Running head: TYPE ABBREVIATED TITLE HERE
Title of the Paper in Full Goes Here
Student Name Here
Strayer University
Dr. Richard Brown
April 15, 2014
1
TYPE ABBREVIATED TITLE HERE
2
Abstract
This is the abstract, which is typed in block format with no indentation. It is a brief summation of
your paper and should be 120 words or less. It should be accurate and concise. Your abstract
should also be written in a self-contained way so people reading only your abstract would fully
understand the content and the implications of your paper. It may be helpful to write this section
last when you have collected all the information in your paper. See section 2.04 APA for helpful
tips and for more information on writing abstracts.
TYPE ABBREVIATED TITLE HERE
3
Title of the Paper
Do not add any extra spaces between your heading and your text (check Spacing under
Format, Paragraph in your word processor, and make sure that it’s set to 0”)—just double space
as usual, indent your work a full ½ inch (preferably using the tab button), and start typing. Your
introduction should receive no specific heading because it is assumed that your first section is
your introduction section.
Once you’ve considered these formatting issues, you will need to construct a thesis
statement, something that lets your reader know how you synthesized the literature into a treatise
that is capable of advancing a new point of view. This statement will then provide your reader
with a lens for understanding the forthcoming research you’ve decided to present in the body of
your essay (after all, each piece of literature should support and be made applicable to this thesis
statement).
Once you’ve established your thesis, you can then begin constructing your introduction.
An easy template is as follows:
1. Start with what’s been said/done regarding your topic of interest.
2. Explain the problem with what’s been said or done.
3. Offer your solution, your thesis statement (one that can be supported by the literature).
4. Explain how your thesis brings about social change.
Level 1 Heading
TYPE ABBREVIATED TITLE HERE
4
This will be the beginning of the body of your essay. Even though it has a new heading,
you want to make sure you connect this to your previous section so your reader can follow you
and better understand your hard work. Remember to make sure your first sentence in each
paragraph both transitions from your previous paragraph and summarizes the main point in your
paragraph. Stick to one topic per paragraph, and when you see yourself drifting to another idea,
make sure you break into a new paragraph. Try to avoid long paragraphs to avoid losing your
reader and to hold his or her attention--it’s much better to have many shorter paragraphs than few
long ones. Think: new idea, new paragraph.
Another Level 1 Heading
Here’s another Level 1 heading. Again, the topic sentence of this section should explain
how this is related or a result of what’s been discussed in the previous section. You’ll also want
to consider using transitions between your sentences as well. Below are a few examples of how
to transition from one statement to another (or in some cases, one piece of literature to another):
1. Many music teachers at Olson Junior High are concerned about losing their jobs (J.
Thompson, personal communication, July 3, 2004). This is not surprising considering the state’s
recent financial cutbacks of fine arts programs (Pennsylvania Educational System, 2004).
2. Obesity affects as much as 17% of the total population of children (Johnson &
Hammer, 2003). This increase of obesity leads to other chronic health problems, some short term
and some long term (Christianson, 2004).
For more examples, see some of our transitions handouts on our website.
Level 2 Heading
TYPE ABBREVIATED TITLE HERE
5
The Level 2 heading here implies that we are in a subsection of the previous section.
Using headings are a great way to organize your paper and increase its readability, so be sure to
review heading rules on APA 3.02 and 3.03 in order to format them correctly. For shorter papers,
using one or two levels is all that is needed. You would use Level 1 (centered, bold font with
both uppercase and lowercase) and Level 2 (left aligned, bold, both uppercase and lowercase).
Level 3 heading. The number of headings you need in a particular paper is not set, but
for longer papers, you may need another heading level. You would then use Level 3 (indented,
bold, lowercase paragraph heading).
One crucial area in APA is learning how to cite in your academic work. You really want
to make sure you cite your work throughout your paper to avoid plagiarism. This is critical: you
need to give credit to your sources and avoid copying other’s work at all costs. Look at APA
starting at 6.01 for guidelines on citing your work in your text.
Level 1 Heading
APA can seem a bit tricky to master, but it’s really fairly straightforward once you get the
hang of it. There are also plenty of sources to help you—don’t be afraid to ask!
And so forth until the conclusion…..
Level 1 Heading
Your conclusion section should recap the major points you have made in your work.
However, perhaps more importantly, it should also interpret what you have written and what it
means in the bigger picture. In your concluding remarks, think big! Some questions to ask
yourself include: What do you want to happen with the information you’ve provided? What do
TYPE ABBREVIATED TITLE HERE
6
you want to change? What is your ultimate goal in using this information? What would it mean if
the suggestions in your paper were taken and used?
TYPE ABBREVIATED TITLE HERE
7
References
(Please note that the following references should NOT appear in your paper)
Alexander, G., & Bonaparte, N. (2008). My way or the highway that I built. Ancient Dictators,
25(7), 14-31. doi:10.8220/CTCE.52.1.23-91
Babar, E. (2007). The art of being a French elephant. Adventurous Cartoon Animals, 19, 43194392. Retrieved from http://www.elephants104.ace.org
Bumstead, D. (2009). The essentials: Sandwiches and sleep. Journals of Famous Loafers, 5, 565582. doi:12.2847/CEDG.39.2.51-71
Hansel, G., & Gretel, D. (1973). Candied houses and unfriendly occupants. Thousand Oaks, CA:
Fairy Tale Publishing.
Hera, J. (2008). Why Paris was wrong. Journal of Greek Goddess Sore Spots, 20(4), 19-21.
Laureate, Education, Inc. (Producer). (2007). How to cite a video: The city is always Baltimore
[DVD]. Baltimore, MD: Author.
Sinatra, F. (2008). Zing! Went the strings of my heart. Making Good Songs Great, 18(3), 31-32.
Retrieved from http:///articlesextollingrecordingsofyore.192/fs.com
Smasfaldi, H., Wareumph, I., Aeoli, Q., Rickies, F., Furoush, P., Aaegrade, V., … Fiiel, B.
(2005). The art of correcting surname mispronunciation. New York, NY: Supportive
Publisher Press. Retrieved from
http://www.onewaytociteelectronicbooksperAPA7.02.com
TYPE ABBREVIATED TITLE HERE
White, S., & Red, R. (2001). Stop and smell the what now? Floral arranging for beginners
(Research Report No. 40-921). Retrieved from University of Wooded Glen, Center for
Aesthetic Improvements in Fairy Tales website: http://www.uwg.caift/~40_921.pdf
8
www.it-ebooks.info
MANAGING AND
LEADING SOFTWARE
PROJECTS
www.it-ebooks.info
Press Operating Committee
Chair
Linda Shafer
former Director, Software Quality Institute
The University of Texas at Austin
Editor-in-Chief
Alan Clements
Professor
University of Teesside
Board Members
David Anderson, Principal Lecturer, University of Portsmouth
Mark J. Christensen, Independent Consultant
James Conrad, Associate Professor, UNC Charlotte
Michael G. Hinchey, Director, Software Engineering Laboratory, NASA Goddard Space Flight Center
Phillip Laplante, Associate Professor, Software Engineering, Penn State University
Richard Thayer, Professor Emeritus, California State University, Sacramento
Donald F. Shafer, Chief Technology Officer, Athens Group, Inc.
Evan Butterfield, Director of Products and Services
Kate Guillemette, Product Development Editor, CS Press
IEEE Computer Society Publications
The world-renowned IEEE Computer Society publishes, promotes, and distributes a wide variety of
authoritative computer science and engineering texts. These books are available from most retail
outlets. Visit the CS Store at http://computer.org/cspress for a list of products.
IEEE Computer Society / Wiley Partnership
The IEEE Computer Society and Wiley partnership allows the CS Press authored book program to
produce a number of exciting new titles in areas of computer science, computing and networking
with a special focus on software engineering. IEEE Computer Society members continue to receive
a 15% discount on these titles when purchased through Wiley or at wiley.com/ieeecs
To submit questions about the program or send proposals please e-mail kguillemette@computer.org
or write to Books, IEEE Computer Society, 10662 Los Vaqueros Circle, Los Alamitos, CA 90720-1314.
Telephone +1-714-821-8380. Additional information regarding the Computer Society authored book
program can also be accessed from our web site at http://computer.org/cspress.
www.it-ebooks.info
MANAGING AND
LEADING SOFTWARE
PROJECTS
RICHARD E. (DICK) FAIRLEY
A JOHN WILEY & SONS, INC., PUBLICATION
www.it-ebooks.info
Copyright © 2009 by IEEE Computer Society. All rights reserved.
Published by John Wiley & Sons, Inc., Hoboken, New Jersey.
Published simultaneously in Canada.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form
or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as
permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior
written permission of the Publisher, or authorization through payment of the appropriate per-copy fee
to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax
(978) 750-4470, or on the web at www.copyright.com. Requests to the Publisher for permission should
be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ
07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permission.
Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts
in preparing this book, they make no representations or warranties with respect to the accuracy or
completeness of the contents of this book and specifically disclaim any implied warranties of
merchantability or fitness for a particular purpose. No warranty may be created or extended by sales
representatives or written sales materials. The advice and strategies contained herein may not be
suitable for your situation. You should consult with a professional where appropriate. Neither the
publisher nor author shall be liable for any loss of profit or any other commercial damages, including
but not limited to special, incidental, consequential, or other damages.
For general information on our other products and services please contact our Customer Care
Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or
fax (317) 572-4002.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print
may not be available in electronic formats. For more information about Wiley products, visit our web
site at www.wiley.com.
Library of Congress Cataloging-in-Publication Data is available.
ISBN: 978-0-470-29455-0
Printed in the United States of America.
10 9 8 7 6 5 4 3 2 1
www.it-ebooks.info
CONTENTS
Preface
1
xv
Introduction
1
1.1
1.2
1.3
Introduction to Software Project Management, 1
Objectives of This Chapter, 2
Why Managing and Leading Software Projects Is
Difficult, 2
1.3.1
Software Complexity, 3
1.3.2
Software Conformity, 4
1.3.3
Software Changeability, 4
1.3.4
Software Invisibility, 5
1.3.5
Team-Oriented, Intellect-Intensive Work, 6
1.4
The Nature of Project Constraints, 9
1.5
A Workflow Model for Managing Software Projects, 13
1.6
Organizational Structures for Software Projects, 16
1.6.1
Functional Structures, 16
1.6.2
Project Structures, 17
1.6.3
Matrix Structures, 17
1.6.4
Hybrid Structures, 18
1.7
Organizing the Project Team, 19
1.7.1
The System Engineering Team, 19
1.7.2
The Software Engineering Team, 20
1.8
Maintaining the Project Vision and the Product Vision, 21
1.9
Frameworks, Standards, and Guidelines, 22
1.10 Key Points of Chapter 1, 23
1.11 Overview of the Text, 23
References, 24
Exercises, 25
v
www.it-ebooks.info
vi
CONTENTS
Appendix 1A:
2
Frameworks, Standards, and Guidelines for Managing
Software Projects, 28
1A.1 The CMMI-DEV-v1.2 Process
Framework, 28
1A.2 ISO/IEC and IEEE/EIA Standards 12207, 34
1A.3 IEEE/EIA Standard 1058, 36
1A.4 The PMI Body of Knowledge, 37
Process Models for Software Development
2.1
2.2
2.3
Introduction to Process Models, 39
Objectives of This Chapter, 42
A Development-Process Framework, 42
2.3.1
Users, Customers, and Acquirers, 43
2.3.2
System Requirements and System Design, 46
2.3.3
Software Requirements, Architecture,
and Implementation, 47
2.3.4
Verification and Validation, 50
2.4
Tailoring the System Engineering Framework for
Software-Only Projects, 52
2.5
Traditional Software Development Process Models, 54
2.5.1
Hacking, 54
2.5.2
Requirements-to-Code, 55
2.5.3
The Waterfall Development Model, 55
2.5.4
Guidelines for Planning and Controlling Traditional
Software Projects, 58
2.6
Iterative-Development Process Models, 58
2.6.1
The Incremental-Build Model, 59
2.6.2
The Evolutionary Model, 64
2.6.3
Agile Development Models, 66
2.6.4
The Scrum Model, 68
2.6.5
The Spiral Meta-Model, 69
2.6.6
Guidelines for Planning and Controlling IterativeDevelopment Projects, 71
2.7
Designing an Iterative-Development Process, 72
2.8
The Role of Prototyping in Software Development, 74
2.9
Key Points of Chapter 2, 75
References, 76
Exercises, 77
Appendix 2A: Frameworks, Standards, and Guidelines for Software
Development Process Models, 79
2A.1 The CMMI-DEV-v1.2 Technical Solution
Process Area, 79
2A.2 Development Processes in ISO/IEC and
IEEE/EIA Standards 12207, 80
2A.3 Technical Process Plans in IEEE/EIA Standard
1058, 81
2A.4 The PMI Body of Knowledge, 81
www.it-ebooks.info
39
CONTENTS
Appendix 2B:
3
vii
Considerations for Selecting an IterativeDevelopment Model, 82
Establishing Project Foundations
85
3.1
3.2
3.3
3.4
Introduction to Project Foundations, 85
Objectives of This Chapter, 86
Software Acquisition, 87
Requirements Engineering, 88
3.4.1
Requirements Development, 89
3.4.2
Requirements Analysis, 96
3.4.3
Technical Specifications, 98
3.4.4
Requirements Verification, 105
3.4.5
Requirements Management, 106
3.5
Process Foundations, 109
3.5.1
Specifying the Scope of Your Project, 110
3.5.2
The Contractual Agreement, 110
3.6
Key Points of Chapter 3, 112
References, 113
Exercises, 114
Appendix 3A: Frameworks, Standards, and Guidelines for Product
Foundations, 116
3A.1 The CMMI-DEV-v1.2 Process Areas for
Requirements Development and
Requirements Management, 116
3A.2 Product Foundations in ISO/IEC and
IEEE/EIA Standards 12207, 117
3A.3 IEEE/EIA Standard 1058, 118
3A.4 The PMI Body of Knowledge, 118
4
Plans and Planning
4.1
4.2
4.3
4.4
4.5
4.6
119
Introduction to the Planning Process, 119
Objectives of This Chapter, 120
The Planning Process, 121
The CMMI-DEV-v1.2 Process Area for Project Planning, 125
4.4.1
Planning Agile Projects, 128
4.4.2
Balancing Agility and Discipline, 129
A Minimal Project Plan, 129
A Template for Software Project Management Plans, 130
4.6.1
Front Matter, 130
4.6.2
Project Summary, 132
4.6.3
Evolution, Definitions, and References, 134
4.6.4
Project Organization, 136
4.6.5
Managerial Processes, 137
4.6.6
Technical Processes, 143
4.6.7
Supporting Processes, 145
4.6.8
Additional Plans, Appendixes, Index, 149
www.it-ebooks.info
viii
CONTENTS
4.7
Techniques for Preparing a Project Plan, 150
4.7.1
Tailoring the Project Plan Template, 150
4.7.2
Including Predefined Elements, 152
4.7.3
Using Organizational Support, 152
4.7.4
Leading a Planning Team, 153
4.7.5
Incremental Planning, 153
4.8
Key Points of Chapter 4, 154
References, 154
Exercises, 155
Appendix 4A: Frameworks, Standards, and Guidelines for Project
Planning, 156
4A.1 The CMMI-DEV-v1.2 Project Planning
Process Area, 156
4A.2 ISO/IEC and IEEE/EIA Standards
12207, 157
4A.3 IEEE/EIA Standard 1058, 158
4A.4 The PMI Body of Knowledge, 158
Appendix 4B: Annotated Outline for Software Project Management
Plans, Based on IEEE Standard 1058, 159
4B.1 Purpose, 159
4B.2 Evolution of Plans, 160
4B.3 Overview, 160
4B.4 Format of a Software Project Management
Plan, 160
4B.5 Structure and Content of the Plan, 162
5
Project Planning Techniques
5.1
5.2
5.3
5.4
5.5
5.6
Introduction to Project Planning Techniques, 173
Objectives of This Chapter, 174
The Scope of Planning, 175
Rolling-Wave Planning, 175
Scenarios for Developing a Project Plan, 176
Developing the Architecture Decomposition View and
the Work Breakdown Structure, 177
5.7
Guidelines for Designing Work Breakdown
Structures, 182
5.8
Developing the Project Schedule, 188
5.8.1
The Critical-Path Method, 190
5.8.2
The PERT Method, 190
5.8.3
Task-Gantt Charts, 193
5.9
Developing Resource Profiles, 193
5.10 Resource-Gantt Charts, 199
5.11 Estimating Project Effort, Cost, and Schedule, 199
5.12 Key Points of Chapter 5, 201
References, 202
Exercises, 202
www.it-ebooks.info
173
CONTENTS
ix
Appendix 5A: Frameworks, Standards, and Guidelines for Project
Planning Techniques, 204
A5.1 Specific Practices of the CMMI-DEV-v1.2
Project Planning Process Area, 204
5A.2 ISO/IEC and IEEE/EIA Standards 12207, 205
5A.3 IEEE/EIA Standard 1058, 205
5A.4 The PMI Body of Knowledge, 206
6
Estimation Techniques
207
6.1
6.2
6.3
6.4
6.5
6.6
Introduction to Estimation Techniques, 207
Objectives of This Chapter, 208
Fundamental Principles of Estimation, 209
Designing to Project Constraints, 214
Estimating Product Size, 216
Pragmatic Estimation Techniques, 224
6.6.1
Rule of Thumb, 224
6.6.2
Analogy, 226
6.6.3
Expert Judgment, 227
6.6.4
Delphi Estimation, 227
6.6.5
WBS/CPM/PERT, 229
6.7
Theory-Based Estimation Models, 230
6.7.1
System Dynamics, 230
6.7.2
SLIM, 231
6.8
Regression-Based Estimation Models, 234
6.8.1
COCOMO Models, 238
6.8.2
Monte Carlo Estimation, 244
6.8.3
Local Calibration, 244
6.9
Estimation Tools, 249
6.10 Estimating Life Cycle Resources, Effort, and Cost, 249
6.11 An Estimation Procedure, 251
6.12 A Template for Recording Estimates, 256
6.13 Key Points of Chapter 6, 258
References, 258
Exercises, 259
Appendix 6A: Frameworks, Standards, and Guidelines for
Estimation, 262
6A.1 Estimation Goals and Practices of the
CMMI-DEV-v1.2 Project Planning Process
Area, 262
6A.2 ISO/IEC and IEEE/EIA Standards 12207, 263
6A.3 IEEE/EIA Standard 1058, 263
6A.4 The PMI Body of Knowledge, 263
7
Measuring and Controlling Work Products
7.1
7.2
Introduction to Measuring and Controlling Work Products, 265
Objectives of This Chapter, 268
www.it-ebooks.info
265
x
CONTENTS
7.3
7.4
7.5
7.6
Why Measure?, 268
What Should Be Measured?, 269
Measures and Measurement, 270
Measuring Product Attributes, 276
7.6.1
Measuring Operational Requirements and Technical
Specifications, 276
7.6.2
Measuring and Controlling Changes to Work
Products, 281
7.6.3
Measuring Attributes of Architectural Design
Specifications, 285
7.6.4
Measuring Attributes of Software Implementation, 288
7.6.5
Complexity Measures for Software Code, 293
7.6.6
Measuring Integration and Verification of Software
Units, 298
7.6.7
Measuring System Verification and Validation, 299
7.7
Measuring and Analyzing Software Defects, 301
7.8
Choosing Product Measures, 309
7.9
Practical Software Measurement, 311
7.10 Guidelines for Measuring and Controlling Work Products, 311
7.11 Rolling-Wave Adjustments Based on Product Measures and
Measurement, 313
7.12 Key Points of Chapter 7, 313
References, 314
Exercises, 315
Appendix 7A: Frameworks, Standards, and Guidelines for Measuring
and Controlling Work Products, 319
7A.1 The CMMI-DEV-v1.2 Monitoring and Control
Process Area, 319
7A.2 ISO/IEC and IEEE/EIA Standards 12207, 320
7A.3 IEEE/EIA Standard 1058, 321
7A.4 The PMI Body of Knowledge, 321
7A.5 Practical Software and Systems Measurement
(PSM), 321
Appendix 7B: Procedures and Forms for Software Inspections, 322
7B.1 Conducting a Software Inspection, 322
7B.2 The Defect Checklist, 324
7B.3 Conducting an Inspection Meeting, 325
8
Measuring and Controlling Work Processes
8.1
8.2
8.3
8.4
8.5
Introduction to Measuring and Controlling Work Processes, 333
Objectives of This Chapter, 336
Measuring and Analyzing Effort, 336
Measuring and Analyzing Rework Effort, 339
Tracking Effort, Schedule, and Cost; Estimating Future
Status, 342
8.5.1
Binary Tracking, 342
8.5.2
Estimating Future Status, 345
www.it-ebooks.info
333
CONTENTS
xi
8.6
Earned Value Reporting, 347
8.7
Project Control Panel®, 353
8.8
Key Points of Chapter 8, 357
References, 358
Exercises, 358
Appendix 8A: Frameworks, Standards, and Guidelines for Measuring
and Controlling Work Processes, 361
9
Managing Project Risk
363
9.1
9.2
9.3
Introduction to Managing Project Risk, 363
Objectives of This Chapter, 365
An Overview of Risk Management for Software
Projects, 366
9.4
Conventional Project Management Techniques, 369
9.5
Risk Identification Techniques, 373
9.5.1
Checklists, 373
9.5.2
Brainstorming, 375
9.5.3
Expert Judgment, 375
9.5.4
SWOT, 375
9.5.5
Analysis of Assumptions and Constraints, 375
9.5.6
Lessons-Learned Files, 376
9.5.7
Cost and Schedule Modeling, 376
9.5.8
Requirements Triage, 379
9.5.9
Assets Inventory, 380
9.5.10 Trade-Off Analysis, 380
9.6
Risk Analysis and Prioritization, 381
9.7
Risk Mitigation Strategies, 382
9.7.1
Risk Avoidance, 382
9.7.2
Risk Transfer, 383
9.7.3
Risk Acceptance, 383
9.7.4
Immediate Action, 384
9.7.5
Contingent Action, 385
9.8
Top-N Risk Tracking and Risk Registers, 388
9.9
Controlling the Risk Management Process, 392
9.10 Crisis Management, 394
9.11 Risk Management at the Organizational Level, 395
9.12 Joint Risk Management, 396
9.13 Key Points of Chapter 9, 396
References, 397
Exercises, 397
Appendix 9A: Frameworks, Standards, and Guidelines for Risk
Management, 399
9A.1 The CMMI-DEV-v1.2 Risk Management
Process Area, 399
9A.2 ISO/EIC and IEEE/EIA Standards
12207, 400
9A.3 IEEE/EIA Standard 1058, 400
www.it-ebooks.info
xii
CONTENTS
Appendix 9B:
10
9A.4 The PMI Body of Knowledge, 401
9A.5 IEEE Standard 1540, 402
Software Risk Management Glossary, 404
Teams, Teamwork, Motivation, Leadership, and Communication
407
10.1
10.2
10.3
10.4
10.5
10.6
10.7
Introduction, 407
Objectives of This Chapter, 408
Managing versus Leading, 408
Teams and Teamwork, 410
Maintaining Morale and Motivation, 417
Can’t versus Won’t, 418
Personality Styles, 420
10.7.1 Jungian Personality Traits, 420
10.7.2 MBTI Personality Types, 421
10.7.3 Dimensions of Social Styles, 425
10.8 The Five-Layer Behavioral Model, 427
10.9 Key Points of Chapter 10, 430
References, 430
Exercises, 432
Appendix 10A: Frameworks, Standards, and Guidelines for
Teamwork and Leadership, 433
10A.1 The CMMI-DEV-v1.2 Framework
Processes, 433
10A.2 ISO/IEC and IEEE/EIA Standards
12207, 433
10A.3 IEEE/EIA Standard 1058, 433
10A.4 The PMI Body of Knowledge, 434
10A.5 Other Sources of Information, 434
10A.5.1 The People CMM, 434
10A.5.2 The Personal Software Process, 435
10A.5.3 The Team Software Process, 436
10A.5.4 Peopleware, 436
11
Organizational Issues
439
11.1
11.2
11.3
11.4
11.5
11.6
Introduction to Organizational Issues, 439
Objectives of This Chapter, 440
The Influence of Corporate Culture, 441
Assessing and Nurturing Intellectual Capital, 443
Key Personnel Roles, 444
Fifteen Guidelines for Organizing and Leading Software
Engineering Teams, 449
11.6.1 Introduction to the Guidelines, 449
11.6.2 The Guidelines, 450
11.6.3 Summary of the Guidelines, 463
11.7 Key Points of Chapter 11, 464
References, 464
www.it-ebooks.info
CONTENTS
xiii
Exercises, 465
Appendix 11: Frameworks, Standards, and Guidelines for
Organizational Issues, 467
A11.1 The CMMI-DEV-v1.2 Process
Framework, 467
A11.2 ISO and IEEE Standards 12207, 469
A11.3 IEEE/EIA Standard 1058, 470
A11.4 The PMI Body of Knowledge, 470
Glossary of Terms
471
Guidance for Term Projects
481
Index
487
www.it-ebooks.info
PREFACE
Too often those who develop and modify software and those who manage software
development are like trains traveling different routes to a common destination. The
managers want to arrive at the customer’s station with an acceptable product, on
schedule and within budget. The developers want to deliver to the users a trainload
of features and quality attributes; they will delay the time of arrival to do so, if
allowed. Sometimes the two trains appear to be on the same schedule, but often one
surges ahead only to be sidetracked by traffic of higher priority while the other
chugs onward. One or both may be unexpectedly rerouted, making it difficult to
rendezvous en route and at the final destination.
Managers traveling on their train often wonder why programmers cannot just
write the code that needs to be written, correctly and completely, and deliver it when
it is needed. Software developers traveling on their train wonder what their managers do all day. This text provides the insights, methods, tools, and techniques needed
to keep both trains moving in unison through their signals and switches and, better
yet, shows how they can combine their engines and freight to form a single express
train running on a pair of rails, one technical, the other managerial.
By reading this text and working through the exercises, students, software developers, project managers, and prospective managers will learn why
managing a large computer programming project is like managing any other large
undertaking—in more ways than most programmers believe. But in many ways it is
different—in more ways than most professional managers expect.1
Readers will learn how software projects differ from other kinds of projects
(i.e., construction, agricultural, manufacturing, administrative, and traditional engineering projects), and they will learn how the methods and techniques of project
management must be modified and adapted for software projects.
1
The Mythical Man-Month, Anniversary Edition, Frederick P. Brooks Jr., Addison Wesley, 1995; pp. x.
xv
www.it-ebooks.info
xvi
PREFACE
Those who are, or will become managers of software projects, will acquire the
methods, tools, and techniques needed to effectively manage software projects, both
large and small. Software developers, both neophyte student and journeyman/journeywoman professional, will gain an increased understanding of what managers do,
or should be doing all day and why managers ask them to do the things they ask/
demand. These readers will gain the knowledge they need to become project managers. Those students and software developers who have no desire to become project
managers will benefit by gaining an increased understanding of what those other
folks do all day and why the seemingly extraneous things they, the developers, are
asked to do are important to the success of their projects.
This text is intended as a textbook for upper division undergraduates and graduate students as well as for software practitioners and current and prospective software project managers. Exercises are included in each chapter. Practical hints and
guidelines are included throughout the text, thus making it suitable for industrial
short courses and for self-study by practitioners and managers.
Chapters 1 through 3 provide the context for the remainder of the text: Chapter
1 provides an introduction to software project management; Chapter 2 covers
process models for developing software-intensive systems; Chapter 3 is concerned
with establishing the product foundations for software projects.
Chapters 4 through 10 cover the four primary activities of software project
management:
•
•
•
•
Planning and estimating is covered in Chapters 4 through 6.
Measuring and controlling is covered in Chapters 7 and 8.
Managing risk is covered in Chapter 9.
Leading, motivating, and communicating are covered in Chapter 10.
Chapter 11 covers organizational issues and concludes the text with a summary of
15 guidelines for organizing and leading software engineering teams.
For each topic covered, the approach taken is to present the full scope of activities for the largest and most complex projects and to show how those activities can
be tailored, adapted, and scaled to fit the needs of projects of various sizes and
complexities.
Learning objectives are presented at the beginning of each chapter and each
concludes with a summary of key points from the chapter. Occasional sidebars
elaborate the material at hand. An appendix to each chapter relates the topics
covered in that chapter to four leading sources of information concerning management of software projects:
1.
2.
3.
4.
CMMI-DEV-v1.2 process framework
ISO/IEC and IEEE/EIA Standards 12207
IEEE/EIA Standard 1058
PMI’s Body of Knowledge (PMBOK®)
The text is consistent with the guidelines contained in PMBOK and ACM/IEEE
curriculum recommendations.
Presentation slides, document templates, and other supporting material for
the text and for term projects are available at the following URL:
computer.org/book_extras/fairley_software_projects
www.it-ebooks.info
PREFACE
xvii
Terms used throughout this text are defined in the Glossary at the end of the
text. Topics, schedule, and a template for term projects follow the Glossary and
included are some hypothetical projects that can be used as the basis for term projects in a course or as examples that practitioners and managers can use to gain
experience in preparing software project management plans. Schedule and templates for deliverables for the hypothetic projects are also provided; electronic
copies of templates and some software tools are provided at the URL previously
cited. Alternatively, practitioners and managers can apply the templates and tools
to a past, present, or future project.
A continued example for planning and conducting a project to build the software
element of an automated teller system is presented to motivate and explain the
material contained in each chapter.
As is well known, one learns best by doing. I strongly recommended that the
exercises at the end of each chapter be completed and that progress through the
material be accompanied by an extended exercise (i.e., a term project) to develop
some elements a project plan for a real or hypothetical software project. The planning exercise can be based on an actual project that the reader has been, is currently,
or will be involve in; or it can be based on one of the hypotheticals at the end of
the text; or it can be based on a project assigned by the instructor. A week-by-week
schedule for completing the term project on a quarter or semester basis is provided.
Completion of the planning exercise will result in a report that contains elements
similar to those presented in IEEE/EIA Standard 1058 for software project management plans.
The material can be presented in reading/lecture/discussion format or by assigned
readings followed by classroom or on-line discussions based on the exercises and
the term project.
I am indebted to the pioneers who surveyed the terrain, prepared the roadbed,
laid down the tracks, and drove the golden spike so that our project trains can
proceed to their destinations. Those pioneers include Fred Brooks, the intellectual
father of us all; Winston Royce, who showed us systematic approaches to software
development and management of software projects; Barry Boehm, who was the first
to address issues of software engineering economics, risk management, and so much
more; Tom DeMarco, the master tactician of software development, project management, and peopleware; and the many others who prepared the way for this text. I
accept responsibility for any misinterpretations or misstatements of their work. My
apologies to those I have failed to credit in the text, either through ignorance or
oversight.
Thanks to Mary Jane Fairley, Linda Shafer, and the other reviewers of the manuscript for taking the time to read it and for the many insightful comments they
offered. Special thanks to the many students to whom I have presented this material
and from whom I have learned as much as they have learned from me.
Richard E. (Dick) Fairley
Teller County, Colorado
www.it-ebooks.info
1
INTRODUCTION
In many ways, managing a large computer programming project is like managing any
other large undertaking—in more ways than most programmers believe. But in many
other ways it is different—in more ways than most professional managers expect.1
—Fred Brooks
1.1
INTRODUCTION TO SOFTWARE PROJECT MANAGEMENT
When you become (or perhaps already are) the manager of a software project you
will find that experience to be one of the most challenging and most rewarding
endeavors of your career. You, as a project manager, will be (or are) responsible for
(1) delivering an acceptable product, (2) on the specified delivery date, and (3)
within the constraints of the specified budget, resources, and technology. In return
you will have, or should have, authority to use the resources available to you in the
ways you think best to achieve the project objectives within the constraints of
acceptable product, delivery date, and budget, resources, and technology.
Unfortunately, software projects have the (often deserved) reputation of costing
more than estimated, taking longer than planned, and delivering less in quantity and
quality of product than expected or required. Avoiding this stereotypical situation
is the challenge of managing and leading software projects.
There are four fundamental activities that you must accomplish if you are to be
a successful project manager:
1
The Mythical Man-Month, Anniversary Edition, Frederick P. Brooks Jr., Addison Wesley, 1995; p. x.
Managing and Leading Software Projects, by Richard E. Fairley
Copyright © 2009 IEEE Computer Society
1
www.it-ebooks.info
2
INTRODUCTION
1.
2.
3.
4.
planning and estimating,
measuring and controlling,
communicating, coordinating, and leading, and
managing risk.
These are the major themes of this text.
1.2
OBJECTIVES OF THIS CHAPTER
After reading this chapter and completing the exercises, you should understand:
•
•
•
•
•
•
•
•
why managing and leading software projects is difficult,
the nature of project constraints,
a workflow model for software projects,
the work products of software projects,
the organizational context of software projects,
organizing a software development team,
maintaining the project vision and product goals, and
the nature of process frameworks, software engineering standards, and process
guidelines.
Appendix 1A to this chapter provides an introduction to elements of the following
frameworks, standards, and guidelines that are concerned with managing software
projects: the SEI Capability Maturity Model® Integration CMMI-DEV-v1.2, ISO/
IEC and IEEE/EIA Standards 12207, IEEE/EIA Standard 1058, and the Project
Management Body of Knowledge (PMBOK®). Terms used in this chapter and
throughout this text are defined in a glossary at the end of the text. Presentation
slides for this chapter and other supporting material are available at the URL listed
in the Preface.
1.3 WHY MANAGING AND LEADING SOFTWARE PROJECTS
IS DIFFICULT
A project is a group of coordinated activities conducted within a specific time frame
for the purpose of achieving specified objectives. Some projects are personal in
nature, for example, building a dog house or painting a bedroom. Other projects
are conducted by organizations. The focus of this text is on projects conducted
within software organizations. In a general sense, all organizational projects are
similar:
•
•
•
•
objectives must be specified,
a schedule of activities must be planned,
resources allocated,
responsibilities assigned,
www.it-ebooks.info
1.3
WHY MANAGING AND LEADING SOFTWARE PROJECTS IS DIFFICULT
3
work activities coordinated,
progress monitored,
communication maintained,
risk factors identified and confronted, and
corrective actions applied as necessary.
•
•
•
•
•
In a specific sense, the methods, tools, and techniques used to manage a project
depend on the nature of the work to be accomplished and the work products to be
produced. Manufacturing projects are different from construction projects, which
are different from agricultural projects, which are different from computer hardware
projects, which are different from software engineering projects, and so on. Each
kind of project, including software projects, adapts and tailors the general procedures of project management to accommodate the unique aspects of the development processes and the nature of the product to be developed.
Fred Brooks has famously observed that four essential properties of software
differentiate it from other kinds of engineering artifacts and make software projects
difficult2:
1.
2.
3.
4.
complexity,
conformity,
changeability, and
invisibility of software.
1.3.1
Software Complexity
Software is more complex, for the effort and the expense required to construct it,
than most artifacts produced by human endeavor. Assuming it costs $50 (USD) per
line of code to construct a one-million line program (specify, design, implement,
verify, validate, and deliver it), the resulting cost will be $50,000,000. While this is a
large sum of money, it is a small fraction of the cost of constructing a complex
spacecraft, a skyscraper, or a naval aircraft carrier.
Brooks says, “Software entities are more complex for their size [emphasis added]
than perhaps any other human construct, because no two parts are alike (at least
above the statement level).” 3 It is difficult to visualize the size of a software program
because software has no physical attributes; however, if one were to print a onemillion line program the stack of paper would be about 10 feet (roughly 3 meters)
high if the program were printed 50 lines per page. The printout would occupy a
volume of about 6.5 cubic feet. Biological entities such as human beings are of
similar volume and they are far more complex than computer software, but there
are few, if any, human-made artifacts of comparable size that are as complex as
software.
The complexity of software arises from the large number of unique, interacting
parts in a software system. The parts are unique because, for the most part, they are
encapsulated as functions, subroutines, or objects and invoked as needed rather
2
3
Ibid, pp. 182–186.
Ibid, p. 182.
www.it-ebooks.info
4
INTRODUCTION
than being replicated. Software parts have several different kinds of interactions,
including serial and concurrent invocations, state transitions, data couplings,
and interfaces to databases and external systems. Depiction of a software entity
often requires several different representations to portray the numerous static
structures, dynamic couplings, and modes of interaction that exist in computer
software.
A seemingly “small” change in requirements is one of the many ways that complexity of the product may affect management of a project. Complexity within the
parts and in the connections among parts may result in a large amount of evolutionary rework for the “small” change in requirements, thus upsetting the ability to make
progress according to plan. For this reason many experienced project managers say
there are no small requirements changes. Size and complexity can also hide defects
that may not be discovered immediately and thus require additional, unplanned
corrective rework later.
1.3.2
Software Conformity
Conformity is the second issue cited by Brooks. Software must conform to exacting
specifications in the representation of each part, in the interfaces to other internal
parts, and in the connections to the environment in which it operates. A missing
semicolon or other syntactic error can be detected by a compiler but a defect in the
program logic, or a timing error caused by failure to conform to the requirements
may be difficult to detect until encountered in operation. Unlike software, tolerance
among the interfaces of physical entities is the foundation of manufacturing and
construction; no two physical parts that are joined together have, or are required to
have, exact matches. Eli Whitney (of cotton gin fame) realized in 1798 that if musket
parts were manufactured to specified tolerances, interchangeability of similar (but
not identical) parts could be achieved.
There are no corresponding tolerances in the interfaces among software entities
or between software entities and their environments. Interfaces among software
parts must agree exactly in numbers and types of parameters and kind of couplings.
There are no interface specifications for software stating that a parameter can be
“an integer plus or minus 2%.”
Lack of conformity can cause problems when an existing software component
cannot be reused as planned because it does not conform to the needs of the product
under development. Lack of conformity might not be discovered until late in a
project, thus necessitating development and integration of an acceptable component
to replace the one that cannot be reused. This requires unplanned allocation of
resources and can delay product completion. Complexity may have made it difficult
to determine that the reuse component lacked the necessary conformity until the
components it would interact with were completed.
1.3.3
Software Changeability
Changeability is Brooks’s third factor that makes software projects difficult. Software coordinates the operation of physical components and provides the functional-
www.it-ebooks.info
1.3
WHY MANAGING AND LEADING SOFTWARE PROJECTS IS DIFFICULT
5
ity in software-intensive systems.4 Because software is the most easily changed
element (i.e., the most malleable) in a software-intensive system, it is the most frequently changed element, particularly in the late stages of a project. Changes may
occur because customers change their minds; competing products change; mission
objectives change; laws, regulations, and business practices change; underlying hardware and software technology changes (processors, operating systems, application
packages); and/or the operating environment of the software changes. If an early
version of the final product is installed in the operating environment, it will change
that environment and result in new requirements that will require changes to the
product. Simply stated, now that the new system enables me to do A and B, I would
like for it to also allow me to do C, or to do C instead of B.
Each proposed change in product requirements must be accompanied by an
analysis of the impact of the change on project work activities:
what work products will have to be changed?
how much time and effort will be required?
who is available to make the changes?
how will the change affect your plans for schedule, budget, resources, technology, other product features, and the quality attributes of the product?
•
•
•
•
The goal of impact analysis is to determine whether a proposed change is “in scope”
or “out of scope.” In-scope changes to a software product are changes that can be
accomplished with little or no disruption to planned work activities. Acceptance of
an out-of-scope change to the product requirements must be accompanied by corresponding adjustments to the budget, resources, and/or schedule; and/or modification or elimination of other product requirements. These actions can bring a proposed
out-of-scope requirement change into revised scope.
A commonly occurring source of problems in managing software projects is an
out-of-scope product change that is not accompanied by corresponding changes to
the schedule, resources, budget, and/or technology. The problems thus created
include burn-out of personnel from excessive overtime, and reduction in quality
because tired people make more mistakes. In addition reviews, testing, and other
quality control techniques are often reduced or eliminated because of inadequate
time and resources to accomplish the change and maintain these other activities.
1.3.4
Software Invisibility
The fourth of Brooks’s factors is invisibility. Software is said to be invisible because
it has no physical properties. While the effects of executing software on a digital
computer are observable, software itself cannot be seen, tasted, smelled, touched,
or heard. Our five human senses are incapable of directly sensing software; software
is thus an intangible entity. Work products such as requirements specifications,
design documents, source code, and object code are representations of software, but
4
Software-intensive systems contain one or more digital devices and may include other kinds of hardware
plus trained operators who perform manual functions. Nuclear reactors, modern aircraft, automobiles,
network servers, and laptop computers are examples of software-intensive systems.
www.it-ebooks.info
6
INTRODUCTION
they are not the software. At the most elemental level, software resides in the magnetization and current flow in an enormous number of electronic elements within
a digital device. Because software has no physical presence we use different representations, at different levels of abstraction, in an attempt to visualize the inherently
invisible entity.
Because software cannot be directly observed as can, for example, a building
under construction or an agricultural plot being prepared for planting, the techniques presented in this text can be used to determine the true state of progress of
a software project. An unfortunate result of failing to use these techniques is that
software products under development are often reported to be “almost complete”
for long periods of time with no objective evidence to support or refute the claim;
this is the well-known “90% complete syndrome” of software projects. Many software projects have been canceled after large investments of effort, time, and money
because no one could objectively determine the status of the work products or
provide a credible estimate of a completion date or the cost to complete the project.
Sad but true, this will occur again. You do not want to be the manager of one of
those projects.
1.3.5
Team-Oriented, Intellect-Intensive Work
In addition to the essential properties of software (complexity, conformity, changeability, and invisibility), one additional factor distinguishes software projects from
other kinds of projects: software projects are team-oriented, intellect-intensive endeavors. In contrast, assembly-line manufacturing, construction of buildings and roads,
planting of rice, and harvesting of fruit are labor-intensive activities; the work is
arranged so that each person can perform a task with a high degree of autonomy
and a small amount of interaction with others. Productivity increases linearly with
the number of workers added; the work will proceed roughly twice as fast if the
number of workers is doubled. Although labor-saving machines have increased
productivity in some of these areas, the roles played by humans in these kinds of
projects are predominantly labor-intensive.
Software is developed by teams of individuals who engage in creative problem
solving. Teams are necessary because it would take too much time for one person
to develop a modern software system and because it is unlikely that one individual
would possess the necessary range of skills. Suppose, for example, that the total
effort to develop a software product or system5 results in a productivity level of
1000 lines of code per staff-month (more on this later). A one million line program
would require 1000 staff-months. Because effort (staff-months) is the product of
people and time, it would require 1 person 1000 months (about 83 years) to complete the project.
A feasible combination of people and time for a 1000 staff-month project might
be a team of 50 people working for 20 months but not 1000 people working for 1
month or even 200 people working for 5 months. The later proposals (1000 × 1 and
5
Software products are built by vendors for sale to numerous customers; software systems are built by
contractors for specific customers on a contractual basis. The terms “system” and “product” are used
interchangeably in this text unless the distinction is important; the distinction will be clarified in these
cases.
www.it-ebooks.info
1.3
WHY MANAGING AND LEADING SOFTWARE PROJECTS IS DIFFICULT
7
200 × 5) are not feasible because scheduling constraints among work activities
dictate that some activities cannot begin before other work activities are completed:
you can’t design (some part of a system) without some corresponding requirements,
you should not write code without a design specification for (that part of) the
system, you cannot review or test code until some code has been written, you cannot
integrate software modules until they are available for integration, and so on.
Adding people to a software development team does not, as a rule, increase
overall productivity in a linear manner because the increased overhead of communicating with and coordinating work activities among the added people decreases
the productivity of the existing team. To cite Fred Brooks once again, the number
of communication paths among n workers is n(n − 1)/2, which is the number of links
in a fully connected graph. Five workers have 20 communication paths, 10 have 45
paths, and 20 have 190. Increasing the size of a programming team from 5 to 10
members might, for example, might increase the production rate of the team from
5000 lines of code per week to 7500 lines of code per week, but not 10,000 lines of
code per week as would occur with linear scaling. In The Mythical Man-Month,
Brooks described this phenomenon as Brooks’s law6:
Adding manpower to a late software project makes it later.
Brooks’s law is based on three factors:
1. the time required for existing team members to indoctrinate new team
members,
2. the learning curve for the new members, and
3. the increased communication overhead that results from the new and existing
members working together.
Brooks’s law would not be true if the work assigned to the new members did not
invoke any of these three conditions.
A simile that illustrates the issues of team-oriented software development is that
of a team of authors writing a book as a collaborative project; a team of authors is
very much like a team of software developers. In the beginning, requirements analysis must be performed to determine the kind of book to be written and the constraints that apply to writing it. The number and skills of team members will constrain
the kind and size of book that can be written by the available team of authors within
a specified time frame. Constraints may include the number of people on the writing
team, knowledge and skills of team members, the required completion date, and the
word-processing hardware and software available to be used.
Next the structure of the book must be designed: the number of chapters, a brief
synopsis of each, and the relationships (interfaces) among chapters must be specified. The book may be structured into sections that contain several chapters each
(subsystems), or the text may be structured into multiple volumes (a system of
systems). The dynamic structure of the text may flow linearly in time or it may
move backward and forward in time between successive chapters; primary and
6
Ibid, pp. 25 and 274.
www.it-ebooks.info
8
INTRODUCTION
secondary plot lines may be interleaved. An important constraint is to develop a
design structure that will allow each team member to accomplish some work while
other team members are accomplishing their work so that the work activities can
proceed in parallel. Some books are cleverly structured to have multiple endings;
readers choose the one they like.
Design details to be decided include the format of textual layout, fonts to be used,
footnoting and referencing conventions, and stylistic guidelines (use of active and
passive voice, use of dialects and idioms). Writing of the text occurs within a predetermined schedule of production that includes reviews by other team members
(peer reviews) and independent reviews by copy editors (independent verification).
Revisions determined by the reviews must be accomplished. The goal of the writing
team is to produce a seamless text that appears to have been written by one person
in a single setting.
A deviation from the planned narrative by one or more team members might
produce a ripple effect that would require extensive revision of the text. If the
completed book were software, a single punctuation or grammatical error in the
text would render the book unreadable until the writers or their copy editor repaired
the defect. An editor determines that each iteration of elements of the text satisfy
the conditions placed on it by other elements (verification). Finally, reviews by critics
and purchases by readers will determine the degree to which the book satisfies its
intended purpose in its intended environment (validation).
The various development phases of writing (analysis, high-level design, detailed
design, implementation, peer review, independent verification, revision, and validation) are creative activities and thus rarely occur in linear, sequential fashion. Conducting analysis, preparing and revising the design of the text, and production,
review, and revision of the various parts may be overlapped, interleaved, and iterated. Team members must each do their assigned tasks, coordinate their work with
other team members, and communicate ideas, problems, and changes on a continuous basis. The narrative above depicts a so-called Plan-driven approach to writing
a book and, by analogy, to developing software. An alternative is to pursue an Agile
approach by which the team members start with a basic concept and evolve the text
in an iterative manner. This approach can be successful:
•
•
•
•
•
if the team is small, say five or six members (to limit the complexity of
communication);
if all members have in mind a common understanding of the desired structure
of the text (i.e., a “design metaphor”);
if there is a strict page limit and a completion date (the project constraints);
if each iteration occurs in one or a few days (to facilitate ongoing revisions in
structure; known as “refactoring”); and
if a knowledgeable reader (known as the “customer”) is available to review
each iteration and provide guidance for the contents of the next iteration.
In some cases, the team members may work in pairs (“pair programming”) to
enhance synergy of effort.
In reality, most software projects incorporate elements of a plan-driven approach
and an agile approach. When pursuing an agile approach, the team members must
www.it-ebooks.info
1.4
THE NATURE OF PROJECT CONSTRAINTS
9
understand the nature of the desired product to be delivered, a design metaphor
must be established, and the constraints on schedule, budget, resources, and technology that must be observed; thus some requirements definition, design, and project
planning must be done. Those who pursue a plan-driven strategy often pursue an
iterative (agile) approach to developing, verifying, and validating the product to be
delivered; frequent demonstrations provide tangible evidence of progress and
permit incorporation of changes in an incremental manner.
The approach taken in this text is to present a plan-driven strategy, based on
iterative development, that is suitable for the largest and most complex projects,
and to show how the techniques can be tailored and adapted to suit the needs of
small, simple projects as well as large, complex ones. Process models for software
development are presented in Chapter 2.
Over time humans have learned to conduct agricultural, construction, and manufacturing projects that employ teams of workers who accomplish their tasks efficiently and effectively.7 Because software is characterized by complexity, conformity,
changeability, and invisibility, and because software projects are conducted by teams
of individuals engaged in intellect-intensive teamwork, we humans are not always
as adept at conducting software projects as we are at conducting traditional kinds
of projects in agriculture, construction, and manufacturing. Nevertheless, the techniques presented in this text will help you manage software projects efficiently and
effectively, that is, with economical use of time and resources to achieve desired
outcomes.
Your role as project manager is to plan and coordinate the work activities of your
project team so that the team can accomplish more working in a coordinated
manner than could be accomplished by each individual working with total
autonomy.
1.4
THE NATURE OF PROJECT CONSTRAINTS
Many of the problems you will encounter, or have encountered, in software projects
are caused by difficulties of management and leadership (i.e., planning, estimating,
measuring, controlling, communicating, coordinating, and managing risk) rather
than technical issues (i.e., analysis, design, coding, and testing). These difficulties
arise from multiple sources; some you can control as a project manager and some
you can’t. Factors you can’t control are called constraints, which are limitations
imposed by external agents on some or all of the operational domain, operational
requirements, product requirements, project scope, budget, resources, completion
date, and platform technology. Table 1.1 lists some typical constraints for software
projects and provides brief explanations.
The operational domain is the environment in which the delivered software will
be used. Operational domains include virtually every area of modern society, including health care, finance, transportation, communication, entertainment, business, and
manufacturing environments. Understanding the operational domain in which the
software will operate is essential to success. Operational requirements describe the
7
To be efficient is to accomplish a task without wasting time or resources; to be effective is to obtain the
desired result.
www.it-ebooks.info
10
INTRODUCTION
TABLE 1.1
Typical constraints on software projects
Constraint
Operational domain
Operational requirements
Product requirements
Scientific knowledge
Process standards
Project scope
Resources
Budget
Completion date
Platform technology
Business goals
Ethical considerations
Explanation
Environment of the users
Users’ needs and desires
Functional capabilities and quality attributes
Algorithms and data structures
Ways of conducting work activities
Work activities to be accomplished
Assets available to conduct a project
Money used to acquire resources
Delivery date for work products
Software tools and hardware/software base
Profit, stability, growth
Serving best interests of humans and society
users’ view (i.e., the external view) of the system to be delivered. Some desired
features, as specified in the operational requirements, may be beyond the current
state of scientific knowledge, either at large or within your organization. Product
requirements are the developers’ view (i.e., the internal view) of the system to be
built; they include the functional capabilities and quality attributes the delivered
product must possess in order to satisfy the operational requirements.
Process standards specify ways of conducting the work activities of software
projects. Your organization may have standardized ways of conducting specific
activities, such as planning and estimating projects, and measuring project factors
such as conformance to the schedule, expenditure of resources, and measurement
of quality attributes of the evolving product. In some cases the customer may specify
standards and guidelines for conducting a project. Four of the most commonly used
frameworks for process standards are the Capability Maturity Model Integration
(CMMI), ISO/IEEE Standard 12207, IEEE Standard 1058, and the Project Management Body of Knowledge (PMBOK). Elements of these standards and guidelines
are contained in appendixes to the chapters of this text.
The scope of a project is the set of activities that must be accomplished to deliver
an acceptable product on schedule and within budget. Resources are the assets, both
corporate and external, that can be applied to the project. Resources have both
quality and quantity attributes; for example, you may have a sufficient number of
software developers available (quantity of assets), but they may not have the necessary skills (quality of assets). The budget is the money available to acquire and use
resources; the budget for your project may be constrained so that resources available within the organization cannot be utilized. The completion date is the day on
which the product must be finished and ready for delivery. In some cases there may
be multiple completion dates on which subsets of the final product must be delivered. The constrained delivery date(s) may be unrealistic.
Platform technology includes the set of methods, tools, and development environments used to produce or modify a software product. Examples include tools to
develop and document requirements and designs, compilers and debuggers to gen-
www.it-ebooks.info
1.4
THE NATURE OF PROJECT CONSTRAINTS
11
erate and check the code, version control tools to track evolving versions of a project’s work products, and testing tools to aid in verify the software. Platform
technology also includes the hardware processors and operating systems on which
the software is developed and on which it will operate (which may be the same or
different). One or more aspects of the platform technology may be obsolete or
otherwise inappropriate for the work to be done.
Business goals may constrain your project to complete the product as soon as
possible (to maximize short-term revenue), or to produce the highest possible
quality (to maintain credibility with existing customers). Ethical considerations may
constrain your project from delivering a product with known defects or from incorporating knowledge of a competitor’s product gained by unethical methods.
Some of the most difficult problems you will encounter in managing software
projects arise from establishing and maintaining a balance among the constraints
on project scope, budget, resources, technology, and the scheduled delivery date:
1.
2.
3.
4.
5.
scope: the work to be done;
budget: the money to acquire resources;
resources: the assets to do the job;
technology: methods and tools to be used; and
delivery date: the date on which the system must be ready for delivery.
The initial balance among these factors is established in your initial project plan.
The scope of your project may change during project execution because of changes
to product requirements or other factors such as the budget or delivery date. The
constraints on your budget, resources, and schedule may change because of internal
factors in your organization, changes in the operational environment of the product
to be delivered, or competitive pressures. Changes in project scope must always be
accompanied by corresponding changes in schedule, budget, resources, and (perhaps)
technology.
The constraints listed in Table 1.1 reduce the conceptual space available in which
to plan and conduct your project. For example, it may not be possible to deliver a
satisfactory product using 10 people for 12 months, but it might be possible if the
schedule were extended to 15 months or if the number of people were increased
from 10 to 15, or if the requirements for the product were reduced to the functionality that can be delivered with acceptable quality by 10 people in 12 months. In
addition to the constraints listed in Table 1.1, there may be political and sociological
factors that you cannot control.
Some of the first things you must do in managing a software project are:
1. establish the success criteria for your project,
2. clarify the constraints on the project and the product, and
3. determine whether there is a reasonable chance of meeting the success criteria
within the constraints.
Constraints should be clarified to determine whether there is any flexibility or
possibility of trade-offs among the constraints because fewer or looser constraints
www.it-ebooks.info
12
INTRODUCTION
increase the options for planning and executing your project. There may be priorities among the success criteria of delivering an acceptable product on schedule and
within budget; for example, delivering on schedule may be more important than the
number of features delivered, or features delivered may be more important than
cost. There may be additional success criteria, such as establishing a working relationship with a new customer, or developing a product architecture that provides a
basis for developing future products, that is, developing a product-line architecture
that consists of base elements and configurable elements.
Factors you will have (or should have) some influence over include:
1. establishing the success criteria,
2. negotiating the project constraints,
3. obtaining consensus among project stakeholders on an initial set of operational requirements, and
4. obtaining consensus among project stakeholders on an initial set of product
requirements.
Factors you will have responsibility for include:
5. making initial estimates and plans;
6. maintaining a balance among requirements, schedule, and resources as the
project evolves;
7. measuring and controlling the progress of the work;
8. leading the project team and coordinating their work activities;
9. communicating with stakeholders; and
10. managing risk factors that might interfere with, or prevent achieving a successful outcome.
The major activities of project management are planning and estimating, measuring and controlling, communicating and leading, and managing risk factors. Planning
and estimating are concerned with determining the scope of activities that must be
accomplished, estimating effort and schedule for the overall project, and developing
estimates and plans for each major work activity. Planning for measurement involves
establishing a data collection and reporting system that will be used to determine
and report the actual status of work activities and work products on a continuing
basis. Controlling involves applying corrective actions when actual status, as indicated by the measurements, does not agree with planned status.
Communicating involves establishing and maintaining adequate communication
channels among all involved parties so that everyone is aware of progress and
problems, and so that they are constantly reminded of the goals and success criteria
for the project. Leading is concerned with providing direction to, removing roadblocks for, and maintaining the morale of project personnel.
Risk management is concerned with identifying risk factors (potential problems),
both initially and on a continuing basis; monitoring identified risk factors; and
engaging in risk mitigation activities such as preparing contingency plans and executing them when necessary.
www.it-ebooks.info
1.5
1.5
A WORKFLOW MODEL FOR MANAGING SOFTWARE PROJECTS
13
A WORKFLOW MODEL FOR MANAGING SOFTWARE PROJECTS
The primary objective of a software project is to develop and deliver one or more
acceptable work products within the constraints of required features, quality attributes, project scope, budget, resources, completion date, technology, and other
factors. The work products to be delivered (e.g., object code, training materials, and
installation instructions) result from the flow of intermediate work products that
are produced by and flow through the work processes (requirements, design, source
code, and test scenarios).
The model of project workflow used in this text is presented in Figure 1.1. All
models, including the one in Figure 1.1, are abstractions of real situations that
emphasize some aspects of interest and suppress details that are unimportant to the
purposes of the model. Important details may be expressed in subordinate models.
Subordinate models to Figure 1.1 are presented throughout this text.
Figure 1.1 indicates some of the processes that support the primary activity of
Product Development; they include Verification and Validation (V&V), Quality
Assurance of work processes and work products (QA), Configuration Management
(CM), and others. Some supporting processes and their purposes are listed in Table
1.2. Each supporting process must be accomplished in accordance with a welldefined model for accomplishing the work activities of that process.
The model in Figure 1.1 is called a process model because it emphasizes work
activities and the flow of work products among work activities. Each work activity
in a process model produces one or more work products that provide inputs to
subsequent work activities. By work product we mean any document produced by
a software project (including the source code). Some work products are delivered
to the customer (called deliverable work products), while others are intermediate
work products developed to advance the creative problem-solving process in
an orderly manner. Some of the work products of software projects are listed in
Table 1.3.
Change Requests
Start Here
Problem Reports
Requirements
and Constraints
Development
Process
Planning
and
Replanning
Customer
Managers
Activity
Definition
Work
Assign
ments
Quality
Assurance
Directives and
Constraints
Estimating and
Re-estimating
Controlling
Data
Retention
Project Reports
Verification
& Validation
Reporting
FIGURE 1.1
Configuration
Management
Other
Supporting
Processes
Measuring
Status Reports
A workflow model for managing software projects
www.it-ebooks.info
End Here
Deliver
Work
Products
14
INTRODUCTION
TABLE 1.2
Some supporting processes for software development
Supporting Process
Configuration management
Verification
Validation
Quality Assurance
Documentation
Developer training
User and operator training
TABLE 1.3
Purpose
Change control, baseline management, product audits,
product builds
Determining the degree to which work products satisfy
the conditions placed on them by other work
products and work processes
Determining the degree of fitness of work products for
their intended use in their intended environments
Determining conformance of work processes and work
products to policies, plans, and procedures
Preparation and updating of intermediate and
deliverable work products
Maintaining adequate and appropriate skills
Imparting skills needed to effectively use and operate
systems
Some work-product documents produced by software projects
Document
Project plan
Status reports
Memos and meeting minutes
e-Mail messages
Operational requirements
Technical specification
Architectural design document
Detailed design specification
Source code
Test plan
Reference manual
Help messages
Release notes
Installation instructions
Maintenance guide
Content of Document
Roadmap for conducting the project
State of progress, cost, schedule, and quality
Issues, problems, recommendations, and
resolutions
Ongoing communications
User needs, desires, and expectations
Product features and quality attributes
Components and interfaces
Algorithms, data structures, and interface details
of individual modules
Product implementation
Product verification criteria, test scenarios, and
facilities
Product encyclopedia
Guidance for users
Known issues, hints, and guidelines
Guidance for operators
Guidance for maintainers
As Michael Jackson has observed, the entire description of a software system or
product is usually too complex for the entire description to be written directly in a
programming language, so we must prepare different descriptions at different levels
of abstraction, and for different purposes [Jack02]. Note that each of the work
products listed in Table 1.3 is a document; software developers and software project
managers do not produce physical artifacts other than documents, which may exist
in printed or electronic form.
As illustrated in the workflow model depicted in Figure 1.1, a software project is
initiated by customer and managers. A customer is the person or organization that
www.it-ebooks.info
1.5
A WORKFLOW MODEL FOR MANAGING SOFTWARE PROJECTS
15
provides the requirements for and accepts the deliverable work products. Customers
may place constraints on a project, such as specifying a required database interface
(a product constraint) or the date when the delivered system must be available for
use (a process constraint). Managers include your management and you, the project
manager. Managers specify constraints and directives. A process constraint from
your manager might place a limit on the number of people available to conduct the
project; a management directive might require that all software projects in the
organization perform a design activity. You, the project manager, might issue directives requiring that the design be documented using UML (the Universal Modeling
Language) and that one or more design reviews be held.
Requirements, constraints, and directives provide the inputs to the planning
process, which is (or should be) a group activity led by you, the project manager.
You should involve the customer, selected members of the development team, and
other primary stakeholders in the planning process. Planning involves estimation.
Factors to be initially estimated include a schedule for conducting the major work
activities; kinds and numbers of resources needed, when they will be needed, and
for how long; and the project milestones (points in time when progress is assessed).
Estimation is best accomplished by using historical data from a data repository. Data
at the completion of your project can be placed in a repository to aid in estimation
of future projects. Intermediate data can be retained to assess progress and prepare
completion estimates, which may result in replanning.
The output of your planning process will include identification of the roles to be
played in conducting the project, which results in assignment of personnel to those
roles. During initial planning, the major work activities to be planned include software development and the various supporting processes such as configuration management, process and product quality assurance, verification, validation, user training;
plus other necessary activities that constitute the scope of your project. Detailed
plans for these activities will evolve as the project evolves.
During execution of the project, data are collected and status reports are prepared on a periodic basis by you and your staff. The status reports will be used by
you (the project manager), your customer, your managers, support groups, and other
project stakeholders. Status reports compare planned progress to actual progress;
they may cause you and your customer, working together, to revise plans and
requirements, or you might, for example, reassign some personnel to different
project roles (e.g., a software designer might be moved to the independent validation team). Status data are also used to provide a basis for estimating future progress
based on progress to date (which may result in replanning), and is retained to
provide a basis of estimation for future projects.
Problem reports are generated to document defects discovered in work products
that must be reworked. Status reports, new requirements, and changes to requirements, constraints, directives, and problem reports provide the data needed to continually update, elaborate, and revise your project plan.
Every organization that develops and maintains software, including yours, should
have one or more workflow models of software development that depicts the major
work activities and flow of work products. Each member of the organization should
be familiar with the workflow model(s) and understand the ways in which their work
activities and work products fit into the model(s). Everyone in your software development organization should be able to sketch and describe the workflow model(s)
www.it-ebooks.info
16
INTRODUCTION
used in the organization. If there is more than one workflow model, everyone should
understand the kinds of projects for which the various models are appropriate.
1.6
ORGANIZATIONAL STRUCTURES FOR SOFTWARE PROJECTS
Projects are one-time, transient events that are initiated to accomplish a specific
purpose and are terminated when the project objectives are achieved (and are
sometimes cancelled before achieving the objectives). A project exists within the
context of the organization in which it is conducted; each project must adhere to
the structural model of the organization. Departments that conduct engineering
projects, including software projects, are typically organized in one of four ways:
functional structure, project structure, matrix structure, or hybrid structure.
1.6.1
Functional Structures
As the name implies, workers in a functional organization are grouped by the functions they perform. Functional groups can be process-oriented or product-oriented.
One process-oriented functional group might, for example, specialize in requirements engineering, another in design of user interfaces, another in design and
implementation of code, another in product validation, and yet another in user
training. When organized by product specialty, one group might specialize in data
communication, another in database systems, another in user interfaces, and yet
another in numerical algorithms. Figure 1.2 illustrates a process-oriented functional
organization, and Figure 1.3 illustrates a product-oriented functional group.
Each functional group has a functional manager whose job is to acquire and
maintain the quantity and quality of workers needed to support the projects within
the organization, train them as necessary, provide the necessary tools, and coordinate their work activities on various projects. Different group members apply their
Department
Manager
Requirements
Group
Design
Group
Implementation
Group
...
Group
FIGURE 1.2 A process-oriented functional organization
Department
Manager
User Interface
Group
Algorithms
Group
Database
Group
...
Group
FIGURE 1.3 A product-oriented functional organization
www.it-ebooks.info
1.6
ORGANIZATIONAL STRUCTURES FOR SOFTWARE PROJECTS
17
expertise to different projects as needed. As a project manager in a functional organization, responsible for delivering an acceptable product on schedule and within
budget, your ability to successfully conduct your project will depend on your skill
in working with the functional managers and their team members to complete the
various work activities and develop the various work products for your project.
1.6.2
Project Structures
In a purely project-structured organization, you, as project manager, have full
authority and responsibility for managing budget and resources. You acquire the
kinds of workers you need to conduct your project and all project members report
directly to you; you might acquire your workers from functional groups or you might
hire them from outside. You, the project manager, have the authority to acquire staff
members within the constraints of your budget and to remove them when they are
no longer needed or are not performing up to your expectations. Your ability to
successfully conduct your project depends on acquiring the quantity and quality of
workers needed, training them as necessary, providing the necessary tools, and
coordinating their work activities. A project-structured organization is illustrated in
Figure 1.4.
1.6.3
Matrix Structures
The goal of a matrix organization is to obtain the advantages of both functional and
project structures; functional specialists are assigned to projects as needed and work
for you, the project manager, while applying their expertise to your project. When
their tasks are completed, they return to their function groups and are assigned, as
needed, to other projects. Workers in a matrix organization thus have two bosses:
their functional manager and their project manager.
An example of a matrix organization is illustrated in Figure 1.5. The functional
groups might be, for example, a user interface group, an algorithms group, a database
group, and a communications protocol group. The numbers in the matrix indicate
the number of workers of each functional type assigned to each project; for example,
project #1 has 10 members: 2 of functional type #1 (user interface), 5 of functional
type #3 (database), and 2 of functional type #4 (communications). Project #3 is the
largest; it has 23 members. Currently 6 members of the user interface group are
assigned to this project, 8 from the algorithms group, 2 from the database group,
and 7 from communications.
Matrix organizations can be characterized as weak or strong, depending on the
relative authority of the functional managers and the project managers. In a strong
Department
Manager
Project #1
Project #2
FIGURE 1.4
Project #3
Project #n
A project-oriented organization
www.it-ebooks.info
18
INTRODUCTION
Department
Manager
Functional
Manager #1
Functional
Manager #2
Functional
Manager #3
Functional
Manager #4
5
3
Project
Manager #1
2
Project
Manager #2
3
4
7
9
Project
Manager #3
6
8
2
7
Project
Manager #m
1
2
4
6
FIGURE 1.5 A matrix-structured organization
matrix, the functional managers have authority to assign workers to projects, and
project managers must accept the workers assigned to them. In a weak matrix, the
project manager controls the project budget, can reject workers from functional
groups and hire outside workers if functional groups do not have sufficient quantities or qualities of workers.
When a matrix organization performs as intended, functional workers apply their
specialties to different projects, under the direction of project managers, over time
while retaining membership in a group of like-minded experts. Two problems that
can occur in matrix organizations are (1) conflicts between functional managers and
project managers over the allocation of worker resources (which puts the workers
in untenable situations), and (2) frequent shifting of workers from project to project
as crises occur (know as “firefighting” mode).
1.6.4
Hybrid Structures
Few, if any, organizations are purely functional, project, or matrix in nature. In a
purely functional organization, there would be no project managers; a coordinator
at the department level would assign tasks to the functional groups and work products would be passed from group to group as they become available. In a purely
project organization, the project would be an entirely separate organization. The
project manager would be responsible for physical facilities, janitorial service, human
resources (i.e., hiring, firing, payroll, health insurance, and conflict resolution), and
other organizational functions. Similarly projects organized in matrix format do not
operate in isolation but are dependent on other functional elements of the organization to provide physical facilities, payroll processing, and janitorial service. Figure
1.6 illustrates the organizational continuum from pure function to pure project with
matrix organizations occupying the middle region [Youk77].
You, as project manager, will have fewer or more responsibilities and more or
fewer constraints on your authority depending on whether your organization has
predominantly a functional, matrix, or project structure.
www.it-ebooks.info
1.7
ORGANIZING THE PROJECT TEAM
19
0%
100%
Functional
Matrix
Functional
Emphasis
Project
Emphasis
Project
0%
100%
Project Coordinator
Project Manager
FIGURE 1.6 The organizational continuum [Youk77]
1.7
ORGANIZING THE PROJECT TEAM
The way in which your organization is structured determines the way in which you
acquire your project members. It is your job to organize your project team, and to
participate, as appropriate as a member of other teams such as the system engineering team.
1.7.1
The System Engineering Team
The responsibilities of systems engineers include:
•
•
•
•
•
•
•
defining the operational requirements;
specifying system requirements;
developing the system design;
allocating system requirements to system components;
integrating the system components as they become available;
verifying that the system to be delivered is correct, complete, and consistent
with respect to its technical specifications; and
validating operation of the system with its intended users in its intended operational environment.
System engineering, when it exists as a separate entity, is typically a specialty
function in an organization. System engineers may be assigned to projects from a
functional group within a matrix organization, or they may provide internal consulting to projects while remaining in their functional group. System engineers must be
experts in their customer domains and knowledgeable of their organization’s capabilities; they are more likely to be long-term organizational members than to be
hired from outside the organization by a project manager.
Note that system engineers are not component specialists; they are generalists
who understand (must understand) the operational domains of their customers and
users and the capabilities of their organizations to develop systems for those domains.
www.it-ebooks.info
20
INTRODUCTION
System engineers work with component specialists to specify collections of components that will satisfy user needs and customer expectations.
A system engineering team for a complex, software-intensive system should
include hardware, software, and human factors specialists as appropriate for the
various kinds of hardware, software, and manual operations of the envisioned
system. You, as manager of the software project for a software-intensive system,
should be (must be) a member of the system engineering team. In addition the lead
technical person on your software team (if you are not that person) and a representative of the group that will maintain the software portion of the system (if that
is not your team) should also be members of the system engineering team.
1.7.2
The Software Engineering Team
Every software project, whether stand-alone or a subproject of a system-level
program, should include a project manager, a lead designer/software architect, and
one or more small development teams, each with a designated team leader. On a
small project (up to 10 members), the roles of team leader, project manager, and
lead designer may be played by a single individual (you). Or, a project manager may
be assigned on a part-time basis with another individual playing the roles of lead
designer and team leader. For intermediate-size projects (11 to 20 members), there
will be (must be) separate people playing the roles of lead designer and full-time
project manager. On large projects (more than 20 members), there may be a design
team with a designated chief architect, staff members to support the project manager,
and multiple development teams.
Figure 1.7 illustrates a hierarchical model for organizing software projects that
can be expanded or contracted to accommodate various sizes of software projects.
Customer
Project Manager
Software Architect
Team
Leader #1
Team
Leader#2
...
...
Team
Leader #3
Member
Member
V&V
CM
XX
Member
Member
Each team has 2 to 5 members plus
a team leader
V&V:
CM:
XX:
Verification and Validation
Configuration Management
other supporting processes
FIGURE 1.7 An organizational model for software projects
www.it-ebooks.info
1.8
MAINTAINING THE PROJECT VISION AND THE PRODUCT VISION
21
A very small project (5 or fewer members) may have only one team whose leader
is the project manager and software architect; a project having 5 to 10 members
may include two teams and a project manager/software architect. Intermediate-size
projects will have one individual playing the role of project manager and another
as lead designer; a project having 20 software developers might have 4 teams of
5 members, with one member of each team playing the role of team leader.
For projects of more than 50 members, the team leaders depicted in Figure 1.7
will be subsystem managers and subsystem designers with team leaders and
their teams reporting to them; a project having 100 software developers might be
decomposed into 4 subsystems with, for example, 5 teams of 5 assigned to each
subsystem.
A hierarchical project structure, as depicted in Figure 1.7, thus provides a
flexible model that can be expanded and contracted as the needs of various
projects dictate. The purpose of hierarchical structures is not to restrict the flow
of communication within the project but rather to provide well-defined work
activities, roles, authorities, and responsibilities at each level in the hierarchy
that minimizes the need for communication among different groups. Communication paths among teams are not restricted to the hierarchy; the communication
paths are informal networks that are dynamically established and disbanded as
appropriate.
To facilitate communication, a fundamental principle of software analysis and
design is that the requirements must be partitioned and the design structured so
that the work of each small team can proceed concurrently with the work of other
teams. The reason for limiting the size of each team is to control the number of
intensive communication paths among software developers who are engaged in
closely coordinated work activities. As previously mentioned, communication paths
can be modeled as links in a fully connected graph where each team member is a
node in the graph. The number of links in a fully connected graph of n nodes is
n(n − 1)/2. Five members thus have 10 paths; 10 members have 45.
The need to partition the work into well-defined work activities for multiple
teams either by process function (e.g., design, coding, testing) or product function
(e.g., database, algorithms, user interface) is particularly important if the team
members reside in functional groups or are geographically distributed. In these
cases the work to be done must be partitioned so that each functional group or
geographic group can proceed with their work activities with a large degree of
autonomy from the other groups.
1.8 MAINTAINING THE PROJECT VISION AND
THE PRODUCT VISION
Every software project, large or small, simple or complex, must maintain the process
vision (the project roadmap) and the product vision (the goals for the product) from
beginning to end; otherwise, it is easy to lose sight of vision and goals in the midst
of the daily work activities of a project. You, as the project manager, are the keeper
of the process vision, which is documented in the project plan (and is updated as
the project evolves). The software architect is the keeper of the product vision,
www.it-ebooks.info
22
INTRODUCTION
which is documented in the requirements and architectural design specifications
(and is updated as the product evolves).8
The project manager can be likened to a movie producer and the software architect to a movie director. The producer has overall responsibility for schedules,
budgets, resources, customer relations, and delivery of a satisfactory product on time
and within budget. The director is responsible for the content of the product. Producer and director must work together to maintain and constantly communicate the
process vision and the product vision to the cast of developers and supporting personnel as well as all other project stakeholders.
Fred Brooks observes that producer and director can be the same person on a
small project (five to seven developers), but they must be different individuals on
larger projects because of the differing skills required and the number of tasks to
be performed. As Brooks points out, if you, as project manager (producer) are not
also the director (i.e., lead designer), you must “proclaim the director’s technical
authority. . . . For this to be possible, the producer and director must see alike on
fundamental technical philosophy; they must talk out the main technical issues privately, before they really become timely; and the producer must have a high respect
for the director’s technical prowess.”9 We should add that, conversely, the director
must have a high respect for the producer’s managerial prowess.
1.9
FRAMEWORKS, STANDARDS, AND GUIDELINES
A process framework is a generic process model that can be tailored and adapted
to fit the needs of particular projects and organizations. An engineering standard is
a codification of methods, practices, and procedures that is usually developed and
endorsed by a professional society or independent agency. Guidelines are pragmatic
statements of practices that have been found to be effective in many practical
situations.
Some well-known frameworks, standards, and guidelines for software engineering and the associated URLs are:
•
•
•
•
the Capability Maturity Model® Integration for development (CMMI-DEVv1.2) [www.sei.cmu.edu/cmmi/models];
ISO/IEC and IEEE/EIA Standards 12207 [www.iso.org], [standards.ieee.
org/software];
IEEE/EIA Standard 1058 [standards.ieee.org/software]; and
the Project Management Body of Knowledge (PMBOK®) [www.pmibookstore.
org].
Elements of these models that are relevant to managing and leading software projects are presented in appendixes to the chapters of this text, including Appendix
1A to this chapter.
8
9
Ibid, pp. 79–83.
Ibid, p. 79.
www.it-ebooks.info
1.11
1.10
•
•
•
•
•
•
•
•
•
•
•
•
•
•
1.11
OVERVIEW OF THE TEXT
23
KEY POINTS OF CHAPTER 1
A project is a coordinated set of activities that occur within a specific time
frame to achieve specific objectives.
The primary activities of software project management are planning and
estimating; measuring and controlling; communicating, coordinating and
leading; and managing risk.
Software projects are inherently difficult because software is complex, changeable, conformable, and invisible.
Software projects are conducted by teams of individuals who engage in intellect-intensive teamwork.
Project constraints consist of limitations imposed by external agents on some
or all of the operational domain, operational requirements, product requirements, project scope, budget, resources, completion date, and platform
technology.
A workflow model depicts the work activities and the flow of work products
among work activities in a software project.
The entire description of a software system or product is usually too complex
for the entire description to be written directly in a programming language, so
we must prepare different descriptions at different levels of abstraction, and
for different purposes.
Organizations that conduct software projects use functional, project, weak
matrix, and strong matrix structures.
Software projects organized in a hierarchical manner provide well-defined
work activities, roles, authorities, and responsibilities at each level in the hierarchy; hierarchies can expand and shrink to fit the needs of each project.
Requirements must be allocated and the design structured so that the work of
each small team can proceed concurrently with the work of other teams.
The project manager maintains the project vision, as documented in the project
plan, and the software architect maintains the product goals, as documented in
the requirements and architectural design.
A software process framework is a generic process model that can be tailored
and adapted to fit the needs of particular projects and organizations.
A software engineering standard is a codification of methods, practices, and
procedures, usually developed and endorsed by a professional society or independent agency.
SEI, ISO, IEEE, and PMI provide process frameworks, standards, and guidelines that contain information relevant to managing software projects (see
Appendix 1A to this chapter).
OVERVIEW OF THE TEXT
This text is organized into 11 chapters. The first 3 chapters present the context in
which software projects are conducted. This chapter provides an overview of and
an introduction to managing software projects. Chapter 2 presents commonly used
www.it-ebooks.info
24
INTRODUCTION
process models for software development and the project management considerations for each of the models. Chapter 3 describes product and process foundations
for software projects. Product foundations include operational requirements, system
requirements and system design, design constraints, and software requirements.
Process foundations include the workflow model, the software development model,
the contractual agreement, and the project plan.
Chapters 4, 5, and 6 are concerned with planning and estimation. Chapter 4
describes the planning process and the format and contents of project management
plans. Chapter 5 presents planning techniques, including work breakdown structures, work packages, activity networks (critical paths and PERT), Gantt charts, and
resource-loading histograms. Chapter 6 is concerned with estimation techniques,
including pragmatic, theory-based, and regression-based techniques.
Chapter 7 presents an introduction to measures and measurement, and measurement and control of work products, including techniques to measure and analyze
software defects. Chapter 8 presents measurement and control of work processes,
including techniques for measuring and controlling schedule, budget, progress, and
risk. Chapter 9 covers risk management, including risk identification, analysis and
prioritization, mitigation strategies, action plans and action items, contingency plans
and contingent actions, and crisis management.
Chapter 10 covers teamwork, motivation, personality styles, and leadership styles.
Chapter 11 covers organizational issues; it concludes with 15 guidelines for organizing and leading software engineering teams.
Each chapter provides exercises; completing them will further your understanding of the topics covered in the chapter. An appendix to each chapter of this text
includes relevant topics, keyed to that chapter, from the SEI Capability Maturity
Model® Integration CMMI-DEV-v1.2, ISO/IEC and IEEE/EIA Standards 12207,
IEEE/EIA Standard 1058, and the PMI Project Management Body of Knowledge
(PMBOK®).
Appendix A to this text provides a glossary of terms used throughout the text.
Appendix B describes some topics for term projects and a schedule of assignments
for a term project to develop a software project management plan. Presentation
slides for each chapter and other supporting material are available at the URL listed
in the Preface.
REFERENCES
[Brooks95]
[CMMI06]
Brooks, F. P. The Mythical Man-Month. Addison Wesley, 1995.
SEI. CMMI® Models and Modules. http://www.sei.cmu.edu/cmmi/models/,
2006.
[IEEE1058] IEEE Std 1058™—1998 IEEE Standard for Software Project Management
Plans. IEEE Press, New York, 1998. Also in Engineering Standards Collection.
IEEE Product: SE113. Institute of Electrical and Electronic Engineers, August
2003.
[IEEE12207] Industry Implementation of International Standard ISO/IEC 12207:1995 Standard for Informati...
Purchase answer to see full
attachment