MSF for CMMI Process Improvement

MSF for CMMI Process Improvement

MSF for CMMI Process Improvement (MSF CMMI) is a lightweight, agile approach to CMMI. It's designed for organizations looking to achieve and maintain a CMMI Level 3 status, as defined by the Capability Maturity Model (CMM) developed by the SEI (an organization we will discuss shortly). Actually it's a stretched version of MSF for Agile Software Development, modified to include the process areas required by a CMMI Level 3 appraisal. Future versions of MSF for CMMI Process Improvement will be stretched all the way to CMMI Level 5.

Although MSF CMMI does not include a number of the traditional project management techniques—such as estimating and tracking, earned value, and critical path method (CPM)—it does offer guidance on incorporating these techniques by using the Microsoft Office Project interface to Team System.

The Capability Maturity Model Integration (CMMI) is not an SDLC model per se, but rather a process improvement framework. It was developed by the Software Engineering Institute (SEI), a federally funded research and development center sponsored by the U.S. Department of Defense. The foundation of the CMMI is the Capability Maturity Model (CMM), originally developed by SEI in the mid-1980s. The CMM was developed primarily as a tool for evaluating the software development capabilities of defense contractors, with the goal of avoiding the spectacular and costly failures that were all too common in those days. Using the CMM, the Department of Defense could objectively assess the “maturity” of a software development organization.

NOTE
The SEI was founded by the United States Department of Defense in 1984 to formulate methods and guidelines that help organizations efficiently create high-quality software that's delivered on time, completed within budget, and performs reliably. The SEI is operated by Carnegie Mellon University in Pittsburgh under contract to the Department of Defense. Although the SEI's primary customers are defense contractors, any organization is welcome to take advantage of the many resources available on their Web site: http://www.sei.cmu.edu/cmmi.

The CMM rates an organization's maturity on a five-tier scale. The various tiers are defined as follows:

• Level 1—Initial

  There are few stable software processes in evidence, and performance can be predicted only on the capability of individuals rather than organizational capability.

• Level 2—Repeatable

  Planning and tracking of software projects is stable and earlier successes can be repeated.

• Level 3—Defined

  The organization uses a defined software process, and software quality is tracked.

• Level 4—Managed

  The software development process is measured and operates within measurable limits.

• Level 5—Optimizing

  The entire organization is focused on continuous process improvement.

Each maturity level is composed of a set of key project areas (KPA). Each KPA is a group of related activities that achieve a set of goals deemed important for establishing process capability at that maturity level. For instance, the Level 2 KPAs are Requirements Management, Project Planning, Project Tracking, Configuration Management, and Quality Assurance. Get those right, and you're a Level 2 shop.

As it turns out, the CMM proved to be an excellent process improvement tool for large software engineering organizations. Once an organization knew its current maturity level, the CMM told it exactly which KPAs to work on to get to the next maturity level. In this way, the CMM provided prescriptive guidance for process improvement.

As experience with the CMM grew, the SEI found that it needed to specialize the CMM for various disciplines such as systems engineering, software engineering, software acquisition, workforce management and development, and integrated product and process development. So it developed a CMM for each of these disciplines. That solved one problem but created another. Many organizations wanted to focus their improvement efforts across the disciplines. However, the differences among these discipline-specific models made this a difficult and costly proposition.

This is where the CMMI comes in. Its purpose is to combine several source models into a single improvement framework for use by organizations pursuing enterprise-wide process improvement. In the process of merging the models, the CMMI Product Team built a framework that accommodates multiple disciplines. MSF for CMMI Process Improvement offers a proven sequence of improvements, beginning with basic management practices and progressing through a predefined and proven path of successive levels.

Principles

Microsoft Solutions Framework for CMMI Process Improvement encapsulates a lightweight approach to formal software development and continuous process improvement. The method, which is rooted in the teaching of Edwards Deming and others, asks the team to focus on the difference between special cause variation and common cause variation in its software engineering practices. The method seeks to eliminate special cause variation through the use of frequent, high-bandwidth communication, aggressive issue management, and progressive risk management. Common cause variation is reduced, and productivity on valuable working software is increased by implementing improvement suggestions under controlled circumstances, and monitored and assessed using a standard set of metrics provided in the tooling. Like many agile methods, MSF for CMMI Process Improvement is focused on the flow of value to the customer in short cycles using small batches of requirements, but unlike agile methods, it introduces an extra dimension of variation reduction and elimination. The net result is a lightweight, agile, adaptive process for highly productive software engineering that provides a significant accelerator to achieving a CMMI Level 3 assessment and lays the groundwork for achievement of Levels 4 and 5 in future.

