Software is a program designed to solve a problem or fill a niche. Usually, software development goes through the following phases.
Before you can solve a problem, you must identify what that problem really is. We need to identify the following things if we want to make a useful product:
- User – Is this designed for yourself (meaning that you know exactly how it works), or for another engineer (who can deal with complex programs), or for a casual user?
- User Needs – How does the user intend to use the program? If it’s a database program, do the users intend to collect unsorted data (BIG DATA!), or financial numbers, or recipes?
- Requirements – What does the program need to do in order to make the user experience work?
- Interfaces – If working with other engineers or teams, how will you split the workload? And, after the workload is split, how will you bring the pieces together?
We now have to craft the solution.
First, we break the requirements up to create batches of functionality called modules. These modules are self-contained units, which can be connected to create complex programs. This is the principle of modularity – breaking the problem into understandable units which can be changed without affecting the rest of the program.
Second, we have to decide how we will build these modules. This includes which languages and tools we will use for development. Note that these tools can include libraries, IDEs, and other programs which help make our programming job easier.
Third, we have to figure out the basic details of how these modules will operate. Flowcharts and pseudocode are common in this phase.
Now that we’ve designed a solution, we need to make it real. This is the phase of implementation or coding.
During this phase, we use the language(s) we have chosen and the tools we’ve selected to generate the actual source code.
Once we have code, we have to figure out whether it works as intended. The testing phase involves looking for the following things:
- Happy Case – If we do everything exactly right, does the program work the way we want it to?
- Expected Error – There are very common ways for things to go wrong. In a network program, for example, we have to deal with dropping the connection. It is also (embarrassingly) common for users to screw up. We need to make sure that these errors don’t break everything!
- Unexpected Error – We can’t anticipate everything, but we can try throwing all sorts of gibberish at the program to see if we break it.
- Interface Error – Finally, when we hook the program up with the other pieces, we need to make sure that the entire package works properly. If we did the other three tests right, and we followed our design, this should be the easiest testing phase.
Finally, we have something worth using, and we give it to the user. So long as our program continues to solve their problems, the user will continue to use the program.
Often, in industry, we do support and maintenance on released code. Support involves explaining how the program is supposed to work and handling problems as they come up. Maintenance involves changing the program to fix errors and add functionality. These two activities extend the release life of our programs.
Archiving and Destruction
Most programs eventually become obsolete as the problems they solve change, or as technology advances. When the time comes to stop using these programs, we either archive them by storing them on CDs, etc. or we destroy them completely.
Generally speaking, I don’t recommend destruction, because we can learn from the lessons of old programs. Also, people often forget to update their data to use the new programs, meaning that you will have to pull the old tool back out at some point.