Lecture 7 Project Scheduling and Tracking Software Engineering Lecture 7 Project Scheduling and Tracking

Why software is delivered late Unrealistic deadline Changing Customer Requirements Underestimate of the amount of effort Predictable / Unpredictable risks Technical Difficulties Human Difficulties Miscommunication among project staff Lack of action to overcome the lateness

Comments on “Lateness” It is unrealistic to march into the customer’s office and demand that the delivery date be changed, because: External market pressures have dictated the date, and the product must be released Developers cannot refuse to undertake the work (from a career standpoint)

Recommended solutions Perform a detailed estimate using historical data from past projects Using an incremental process model (deliver critical functionality, delay others) Meet with the customer and explain why the imposed deadline is unrealistic (using the detailed estimate)

Project Scheduling Basic Principles Project Manager’s Objectives: Define all project tasks Build a network of task interdependencies Identify tasks that lie on the critical path Software Project Scheduling is an activity that distributes estimated effort across the planned project duration by allocating the effort to specific software engineering tasks. The schedule evolves over time.

Macroscopic vs Detailed Schedule Macroscopic schedule: identifies all major software engineering activities and the product functions to which they are applied As the project gets under way, each entry on the macroscopic schedule is refined into a detailed schedule. Detailed schedule: specific software tasks (required to acomplish an activity) are identified and scheduled

Software Project Scheduling Guidelines Compartmentalization (decompose activities and tasks) Interdependency (of activities / tasks) Time Allocation (for each task) Effort Validation (e.g. 3 person-day for a task) Defined Responsibilities (task - team member assignment) Defined Outcomes (e.g. work product) Defined Milestones (a group of approved work products)

Defining a task set for the software project A task set is a collection of software engineering work tasks, milestones, and deliverables that must be accomplished to complete a particular project Task sets are designed to accommodate different types of projects and different degrees of rigor

Taxonomy of software project types Concept development projects (explore new business concepts / new technology) New application development projects Application enhancement projects (major modifications to functions, performance, or interfaces) Application maintenance projects (correct, adapt, or extend existing software) Reengineering projects (rebuild an existing system)

Degree of rigor (1) The degree of rigor is a function of many project characteristics. Casual All process framework activities are applied A minimum task set is required Umbrella tasks are minimized Documentation requirements are reduced. Structured SQA, SCM, documentation, and measurement tasks will be conducted in a streamlined manner

Degree of rigor (2) Strict Quick Reaction The full process will be applied with a degree of discipline to ensure high quality All umbrella activities will be applied Robust work products will be produced Quick Reaction The process framework will be applied, but only those tasks essential to maintaining good quality will be applied Back-filing (documentation, reviews) will be accomplished after the product is delivered

Adaptation Criteria Adaptation criteria are used to determine the recommended degree of rigor with which the software process should be applied on a project. Evelen adaptation criteria are defined for a software project. Each of the adaptation criteria is assigned a grade that ranges between 1 and 5. 1 represents a small set of process tasks are required (minimal requirements) 5 represents a complete set of process tasks should be applied (overall methodological and documentation)

Eleven adaptation criteria 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 constrains Embedded and nonembedded characteristics Project staff Reengineering factors

Computing The Task Set Selector Step 2 Grade 1 to 5 Adaptation Criteria Grade Weight Entry Point Multiplier Product Conc Ndev Enhan Maint Reeng Size of project 1.20 1 Number of users 1.10 Business criticality Longevity 0.90 Stability of requirements Ease of communication Maturity of technology Performance constraints 0.80 Embedded/nonembedded Step 1 Choose the project type Step 4 Grade x weight x entry point multiplier Step 3 Weight 0.8 – 1.2 Step 5 TSS = Average(Products)

Interpreting the TSS value Task Set Selector Value Degree of rigor TSS < 1.2 Casual 1.0 < TSS < 3.0 Structured TSS > 2.4 Strict

Project Scheduling Methods (1) PERT (Program Evaluation and Review Technique) and CPM (Critical Path Method) are two project scheduling methods that can be applied to software development. Interdependencies among tasks may be defined using a task network (activity network), a graphic representation of the task flow for a project.

Project Scheduling Methods (2) Both PERT and CPM provide quantitative tools that allow the software planner to: Determine the critical path Establish “most likely” time estimates for individual tasks Calculate “boundary times” that define a time “window” for a particular task

Timeline Charts A timeline chart, also called a Gantt chart depicts the software project schedule for the entire project. Alternatively, separate charts can be developed for each project function or for each individual working on the project.

Tracking the Schedule Conducting periodic project status meeting Evaluating the results of all conducted reviews Determining whether milestones have been accomplished by the scheduled date Comparing actual start-date to planned start-date for each project task Meeting informally with practitioners to obtain their subjective assessment of progress to date Using Earned Value Analysis to assess progress quantitatively

Earned Value Analysis (1) The earned value analysis (Humphrey, 1995) provides a common value scale for every software project task, regardless of the type of work being performed. The total hours to do the whole project are estimated, and every task is given an earned value based on its estimated percentage of the total. Earned value is simply a measure of progress.

Earned Value Analysis (2) BCWS (Budgeted cost of work scheduled) is the sum of the BCWSi values for all work tasks that should have been completed by that point in time on the project schedule. The BCWS values for all work tasks are summed to derive the Budget At Completion (BAC). BAC = å (BCWSk) for all tasks k BCWP (Budgeted cost of work performed) is the sum of the BCWS values for all work tasks that have actually been completed by a point in time on the project schedule.

Earned Value Analysis (3) Given values for BCWS, BAC, and BCWP, important progress indicators can be computed: Schedule Performance Index, an indication of the efficiency with which the project is utilizing scheduled resources. SPI = BCWP / BCWS Schedule Variance, an absolute indication of variance from the planned schedule. SV = BCWP – BCWS Percent scheduled for completion = BCWS / BAC Percent complete = BCWP / BAC

Earned Value Analysis (4) ACWP (Actual cost of work performed) is the sum of the effort actually expended on work tasks that have been completed by a point in time on the project schedule. Cost performance index, CPI = BCWP / ACWP Cost variance, CV = BCWP – ACWP

Summary Scheduling is the culmination of a planning activity that is a primary component of software project management. When combined with estimation methods and risk analysis, scheduling establishes a road map for the project manager.

References Pressman, Chapter 7