i.3 Project Life Cycle in Software Program Management

 < Day Day Up > 



The basic life cycle for a project within the SPMO is shown in Figure i.2. The process is really quite easy to understand, and it follows a logical process of identifying a need, planning for the project, designing the product, making it, testing it, getting it out to the users, and supporting it. The diagram also indicates a final step of project life cycle: closure. We use an established framework of processes known as a Systems Engineering Process (SEP).

click to expand
Figure i.2: The Process Rollercoaster.

i.3.1 Systems Engineering Process

The SEP is a well-defined, detailed, phase-managed set of processes and procedures that make up an entire software project methodology. SEP is a hybrid of the waterfall methodology that started in the 1960s and, according to Edward Yourdon in his book The Decline and Fall of the American Programmer [1], it is still the most widely used methodology in practice today. All eight of the following phases of SEP are managed within the scope of the SPMO:

I. Initiation

II. Planning

III. Design

IV. Construction

V. Testing

VI. Implementation

VII. Support

VIII. Closure

Each phase of the SEP will be described in greater detail in Chapters 2 through 9 of this book. It is important at this point to understand that an SPMO must embrace a methodology or framework within which work will be done. For our purposes, that framework is called SEP. The project documents and templates referenced herein are used to support SEP execution in an environment where multiple concurrent projects are common.

Throughout this book, the management of software projects is based on an assumption of the establishment and standardization of processes and methodology within an IT environment. This book is also a starting point for helping your organization define and achieve the goals of the Capability Maturity Model[2], which was evolved from the Process Maturity Model at the Software Engineering Institute (SEI) at Carnegie-Mellon University.

i.3.2 Overview of the SEI Process Maturity Model

The SEI Process Maturity Model[3] consists of five distinct levels. In the first, or Initial Level, the organizational programmers operate in an ad-hoc fashion. There are no real organizational standards, and, if any exist at all, they are applied in an inconsistent, informal manner by the software development team. The recommended solution at this stage is, of course, implementation of stringent project management procedures. Management must commit to overseeing completion of the process, and both process and quality assurance implementation and training must begin. It is at this level, overcoming the Initial Level roadblock, that we will concentrate our efforts. The commitment required here is to create a standardized, flexible approach to ensuring the success of each project. The focus becomes one of preparing ourselves to achieve consistent, repeatable results by defining processes that prevent common errors. From the Initial Level, we can build a solid foundation that implements industry-standard best practices to assist us and ensure success.

At the second level in the SEI Process Maturity Model, the Repeatable Level, an initial definition of the software development processes has taken place. An organization has achieved a stable level of operation for software development. The organization has developed repeatable processes and has produced statistically acceptable variance tolerances over these development processes. Process groups have been established to ensure compliance with standards; an architecture for software development has been defined and is being adhered to at all levels of development. Finally, software engineering development methodologies are being introduced to the organization.

The next level, the Defined Level, has been achieved by very few organizations. At this level, a strong foundation has been established for the development process. Basic elements of process management have been set up to identify quality and cost factors. A process database has been established, and data-gathering and processing techniques are in place to allow the organization to make informed decisions about the product and management of its development.

The fourth level, the Managed Level, continues to focus the organizational efforts by automation of the data-gathering techniques. The data, which consists of more than cost and schedule data (such as basic software metrics), is used to refine procedures and techniques that support the software development process. Modification of processes based on the use of this data is the major task to accomplish at this level.

The last level described by the SEI Process Maturity Model is the Optimizing Level. You should view this level as a continuation of the previous level because the modifications take place at the Managed Level. The end result of the modifications made at the fourth level is reasonably argued to be the Optimized Level of the organization. This level is an end product of the maturity process and not really a step along the path to software development process maturity.

Baselining Your Organization

As an SEP manager, when you attempt to move your organization from its current state to an optimized level, it is recommended that you start at the beginning and move up the various levels as soon as you can. To that end, this book will provide you with some key recommendations in the next few paragraphs.

Assume Level One from the Beginning

As stated in the previous paragraph, assume you are operating at level one from the outset. If your organization is at level two, it is a simple matter to verify that the criteria for moving to the second level are met. On the other hand, if your organization is really at level one, you need to establish the criteria for moving to the next level.

click to expand
Figure i.3: Five Levels of the SEI/CMU process Maturity Model

Establish Criteria to Move to the Next Level

A solid review of the basic criteria for attaining the Repeatable Level should be undertaken by your organization. At this point, you need to balance the needs of your organization with the absolute necessity of moving up to the Repeatable Level. In the end, much time and money will be saved by making this move, so you, as a manager, must not delay this effort. To establish these criteria, we recommend that you obtain a copy of the SEI Capability Maturity Model document. This document is an update of the initial SEI Process Maturity Model document. We further recommend that your organ-ization establish a working group to research what are perceived to be the most important first steps and implement those steps as soon as possible.

After the dust settles from this first strike to the 'wild ones' in your organization, the creation of initial training programs is necessary to educate your personnel in what the organizational goals are. Quickly weed out or reeducate any dissenters who may become roadblocks to success, but remain open to fair and objective criticism from your personnel. Reward compliance with new standards by setting up shopwide recognition programs to provide an incentive to your people for doing it better than before. You should also strive to encourage the 'wild ones' to develop and establish their own standards as a model for the organization's working group to use. By putting the monkey on their back, you task them with helping meet goals that adhere to SEP guidelines that your working group establishes. Once these newly developed policies and standards have been reviewed and approved by the working group, a higher degree of compliance is almost always assured.

Aspire to Move Onward and Upward

Encourage the people in your organization to help the process mature. As they achieve the goals set forth by the working group, their job becomes much easier. They become more productive and can satisfy requirements much better than before. Instill a new level of professionalism in your people. Do not allow them to maintain or acquire the attitude of the old-timer who 'has been doing it this way for 20 years without problems, so there should be no reason to change now.'



 < Day Day Up > 



Managing Software Deliverables. A Software Development Management Methodology
Managing Software Deliverables: A Software Development Management Methodology
ISBN: 155558313X
EAN: 2147483647
Year: 2003
Pages: 226

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