Introduction to Software Project Management PDF

Introduction to Software Engineering & Systems Development Villafiorita Although software development is one of the most complex activities carried out by man, sound d...

Introduction to Software Engineering & Systems Development Villafiorita Although software development is one of the most complex activities carried out by man, sound development processes and proper project management can help to ensure Software your software projects are delivered on time and under budget. Providing the know- how to manage software projects effectively, Introduction to Software Project Introduction to Software Project Management Management supplies an accessible introduction to software project management. Project The book begins with an overview of the fundamental techniques of project management and the technical aspects of software development. This section supplies the understanding of the techniques required to mitigate uncertainty in projects and better control the complexity of software development projects. The second part Management illustrates the technical activities of software development in a coherent process— describing how to customize this process to fit a wide range of software development scenarios. Examines project management frameworks and software development standards, including ESA and NASA guidelines, PRINCE2®, and PMBOK® Addresses open source development practices and tools so readers can adopt best practices and get started with tools that are available for free Explains how to tailor the development process to different kinds of products and formalities, including the development of web applications Includes access to additional material for both practitioners and teachers at www.spmbook.com Supplying an analysis of existing development and management frameworks, the book describes how to set up an open-source tool infrastructure to manage projects. Since practitioners must be able to mix traditional and agile techniques effectively, the book covers both and explains how to use traditional techniques for planning and developing software components alongside agile methodologies. It does so in a manner that will help you to foster freedom and creativity in assembling the processes that will best serve your needs. Adolfo Villafiorita K15541 6000 Broken Sound Parkway, NW Suite 300, Boca Raton, FL 33487 ISBN: 978-1-4665-5953-0 711 Third Avenue 90000 an informa business New York, NY 10017 2 Park Square, Milton Park www.crcpress.com Abingdon, Oxon OX14 4RN, UK 9 781466 559530 www.auerbach-publications.com K15541 cvr mech.indd 1 1/10/14 9:28 AM Introduction to Software Project Management Introduction to Software Project Management Adolfo Villafiorita CRC Press Taylor & Francis Group 6000 Broken Sound Parkway NW, Suite 300 Boca Raton, FL 33487-2742 © 2014 by Taylor & Francis Group, LLC CRC Press is an imprint of Taylor & Francis Group, an Informa business No claim to original U.S. Government works Version Date: 20140108 International Standard Book Number-13: 978-1-4665-5954-7 (eBook - PDF) This book contains information obtained from authentic and highly regarded sources. Reasonable efforts have been made to publish reliable data and information, but the author and publisher cannot assume responsibility for the validity of all materials or the consequences of their use. The authors and publishers have attempted to trace the copyright holders of all material reproduced in this publication and apologize to copyright holders if permission to publish in this form has not been obtained. If any copyright material has not been acknowledged please write and let us know so we may rectify in any future reprint. Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced, transmit- ted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopying, microfilming, and recording, or in any information storage or retrieval system, without written permission from the publishers. For permission to photocopy or use material electronically from this work, please access www.copyright. com (http://www.copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400. CCC is a not-for-profit organization that provides licenses and registration for a variety of users. For organizations that have been granted a photocopy license by the CCC, a separate system of payment has been arranged. Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for identification and explanation without intent to infringe. Visit the Taylor & Francis Web site at http://www.taylorandfrancis.com and the CRC Press Web site at http://www.crcpress.com To Barbara Contents Preface..................................................................................... xv Acknowledgments....................................................................... xvii Author..................................................................................... xix 1 Introduction......................................................................... 1 1.1 What is a Project.............................................................. 1 1.1.1 Projects and Operational Work.................................. 1 1.1.2 Programs, Subprojects, and Portfolios.......................... 3 1.1.2.1 Programs................................................ 4 1.1.2.2 Subprojects............................................. 4 1.1.2.3 Portfolios................................................ 4 1.2 What is a Software Project.................................................. 5 1.2.1 Application Development......................................... 5 1.2.2 Process and Systems Reengineering Services................... 6 1.2.3 System Integration Services....................................... 6 1.2.4 Other Types of Projects............................................ 7 1.3 Managing Projects............................................................ 7 1.3.1 The Project Manager and the Project Stakeholder........... 7 1.3.2 Project Stakeholders................................................ 8 1.3.3 Code of Conducts and Ethical Aspects......................... 9 1.4 Software Project Management.............................................. 10 1.5 Goals and Organization of the Book...................................... 13 1.6 Further References............................................................ 14 1.7 Questions and Topics for Discussion..................................... 16 References.............................................................................. 16 vii viii Contents 2 The Basics: Software Development Activities and Their Organization........................................................... 19 2.1 Software Requirements Deﬁnition........................................ 20 2.1.1 Requirements Elicitation.......................................... 21 2.1.2 Requirements Structuring......................................... 21 2.1.3 User Experience Design............................................ 22 2.1.4 Requirements Validation.......................................... 23 2.2 Business Modeling............................................................ 23 2.2.1 Mapping the Organizational Structure......................... 24 2.2.2 Modeling the Business Processes................................. 25 2.2.3 Mapping the Existing IT Infrastructure........................ 25 2.2.4 Mapping Business Entities........................................ 25 2.3 Design and Implementation................................................ 26 2.3.1 System Design....................................................... 26 2.3.2 Implementation..................................................... 28 2.4 Veriﬁcation and Validation.................................................. 29 2.4.1 Testing................................................................. 29 2.4.2 Organizing Testing Activities..................................... 30 2.4.2.1 Test Plan Deﬁnition.................................. 30 2.4.2.2 Test Execution and Reporting...................... 30 2.5 Deployment.................................................................... 31 2.6 Operations and Maintenance............................................... 34 2.6.1 Supporting and Monitoring Operations....................... 34 2.6.2 Maintenance......................................................... 34 2.6.3 Organizing Support and Maintenance Activities............. 35 2.7 Questions and Topics for Discussion..................................... 36 References.............................................................................. 37 3 Making IT Right: Managing Goals, Time, and Costs...................... 39 3.1 Before You Start: Assessing Value and Risks............................. 39 3.1.1 Project Value: Aspects to Consider.............................. 40 3.1.2 Project Risks: Aspects to Consider............................... 40 3.1.3 Techniques to Assess Value and Risks........................... 41 3.1.3.1 Financial Methods.................................... 41 3.1.3.2 Score Matrices......................................... 43 3.1.3.3 SWOT Analysis....................................... 44 3.1.3.4 Stakeholder Analysis.................................. 45 3.1.3.5 Assessing Sustainability.............................. 46 3.1.3.6 A Recap of Project Selection Techniques......... 46 3.1.4 The Project Feasibility Document............................... 47 3.2 Formalizing the Project Goals.............................................. 48 3.2.1 Project Goals and Requirements................................. 49 3.2.2 Project Assumptions and Constraints........................... 50 Contents ix 3.2.3 Project Outputs and Control Points............................ 51 3.2.4 Project Roster........................................................ 53 3.3 Deciding the Work........................................................... 53 3.3.1 Building a WBS..................................................... 54 3.3.2 WBS Decomposition Styles....................................... 56 3.3.3 WBS Dictionary.................................................... 58 3.3.4 WBS Construction Methodologies.............................. 58 3.4 Estimating...................................................................... 58 3.4.1 Eﬀort, Duration, and Resources................................. 59 3.4.2 The “Quick” Approach to Estimation.......................... 60 3.4.3 The Uncertainty of Estimations.................................. 61 3.4.4 PERT.................................................................. 63 3.4.5 Algorithmic Techniques........................................... 64 3.4.5.1 Function Points........................................ 65 3.4.5.2 COCOMO............................................ 67 3.4.5.3 Web Objects........................................... 71 3.4.5.4 Eﬀort and Project Phases............................ 72 3.5 Scheduling a Plan............................................................. 72 3.5.1 Identify Dependencies among Activities....................... 73 3.5.1.1 Type of Dependencies................................ 73 3.5.1.2 Lead and Lag Time................................... 75 3.5.1.3 Network Graphs....................................... 75 3.5.2 Identify the Critical Path.......................................... 76 3.5.3 Allocate and Level Resources..................................... 80 3.5.3.1 Qualifying the Resources Needed for a Task............................................... 81 3.5.3.2 Specifying Resource Availability.................... 81 3.5.3.3 Allocating Resources to a Plan...................... 83 3.5.4 The Gantt Chart.................................................... 84 3.6 Optimizing a Plan............................................................ 86 3.6.1 Renegotiating Goals and Deadlines............................. 86 3.6.2 Phase the Project.................................................... 87 3.6.3 Project Crashing..................................................... 87 3.6.4 Fast Tracking......................................................... 88 3.6.5 Critical Chain Management...................................... 90 3.7 Budgeting and Accounting.................................................. 92 3.7.1 Project Costs......................................................... 92 3.7.2 Cost Element Structures........................................... 93 3.7.3 Determining the Project Costs................................... 95 3.7.4 Managing Project Costs............................................ 95 3.8 Project Execution............................................................. 97 3.8.1 Kicking Activities Oﬀ.............................................. 98 3.8.2 Collect the Output of Activities.................................. 98 x Contents 3.8.3 Collect Information about the Project Status................. 98 3.8.4 The Project Routine in Agile Methods......................... 99 3.9 Project Monitoring and Control........................................... 99 3.9.1 Bookkeeping Your Plan: Actual Start and End Dates........ 100 3.9.2 Monitoring Time and Work...................................... 102 3.9.3 Monitoring Costs................................................... 103 3.9.4 An Integrated Approach: Earned Value Analysis.............. 104 3.9.4.1 Planned Value.......................................... 105 3.9.4.2 Actual Costs............................................ 106 3.9.4.3 Earned Value........................................... 107 3.9.4.4 Assessing a Plan Health Using Earned Value Analysis.................................................. 107 3.9.4.5 Some Considerations about Earned Value Analysis.................................................. 109 3.9.5 Monitoring Progress, the Agile Way............................. 110 3.9.6 Agile-Earned Value Analysis...................................... 112 3.10 Project Closing................................................................ 114 3.10.1 Getting Client Acceptance........................................ 115 3.10.2 Installing Project Deliverables.................................... 115 3.10.3 Archiving Old Deliverables....................................... 116 3.10.4 Documenting the Project.......................................... 116 3.10.5 Performing a Financial Closure.................................. 116 3.10.6 Postimplementation Audit........................................ 116 3.10.7 Staﬀ-Releasing....................................................... 118 3.11 An Example.................................................................... 118 3.11.1 Initiating.............................................................. 119 3.11.2 Building a Plan...................................................... 120 3.11.3 Creating a Budget for the Project................................ 122 3.11.4 Changing the Plan to Meet External Deadlines............... 123 3.11.4.1 Changing the Project Approach.................... 124 3.11.4.2 Reducing or Changing the Project Scope........ 124 3.11.4.3 Allocating Resources More Eﬃciently............ 125 3.11.4.4 Fast Tracking the Plan................................ 125 3.12 Questions and Topics for Discussion..................................... 125 References.............................................................................. 126 4 Making IT Better: Managing Changes, Risks, and Quality............... 131 4.1 Managing Changes........................................................... 131 4.1.1 Managing Changes in the Traditional Approach............. 134 4.1.2 Managing Changes in the Agile Methods...................... 136 4.1.3 Conﬁguration Management...................................... 136 4.1.3.1 Conﬁguration Management Goals and Practices........................................... 137 Contents xi 4.1.3.2 Versioning Systems and Software Evolution Models................................................... 139 4.2 Risk Management............................................................. 141 4.2.1 Deﬁne Standards.................................................... 142 4.2.2 Identify Risks........................................................ 143 4.2.3 Some Common Risks in Software Development............. 144 4.2.4 Classify Risks......................................................... 145 4.2.5 Risk Management Strategies...................................... 147 4.2.6 Budgeting for Risks................................................. 149 4.2.7 Risk Monitoring and Control.................................... 150 4.2.7.1 Review and Share..................................... 150 4.2.7.2 Apply Contingency Plans............................ 151 4.2.7.3 Revise and Iterate..................................... 151 4.3 Quality Management......................................................... 151 4.3.1 Quality Planning.................................................... 152 4.3.2 Quality Assurance................................................... 153 4.3.3 Quality Control..................................................... 153 4.3.4 Establishing a Metrics Program.................................. 156 4.3.4.1 Size Metrics............................................. 157 4.3.4.2 Complexity Metrics................................... 157 4.3.4.3 Quality Metrics........................................ 157 4.4 Questions and Topics for Discussion..................................... 158 References.............................................................................. 158 5 Making IT Perfect: Managing People and Organizing Communication.................................................................... 161 5.1 Managing People.............................................................. 162 5.1.1 Deﬁne Staﬀ Requirements........................................ 162 5.1.2 Selecting Internal Staﬀ............................................. 163 5.1.3 Selecting External Staﬀ............................................. 164 5.1.4 Managing Staﬀ...................................................... 165 5.1.5 Management Styles................................................. 168 5.2 Project Organization Structures............................................ 170 5.2.1 Hierarchical.......................................................... 170 5.2.2 Matricial Organizations............................................ 172 5.2.3 RACI Matrix......................................................... 173 5.2.4 Agile Teams.......................................................... 173 5.3 Managing Communication................................................. 175 5.3.1 Planning a Communication Strategy........................... 176 5.3.2 Communication Styles............................................. 177 5.3.3 Meetings.............................................................. 178 5.3.3.1 Managing Meetings................................... 178 5.3.3.2 Types of Meetings..................................... 179 xii Contents 5.3.3.3 Delphi................................................... 182 5.3.3.4 Planning Poker........................................ 182 5.4 Questions and Topics for Discussion..................................... 183 References.............................................................................. 183 6 Software Project Pricing.......................................................... 187 6.1 From Cost to Pricing......................................................... 187 6.2 Software Pricing............................................................... 189 6.2.1 Software Pricing Models........................................... 189 6.2.2 Selling and Licensing Software................................... 190 6.2.3 Open Source Software............................................. 190 6.3 Project Pricing Strategies..................................................... 192 6.3.1 Determining the Project Price.................................... 193 6.3.2 Contractual Agreements........................................... 193 6.3.3 Contractual Agreements and Project Budget.................. 195 6.4 Procurement and Outsourcing............................................. 197 6.4.1 Vendor Solicitation................................................. 198 6.4.2 Procurement Timing Activities................................... 199 6.5 An Example.................................................................... 201 6.6 Questions and Topics for Discussion..................................... 203 References.............................................................................. 203 7 Managing Software Development Projects................................... 205 7.1 Project Life Cycles............................................................ 205 7.2 From Traditional to Agile................................................... 207 7.2.1 The Waterfall........................................................ 207 7.2.2 The V-Model........................................................ 209 7.2.3 The Rational Uniﬁed Process..................................... 211 7.2.4 The Spiral............................................................. 213 7.2.5 Prototyping/Evolutionary......................................... 214 7.2.6 Cleanroom Software Engineering................................ 215 7.3 Agile Methodologies.......................................................... 217 7.3.1 Extreme Programming............................................. 218 7.3.2 Dynamic System Development Method....................... 220 7.3.3 Scrum................................................................. 221 7.3.4 Kanban................................................................ 225 7.4 Open Source Development Practices..................................... 227 7.4.1 Open Source Development Challenges......................... 227 7.4.2 An Open Source Development Process......................... 228 7.4.2.1 Open Source Project Steering....................... 229 7.4.2.2 Open Source Development......................... 230 7.4.2.3 Open Source Releases................................ 231 Contents xiii 7.5 Questions and Topics for Discussion..................................... 233 References.............................................................................. 233 8 Development and Management Standards.................................... 237 8.1 Microsoft Solutions Framework............................................ 237 8.1.1 Foundational Principles............................................ 238 8.1.2 Team Model.......................................................... 238 8.1.3 Process Model........................................................ 239 8.1.4 Disciplines............................................................ 240 8.2 PMBOK Guide............................................................. 241 8.2.1 Knowledge Areas.................................................... 241 8.2.2 Process Groups...................................................... 242 8.2.3 Processes.............................................................. 242 8.2.4 PMBOK Guide for Software Development................. 242 8.3 NASA Practices................................................................ 245 8.3.1 NASA System Engineering Practices............................ 245 8.3.2 NASA Software Management Process Requirements........................................................ 247 8.3.3 NASA Software Development Practices........................ 248 8.4 PRINCE2.................................................................... 251 8.4.1 PRINCE2 Process Model....................................... 251 8.4.1.1 Starting a Project...................................... 252 8.4.1.2 Initiating a Project.................................... 252 8.4.1.3 Directing a Project.................................... 252 8.4.1.4 Controlling a Stage................................... 252 8.4.1.5 Managing Product Delivery......................... 253 8.4.1.6 Managing Stage Boundaries......................... 253 8.4.1.7 Closing a Project...................................... 253 8.4.1.8 Planning................................................ 253 8.4.2 PRINCE2 Components........................................ 254 8.4.2.1 Business Case.......................................... 254 8.4.2.2 Organization........................................... 255 8.4.2.3 Plans..................................................... 255 8.4.2.4 Control.................................................. 255 8.4.2.5 Change Control....................................... 256 8.5 Capability Maturity Model Integration.................................. 256 8.6 Questions and Topics for Discussion..................................... 259 References.............................................................................. 259 9 Open Source Tools for Managing Projects.................................... 261 9.1 Project Information Flow.................................................... 262 9.2 Basic Infrastructure........................................................... 264 9.3 Basic + Infrastructure........................................................ 265 xiv Contents 9.4 Collaborative Document Writing.......................................... 266 9.5 Management Infrastructure................................................. 266 References.............................................................................. 268 Index....................................................................................... 269 Preface Software development is considered among the most complex activities carried out by man. The steady growth of software systems’ size, the increasing role software is playing in safety critical applications, and the speed at which technology and software change are some of the causes frequently mentioned to support the above claim. Although techniques and tools to build software have improved considerably in the last 60 years, a proper development process and a sound project management are and will remain the top reasons software projects fail or succeed. Software project managers share many of the goals of project managers in other domains, namely, ensuring an appropriate quality of the end product, while, at the same time, keeping under control all the other project variables, like time and costs. Diﬀerent from other domains, however, software has speciﬁc characteristics, such as invisibility, complexity, and ﬂexibility (in its application and production means), that call for speciﬁc management techniques. This book is an introduction to the area of software project management. After a presentation of the main deﬁnitions and concepts, the book is organized in two main parts. The ﬁrst part overviews the technical activities for developing software (Chapter 2) and techniques for managing projects (Chapters 3 through 6). The goal is pro- viding the basic building blocks and the techniques to mitigate the complexity of software development and control the uncertainty of projects. The second part of the book organizes the technical activities in a coher- ent process and shows how this process is customized in practice to ﬁt common software-development scenarios (Chapter 7). An analysis of existing development and management frameworks (Chapter 8) and a discussion about how to setup a tool infrastructure to manage projects (Chapter 9) close the book. xv xvi Preface In recent years, I have found myself mixing traditional and agile techniques more often, using traditional techniques for planning and developing some of the software components with agile methodologies and iterative processes. This book, thus, presents both techniques. It tries to do so in a manner to favor some freedom and creativity in assembling the process which best ﬁts one’s needs. Accompanying this text is a web site (http://www.spmbook.com) that provides teaching material for instructors and additional reference material for students. I hope you enjoy the textbook and web site! Acknowledgments Writing a book requires many resources, and this book would have not been possible without the support, help, and encouragement of family, friends, and colleagues. A special thank you goes to Ali Al-Shammari, Aaron Ciaghi, Andrea Nodari, and Pietro Molini and the other colleagues of the ICT4G group for the comments they gave me on preliminary versions of this book. If you enjoy reading this book, that is because of the feedback they gave me on earlier versions. My sincere gratitude also goes to my editor John Wyzalek, who believed in this project and to all the team who made the book possible, among which Kate Gallo, Robert Sims, and Karthick Parthasarathy. I wish also to thank my family and friends. A ﬁrst big thank you goes to my wife Barbara, for her patience and support. Another goes to my nephew Marco, who told me once I have a sweet tooth and thus gave me the inspiration for the millefoglie example. My dad Enzo, Andrea, Ombretta, and Rienzo also provided a lot encouragement. Least but not last, I wish to thank the friends of the Argentario Squash club, Max, Rudy, Maurizio, Paolo, Michele, Piero and all the others who made sure I would not get too fat while writing this book! xvii Author Adolfo Villaﬁorita, PhD, is a senior researcher at Fondazione Bruno Kessler where he leads the ICT4G unit, whose mission is the use of ICT to foster social and economic development. With long experience in the area of formal veriﬁcation, he has led various technology transfer and development projects in the national and international context. He is a contract professor at the University of Trento, where he teaches software project management. xix Chapter 1 Introduction 1.1 What is a Project 1.1.1 Projects and Operational Work Project Management Institute (2004) deﬁnes a project as a temporary endeavor undertaken to create a unique product or service. The deﬁnition entails ﬁve impor- tant characteristics of a project, some explicitly mentioned and some following as a consequence. These characteristics also deﬁne some of the requirements of a good project manager, as we will see later. The ﬁrst characteristic is that a project is temporary, that is, it has a beginning and an end. In many cases, determining the start and the end is easy. Consider the following examples: a contract sign-oﬀ, a formal autho- rization to proceed from senior management, a system going in production. In practice, however, many projects begin by slowly building up resources and interest, while the oﬃcial start happens sometime after the resources and work have been invested. Others have residual work and activities going on after the oﬃcial end, for instance to follow up on defects and problems found in project outputs. In all cases, however, projects have a start and a conclusion. The fact that a project is temporary has a natural consequence. Every project will, in fact, have 1. An initiating phase, during which the project infrastructure and the project’s goals are drafted. 2. A planning phase, during which project goals are reﬁned, activities identiﬁed and scheduled, and many other support activities are properly planned. 1 2 Introduction to Software Project Management 3. An executing phase, during which the actual work takes place. Running in parallel, a monitoring phase measures the progress and raises ﬂags when plans and reality disagree. 4. A ﬁnal closing phase, where the project outputs are handed out and the project is closed. The amount and intensity of work in a project change according to the project phase. The initiating and planning phases will require a relatively small amount of work. Work will accumulate fast during the execution phase, as the project activities, many of which are running in parallel, unfold. As the project gets near to its con- clusion, work will reduce and stop, of course, when the project delivers its outputs. If we plot the cumulative work produced in a project, we get an s-shaped curve. Both the phases of a project and the typical trend of cumulative work are shown in Figure 1.1. As a side remark, Figure 1.1 also introduces the notation we will use for pro- cess diagrams, which was inspired by the activity diagram notation of the Uniﬁed Modeling Language (UML). In particular, rounded rectangles represent activities, a black dot represents the initial state, and a bull’s eye represents the ﬁnal state. The arrow shows the order in which activities run. Although not shown here, we will also use rectangles to denote artifacts and diamond for choices. The second characteristic is that a project delivers an output in the form of a product, a service, or a capability. The outputs are tangible, and often their proper- ties are also measurable. Thus, a project can be set up and organized, starting from the description and the characteristics of the outputs it delivers. Such description, in fact, entails the work that has to be done to build the outputs. The descrip- tion of the project outputs also deﬁnes the project completion criteria: the project Initiate Plan Execute Close Monitor Cumulative work Time Figure 1.1 Project phases and cumulative work. Introduction 3 ends when the outputs are delivered as speciﬁed. Things are not always so sim- ple, however. Many projects have a clear output, but the way in which this is achieved might not be clear. Consider, for instance, a situation in which we want to improve the performances of a software system. The goal is clear, but the means to achieve it might not. In other situations, the outputs might not be completely clear or well spelled out. This is quite common in software development, where coming out with a complete and unambiguous description of a system is not always easy. The third characteristic is that projects are resource constrained. A limited time is available to build the project outputs. Also limited will be other project resources, such as the budget and the team. An important consequence is that the project man- ager and the team have to ﬁnd an achievable solution, while respecting all project constraints. Thus, the output of a project is seldom the best possible solution but rather the best solution given the constraints. The fourth characteristic is that a project requires a progressive elaboration to build the project outputs. At the beginning, diﬀerent ways are possible to achieve the project goals. As we move along, many project activities require to take choices, which reduce the degrees of freedom, till we get to the end of the project with the only possible implementation of the project goals. Thus, the cost of changes increases as a project progresses, since the amount of rework necessary to implement a change increases as we reduce our degrees of freedom. The ﬁfth and ﬁnal characteristic is that a project delivers a unique output. Thus, what a project delivers has some novelty, one way or the other. This allows us to introduce the last important characteristic, namely, that a project always has some risk coming in the form of menaces or opportunities. Risks come from the unique characteristics of the project outputs, which sometimes are not fully understood or not clear when a project starts. Other risks derive from additional constraints that are set in a project; consider, for instance a situation in which a customer pushes for a schedule that is too tight or for quality requirements that are set too high. Having seen the main qualities of a project, we need to mention that not all work is a project. Work that is not a project is called operational, even though one might still call it a project. The techniques for managing a project, however, can also be useful for operational work. 1.1.2 Programs, Subprojects, and Portfolios Projects come in diﬀerent sizes. Small projects might require the work of a few people for a few weeks or a few months. Larger projects might involve the work of thousands of people for years. Consider, for instance, the development of the F22 ﬁghter aircraft. The development started in 1986 with a ﬁrst phase to build two prototypes, which lasted 50 months. After the demonstration of the prototypes and the selection of the best model, the actual development started in 1991, with 4 Introduction to Software Project Management the ﬁrst production aircraft delivered in 2003. The total costs of the project are estimated at 67.3 USD billion, in then-year dollars, that is, without any adjustment for inﬂation (Gertler, 2012). Although in principle the development of the F22 could be organized as a sin- gle project, a more practical approach organizes its construction at diﬀerent levels of abstraction and granularity. Projects are thus often organized and combined to achieve objectives larger than those of any single initiative. A common classiﬁcation distinguishes among portfolios, subprojects, and programs. 1.1.2.1 Programs A program is a set of related projects managed in a coordinated way. The underlying motivation is that coordination allows one to achieve additional beneﬁts. The most famous program is probably the U.S. manned space program, which culminated with men landing on the moon. Program management uses many project management techniques, but it has a diﬀerent focus and goal. The higher abstraction level at which program management takes place, in fact, requires a manager to reason in terms of vision, rather than goals, and roadmaps, rather than detailed plans. 1.1.2.2 Subprojects Complex projects for which program management is an overkill can be organized and broken down into subprojects. A subproject is thus the way in which one can organize the implementation of some speciﬁc objectives of a larger project. We will see in Chapter 3 how the organization of project activities can naturally lead one to identify a set of subprojects, with the deﬁnition of the contract work breakdown structure. The distinction between a subproject and a project is often just a matter of ter- minology, since the approach and techniques are identical. A similar consideration applies to the boundaries between a project organized in subprojects and a program with diﬀerent projects. 1.1.2.3 Portfolios Organizations often use projects to develop similar systems. The term portfolio management thus identiﬁes a situation in which a set of independent projects are coordinated to achieve better results. A common situation is one in which a portfolio includes projects with simi- lar functional aspects or technical challenges. Diﬀerent groupings are possible. For instance, Project Management Institute (2004) highlights that a portfolio could include projects with the same class of risks, since they might beneﬁt from the application of similar techniques. Introduction 5 1.2 What is a Software Project When we think about software projects, probably the ﬁrst thing that comes to mind is developing applications. While this is true in many cases, software-related projects take diﬀerent forms. Even when the main goal is developing a system, coding is just one of the required activities, as we will see in Chapter 2. In this section, we look at the main types of software-related projects. 1.2.1 Application Development Application development might not be the only type of software-related project, but it is probably one that is great fun. The goal in this kind of project is building an application and providing the additional services and outputs to support it. From the project management point of view, we can distinguish the following types of applications: One-oﬀs or bespoke systems that are software systems speciﬁcally created for a customer. A bespoke system often implements a speciﬁc need of a cus- tomer, although in some cases the customer base of the ﬁnal product could be large. Some examples of bespoke systems include a luggage tracking software, a compiler for a speciﬁc hardware platform, and a system to monitor a ﬂeet of trucks. For bespoke systems, the speciﬁcation of the application to develop (more in general of the project goals) will be driven and have to be agreed with the customer. The ownership and the source code of the ﬁnal product might also be handed over to the customer. This kind of projects oﬀers an opportunity for the supplier to enter a new market or establish a long-term relationship with a new customer. Consider, for instance, activities related to the long-term maintenance of a complex software system. The uniqueness and novelty of the product also constitute the main risk both for the customer and the supplier. Oﬀ-the-shelf applications are software systems implementing a function which is useful to many diﬀerent users. It is the software we buy from mar- ketplaces or stores and it is the equivalent of the Ford Model-T: one size ﬁts all.∗ The goals and functions of the applications, in this case, come from the company developing the system, which sometimes conducts user surveys, to better understand needs and features that are most useful. Larger organizations might involve diﬀerent departments in the speciﬁcation of the software, mak- ing the activity similar to the previous case. A marketing department might play the role of the customer, deﬁning the requirements, while an engineer- ing department plays the role of the supplier and delivers the solution. The main characteristic is that the system is the same for each user and that the ∗ This is not completely true as many applications come in diﬀerent versions, for instance, a base and a pro, or with a plugin system that allows some customization. 6 Introduction to Software Project Management company developing the system sets the roadmap, choosing when to upgrade, what functions to add, and when to do maintenance. Finally, a customized oﬀ-the-shelf application sits somewhere between the two other types of applications. They are systems that are developed similar to oﬀ-the-shelf applications. However, they need to (or can) be customized to ﬁt the customer needs. An example of a customized oﬀ-the-shelf applica- tion is an enterprise resource planning (ERP) system. An ERP system helps plan the resources of an organization and automate information management. While the engine of many ERPs is generic (and developed as an oﬀ-the-shelf application), many other characteristics (modules to use, what data has to be stored, how information ﬂows) need to be customized for each client. 1.2.2 Process and Systems Reengineering Services Process and Systems Reengineering Services are projects related to improving the eﬃciency of an organization, by changing the way in which they conduct their operational work. These projects often accompany the introduction of one or more systems. In many cases, the system being introduced is an ERP. According to the project goals and size of the client, these projects might be signiﬁcant and complex. Consider the example of a multinational company revising its customer help- desk to improve quality and responsiveness. This project requires to understand how the organization currently works, what are the bottlenecks, and thus the possible interventions. These could include modiﬁcations to the current practices, training, and perhaps the introduction of a customer relationship management system to support the new processes. See also Section 2.2 for a discussion on the topic. 1.2.3 System Integration Services System integration services are projects and services related to automating the information ﬂow among the diﬀerent and independent systems used by an organiza- tion. The goals are to improve the eﬃciency of work and to reduce data duplication and errors. The approach is chosen when migrating to a new system is impractical or too costly. Two types of integration are possible, vertical or horizontal. The ﬁrst refers to the integration of diﬀerent systems performing similar functions (e.g., putting together data about customers kept by diﬀerent departments of a multinational company). The latter refers to automating or improving business functions (e.g., automating the ﬂow of orders from marketing to production). System integration services are more common in large organizations, which have a long history of system automation, or organizations in which departments have large autonomy. In these cases, in fact, diﬀerent departments might automate similar functions without paying too much attention to data integration. Over time, the Introduction 7 portfolio of applications grows and data coherence problems start to pop up. For instance, the IT systems of a company might still grant access to its premises to a person whose contract has expired, if the contracts and accesses are managed by two independent systems and someone forgot to manually update the data. According to the project scope, these kinds of projects might be large, like in the case of reengineering services, or very focused, like it could be the case of a project to interface two systems. In the ﬁrst case, the project requires an analysis of the business procedures and of the IT infrastructure. Compare the previous section and Section 2.2. In the second case, they are organized similar to an application development project. 1.2.4 Other Types of Projects Consulting services might be asked to gain know-how, which is outside a com- pany’s core competence. An example of consulting services is the evaluation of the reliability of a software system conducted using very speciﬁc techniques, which could not be part of the core business of a company. Another very common request is the assessment of the state of the art in a particular sector. Installation and training services are services related to the installation of spe- ciﬁc software systems (also in the open source domain) and/or training in the use of speciﬁc technologies or systems. 1.3 Managing Projects 1.3.1 The Project Manager and the Project Stakeholder In my career, I have met project managers with diﬀerent characters, qualities, and capacities, and I believe there is no such thing as the ideal project manager. Simi- lar to a sport, talent, studying the techniques, practicing a lot, and learning from experience determine the kind of manager one becomes. We have hinted above, however, that the characteristics of a project determine some of the features of a good project manager. Let us elaborate a bit on the concept. As we have seen, projects are characterized by constraints and uncertainty. A bit of inventiveness and some predisposition to risk and ﬂexibility can thus be of help in integrating the techniques we will present in the rest of this book. Notice that project management is about taming and mitigating risks, rather than passively accepting them. However, even when one tries and plans for the unex- pected, unplanned unknowns will happen and a good project manager deals with them. Another important distinctive feature is that projects are time limited. Thus, a sense of urgency can help set up a project fast and deliver according to the 8 Introduction to Software Project Management time constraints. The project manager, however, is also responsible for setting a sustainable pace in a project, so that the right rhythm is set and the team can work more eﬀectively. Some projects are also characterized by enormous complexity and require dif- ﬁcult choices to be taken. Cox and Murray (2004), a very nice reading about the Apollo program, describes many situations in which the project team had to take diﬃcult decisions. One example that I found particularly striking is when George Low, manager of the Apollo program, faced with the possibility of the program slipping after the deadline set by President Kennedy, decided to change the sched- ule of ﬂights, reducing the number of unmanned test ﬂights, since these would not have provided any signiﬁcant information to the program. History and system engineering proved him right. I have not yet mentioned technical proﬁciency, namely, mastering the tools and techniques, which will be used in a project. I did it on purpose. Technical compe- tence is certainly an important asset for a project manager, since it simpliﬁes various tasks, such as forming a vision on the product, choosing a sound approach to project development, and identifying the main project criticalities and risks. Management is also about delegation, and technical proﬁciency can backﬁre, if, for instance, it comes with stubbornness or an incapacity to listen or second the choices of experienced teams. People are a key contributor to the success or failure of projects. It is the work of people that makes the project outputs possible, mitigating the impact of tech- nologies that do not work as expected and ﬁnding creative solutions when the unexpected occurs. They can also contribute to the failure of a project, with their sloppiness or disinterest. A good project manager thus deals with and manages people eﬀectively. This is so important that Project Management Institute (2004) dedicates to these activities three of the 10 areas it deﬁnes to manage a project: stakeholder management, human resource management, and communications management. 1.3.2 Project Stakeholders Project Management Institute (2004) deﬁnes a project stakeholder as any individ- ual or an organization that is actively involved in a project, or whose interest might be aﬀected as a result of project execution or completion. Some stakeholders are simple to identify. Since the deﬁnition includes all people working in a project, the project manager and the project team, namely, the people responsible for carrying out the work in a project, are stakeholders. Other stakeholders are those who beneﬁt from the project execution or the project outputs. Among these are the client, the performing organization, and the project sponsor. The ﬁrst, in fact, beneﬁts from the project outputs, the second from the know-how and the revenues made in the project, and the third because of the peculiar interest he or she has in the project. Introduction 9 The remaining stakeholders might be directly or indirectly aﬀected by the project. For instance, a company producing a software system might be negatively aﬀected by a project of another organization developing a competing product. Understanding who are the project stakeholders and eﬀectively managing them is an important activity of a project manager. We will see in Chapter 3 some tech- niques to identify and manage stakeholders. Here, it is suﬃcient to mention that stakeholders have diﬀerent interests and inﬂuence. Some might be interested to see the project that fails, while others might support it strongly. The inﬂuence a stake- holder can exert is usually a combination of how close the stakeholder is to a project and how much power he or she has. 1.3.3 Code of Conducts and Ethical Aspects I do not want to go here into a philosophical discussion about what is good and evil and why one should behave good rather than bad. So I will take a rather practical approach and say that sticking to a code of conduct and behaving ethically is often also the most eﬃcient and best choice both for the manager and for the project. In an informal survey conducted among the members of the Project Man- agement Institute (PMI ), about 80% of the managers interviewed faced ethical dilemmas (Cabanis, 1996). This is not surprising as many decisions taken by project managers are in the gray area, in which distinguishing what is good from what is wrong can be diﬃcult. Consider, for instance, a situation in which a “buy in” bid is made to get a contract.∗ Surely it does not sound right. Consider the same situa- tion, however, when getting the contract makes the diﬀerence to some employees of a company, who will get ﬁred if the contract is not awarded. The situation becomes a bit more blurry.† Organizations provide diﬀerent codes of conduct. We will stick to that promoted by the PMI , one of the reference organizations for project management, which we will brieﬂy present here. The code of conduct of the PMI has been written by practitioners and is organized in four areas: 1. Responsibility: the duty of taking ownership of decisions made or failed to make and their consequences 2. Respect: the duty of treating with respect the resources assigned to us, such as people, money, reputation, environment, and so on 3. Fairness: the duty of taking decisions impartially and objectively 4. Honesty: the duty of acting in a truthful manner. ∗ A “buy in bid” underestimates project costs to make it more appealing. The costs are then raised as the project develops to match the actual expenditure. † It is still wrong should you have had any doubt. 10 Introduction to Software Project Management For each area, two types of requirements are listed. Mandatory requirements have to be met in any situation. Aspirational requirements are nice to have (Project Management Institute, 2013). Thus, for instance, while a mandatory requirement is that of getting informed and sticking to regulations and laws governing one’s work (Requirement 2.3.1), listening to and understanding other people’s point of view is an aspirational require- ment (Requirement 3.2.2). (As a side remark, the fact that the requirement of listening to and understanding other people’s point of view is only aspirational tells a lot about how daunting the task is and how patient project managers are.) Other codes of conducts are available and applicable to the profession of project managers. For instance, the IEEE Board of Directors (2006), the code of ethics of the Association of Electrical and Electronics Engineers, similar to another famous code of conduct, lists in 10 items the rules one should stick to. Although one’s values are often suﬃcient to take sound and ethical decisions, reading one or more codes of conduct is a good idea to help individuate those sit- uations that might pose ethical choices in the profession and give project managers and professionals a reference framework when needed. 1.4 Software Project Management Software project management is the integration of management techniques into software development. The need for such integration has its root in the 1960s, in the days of the “software crisis,” when practitioners recognized the increasing complexity of delivering software products meeting the speciﬁcations. A number of works started then to improve the software development practices, detailing and structuring technical activities more rationally. In parallel with this, some big engineering projects started by the U.S. Govern- ment in the 1960s contributed to the consolidation and introduction of important project management techniques. The two areas, however, were too young or grow- ing too fast to look at each other, and for a while they grew independent of each other. Similar to system engineering, software engineering shares many concerns that can be dealt with by sound management practices. As software engineering matured as a discipline, more interest grew in the systematic integration of management activities in the software production process. Software development and project management thus started to be integrated more tightly. This is exactly what we start doing in this section. People in operating systems often compare the architecture of an operating sys- tem to that of an onion. Similar to an onion, operating system architectures deﬁne diﬀerent layers of functions, each layer building on top of the lower level ones. Taking inspiration from this analogy, we try and build our own tastier comparison between software project management and the millefoglie pastry, which is made up Introduction 11 of layers of pastry and custard cream.∗ It requires quite a bit of fantasy, and maybe it does not work as well as the onion analogy, but it is certainly tastier! Similar to the pastry, in fact, we organize software project management activities in two groups. The pastry gives structure and helps deliver. The custard binds the pastry together and ensures a harmonious result. Our millefoglie is composed of four layers of pastry. The bottom layer includes all the activities that are essential to develop software. The other layers are made of management ﬂour and butter. The second layer is scope management, which includes all the activities to ensure that a project delivers according to the goals it sets. The third layer is time management, which deﬁnes a schedule for a project and delivers according to the schedule. The fourth layer is cost management, which deﬁnes a budget and controls spending during a project. With four layers of pastry, we need three layers of custard. These come in the form of technical and managerial activities to help ensure a coherent development of a project and of its results. Their common characteristics are that they run along the whole process and interact with the other activities, guaranteeing order and coherence. The ﬁrst layer of the custard is composed of change and conﬁguration manage- ment, which help manage changes in a project, while maintaining a coherent view on its outputs. These processes interact with all software development activities and also inﬂuence goals, schedules, and costs. The second layer of the custard is risk management, the set of activities to eﬀectively manage menaces and opportunities. Similar to the previous case, risk management runs throughout a project, reducing the inﬂuence of unexpected events. Finally, the third layer of the custard is made of quality management, the set of activities to ensure that a project deﬁnes quality goals and delivers accordingly the goals. Finally, human resource management and stakeholder management are the powdered sugar sprinkled at the top. Try it without it, and it does not taste as good. To continue the analogy, we can split our millefoglie into four slices, correspond- ing to the four phases we have introduced in Section 1.1.1. Each slice will still have all the layers. As a matter of fact, all the management concerns we have introduced in our analogy have an initiating, a planning, a monitoring, and a closing phase. (Software development is a bit of an exception, since it is mainly concentrated in the execution phase.) This is shown in Figure 1.2, where we present our millefoglie. The horizontal axis represents the various project phases, while the vertical axis presents the pastry ∗ Good food seems to be particularly relevant for people working in the area. A report about the meeting where the “software crisis” term was coined includes the following quote: “The con- ference had been held outside Rome in a rather charmless American-style hotel whose facilities and cuisine I’m sure did little to engender a harmonious atmosphere” (Randell, 1996). 12 Introduction to Software Project Management Initiate Plan Execute and Close monitor Assess Formalize Collect Close feasibility goals outputs Monitor goals, cost, and Develop Release schedule Deﬁne Kick off schedule activities Deﬁne costs (Obtain approval) Change control and conﬁguration management Quality management Risk management Human resource management Figure 1.2 The software project management millefoglie. and custard, one per row. In Figure 1.2, we have deconstructed the millefoglie a bit, so that we can present more elementary activities and suggest one ordering in which the activities can be executed. The ﬁrst row contains the management of the project goals. The process spans all the four phases, including an assessment of the feasibility, the formalization of the project goals, the collection of the outputs, and closing the project. The second row shows the software development activities, in which we have highlighted only two of the phases, namely, development and release. The third row contains time management. We distinguish three activities, namely, the deﬁnition of a schedule, kickoﬀ of activities and, in the dotted box, monitoring and control. The fourth row contains cost control, including the deﬁnition of the budget and its monitoring (dotted box). The remaining four layers contain the activities to manage changes, control software conﬁgurations, assess quality, tame risks, and manage human resources. Introduction 13 The arrows show a possible ordering of the activities. As we will see, it is one of diﬀerent possible ways to organize work. Notice that not all layers are always necessary to have a good project. Practi- tioners distinguish between traditional and agile management. The ﬁrst favors structure, while the second prefers more lightweight approaches. Thus, some projects are better managed by reducing the fat and the infrastructure, while others can succeed only if you have the full deal. This also holds true for the millefoglie: more is not always better. To conclude, I hope that you enjoyed the analogy with gusto. In the next chapters, we will have a look at the techniques in each area. 1.5 Goals and Organization of the Book This book is organized in two parts. The ﬁrst part introduces the building blocks and techniques to develop and manage software projects, while the second puts them together in an organized process. To go back to Figure 1.2, the ﬁrst part describes the boxes, while the second part shows how these boxes can be organized in diﬀerent ways. The goal of this approach is to achieve ﬂexibility and to allow readers to be creative by selecting and mixing the techniques they ﬁnd more eﬀective for their projects. For this reason, traditional and agile techniques are presented side by side. The ﬁrst part of the book develops in the next four chapters. In more detail, Chapter 2, introduces the main activities characterizing software development projects. It covers the execution phase of a project and also helps understand why a sound management structure is also necessary for software development. Chapter 3 covers the essentials, namely, how to manage goals, time, and costs. Starting from project selection, which describes some of the factors to consider before starting a project, the chapter develops by introducing techniques to deﬁne project goals, making them into a speciﬁcation and a schedule of the work to be performed. A discussion on algorithmic techniques helps us understand how we can come out with reliable estimations and, consequently, with a budget for the project. The chapter covers the diﬀerent project phases, including monitoring and control. Thus, it introduces the basic management techniques from end to end. Chapter 4 introduces the variability and uncertainty that characterize any project and describes the techniques that can be used to ensure that these do not aﬀect a project and its outputs. We will look, in particular, at techniques to deal with change requests and changes and demonstrate why a sound conﬁguration manage- ment is essential. We will continue by analyzing the main techniques to deal with risks. A discussion on quality and on the techniques to ensure that quality goals are met concludes the chapter. Some might argue that quality management is an essen- tial process deserving to be presented alongside goals, time, and costs management. I understand the point of view. Quality and quality management, however, not only 14 Introduction to Software Project Management set the baseline characteristics of the project outputs but also ensure that they are met in spite of the unexpected. I prefer to emphasize this second aspect. Chapters 5 and 6 close the ﬁrst part of the book. Chapter 5 introduces some theories about what motivates people and the techniques to manage team and stake- holders, establishing appropriate project structures and communication channels. Chapter 6 introduces some concepts related to software pricing and procurement activities. The second part of the books puts the techniques together in a coherent process. Over the years, the way in which software projects are organized has changed con- siderably. Chapter 7 thus describes how to organize software development projects, introducing traditional and agile processes. Thus, the technical and managerial activities presented in the ﬁrst part of the book are put together in diﬀerent ways to try and tame the complexity of software development. Chapter 8 concludes the description of processes by presenting standards and frameworks for software project management. Automation has always been important to present and track information in a project. Today, it has become an essential infrastructure to also organize and allocate work. Chapter 9 thus closes this book by presenting some open source tools to support planning, management, and the organization of work. The simplest way to read the book is, of course, from end to end. Each chapter, however, should be suﬃciently self-contained to be readable and understandable by itself. The chapters in the second part of the book (Chapters 7 through 9) make more sense after reading the ﬁrst part of the book. 1.6 Further References The literature on project management, software engineering, and software project management is huge. There are some references that I have found myself resort- ing to over and over again during my career as a teacher and as a professional. So, while you will ﬁnd speciﬁc references in the chapters, if you are building your software project management bookshelf or if you want to complement this book with some additional readings in the area, the following references are some starting points. Project management books: Burke (2006) is a very well-written introduction to project management. With its many diagrams and techniques, it clearly explain many topics of project management. I have found particularly interesting the discussion on project selection and budgeting techniques. All in all, the book is clear and fun to read. Wysocki (2011) is another very readable book on project management. With its 734 pages, it is also a considerable challenge to reading, but worth the eﬀort or worth consulting, if you prefer to pick topics here and there. I found the Introduction 15 description of traditional, agile, and extreme project types particularly inter- esting. Critical chain management and project closing are two other topics to look at. Maylor (2010) provides many insights from case studies while presenting techniques to manage projects. The presentation is based on the 4-D model: deﬁne it, design it, do it, and develop it. Project Management Institute (2004) is the deﬁnitive reference guide on project management. Sponsored by the PMI , it illustrates the techniques that are most appropriate at each phase of project development. Given the breadth, the book only hints at the techniques and is a starting point to look for further references. The organization in process groups and knowledge areas, which we will see in Section 8.2, is very eﬀective. There are also various books explicitly focused on software project management. Among them Brooks (1995) is a seminal book on the topic, covering and introducing var- ious important concepts that distinguish software project management from other management areas. Worth reading. Henry (2003) is the ﬁrst book on software project management that I came across. It also raised my interest to the function points estimation techniques, which are clearly introduced there. We will cover function points estimation in Section 3.4.5.1. Hughes and Cotterell (2009) is a nice introduction to the topic. With a nice discussion on software quality and procurement, it introduces many of the concepts related to software project management. A huge number of books cover software development and the management of software projects. I will mention only a few: McConnell (1996) presents critical aspects of software development, suggest- ing how becoming more agile can help tame wild software schedules. Rich in examples, the description of how stakeholders can make the project goals impossible to achieve is very interesting. Rothman (2007) provides a very practical approach to managing a project, with many insights and techniques to cope with the diﬃculties of software development projects. Ruby et al. (2013) provides the clearest and most readable example of agile development that I came across recently. So, while the book presents Ruby on Rails, a web development framework, its presentation is organized as a Scrum sprint. We will cover Scrum in Section 7.3.3. Finally, I need to mention the many reports and books on the topic made avail- able by NASA. While only partially overlapping with project management, NASA (2007) is very interesting to read. So are various other reports, including NASA (1990). 16 Introduction to Software Project Management 1.7 Questions and Topics for Discussion 1. Recap the main characteristics of a project. 2. Try and see which of the activities you commonly do could be organized as projects and which are operational work. Consider the following exam- ples: writing an essay; studying at the university; preparing a meal; preparing dinner every evening; painting a house; exercising; training for the Olympic games. 3. Consider the construction of a web application that allows people to donate food. Who could be the stakeholders of the project? 4. Many software development processes are iterative. Each iteration delivers a software system that gets reﬁned as development progresses. Go back to Figure 1.2 and think about how you could modify the process to make it iterative. How many possible loops can you envisage? References Brooks, F. P. J., 1995. The Mythical Man Month (Anniversary ed.). Addison-Wesley, Boston, MA, USA. Burke, R., 2006. Project Management, Planning and Control Techniques (4th ed.). John Wiley & Sons, New York, NY, USA. Cabanis, J., 1996, December. A question of ethics: The issues project manager face and how they resolve them. PM Network, 19–24. Cox, C. B. and C. Murray, 2004, September. Apollo. South Mountain Books, Burkittsville, MD. Gertler, J., 2012, October. Air force. Technical Report RL31673, Con- gressional Research Service. Last retrieved July 11, 2013. Available at http://www.fas.org/sgp/crs/weapons/RL31673.pdf Henry, J., 2003. Software Project Management: A Real-World Guide To Success. Pearson Education, Addison-Wesley, Boston, MA, USA. Hughes, B. and M. Cotterell, 2009. Software Project Management. McGraw-Hill Higher Education. IEEE Board of Directors, 2006, February. IEEE code of ethics. Available at http://dusk.geo.orst.edu/ethics/codes/IEEE_code.pdf. Last retrieved May 31, 2013. Maylor, H., 2010. Project Management (4th ed.). Pearson, Harlow, England. McConnell, S., 1996. Rapid Development—Taming Wild Software Schedules. O’Reilly, Sebastopol, CA, USA. NASA, 1990. Manager’s handbook for software development. Software Engineering Labo- ratory Series SEL-84-101, NASA Goddard Flight Center. NASA, 2007, December. Systems engineering handbook. Technical Report NASA/SP-2007- 6105 Rev1, NASA. Project Management Institute, 2004. A Guide to the Project Management Body of Knowl- edge (PMBOK Guides) (4th ed.). Project Management Institute, Newtown Square, Pennsylvania 19073-3299 USA. Introduction 17 Project Management Institute, 2013. Project Management Institute—code of ethics and professional conduct. Available at http://www.pmi.org/en/About- Us/Ethics/∼/media/PDF/Ethics/ap_pmicodeofethics.ashx. Last retrieved May 31, 2013. Randell, B., 1996. The 1968/69 NATO software engineering reports. Last retrieved July 11, 2013. Rothman, J., 2007. Manage IT! Your Guide to Pragmatic Project Management. The Pragmatic Bookshelf, Raleigh, NC. Ruby, S., D. Thomas, and D. H. Hansson, 2013. Agile Web Development with Rails. The Pragmatic Bookshelf, Raleigh, NC. Wysocki, R. K., 2011, October. Eﬀective Project Management: Traditional, Agile, Extreme (6, illustrated ed.). John Wiley & Sons, New York, NY, USA. Chapter 2 The Basics: Software Development Activities and Their Organization Software development projects range from the very small to the very large and encompass a wide range of complexity, starting from software developed by a small team in their spare time and ending with projects lasting several years and involving the work of many people. Similarly, the concept of what it means for a software development project to succeed also varies according to the context. For the small team developing an open source solution, it could be the intellectual challenge of solving a complex problem or the satisfaction of contributing to a community. Time is not critical, nor are costs: having fun in the process probably is. For people developing safety-critical systems, the challenge is diﬀerent. They need to ensure that the system will perform as expected in a wide array of opera- tional conditions, including those in which there are malfunctions. Quality and a controlled process are paramount in this context. Finally, for people developing a web application or another desktop system, the most important aspect could be the the price that can be set for the product or making sure that the product is released before the competition. In this context, time and costs might be the main drivers. Thus, the activities that are required or beneﬁcial to develop successful software vary from project to project. Some projects might allow a more informal approach, while others are better served by a very structured and controlled process. Going 19 20 Introduction to Software Project Management back to the millefoglie example, the goal of this chapter is to present the “pastry,” that is, the activities that are needed to develop software. These are the technical building blocks for constructing software, that is, what we do in the “execute” phase of a software development project. These building blocks will be selected, composed, and organized in diﬀerent ways, according to the project size and formality, the process adopted, and other management choices in Chapter 4. 2.1 Software Requirements Definition The ﬁrst step of any nontrivial software development project is to form an idea about the system that has to be developed. Software requirements deﬁnition includes the methods to identify and describe the features of the system to be built. The main output of this activity is one or more artifacts describing the (software) requirements of a system, namely, the functions it has to implement and the other properties it has to have. Software requirements are strongly related to the scope document, which deﬁnes the goals of a project and which we will see in Chapter 3. There are two main output formats for these artifacts, textual or diagrammatic. When the textual format is used, the requirements are written in English, in some cases using a restricted set of language or predeﬁned linguistic patterns. For instance, special words, such as “shall,” might be required to indicate an essential requirement—see, for example, Brader (1997). Concerning the structure, the requirements are often presented as lists of items, one per requirement. Another very common representation writes requirements in the form of user stories, using the following pattern: As a [user] I want to do [this] because of [that]. The advantage of this approach is that each requirement clearly identiﬁes the user, the function that has to be performed, and the motivation for the function to be implemented, something that helps identify the priority or importance of a requirement. The diagrammatic notation describes requirements with a mix of diagrams and textual descriptions. Diagrams depict the interaction between the user and the sys- tem and the textual description explains the interaction using a sequence of steps. The most common graphical notation is that of the use case diagrams of UML and the corresponding textual descriptions are called use cases (Booch et al., 1999; Fowler and Scott, 2000). The requirement engineering discipline includes the activities necessary to deﬁne and maintain requirements over time. Simplifying a bit, requirements engi- neering entails a cyclical reﬁnement process in which the following steps are repeated at increasing levels of detail till a satisfactory level of know-how about a system is achieved. The Basics 21 In more detail, the process is composed of four steps: 1. Requirements elicitation 2. Requirements structuring 3. User experience design 4. Requirements validation. 2.1.1 Requirements Elicitation Requirements elicitation is the activity during which the list of features of a sys- tem are elicited from the customer. This activity can be performed with interviews, workshops, or the analysis of existing documents. 2.1.2 Requirements Structuring Requirements structuring is the phase during which the requirements are anno- tated to make their management and maintenance simpler. During the process, requirements are Isolated and made identiﬁable. Each requirement is clearly isolated and dis- tinguished from the others and is also assigned a unique identiﬁer. This allows one to reason and manipulate each requirement more easily. Concerning identiﬁcation, a commonly used practice is that of assigning each require- ment a number or a combination of some characters (describing the type of requirements) and a number. Organized and classiﬁed. A simple classiﬁcation distinguishes between functional and nonfunctional requirements. The former are requirements describing what the system has to do. The latter are requirements describ- ing what other properties the system should exhibit (e.g., “the system will have to run on Windows devices”). Functional requirements are usually orga- nized in functional areas. Each functional area groups requirements describing a homogeneous set of functions. For instance, a requirement document might have an “accounting functions” section describing all requirements pertaining to accounting functions. Nonfunctional requirements are often organized in four groups: usability, reliability, performance, and supportability. Annotated. Requirements are annotated to simplify their management and to support planning activities, like, for instance, which requirements should be implemented ﬁrst. It is a good practice to assign each requirement at least two properties, namely, the importance for the customer and the diﬃculty to develop, for instance, using values from 1 to 5. We will see other types of classiﬁcations in Section 3.2.1. Requirements evolve over time and a sound approach to requirement man- agement also necessitates deﬁning a proper strategy to control the evolution of 22 Introduction to Software Project Management Description [ID] As a [user] I want to do [this] because of [that] Attributes Importance: [IMPORTANCE] Priority: [PRIORITY] Traceability: [THIS REQUIREMENT RELATES TO...] Revision History - [DATE] [AUTHOR] [DESCRIPTION] Figure 2.1 A template for a requirement. requirements. We will see some of the issues in Section 4.1. Here, it is suﬃcient to mention that requirements are often annotated with Traceability information, which has the goal of highlighting where a require- ment originates from. Traceability shows the relationships among require- ments and the relationships among requirements and other artifacts of software development. This allows one to understand the impact of changes. See Gotel and Finkelstein (1994) for a formal deﬁnition and more details. History log, which records the changes each requirement has undergone. The history log traces how requirements have changed over time. Figure 2.1 shows an example of a template of an annotated requirement. 2.1.3 User Experience Design User experience design has the goal of providing a coherent and satisfying experi- ence on the diﬀerent artifacts that constitute a software system, including its design, interface, interaction, and manuals. It is deﬁned in International Organization for Standardization (2010) as the extent to which a product can be used by speciﬁed users to achieve speciﬁed goals with eﬀectiveness, eﬃciency, and satisfaction in a speciﬁed context of use. The typical user experience design activities include User-centered analysis, which has the goal of understanding how users will interact with the system. It runs in parallel with the requirements deﬁnition and requires the organization of workshops and other activities (e.g., surveys) to proﬁle the users, analyze which tasks they will perform, and deﬁne which style guides will be followed in designing the system. User-centered design, which has the goal of specifying how users will actually interact with the system. It runs in parallel with the requirements deﬁnition and system design (see the next section). The outputs include storyboards The Basics 23 describing the interaction, mock-ups, and prototypes. (A mock-up is a full- size model of something that has not yet been built, showing how it will look or operate (Cambridge University Press, 2013).) 2.1.4 Requirements Validation Requirements validation is the phase during which the requirements are analyzed to ﬁnd Inconsistencies, for example, two requirements require a system to behave in contradictory ways. In a common situation, a requirement document includes two requirements, the ﬁrst prescribing a general behavior (e.g., “the system should always abort in case of error”) and the other suggesting the opposite one in a speciﬁc situation comprised also in the general requirement (e.g., “the system should recover from a sensor-reading error”). Incompleteness, when no information is given about a speciﬁc situation. Duplicates, when one requirement describes a function already described by another requirement. Diﬀerent techniques can be used to validate requirements. We mention inspec- tions and formal analyses. Document inspections are based on the work of a team that analyzes the content of documents and highlights any issue. The technique relies on the ability and experience of the team. Formal analyses use mathematical notations (such as ﬁrst-order logic) to represent requirements and automated tools (such as theorem provers and model checkers) to prove properties about the require- ments. Several notations and approaches are available; see, for instance, Clarke et al. (2000), Bozzano and Villaﬁorita (2010), and Spivey (1989) for more details. Notice that the goals of this phase overlap with those of quality management. We will see more about veriﬁcation and validation techniques in Section 4.3. 2.2 Business Modeling In the 1990s, the university where I teach—a complex organization in which diﬀer- ent oﬃces have considerable organizational autonomy—kept personnel records in diﬀerent databases: one for contracts, another for teaching assignments, another for granting entrance to laboratories, to name some. The database was not connected; any change had to be propagated manually to all databases, causing inconsistencies, omissions, and a lot of extra work to try and keep data in sync. Enterprise resource systems (ERP) are systems that can automate and simplify the processes of an organization, integrating the data and the procedures of diﬀerent business units. These systems are usually composed of standardized components, which implement the main procedures of an organization in a particular business sector (e.g., government, logistics, services). Their introduction in an organization 24 Introduction to Software Project Management typically requires them to act not only on the system, personalizing data, procedures, and functions, but also on the organization, by changing the existing procedures to take full advantage of the system being introduced. In this kind of project, understanding how work is carried out in an organization is often more relevant than eliciting the requirements of the system to be built, since an important part of the project work will focus on mapping the current procedures and changing them to accommodate those that supported by the ERP. The activity to understand how an organization is structured and works is called business process modeling or business modeling in short. Those to modify the current procedures go under the name of business process re-engineering. Business modeling and business re-engineering are usually organized in two main steps. An initial “as is” analysis describes the organization before the intro- duction of a new system. The “as is” analysis helps one understand the current infrastructure and needs. A complete analysis will include A description of the organizational structure, highlighting the chain of responsibility and accountability. A description of the business processes, describing how the organization carries out the diﬀerent procedures. A map of the existing IT infrastructure, highlighting hardware, systems, and databases. A list of the business entities, highlighting the data produced and processed by the organization. Following the “is” analysis, a “to be” phase deﬁnes how the organization will change with the introduction of the new system. The “to be” analysis produces the same set of information required by the “as is” analysis, but it describes the processes, the systems, and the business data that will be introduced to make operations more eﬃcient. Let us see in more detail the information produced with the “as is” and the “to be” analyses. 2.2.1 Mapping the Organizational Structure Mapping the organizational structure has the goal of understanding how an organization is structured. The information to collect includes the list of the diﬀerent business units and the lines of responsibility. More detailed analyses also include the roles or the staﬀ employed by each business unit and the functions assigned to each role or person. The output is a text document or an organizational chart describing the units and their functions. It is used to identify the changes that will have to be implemented in the organization to support the new processes. The Basics 25 2.2.2 Modeling the Business Processes Modeling the business processes has the goal of documenting how an organization carries out its procedures. These are typically represented with ﬂow diagrams sketched, for instance, using the business process modeling notation—BPMN (OMG, 2011). Business pro- cesses highlight, for each process, which steps need to be performed, by whom, and what outputs are produced and consumed. The speciﬁcation should model both nominal and exceptional situations. For instance, if the target of the analysis is a paper-based procedure to authorize a trip, a good process description will docu- ment what happens when everything ﬂows as expected and how the organization recovers if some error occurs—for example, a paper form is lost in the middle of a procedure. A diﬃcult aspect of this analysis is capturing not only the formal procedures but also the current practices, namely, how people actually carry out the procedures. The ethnography software engineering ﬁeld focuses on methods to simplify this activity. See, for instance, Rönkköa (2010) for an introduction on the matter. The output

Introduction to Software Project Management PDF

Document Details

Tags

Related

Summary

Full Transcript