A View of Software Development Projects


Software development projects are complex projects that involve a variety of different moving parts: Yes, developers are an important component of the software development machinery, but they are far from the only component. With any sufficiently sized project, architects are also involved. They act as the keepers of the technical blueprint for a solution and work closely with developers to ensure that the blueprint is achievable in code and that it matches the requirements and expectations of the project. Testers are also involved. They test the validity of the code produced by the developers against a gamut of quality benchmarks. And finally, one or more individuals are usually needed to manage the logistics of the project: who is working on what, schedule achievement, and general process management.

In addition to the different roles and skill sets involved, any given project progresses through a series of phases from inception to completion. Over time, the software industry has evolved various models that are useful in describing the software development life cycle and the interactions between the various roles and parties.

Microsoft has developed its own series of models and guidance around the SDLC and the involved roles called the Microsoft Solutions Framework. The Microsoft Solutions Framework, or MSF, is in its fourth major incarnation. It documents a process model for describing the phases and activities within the SDLC and a team model for describing the roles that participate on the software development project team. It is also a collection of best practices, project-specific guidance, and templates.

The MSF is available in two flavors: MSF for Agile Software Development (MSF Agile) and MSF for CMMI Process Improvement (MSFCMMI). A basic understanding of MSF is important to this discussion of Visual Studio Team System for two reasons:

  • To understand the value of VSTS, you first have to understand the problem space presented with software development projects; by using a common set of terms and semantics to describe this problem space, you'll have a much easier time understanding the benefits that the Visual Studio Team System brings to the table.

  • In addition, VSTS is capable of using template models that actually impact tool behavior within Visual Studio. MSF Agile and MSF for CMMI are two templates delivered by Microsoft for direct use with Visual Studio Team System.

MSF Agile

MSF Agile maps the concepts of a solutions framework into the values favored by an agile development methodology. Although it is hard to come up with a universal definition of what makes a development process agile, in general these methodologies can be said to adhere to and prize the following characteristics:

  • Individuals and interactions trump processes and tools.

  • Valid, quality software is valued over comprehensive documentation.

  • Collaboration with the customer and between team members is advocated over contract negotiation.

  • The project team is empowered to react to change as opposed to following a prescriptive project plan.

The MSF Agile Process Model

The MSF v4 Agile process model deals with the development process in terms of tracks, checkpoints, and work products. Tracks are a set of activities (some sequential, known as workstreams; others not). Checkpoints are consensus points where the team collaboratively examines progress and determines whether to continue on the current path, change paths, or stop altogether. Work products is the term given to the tangible outputs from one or more activities; these are the source code, documents, spreadsheets, and so on, that are generated throughout the course of a project.

The MSF Agile model also incorporates the concept of cycles. Cycles represent the frequency with which activities are performed. For instance, a daily build is an example of a cycle that involves a discrete set of activities that, in turn, result in a discrete set of work products.

The MSF Agile Team Model

Beyond the activities you expect to see within an SDLC, it is also useful to understand the interaction between the various roles you encounter on a software project. The MSF Agile team model represents the project team as a set of different constituencies. The needs of each constituency are represented by its team members, and all members are considered to be peers on the project team. No one role is more important than another. Figure 17.1 documents the Agile team model.

Figure 17.1. Constituencies and roles in the MSF Agile team model.


MSF for CMMI

The Software Engineering Institutes Capability Maturity Model (CMM) is "a reference model of mature practices in a specified discipline, used to improve and appraise a group's capability to perform that discipline" (see http://www.sei.cmu.edu). The Capability Maturity Model for Integration (CMMI) is a collection of four CMMs focused on the disciplines of software engineering, systems engineering, integrated product and process development, and supplier sourcing. MSF v4 for CMMI (MSFCMMI) is a framework tied directly to this four-discipline CMMI.

The MSF for CMMI Process Model

Just like MSF Agile, the MSF for CMMI process is described in terms of tracks and checkpoints. The tracks within MSFCMMI are more formally defined, and the checkpoints are also all well defined with expected deliverables.

Figure 17.2 shows the tracks and checkpoints espoused by the MSF for CMMI process model.

Figure 17.2. Tracks and checkpoints in MSF for CMMI.


These tracks are a recognition of the fact that although there are many competing models for the SDLC, they really all distill down to project activities spread across the natural rhythm of the project process:

  • First, all the parties involved need to agree on the vision for the project. What are they setting out to achieve? How will they know whether they are successful?

  • After a common vision has been agreed upon, boundaries have been set, and goals have been documented, the project team needs to agree on both what they are going to build and how they are going to build it.

  • Then the plans are put into action, and the software application is actually architected, designed, and written.

  • As various components of the system are written, they need to be tested to ensure that they are actually realizing the requirements of the project and that they meet the project team's commitments with respect to quality.

  • And finally, after all of the parts have been written, tested, and approved, the software application has to actually be deployed so that it can be used.

These phases are termed, respectively, Envisioning, Planning, Developing, Stabilizing, and Deploying. Each of these phases has a different set of anticipated work activities, work outputs, and culminating checkpoints.

The MSF for CMMI Team Model

The MSFCMMI team model is identical in principle and structure to the MSF Agile team model, but it defines and maps many more roles. Compare Figure 17.1 with Figure 17.3.

Figure 17.3. Constituencies and roles in the MSF for CMMI team model.





Microsoft Visual Studio 2005 Unleashed
Microsoft Visual Studio 2005 Unleashed
ISBN: 0672328194
EAN: 2147483647
Year: 2006
Pages: 195

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net