Hi, I’m going to tell you about how to implement «staged delivery» in your software project. First of all let’s discuss what is staged delivery. Staged delivery is an approach to organize the deliveries on a software project, it is based in stages, there isn’t a magic number for this, some one need 5, 2 or just one stage to release the product. Why staged delivery is the best? because this means the most important part of the project is going to be build at the first stages. The best of all is that everybody could track it, upper management, costumers and users.
Software projects are divided into three conceptual stages:
The first phase is going to be discovery, here is where the uncertainty areas changed to certainty areas. Here is where technical investigation and building user interface prototypes take place.
In the middle of the project is where the phase change to invention. Here is where developers at macro level invent a software architecture and design. At the micro level, each function or class may require small inventions.
In last part the phase shifts again into implementation. In this phase is where the work done in discovery and invention are mapped.
The next figure illustrates how a staged delivery take place:
This plan emphasizes project planning and risk reduction. The project team develops a software concept first, then gathers and analyses requirements and then completes an architectural design. In each stage the project team does detailed design, coding, debugging, and testing. As I mentioned at first It doesn’t need to be 3 stages, this is only a example of how it will be if there is only 3 stages. But in real life it will take more than three or less.
The benefits of this are:
- Critical functionality is available earlier.
- Risk are reduced early.
- Problems become evident early.
- Status-reporting overhead is reduced.
- Staged delivery makes more options available.
- Staged delivery reduces the possibility if estimation error.
- Staged delivery balances flexibility and efficiency.
But there are some disadvantages:
- Increases project overhead.
- Retest already tested features.
- Perform version control tasks associated with making a delivery
- Address extra complexity of supporting additional versions of the software in the field.
The next picture define a well structured project and its stages:
The black line shows the nominal code growth pattern, and the shades area shows the range of normal variations. The variations in code growth in the middle of the project are due too interim releases in which the projects emphasis shifts from generating new code to raising the quality of existing code.
Telling this, here is another approach:
Change control procedure
This approach ensure the project to be stable if there are changes ready to be implemented. This approach evaluates, control and approves important changes.