The Project Manager's Guide to Software Engineering's Best Practices / Edition 1

by Mark Christensen, Richard H. Thayer

Overview

Since the earliest days of the computer industry, managing a software project has been a complex and demanding activity. While the technical content of software products and the technical methods used to build them have changed over time, the fundamental issues that determine the success or failure of software projects have remain fairly constant. That is, the same fundamental management mistakes continue to be made. To cite a few examples; requirements are unclear at the beginning of projects and are not managed during the project, the product is not tested adequately, schedules are misestimated or not tracked in sufficient detail. The contents of this book, together with the underlying IEEE Standards, are dedicated to helping the reader in their work: The continuing quest to produce quality software products in a predictable manner.

This book, containing all original material, is based on the proposition that the IEEE Software Engineering Standards capture many of the fundamental 'best practices' of software project management. It is written to assist the reader in applying those standards to their projects and company. To meet this goal, the authors discuss and elaborate the standards that bear on the three key management areas of: Software systems engineering, Processes for developing software products, Planning and control of software project activities.

The body of the book is correspondingly organized into three parts. Software Systems Engineering, which argues that software development projects are most successful when developed using a systems level viewpoint. Process Management and Control, which describes the key activities needed to define, support, and manage a project's software development processes. Project Planning and Management completes the book, integrating the elements of cost and schedule estimation and control, risk management, and the role metrics play in performing those tasks.

Product Details

ISBN-13:	9780769511993
Publisher:	Wiley
Publication date:	05/11/2002
Series:	Practitioners , #22
Pages:	552
Product dimensions:	6.81(w) x 10.06(h) x 1.07(d)

About the Author

Mark J. Christensen, Ph.D., is an independent consultant based in St. Charles, Illinois, USA. Dr. Christensen serves a national client base, offering process and project evaluation services, and project management training. His customers include industrial, governmental, and academic organizations.
Dr. Christensen is a member of the Association for Computing Machinery (ACM) and the IEEE Computer Society (IEEE CS). He chairs the Press Operations Committee of the Computer Society. He is co-author with Dr. Richard Thayer of an upcoming book (1st Quarter 2002) describing how to apply the IEEE Software Engineering Standards to the Management of software projects.
He holds a BS degree in physics and mathematics from Wayne State University and an MS in physics from Purdue, where he was a Woodrow Wilson Fellow. His doctorate from Wayne State is in probability theory.

Richard H. Thayer, Ph.D., is consultant in the field of software engineering and project management. Prior to this hew was a Professor of Software Engineering at California State University, Sacramento, California, United States of America. Dr. Thayer travels widely where he consults and lectures on software engineering, project management, software engineering standards, software requirements engineering, and software quality assurance. He is a Visiting Researcher and Lecturer at the University of Strathclyde, Glasgow, Scotland. His technical interests lay in software project management and software engineering standards.
Dr. Thayer is a Fellow of the IEEE, a member of the IEEE Computer Society, and the IEEE Software Engineering Standards Committee. He is a principle author for a Standard for a Concept of Operations (ConOps) document (IEEE std 1362-1998) and a principle author of the Standard for Software project Management Plans (IEEE std 1058-1998).
He is also an Associate Fellow of the American Institute of Aeronautics and Astronautics (AIAA) where he served on the AIAA Technical Committee on Computer Systems, and he is a member of the Association for Computing Machinery (ACM). He is also a registered professional engineer.
He holds a BSEE degree and an MS degree from the University of Illinois at Urbana (1962) and a Ph.D. from the University of California at Santa Barbara (1979) each in Electrical Engineering.

Read an Excerpt

The Project Manager's Guide to Software Engineering's Best Practices

---

By Mark Christensen Richard H. Thayer

John Wiley & Sons

ISBN: 0-7695-1199-6

---

Chapter One

Software Systems Engineering

1.1 Introduction