Following are the core ideas of MSF for CMMI Process Improvement:

Partner with Customers

The customer is the consumer at the end of the value chain. To maximize customer value, everyone in the value chain must partner by seeking to better understand customer value and share that information back up the value chain.

Foster Open Communications

To maximize individual effectiveness, encourage improvement suggestions, facilitate root cause analysis, and help eliminate special cause variations. Open, direct, high-bandwidth communication and information sharing must be a core to the culture to the team.

Work Toward a Shared Vision

Shared vision aligns the interests and work focus of all team members throughout the value chain. Collaboration is improved. A shared vision provides a framework against which decisions can be assessed and made by consensus.

Quality Is Everyone's Business, Every Day

Quality is everyone's business, every day. Quality encapsulates the ideas of pride of workmanship, right first time, and continuous improvement. Everyone on the team should understand variation and specifically understand how to measure and interpret the variation in their inputs, their rate of input, their working method, their lead time, and their rate of output. Eliminating special cause and reducing common cause variations should be everyone's business, every day. Suggestions for improvement could come from anyone, any time, and be implemented by a local consensus. Continuous improvement in productivity, on-time delivery, with agreed functionality, and within bug tolerance levels is more easily achieved when everyone on the team is contributing.

Stay Agile, Adapt to Change

Profits come from differentiation, and differentiation requires innovation. By its very nature, innovation is new and unknown, and innovative projects contain uncertainty. Uncertainty adds variation and change. Because change is a fact of life in innovative software development, the engineering method must be designed to cope gracefully with it.

Make Deployment a Habit

“Teams that learn to ship, ship!” is a saying commonly used in Microsoft product groups. It is important for risk management, eliminating special cause variation, and facilitating the flow of value to knock the kinks out of the delivery and deployment processes. By making deployment a habit and by practicing and testing deployment procedures, even with early life-cycle prototypes, the whole team learns how to make deployments run smoothly and predictably.

Flow of Value

Flow of value separates out the notion of a functional resource with a capacity from the flow of customer-valued functionality. A project is a collection of value scheduled for realization, whereas a functional resource has a capacity to create working software of value at a known pace or velocity. Focusing on flow of value means scheduling cohesive small batches of customer value for deployment at regular intervals and facilitating that flow by eliminating special cause variation. Meanwhile, functional managers responsible for capacity can focus on reduction of common cause variation in the method of software engineering and increasing capacity through continuous improvement of productivity measured as velocity.

Mindsets

A mindset is a framework for thought (also known as a paradigm). A mindset is defined by a collection of principles, which are abstract concepts used to guide and constrain concrete activities. When a team member is deciding how to act and is forced with a complex decision, principles provide a guiding set of constraints—a framework—within which to decide the correct course of action. Mindsets and principles of MSF should become ingrained in the mind of every team member. They should be referred to daily as team members make decisions to guide and steer the project, prioritize work, and interact with stakeholders.

Following are the mindsets of MSF for CMMI Process Improvement:

Quality Is Defined By Customer

Satisfied customers are priority number one for any team. The customer in this case is the end consumer of the product or service. There is only one customer in the value chain: the consumer at the end of the chain. Everyone on the team should be aware of the consumers for the product and be focused on delivering something that they need, want, and will derive value from. In MSF, consumers are defined using personas. A persona focus throughout development means having a commitment from the team to understand and solve the persona's problems. Once understood, real consumer involvement must be maximized to the degree possible to ensure that consumer expectations are aligned with the product features committed to for the project. Techniques that support setting and managing consumer expectations include reporting on the backlog, building small batch sizes (or highly iterative delivery), and high quality in terms of functioning without errors, but more so in terms of correct interpretation of the needs and wants of the persona and the consumers that the persona represents.

Pride of Workmanship

Pride of workmanship is core to any craft or profession. In software development, pride of workmanship is the notion that every team member involved in a product takes a deep, heartfelt care and passion in the quality of the finished product. Division of labor and 20th century mass-production thinking tended to weaken pride of workmanship. It was too common to simply throw the work to the next person in the chain and wait for the quality control department to reject the defects. Much of this thinking crept into software engineering with the idea that specialized analysts pass work to specialized designers, who pass it to coders, who pass it to testers, and so forth. Pride of workmanship in the quality of the end product was lost. MSF asks all team members to take pride in the quality of the end product and to do their best to ensure that Quality Assurance is embedded at every step in the life cycle.

