Software Quality Process The Early Days

When the development of PIMS began, few of the people involved with the project had formal computer science training. Most were manufacturing personnel or engineers who could help define production needs but did not yet recognize the need for a software development process specification analogous to a production process specification.

The corporate quality improvement effort at Motorola had been well under way for years, but was only rarely being applied to such soft activities as administrative functions, personnel management, and software. This meant that there were few if any accepted models for developing high-quality software systems. The Motorola Six Sigma Quality program — a statistical approach defining quality goals of fewer than 3.4 introduced errors per million opportunities — was being applied to software in only a few remote areas within Motorola.

Manufacturing improvement efforts undertaken at the time required massive amounts of production data to support measured Six Sigma improvements. Ironically, the subsequent drive for data often caused information systems to be developed rapidly and with little or no control, so that several poor-quality information systems were a legacy of production quality improvement efforts.

Because the full requirements of PIMS were not well understood by the factory users or the developers, the early process life cycle used was essentially a spiral model: the goal was to place some capability out onto the manufacturing floor, exercise it, find the problems, and determine the real requirements, and then reiterate to build on each release. Methods were applied informally (e.g., the "back of the napkin" approach). The development model in use meant that design occurred simultaneously with editing the code. This approach resulted in fast product turnaround and an increased understanding of user needs early in the project, but it also meant that little of the process was documented and plenty of mistakes made their way to the users.

The project was managed essentially on a contract basis — there was little description of specific requirements for product releases, so programmers worked as time and materials were available and the project continued as long as management was satisfied with the progress. Releases occurred often and were not well controlled; access to programs was controlled even less.

In early 1990, Motorola began asking local software contractors to conform to sector and corporate requirements for higher-quality software development. Because PIMS was of a magnitude and importance that it could have significant impact on Motorola manufacturing, requirements were specifically placed on that project. Unfortunately, few experts from IS were available to help guide process improvements. An initial process plan was developed by Sterling and the FMG, which helped to lead the evolution from an informal, ad hoc environment to a more formal process.

About the same time, an initial, informal Software Engineering Institute (SEI) assessment had been made of the FMG CIM Development Group that was overseeing the PIMS project. This assessment indicated many deficiencies in the development processes used both internally and in contracted work. The internal recognition of the need for significant software process improvement was strong, especially for large projects such as PIMS. By then, the factory was depending on the complex PIMS system, which was more than 100,000 lines of code in Tandem COBOL and SQL. (It is now about 250,000 lines excluding libraries.) Quality was critical.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment