Back Up Next

Chapter 4: Software Development Track Milestones

Certification Objectives. 2

Achieving Shared Vision for a Project Team.. 4

Defining the Vision/Scope Approved Milestone. 7

Identifying the Interdependent Roles/Shared Responsibilities of Project Team Members. 9

Describing the Deliverables to be Produced during the Envisioning Phase. 9

Defining the Tasks Leading to Vision/Scope Approval 11

Writing the Vision/Scope Document 14

Determining the Project Structure. 17

From the Classroom.. 18

Exercise 4-1: 19

Defining the Project Plan Approved Milestone. 19

The Importance of a Functional Specification. 22

The Interdependent Roles/Shared Responsibilities of Project Team Members. 23

Defining the Deliverables for the Planning Phase. 24

Developing a Functional Specification. 25

Developing a Project Plan. 26

Developing a Project Schedule. 27

Defining the Scope Complete/First Use Milestone. 29

Defining the Deliverables for Scope Complete/First Use. 32

Defining the Release Milestone. 35

Effective Usability Testing. 38

Defining the Deliverables for Release. 39

Two-Minute Drill 44

Answers to Exercise 4-1. 47

Answers to Exercise 4-2. 47

Answers to Exercise 4-3. 48

Answers to Exercise 4-4. 48

Answers to Exercise 4-5. 48

 

Certification Objectives

·       The Vision/Scope Approved Milestone

·       The Project Plan Approved Milestone

·       The Scope Complete/First Use Milestone

·       The Release Milestone

For software development projects, the process model is an invaluable tool for good project planning. This model is used to assist in planning and managing projects, and acting like a roadmap, it shows the activities that take place in a solution’s life cycle. Starting with the conception of the solution, and going step-by-step through the development cycle to its release, the process model allows members of the team to synchronize their efforts and see progress in a project by the activities that have been completed.

The Process Model

As we saw in Chapter 2, the process model breaks a project up into four phases, with each phase culminating in a milestone. Milestones mark the point where one phase of the project ends and another begins, and indicate a point in the project where team members should synchronize their efforts. Milestones are customer oriented, and are used by team members to see if the project is still meeting customer expectations. This allows them to deal with changes required in a project, and assess the risks that will be associated with those changes.

In using the process model, it’s important to distinguish between project phases and project milestones. Each phase of the process model is where the work is performed to achieve the milestone. People in the different team model roles perform various tasks, working to reach the milestone at the end of each phase. These phases, and their associated milestones, consist of the following:

·       Envisioning phase, which results in the vision/scope approved milestone

·       Planning phase, which results in the project plan approved milestone

·       Developing phase, which results in the scope complete/first use milestone

·       Stabilizing phase, which results in the release milestone

Through the work performed in these phases, you complete part of the overall project. The milestones at the end of these phases allow members of the project team to coordinate their efforts, and see what work has been done. It also allows them to see where they need to go forward to ensure the project’s success.

The four phases of the process model always follow the same order, starting with the envisioning phase, and ending with the release milestone of the stabilizing phase. Each of the phases of the process model result in several deliverables. A deliverable is a tangible result of the work performed. It can be a document that outlines risks, one that lays out the features and functionality of the product, or it can be the completed product itself. This is something we’ll see as this chapter progresses, and we discuss each of the four phases and their related milestones individually.

 The Vision/Scope Approved Milestone

The first part of any well-planned journey involves determining where you’re going. That’s what the envisioning phase of the process model accomplishes. The design of any application is driven by the needs of the user, and this is what the envisioning stage works to understand. Tasks performed during this phase of the process model are geared toward determining what the project entails. The team looks at what issues are driving the need for the product or service, and what features should be incorporated to address future needs. This phase not only identifies the present needs of the organization, but attempts to predict future needs while allowing for growth. In doing so, an understanding of the customer’s needs, and the issues surrounding those needs, is attained.

The envisioning phase uses a proactive approach to determining what features should be included in a product. By spending some time to project where the organization may wish to expand their services, the team has a better understanding of whether to include certain capabilities in the project, thus likely saving money and time in the future. Through the use of versioned releases of the product, each of the current and future needs of the organization can be addressed. Though certain functionality may not appear in the current version of the product, it can be included in future versions.

Once both the customer and team achieve a shared understanding of what’s expected from the application, the envisioning phase reaches its major milestone: the vision/scope approved milestone. It occurs when an agreement is made between the customer and team on the direction the project will take. As we’ll see in the sections that follow, a considerable amount of work goes into reaching this milestone, which results in several deliverables. The information gathered during this phase, the work performed by the team, and the deliverables produced, are used by the team in other phases of the process model.

Achieving Shared Vision for a Project Team

Calling this first phase of the process model the envisioning phase captures the goal of this first stage of software development. The envisioning phase strives to achieve a shared vision for the project team. Vision is an unbridled view of a project’s goals, with no consideration given to the constraints of a project. Vision looks at the project from the perspective of the business and user, and focuses on what elements these parties find desirable and what should be added to the project.

With vision, the constraints of a project aren’t an issue. When you consider that any application is bound by technical constraints of operating systems, network configurations, and so forth, this may see strange. Any software development project is also restricted by the constraints of time, money, and available resources that affect how and when the project will be undertaken. However, these all hinder the imagination of team members and stakeholders. Vision doesn’t acknowledge such constraints, because to do so would be a stumbling block to any of the exciting ideas that interested parties might have. You want people to have the utmost creative freedom at this point. Introducing constraints at this point only stifles people’s creativity, and blurs the vision of what the project could be.

This isn’t to say that the constraints mentioned aren’t considered in the design of your product. That is where scope comes into play. Scope is a narrowing of vision that maps the vision of a product against technology and project constraints. Vision is a dream of what your application could become, and scope is a detailed analysis of that dream that defines whether certain aspects of the dream can become reality. Scope looks at whether features can be included in a current version—based on scheduling, cost, the availability of resources, and other issues—and determines if certain features must be put off for now, and included in future versions of the product. It defines the limitations of a product or service, and determines what can be done within the project’s constraints. It balances optimism with realism, looking at what the customer needs and what can actually be done to fulfill those needs.

Through a balancing of vision and scope, a clear understanding of what the project entails is achieved. As we’ll see later in this chapter, this shared vision is outlined in a vision statement or vision/scope document. The vision/scope document is a documentation of this shared vision, and specifies the direction and goals for a project.

Team Focus

In Chapter 2 we discussed the different roles that make up the MSF team model. In performing the various activities associated with the envisioning phase, team members in these roles focus on different tasks to ensure the success of this phase of the project. This means that each team member brings a level of competence to a specific area of the project. The work done successfully in one area of the project compliments the work done in other areas to ensure the success of the project as a whole.

In the team model, the team leaders are entrusted with supervising, guiding, and coordinating the teams. Team members have clearly defined roles, which allow them to focus on specific areas of the project. At each phase of the process model, one of the team model’s roles is accountable for planning, managing, and executing the tasks associated with a particular milestone. They “own” the responsibility of ensuring that the team achieves a milestone.

In the envisioning phase, it is the responsibility of Product Management to see that the team achieves the vision/scope approved milestone. This role is responsible for identifying user needs, the business problem, expected benefits of a solution, project vision, and the risks associated with the project. These are documented in the vision statement, which Product Management is responsible for creating and maintaining. In managing the expectations of a product, Product Management ensures that expectations are clearly communicated to both the project team and the customer. This allows both customer and project team to have a shared vision of what the project entails.

Program Management is responsible for setting design goals for the project. In doing so, this role establishes what factors will determine the project’s success, and what metrics will be used to measure this success. Program Management is also responsible for documenting the solution, researching the existing infrastructure that will be used with the product, and chronicling the success factors and metrics. This allows the team to see how well they are doing on the project, and initial specifications that will be used in the product.

During this phase, Development assists Program Management with documenting the solution. This role also researches existing solutions. This allows the team to determine if there are applications already available that provide the features and functionality that the customer requires. In doing so, a decision can be made to use and/or purchase an off-the-shelf solution rather than developing a solution that does the exact same thing or to design the new application to work with existing applications.

User Education determines training requirements for users of the solution. In doing so, this role identifies and establishes communication channels that can practically be used to advise and inform users of the application. In addition to users, User Education also determines any necessary training requirements for project team members. If a new language must be learned by Development, or other team members require some other upgrading in education, it is up to User Education to ensure that training is available and provided.