Team of Peers

A team of peers implies that equal value is given to each constituency in the Team Model. Although different roles have different foci within different tracks, all constituencies are equally important to the risk management of the project and successful delivery of a quality product. A team of peers calls for team accountability and shared responsibility for effectiveness and project success.

Frequent Delivery

Early and frequent delivery builds trust among the team and externally with sponsors, business owners, and product consumers. Trust is the grease that lubricates a highly productive software engineering organization. Trust enables agility and reduces the need for verification, documentation, and checkpoints. The frequency of delivery should be tuned to the cadence of the business domain. In some domains, delivery every day makes sense, whereas in others it will be quarterly, biannually, or annually. There is a transaction cost to delivering a shippable product, and that cost must be understood and factored against the desire to make the frequency of delivery as short as possible. Frequent delivery reduces the batch size for an iteration or release, so the iteration or release cycle is shorter. Small batch sizes are good for risk management and also facilitate flow of value and quality. It is easier to keep a small batch moving; the number of issues and risks to monitor and resolve will be smaller. Quality is higher with small batches because each individual function receives better focus and attention from the team. Through frequent delivery, process and infrastructure are proven and improved. Risks, bugs, and missing requirements are detected early. Feedback can be provided when it can make a difference. Some keys to frequent delivery are keeping batch sizes small, working on deliverables in a “just-in-time” manner, and keeping options open by postponing decisions until the last responsible moment. This is embodied in the late planning techniques, which lock only fine-grained commitments at the start of each iteration. Frequent delivery enables quality, continuous improvement, trust, better flow, increased productivity, and overall better economic performance from the organization.

Willingness to Learn

Because each development project, environment, and team is unique, each project and iteration within the project creates a learning opportunity. However, there can be no learning without honest feedback and reflection. Unless there is a supportive, risk-tolerant environment that fosters personal safety, feedback will be limited and cannot facilitate continuous improvement. After a framework is in place to facilitate learning, individuals and teams can focus on continuous improvement, gathering and sharing of knowledge, and root-cause analysis of special cause (or chaotic) events that disrupt plans, schedules, and commitments. Proven best practices from external sources can be introduced under controlled, objective conditions and monitored for their effects. Learning opportunities include peer reviews, iteration retrospectives, operations reviews, and process- and guideline-tailoring activities.

Get Specific Early

Abstract thinking is a useful tool. However, abstractions by their very nature lack definition and detail. Using abstract techniques often leads to a diversity of thought across a team. By getting specific early and developing concrete examples using personas and scenarios, a team can better align its thinking and come to a shared vision and consensus on the work to be undertaken. Being abstract too long adds risk to a project and undermines team effectiveness. Too many projects lose time because of people procrastinating about the “big” picture instead of tackling solvable problems. Take one small step at a time, get specific, use concrete examples, and build concrete working code. Learn from these specific examples rather than debate abstract vaporware. Techniques supporting this mindset include personas, scenarios, design for deployment, and test cases.

Qualities of Service

A QoS mindset looks at the solution and develops plans based on every aspect of customer experience. The idea is that qualities of service such as performance and security should not be considered late in the project, but throughout the entire project. When ignored, these qualities of service are ultimately consumer dissatisfiers. The consumer is dissatisfied because the QoS is implicitly assumed. In the spirit of getting specific early, MSF turns implicit assumptions into explicit QoS requirements. Techniques supporting this mindset include using specialist expertise where you need it and discovering risks as early as possible.

Citizenship

Be a good project and software engineering organization citizen. Team members are encouraged to treat others as they would want to be treated and to treat project and organization assets as if they were their own. A good citizen is a steward of corporate, project, and computing resources. Members seek to reuse resources and to provide resources that can be reused. They clean up their own messes. Citizens keep their home and its precincts tidy. Citizens share resources and do not hog valuable assets for their own use. They share knowledge and recognize that the whole takes precedence over the individual. Citizens act for the greater good. Citizens think holistically about the system of software engineering. Citizens value every contribution toward the achievement of the product vision and delivery of successful projects.

Roles

