Software project-scheduling

Software project-scheduling

• 2.
  • An unrealistic deadline established by someone outside the software engineering group • Changing customer requirements that are not reflected in schedule changes • An honest underestimate of the amount of effort and /or the number of resources that will be required to do the job • Predictable and/or unpredictable risks that were not considered when the project commenced • 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 falling behind schedule and a lack of action to correct the problem 2
• 4.
  • On large projects, hundreds of small tasks must occur to accomplish a larger goal • Project manager's objectives – Define all project tasks – Build an activity network that depicts their interdependencies – Identify the tasks that are critical within the activity network – Build a timeline depicting the planned and actual progress of each task – Track task progress to ensure that delay is recognized "one day at a time" – To do this, the schedule should allow progress to be monitored and the project to be controlled ( (More on next slide) 4
• 5.
  • Software project scheduling distributes estimated effort across the planned project duration by allocating the effort to specific tasks • Scheduling for projects can be viewed from two different perspectives – In the first view, an end-date for release of a computer- based system has already been established and fixed • The software organization is constrained to distribute effort within the prescribed time frame – In the second view, assume that rough chronological bounds have been discussed but that the end-date is set by the software engineering organization • Effort is distributed to make best use of resources and an end-date is defined after careful analysis of the software – The first view is encountered far more often that the second 5
• 6.
  • Compartmentalization – The project must be compartmentalized into a number of manageable activities, actions, and tasks; both the product and the process are decomposed • Interdependency – The interdependency of each compartmentalized activity, action, or task must be determined – Some tasks must occur in sequence while others can occur in parallel – Some actions or activities cannot commence until the work product produced by another is available • Time allocation – Each task to be scheduled must be allocated some number of work units – In addition, each task must be assigned a start date and a completion date that are a function of the interdependencies – Start and stop dates are also established based on whether work will be conducted on a full-time or part-time basis ( (More on next slide) 6
• 7.
  • Effort validation – Every project has a defined number of people on the team – As time allocation occurs, the project manager must ensure that no more than the allocated number of people have been scheduled at any given time • Defined responsibilities – Every task that is scheduled should be assigned to a specific team member • Defined outcomes – Every task that is scheduled should have a defined outcome for software projects such as a work product or part of a work product – Work products are often combined in deliverables • Defined milestones – Every task or group of tasks should be associated with a project milestone – A milestone is accomplished when one or more work products has been reviewed for quality and has been approved 7
• 9.
  • A task set is the work breakdown structure for the project • No single task set is appropriate for all projects and process models – It varies depending on the project type and the degree of rigor (based on influential factors) with which the team plans to work • The task set should provide enough discipline to achieve high software quality – But it must not burden the project team with unnecessary work 9
• 10.
  • Concept development projects – Explore some new business concept or application of some new technology • New application development – Undertaken as a consequence of a specific customer request • Application enhancement – Occur when existing software undergoes major modifications to function, performance, or interfaces that are observable by the end user • Application maintenance – Correct, adapt, or extend existing software in ways that may not be immediately obvious to the end user • Reengineering projects – Undertaken with the intent of rebuilding an existing (legacy) system in whole or in part 10
• 11.
  • Size of the project • Number of potential users • Application longevity • Stability of requirements • Ease of customer/developer communication • Maturity of applicable technology • Performance constraints • Embedded and non-embedded characteristics • Project staff • Reengineering factors 11
• 12.
  • Also called an activity network • It is a graphic representation of the task flow for a project • It depicts task length, sequence, concurrency, and dependency • Points out inter-task dependencies to help the manager ensure continuous progress toward project completion • The critical path – A single path leading from start to finish in a task network – It contains the sequence of tasks that must be completed on schedule if the project as a whole is to be completed on schedule – It also determines the minimum duration of the project 12
• 13.
  Task F Task G Task H 2 3 5 Task B 3 Task N 2 Task A 3 Task C Task E Task I Task J 7 8 4 5 Task M 0 Task D 5 Task K Task L 3 10 Where is the critical path and what tasks are on it? 13
• 14.
  Task F Task G Task H 2 3 5 Task B 3 Task N 2 Task A 3 Task C Task E Task I Task J 7 8 4 5 Task M 0 Task D 5 Task K Task L 3 10 Critical path: A-B-C-E-K-L-M-N 14
• 16.
  • Also called a Gantt chart; • All project tasks are listed in the far left column • The next few columns may list the following for each task: projected start date, projected stop date, projected duration, actual start date, actual stop date, actual duration, task inter- d dependencies (i.e., predecessors) • To the far right are columns representing dates on a calendar • The length of a horizontal bar on the calendar indicates the duration of the task • When multiple bars occur at the same time interval on the calendar, this implies task concurrency • A diamond in the calendar area of a specific task indicates that the task is a milestone; a milestone has a time duration of zero Jan Feb Mar Apr May Jun Jul Aug Sep Oct Task # Task Name Duration Start Finish Pred. 1 Task A 2 months 1/1 2/28 None 2 Milestone N 0 3/1 3/1 1 16
• 17.
  Timeline chart: SOLUTION 4/1 4/8 4/15 4/22 4/29 5/6 5/13 5/20 5/27 6/3 Task # Task Name Duration Start Finish Pred. A Establish increments 3 4/1 4/3 None B Analyze Inc One 3 4/4 4/6 A C Design Inc One 8 4/7 4/14 B D Code Inc One 7 4/15 4/21 C E Test Inc One 10 4/22 5/1 D F Install Inc One 5 5/2 5/6 E G Analyze Inc Two 7 4/7 4/13 A, B H Design Inc Two 5 4/14 4/18 G I Code Inc Two 4 4/19 4/22 H J Test Inc Two 6 5/2 5/7 E, I K Install Inc Two 2 5/8 5/9 J L Close out project 2 5/10 5/11 F, K Task network and the critical path: A-B-C-D-E-J-K-L B. Analyze C. Design D. Code E. Test F. Install Inc One Inc One Inc One Inc One Inc One 3 8 7 10 5 A. Establish Increments L. Close out 3 Project 2 G. Analyze H. Design I. Code J. Test K. Install Inc Two Inc Two Inc Two Inc Two Inc Two 7 5 4 6 2 17
• 18.
  18
• 19.
  • Qualitative approaches – Conduct periodic project status meetings in which each team member reports progress and problems – Evaluate the results of all reviews conducted throughout the software engineering process – Determine whether formal project milestones (i.e., diamonds) have been accomplished by the scheduled date – Compare actual start date to planned start date for each project task listed in the timeline chart – Meet informally with the software engineering team to obtain their subjective assessment of progress to date and problems on the horizon • Quantitative approach – Use earned value analysis to assess progress quantitatively 19