The Application of the Microsoft Solutions Framework (MSF) Process Model to WILM Web Application Development

Version 1.0 (March 2006)

Table of Contents List of Figures...........................................................................................................ii Preface....................................................................................................................iii Introduction ............................................................................................................. 1 Overview ................................................................................................................. 1 Phase 1: Envisioning............................................................................................... 3 Phase 2: Planning ................................................................................................... 4 Phase 3: Developing ............................................................................................... 6 Phase 4: Stabilizing................................................................................................. 6 Phase 5: Deployment .............................................................................................. 7 Glossary .................................................................................................................. 8 References.............................................................................................................. 9 APPENDIX A: History of Revisions ...................................................................... 10 APPENDIX B: Descriptions of MSF Deliverables ................................................. 12

List of Figures Figure 1: Waterfall Model ........................................................................................ 1 Figure 2: Spiral Model ............................................................................................. 2 Figure 3: MSF Process Model................................................................................. 2 Figure 4: MSF Process Model Phases and its Milestones ..................................... 2 Figure 5: MSF Phase 5 Deploying........................................................................ 6

ii

Preface This document will be revised as necessary.

iii

The Application of the Microsoft Solutions Framework (MSF) Process Model to WILM Web Application Development
Introduction The purpose of this paper is to provide a basic, non-technical understanding of the Microsoft Solutions Framework (MSF) Process Model, and how it will be applied to Web Application Development for WILM. Overview The first version of MSF was introduced in 1994. It was developed by Microsoft, to organize the development process at Microsoft. It is a highly customizable, scalable, fully integrated set of software development processes, principles, and proven practices designed to deliver the type of guidance desired by the user when and where it is needed. MSF provides the best of two popular process models; Waterfall and Spiral, These models provide two different approaches to the project life cycle.

Waterfall model: This model uses milestones as transition and assessment points. When using the waterfall model, each set of tasks in one phase must be completed, before moving on to the next phase. This model works best when project requirements can be clearly defined, and the requirements are fixed, and not modified in the future. Schedules are easily monitored, because there are fixed transitions.

Figure 1: Waterfall Model (Adapted from Microsoft Corporation. MSF Whitepaper: MSF Process Model v3.1)

Spiral model: This model is based on the continual need to refine the requirements and estimates for a project. The spiral model is best used for rapid application development (RAD) of small projects. With this approach, the customer is involved in all stages by providing feedback and approval. The model does not incorporate clear transition points, as does the waterfall model.

Figure 2: Spiral Model (Model (Adapted from Microsoft Corporation, June 2002a)

The MSF Process Model combines the best principles of the waterfall and spiral models. It combines the milestone-based planning of the waterfall model, with the spiral models continuous customer feedback.

Figure 3: MSF Process Model (Adapted from Microsoft Corporation, June 2002a)

The Microsoft Solutions Framework Process Model is composed of five distinct phases:

1) 2) 3) 4) 5)

Envisioning Planning Developing Stabilizing Deploying

Figure 4: MSF Process Model Phases and its 5 Milestones (Adapted from Microsoft Corporation, June 2002a)

Phase 1: Envisioning During this phase, the team creates an overview of the business problem to be solved and determines how that problem relates to the organization. This helps the team get a clear vision of what the team must accomplish for its customers. For a successful project, you need to know what the customer wants to achieve with the solution. During the envisioning phase, the development team and the customer define the highlevel business requirements (through the process of gathering requirements) and the project goals. The main focus of the envisioning phase is on creating clear definitions of the problem. Deliverables There are six deliverables that are created in this phase. Please see Appendix B for a description of each deliverable. The deliverables that are created in this phase include the: baseline vision/scope document (this includes the gathered requirements) milestone review report feature proposal project structure document team lead project progress report risk assessment document

Phase 2: Planning The business problem must be fully understood in this phase, so that a solution can be designed to address the business problem. During this phase, the functional specification, which is the blueprint of the solution, is created. The Planning phase is comprised of several sub-processes or steps: Creating the Conceptual Design During this step, the solution is described from the organization and user perspectives. During the envisioning phase, enough information is gathered, so that the team is able to create the baseline vision/scope document. Near the end of the envisioning phase, the team moves on to the planning phase of the (MSF) Process Model. During this phase, you ensure that the business problem to be addressed is fully understood so that you can design the solution that addresses the business problem. In addition, you plan how the solution will be developed and determine whether you have the resources to develop the solution.

