Instead of functions, start with subroutines. Tell them that a program is just a list of instructions, a recipe to tell the computer how to do something. And that it is being executed one instruction after another (with a possibility to make some steps in parallel, but more about that later).
Some tasks are quite common and repetitive, so it would be terrible if we had to always write them down again and again, so we write them just once and make a "smaller program" out of it – a subroutine, that can be reused by other parts of the program. In order to be able to execute it more than once, we give it a meaningful name in our program. And then we can use that name when we want to execute this "little program" as part of a bigger one, by calling it by that name.
Calling a subroutine is like summoning a demon who knows how to perform that task, by the name of that demon. So when we want to do that particular task in our program, we write "call the demon named Argoth", and the demon shows up and does the task for us as we instructed him to do, and then goes away and we can continue our job.
Sometimes the demon requires some additional information without which he cannot decide which of the tasks to perform, or what we really want from him. E.g. if the demon is supposed to build a castle, he may need to know where he is supposed to build it, or how big, etc. Those are the arguments passed to the demon... I mean, the subroutine, which now becomes parametrized.
Parameters are those pieces of information that are missing, but required, in order to do the task. They change what the subroutine can do by a little bit. They are like blank slots in the recipe that need to be filled in before we could execute it.
Arguments, on the other hand, are the actual information (values) that we supply for these parameters.
As for parallel execution, we can think of it this way: there's always someone (or something) that is executing the program (the list of instructions). It's either another human being (did you know that "computer" was once a name for a person who was performing the computation?), or a machine. A program is just a list of instructions, it doesn't work on its own. There must be someone or something who will do the computational process (perform these actions from the list). And sometimes these actions can be done in parallel – we can distribute the copies of the list to several people and let each of them do a different set of tasks from the list, as long as they don't interrupt each other, or don't have to wait for the results of someone else's work. That's multithreading for you ;)
As for the difference between functions and subroutines (also called procedures), the usual difference is that a function is being called to calculate a certain value which it returns as a result of its execution, while procedures are being executed just for fun ;) AKA for their "side effects" – just for the sake of the operations performed from the list.
But if calling a procedure or function causes some trouble at first, you can use another term that was once popular: jumping. One can jump into a subroutine, which means that you stop executing whatever you're doing right now, and "jumping" to another place on the list (or another list whatsoever) – the subroutine – in order to perform its tasks. Then, when you finish, you "jump back" – that is, you return to the place you've been interrupted, so that you could continue with your previous task. The difference between calling and jumping is that now you are the demon.
As for methods mentioned here by someone, or the fact that some languages "doesn't have functions, only methods" – that's not quite correct, because methods are functions! – a special kind of them: they are functions that are being used to retrieve some information encapsulated inside an object, or operate on them. They are a "method of operating on those data". The name came from object-oriented paradigm in which data are enclosed withing objects and cannot be operated directly, only by special functions called "methods".
A method is special in a certain other way: it has to know which particular object it is supposed to operate/be called on (the "this" object). That's why methods are usually embellished with an additional hidden parameter that stores information about the object upon which it has been called (the "this" pointer). This complicates the way the function is being called a bit, but it's an "implementation detail" a programmer shouldn't bother much, as long as he knows what he's doing.