Although there is no actual solution to test at this point, Testing must begin work on developing a testing process that will be implemented at a later stage. This role is responsible for developing the test criteria based on the design goals of the project. It determines the frequency and process of testing, logs risks, and risk rates, and establishes a mechanism for feedback on the solution.

Logistics has the task of identifying any possible constraints that may affect the project. Team members in this role must research and report on constraints, inclusive to materials that may or may not be available for the project. Logistics also identifies any shipping and delivery issues that may arise. Through the work performed by Logistics, a foundation is set for long-term management and support.

Defining the Vision/Scope Approved Milestone

The vision/scope approved milestone occurs when the project team, customer, and stakeholders come to an agreement on key aspects of the project. This includes such elements as the vision and scope of the project, and the priority of which business requirements need to be addressed first. The team, customer, and stakeholders come to an understanding of how the solution will solve the organization’s business requirements. Business constraints that could affect the project are identified, discussed, and agreed upon as potential risks. Other risks and assumptions associated with the project are also addressed, as is the time frame in which the functionality of the application needs to be available. The level of work needed in the next phase of the process model is determined, setting the initial foundation for the decisions on resources that will be made in the planning phase. When an agreement is made on such elements of the project, the vision/scope approved milestone is reached, and the team moves into the planning phase of the project.

The way that team members, customers, and stakeholders come to this agreement is with the vision/scope document, which is also called a vision statement. This document outlines what each of these parties is agreeing to, by providing a conceptualization of how the project will look upon completion. Essentially acting as a contract, this document establishes the project’s scope, vision, and provides direction to team members. It provides an explanation of how the solution will solve the organization’s business requirements. It does this by utilizing scenarios the organization may experience, explaining specific features of the product, and defining the vision and scope of the project.

By agreeing to the contents of the vision statement (vision/scope document), everyone demonstrates a clear understanding of what will be created. They agree and show understanding of the work that needs to be done, what the project entails, and what the finished product will be. This establishes clear design goals, and sets the foundation for work that will be done in ensuing phases of the process model.

Interim Milestones

While each phase of the process model has an associated milestone, this may not be enough on larger projects. Larger projects can take so long to complete that the time between each of the four milestones lessens the benefits of a milestone-based process. Rather than being able to coordinate and synchronize their efforts, members of the team can lose effectiveness because it takes so long to move from one major milestone to the next. Instead or working as a team, and having one another’s work complimenting each others, they become small groups of individuals that may lose focus on what the project is really about. This is where interim milestones become a vital part of the process model.

Interim milestones are like mini-milestones. They occur between the major milestones of the process model, and provide additional coordination points for members of the team. This allows team members to get together and discuss areas of the project. Depending on the phase the team is currently in, the formal or informal meetings arranged for interim milestones may include addressing scheduling, specifications, or other elements of the project. Each phase of the process model has interim milestones that can be used.

The envisioning phase of the process model has two interim milestones associated with it. These interim milestones are the vision statement draft and design goals draft. A draft is a rough or preliminary copy of a final document. The design goals draft provides the team with a chance to review the design goals of the project before they’re included in the vision/scope document. This allows team members to discuss what they consider the design goals of the project to be, to add new goals, and remove ones that don’t meet the actual vision of the project. Similarly, the vision statement draft allows the team to discuss and analyze the business problems, which are solved by the solution, and set the focus of the project. This allows the team to boil down the issues faced by the organization, and identify the problems and features that will solve these problems. Once the issues discussed in the vision statement draft are finalized, they are included in the vision/scope document (vision statement).

Identifying the Interdependent Roles/Shared Responsibilities of Project Team Members

Earlier in this chapter, we discussed how the different roles of the team model work together on different tasks of the envisioning phase. Product Management has ownership of the envisioning phase, and is responsible for seeing that the tasks associated with this phase are carried out. Each of the roles of the team model work as a group of peers, and depend on one another to carry out the activities they are responsible for.

If one of the team roles fails to complete their duties, then the envisioning phase will fail to reach the vision/scope approved milestone. Program Management relies on Product Management to supply the customer requirements and set the vision for a project. Program Management works with Development to document the solution, which provides information that Logistics and Testing require to fulfill their tasks. If the team requires training—such as Development needing education on new technologies— User Education must provide that training. Though existing in different roles, with different duties, each member must work together as a team if the project is to succeed.

Describing the Deliverables to be Produced during the Envisioning Phase

A deliverable is a product of work that’s generated from the activities of a given phase in the process model. Unlike interim milestones, which are points of time allotted for the team to synchronize their efforts, a deliverable is a physical component that results from the work that’s been done. Each of the four phases results in deliverables that are used in other phases of the process model.

The envisioning phase results in three deliverables: the vision/scope document, the risk assessment, and the project structure document. Each of these documents provides valuable information that is used to ensure the project’s success.

The vision/scope document is used to explain the project. Basically, it describes what the project entails, and answers the questions of who, what, when, where, and how things will be done. It provides the team with direction, sets expectations for the team, and describes the criteria that the team will use for the design and deployment of the finished product. The vision/scope document consists of four distinctive components. These are the problem statement/business objectives, the vision statement, user profiles, and the solution concept. Each part of the document describes or explains a different aspect of the project, and serves to aid team members in completing their individual assignments.

The first part of the vision/scope document is the problem statement/business objectives, which outlines the rationale behind the project, and describes the needs and objectives of the organization. This is used to explain why the project is being undertaken. It answers the question of what needs and problems the solution is required to meet and solve.

The vision statement component addresses the issues raised in the problem statement/business objectives segment of the document. It outlines the long-term vision of the project. In essence, the vision statement is the meat of the document in that it’s what people think of when considering vision/scope documents. Therefore, vision/scope documents and vision statements are often used synonymously. The statement provides information that guides the decision-making of the project team throughout the life of the project. It is also instrumental in providing the project team with a way of evaluating the project.

User profiles provide a way for the team to understand whom they’re creating the software for. In short, it describes the end user of the application. The information contained in the user profile guides the team in communicating how much change the solution will cause for the user, by allowing them to assess the expectations, risks, goals, and constraints of the project. By understanding the end user, the team has a better success rate of meeting the end user’s needs.

The final component is the solution concept. This part of the document provides the groundwork for creating specifications for the solution. It details how the team will initiate the planning process, and defines the work necessary to successfully complete the project. This allows the team to establish priorities for the project, and determine what features are necessary for the current version, and which features should be passed forward to future versions. The major focus of the solution concept is defining the services that will comprise the application. These services fall into one of three categories: user services, data services, and business services. From Chapter 2 you’ll remember that these services make up the MSF application model, which we’ll discuss further in future chapters of this book.

Moving away from the vision/scope document, the second deliverable of the envisioning phase is the risk assessment. As we saw in the previous chapter, a risk is the possibility of incurring some sort of loss. Left unchecked, a risk could jeopardize a project’s success. A risk assessment is used to determine the likelihood of a condition or situation that could adversely affect the project. This assessment identifies risks that could emerge in the project, evaluates what impact they would have on the project, and provides general provisions for monitoring such risks.

In writing a risk assessment, you would identify each individual risk in the project. This could be as simple as a paragraph on each risk. It should mention what the risk is, how it could affect the project, how it should be monitored, and what could be done to deal with it. In short, you would address the who, what, when, where, and how of the risk. By identifying and determining the level of risk, you are better able to deal with it.

The final deliverable produced during the envisioning phase is the project structure document. This document is used to outline how the project will be managed and supported. In addition, it details the administrative structure for the project team. While we’ll discuss this document in a later section of this chapter, it’s important to realize that the work done on this document doesn’t end in the envisioning phase. It is passed forward and updated at the project plan approved milestone, when resources have been assigned to the project.

Defining the Tasks Leading to Vision/Scope Approval

Reaching the vision/scope approved milestone requires an agreement between the customer, the project team, and any other stakeholders in the project. This agreement is on several key points dealing with the project:

The overall vision for the project
Which business requirements should be addressed first
Setting a time frame for the project
Risks that are associated with the project
Business constraints that may affect the project
The required effort expected to complete the project.

In going through each of these points, you can see that each is a major element of the project as a whole. Without agreement on these issues, the team, customer, and other stakeholders will fail to have a shared understanding of what the project entails.

It’s important to remember that the vision/scope approved milestone occurs when the vision and scope of the project have been agreed upon. The points listed above must be met to move onto the next phase of the process model. If this hasn’t occurred, the milestone can’t be reached, and additional work is required.