In MSF for CMMI Process Improvement, a team of peers advocates for the seven constituencies in the MSF Team Model. The Team Model was created to model all the views of a project that must be represented and monitored to reduce risk and increase the likelihood of a successful project. Experience with earlier versions of MSF has shown that failure to have all the constituencies in the Team Model represented leads to the increased likelihood of project failure or disappointment. The Team Model constituencies represent the full project life cycle including vision, production, use, and maintenance. Each team member plays at least one of the roles and is accountable for advocating on behalf of a given constituency within the Team Model. No constituency is more important than any other, so no specific role is more important than any other. MSF for CMMI Process Improvement is a consensus lead process definition that requires facilitated agreement among role players. Together, the Team Model and the consensus-oriented nature of role-playing in MSF for CMMI Process Improvement provide the necessary checks and balances to ensure overall quality and satisfied customers within a framework of good governance.

The team of peers breaks down into seven advocacy groups. Here is a list of these groups with the roles they contain:

• Product Management—product manager, business analyst

• Program Management—project manager, sponsor

• Architecture—architect, subject matter expert

• Development—developer, developer manager, build engineer

• Test—tester, test manager, auditor, QoS specialist

• Release/Operations—release manager, integrated program management (IPM) officer

• User Experience—user experience architect, user education specialist

Here are the roles as defined by MSF for CMMI Process Improvement:

• Product Manager

  The product manager is the main advocate for the product management constituency in the MSF Team Model. The product manager is the proxy for the end consumer of the product and has overall product mix responsibility for the requirements. The product manager must ensure that the product vision is met through the requirements and that the acceptance tests are developed to validate the product. The product manager must show that the product aligns with the organization's strategic planning and fits the market segment(s) intended in the original vision statement. The product manager will ensure that the project stays within budget and that the business case is realized. The product manager's work is used as the primary source for the track checkpoints in the MSF Governance Model.

  Work streams and activities: capture the product vision and release a product.

• Business Analyst

  The business analyst's main goal is to advocate for the product management constituency in the MSF Team Model. This goal is achieved by working with sponsors, subject matter experts, product managers, and user experience architects to analyze and define the business opportunity and the product outlined in the vision statement for the project. The business analyst will work on defining personas, writing scenarios, and acting as a proxy for the users and customers by interfacing directly with developers, testers, and other roles active in the later project life cycle.

  Work streams and activities: analyze, create a QoS requirement, create a scenario, create product requirements, establish project process, issue management, manage change requests, plan an iteration, release a product, risk management, test a scenario, test a QoS requirement, verify a functional requirement, and verify an operational requirement.

• Project Manager

  The project manager advocates for program management constituency in the MSF Team Model. The project manager is responsible for the flow of knowledge creation and ultimately the realization of value, which comes from delivery of the product outlined in the vision statement. The project manager owns the life cycle of the project from end to end. The main goal is to deliver business value within the agreed-upon schedule and budget. The project manager is charged with planning and scheduling duties, including developing project and iteration plans, monitoring and reporting status, and identifying and mitigating risk. The project manager is also expected to consult with business analysts to plan the backlog for the project and its iterations; and consult with architects, developers, testers, user education specialists, and user experience architects to estimate work and facilitate communication within the team.

  Work streams and activities: capture product vision, create product requirements, develop documentation, establish project processes, issue management, plan an iteration, plan a project, risk management, test a scenario, test a QoS requirement, verify a functional requirement, and verify an operational requirement.

• Sponsor

  A project should not be undertaken without a sponsor. A sponsor advocates for the product management constituency in the MSF Team Model. A sponsor is responsible for providing the business case and finances for the project. The sponsor's input controls the governance of the project. The sponsor holds the business case and product vision against which the project governance is measured. Without a sponsor, there can be no governance.

  Work streams and activities: capture the product vision, create product requirements, and release a product.

• Architect

  The architect role is to advocate for the architecture constituency in the MSF Team Model. The architect is responsible for maintaining the architectural integrity of the product and for ensuring the success of the project by designing the foundations on which all the value can be realized. This role includes defining both the organizational structure of the application and the physical structure of its deployment. In these endeavors, the architect's goal is to reduce complexity, decrease coupling and regression effects, and increase the cohesiveness of components by partitioning the system into parts that can be built and tested independently. The resulting architecture is extremely important because it not only dictates how the system will be built going forward but also establishes whether the application will exhibit the many traits that are essential for a successful project. These traits include its usability, whether it is reliable and maintainable, whether it meets performance and security standards, and whether it can be evolved easily in the face of changing requirements.

  Work streams and activities: analysis, create a QoS requirement, create product requirements, create solution architecture, establish environments, establish project process, test a scenario, test a QoS requirement, verify a functional requirement, and verify an operational requirement.

