Prof. Upchurch:

This is the latest verson of the SWPI intro page. There aren't any major changes. My idea is to put this page and everything it references onlne. I'm sure all the pages will comprise a 'living' document (ie various sectons will change as necessary). What do you think? 

-Steve

<title>Software Process Improvement</title> <h1>Software Process Improvement - What is it?</h1> 

Computers are being asked to perform tasks which are more and more complex. To accomplish this, the programs they run are necessarily getting more and more complex. Often, one computer is not capable of solving a problem and a system of multiple computers must be used. Examples of these types of systems include the air traffic control network, the computers on board the space shuttle, and various military systems. Successfully designing and building these systems is difficult, and it is the design and development of these types of systems where software process improvement can help the most. The problem of building complex software systems is known very well at the Denver International Airport in Denver, Colorado. This is not the only large software system to have problems, it is just one of the unfortunate few to get more than the average share of publicity. <p>

Software process improvement is the process of improving the "software building process" which is different (though related) to improving the actual software product. In general, the concept of process improvement (for any process) is very simple. Process improvement involves measuring the quality of the process and finding way to improve the process. It also requires keeping track of the mistakes you make and then being smart enough to not make those same mistakes again. In relation to software, it means keeping track of the mistakes made when building software and not making those mistakes again. In order to not make those mistakes again, the software builder may have to change the software building process a little. That's it. There is really nothing difficult in the idea. The difficulty comes when one tries to implement the idea. <p> 

Process improvement involves:<p>
<li>knowing what your <em>current</em> software development process is <li>identifying aspects of the process that can be measured <li>identifying aspects of the product that can be measured <li>identifying measures that collect the data needed (which implies and understanding of the relation between data and process or product)
<li>having a commitment from upstream and downstream people to collect "valid" data
<li>understanding how to use the data
<li>understanding how the data relates to the process <li>having a commitment from upstream and downstream people to effect change based on data <p>

Implementing a software process improvement program is a tough job, there is no doubt about that, but that's not why it hasn't caught on. 

<h2>Why hasn't software process improvement caught on?</h2> 

One reason software process improvement techniques have not caught on can be seen when one tries to implement a software process improvement program. Many organizations (and as a result many people) will discover they need to change the way they think about software design in order to successfully build complex software systems. This is the hardest obstacle to overcome. Also, organizational and social issues must not be overlooked. These include the time designers take doing non-design related issues. Determining things like how much time people spend finding information they need, how much time is spent in meetings, how much time is spent doing administrative duties, are important because these activities are also part of the design process. The article "People, Organizations and Process Improvement" by Perry, Straudenmayer and Votta looks at this issue. <p>

Another obstacle is that many people see software process improvement as "bean counting". It is seen as a waste of time just "gathering metrics and putting up charts". In some cases this assessment may be correct. If information is gathered but is not used to show
<A href="/home/stu3/iacobbo/html/sw_engineering.html">software engineers</A> how the process of building software can be improved, then gathering the information is useless.
Applying what the metrics are telling you is very important. Furthermore, developers and managers need to realize that there are many non-code related measurements that must be included in the overall measurement activities. Data indicates that most of the errors that have a major impact project schedule and budget are introduced in the design/planning stage of the project. These are the problems that are hardest to detect and resolve and often don't even show up until integration. Software process improvement can help stop some of these problems while the project is still in the early stages of development.<p> 

It must be realized that software process improvement techniques are not something that can be implemented overnight. Moving through the phases of software process improvement generally takes months or years. In the end, the benefits of implementing these techniques will be worth the effort. 

<h2>What good comes from a software process improvement program?</h2> 

In order for organizations to want to start a software process improvement program, there have to be some incentives. Generally companies that have such programs are involved in defense related work and the federal government mandates that a such a program (and often an SEI rating of a certain level) is necessary to get certain contracts. Companies that have adopted these techniques are seeing an return on their investment in terms of a better  bottom line. <p>

Exactly how much software process improvement programs will automate the process of building software is a point still open for debate. A less debated point is that most organizations need to apply some type of structure to their software building process. Two articles in the magazine <cite>IEEE Software</cite> under the heading of point-counterpoint disagree on exactly how to establish a software process improvement program, but both agree that structure is needed if an organization is to produce quality software. Martin Thomas of Praxis,Touche-Ross, is a proponent of top-down process improvement. This idea is based on the belief that software engineering has some set of standard practices that are basic to the entire field, much like other fields of engineering have certain standard practices. After evaluating an organization's entire software building process in light of these standard practices and relating it to the goals of the organization, a program can be formed which will change the organization's current process into one that more closely resembles the model and will help the company achieve its desired goals. <p>

Frank McGarry of the NASA Goddard Space Flight Center see things a little differently. He prefers what is sometimes referred to as a bottom-up approach. He does not feel a generic "standard model" should be used but feels that each product an organization produces must be evaluated solely on the basis of the organizational goals for that product.<p> 

We could argue for hours about pros and cons of using a standard model but that's not the point. The point is that most software developers who understand the complexity of developing software realize that some sort of <em>structure</em> is necessary if quality software is to be built consistently.

<h2>How to start on the road to Software Process Improvement</h2> 

The Software Engineering Institute (SEI) at Carnegie Mellon University is a good place to start getting aquainted with Software Process Improvement techniques. The SEI is responsible for defining something called the Capability Maturity Model (CMM). The CMM provides a foundation for building guidelines to establishing software process improvement programs. It must be realized that CMM is <strong>not</strong> the program itself. It is a guide to help organizations build a software process improvement program. <p> 

More information on CMM and other associated products can be received by contacting: <p>

SEI Customer Relations<br>
Software Engineering Institute<br>
Carnegie Mellon University<br>
Pittsburgh, PA USA 15215<br>
(412) 268-5800 (voice - from the USA)<br> Internet: customer-relations@sei.cmu.edu<br><p> 

<h2>In the mean time... </h2>

Even before a software process improvement program gets under way, there are certain techniques that organizations can use to begin to develop better software and to ease the transition into a software process improvement program. <p>

Over the years, many techniques have come and gone, each claiming by its proponents to be the so-called "silver bullet" - the technique that will make building complex software easy (or at least easier). Unfortunately, no technique has proved to be all that it claimed. Fred Brooks wrote an article titled  "No Silver Bullet", which describes the difference between the essential difficulties and the accidental difficulties in software development. <p> 

The essential difficulties describe the complexity of the software. They describe how procedure invocations and data structures in the software must interact. This is an essential difficulty because it is something that is 'part of' the system being built that can't be taken out or simplified without changing the nature of the system. In other words, these difficulties are necessary if you want the program to do certain things. It is these essential difficulties that make large software systems tough to build. <p> 

Accidental difficulties are those aspects of the software building process that can be aided by software development tools and in some cases automated. The act of building (compiling/linking) the software is an accidental difficulty. Code generation can, in some cases, also be considered and accidental difficulty. Configuration management is another example of an accidential difficulty. Brooks identifies some of the more popular software tools and describes why they address only the accidental difficulties of software development. <p> 

He concludes by saying that it is <strong>necessary</strong> to understand the difference between these two types of difficulties. With this understanding, the available development tools/techniques can be better applied to building software.<p>

The techniques Brooks mentions are not intended to be an alternative to a software process improvement program, but adoption of these techniques can ease an organization's transition into a software process improvement program because they begin to add structure to the software development process.<p>