There are many ways to divide the Software Development Life Cycle. I've choosen some common terms, but don't be surprised to see other terms. Here's a brief explanation of the what each means.
When you understand a problem and its solution very well,
it's possible write a program by following the steps at the left.
But problems are rarely understood as well at initially thought, and
this "waterfall" approach has turned out to be responsible for an
extraordinarily high number of software project failures.
There are several reasons for this.
Although it is probably responsible for more failures than successes, not everything is bad about this approach.
It's often hard for students to restrict themselves to small changes, and they write many, many lines of code. Or to think of it another way, many bugs. The more simultaneous bugs a program has, the harder it is to debug, so keep the number of new bugs to a minimum.
Making very small changes, compiling and testing means that you are much less likely to be faced with a long list of error messages with no idea how to find the problem. A single missing left brace can produce many error messages. If you've only entered a few lines of code before recompiling, you know the error is in those few lines of code and it's much easier to track it down.
A good technique for all programs is to develop them iteratively or incrementally. These are the common programming terms that mean to do them in little steps, where each you compile and run after making each small step.
This is the recommended technique for all programs, from very large to very small. It has several advantages over trying to write the program as one lump.
A disadvantage of iterative programming is that it tempts you to start coding before you have a clear idea of what you want to do. Think about the problem a little bit before you start. This design process becomes more important as programs become larger.