• Subject Matter Expert

  A subject matter expert is someone who advocates for the product management constituency in the MSF Team Model. A subject matter expert can be anyone who happens to have the knowledge of an area of the business or product vision or technical solution. A subject matter expert is responsible for communicating and transferring their knowledge into other members of the team, so that the appropriate area of the product vision can be realized.

  Work streams and activities: analysis, create a QoS requirement, create product requirements, test a scenario, test a QoS requirement, verify a functional requirement, and verify an operational requirement.

• Developer

  The developer advocates for the development constituency in the MSF Team Model. The developer is responsible for the bulk of the work building the product. Other development roles, such as the lead developer and development manager, have additional communication and project management responsibilities. The developer should suffer a minimum of communication overhead allowing for a maximum effort on construction of code. In addition, during the early stages of a project, developers might be expected to help specify product requirements not included in the customer requirements and to work on analysis and architecture activities as part of a multi-disciplinary team. A lead developer's role is to lead and to communicate on behalf of other developers. A lead developer advocates for the development constituency in the MSF Team Model, lends experience and skill, and shows leadership by coaching fellow developers. Lead developers carry responsibility for code reviews, design, and unit testing coverage. Lead developers act as a conduit to the rest of the project for the developers. As an aid to productivity, lead developers funnel communications between the wider project team and external organizations, and shield developers from noise and random interference in their daily schedules. Because of this, lead developers can seldom dedicate themselves to development tasks. Typically, they will spend about 50 percent of their time on communication and split the remainder between leading and coaching the developers on their team, and actually writing code for development tasks.

  Work streams and activities: analysis, create solution architecture, develop documentation, establish environments, establish project process, fix a bug, implement a development task, release a product, test a scenario, test a QoS requirement, verify a functional requirement, and verify an operational requirement.

• Developer Manager

  The development manager is the functional line manager for software development. Lead developers and developers will report in to a development manager. A development manager advocates the development constituency in the MSF Team Model. They are responsible for the capacity of the software development team as measured by metrics such as velocity, and for the variation in capacity and rate of productivity and quality as measured by metrics such as unplanned work, work remaining, quality indicators, and actual quality versus planned velocity. The development manager takes responsibility for the continuous improvement and learning in the software development team. The development manager does not have direct responsibility for the flow of a project and the value in the product solution, but instead works with the project manager to provide the resources to facilitate the smooth flow of the project through development.

  Work streams and activities: create product requirements, establish environments, establish project process, and release a product.

• Build Engineer

  A build engineer is a specialist who performs the function of facilitating the build or integration of the source code. The build engineer advocates for the development in the MSF Team Model. By specializing the build and integration skills in a single role, the developer is freed to focus on understanding the product vision and the creation of value. The build engineer will run the build and develop scripts for automation of the build and automated reporting mechanisms such as the build report. Within Visual Studio Team System, the build engineer owns the “Team Build” functionality.

  Work streams and activities: build a product, establish environments, and establish project process.

• Tester

  The tester advocates for the test constituency in the MSF Team Model. The tester's main goal is to discover and communicate problems with the product that could adversely affect its value. The tester must understand the context for the project and help others to make informed decisions based on this context. A key goal for the tester is to find and report the significant bugs in the product by testing the product. After a bug is found, it is also the tester's job to accurately communicate its impact and describe any workaround solutions that could lessen its impact. The tester makes bug descriptions and steps for re-creating the bugs easy to understand and follow. The tester participates with the entire team in setting the quality standards for the product. The purpose of testing is to prove that known functions work correctly and to discover new product issues.

  Work streams and activities: analysis, close a bug, develop documentation, establish environments, establish project process, release a product, test a scenario, test a QoS requirement, verify a functional requirement, and verify an operational requirement.

• Test Manager

  The test manager is responsible for the capacity and quality of the testing function. Testers report to the test manager. The test manager advocates for the test constituency in the MSF Team Model and takes responsibility for the continuous improvement and learning in the software test team. A test manager does not have direct responsibility for the flow of a project and the value in the product solution but instead works with the project manager to provide the resources to facilitate the smooth flow of the project through test.

  Work streams and activities: create product requirements, establish environments, establish project process, release a product, test a scenario, test a QoS requirement, verify a functional requirement, and verify an operational requirement.

