Managing Software Projects

1. Managing Software Projects CHAPTER 7Project Scheduling and Tracking Software engineering: a practitioner’s approach / Roger S. Pressman.—5th ed

2. Software is delivered late Although there are many reasons why software is delivered late, most can be tracedto one or more of the following root causes: • An unrealistic deadline • Changing customer requirements • An honest underestimate of the amount of effort and/or the number ofresources • Predictable and/or unpredictable risks • Technical difficulties that could not have been foreseen in advance. • Human difficulties that could not have been foreseen in advance. • Miscommunication among project staff that results in delays. • A failure by project management to recognize that the project is fallingbehind schedule and a lack of action to correct the problem.

3. Software project scheduling • The project manager’s objective is to define all project tasks, build a network thatdepicts their interdependencies, identify the tasks that are critical within the network,and then track their progress to ensure that delay is recognized "one day at a time.“ • To accomplish this, the manager must have a schedule that has been defined at adegree of resolution that enables the manager to monitor progress and control theproject. • Software project scheduling is an activity that distributes estimated effort across theplanned project duration by allocating the effort to specific software engineering tasks.

4. Principles guidesoftware project scheduling • Like all other areas of software engineering, a number of basic principles guidesoftware project scheduling: • Compartmentalization. The project must be compartmentalized into anumber of manageable activities and tasks. To accomplish compartmentalization,both the product and the process are decomposed. • Interdependency. The interdependency of each compartmentalized activityor task must be determined. Some tasks must occur in sequence while otherscan occur in parallel. Some activities cannot commence until the work productproduced by another is available. Other activities can occur independently.

5. Principles guidesoftware project scheduling • Time allocation. Each task to be scheduled must be allocated some numberof work units (e.g., person-days of effort). • In addition, each task must beassigned a start date and a completion date that are a function of the interdependenciesand whether work will be conducted on a full-time or part-timebasis.

6. Principles guidesoftware project scheduling • Effort validation. Every project has a defined number of staff members. Astime allocation occurs, the project manager must ensure that no more thanthe allocated number of people have been scheduled at any given time. • Forexample, consider a project that has three assigned staff members (e.g., 3person-days are available per day of assigned effort5). On a given day, sevenconcurrent tasks must be accomplished. Each task requires 0.50 person daysof effort. More effort has been allocated than there are people to do the work.

7. Principles guidesoftware project scheduling • Defined responsibilities. Every task that is scheduled should be assignedto a specific team member. • Defined outcomes. Every task that is scheduled should have a defined outcome. • For software projects, the outcome is normally a work product (e.g.,the design of a module) or a part of a work product. Work products are oftencombined in deliverables.

8. Principles guidesoftware project scheduling • Defined milestones. Every task or group of tasks should be associated witha project milestone. • A milestone is accomplished when one or more workproducts has been reviewed for quality and has been approved.Each of these principles is applied as the project schedule evolves.

9. Software engineering work tasks • A task set is a collection of software engineering work tasks, milestones, and deliverablesthat must be accomplished to complete a particular project. • Eleven adaptation criteria [PRE99]are defined for software projects: • Size of the project • Number of potential users • Mission criticality • Application longevity • Stability of requirements • Ease of customer/developer communication • Maturity of applicable technology • Performance constraints • Embedded and nonembedded characteristics • Project staff • Reengineering factors

10. Task network oractivity network • A task network, also called an activity network, is a graphic representation of thetask flow for a project. • It is sometimes used as the mechanism through which tasksequence and dependencies are input to an automated project scheduling tool. • In itssimplest form (used when creating a macroscopic schedule), the task network depictsmajor software engineering tasks.

11. Scheduling of a software project • Scheduling of a software project does not differ greatly from scheduling of any multitaskengineering effort. Therefore, generalized project scheduling tools and techniquescan be applied with little modification to software projects. • Program evaluation and review technique (PERT) and critical path method (CPM)[MOD83] are two project scheduling methods that can be applied to software development.

12. PERT and CPM • Both techniques are driven by information already developed in earlier projectplanning activities: • Estimates of effort • A decomposition of the product function • The selection of the appropriate process model and task set • Decomposition of tasks • Interdependencies among tasks may be defined using a task network. Tasks, sometimescalled the project work breakdown structure (WBS), are defined for the productas a whole or for individual functions.

13. PERT and CPM • Both PERT and CPM provide quantitative tools that allow the software planner to • determine the critical path—the chain of tasks that determines the duration of theproject; • establish “most likely” time estimates for individual tasks by applying statisticalmodels; and (3) calculate “boundary times” that define a time "window" for aparticular task.

14. PERT and CPM • Riggs [RIG81] describes important boundary times that may be discernedfrom a PERT or CPM network: (1) the earliest time that a task can begin whenall preceding tasks are completed in the shortest possible time, (2) the latest time fortask initiation before the minimum project completion time is delayed, (3) the earliestfinish—the sum of the earliest start and the task duration, (4) the latest finish—the latest start time added to task duration, and (5) the total float—the amount ofsurplus time or leeway allowed in scheduling tasks so that the network critical pathis maintained on schedule. • Boundary time calculations lead to a determination ofcritical path and provide the manager with a quantitative method for evaluatingprogress as tasks are completed.

15. PERT and CPM • Both PERT and CPM have been implemented in a wide variety of automated toolsthat are available for the personal computer [THE93]. • Such tools are easy to use andmake the scheduling methods described previously available to every software projectmanager.

16. THE PROJECT PLAN • Each step in the software engineering process should produce a deliverable that canbe reviewed and that can act as a foundation for the steps that follow. • The SoftwareProject Plan is produced at the culmination of the planning tasks. It provides baselinecost and scheduling information that will be used throughout the software process.

17. DocumentSoftware Project Plan • The Software Project Plan is a relatively brief document that is addressed to a diverseaudience. It must (1) communicate scope and resources to software management,technical staff, and the customer; (2) define risks and suggest risk aversion techniques; (3) define cost and schedule for management review; (4) provide an overall approachto software development for all people associated with the project; and (5) outlinehow quality will be ensured and change will be managed.

18. DocumentSoftware Project Plan • A presentation of cost and schedule will vary with the audience addressed. If theplan is used only as an internal document, the results of each estimation techniquecan be presented. • When the plan is disseminated outside the organization, a reconciledcost breakdown (combining the results of all estimation techniques) is provided. • Similarly, the degree of detail contained within the schedule section may vary withthe audience and formality of the plan. • It is important to note that the Software Project Plan is not a static document. Thatis, the project team revisits the plan repeatedly—updating risks, estimates, schedulesand related information—as the project proceeds and more is learned.