Software Process & Improvement

Home > Tech Papers > Software Process & Improvement

Update: Lately I've been reading a lot about Agile methodologies, and have reached the conclusion that they are very appropriate for projects carried out by small teams. This paper was prepared back in 2000, and may still be relevant for some projects.

Software Process & Improvement

Outline

Introduction
Software Process
Software Process Improvement
Specific Software Process Models
Key Components of a Software Process Model
Conclusion
Other Related Links

1. Introduction

The purpose of this document is to bring together various readings and the author's random thoughts in relation to Software development processes and software process improvement.

This is an evolving document, with sections added, removed or changed over time as the author learns more about the subject matter.

Refer to the outline above for a guide to the content and structure.

2. Software Process

2.1 What is a software process?

According to Watt S. Humphrey, a "software process is the sequence of steps required to develop or maintain software. It sets out the technical and management framework for applying methods, tools and people to the software task. The process definition defines roles, specific tasks, establishes measures and provides entry/exit criteria for each step."

2.2 Why have a defined software process?

Software development can be a complex undertaking. Frederick P. Brooks has argued that "software entities are more complex for their size than perhaps any other human construct."

The 1995 Standish Group Chaos study found that for a sample of 8,380 applications, 31.1% of software projects were cancelled and 52.7% were completed over budget and/or late. Only 16.2% of projects were classed as successful - that is, projects completed on-time and on-budget.

The major consequences of "chaotic" software development processes are listed in an article entitled "Customized Process Improvement" (Software Development, March 1999, pp.S1-S8):

success or failure depends on individual skills and experience
developers waste effort on duplication, false starts, and lack of software reuse
learning curves are steep for employees new to a team
as projects ramp up, experienced staff must focus more time on training new staff, or correcting errors caused by new, inadequately trained team members

There are several advantages of having well defined processes (Kellner, cited by W.S. Humphrey, p.5):

they enable effective communication about the process among users, developers, managers, customers, and researchers
they enhance management's understanding, provide a precise basis for process automation, and faciltate personnel mobility
they facilitate process reuse, by defining standard elements
they support process evolution by providing an effective means for process learning and a solid foundation for process improvement
they aid process management, by providing clear plans and a precise, quantified way to measure status against those plans

In addition to these internal benefits, an organisation with well-defined processes is likely to be more efficient, and more capable of demonstrating it has the capability to develop major software projects.

2.3 Assessing Process Maturity

There are several models that can be used to assess the current maturity of an organisation's software process. For example, the Software Engineering Institute (SEI) has developed the Capability Maturity Model (CMM). This model defines five levels of maturity, namely:

Initial
Repeatable
Defined
Managed
Optimizing

The model also establishes priorities or key process areas (KPAs) for improvement.

Other assessment models exist, including SPICE.

The need for improvement is not only advocated by pinheads. In an article entitled "The Commando Returns" (Software Development, March 1999, pp.78-80), a former cowboy coder admits the errors of his ways and argues for the need to have design and code reviews, walkthroughs, metrics and planning.

3. Software Process Improvement

3.1 What is Software Process Improvement?

David Rico defines Software Process Improvement (SPI) as "the discipline of characterizing, defining, measuring, and improving software management and engineering processes, leading to successful software engineering management, higher product quality, greater product innovation, faster cycle times, and lower development costs, simultaneously" (SPI: Impacting the Bottom Line by using Powerful Solutions).

Ian Sommerville (Software Engineering, 5th ed, p. 638) states that "SPI involves understanding existing processes amd changing these processes to improve product quality and/or reduce costs and development time". Sommerville goes on to say that "process improvement does not simply mean adopting particular methods or tools or using some model of a process which has been used elsewhere". Further, "process improvement should always be seen as an activity that is specific to an organization or a part of a larger organization".

3.2 The Process of Software Process Improvement

A generic model of SPI is depicted by Sommerville, Figure 31.1, p.638. The key stages are:

Process analysis
Improvement identification
Process change introduction
Process change training
Change tuning

Ten Steps To Successful Process Improvement are listed in the eponymously-named article.

Customized Process Improvement also provides recommendations.

A key theme throughout is the need to have the support of the entire organisation, from top management down. Adequate training and continuous review are also crucial elements of software process improvement.

4. Specific Software Process Models

4.1 Warning: There's No Silver Bullet

Before examining specific software process models, I think we should be reminded there is no magic solution to the software development puzzle. The notion that Camtech Consulting could just buy the Rational Rose package as a panacea is unrealistic. Fred Brooks stated in his famous article "No Silver Bullet" that there is no single tool that can remove the essential complexity of software development. Instead organisations need to focus on tools and methods which improve the productivity of the development process.

Note that just because a model works for one organisation, that doesn't necessarily mean it will be effective for Camtech. It will probably be necessary to pick-and-choose elements of various models that suit Camtech.

4.2 Capability Maturity Model (CMM)

As stated earlier, the CMM is a qualitative model which allows an organisation to assess the current maturity of it's process. It also identifies key process areas (KPAs) for improvement.