On the Job: The vision and scope of a document allow everyone involved in a project—team members, customers, users, and other parties alike—to have a clear understanding of the project. This is important because it is easy for different people to have different perceptions of a project. While one party may view the project as a spreadsheet program, others may see it as more of a database application. It’s important to understand what the project is, as well as the features that will and will not be included in a version. Without a clear understanding, the project is destined for failure.

Setting the Vision and Scope for a Project

It’s important for a project to have the vision and scope set if the project is to be successful. Vision is the perceptions of customers, users, team members, and other stakeholders of what the project will be. It allows for creativity, without being burdened by constraints or preconceived limitations. Scope narrows the focus of the project, by mapping the vision to realistic constraints and requirements. It is necessary to do this so you can achieve the vision of the project, without having to trash it as a pipe dream. By properly setting the vision and scope of the project, you can have a clear focus of what the project will be.

The envisioning phase of the process model not only allows the team to focus on the needs of the customer, but also has a focus on the team itself. There is a symbiotic relationship between the customer who buys the product, the user who uses it, and the team that develops it. Neither can do without the other, and none can ignore the others’ importance to the project. A shared vision of what the project entails helps to enforce this relationship, as everyone is working toward a common and well-understood goal.

Once the team has a clear vision of what the organization and users prefer, desire, and need from a project, they are better able to commit to the project. The team members can feel that they’re part of something, and see what they’re working toward. This motivation translates into higher productivity on the part of each team member, and allows the team to feel they’re working together toward a common goal.

The thoughts and ideas of each team member, the customer, business, and end user are given careful examination. This allows members to feel that their input is worthy, and not dismissed out of turn. Communication is a key factor. Allowing team members and stakeholders to openly discuss elements and ideas of the project means that the project has addressed the concerns of everyone concerned.

Communicating this vision of a project to other team members requires a combination of verbal and visual components. As we’ll see later, a vision statement is used to outline the elements that make up the project in a clear and concise manner. Images, diagrams, and so forth can be created to illustrate how a feature or function should work in the product. You can also use existing applications that have similar features to elaborate how a certain feature or functionality in the application will work. Metaphors can be used to translate a feature or functionality in the project in a way that conveys a common image. You’ve probably used metaphors without even realizing it. A file or folder in Microsoft Windows is a metaphor for a binary unit or area or storage, but by using a commonly used metaphor to communicate its functionality, everyone can picture what the file or folder is and does. In Chapter 11, we’ll discuss metaphors in greater detail. It’s important to have clear communication between members of the team, so that they know what they’re working toward, and can then determine how to get that work done.

Throughout the process of acquiring a shared vision of the product, it’s important to keep one thing in mind: the business. Always remember that you’re working to improve the productivity and answer some need that the organization has. While a feature or capability may be interesting to include in the software, it’s useless if it doesn’t actually serve the customer or end user. The components that make up your solution should always be practical for the organization and end users.

Writing the Vision/Scope Document

The vision/scope document is made up of several parts, which together map out what the project entails. These components of the document consist of the problem statement/business objectives, the vision statement, user profiles, and the solution concept. While we’ll go through each of these parts of the document individually in this section, they shouldn’t be thought of as individual deliverables of the envisioning phase. Like chapters making up a book, these components make up the vision/scope document. Together, they provide the team with direction on what is necessary in the project. It explains who will use the solution, the expectations of the customer and end user, and the criteria that will be applied to designing, developing, and deploying the product.

The first part of the vision/scope document is the problem statement/business objectives. In writing this component of the document, you’re explaining the motivation and rationale behind the project. In short, you’re explaining why the project is necessary. What business problem will the solution address? What does the organization hope to accomplish with this application? These are the fundamental questions answered by the problem statement/business objectives portion of the vision/scope document. By defining the problem and stating the objectives addressed with the solution, you can create a product that can directly address these issues.

Product Management acquires information that goes into the problem statement/business objectives through a variety of methods. Interviews can be conducted with customers and end users, as well as senior management—technology and business architects, steering committees, etc.—or IT professionals and sponsors in the organization. These are the people who will benefit from a good solution, and can provide valuable information on the needs and problems faced in the organization. In addition to these individuals, researching documents within the company can provide valuable information on the business’s objectives and problems. Such documents include contracts and commitment documents, such as presentations, proposals, and cost justifications. The availability of such documents depends on the security of the organization. Certain military and corporate clients may be unwilling to divulge such information, for fear that it will leak out into the public. You need to be aware that the avenues available in researching for the problem statement/business objectives portion will vary from organization to organization.

The vision statement portion of a vision/scope document defines the perception or understanding of the project. This is the long-term vision of the product, which will follow the software throughout its development cycle. It defines what the product consists of. This not only establishes what features are to be included in the product, but what features will be left out. It allows the team, customer, and end user to agree on whether certain aspects of the project should be passed forward to future versions.

Setting the features to be included in a product is an important point in design, as issues such as scheduling and budget can affect the vision of the product. This vision of what the project entails needs to be set early in the design of the application. It can be demoralizing for a team to expect to create an incredible product—based on what’s included in the vision statement—only to have the vision change part way through the project. This can occur because the organization needs the product sooner than expected, or due to other issues not expected or considered during the envisioning phase.

The contents of the vision statement aid the team in making decisions throughout the life of the product. The team can look at the vision statement of the product, and determine whether features or functionality meet the set vision of the product. It can help them evaluate their options, by allowing them to view what was originally envisioned as the finished product.

User profiles are a depiction of the user or group who will use the new solution. It identifies who will be the users of the solution. As we’ll see in greater detail in Chapter 9, user profiles allow the team to see from whom the requirements and information on the project is being obtained. Each department, unit, end user, and the business itself may have their own individual needs and goals on a project. User profiles outline the specifics of these users—such as the number of people in a department, geographical locations, and so forth—and allow the team to see if the needs and goals of certain users conflict or agree with one another. It also aids them in gauging the level of change the solution will have on these users. By knowing whom you’re creating the solution for, you have a better chance of that solution being successful.

As we’ll see in Chapter 9, the information gathered for the user profiles can come from a variety of sources. These include Joint Application Design (JAD) sessions, interviews with individual users, and surveys. When used with usage scenarios, which detail how a certain activity or task is performed, user profiles can be a valuable resource in understanding your solution’s target audience.

The final portion of the vision/scope document is the solution concept. This part of the document details how the team will initiate the planning process and the groundwork necessary to successfully complete the project. It includes elements such as the following:

·       project success factors

·       a list of deliverables

·       the operational concept

·       the acceptance criteria for the project

Together, they provide the team with a means of establishing priorities, and setting the groundwork for tasks performed in the next phase of the process model.

Project success factors are used to determine what will make the project successful. There are many different elements that can be used to determine this, inclusive to certain features or functionality in the program, time, monetary factors, comparisons, and so forth. What your team includes as factors will be used later to measure the success or failure of the project.

A list of deliverables is included in the solution concept portion to show what the project will produce. You’ll remember that a deliverable is a tangible result of work performed. The listing of deliverables for the project show what will make the product operational.

The operational concept is a conceptual documentation of how the solution will be implemented, and how users will use the new product. Basically, it is a run down of what the solution will do, how it is used, and how it fits into the existing system. It also shows an understanding of the organization, department, or end user’s workflow.

The acceptance criteria is used to show what is necessary in the project. If a project is to be considered acceptable, certain elements of the project must be satisfied before the product goes into production. A checklist of requirements is created. When a requirement is fulfilled, that particular element is checked off.

A major focus of the solution concept is on each of the types of services that comprise the application. These include user services, business services, and data services. As mentioned earlier, these were discussed in Chapter 2, and make up MSF’s application model. It is important to determine where elements of your application will reside early in design, as this can affect the performance of an application. In future chapters of this book, we’ll discuss each of the services in greater detail, and show how important it is to put the proper coding into the appropriate service.

Determining the Project Structure

As its name implies, the project structure document is used to outline the structure of the project. This includes information such as the following:

·       how the project will be managed and supported

·       the administrative structure of the project team

·       other information that may be helpful to the project team

The project structure document is a vital information tool that is passed forward to the planning phase of the process model. Upon reaching the milestone of this next phase of the process model, the document is updated to reflect resource assignments to the project. Information included in the document at this point sets the foundation for future work.

The project structure document contains guidelines that can be used to manage and provide support for the project. This allows the team to understand how the project will be handled, and aids them when experiencing problems with the project. Through these guidelines, the project has a better chance of success, because management and support issues are handled early in the process.

Also included in the project structure document is an outline of the administrative structure of the team. This structure shows team leadership and whom the team reports to in the organization. This keeps team members from having to wonder and stumble around seeking approval on elements of the project, by allowing them to know the exact administrative structure of the project.

