Stages of the software development cycle
I’ve been in the software business for a very long time. I’ve seen lots of good and bad practices in that time and would like to share some of my thoughts on them. Mostly, I will talk about practices that affect quality and schedule. To facilitate that discussion, I’ll start by defining the various stages of the software development cycle. At least, the way I see it!
1. Concept – somebody gets an idea for useful software or a useful hardware/software combination
2. Requirements Definition – this stage may have several phases such as:
a. Requirements Gathering – this may involve talking to the end users of the software, watching how they do the task you want to help with or, if you yourself will be the end user, just thinking about what you want to accomplish with the software.
b. Requirements Prioritization – by this I mean knowing or learning which features are absolutely critical to accomplish the task and which are less important. Often, the requirements are ranked into categories such as 1 through 3 or Critical, Important or Nice to Have. There are several reasons this is done:
i. It helps you decide which features to do first so that you can offer a prototype or alpha version to testers and/or end users. In some cases, you might want to do a demo of the software to show your progress to management, customers, or the end users.
c. Requirements Documentation – I have seen everything from a list of hand written notes to 2 inch thick for requirements specifications. In my opinion, you must have something written down by the person or team doing the requirements definition so that the people developing and testing the software have a target to aim at! It’s also useful for reviews with the customer. I don’t mean that it has to be fancy or formal or big or detailed. But, it should be written for easy reference and distribution.
d. Requirements Review –Again, we have a wide range of choices. I have seen everything from the 2 programmers chatting in an office to formal reviews with several speakers presenting pieces of the plan to customers and their consultant advisors.
e. Requirements Dissemination – by this I simply mean spreading the word of what the requirements are to the people who will do the work.
3. Design – There can be several phases to this stage too:
a. System Design refers to the high level design and feasibility analysis that answers the following sorts of questions:
i. Is the project possible with current “off-the-shelf” technology?
ii. If not, can the necessary hardware and/or software be developed in a timely manner?
iii. What sorts of technology can be put together to solve the problem?
b. Component Design refers to the mid level design each component of the overall system.
c. Detailed Design refers to the low level chunks of the system such as objects, library methods, etc.
4. Development – the coding of the required software and manufacture or acquisition of the necessary hardware
5. Unit Testing – The testing of the low level chunks of the system objects, library methods, etc. These tests are usually written by the developer. The testing stages can be grouped under a heading such as Integration & Stabilization. I have intentionally not done that.
6. Integration Testing – Testing the interfaces between individual components of the system.
7. System Testing or End-to-End Testing – Testing the entire system for functional and performance requirements.
8. Delivery (or Deployment or Distribution)
9. Support (or Maintenance) – This can involve training for the customers/users, bug fixing, updating documentation, online or telephone help, etc. The activities in this stage are affected by decisions made in Design and Development stages.
Sometimes, the line between stages is blurred. Sometimes, a stage or a phase within a stage can be omitted due to the nature of the project. Next time I will begin talking about various approaches and practices.