Creating the Logical Design During this step, the solution is described from the developers perspective. The project team begins to identify significant objects and entity attributes needed. Logical design helps the developer further refine the requirements that were created during the envisioning phase and refined during the conceptual design process. Creating the Physical Design Along with conceptual and logical design, the project team creates a physical design of the solution during the planning phase. During the physical design, the developer improves the operation of the solution, that was developed during the logical design step. There are four steps used to create the physical design. They are: research, analysis, rationalization, and implementation. Physical design is the last step in the planning phase of the MSF Process Model. The project team proceeds to physical design after all members agree that they have enough information from the logical design to begin physical design. During physical design, the team applies technology considerations and constraints to the conceptual and logical designs. Due to the fact that the physical design evolves from the conceptual and logical designs, its success depends on the accuracy of the previous two designs. The reliance of physical design on the conceptual and logical designs ensures that the team will be able to complete a physical design that meets the business and user requirements. Presentation Layer Design During the presentation layer design process, the user interface (e.g., web page) of the application is designed. Data Layer Design The data layer is designed for the solution. This includes database design, optimizing data access, and implementing data validation. Designing Security Specifications Security policies and features are designed for the application. This includes adding the appropriate authentication and authorization schemes, ensuring data integrity, and performing data validation. Creating the Technical Specification The technical specification document is created. This document is the blueprint of the solution.

Deliverables There are twenty-three deliverables that are created in this phase. Please see Appendix B for a description of each deliverable. The deliverables that are created in this phase include the: backup and recovery plan business requirements document capacity plan conceptual design document deployment plan development plan end-user support plan functional specifications document logical design document master project plan monitoring plan operations plan operations requirements performance plan physical design document pilot plan security plan support plan (different from the end-user support plan) system requirements document test plan training plan usage scenarios user requirements

Phase 3: Developing In this phase, the code is written and the application is created. Deliverable There are two deliverables that are created in this phase. Please see Appendix B for a description of each deliverable. The deliverables that are created in this phase include the: testing and bug report traceability audit

Phase 4: Stabilizing The goal of the stabilizing phase is to improve the quality of the solution to meet the acceptance criteria for release to production. This is the phase where the application is tested. Deliverables There are three deliverables that are created in this phase. Please see Appendix B for a description of each document. The deliverables that are created in this phase include the: pilot review release signoff test specifications

Phase 5: Deploying During the deploying phase, the solution is deployed to the production environment. Deployment includes installation and end-user training. Deliverables There are two deliverables that are created in this phase. Many of these deliverables are updated throughout the life cycle of the project. The deliverables that are created in this phase include the: post-project analysis project closeout report

Figure 5: Phase 5 Deploying (Adapted from Microsoft Corporation, August 2005)

Glossary
Data integrity Iterative Process

The consistency and accuracy of data. An iterative (repetitive) development process, is a process in which development progresses in incremental stages. This helps to maintain a focus on manageable tasks and ensures that earlier stages are successful, before later stages are attempted. Users are involved throughout the development process. A point at which the team assesses progress and makes mid-course corrections. Milestones are review and synchronization points, not completion points. The project life cycle refers to the overall project from inception to completion. Key life cycle phases include process and project management, requirements, modeling, testing, and software change and configuration management.

Milestones

Project Life-Cycle

References
Microsoft (2003). [MCAD MCSD 70-300] Analyzing Requirements and Defining Microsoft .NET Solution Architectures. Redmond, WA: Microsoft Press. Microsoft Corporation (May 2004). Visual Studio 2005 Team System: Microsoft Solutions Framework. http://www.microsoft.com/technet/itsolutions/msf/default.mspx Microsoft Corporation (April 14, 2004). MSF Sample Templates v3.0. http://www.microsoft.com/technet/itsolutions/msf/default.mspx Microsoft Corporation (June 2003a). MSF Whitepaper: IT Occupation Taxonomy v3.0. http://www.microsoft.com/technet/itsolutions/msf/default.mspx Microsoft Corporation (June 2003b). MSF Whitepaper: Microsoft Solutions Framework version 3.0 Overview. http://www.microsoft.com/technet/itsolutions/msf/default.mspx Microsoft Corporation (June 2002a). MSF Whitepaper: MSF Process Model v3.1. http://www.microsoft.com/technet/itsolutions/msf/default.mspx Microsoft Corporation (June 2002b). MSF Whitepaper: MSF Project Management Discipline v1.1. http://www.microsoft.com/technet/itsolutions/msf/default.mspx Microsoft Corporation (June 2002c). MSF Whitepaper: MSF Readiness Management Discipline v1.1. http://www.microsoft.com/technet/itsolutions/msf/default.mspx Microsoft Corporation (June 2002d). MSF Whitepaper: MSF Risk Management Discipline v1.1. http://www.microsoft.com/technet/itsolutions/msf/default.mspx Microsoft Corporation (June 2002e.). MSF Whitepaper: MSF Team Model v3.1. http://www.microsoft.com/technet/itsolutions/msf/default.mspx Microsoft Corporation. Datasheets for MSF v3 and the MSF Practitioner Program. http://www.microsoft.com/downloads/details.aspx?FamilyID=7d6121ab-7062-4c489181-ffb34d19e0da&DisplayLang=en