Additional information may also be included in the project structure document, which can assist team members throughout the project. This may include such things as e-mail addresses, telephone numbers, server and directory information, and any other information that may be helpful to the project team. This allows the team to quickly find other members of the team, and which members are in certain roles of the team model. Through this information, the team can function much more effectively.

On the Job: It’s not uncommon for much of the information in the project structure document to be posted to a Web page on the corporate intranet. A page with hyperlinks to e-mail addresses, locations of team members, and other information can prove beneficial to the team.

From the Classroom

 Software Development Process model

The process model is one of the most clearly defined models included in Microsoft's Solutions Development Discipline course. It is used in both the Software Development and Enterprise Architecture Development processes. Since both activities use the Process model, complete with their own set of interim milestones and deliverables, it is very important to keep these independent sets of items distinct. Confusing them, for purposes of the exam, can result in extreme difficulties in sorting out the details of responsibility.

One of the more difficult aspects concerning the process model involves keeping track of the tasks performed by each role during each individual phase—specifically, those task performed by the Product and Program Management teams.

Be sure to memorize the interim milestones, deliverables, and the relationship between the two. For each interim milestone, certain deliverables are considered necessary for completion of the interim milestone.

—Michael Lane Thomas, MCSE+I, MCSD, MCT, MCP+SB, MSS, A+

Exercise 4-1:

Identify the deliverable from the description.

1.     This component of a deliverable outlines the needs and objectives of the organization.

2.     The issues raised in the problem statement are contained in this portion of the deliverable. This part also outlines the long-term vision of the project.

3.     This portion of the same deliverable describes the end user of the application.

4.     The final part of this deliverable provides the groundwork for creating specifications for the solution and defines the services that will comprise the application.

5.     This deliverable defines the possibility of incurring loss by the organization as a result of the final application or the development process.

6.     The final deliverable outlines how the project will be managed and supported.

The Project Plan Approved Milestone

The planning phase of the process model culminates in the project plan approved milestone. It is during this phase of the process model that the team and the customer agree on what will result from the project, and how to proceed with development. Priorities and expectations for the project are set, and an agreement is made on what be delivered, and how the product will be built.

This is similar to the envisioning phase. The planning phase takes the work done in the previous phase, and expands on it. During the planning phase, risks involved in the project are reassessed, estimates for schedules and resources are made, and the expectations and requirements are applied to create a functional specification and project plan. As we’ll see, the functional specification, project plan, and schedules are passed forward to the third phase of the process model, which is the development phase.

Defining the Project Plan Approved Milestone

The project plan approved milestone occurs when the work done in the planning phase has been completed and approved by the customer. During this phase, resources are assigned to the project, and work from the previous phase is built upon. This work results in four deliverables:

·       Functional Specification, which describes the purpose of the product, and acts as a blueprint for the solution

·       Risk Assessment, which is a reassessment of the risk assessment document produced in the previous phase

·       Project Schedule, which are created by each of the six team roles making up the team model

·       Project Plan, which is created by each of the six team roles making up the team model, showing how each team will approach their part in the project

The information that is provided in these documents provides a structure for the remainder of the project. When a consensus is reached, and the team members and customer(s) agree on the contents of these documents, the project plan approved milestone is reached. Once this happens, the team can move onto the developing phase of the project.

Team Focus

As we saw in the previous phase of the process model, each of the roles making up the team model focuses on different tasks to reach the milestone. In the planning phase, Program Management has ownership of the project plan approved milestone. This means that Program Management is accountable for reaching this milestone. Program Management has the responsibility of planning, management, and seeing that the tasks associated with this milestone are successfully executed. If any of the roles in the team model fail to complete their respective tasks, then the team’s ability to reach the project plan approved milestone is compromised.

In addition to having accountability and ownership of this milestone, Program Management also has additional duties on which to focus. Program Management creates the Program Management plan and schedule. This shows the estimated times and tasks that Program Management will require on the project. It is a plan and schedule that the Program Management team can commit to, so that no changes need be made to this in later phases of the project.

The Product Management ensures that the expectations of the user are included in the design of the product. Members in this team role collect and analyze information that is germane to user expectations and is responsible for ensuring that these are met in the product design. This role is also responsible for creating the Product Management plan and determines a schedule for this plan.

Development also creates a project plan and schedule. This role focuses on creating their plan and schedule to revolve around development issues. Development identifies and evaluates options, and creates the physical design for the product.

User Education is responsible for determining the training needs of users. In deciding on what the users’ needs are in this regard, a User Education plan and schedule are created. This not only includes plans on how to train and provide educational support for users, but also includes a means of measuring user performance. This allows the project team to see that the user’s productivity and experience with the product is enhanced.

The Testing team is responsible for looking at the design created by Development, and evaluating it. This allows Testing to determine what should be tested after the product goes through development, and the Testing team is ready to begin checking the product for problems. This assessment of the design is applied to the Testing plan and schedule.

Finally, Logistics looks at what resources will be required to complete the project, and determines how they will be obtained. These materials are what will be used in creating the product, and without the necessary resources, the project will fail. This information is applied to the plan and schedule, which Logistics will create.

Interim Milestones

The planning phase of the process model incorporates three interim milestones to facilitate the process of achieving the project plan approved milestone: the functional specification draft, development schedule draft, and ship date determination. These interim milestones involve developing two drafts, and setting a date for shipping the final released version of the product.

The functional specification draft is used to help produce the deliverable known as the functional specification. Since a detailed description and definition of the product must begin somewhere, it rests on the creation of the functional specification draft to start to come to life. This interim milestone maps to the functional specification deliverable, to some degree. It is considered met upon its ability to provide the Development, User Education, Testing, and Logistics Management roles with enough information to begin mapping out their contributions to the development project.

The development schedule draft interim milestone is a rough draft of the overall development schedule to which Product Management, Program Management, Testing, User Education, and Logistics will attempt to synchronize their schedules. In essence, this interim milestone is used to set the tone or pace for the development team. Since the Development role is most closely linked to the critical path of development, it is beneficial to have this role responsible for helping to set the overall pace.

The ship date determination interim milestone is the result of negotiating the functional specification draft and development schedule draft. The determination of a ship date helps to provide a goal to which the entire can strive to meet.

The Importance of a Functional Specification

Functional specifications have a special importance to any project, and it’s important to create one before starting development on a project. To do so during or after development would be like an architect creating a blueprint as contractors are putting up the building, or a baker referring to a recipe once the ingredients have already been added. Because the functional specification describes the application, its purpose, and serves as a blueprint for what will be developed, it’s vital that one is created before development begins. This will allow the team members to refer to the document, and see what exactly needs to be done to create a successful application.

The functional specification is based on the needs and requirements of the business, customer, and/or end user. It provides a clear outline of what needs to be included, and what shouldn’t be added to the finished product. Without a functional specification, the vision and scope of the project, which were set in the previous phase, may become lost. It is a representation of the needs and requirements to be included in the application, by showing the components that address each business requirement and need.

As a blueprint for the finished product, when customers and team members agree to its contents, the functional specification acts as a contract between the customer and the project team. It shows what has been agreed to be included in the product, what shouldn’t be added or should be removed, and what features may be passed forward to future versions. If a dispute occurs during development, the customer and team can refer to this document to show exactly what the consensus was on certain components, features, or functionality. If the functional specification suits the needs and requirements of the user, the team is given the go-ahead to start development.

The Interdependent Roles/Shared Responsibilities of Project Team Members

As we saw earlier in this chapter, the team model is based on the premise of a group of peers working together toward a common goal. That goal is the success of the project. Though each role has its own tasks, there are shared responsibilities and an interdependency that requires real teamwork.

Tasks Leading to Project Plan Approval

Within the team, there are specific tasks that cause various roles in the team model to be interdependent on one another. The Program Management team must sign off that the functional specification/design specification will meet the desired requirements.  The Program Management team agrees that there is sufficient accountability for each function and that the schedules are realistic. The Development team is charged with investigating possible risks and ensuring that these risks are manageable as well as being willing to commit to the schedules put forth in the planning phase.

Outside of the team, members must work with the customer and end users of the product. The customer must sign off on the project before any development can begin. Customers must be at a point where they recognize the business benefits to be gained by the solution and the time frame in which the solution is to be delivered. If a customer can’t agree on either the schedule or see the product as being beneficial, the project plan approved milestone can’t be achieved. In such a case, the team will need to go back over the tasks they’ve performed, and try to reach a consensus with the customer on elements of the project and the time allotted to finish the product.