This chapter describes the application of systems engineering principles to the development of a computer software system. The activities, tasks, and procedures that make up these principles are known as software systems engineering (SwSE). The purpose of this chapter is to identify SwSE processes and tools, describe them, and reflect on their contribution to the software development process.

Systems have become larger and more complex than ever before. The hardware and software that makes up those systems have, correspondingly, grown in capacity and complexity at nearly an exponential rate. In some cases, the physical and logical boundaries of systems are no longer clear-cut (witness the increasing interdependencies of internet-based systems), and other classes of systems having clear boundaries are growing in their complexity as well (witness the increasing functionality and integration of modern aircraft and automotive systems). The workstation sitting on virtually everyone's desk or the wireless device in their pockets reflects this trend: Microsoft Word has grown in size from a product that would fit on a 360-Kbyte diskette to a product that will only fit on a 600-Mbyte CD, and desktop operating systems have grown from requiring a few tens of thousands of bytes of memory to well over 8 million.

Hardware capacity has grown to the point where the size and capability of a software program are no longer determined by the capabilities of the computing platforms. Likewise, efficiency of implementation no longer ranks among the primary design goals for most development projects. This has fueled demand for larger and larger systems, of which the software is often the most critical component. The trend is, and will continue to be for some time, to develop extremely large and complex software systems.

The majority of these large software systems are not delivered on the desired date for the expected cost. All too often, when they are delivered, they do not completely satisfy the customer's desires or the producer's promises. This phenomenon, when combined with the shortage of adequately skilled software engineers, has come to be regarded as the "software crisis" [Gibbs l994, Royce 1991]. In response to this so-called crisis, engineering practices have been increasingly introduced into software development efforts. Some of these practices are straightforward adaptations of engineering practices that have been used to develop nonsoftware products for some time, whereas others are more novel.

As these practices are applied during the development of a product, it is not sufficient to simply mechanically track project status. Monitoring the resources used, the schedules met, or the milestones accomplished will not provide sufficient feedback as to the health of the project. The technical processes and products must be actively managed. Systems engineering provides the tools needed to perform the technical management of systems under development.

Engineering practices applied to software products consist primarily of (1) processes for the systematic development of the software elements of the system and (2) representation methods and tools, used to describe the products and their attributes. Examples include the following:

Life cycle development processes-These divide the project into phases.

Managing software as a distinct and separate element of a project-Ensures that adequate support and oversight are applied to the effort.

Use of intermediate products (specifications and descriptions)- Takes advantage of, for example, requirements specifications and design descriptions.

Software-specific analysis, representation methods, and design tools-Makes use of, for example, structured and object-oriented techniques.

Reviews and audits-Used to provide visibility to the ongoing development activities and their products.

Verification, validation, and testing-Confirms that the products of the development effort conform to their requirements.

Configuration management and quality assurance-Provides confidence that the developmental activities are being conducted as planned and that the results are available and reproducible.

Prototyping-Explores requirements, evaluates alternative approaches, and determines the feasibility of proposed solutions.

Use of off-the-shelf components-Leverages existing technologies and improves interoperability with other products used in the application domain.

This chapter is not based on any single IEEE software engineering standard but instead is derived from a collection of standards that support software systems engineering. This chapter also supports IEEE Standard 1220-1998, IEEE Standard for the Application and Management of the Systems Engineering Process, and IEEE Standard 1233-1998, IEEE Guide for Developing System Requirements Specifications.

1.2 Objectives

In this chapter you will learn:

How the software systems engineering process is used to manage the technical effort of a project.

How software systems engineering affects all phases of the development life cycle.

The relationship between product systems engineering and software systems engineering.

The relationship between software systems engineering and project management.

The activities that make up software systems engineering.

The role of software systems engineering in the software requirements analysis process.

The role of software systems engineering in the software design process.

The activities of software systems engineering that support the planning of the project.

The activities of software systems engineering that support control of the project.

How software systems engineering supports verification, validation, and testing.

1.3 Systems Engineering Concepts

1.3.1 Overview of Systems

