Mastering Software Project Management: Best Practices, Tools and Techniques
408
Mastering Software Project Management: Best Practices, Tools and Techniques
408Hardcover(New Edition)
-
SHIP THIS ITEMIn stock. Ships in 6-10 days.PICK UP IN STORE
Your local store may have stock of this item.
Available within 2 business hours
Related collections and offers
Overview
Product Details
| ISBN-13: | 9781604270341 |
|---|---|
| Publisher: | Ross, J. Publishing, Incorporated |
| Publication date: | 07/01/2010 |
| Edition description: | New Edition |
| Pages: | 408 |
| Product dimensions: | 6.00(w) x 9.00(h) x 1.10(d) |
About the Author
Read an Excerpt
CHAPTER 1
SOFTWARE PROJECT BASICS
INTRODUCTION
Human endeavor, from its earliest hunter/gatherer roots, was carried out in teams, each with a hierarchy of roles. As civilization progressed, the need for structure and rules increased. A large farm is a team organization based on a simple hierarchy of an owner, overseers, and employed laborers. The Industrial Revolution created factories which required more complex hierarchies, both within teams and between teams. Factories aggregated the production of goods for consumption into concentrated units capable of greater productivity. To achieve this great jump in productivity, rules were developed to effectively run the factories. These developments were the genesis of the art and science of managing production, which has been called production management.
Classification of organizations. The type of production can be used to classify organizations based on the manner in which goods are produced. The categories are:
• Mass production: continuously produces the same products
• Batch production: produces goods in batches; each batch is similar, but not identical
• Flow process production: production of chemicals, pharmaceuticals, and fertilizer products, generation of electricity, etc.
• Job order production: produces tailor-made goods (i.e., goods are produced only when an order is received)
Initially, management texts focused on mass production, batch production, and flow process production systems (also known as "made to warehouse" production systems). In made to warehouse production systems, goods are produced and stored in warehouses for distribution. The significant feature of mass production and flow process production is that the rate of consumption/demand equals or exceeds the rate of production for the product. In batch production, the rate of production exceeds the rate of consumption/demand for the product. The goal of production management is to balance both rates.
Production management texts, however, did not address organizations such as ship building, aircraft manufacturing, heavy equipment manufacturing, etc. These organizations are known as job order production or made to order organizations. In made to order organizations, items are produced only after an order is received.
By leaving out job order "shops," management texts also excluded organizations that constructed buildings, highways, and other infrastructure facilities. These types of organizations are certainly not serial production organizations even though they create wealth and employ people. Their work was classified as projects. Some knowledge, however, was gathered and released under the title of project management. Job order production system organizations latched onto this concept and became project-based production systems.
Presently, management theory addresses organizations in two basic categories: production organizations and service organizations. The art and science of managing these organizations has metamorphosed from production management to operations management.
Similarly, we can categorize organizations by the nature of their operations:
• Continuous operations: organizations with fixed facilities that carry out similar operations day after day continuously and produce products for stockpiling in warehouses (real or virtual)
• Project operations: organizations with fixed but flexible facilities that carry out dissimilar operations from day to day and produce only against a customer order
More and more organizations are moving toward project operations due to market forces, which put emphasis on individual preferences while reducing costs. Gone are the days of the famous words of Henry Ford, Sr.: "You can have the car of any color as long as it is black."
The project operations category has seen significant development over the past few years under the title "mass customization." Mass customization blends aspects of continuous and project operations.
Having put the concept of project operations in an historical perspective, seeTable 1.1 for a comparison of continuous operations with project operations. Mass customization walks the line between the two extremes identified in Table 1.1, typically with most of the benefits of each, but with a greater reliance on self-directed teams that make hierarchies and matrix organizations very nervous.
Description of a project. Let's now examine what comprises a project: a project is a temporary endeavor with the objective of manufacturing (producing or developing) a product or delivering a service, while adhering to the specifications of the customer (including functionality, quality, reliability, price, and schedule) and conforming to international/national/customer/internal standards for performance and reliability. Translation:
• A project is a temporary endeavor.
• A project has a definite beginning and a definite ending.
• No two projects will be identical, although they may be similar.
• Each project needs to be separately approved, planned, designed, engineered, constructed, tested, delivered, installed, and commissioned.
• A project may be stand-alone or a component in a larger program.
• A project is executed in phases, with an initiation phase and one or more intermediate phases and a closing phase.
• Many projects have a transition phase (e.g., handover to customer).
• A project may extend through a maintenance phase.
A software development project (often shortened to software project) has the objective of developing a software product or maintaining an existing software product. Software development projects have several general attributes, including: •The project has a definite beginning and a definite end.
• The project deliverable is functional software and related artifacts.
• Activities that may be included in a project are user and software requirements, software design, software construction, software testing, acceptance testing, and software delivery, deployment, and handover.
• Activities not included in a project are the activities of project selection/acquisition and post-handover.
Some of the more unique attributes of software development projects include:
• The primary output is not physical — in the sense that the primary deliverable is functional software and no tangible components are delivered — almost everything is inside a computer.
• Process inspection does not facilitate progress assessment — functional software or at least the code is the real measure of progress. In a manufacturing organization, one can see semifinished goods. The proof of work being performed is in the noise made by machines. In a software development organization, visual assessment is not enough to ensure that a person is performing. One needs to walk through the code being developed to ensure that the person is working.
• Despite significant progress in software engineering tools and diagramming techniques, they do not rise to the level of precision of the engineering drawings used in other engineering disciplines.
• Professional associations in software development and standards organizations have not defined standards or practices for developing software as has occurred in other engineering practices. The International Organization for Standardization (ISO) and the Institute of Electrical and Electronic Engineers (IEEE) have defined a number of standards, but these standards are not at the same level of granularity as other engineering standards.
• Although significant improvements in software development methodologies have been made, these methodologies are still largely dependent on human beings for productivity and quality. Tools are available to help in development or testing, but they still have not been able to rise to the level set by the standards and tools used in fabrication/ inspection/testing in other engineering disciplines. In other engineering disciplines, tools are available that shift the onus for productivity/ quality from human beings to the combination of tools and process. Most would agree that an average-skilled person can achieve higher productivity/quality with tools than a super-skilled person without tools.
Therefore, the rigor of planning is all the more important in software development than in other engineering projects — planning is a critical tool to keep a project focused. In other engineering projects, a simple schedule based on PERT/ CPM (Program Evaluation and Review Technique/Critical Path Method) would suffice, whereas in software development projects, increased rigor and more planning documents are required (planning documents commonly required are described in subsequent chapters).
TYPES OF SOFTWARE PROJECTS
Software development projects (SDPs) are not homogenous. They come in various sizes and types. Some examples will help us gain an understanding of the breadth of SDPs:
• An organization desires to shift a business process from manual information processing to computer-based information processing. This project will include studying the user requirements and carrying out all of the activities necessary to implement the computer-based system
• An organization desires to shift a business process from manual information processing to computer-based information processing. The organization does not want the software be developed from "scratch." It wants to use a commercial off-the-shelf software (COTS) product. This project will include implementation and perhaps some customization of the COTS product to make it appropriate for the organization.
• An organization has a computer-based system that needs to be shifted to another computer system because the existing system has become obsolete and support to keep the obsolete system in working condition is no longer available. This project could include porting the code, training users, and testing the new implementation.
• An organization has a computer-based system and desires to shift it from a flat file system to a RDBMS-based system (relational database management system). Activities will include data conversion in addition to other activities.
• An organization has a computer-based information processing system and needs to effect modifications in the software or add additional functionality. Activities include adding functionality and making required modifications in the software of a third party (if required).
• An organization has developed a computer-based information processing system and wants to get it thoroughly tested by an independent organization. Activities will include testing and interfacing between the organizations.
These examples barely scratch the surface of the breadth of software projects — and new project types keep coming in. In all cases, however, the projects concern software, but the tasks, activities, and therefore the work in each of the projects are vastly different.
CLASSIFICATIONS OF SOFTWARE PROJECTS
Software projects may be classified in multiple ways (Figure 1.1). For example, software projects may be classified as:
* Software development life cycle (SDLC) projects
• Full life cycle projects
• Partial life cycle projects
* Approach-driven software development projects
• "Fresh" development (creating the entire software from "scratch")
• COTS product customization/implementation
• Porting
• Migration
• Conversion of existing software to meet changed conditions such as Y2K and Euro conversion
* Maintenance projects
• Defect repair
• Functional expansion
• Operational support
• Fixing odd behavior
• Software modification
* Web application projects
* Agile development projects
Let's now discuss each type of software project in greater detail.
Based on Software Development Life Cycle
Full life cycle projects. A full life cycle project is a project that traverses the entire arc of the methodology being used: starts at the beginning and ends at the end. One problem when discussing a full life cycle project is that there is no standardization concerning what constitutes a software development life cycle (SDLC). Generally agreed is that user requirements analysis, software requirements analysis, software design, construction, and testing (regardless of what they are called) are parts of a SDLC. Some of the components of an SDLC that remain in question include:
• A feasibility study determining whether the project is worthwhile
• Special testing that is beyond unit testing, integration testing, system testing, and acceptance testing
• Implementation, including installation of hardware, system software, application software, etc.
• Software commissioning, including creating master data files, user training, pilot runs, parallel runs, etc.
In many instances, when the end product is used within the same organization, these four components are considered part of an SDLC. Alternately, in other circumstances, these components are excluded for organizations that specialize in software development and/or develop software for use by a different organization (unless contractually included or part of a software as a service architecture).
In this book, we exclude these four components. We assume that a full life cycle project is one that starts with user requirements and ends with the delivery of software. Therefore, all post-delivery activities and pre-user requirement activities are not considered to be within the scope of this book.
Partial life cycle projects. Partial life cycle projects are those that include only a portion of the SDLC. In partial life cycle projects, any number of permutations could occur, including:
* Testing projects in which the scope of the work involves conducting the specified or necessary software tests on the software product to certify the product (Unit testing and code walk-through are normally not included in this type of project.)
* Independent verification and validation (IV&V) projects in which projects go beyond mere testing, including code walk-through and other forms of validation to determine the efficiency of coding
* A project divided between two or more vendors based on the specialty to derive the advantages of best practices developed through specialization which can lead to defining the project by phase or by combination of phases, such as:
• Requirements analysis
• Design
• Software construction
• Testing
Approach Driven
Fresh or new software development projects. Fresh or new software development projects are identical to full life cycle development projects previously discussed.
COTS product customization/implementation projects. Numerous popular COTS products are available in the marketplace. Examples include the implementation of ERP (enterprise resource planning software, e.g., by SAP and PeopleSoft), CRM (customer relationship management), SCM (supply chain management), EAI (enterprise applications integration), and data warehousing software. Typical phases in these projects include:
1. Current system study: a review of the present system
2. Gap analysis: a comparison of the current system to the COTS product
3. Customization report: a discussion of the desired levels of customization of the system
4. Statement of work: definition of the required customization of the COTS product
5. Design: how the software will accomplish the task
6. Construction and integration
7. Testing
8. Custom code integration: integration of the code bases (in some cases it can include building a layer over the COTS product and integration of custom developed code into the source code of the COTS product)
9. COTS source code modification (rare)
10. Implementation
11. Training: instruction of users (all classes required) in usage of the system, troubleshooting, and operations and maintenance of the system
12. Transition of the system
Many variations of these phases are also possible for COTS projects.
Porting. Porting projects deal with moving software from one hardware platform to another hardware platform. Porting projects can include:
• Changes in programming language
• Differences between implementations
• Manual intervention to make the existing software work on new hardware without issues
Project execution work in a porting project involves:
1. Documenting the differences between the two versions of the programming languages
2. Developing a software tool to make corrections in the code based on the details mentioned above (Sometimes, vendors of the programming language supply this type of tool.)
3. Execution of the software porting tool to make all possible corrections
4. Manual correction to make any specific corrections needed
5. Conducting the specified software tests
6. Modifications to the software engineering documents required to reflect the changes made in the software
7. Conducting acceptance testing
8. Delivery of the software
(Continues…)
Excerpted from "Mastering Software Project Management"
by .
Copyright © 2010 Copyright J. Ross Publishing.
Excerpted by permission of J. Ross Publishing, Inc..
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
Foreword ix
Preface xiii
About the Authors xv
Web Added Value? xvii
Chapter 1 Software Project Basics 1
Introduction 1
Types of Software Projects 5
Classifications of Software Projects 6
Based on Software Development Life Cycle 7
Approach Driven 9
Maintenance 12
Web Application 16
Agile Development 17
Conclusion 17
Chapter 2 Approaches to Software Project Management 19
Alignment of Software Engineering Methodology with Project Management Methodology 19
The Ad Hoc Methods-Based Approach 21
The Process-Driven Approach 22
So, What is the Right Approach? 23
The Ad Hoc Approach 24
The Process-Driven Approach 24
But Is a Process-Driven Approach the Right Choice? 24
In a Process-Driven Approach: What Process and How Much? 26
Chapter 3 Software Project Acquisition 31
From an External Client 31
The Request for Proposal 32
The Proposal 34
Negotiation 42
Contract Acceptance 43
From an Internal Client 44
The Feasibility Study 45
Preparing the Proposal 47
Finalizing the Proposal 47
Reference 48
Chapter 4 Software Project Initiation 49
Introduction 49
Initiation Activities 49
Project Management Office-Level Activities 52
Identifying the Software Project Manager 52
Preparing/Handing Over the Project Dossier to the Software Project Manager 52
Coordinating Allocation of Project Resources 53
Assisting the Software Project Manager in Obtaining Necessary Service Level Agreements from Departments in the Organization 55
Assisting the Software Project Manager with the Project Kickoff Meeting 55
Software Project Manager-Level Activities 55
Ensuring that Project Specifications Are Complete 57
Reviewing Estimates and Revisions/Updates of Estimates 57
Identifying Necessary Resources and Raising Requests 59
Preparing Project Plans 62
Setting up the Development Environment 63
Arranging for Project-Specific Skill Training 63
Organizing the Project Team 64
Training the Project Team on the Project Plans 64
Conducting a Project Kickoff Meeting 65
Arranging for a Phase-End Audit 65
Common Pitfalls in Project Initiation 66
Identifying the Wrong Software Project Manager 66
Identifying Inappropriate Resources 66
Incurring Delays in Software Project Initiation Activities 67
References 67
Chapter 5 Software Project Planning 69
Introduction 69
Planning Defined 71
Plans Prepared in Software Project Management 73
The Project Management Plan 77
Resources 77
Skill Sets 77
Computer Systems 79
Project Management Method 79
The Configuration Management Plan 80
Naming Conventions 83
Change Management 84
The Quality Assurance Plan 85
The Schedule Plan 86
The Induction Training Plan 86
The Risk Management Plan 87
The Build Plan 88
The Deployment Plan 88
The User Training Plan 89
The Handover Plan 90
The Software Maintenance Plan 90
The Documentation Plan 90
Roles in Planning 91
The Organization 91
The Software Project Manager 92
Pitfalls in Software Project Planning 93
Best Practices in Software Project Planning 95
References 96
Chapter 6 Software Project Execution 97
Introduction 97
Work Management 98
Work Registers 100
De-allocation 102
Configuration Management 104
Information Artifacts 104
Code Artifacts 106
Configuration Registers 111
Configuration Management Tools 115
Quality Management 117
Verification Techniques 119
Validation Techniques 120
Product Testing 121
Allocation of Quality Assurance Activities 124
But How Much Quality Assurance? 124
Testing Tools 125
Morale Management 126
Motivation 126
Conflict 130
Productivity Management 131
Stakeholder Expectations Management 133
Product Integration Management 138
Pitfalls and Best Practices 140
Chapter 7 Software Project Execution Control 143
Introduction 143
Aspects of Control in Project Execution 144
Scope Control 145
Cost Control 146
Schedule/Progress Control 147
Quality Control 148
Effort Control 148
Productivity Monitoring 148
Control Mechanisms 149
Progress Assessment: Earned Value Analysis 153
Chapter 8 Change Management in Software Development Projects 157
Introduction 157
Origins of Change 158
The Change Request Register 160
Change Request Resolution 162
Change Request Implementation Strategy 163
The Value of Metrics Derived from a Change Request Register 167
Chapter 9 Scheduling 171
Introduction 171
The Initial Work Breakdown Structure 172
A Work Breakdown Structure with Predecessors Defined 172
A Work Breakdown Structure with Initial Dates 176
A Work Breakdown Structure with Resource Allocation 178
Scheduling in Practice 181
Graphic Representation of a Schedule 181
Chapter 10 Software Project Closure 183
Introduction 183
Identifying Reusable Code Components 185
Documenting the Best Practices 186
Documenting the Lessons Learned 187
Collecting/Deriving and Depositing the Final Project Metrics in the Organizational Knowledge Repository 188
Conducting Knowledge-Sharing Meetings with Peer Software Project Managers 188
Depositing Project Records with the Project Management Office 189
Depositing Code Artifacts in the Code Repository 190
Conducting the Project Postmortem 190
Releasing the Software Project Manager 191
Closing the Project 192
The Role of the Organization in Project Closure 192
The Project Management Office 192
The Configuration Control Board 193
The Systems Administration Department 194
Reference 194
Chapter 11 Agile Project Management 195
Introduction 195
Project Management Roles 195
Agile Project Management Characteristics 196
Metaphor 197
Teamwork and Collaboration 197
Guiding Principles 198
Open Information 198
Use a Light Touch 199
Monitoring and Adjustment 199
The Nuts and Bolts of Agile Project Management 200
Planning the Work 200
Controlling the Work 202
Process Improvement 205
Reference 206
Chapter 12 Pitfalls and Best Practices in Software Project Management 207
Introduction 207
Organizational-Level Pitfalls and Best Practices 208
Process-Driven Project Management 208
An Ineffective Project Management Office or No Project Management Office 208
Poor Project Initiation 210
Poor Software Estimation 211
Poor Project Planning 211
The Wrong Service Level Agreements 212
Poor Standards and Guidelines for Software Development 213
Poor Project Oversight 214
Inadequate Project Management Training 214
Software Project Manager-Level Pitfalls and Best Practices 215
Fair Treatment of Project Human Resources 216
A Balanced Workload 216
Equitable Rewards 217
Poor Software Estimation 217
Poor Project Planning 217
Informal Issue Resolution 217
Poor Change Management 218
Poor Record Keeping 218
Additional Best Practices for Software Project Management 219
A Knowledge Repository 219
Continuous Process Improvement 219
Project Postmortems 219
Training in the Soft Skills 220
Information Sharing 220
Management Support 220
Some Closing Words 221
Appendix A Management of Software Development Projects 223
Appendix B Decision-Making for Software Project Managers 237
Appendix C People Management 251
Appendix D Productivity Concepts for Software Project Managers 271
Appendix E Issue Resolution in Software Project Management 287
Appendix F Measurement and Metrics in Software Development Organizations 295
Appendix G Measurement and Management of Customer Satisfaction 315
Appendix H An Introduction to PERT/CPM 327
Appendix I Abbreviations 347
Appendix J Templates for Software Project Managers 351
Index 373