THE MANAGEMENT SPECTRUM Effective software project management focuses on the four P’s: people, product,
3.1 THE MANAGEMENT SPECTRUM Effective software project management focuses on the four P’s: people, product,
process, and project. The order is not arbitrary. The manager who forgets that soft- ware engineering work is an intensely human endeavor will never have success in project management. A manager who fails to encourage comprehensive customer communication early in the evolution of a project risks building an elegant solution for the wrong problem. The manager who pays little attention to the process runs the risk of inserting competent technical methods and tools into a vacuum. The manager who embarks without a solid project plan jeopardizes the success of the product.
3.1.1 The People
The cultivation of motivated, highly skilled software people has been discussed since the 1960s (e.g., [COU80], [WIT94], [DEM98]). In fact, the “people factor” is so impor- tant that the Software Engineering Institute has developed a people management capa- bility maturity model (PM-CMM), “to enhance the readiness of software organizations
“There exists to undertake increasingly complex applications by helping to attract, grow, motivate, enormous variability
deploy, and retain the talent needed to improve their software development capabil- in the ability of
different people to ity” [CUR94]. perform
The people management maturity model defines the following key practice areas programming
for software people: recruiting, selection, performance management, training, com- tasks.”
pensation, career development, organization and work design, and team/culture
Bill Curtis
development. Organizations that achieve high levels of maturity in the people man- agement area have a higher likelihood of implementing effective software engineer- ing practices.
The PM-CMM is a companion to the software capability maturity model (Chap- ter 2) that guides organizations in the creation of a mature software process. Issues
CHAPTER 3
PROJECT MANAGEMENT CONCEPTS
associated with people management and structure for software projects are consid- ered later in this chapter.
3.1.2 The Product
XRef
Before a project can be planned, product 1 objectives and scope should be established,
A taxonomy of alternative solutions should be considered, and technical and management con- application areas that
straints should be identified. Without this information, it is impossible to define rea- spawn software
“products” is discussed sonable (and accurate) estimates of the cost, an effective assessment of risk, a realistic
in Chapter 1. breakdown of project tasks, or a manageable project schedule that provides a mean- ingful indication of progress.
The software developer and customer must meet to define product objectives and scope. In many cases, this activity begins as part of the system engineering or busi- ness process engineering (Chapter 10) and continues as the first step in software requirements analysis (Chapter 11). Objectives identify the overall goals for the prod- uct (from the customer’s point of view) without considering how these goals will be achieved. Scope identifies the primary data, functions and behaviors that character- ize the product, and more important, attempts to bound these characteristics in a quantitative manner.
Once the product objectives and scope are understood, alternative solutions are considered. Although very little detail is discussed, the alternatives enable managers and practitioners to select a "best" approach, given the constraints imposed by deliv- ery deadlines, budgetary restrictions, personnel availability, technical interfaces, and myriad other factors.
3.1.3 The Process
A software process (Chapter 2) provides the framework from which a comprehen- sive plan for software development can be established. A small number of frame- work activities are applicable to all software projects, regardless of their size or
Framework activities complexity. A number of different task sets—tasks, milestones, work products, and are populated with
quality assurance points—enable the framework activities to be adapted to the char- tasks, milestones,
acteristics of the software project and the requirements of the project team. Finally, work products, and
umbrella activities—such as software quality assurance, software configuration man- quality assurance
points. agement, and measurement—overlay the process model. Umbrella activities are inde- pendent of any one framework activity and occur throughout the process.
3.1.4 The Project
We conduct planned and controlled software projects for one primary reason—it is the only known way to manage complexity. And yet, we still struggle. In 1998, indus- try data indicated that 26 percent of software projects failed outright and 46 percent experienced cost and schedule overruns [REE99]. Although the success rate for
1 In this context, the term product is used to encompass any software that is to be built at the request of others. It includes not only software products but also computer-based systems, embedded software, and problem-solving software (e.g., programs for engineering/scientific prob- lem solving).
58 PA R T T W O M A N A G I N G S O F T WA R E P R O J E C T S
software projects has improved somewhat, our project failure rate remains higher than it should be. 2
In order to avoid project failure, a software project manager and the software engi- neers who build the product must avoid a set of common warning signs, understand the critical success factors that lead to good project management, and develop a com- monsense approach for planning, monitoring and controlling the project. Each of these issues is discussed in Section 3.5 and in the chapters that follow.
Parts
» The Concurrent Development Model
» SUMMARY Software engineering is a discipline that integrates process, methods, and tools for
» PEOPLE In a study published by the IEEE [CUR88], the engineering vice presidents of three
» THE PROCESS The generic phases that characterize the software process—definition, development,
» THE PROJECT In order to manage a successful software project, we must understand what can go
» METRICS IN THE PROCESS AND PROJECT DOMAINS
» Extended Function Point Metrics
» METRICS FOR SOFTWARE QUALITY
» INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
» METRICS FOR SMALL ORGANIZATIONS
» ESTABLISHING A SOFTWARE METRICS PROGRAM
» Obtaining Information Necessary for Scope
» An Example of LOC-Based Estimation
» QUALITY CONCEPTS 1 It has been said that no two snowflakes are alike. Certainly when we watch snow
» SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the
» R diagram 1.4 <part-of> data model; data model <part-of> design specification;
» SYSTEM MODELING Every computer-based system can be modeled as an information transform using an
» Facilitated Application Specification Techniques
» Data Objects, Attributes, and Relationships
» Entity/Relationship Diagrams
» Hatley and Pirbhai Extensions
» Creating an Entity/Relationship Diagram
» SUMMARY Design is the technical kernel of software engineering. During design, progressive
» Data Modeling, Data Structures, Databases, and the Data Warehouse
» Data Design at the Component Level
» A Brief Taxonomy of Styles and Patterns
» Quantitative Guidance for Architectural Design
» Isolate the transform center by specifying incoming and outgoing
» SUMMARY Software architecture provides a holistic view of the system to be built. It depicts the
» The User Interface Design Process
» Defining Interface Objects and Actions
» D E S I G N E VA L U AT I O N
» Testing for Real-Time Systems
» Organizing for Software Testing
» Criteria for Completion of Testing
» The Transition to a Quantitative View
» The Attributes of Effective Software Metrics
» Architectural Design Metrics
» Component-Level Design Metrics
» SUMMARY Software metrics provide a quantitative way to assess the quality of internal product
» Encapsulation, Inheritance, and Polymorphism
» Identifying Classes and Objects
» The Common Process Framework for OO
» OO Project Metrics and Estimation
» Event Identification with Use-Cases
» SUMMARY Object-oriented analysis methods enable a software engineer to model a problem by
» Partitioning the Analysis Model
» Designing Algorithms and Data Structures
» Program Components and Interfaces
» SUMMARY Object-oriented design translates the OOA model of the real world into an
» Testing Surface Structure and Deep Structure
» Deficiencies of Less Formal Approaches 1
» What Makes Cleanroom Different?
» Design Refinement and Verification
» SUMMARY Cleanroom software engineering is a formal approach to software development that
» Structural Modeling and Structure Points
» Describing Reusable Components
» SUMMARY Component-based software engineering offers inherent benefits in software quality,
» Guidelines for Distributing Application Subsystems
» Middleware and Object Request Broker Architectures
» An Overview of a Design Approach
» Consider expert Web developer will create a complete design, but time and cost can be appropriate
» A Software Reengineering Process Model
» Reverse Engineering to Understand Data
» Forward Engineering for Client/Server Architectures
» SUMMARY Reengineering occurs at two different levels of abstraction. At the business level,
Show more