Iteration in Software in Project
Posted by sirajq on March 11, 2008
While development of the solution continues through its phases, each iteration of the process brings the solution closer to its final release. Iterations are continued within a specific phase until the goal for the phase has been reached. In addition, an iteration allows the project to be developed in smaller steps, with future iterations being based on the success or failure of an earlier step. Deliverables such as the vision/scope document and other documents, code, designs, and plans are developed in an iterative manner. Instances of iteration in a project life cycle include:
-
Creating versioned releases
-
Creating living documents
-
Creating periodic builds (weekly or daily)
When using MSF, a team develops solutions by building, testing, and deploying a core of functionality, and then adding sets of features to the solution in every release. This is known as a version release strategy.
Figure 1.7 illustrates how functionality develops during the creation of many versions of a solution. The time between versions depends on the size and scope of the project.
Versioned releases improve the team’s relationship with the customer and ensure that the best ideas are reflected in the solution. Customers will be more receptive to deferring features until a later release if they trust the team to deliver the initial and subsequent solution releases on time. Several guidelines facilitate the adoption of versioned releases:
-
Create a multiple version release plan. Thinking beyond the current version enhances a team’s ability to make good decisions about what to create now and what to defer. This allows the team to make the best use of the available resources and schedule. In addition, you can prevent unwanted expansion of scope by providing a timetable for future feature development.
-
Work through iterations rapidly. A significant benefit of versioning is that it delivers usable solutions to the customer quickly and improves them incrementally over time. Maintain a manageable scope so that iterations are achievable within acceptable time frames.
-
Deliver core functionality first. Delivering a basic solution that is solid and usable is more effective than developing a solution that the customer cannot use for weeks or months. Delivering core functionality first enables developers to incorporate customer feedback that will motivate feature development in subsequent iterations.
-
Create high-risk features first. During risk assessment, the team identifies the riskiest features. Schedule these features for proof-of-concept testing first. If you encounter any problems that require major changes to the architecture, you can implement the changes earlier in the project and minimize the impact to schedule and budget.
To ensure that you do not spend too much time refining the early phases of the project, you need to create living documents—that is, documentation that changes as the project changes. Living documents allow teams to make modifications to any aspect of the project design and development when there is a change in requirements. This process ensures that the completed solution meets the final requirements and not just the initial set of requirements. MSF project documents are developed iteratively.
For example, the MSF Process Model recommends that planning documents start out as generalized documents without extensive details. They are submitted for review by the team and stakeholders during the initial stages of the project. As the solution progresses through different phases, the documents are developed into detailed plans. These plans are once again reviewed and modified iteratively. The type and number of these plans depends on the size of the project.
MSF recommends the preparation of frequent builds of the components of a solution for testing and review. This approach applies to developing code in addition to builds of hardware and software components. By creating daily builds, you can ensure that you understand the stability of the total solution and have accumulated ample test data before releasing the solution.
Using the daily build approach is particularly effective for larger, complex projects that are divided into smaller subsystems. Separate teams develop and test these subsystems and then consolidate them into a single solution. Developers complete core functionality of the solution or product first, and add additional features later. Development and testing occur continuously and simultaneously. Creating daily builds ensures that all code is compatible and allows the various subteams to continue their development and testing iterations.