Each of the different team roles is responsible for creating their own plans and schedules. The plans outline what tasks each team will need to perform in the project, and how they will be handled. The schedules reflect a timeline for completing these tasks that the team feels they can commit to. As we’ll see in the next phase of the process model, these plans and schedules are respectively added to the master project plan and master project schedule. When added into master plans and schedules, it shows the total amount of effort and time needed to complete the project.

Defining the Deliverables for the Planning Phase

During the planning phase, four deliverables are produced: the functional specification, project schedule, project plan, and the risk assessment. Together they define what the project is, how it will be undertaken, the risks involved in the project, and the time it will take to complete tasks associated with the project.

Deliverables

The risk assessment of the planning phase is a reassessed version of the risk assessment document that’s generated during the envisioning phase. This document contains estimates and assessments of risks that could adversely effect the project if not addressed. By identifying the likelihood of risks, the team is better able to handle problems before they occur in a project.

A project schedule is generated by each of the six roles of the team model. Team leaders work with members of their team to create a schedule that team members can commit to, and reflect a realistic view of how much time is required to successfully complete their respective tasks.

A project plan is also created by each of the six roles of the team model. As with project schedules, team leaders work with their teams to document how they will approach their part in the project. It shows how that particular team will tackle the project from this point forward. Team leaders look at the individual components contained in the functional specification, and map these functional components to tasks that team members perform. By putting these into a project plan, a strategy is produced on how the project will take shape.

The functional specification acts as a contract between the customer and the project team. It describes the application, its purpose, and acts as a blueprint for the solution. It also defines the visual design, functional interfaces, and data requirements. In short, it is a document that specifies the functionality of the solution. In doing so, it also acts as a contract between the customer and project team. By coming to a consensus, and agreeing to the contents of the functional specification, the team is able to then move forward into the development phase of the process model.

Developing a Functional Specification

Once the vision and scope of the project have been set in the envisioning phase, the work performed at this phase can be passed forward and applied to the functional specification. Information in this document is derived from the objectives and requirements of the business, user profiles, and usage scenarios. User profiles identify the user of the solution, while usage scenarios describe how user tasks are executed. This information is applied to the functional specification, and shows what is needed in the application.

Because Program Management has ownership of the project plan approved milestone, this role is subsequently responsible for the functional specification. This doesn’t mean that Program Management is alone in generating this document. Each role of the team model has an active role in assisting Program Management. Team members contribute to the functional specification by adding components to the document that reflect their expertise. This includes reviewing contents and assessing risks of the parts they contribute.

Team members need to show that what’s included in the functional specification can actually be built and delivered to the customer. If a customer requires a specific feature, and the team isn’t sure that it can be provided, then the team must come to a concrete decision whether the feature should be dropped or passed forward to a future version. To show they can deliver what the customer requires, the team may develop prototypes. Prototypes are mockups of such things as visual interfaces, and provide the customer with something tangible to view. Developing a prototype allows the customer to see what they’re getting, and can let the team determine whether certain items in the functional specification can actually be provided.

In developing the functional specification, the requirements of the business are broken up into different services. These services consist of user services, business services, and data services. You’ll notice that these are the three tiers of the application model, which we discussed in Chapter 2. This aids the team in defining the visual design, functional interfaces, and data requirements of the solution. By separating the requirements into each of these three tiers, a distinct view of what the application will be, and how it will be created is established. Team members can then use this information when building the application in the development phase of the process model.

The functional specification should include interoperability issues that may affect the project. External interfaces, communication, components, and other issues that determine how the solution will interact with other applications and users should be included.

Developing a Project Plan

A project plan is a document containing the tasks, dependencies, assumptions, and approaches to handling specific aspects of the project. Each role of the team model creates a project plan that shows how they intend to perform various tasks that are mapped from the functional specification. Because the functional specification shows each of the functional components that make up the project, these components can easily be applied to tasks that are necessary to complete the project.

A project plan is basically a plan of attack, showing strategies on how individual teams will undertake their particular responsibilities to the project. For example, User Education would create a plan that shows performance objectives, how user performance requirements can be fulfilled, and information that will reflect training plans that can be implemented later in the process model. The project plan would also show budget and cost information, required resources, and other data necessary to successfully complete the project.

A project plan starts with a purpose statement. This is a brief report on what that particular team assumes should be achieved by their work. It shows that the team understands what goals need to be met. The plan then documents the strategy that will be used to meet this purpose.

Developing a Project Schedule

Schedules are an important part of any project. They show the amount of time required by team members to execute specific tasks, necessary in creating the product. For example, Development would create a schedule to show how long it would take to code different components making up an application. When each of these estimates are added together, the schedule would show the total time necessary to code the total solution. Schedules give team members reasonable deadlines to complete their work, and show the entire project team how long each team role requires to fulfill their tasks.

The tasks that require scheduling are taken from the functional specification. The team leaders map individual functional components, outlined in the functional specification, to tasks. The team leaders then assign these tasks to members of their team. Team leaders have the responsibility of creating schedules for this work that the team members can meet.

Bottom up, task-level estimating should be used in creating project schedules. This means that the person who does the work determines how long that work will take. This provides a more realistic estimate of how long it will take to perform a task. These estimates are given back to the team leader, who applies them to the schedule.

There are two common problems that often occur in creating project schedules. Both of these deal with the people performing tasks associated with a project misdiagnosing the amount of time it takes to complete a task. Overly optimistic scheduling occurs when too little time is assigned to a job. Sometimes this isn’t the fault of team members. There may be a deadline—such as the date of a trade show, or a seasonal requirement to the project (such as income tax time)—where a project must be completed or the benefits of the project are diminished. More commonly though, overly optimistic scheduling results from unreasonable expectations. They assume a task is less complicated than it really is, or have a greater faith in their abilities than is really there. On the flip side of this, some people may add time to their estimates, or estimate the task as taking longer than it really should. This can occur from team members having a lack of faith in their abilities, confusion over what the task involves, or any number of other reasons. In creating estimates, it’s important that those estimates are an accurate reflection of the time it will take to complete a task.

Exercise 4-2

Identify the deliverable from the description.

1.     This deliverable is a revision of one of the envisioning phase deliverables. It contains estimates and assessments of issues that could adversely affect the project.

2.     This deliverable is a group effort from each of the six roles of the team model. It reflects a realistic estimate of task effort.

3.     This deliverable documents how each team will complete their tasks in the project.

4.     This deliverable describes the application and acts as a blueprint for the solution.

The Scope Complete/First Use Milestone

The developing phase is the third phase of the process model, and culminates in the scope complete/first use milestone. For those who love to code this is the phase of the project that’s highly anticipated. During this phase, the project moves away from design and the focus changes to developing the actual product.

The developing phase is initiated when the customer has approved the design of the product, and ends with the creation of a software solution that’s ready for testing and stabilization. When this end result is achieved, the scope complete/first use milestone is reached. Work done in achieving this milestone revolves around building the product, and identifying any additional issues that need to be resolved before the product ships.

The functional specification, and other deliverables from previous phases—inclusive to the project plan—are used in this phase as a baseline, and provide focus in developing the actual product. As we’ll see, these aren’t the only deliverables that aid team members in creating the product. The project plans and project schedules of different roles in the team model are combined into master documents, which are used to show team members the tasks to perform in the developing phase, and allow the team to measure the work they do against what is actually required.

Defining the Scope Complete/First Use Milestone

The developing phase signals that the design of the application is at the point where it can be developed and optimized. Each of the six team roles making up the team model work to ensure the solution is developed to the best of their ability, resulting in a high-quality product. During this phase, coding begins on the solution, support and training facilities are identified, and an actual software product takes a tangible form. The development team builds the product, going through a number of cycles involving testing, debugging, and fixing the product. This occurs until it is ready to be passed forward to the stabilizing phase of the process model. The scope complete/first use milestone is achieved when a consensus is reached that the solution, and its support and training mechanisms, are ready for testing and stabilization.

Team Focus

During the developing phase, the team roles of Development and User Education have ownership. It is their responsibility that this phase of the project is properly planned, managed, and that the tasks associated with developing are correctly carried out. If they fail in doing this, the scope complete/first use milestone won’t be reached.

During the developing phase, members in each of the team model roles follow the individual plans that make up the master project plan. Later in this chapter, we’ll discuss the master project plan and master schedule in greater depth. The main focus on this phase is developing the product, so that an efficient and high-quality solution is produced. Each of the team members work toward this, and communicate regularly with one another in achieving this goal.

