PART I: SOFTWARE PROCESS MATURITY
1 A SOFTWARE MATURITY FRAMEWORK
1.1 Software Process Improvement
To improve their software capabilities, organizations must take six steps:
1. Understand the current status of their development process or processes.
2. Develop a vision of the desired process.
3. Establish a list of required process improvement actions in order of priority.
4. Produce a plan to accomplish the required actions.
5. Commit the resources to execute the plan.
6. Start over at step 1.
1.2 Process Maturity Levels
1. Initial
2. Repeatable
3. Defined
4. Managed
5. Optimizing
Initial
Repeatable
Defined
Managed
Optimizing
Basic Management Control
Process Definition
Process Measurement
Process Control
1.3 The Optimizing Porcess helps people to be effective in several ways:
o It helps managers understand where help is needed and how best to provide the people with the support they require.
o It lets the professionals communicate in concise, quantitative terms.
o It provides the framework for the professionals to understand their work performance and to see how to improve it.
2 THE PRINCIPLES OF SOFTWARE PROCESS CHANGE
The six basic principles of software process change are:
1. Major changes to the software process must start at the top.
2. Everyone must be involved.
3. Effective change requires knowledge of the current process.
4. Change is continuous.
5. Software process changes will not be retained without conscious effort and periodic reinforcement.
6. Software process improvement requires investment.
The key topics to focus on once the decision has been made to invest in process improvement are:
u To improve the software process, someone must work on it!
u Unplanned process improvement is wishful thinking.
u Automation of a poorly defined process will produce poorly defined results.
u Improvements should be make in small, tested steps.
u Train, train, train!
Some common misconceptions about the software process are:
u We must start with firm requirements.
u If it passes test, it must be OK.
u Software quality can’t be measured.
u The problems are technical.
u We need better programmers.
u Software management is different.
3 SOFTWARE PROCESS ASSESSMENT
Assessments are done:
p To learn how the organization actually works
p To identify its major problems
p To enroll its opinion leaders in the change process[3]
Assessments are typically conducted in three phases: preparation, the on-site assessment, and findings and action recommendations.
4 THE INITIAL PROCESS
The Initial Process is a largely chaotic state in which the professionals are driven from crisis to crisis by unplanned priorities and unmanaged chang.
For creative professionals, the most frustrating part of this environment is that the same problems keep repeating. Plans are ad hoc, schedules are arbitrary, design control is nonexistent, and resources are always inadequate.
PART II: THE REPEATABLE PROCESS
5 MANAGING SOFTWARE ORGANIZATIONS
Organizations have line and staff groups with conflicting goals. Line management focuses on getting the product out the door, while the staff is concerned with the organization’s long-term capability.
An effective management system uses reviews and a contention system to resolve product and period conflicts and establish the balance between line and staff.
Each line and staff organization prepares its annual plan and reviews it with all involved parties. Similarly, each project area establishes its own plans, which are reviewed prior to project initiation and then periodically updated and reviewed.
In establishing a project management system, the first essential action is to obtain agreement from the senior management team that such a system is needed. Then:
1) The commitment system is defined.
2) The quarterly review system is established.
3) The phase review system is initiated.
6 THE PROJECT PLANThe project plan provides a definition of each major task, an estimate of the time and resources required, and a framework formanagement review and control. It is developed at the beginning of the job and is successively refined as the work progresses.
With rare exceptions, initial resource estimates and schedules are unacceptable. This is not because the programmers are unresponsive, but because the users generally want more than they can afford. If the job doesn’t fit the available schedule and resources, it must either be pared down or the time and resources increased.
The elements of a software plan are: goals and objectives, a sound conceptual design, Work Breakdown Structure (WBS), product size estimates, resource estimates, and the project schedule. In addition to defining the work, this plan provides management the basis for periodically reviewing and tracking progress against the plan.
7 SOFTWARE CONFIGURATION MANAGEMENT----PART I
The baseline is the official source for code and the repository for all completed work. It is the official standard on which subsequent work is based and to which only authorized changes or aditions are made. The baseline contains all the project code, and each level is uniquely named so it can be distinguished from all others. Procedures are established to maintain control over all code changes.
To implement these controls and procedures, responsibility assignments are made for the configuration manager, module ownership, and the Change Control Board (CCB). The change management system tracks the change requests, problem reports, CCB actions, and activity log entries. Data is recorded on what was done, by whom, when, what remains to be done, any special conditions, and current status.
The system library stores the development work products. This includes the source and object code for every baseline and change, the test cases, and the development tools. It has locks to prevent unauthorized changes and the capability to build the various system configurations, test drivers, and test scenarios or buckets required by development.
8 SOFTWARE QUALITY ASSURANCE
The role of SQA is to assure management that the software development work is performed the way it is supposed to be. Its prime benefit to management is the assurance it provides them that their directions are actually implemented. The SQA organization is not responsible for producing quality products or for making quality plans; these are development jobs. SQA is responsible for auditing the quality actions of the line organization and alerting management to any deviations.
SQA can be effective when they report through an independent chain of command, when they are properly staffed with competent professionals, and when they see their role as supporting the development and maintenance personnel in improving product quality. If SQA fulfills its role, and if senior management refuses to allow line management to commit or to ship products until the SQA issues have been addressed, then SQA can help management improve product quality.
Each development and maintenance project should have a software quality assurance plan that specifies its goals, the SQA tasks to be performed, the standards against which the development work is to be measured, and the procedures and organizational structure to be used.
There are five common reasons why many Software Quality Assurance organizations fail to be effective in improving software quality: they are rarely staffed with sufficiently experienced or knowledgeable people; their management team is not capable of negotiating with development; senior management backs development over SQA on a large percentage of the issues; SQA operates without suitably documented and approved development standads and procedures; and most software development groups do not have verifiable quality plans.
Getting good people into SQA is one of the most difficult problems software managers face. Any reasonable staffing system can work, however, if it has the full backing of senior management --- but no staffing method will work if it does not.
PART III: THE DEFINED PROCESS
9 SOFTWARE STANDARDSA standard is a rule or basis for comparison that is used to assess the size, content, value, or quality of something.
Standards promote the consistent use of better tools and methods, and they support the SQA prople in doing their work. Before establishing an aggressive standards development program, it is wise to formulate an overall plan that considers the available standards, the priority needs of the organization, the status of the projects, the available staff skills, and the means for standards enforcement. The actual work of establishing a standard should be done by individuals or small working group of technical experts.
Standards must be kept current, but standards maintenance should not involve a great deal of work.If a standard needs frequent changes, it probably convers a subject that is not ready for standardization. The standards and procedures should also be reviewed at least once every three to five years to ensure they are current and needed. Statnards enforcement is the basic role of the SQA organization. Automated tools can be most helpful for policing some items, exhaustive reviews are advisable for others, and statistical reviews are used for the balance.
A standard is appropriate when no further judgment is needed. There are also many cases in which standards are totally inappropriate. Typically these are cases involving technical judgment. Clearly it is no wise to establish a standard unless there is convincing evidence that it is always the right thing to do.
10 SOFTWARE INSPECTIONS
The fundamental purpose of inspections is to improve the quality of programs by assisting the software engineers to recongnize and correct their errors. While inspections will not solve all problems, they are enormously effective, and all software organizations should use inspections, walkthroughs, or technical reviews in all major aspects of their work. This includes requirements, design, implementation, test, maintenance, and documentation.
The basic objectives of inspections are to find errors at the earliest possible point in the development cycle, to ensure that the appropriate parties technically agree on the work, to verify that the work meets predefined criteria, to complete formally a technical task, and to provide data on the product and the inspection process.
Inspections have been installed successfully in many organizations with very positive results. Since the effectiveness of inspections depends on the time and effort spent in preparing for and conducting them, however, the way the inspection program is introduced can have an important impact on its effectiveness.
Inspections are an important way to find errors. Not only are they more effective than testing in find many types of problems, but they also find them early in the project when the cost of making the corrections is far less.
Inspections should be a required part of every well-run software process, and they should be used for every software design, every program implementation, and every change make either during original development, in test, or in maintenance.
11 SOFTWARE TESTING
Software testing is the execution of a program to find its faults. We should think of testing like weeding a garden: Individual bugs can be found with test, but more powerful methods are needed for cleaning up the jungle thickets.
A test is an experiment and should be approached as such. A properly disciplined experiment starts with a hypothesis that the experiment is designed to verify or to disprove. Testing hypotheses should concern the types and quantity of defects in the program.
Effective test planning starts with an overall development plan that defines the functions, foles, and methods for all test phases. The conduct of every test is carefully controlled and recorded so it can be reproduced. The test results are then detailed in a test report and retained in a configuration management database along with other key test data.
12 SOFTWARE CONFIGURATION MANAGEMENT--(CONTINUED)
The first step in establishing an SCM system is to development an SCM plan. Project naming conventions are establishied and a family of forms and procedures is provided to ensure that every change is recorded, reviewed, and tracked. The specification is used as a basis for the development work and as a reference for developing the functional, system, and acceptance tests.
During the design phase, SCM maintains control over the design and the rationale for establishing it. As changes are made, the appropriate design documentation is correspondingly updated. Additional SCM facilities are needed to record all code changes. Finally, for large projects and for all projects during the maintenance phase, procedures are needed to handle the development of somultateous versions of the same program. The tools used to design, implement, test, and maintain the software must also be maintained under configuration control.
The purpose of software configuration status accounting is to maintain a continuous record of the status of all baselined items. A software configuration audit is periodically performed to ensure that the SCM practices and procedures are rigorously followed.
13 DEFINING THE SOFTWARE PROCESSEach software organization should establish a process architecture and process models that are tailored to its particular needs. The appropriate steps are: Identify the unique project issues, problems, and success criteria; establish a basic overall project process; and repeat these definitions for each component and program module.
Some guidelines on developing and using a process architecture are: establish objectives, define the basic process architecture, make sure it meets the needs of the projects, and then enforce it as a noverall process framework. Also remember that each project, component, and module is unique and its process should be uniquely determined. Porcess definition standards are also needed. The process models should be changed as the problems change, and all deviations from the standard process must be documented and approved.
Above all, remember that process definitions can be very complex. They should thus be approached with the same care as the design of a large system; start with a prototype and add enhancements as requirements knowledge and development experience are gained.
14 THE SOFTWARE ENGINEERING PROCESS GROUP
Software process improvement often receives little orderly attention. If it is important enough to do, however, someone must be assigned the responsibility and given the resources to make it happen. Until this is done, it will remain a nice thing to do someday, but never today.
The SEPG has two basic tasks that are done simultaneously: initiating and sustaining process change and supporting normal operations. Process change requires the professionals to learn new methods and to accommodate to the changing nature and scale of the problems they encounter. The SEQG supports this learning while also serving as a consolidating force for the changes that have already been made. As a change agent, it provides the skilled resources, the organizational focus, and the management leverage to make things happen.
The SEPG is the focal point for establishing process standards, and it maintains the process database as a permanent repository for the data gathered on the software engineering process and products. In its role as a technology insertion focal point, the SEPG helps coordinate the projects’ technology efforts. At least until a permanent technology group is established. Further SEPG roles concern education, consultation, and awareness of the current state of software practice.
The major risks in establishing an SEPG are that it will not be adequately staffed, that it will receive insufficient management support to do its job, or that the SEPG manager will not be able to obtain the participation and support of the project leaders and software professionals. While SEPG performance can be evaluated with the traditional means for judging support staffs, probably the best meansure is the SEPG’s adherence to the software process maturity framework for their own wok.