Before describing the processes and methods that make up systems engineering, the term system should be defined. The IEEE standards define a system as:

A collection of components organized to accomplish a specific function or set of functions. [IEEE Standard 610.12-1990]

Equivalently, a system is a collection of related or associated entities that together accomplish of one or more specific objectives. The key words are related, together, and specific objectives. A mere assemblage of isolated entities or elements with no common objective would not be a system. They might, instead be parts of other systems or completely autonomous items. This concept is illustrated in Figure 1.1.

A man-made system is a collection of hardware, software, people, facilities, procedures, and other factors organized to accomplish a common objective. A software system is, therefore, a man-made system or subsystem made up of a collection of programs and documents that together accomplish some specific requirements. Thus, one software system may operate entirely on a conventional desktop or data processing environment, whereas another might in fact be a subsystem of a larger system composed of sensors, mechanical and optical devices, and computers.

1.3.2 Systems Engineering

Systems engineering (SE) is the practical application of the scientific, engineering, and management skills required to transform a user's need into a description of a system configuration that best satisfies that need in an effective and efficient way. The products of SE activities are largely documents, not physical artifacts. The single product that is not a document is the final system itself. The document products are used to ensure that the system is developed in an orderly, technically sound manner and is acceptable to the customer. Examples of such documents include these:

The top-level architecture of the system, identifying its topology, its subsystems, and their interactions;

Specifications for the system and its subsystems;

The logistical and maintenance concepts needed to sustain the system;

Trade studies and analyses used to select between different design and implementation approaches for the system and subsystems;

Evaluations of intermediate products of the subsequent development activities;

Integration of the subsystems to form a whole;

System-level test plans, execution of those tests (which results in the final system), and reports of actual performance;

Assessments and interpretation of technical anomalies uncovered as the project evolves; and

Technical oversight of the various suppliers, both internal and external, producing subsystems, or components that will be integrated into the product.

According to H. C. Alberts [Alberts 1988], a professor at the Defense System Management College in Fort Belvoir, Virginia, who teaches SE, the term SE was first proposed in 1956 by H. Hitch, chairman of the Aeronautical Engineering Department at Penn State University. Based on experience gained during the Second World War while developing large, complex systems, such as high-altitude bombers, surface ships, submarines, tanks, and their attendant manufacturing and support systems, Hitch was trying to develop an engineering discipline that could concentrate on the development of large systems that used many diverse engineering disciplines to develop a system with an expected long life. In 1961 the first formal educational program in systems engineering was established at the University of Arizona, followed by a select group of other universities. These principles were first systematically applied to large systems developments in the 1960s and 1970s, such as the Apollo moon program [Chapman et al. 1992] and the USAF/USN Ballistic Missile Program [Dorfman 2001].

Systems engineering provides the overall technical management of a system development project. IEEE Standard 1220-1998 defines the environment and processes that comprise systems engineering. A variety of definitions can be given for systems engineering, all of which contain the same essential features:

Systems engineering is the management function that controls the total system development effort for the purpose of achieving an optimum balance of all system elements. It is a process that transforms an operational need into a description of system parameters and integrates those parameters to optimize the overall system effectiveness. [DSMC 1989]

The systems engineering process is the integrated sequence of activities and decisions that transforms a defined need into an operational, life-cycle-optimized system that achieves an integrated and optimal balance of its components. [USAF 1985]

The principle top-level function of systems engineering is to ensure that the system satisfies its requirements throughout its life cycle. Everything else follows from this function. [Wymore 1993]

Thus, SE is a generic problem-solving process that provides mechanisms for defining, describing, and evolving both the product and the processes needed to build the product. This process should be applied throughout the system life cycle to all activities associated with product development, verification/test, manufacturing, training, operation and use, support, distribution, and disposal [IEEE 1220-1998].

