Iteration in Software in Project

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)

Versioned releases

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.

 

Figure 1-7. Functionality of versioned releases

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.

 

Living documents

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.

Daily builds

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.

Managing Project Trade Off

Projects frequently fail, are completed late, or exceed the planned budget. Ambiguous project scope can contribute to or be the cause of each of these problems. The scope of a project specifies what the solution will and will not do. To effectively define and manage the scope, you need to:

• Identify project constraints

• Manage tradeoffs

• Establish change control

• Monitor project progress

In the process of identifying and managing tradeoffs, you are not necessarily reducing the features of a solution, but identifying tradeoffs might result in a reduction of features. Managing tradeoffs provides a structured way to balance all parts of the project while realizing that you cannot attain all of your goals at the same time. Both the team and the customer must review the tradeoffs and be prepared to make difficult choices.

The tradeoff triangle and the project tradeoff matrix are two of the tools that MSF uses for managing tradeoffs

Project Management Role and Responsibilities

To deliver a solution within project constraints, strong project management skills are essential. Project management is a process that combines a set of skills and techniques to address the following tasks:

• Integrate planning and conduct change control

• Define and manage the scope of the project

• Prepare a budget and manage costs

• Prepare and track schedules

• Ensure that the right resources are allocated to the project

• Manage contracts and vendors and procure project resources

• Facilitate team and external communications

• Facilitate the risk management process

• Document and monitor the team’s quality management process

• makes the final decision on the issue by transitioning into the role of decision leader to enable the project to continue.

• Program management makes the decision with the goal of meeting the customer’s requirements and delivering the solution within the constraints. After the decision is made, the team returns to operating as a team of peers.

Project readiness Management Process

The Project readiness management discipline includes a process to help you develop the knowledge, skills, and abilities (KSAs) needed to create and manage projects and solutions.

Each step of the process includes a series of tasks to help reach the next milestone.

• Define. During this step, the team identifies the scenarios, competencies, and proficiency levels needed to successfully plan, create, and manage the solution. This is also the time to determine which competencies and corresponding proficiency levels are required for each role in the organization. The assigned role determines whether an individual needs to be proficient in one or many of the defined competencies.

• Assess. It is during this step that the team begins analysis of the current competencies as they relate to the various job roles. The purpose of this analysis is to determine the skills of individuals within each of these roles. The team then compares the competencies identified in the previous step to the current competencies. Comparing current skill levels to required skill levels is necessary to develop a learning plan, so that team members can reach the necessary competency levels.

• Change. During this step, team members begin to improve their skills by means of structured learning to raise current proficiency levels to the desired levels. This step consists of:

  • Training. The learning and mentoring that occurs according to what was outlined in the learning plan.

  • Tracking progress. The tracking of progress that enables individual or overall readiness to be determined at any time during the life cycle. This tracking enables the team members to make necessary adjustments to the learning plan.

• Evaluate. During this step, the team determines whether the learning plans were effective and whether the lessons learned are being successfully implemented on the job.

Project Risk Management Process

The Project risk management discipline advocates proactive risk management, continuous risk assessment, and decision making throughout the project life cycle. The team continuously assesses, monitors, and actively manages risks until they are either resolved or turn into problems to be handled as such.

The  risk management process defines six logical steps through which the team manages current risks, plans and executes risk management strategies, and documents knowledge for the enterprise.

1. Risk identification allows individuals to identify risks so that the team becomes aware of any potential problems.

2. Risk analysis transforms the estimates or data about specific project risks that emerges during risk identification into a form the team can use to make decisions about prioritization.

3. Risk planning uses the information obtained from risk analysis to formulate strategies, plans, and actions.

4. Risk tracking monitors the status of specific risks and documents the progress in their respective action plans.

5. Risk control is the process of executing risk action plans and their associated status reporting.

6. Risk learning formalizes the lessons learned and relevant project documents and tools, and records that knowledge in reusable form for use within the team and by the enterprise.

Project Team Model

In an enterprise solution project, a large number of activities must be performed, and the project must be viewed from several perspectives. To accommodate these needs, the MSF Team Model specifies six distinct roles, and each role has clearly defined responsibilities and goals.

The roles in the Project Team Model are as follows:

• Product management. Responsible for managing customer communications and expectations. During the design phase, product management gathers customer requirements and ensures that business needs are met. Product management also works on project communication plans such as briefings to the customers, marketing to users, demonstrations, and product launches.

• Program management. Responsible for the development process and for delivering the solution to the customer within the project constraints.

• Development. Responsible for developing the technology solution according to the specifications provided by the program management role.

• Testing. Responsible for identifying and addressing all product quality issues and approving the solution for release. This role evaluates and validates design functionality and consistency with project vision and scope.

• Release management. Responsible for smooth deployment and operations of the solution. Release management validates the infrastructure implications of the solution to ensure that it can be deployed and supported.

• User experience. Analyzes performance needs and support issues of the users and considers the product implications of meeting those needs.

• Additional team members

  In addition to the roles defined previously, the project team also includes the project stakeholders, though they are not part of the MSF Team Model. These stakeholders include the following roles:

  • Project sponsor. One or more individuals initiating and approving the project and its result.

  • Customer (or business sponsor). One or more individuals who expect to gain business value from the solution.

  • End user. One or more individuals or systems that interact directly with the solution.

  • Operations. The organization responsible for the ongoing operation of the solution after delivery.

Process Model

 A Process Model guides the order of project activities and represents the life cycle of a project. Historically, some process models are static and others do not allow checkpoints. Two such process models are the waterfall models and the spiral model.

Waterfall Model:

This model uses the milestone as transition and assessment points. When using the waterfall model, you need to complete each set of tasks in one phase before moving on to the next phase. The waterfall model works best for the project in which the project requirements are clearly defined and are not liable to modification in the future.  Waterfall model allow us to monitor schedule easily and assign clear responsibilities and accountability because it has fixed transition points between phases.

Spiral Model:

The model is based on the continual need to refine the requriements and estimates for a project. The spiral model is effective when used for rapid application development of very small project. Customer is also involved in all stages by providing feedback and approval, so it helps to improve communication between development team and  the customer. It does not incorporate any clear checkpoints. Consequently, the development process might become chaotic.

MSF Process Model:

MSF Process Model is phase-based, milestone driven and iterative model that can be applied to developing and deploying traditional application, ecommerce and web distributed application.

It combines the best principles of the waterfall and spiral models. It combines the waterfall model ’s milestone-based planning and resulting predictability with the spiral model ’s benefits of feedback and creativity.

Agile Process Model: 

Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project.

There are many agile development methods; most minimize risk by developing software in short amounts of time. Software developed during one unit of time is referred to as an iteration, which may last from one to four weeks. Each iteration is an entire software project: including planning, requirements analysis, design, coding, testing, and documentation. An iteration may not add enough functionality to warrant releasing the product to market but the goal is to have an available release (without bugs) at the end of each iteration. At the end of each iteration, the team re-evaluates project priorities.

Agile methods emphasize face-to-face communication over written documents. Most agile teams are located in a single open office sometimes referred to as a bullpen. At a minimum, this includes programmers and their “customers” (customers define the product; they may be product managers, business analysts, or the clients). The office may include testers, interaction designers, technical writers, and managers.

Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for face-to-face communication, agile methods produce very little written documentation relative to other methods. This has resulted in criticism of agile methods as being undisciplined.