• Auditor

  An auditor is external to the project and offers an independent objective view of a project and its processes. An auditor effectively advocates for the product management constituency in the MSF Team Model by auditing the QA (quality assurance) in the project's product and its processes. The auditor is responsible for assessing the quality in the product as measured by quality control and the QA measured as conformance against process definition. An auditor reports variance from specification, variance from plan, and variance from process definition. An auditor's reports can be used to assess the likely quality of the product and whether or not the organization exhibits control in its operations.

  Work stream and activity: establish project process.

• Quality of Service Specialist

  A quality of service specialist is a developer with particularly specialized skills in one or more areas of technology that are needed to deliver qualities of service requirements such as performance, scalability, reliability, security, and so forth. A quality of service specialist advocates for the development constituency in the MSF Team Model. By specializing qualities of service knowledge into a single role, the regular developer is freed up to focus on the product vision, the customer requirements, and delivering customer value while a specialist can assist him or her to ensure that his or her code meets the exacting requirements of challenging qualities of service. A quality of service specialist can either rework code written by developers or develop prototypes and examples and publish these as patterns for use in code reviews. A quality of service specialist can coach other team members about how to develop code using the appropriate design patterns to deliver the required quality of service.

  Work stream and activity: establish project process.

• Release Manager

  The release manager advocates for the Release and Operations constituency in the MSF Team Model. This role's goal is to manage the rollout of the product. The release manager coordinates the release with operations or media control, creates a rollout plan, and certifies release candidates for shipment or deployment.

  Work streams and activities: baseline configuration management, create product requirements, establish project process, manage change requests, and release a product.

• Integrated Program Management (IPM) Officer

  The IPM officer is the executive responsible for the overall organizational scheduling, planning, and resource allocation. The integrated program management office (IPMO), which is run by the IPM officer, coordinates all projects in a portfolio and provides a means for project members to communicate schedule and resource information to each other. The IPM officer advocates for the program management constituency in the MSF Team Model. The IPM officer is responsible for the organization-level flow of projects in a portfolio, whereas a project manager is responsible for the flow of a single project. The IPM officer's main role is to hold coordinating meetings among project managers and to facilitate the negotiation of priorities, schedules, and resource allocation. This becomes particularly important when scarce specialist shared resources have conflicting demands from two or more projects in a portfolio. A good IMP officer is a diplomat, a negotiator, and a facilitator.

  Work streams and activities: create product requirements, establish project process, issue management, plan an iteration, and release a product.

• User Experience Architect

  A user experience architect advocates the user experience constituency in the MSF Team Model. A user experience architect is responsible for the product design; not the technical architecture of the technical solution, but the form and function of the user interface, its aesthetics, and the overall product usability. Within the field of user experience architects, there is room for specialization. In many organizations, this role is represented by a team of people with specialist job titles such as usability engineer, interaction designer, and graphic designer. In MSF, these disciplines are represented in a single role. A user experience architect gets involved at the very beginning of a project. He or she will seek to understand the goals of the consumer for the product and to envision a design that meets those goals. A user experience architect will develop the personas and usage scenarios for the customer requirements. He or she may also develop prototypes or storyboards and conduct usability testing at several stages in the project life cycle during the planning, build, stabilize, and deploy tracks in the MSF Governance Model.

  Work streams and activities: analysis, capture product vision, create a scenario, create product requirements, establish project process, and release a product.

• User Education Specialist

  The user education specialist is typically a technical writer who advocates for the user experience in the MSF Team Model. The user education specialist focuses on consumer-focused technical writing that reinforces or enhances product value and helps to realize the product vision. A user education specialist can work on product manuals, online help, operations manuals, maintenance manuals, training manuals, and any other documentation that can be used to enhance the usage and value delivered with the product. User experience architects typically work closely with user education specialists. A good user experience and product design typically leads to a lower workload for the technical writing team. Excessive documentation may be an indicator that the user experience is poor, and the writing is compensating for poor overall product design.

  Work streams and activities: analysis, develop documentation, establish project process, and release a product.

Work Item Types

MSF for CMMI Process Improvement includes the following items:

