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
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.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):
There are several advantages of having well defined processes (Kellner, cited by W.S. Humphrey, p.5):
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:
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.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:
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.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 its 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:
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.
More relevant for telecommunications companies, with a customer focus.
4.5 Quality Improvement Paradigm (QIP)
Developed by the Software Engineering Laboratory.
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:
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":
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.
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".
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".
7.2 Online Publications and Articles
7.3 Links Pages
Author: Bruno Andrighetto