It should be noted that this is mainly a descriptive model, leaving it up to the organisation to work out how to actually go about increasing process maturity. David Rico warns us that used in isolation "the CMM is a journey of infinite and indefinite self discovery".

There are very few organisations which have achieved the highest level. "The Journey to CMM level 5: A Time Line" describes one such organisation's progress to the Holy Grail. The article includes lessons learned during the 7+ years it took to progress from level 1 to level 5.

4.3 Rational Unified Process (RUP)

RUP is a leading practical process model. It is intended for projects with poorly understood requirements, poorly understood architecture and high risk.

It has a high overhead, and requires considerable resources devoted to training and monitoring. Camtech's Electronic Commerce division is using this approach with good results. Also, I've been informed that Rational provide significant support.

Five best practices are identified:

Develop iteratively (incremental development life cycle)
Use component-based architecture
Visually model the product using the Unified Modeling Language (UML)
Verify software quality throughout the life cycle
Control software changes

Rational claim that RUP can help an organisation meet the CMM level 2 and 3 KPAs. More information can be obtained at Rational's website.

4.4 Trillium Process Model

More relevant for telecommunications companies, with a customer focus.

4.5 Quality Improvement Paradigm (QIP)

Developed by the Software Engineering Laboratory.

4.6 IDEAL

Another product of SEI, adopting a more iterative approach. It is based on CMM, and can be applied beyond SPI.

4.7 Project Management Institute's Body of Knowledge

This model focuses exclusively on management processes. Refer downloaded PDF document.

4.8 "Powerful" SPI Models

David Rico has written an interesting article (SPI: Impacting the Bottom Line by using Powerful Solutions) advocating the use of "proven, structured, universal, portable, measurable, and powerful software process solutions". He breaks down SPI models into three categories:

Indefinite SPI Models
Indefinite SPI models are not solutions at all. Indefinite approaches offer tools to novices in a vain attempt to aid in the invention of new solutions. Examples of indefinite SPI models include ISO 9000, Total Quality Management (TQM), the CMM, and Business Process Reengineering
Vertical Process SPI Models
The Vertical Process Strategy has been advocated for many decades in various forms, which involves not the invention of a process, but the exploitation of existing process technology. This approach involves identifying, selecting, and improving but a single software development process, which is believed to positively affect the bottom line. The Software Inspection Process has proved to be powerful enough to improve the bottom line, and even directly lead to achieving CMM Level 5. In fact, the overwhelming majority of successful SPI participants, cite the Software Inspection Process as "the" key to successful SPI.
Vertical Life Cycle SPI Models
The Vertical Life Cycle Strategy, like the Vertical Process Strategy, involves the exploitation of a proven process technology or solution. But, instead of a single process, it involves the use of an entire life cycle. PSP is an example.

5. Key Components of a Software Process Model

This section outlines several key elements that I believe should be part in our software process.

In some cases there should be room for flexibility. For example, the particular lifecycle used should depend on the type of project. Other project-specific decisions include the level of documentation to be prepared, metrics to be gathered and the importance of configuration management. Clear criteria should be put in place to assist project managers.

5.1 Best Practices

The Software Project Manager's Network (SPMN) has identified nine "Principal Best Practices":

Formal Risk Management
Agreement on Interfaces
Formal Inspections
Metric-based Scheduling and Management
Binary Quality Gates at Inch-Pebble Level
Program-wide Visibility of Progress Vs Plan
Defect Tracking Against Quality Targets
Configuration Management
People-aware Management Accountability

Not all of them are relevant to all projects, but they can be used as a guide.

Rational has defined five best practices as part of the RUP (refer section 4.2). I believe all five should be applied to projects where relevant.

5.2 Documentation and Configuration Management

The IEEE has defined several standards relating to Software Engineering. Many of these standards address the CMM's level 2 KPAs. The IEEE has decided not to make the standards available free of charge over the Internet. I have paper copies of the more relevant standards and guidelines.

The use of widely accepted tools such as the Unified Modeling Language (UML) should be investigated.

Not all projects need to be documented to the same degree.

5.3 Software Metrics

Any process improvement activity will require some way of measuring the state of play. "A Software Metrics Primer" (Software Development, July 1999, p.39ff) provides a good introduction.

5.4 Personal Software Process (PSP)

Individual programmers should take responsibility for their software development activities. Humphrey's PSP is a proven quantitative model for improving individuals' software processes. David Rico suggests that PSP is one of the most cost-effective ways of improving organisational software processes. In fact, PSP addresses 12 of the 18 KPAs identified in the CMM.

Training in PSP should be provided to all members of Camtech's Application Development Practice.

5.5 Peopleware

Okay, this isn't formally mentioned in any of the models, but I think it's important. DeMarco and Lister state in their 1987 book, Peopleware: Productive Projects and Teams, that many problems in software development are more sociological than technological in nature. Further, in their Coding War Games experiment, "the top performers' space is quieter, more private, better protected against interruption, and there is more of it".

6. Conclusion

SPI is crucial as Camtech attempts to take on and deliver larger projects. The lack of well defined software processes can be very costly.

Support from all staff, especially top management, is a prerequisite for any serious SPI initiative.

As a great philosopher once said, "It won't happen overnight, but it will happen".