Development also has responsibility for building the solution. They are required to code the solution, so that each of the components outlined in the functional specification are included and function properly. During the building of the product, the development team goes through a series of cycles, involving testing, debugging, and fixing the product. This in no way means that further testing isn’t necessary. It ensures that basic functionality of the product performs as expected, inclusive to the solution starting and exiting properly. Basically, if the solution doesn’t even work, then Testing will be unable to check specific features and functions in the program.

User Education also has the responsibility for identifying support and training facilities. By having support and training mechanisms established early in development, users will have a better opportunity to understand how to use the product.

Testing sets up usability testing procedures, which will be used in determining whether the application meets the user’s need and expectations. In a later section of this chapter, we’ll discuss the importance of this.

A major task addressed by all roles of the team model, as well as customers, users, and other stakeholders, are issues that need to be addressed before the product is ready for shipping and deployment. These issues need to be addressed here because after this phase, it is generally too late to do anything.

Interim Milestones

The developing phase of the process model is provided with five interim milestones presented in a loose chronological order. The interim milestones are not required to be obtained or reached in the order provided, but rather the order is allowed to vary from project to project. The order provided is merely considered optimal for reducing the impact of changes that may occur within the developing phase. These interim milestones are visual design freeze, database freeze, internal releases, functional specification freeze, and feature complete.

The visual design freeze interim milestone is the first interim milestone to be reached in the developing phase. This milestone allows screenshots of the visual design to be acquired by Product Management and User Education to assist in documentation and packaging concerns. This interim milestone may be ascribed to the entire project, or just on internal releases as defined by the internal release interim milestone.

The database freeze interim milestone is reached once the database schema is solidified and decided upon. By freezing the database schema, the component interfaces may begin to be defined. This also allows the different Development teams for the separate application layers to begin parallel development tracks without fear of database changes forcing recoding of components.

The internal release interim milestone is usually reached several times, as several internal releases clustering different product features are tested and debugged. Depending on project size, many different internal release milestones may actually be reached prior to reaching the ultimate scope complete/first use milestone. This interim milestone generally involves a release of code by the Development role once a level of reasonable stability has been obtained. This code has already undergone testing and verification of the daily builds from which the internal release is obtained. Part of this interim milestone is the production of a testing release document (TRD) to document the interim milestone and provide documentation for identifying untestable areas, known bugs, and general information about the internal release. In order to reach this interim milestone, the physical internal release must pass testing performed by the Testing role to ensure acceptable stability of the feature set.

The functional specification freeze interim milestone is used to develop a final, formal functional specification for the product in order to fully define the product. Last minute tradeoffs in the product are solidified and the features are fully set into a completed specification. Although this is considered the final specification, keep in mind that minor changes are allowed after the product ships to account for last-minute visual changes.

The feature complete interim milestone represents the first internal release of the product that is fully functional. This is the first release against which full test scripts may be run. The final testing separates this interim milestone from the scope complete/first use milestone and involves heavy systems testing to allow the product to move from alpha to beta status.

Tasks Leading to Scope Complete/First Use

The tasks performed by the project team revolve around creating a high-quality solution, which meets the needs and requirements of the customer. A great deal of work is performed during this phase of the project, inclusive to building the actual product. Each of the tasks performed work toward creating a product that is ready for testing and stabilization. Once the customer and project team agree that this has happened, the scope complete/first use milestone is reached, and the next phase of the process model is ready to begin.

During this phase, Development and User Education own responsibility for achieving the scope complete/first use milestone. This is due to the fact that the developing phase revolves around building the product, and setting support and training for the product. These two roles of the team model plan, manage, and ensure that the tasks involved in this phase are properly executed by the other teams roles.

During the developing phase, risk assessments are applied to create a risk management plan. The risk management plan outlines strategies that can be used to deal with problems before they occur. This is a proactive method of dealing with risks. If the risk has already produced a problem that will result in some sort of loss, the risk management plan should provide some method of how the team should react to the risk. You’ll remember that these issues are discussed in greater detail in the previous chapter.

Development creates the source code and executables that make up the solution. This is where the design is applied to the building of an actual solution. As mentioned, this also includes a cycle of testing, debugging, and fixing the product. By writing and compiling the application, and then going through these cycles, many of the problems that can occur in the application are caught before testing and stabilization begins.

Performance support elements are set during this phase of the process model. User Education creates a strategy by establishing how the solution will need to satisfy user performance requirements.  This is used to determine areas where the application meets or fails such requirements.

Testing is responsible for creating test specifications and test cases, which can be used in the next phase of the process model. These give team members in this role something to follow in testing the application. Through these documents, Testing will be able to find potential problems by taking the solution through a series of tests that match how the user will use the product.

Defining the Deliverables for Scope Complete/First Use

There are more deliverables produced during the developing phase than in previous phases of the process model. Many of these are built upon deliverables created in previous phases, but all provide the team with knowledge in creating a high-quality solution. One of the most distinctive deliverables at this phase is the solution itself. Source code, executables, and COM components are written and compiled, making up the application as a whole. As we’ll see though, this isn’t the only important deliverable generated in this phase.

Deliverables

The developing phase of the process model produces a number of different deliverables:

·       Frozen functional specification

·       Source code and executables

·       Performance support elements

·       Test specification and test cases

·       Master project plan

·       Master project schedule

·       Risk management plan

Each of these deliverables is used by the team to create a high-quality solution meets the needs and requirements of the business.

Because development starts at this phase of the process model, the functional specification is frozen at this point. The only changes applied to the design of the application are fixes. The frozen functional specification contains all of the features from the previous phase, but doesn’t allow additional features or functionality to be added.

Source code is written, and executables and components of the application are compiled during this phase of the process model. This results from using a programming language (such as Visual Basic or C++) to write the programming code, and then compiling it into an actual program that can start, perform its functionality, and then exit. Considerable time and work is put into this by Development, who creates the physical solution that users will work with.

Performance support elements are identified and set. These elements dictate what user performance requirements are necessary, and are used to develop a strategy that can be used to analyze whether the application meets those requirements. By improving performance in areas that the user requires, the user’s experience with the application will be enhanced.

Test specifications and test cases are created to show how testing will be performed in the next phase of the process model. Test specifications show guidelines, rules, and approaches that will be taken to ensure that the product meets the standards, quality, and performance that are required from the application. Such specifications let the Testing team know what needs and requirements have to be met in the solution. Test cases provide scenarios that Testing can follow in order to find errors or malfunctions in the application. This allows Testing to test the product in ways that the user will use the product.

The master project schedule is the combined schedules of each of the six roles of the team model. Team leaders provide schedules for each of their teams. These are schedules that team members can commit to, and reflect a realistic view of how much time is required to successfully complete their respective tasks. These are combined into a master project schedule, which shows the total scheduling of the entire project team.

The master project plan is similar to the master project schedule, in that each of the six roles provide individual components to create a master document. With the master project plan, team leaders submit plans of their teams. These include implementation, user education, logistics, testing, solution marketing, and budget plans. Together, they show how the team will tackle the project from this point forward.

Risk assessments from previous phases of the process model are used at this phase to create a risk management plan. Risk management plans define how the team should manage risks. As we saw in the previous chapter, risk management can be proactive or reactive. Strategies contained within the plan show how the team can keep risks from resulting in loss, and how to deal with risks once they’ve become a problem.

Exercise 4-3

Identify the deliverable from the description.

1.     This deliverable contains all of the features from the previous phase but allows fixes only to the design, no additional functionality.

2.     The major part of this deliverable is the code that executes the functionality of the application.

3.     This deliverable contains the support elements and performance requirements.

4.     This deliverable includes the guidelines, rules, and approaches taken to ensure that the end product meets the stands, quality, and performance.

5.     The combined schedules for the six project teams comprise this deliverable.

6.     For this deliverable, team leaders submit analyses of their components that show how the team will continue the project.

7.     This deliverable results from the risk analysis of the previous two phases.

The Release Milestone

Once the scope complete/first use milestone is achieved, team members are ready to move into the stabilization phase of the project. The stabilization phase is where product testing is performed, allowing bugs to be found and fixed before it is shipped or put into service. The goal of this phase is to make the solution a stable product that is ready for end users.

Once testing is completed during this phase, responsibility of the product is handed over to operations and support. When a consensus is made that the product is stable and testing is complete, the release milestone is achieved. Operations and support staff will manage and support this current release of the software, and the project team can begin on the next version of the product or move on to a new project.

Defining the Release Milestone