Systems engineering defines the plan to be followed in managing a project's technical activities. It identifies the system life cycle model for the project, along with the necessary processes. Likewise, systems engineering defines the environment or framework within which those processes will operate, together with the interfaces between them, the products, and the approach used to manage risk throughout the development of the project. Finally, systems engineering produces the technical baseline for all development, both software and hardware. The requirements specified for the system must be divided into those allocated to the software subsystem and those allocated to the hardware subsystem (or both or neither). Based on the requirements allocated to each subsystem it must be designed, implemented, and tested using the applicable software and hardware engineering processes and, ultimately, integrated with the other subsystems to create the system.

The emphasis of the systems engineering effort for a given project is determined by the nature of the product and what phase of the product life cycle is currently ongoing. Thus the generic systems engineering effort would be intense in the early stages of the product development life cycle as the concept of operations document, system architecture, software requirements specification, hardware requirements specification, and draft acceptance test plans were being first created. Concurrently the maintenance and support concepts would be elaborated. As the hardware and software items are actually being designed and implemented, the systems engineering effort would consist primarily of the verification and validation that the items being produced will satisfy their intended requirements and use. Later, as the items are integrated, the systems effort would be dominated by the integration of the items and, ultimately, by the system-level testing that will lead to acceptance.

Figure 1.2 presents a conceptual view of the relative systems engineering effort applied during a typical program.

1.3.3 Functions of Systems Engineering

Systems engineering includes the following functions:

Problem definition-Determine the product expectations, needs, and constraints by collecting and analyzing requirements. Work closely with the customer to establish the operational needs,

Solution analysis-Determine what options exist to satisfy the requirements and constraints; study and analyze the possible solutions. Select the optimum one, balancing immediate needs, implementation options, long-term suitability, and operational utility.

Process planning-Determine the major technical tasks to be accomplished, the effort required to perform those tasks, the priority of tasks, and the potential risks to the project.

Process control-Determine the methods for controlling the technical activities of the project and the process, measure progress, review intermediate products, and take corrective action when necessary.

Product evaluation-Determine the quality and quantity of delivered products through evaluations consisting of, but not limited to, testing, demonstration, analysis, examination, and inspection.

At this point it is important to distinguish between systems engineering and project management. First, systems engineering is fundamentally a capability that an organization does or does not possess. It may or may not be a specific, identifiable entity within a company. Depending on the product being developed there may or may not be a group with the term "Systems Engineering" in its title. Likewise, for a particular project, there may or may not be someone with the title "project system engineer." The functions listed above are often performed by a combination of the system architect, the lead designer, and the process architect.

This is not the case with project management: Every project should have someone with the title "project manager" or "software engineering project manager" whose primary functions are described in Chapter 12. Some of the functions listed above also appear on the list of tasks to be performed by software engineering project management. This is especially true for those functions associated with process planning and control. The distinction is that project management is concerned with the process planning (e.g., scheduling) and control for all of the activities of the project, whereas systems engineering is concerned with the technical activities of the product development and sustainment. In this sense systems engineering is an agent of project management in this area of activity. However, systems engineering is primarily concerned with the methods that will be applied to accomplishing those tasks. In that sense systems engineering goes beyond the traditional concerns of project management.

(Continues...)

---

Excerpted from The Project Manager's Guide to Software Engineering's Best Practices by Mark Christensen Richard H. Thayer Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

---

Table of Contents

Foreword.

Preface.

Acknowledgements.

Reviewers.

I: Software Systems Engineering.

1. Software Systems Engineering.

2. Concept of Operations.

3. Software Requirements Specification.

4. Software User Documentation.

5. Software Verification and Validation.

6. Software Maintenance.

II: Process Management and Control.

7. Software Life Cycle Process Management.

8. Software Process Improvement.

9. Software Configuration Management.

10. Software Quality Assurance.

11. Software Reviews.

III: Project Planning and Management.

12. Software Cost and Schedule.

13. Software Engineering Project Management.

14. Software Risk Management.

15. Software Metrics.

A. The Work Breakdown Structure.

B. Representing Project Schedules.

Index.

About the Authors.