APPENDIX A History of Revisions

History of Revisions
Version 1.0 Date 03-16-2006 Notes First version

10

APPENDIX B Descriptions of MSF Deliverables

11

Descriptions of MSF Deliverables

(in alphabetical order) backup and recovery plan
The Backup and Recovery Plan presents the aspects of the solution relevant to backup and recovery, identifies and describes weaknesses in the system, and describes backup methods and recovery steps.

baseline vision/scope document

The Vision/Scope document represents the ideas and decisions developed during the envisioning phase. The goal of the phase, represented by the content of the documentation, is to achieve team and customer agreement on the desired solution and overall project direction. This document includes the gathering of requirements.

business requirements document

The Business Requirements document defines the needs of the organization with regards to the solution.

capacity plan
The Capacity Plan outlines the strategy for 1) assessing overall solution and component performance and 2) using this information to develop the plan for component acquisition, configuration, and upgrade.

conceptual design document

The Conceptual Design is a strategic statement of how the solution will provide value to the collection of usage scenarios. The usage scenarios describe all the participants and activities within a business environment that require a solution.

deployment plan
Deployment Plan describes the factors necessary for a smooth deployment and transition to ongoing operations. It encompasses the processes of preparing, installing, training, stabilizing, and transferring the solution to operations.

development plan
The Development Plan describes the solution development process used for the project. This plan compliments the functional specifications that provide the technical details of what will be built.

end-user support plan

The End-user Support Plan guides how the end-users are supported in their use of the solution. Endusers do not include development, project management or IT operations staff that help to create the solution. Rather they refer to those who will use the end product.

feature proposal
This proposal describes the end-users, as well as how the feature will help meet the project goals. It also describes the characteristics most important to the solution, how it will look and act, how it works with other features, etc.
* Descriptions taken from the Microsoft MSF Templates (http://www.microsoft.com/technet/itsolutions/msf/default.mspx)

12

functional specifications document

The Functional Specification is the repository for the set of deep, technical drill-down documents that detail every element of the solution deliverables, explaining in exact and specific terms what the team is building and deploying. The Functional Specification is the final technical document against which every development team member will build. The Functional Specification is built upon the foundation of 8 separate documents, which are summarized in the Functional Specification.

logical design document

The Logical Design presents a complete and unambiguous definition of the solutions logical elements from the user and functional point-of-view.

master project plan

The Master Project Plan is the document into which all subsidiary plans (development, test, etc) are synchronized and presented together as a single plan.

milestone review report

The Milestone Review Report summarizes the observations and findings of the projects Milestone Review. This process is undertaken at transition points throughout the project to ensure quality and make necessary adjustments.

monitoring plan
Monitoring Plan defines the process by which the operational environment will monitor the solution. It describes what will be monitored, what monitoring is looking for, how monitoring will be done, and how the results of monitoring will be reported and used.

operations plan
The Operations Plan describes how day-to-day operations will occur when the solution is in place. It provides guidance for the organization to maintain the solution successfully over an extended period of time. It contains details on both ongoing and contingency operations and how to proactively handle problems that may arise. Key components of this plan include backup recovery steps, managing configuration changes, and the skills necessary to support the operations.

operations requirements
The Operations Requirements describe what the solution must deliver to maximize operability and improve service delivery with reduced downtime and risks. It addresses the key elements of operations reliability, availability, scalability, supportability, and manageability.

performance plan
The Performance Plan describes the solutions performance requirements, what elements of the solution will be developed to measure performance, and how solution performance will be measured to ensure the requirements are continuously met.

physical design document

The Physical Design is the application of real-world physical design constraints applied to the Logical Design. This is developed by analyzing which pieces of the Logical Design already exist in components, what can be reused or modified, and what new pieces must be created.
* Descriptions taken from the Microsoft MSF Templates (http://www.microsoft.com/technet/itsolutions/msf/default.mspx)

13

pilot plan
The Pilot Plan describes what aspect of the solution will be delivered as a pilot and provides the details necessary to conduct the pilot successfully. This includes details on how to evaluate the pilot, the results of which will facilitate a decision whether or not to move the solution to production.

pilot review
The Pilot Review document records the results of the process that validates that what is delivered during the pilot meets specifications and business requirements.

post-project analysis
The Post Project Analysis document records the results of conducting a depth and breadth assessment of the project from its inception (envisioning phase) to completion (deployment phase). This assessment captures successes, challenges and failures, and identifies what should have been done differently on this project and what could be done differently for the next project.

project closeout report

The Project Close-Out Report is the projects epilogue. It records the comparison between the initial intent of the project and what the project actually delivered. It also records the closing of all remaining open issues, documents any significant changes that occurred in the project during the development and solution deployment, and provides information on the vision for future projects. This is not an evaluation document the final project analysis is recorded in the Post Project Analysis document.

project structure document

The Project Structure document defines the approach the team will take in organizing and managing the project. It is the strategic representation of initial decisions made regarding goals, work scope, team requirements, team processes, and risk.

release signoff
Customers and the development team sign off on a sheet that states that the solution is finished and ready for release.

risk assessment document

List possible risks identified from brainstorming, interviews, and/or risk knowledge bases

security plan
The Security Plan describes how the solution will be brought to acceptable security levels in order to operate successfully. This plan describes what security threats will exist and how implementing security standards will mitigate those.

support plan (different from the end-user support plan)

The Support Plan describes how the solution will be supported once operational. This includes a description of the support personnel and their roles as well as the processes to resolve problems arising within the solution boundaries.
* Descriptions taken from the Microsoft MSF Templates (http://www.microsoft.com/technet/itsolutions/msf/default.mspx)

14

system requirements document

The System Requirements define the current state of the IT infrastructure (cable, routers, bridges, etc. that provide a service) and how that current state will be impacted by the new solution. It identifies how the new solution will interact with the existing system and where critical dependencies exist that must be carefully managed.

team lead project progress report

The Team Lead Project Progress Report summarizes your teams progress on this project, including variance and impact on project delivery (schedule, cost, and scope). Depending on your projects communication plan, you may want to prepare and distribute this report weekly.

test plan
The Test Plan describes the strategy and approach used to plan, organize, and manage the projects testing activities. It identifies testing objectives, methodologies and tools, expected results, responsibilities, and resource requirements.

test specifications
This Test Specification is the technical outline for conducting the testing process. It defines the input, output, environment, and procedural guidelines at the solution level as well as for each test case. The Test Specification is developed using the framework of the Test Plan (created during the Planning Phase) and the contents of the functional specifications.

testing and bug report

The Testing and Bug Report is a roll-up summary of the individual test cases from each stage of testing. The intent is that this document will be used multiple times at frequent intervals during the development, testing, and stabilization phases. For example, during a six-week build phase, the test team might submit this report weekly, or six times during the build phase; however, the team might submit the report bi-weekly during the stabilization phase.

traceability audit
The Traceability Audit documents the processes of 1) comparing specifications to what was actually developed and plans to actual events, 2) identifying if and where change control process broke down, and 3) determining the cause of all variations and deviations. The comparison process focuses on Functional Specification and the Master Project Plan and looks at what occurred in the development phase and how that was different than planned. These differences could take the form of feature reduction, elimination, creation; modifications in the Functional Specification; or scope/schedule/budget changes in the Master Project Plan. The comparison process will also discover if those documents were maintained through the change control procedure. If not, they must be updated and change requests made.

training plan
The Training Plan identifies the needs and processes for training the people who will participate in creating the solution. This training could be on a particular software package or development environment or about specific hardware components. This document focuses on the project teams (which includes the customers information technology staff and help desk); it does not address the training needs of the end-user or support staff for ongoing operations.
* Descriptions taken from the Microsoft MSF Templates (http://www.microsoft.com/technet/itsolutions/msf/default.mspx)

15

usage scenarios
The Usage Scenarios document describes the set of activities that the solution will address and support. These activities are described in terms of what the user wants the solution to do and what other interfacing applications and systems need the solution to do. This information is expressed in terms of actions (functions), actors (users in a specific situation), paths (moving from one state to another within a function), conditions (what must occur to move down the path), and results (output).

user requirements
The User Requirements document defines the non-functional aspect of the users interaction with the solution. It provides guidance on the user interface, expectations of the solutions performance, reliability, and accessibility, and defines what must be done in order to properly train the users on the solution.
* Descriptions taken from the Microsoft MSF Templates (http://www.microsoft.com/technet/itsolutions/msf/default.mspx)

16