The release milestone is a mechanism for ensuring the quality of the product. It is during this phase of the process model that testing and stabilization of the product take place. Once it’s determined that testing is complete, and the software product is stable enough to be used, the release milestone is achieved. This means that the product can be shipped or put into service, and users can now benefit from its capabilities.

In determining whether the product is ready for release, the customer and project team must come to a consensus. They must agree that the application has fulfilled expectations, and is ready for use. This can be determined when the following factors are met:

·       The solution meets the requirements of the business, and all the users who were identified in the scope of the project.

·       The new problems encountered have steadily declined or are to the point that it is at or near zero each day.

·       A consensus is reached that the solution is supportable, possesses no quirks, and a support system for the solution has been implemented.

·       The customer is satisfied that the product provides the solution as outlined in the scope.

The application is ready for release when the above four steps have been accomplished. The quality of the product is the responsibility of each functional team, as well as the organization. By accomplishing these steps, the project team and organization can establish that this quality is met.

Team Focus

During the stabilizing phase of the product, Testing and Logistics have ownership. It is their responsibility to plan, manage, and see that the necessary tasks involved in achieving the release milestone are completed successfully. This results in the team releasing a high-quality, usable product.

As the primary goal of the stabilizing phase is to create a stable product, it is here that Testing goes through the application to find errors and malfunctions in the product. If the application crashes due to certain actions, fails to perform certain functions, or has features that aren’t included or don’t work, the product must go back to Development to be fixed. In testing the application, the Testing team uses the specifications and test cases that were created in the previous phase.

Logistics ensures that the operations, help desk, and other support staff are in place, and properly prepared for the release of the product. It is the responsibility of this role to ensure a smooth rollout of the product, and make certain that deployment of the solution is possible. Installation programs must work correctly, and installation sites are checked so they fit the necessary requirements for deployment.

Interim Milestones

The stabilizing phase of the process model is provided with six very closely-related interim milestones: content complete, bug convergence, code freeze, zero-bug release, release candidate, and golden release. Most of these interim milestones are grouped towards the end of the stabilizing phase, and can be reached almost simultaneously on some projects. In order to reach these milestones, numerous beta releases may be required, effectively masking the true degree of effort required to obtain these milestones, from the standpoint of the process model alone. In most cases, a great deal of effort precedes these interim milestones.

The content complete interim milestone involves the final editing and production of the support elements for the product by User Education. At this point, the content to be provided by User Education is finalized and full testing is performed for this material.

The bug convergence interim milestone is somewhat tricky to determine. This milestone occurs when the rate of bug resolution exceeds, for the last time, the rate of bug identification. In simpler terms, this interim milestone is considered to have been reached when the number of new bug fixes is greater than the number of new bugs. Although this may occur several times, the last such occurrence is considered the mark for the milestone.

The code freeze interim milestone and the zero-bug release interim milestone go hand-in-hand in the development process. They are almost always reached simultaneously. The code freeze milestone occurs when the last known active bug has been resolved. Once Development has caught up with Testing in this manner, for the first time, then the code freeze milestone is reached. Immediately following this milestone, the product release built from this code is sent to Testing as a zero-bug release, and the zero-bug release milestone has been reached.

The release candidate interim milestone is reached when a product version is returned from Testing, and the following conditions are true:

·       No Severity 1,2, or 3 bugs are found

·       No Priority 1,2, or 3 bugs are found

·       All files to be shipped with the final product are included with the release

·       No Severity 1 bugs are found for a preset length of time

The generally accepted definitions for severity levels are as follows:

·       Severity 1 – causes system crashes

·       Severity 2 – defined as a major problem

·       Severity 3 – define as a minor problem

·       Severity 4 – defined as a trivial problem

The generally accepted characteristics of Priority levels are as follows:

·       Priority 1 – Highest Priority bugs are completely reproducible, following a simple series of steps, and have been given a severity of 1,2, or 3. These bugs must be fixed.

·       Priority 2 – High Priority bugs are very reproducible through somewhat complex or convoluted steps. These bugs should be fixed.

·       Priority 3 – Medium Priority bugs are only reproducible intermittently, and only through a convoluted series of steps. The fix is not intuitive or obvious. These bugs are fixed last and a product may ship with them.

·       Priority 4 – Low Priority bugs are very difficult to reproduce. Fixes are not obvious. Only fix these bugs given a low-risk solution acquired without effort to ascertain.

The golden release interim milestone results in the final product release. This milestone coincides directly with the golden release deliverable. Upon full testing of the golden release, including archival of the release, this interim milestone will have been reached.

Effective Usability Testing

Usability testing is an important component in preparing for the employment of the solution. It gives you an idea of how well the solution meets the users’ needs and expectations. Effective usability testing is accomplished by first defining the target audience to determine the test goals. When determining the goals you should focus on tasks.

One method of usability testing is to provide an environment that’s comparable to the target setting. Then, you need to allow the users a reasonable amount of time to try and work through any difficult situations that may arise with as little intervention as possible. Finally, you should record the results, preferably with a video camera, so the results can be reviewed later and more in-depth. 

As we’ll see in the sections that follow, there are other methods of determining the usability of a solution. The importance of establishing the usability of a solution is high indeed. If an application is unusable, the product will fail because no one will want to use it.

Beta Testing

Beta releases are test or trial copies of a product that are released to a limited number of users. These users are called beta testers, and they try out the product before the final version is released to the public. These beta testers use the product, and report bugs and problems with the solution to the team. Beta testing allows the project team to see how the solution works while being used by the target audience.

On the Job: Beta releases of a product aren’t uncommon, and are usually provided to users free of charge. There are exceptions to this, as was the case with the beta release of Windows 98. There are various reasons why users are willing to try out these beta releases before the finished product is ready. Some want to view the new version before it’s on the market. Many teams will provide some sort of incentive for people to beta test the product, inclusive to a free copy of the finished product, or a discount.

Release Candidates

On occasion beta releases will go through a number of different versions before the official, final version of the product is released. These are called release candidates. Each candidate contains fixes to bugs or problems reported by users.

Release candidates may also contain such things as different features, visual interface, and tools included in the product. This allows users to communicate what they like and dislike in the product, before the final version is released. For example, some users who are beta testing a product may find one version of the visual interface easier to use than another. While this isn’t usually tested with release candidates, and more often determined with prototypes, it can be tested with release candidates of some products.

Defining the Deliverables for Release

The release milestone is the final milestone of the process model. The deliverables in this stage are the last ones of the project. After they have been produced and a consensus is reached to release the product, the project team is ready to move onto other projects or new versions of the current product.

Deliverables

The stabilizing phase of a software development project results in the following seven deliverables:

·       Golden release

·       Source code and executables

·       Release notes

·       Project documents

·       Performance support elements

·       Test results and testing tools

·       Milestone review

These deliverables are the result of work performed in the current and preceding phases of the project. As we’ll see, many of these deliverables can be applied to future projects, or future versions of the current product.

The golden release is the finished product. It’s also called a golden master, as this is the master copy of the solution. This is released to manufacturing, and is the copy from which all copies of the finished application will be made.

Source code, as well as executables and components that make up the application are another deliverable of this phase. You’ll remember that this was one of the deliverables from the developing phase. The difference between the raw and compiled code of these two phases is that this deliverable has gone through testing, and is considered stable. The source code from the stabilizing phase can be used for future versions of the product, and should be kept for this reason.

Release notes are documentation that describes updated features, and may contain information on the history of the solution. When such a history is included in the release notes, it describes what bugs or problems have been fixed in each version, or what features were added and removed from the product. Release notes allow users to view what has been done to the product in current and previous versions.

Product documents provide users and team members with information on the current version of the product. These documents describe features and functionality in the current version, and guidelines on how to use them. Such documents provide a clear view of the product’s capabilities.

Performance support elements are updated during the stabilization phase of the process model. It is revised from the performance support elements established in the developing phase.

Test results and testing tools are another deliverable produced during this phase. Testing tools are the utilities and tools used in automated and manual testing of the product. These include performance tools, as well as those that test features and functionality in the product. Test results are the documented results of the work performed by the Testing team during this phase. They show how the application merited during testing, and can be used when creating future versions of the product.

A milestone review is done to analyze how the project went in meeting each of the milestones in the process model. Were there any problems that could have been avoided? How well did the team measure up in meeting these milestones? These are a few of the questions that are asked in a review of the milestones. By doing a milestone review, you can determine what issues, problems, and successes occurred. This allows the team to apply this knowledge to future projects.

Following are some possible scenario questions, and their answers.

What are the phases and associated milestones of the process model?