• Bug

  This item communicates that a potential problem exists or has existed in the system. The goal of opening a bug is to accurately report bugs in a way that allows the reader to understand the full impact of the problem. The descriptions in the bug report should make it easy to trace through the steps used when the bug was encountered, thus allowing the bug to be easily reproduced. The test results should clearly show the problem. The clarity and understandability of this description often affects the probability that the bug will be fixed.

• Change Request

  A change request work item identifies a proposed change to some part of the product or baseline. Change requests must be created when a change is proposed to any work product that is in the configuration management system. The change request work item is used by the change control board to analyze, accept, and reject proposed changes. If a change request is accepted, it is used to generate tasks to implement the change. After changes are implemented, the change request is eventually closed.

• Issue

  The issue work item documents an event or situation that may block work or is currently blocking work on the product. Issues differ from risks in that they are identified spontaneously, generally during daily team meetings. Issue work items are reviewed and analyzed to create tasks to resolve the issue. After corrective action is taken by completing the tasks, the issue is resolved. Finally, if the corrective action is deemed acceptable, the issue is closed.

• Requirement

  Requirements capture and track what the product needs to do to solve the customer problem. There are several types of requirements: scenario, QoS, functional, operational, and interface. As requirements are identified, they begin in the Proposed state. When a requirement is accepted for the current iteration, it moves to the Active state and is analyzed to create tasks to implement it. When the tasks are complete and system tests are passed to show that the requirement is successfully implemented, it moves to the Resolved state. Finally, when the requirement is validated, it is moved to the Closed state.

• Review

  The review work item documents the results of a design or code review. The review work item must include detailed information about how the design or code met standards in areas of name correctness, code relevance, extensibility, code complexity, algorithmic complexity, and code security. If the review found that the design or code needed no changes, the review work item can be closed. If minor changes or major changes are needed, the active review work item is assigned to a developer to resolve. If minor changes are needed, the developer can close the review work item directly. If major changes are needed, a second review is required, and the review work item is closed only if the second review passes successfully.

• Risk

  This item documents and tracks the technical or organizational risks of a project. When concrete action is required, these risks might translate into tasks to be performed to mitigate the risk. For example, a technical risk can set off an architectural prototyping effort. The team should always regard risk identification in a positive way to ensure contribution of as much information as possible about the risks it faces. The environment should be such that individuals identifying risks can do so without fear of retribution for honest expression of tentative or controversial views. Teams creating a positive risk management environment will be more successful at identifying and addressing risks earlier than those teams operating in a negative risk environment.

• Task

  This process template item communicates the need to do some work. Each role has its own requirements for a task. For example, a developer uses development tasks to assign work derived from scenarios or QoS requirements to component owners. The tester uses test tasks to assign the job of writing and running test cases. A task can also be used to signal regressions or to suggest that exploratory testing be performed. Finally, a task can be used generically to assign work within the project. On the work item form, certain fields are used only in cases when a task relates to a particular role.

Disciplines and Qualities of Service

MSF for CMMI Process Improvement defines the same disciplines as does MSF for Agile Software Development: project management and risk management. Qualities of service are the same as well: security, performance, and user experience.

Governance

Governance concerns utilization of resources through the control of time and money relative to the flow of value. MSF for CMMI Process Improvement defines five tracks for the project life cycle that encapsulate sets of work streams and activities. Each track concludes with governance checkpoints, and each checkpoint provides an opportunity to authorize continued work on the project or to cancel or suspend the project. The checkpoint for each track asks a different question or set of questions. The objective for the work within a track is to provide the answers to the governance questions and back those answers with transparent project data gathered through the day-to-day operations of the software engineering organization.

The MSF Governance Model is designed to be risk-tolerant and to facilitate the easy flow of a project. Tracks start when the required inputs are available; that is, tracks are event-driven. Work in several tracks can run in parallel. Governance checkpoints at the end of tracks provide the opportunity to shut a project down with the understanding that some work on subsequent tracks may already be under way. The risk of waste is balanced against the desire to keep the project moving and be both agile and productive within a formal governance framework.

MSF for CMMI Process Improvement seeks to separate out the operational management of the organization from the corporate governance of the organization. The first asks for a focus on “Are we good at software engineering?” whereas the second asks for a focus on “Are we making best use of our software engineering resources?” Operational management is about capacity, quality, and reliable low-variation engineering. Governance is about making best use of the shareholder's or taxpayer's funds through the optimal utilization of capacity.

The MSF for CMMI Process Improvement defines seven tracks: envision, plan, build, stabilize, deploy, operational management, and governance.