Synchronize and Stabilize Methodology

One open-source model is the one used by Microsoft. The methodology is used to build Microsofts consumer level products with the synchronize and stabilize methodology (see Figure 4.11). The concept is easy project team members synchronize their individual/team tasks on a continuous basis and then stabilize the product in small increments, as the project moves forward. The methodology is based on the phases shown in Table 4.6.

Table 4.6: Synchronize and stabilize model

Figure 4.11: Synchronize and stabilize methodology.

This methodology is feature driven. The team members can work autonomously, thereby ensuring that some creative license is allowed on the project, provided their work can be combined successfully into the daily builds. The teams are also allowed to come up with fun ways of discipline when a daily build has not been achieved. Synchronize (daily build) and stabilize (fix errors at end of each milestone), such that the required set of features is completely functional. Product managers develop a vision statement and feature list based on customer input. Program managers develop an initial functional specification based on the vision statement. Program managers create schedules and parallel feature teams of three to eight developers and testers based on the functional specification.

ЬШиЦЩ 1иллл1М1Ы1Д

Reverse Engineering Development Methodology

Important differences with this development model are the inclusion of two conceptually new steps and the reusability of parts of some existing system. As with most models, the development life cycle starts with the requirements. If we get the requirements wrong, we will be developing the wrong product from the start. The requirements of all stakeholders must be considered.

In Figure 4.12, notice the feedback loops. If a test in design fails, design does not move back to performance analysis. A design problem should not be solved by adjusting a performance parameter. Design problems usually go back to requirements engineering, although it is sometimes permissible to check on the functionality on the way. This does not allow a function to be changed without reference to the root requirement. Similarly, if a code fails a test and is subsequently amended, there should always be a back reference to the design of that portion of code. Integration and test phase problems should not be rectified by reference to the coding phase but should go to the root at the design phase (then possibly back further). Many projects have been allowed to go horribly wrong by taking shortcut measures in the software and hardware developments or accidentally omitting the loop back to the correct place in the development life cycle. Being unprofessional and taking shortcuts do not work and often cause projects to ultimately take more time, not less.

User

Епдтв&пгьд

, I FiinclkirLBl Analysis

Build / Bvy * Test

Figure 4.12: Reverse engineering methodology.

Requirements Engineering Phase

The stages of requirements engineering (RE) are:

Requirements elicitation: Helping the stakeholder to list and clarify as many requirements as are known.