The process model consists of four phases, with a milestone associated with each: envisioning phase (vision/scope approved milestone), planning phase (project plan approved milestone), developing phase (scope complete/first use milestone), and stabilizing phase (release milestone).

Who has ownership of the different milestones?

Product Management has ownership of the vision/scope approved milestone, Program Management owns the project plan approved milestone, Development and User Education own the scope complete/first use milestone, and Testing and Logistics own the release milestone.

Why is bottom up, task-level estimates beneficial for scheduling?

Bottom up, task-level scheduling has the person performing a task providing an estimate on how long the task will take to complete. Because the person doing the work has the best idea of how long it will take them to complete it, the estimates are more accurate.

Why should milestones be reviewed at the end of a project?

To determine issues that resulted from the current project. By knowing what problems occurred, and what was successful in the current project, you can apply that knowledge to future projects.

Exercise 4-4

Identify the deliverable from the description.

1.     This deliverable is the finished product.

2.     This deliverable provides the foundation for future enhancements and releases.

3.     Any notes for the feature or history of the solution is contained in this deliverable.

4.     This deliverable provides the users with instructions on how to use the features of the current release.

5.     This deliverable is a revision of a deliverable in the previous phase and updates response times as well as other issues.

6.     This deliverable is comprised of any automated or manual procedures used to verify functionality.

7.     This deliverable documents the issues, problems, and successes that occurred during the project.

Exercise 4-5

Identify the milestone associated with each attribute.

1.     Agreement on product characteristics.

2.     Bugs and problems encountered are near zero.

3.     Identify the support and training requirements.

4.      Estimate schedule and resource requirements.

5.     Identify the timeframe for the application to be functional.

6.     Determine the level of work needed in the planning phase.

7.     Agreement on how to proceed with the development.

8.     Set priorities and expectations.

9.     Understand how the solution will solve the business requirements.

10.  Re-assess risks.

11.  The application has to be deployed to the appropriate users.

12.  Agreement on vision and scope of the project.

13.  Agreement on priority of business requirements.

14.  Create functional specifications.

15.  Identification of business constraints, risks, and assumptions.

16.  Build, test, debug, and fix the product.

17.  The customer concludes that the product is what they wanted.

18.  The support system for the application is in place.

19.  Write code that satisfies the solution.

Certification Summary

The process model provides the roadmap needed for ensuring that product development does not fall off track. The process model for software development is comprised of major milestones, interim milestones, deliverables, and phases.

The process model is broken up into four major phases: envisioning, planning, developing, and stabilizing. Each of these phases has its own collection of interim milestones and deliverables. Each phase culminates in a final milestone that signifies the end of that phase.

The envisioning phase culminates with the vision/scope approved milestone. Leading up to this, the envisioning phase includes vision statement draft and design goals draft interim milestones. The envisioning phase physically results in an internal deliverable known as the risk management plan, and external deliverables known as a vision/scope document and a project structure.

The planning phase concludes with the project plan approved milestone. Prior to this milestone, this phase involves three interim milestones: functional specification draft, development schedule draft, and ship date determination. During this phase, the physical deliverables include an internal risk management plan, and external deliverables are a functional specification, master project plan, and a master project schedule.

The developing phase finishes up with a scope complete/first use milestone. During this phase, the interim milestones are visual design freeze, database freeze, internal releases, functional specification freeze, and feature complete. These interim milestones contribute to the production of six deliverables: functional specification, risk management plan, source code executables, performance support elements, test specification plus test cases, and master project plan / schedule updates.

The final phase, stabilizing, results in the release milestone, with six interim milestones: content complete, bug convergence, code freeze, zero-bug release, release candidate, and golden release. These result in seven deliverables. The external deliverables include performance support elements, release notes, and the long-anticipated golden release. The internal deliverables include testing document and tools, source code and executables, project documents, and the final milestone review.

Two-Minute Drill
The process model breaks a project up into four phases, with each phase culminating in a milestone. Milestones mark the point where one phase of the project ends and another begins, and indicate a point in the project where team members should synchronize their efforts.
The four phases of the process model always follow the same order, starting with the envisioning phase, proceeding through the planning phase and the developing phase, and ending with the release milestone of the stabilizing phase.
The design of any application is driven by the needs of the user, and this is what the envisioning stage works to understand.
The vision/scope approved milestone occurs when the project team, customer, and stakeholders come to an agreement on key aspects of the project. This includes such elements as the vision and scope of the project, and the priority of which business requirements need to be addressed first.
A deliverable is a product of work that’s generated from the activities of a given phase in the process model. Unlike interim milestones, which are points of time allotted for the team to synchronize their efforts, a deliverable is a physical component that results from the work that’s been done.
It’s important to remember that the vision/scope approved milestone occurs when the vision and scope of the project have been agreed upon.
The vision/scope document is made up of several parts, which together map out what the project entails. These components of the document consist of the problem statement/business objectives, the vision statement, user profiles, and the solution concept.
The project structure document is a vital information tool that is passed forward to the planning phase of the process model. Upon reaching the milestone of this next phase of the process model, the document is updated to reflect resource assignments to the project.
Be sure to memorize the interim milestones, deliverables, and the relationship between the two. For each interim milestone, certain deliverables are considered necessary for completion of the interim milestone.
The project plan approved milestone occurs when the work done in the planning phase has been completed and approved by the customer. During this phase, resources are assigned to the project, and work from the previous phase is built upon.
Functional specifications have a special importance to any project, and it’s important to create one before starting development on a project. To do so during or after development would be like an architect creating a blueprint as contractors are putting up the building, or a baker referring to a recipe once the ingredients have already been added.
The functional specification is based on the needs and requirements of the business, customer, and/or end user. It provides a clear outline of what needs to be included, and what shouldn’t be added to the finished product.
During the planning phase, four deliverables are produced: the functional specification, project schedule, project plan, and the risk assessment. Together they define what the project is, how it will be undertaken, the risks involved in the project, and the time it will take to complete tasks associated with the project.
In developing the functional specification, the requirements of the business are broken up into different services. These services consist of user services, business services, and data services.
A project plan is a document containing the tasks, dependencies, assumptions, and approaches to handling specific aspects of the project.
Schedules give team members reasonable deadlines to complete their work, and show the entire project team how long each team role requires to fulfill their tasks.
The developing phase is initiated when the customer has approved the design of the product, and ends with the creation of a software solution that’s ready for testing and stabilization. When this end result is achieved, the scope complete/first use milestone is reached.
The developing phase signals that the design of the application is at the point where it can be developed and optimized. Each of the six team roles making up the team model work to ensure the solution is developed to the best of their ability, resulting in a high-quality product.
There are more deliverables produced during the developing phase than in previous phases of the process model.
The stabilization phase is where product testing is performed, allowing bugs to be found and fixed before it is shipped or put into service. The goal of this phase is to make the solution a stable product that is ready for end users.
The release milestone is a mechanism for ensuring the quality of the product. It is during this phase of the process model that testing and stabilization of the product take place.
Effective usability testing is accomplished by first defining the target audience to determine the test goals.
The release milestone is the final milestone of the process model. The deliverables in this stage are the last ones of the project.
A milestone review is done to analyze how the project went in meeting each of the milestones in the process model.

Answers to Exercise 4-1

1.     Problem statement/business objectives

2.     The vision statement

3.     User profiles

4.     The solution concept

5.     The risk assessment

6.     The project structure document

Answers to Exercise 4-2

1.               The risk assessment

2.               The project schedule

3.               The project plan

4.               The functional specification

Answers to Exercise 4-3

1.     Frozen functional specification

2.     Source code and executables

3.     Performance support elements

4.     Test specification and test cases

5.     Master project plan

6.     Master project schedule

7.     Risk management plan

Answers to Exercise 4-4

1.     Golden release

2.     Source code and executables

3.     Release notes

4.     Project documents

5.     Performance support elements

6.     Test results and testing tools

7.     Milestone review

Answers to Exercise 4-5

1.     The project plan approved milestone

2.     The release milestone

3.     The scope complete/first use milestone

4.     The project plan approved milestone

5.     The vision/scope approved milestone

6.     The vision/scope approved milestone

7.     The project plan approved milestone

8.     The project plan approved milestone

9.     The vision/scope approved milestone

10.  The project plan approved milestone

11.  The release milestone

12.  The vision/scope approved milestone

13.  The vision/scope approved milestone

14.  The project plan approved milestone

15.  The vision/scope approved milestone

16.  The scope complete/first use milestone

17.  The release milestone

18.  The release milestone

19.  The scope complete/first use milestone