Project Scheduling and Tracking Software Engineering 8 1 Why Are Projects Late? An unrealistic deadline established by someone outside the software development 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 SOE8 1
Scheduling Principles Compartmentalization define distinct tasks Interdependency indicate task interrelationships, effort validation be sure resources are available Defined responsibilities people must be assigned Defined outcomes each task must have an output Defined milestones review for quality 3 Task Set A set of tasks that enable the software team to define, develop, and ultimately maintain software. No single set of tasks is appropriate for all projects An effective software process should define a collection of task sets designed to meet the needs of different types of projects. The task set is a collection of software engineering work tasks, milestones, and deliverables that must be accomplished to complete a particular project. 4 SOE8 2
Defining Task Sets Determine type of project Assess the degree of rigor required identify adaptation criteria compute task set selector (TSS) value interpret TSS to determine degree of rigor Select appropriate software engineering tasks 5 Five common types of task sets Development Projects-- initiated to explore some new business concept or application of some new technology New Application Development Projects-- undertaken as a consequence of a specific customer request Application Enhancement Projects-- occur when existing software undergoes major modifications to function, performance, or interfaces that are observable by the end user Application Maintenance Projects-- 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 6 SOE8 3
Example I.2 Preliminary concept planning I.3 Technology risk assessment Planning Project Definition I.1 scoping Eng inee ring/ Construction I.4 Proof of concept Reeng inee ring App lication Ma intenance Deve lopment New App lication App lica t ion Deve lopment Enhancement I.6 Customer reaction I.5 implementation Customer Eva lua tion Release Figure 7.2 development tasks using an evolutionary model 7 Define a Task Network I.3a Tech. Risk Assessment I.5a Implement. I.1 scoping I.2 planning I.3b Tech. Risk Assessment I.4 Proof of I.5b Implement. Integrate a, b, c I.6 Customer Reaction I.3c Tech. Risk Assessment I.5c Implement. Three I.3 tasks are applied in parallel to 3 different concept functions Three I.3 tasks are applied in parallel to 3 different concept functions 8 SOE8 4
Effort Allocation 40-50% 15-20% 30-40% front end activities customer communication analysis design review and modification construction activities coding or code generation testing and installation unit, integration white-box, black box regression 9 Use Automated Tools to Derive a Timeline Chart week 1 week 2 week 3 week 4 Work tasks week 5 I.1.1 I.1.2 I.1.3 I.1.4 I.1.5 I.1.6 I.1.7 I.1.8 Identify need and benefits Meet with customers Identify needs and project constraints Establish product statement Milestone: product statement defined Define desired output/control/input (OCI) Scope keyboard functions Scope voice input functions Scope modes of interaction Scope document diagnostics Scope other WP functions Document OCI FTR: Review OCI with customer Revise OCI as required; Milestone; OCI defined Define the functionality/behavior Define keyboard functions Define voice input functions Decribe modes of interaction Decribe spell/grammar check Decribe other WP functions FTR: Review OCI definition with customer Revise as required Milestone: OCI defintition complete Isolate software elements Milestone: Software elements defined Research availability of existing software Reseach text editiong components Research voice input components Research file management components Research Spell/Grammar check components Milestone: Reusable components identified Define technical feasibility Evaluate voice input Evaluate grammar checking Milestone: Technical feasibility assessed Make quick estimate of size Create a Scope Definition Review scope document with customer Revise document as required Milestone: Scope document complete 10 SOE8 5
Scheduling Methods: Strengths These methods are continuously useful to project managers prior to and during a project. They are straightforward in concept and are supported by software. Their graphical representation of the project's tasks help to show the task interrelationships. Their ability to highlight the project's critical path and task slack time allows the project manager to focus more attention on the critical aspects of the project-time, costs and people. The project management software that creates the network usually provides excellent project tracking documentation. These methods are applicable in a wide variety of projects. 11 Scheduling Methods: Weaknesses In order for these methods to be useful, project tasks have to be clearly defined as well as their relationships to each other. These methods do not deal very well with task overlap. They assume the following tasks begin after their preceding tasks end. They are only as good as the time estimates that are entered by the project manager. By design, the project manager will normally focus more attention on the critical path tasks than other tasks, which could be problematic for near-critical path tasks if overlooked. 12 SOE8 6
Software Project Tracking and Oversight Activities Performed Goal 1 Actual results and performances are tracked against the software plans. Activity 5 Activity 6 Activity 7 Activity 8 Activity 9 Activity 10 The size of the software work products (or size of the changes to the software work products) are tracked, and corrective actions are taken as necessary. The project's software effort and costs are tracked, and corrective actions are taken as necessary. The project's critical computer resources are tracked, and corrective actions are taken as necessary. The project's software schedule is tracked, and corrective actions are taken as necessary. Software engineering technical activities are tracked, and corrective actions are taken as necessary. The software risks associated with cost, resource, schedule, and technical aspects of the project are tracked. 13 Software Project Tracking and Oversight Activities Performed Goal 1 Actual results and performances are tracked against the software plans. Activity 1 Activity 11 Activity 12 Activity 13 A documented software development plan is used for tracking the software activities and communicating status. Actual measurement data and replanning data for the software project are recorded. The software engineering group conducts periodic internal reviews to track technical progress, plans, performance, and issues against the software development plan. Formal reviews to address the accomplishments and results of the software project are conducted at selected project milestones according to a documented procedure. 14 SOE8 7
Software Project Tracking and Oversight Activities Performed Goal 2 Corrective actions are taken and managed to closure when actual results and performance deviate significantly from the software plans. Activity 2 Activity 5 Activity 6 Activity 7 Activity 8 Activity 9 Activity 10 The project's software development plan is revised according to a documented procedure. The size of the software work products (or size of the changes to the software work products) are tracked, and corrective actions are taken as necessary. The project's software effort and costs are tracked, and corrective actions are taken as necessary. The project's critical computer resources are tracked, and corrective actions are taken as necessary. The project's software schedule is tracked, and corrective actions are taken as necessary. Software engineering technical activities are tracked, and corrective actions are taken as necessary. The software risks associated with cost, resource, schedule, and technical aspects of the project are tracked. 15 Software Project Tracking and Oversight Activities Performed Goal 3 Changes to software commitments are agreed to by the affected groups and individuals. Activity 3 Activity 4 Software project commitments and changes to commitments made to individuals and groups external to the organization are reviewed with senior management according to a documented procedure. Approved changes to commitments that affect the software project are communicated to the members of the software engineering group and other softwarerelated groups. 16 SOE8 8
Tracking: Elementary Metrics 17 Project Tracking - Manpower & Effort Steen Andersen, Peter Stegenborg Larsen, Carsten Lindholst: Evaluation and Evolution of Navi - a Web Based Tool for Project Planning and Tracking, Masters Thesis, Computer Science, Aalborg University, 1998. 18 SOE8 9
Project Tracking - Lines of Code & Defects Steen Andersen, Peter Stegenborg Larsen, Carsten Lindholst: Evaluation and Evolution of Navi - a Web Based Tool for Project Planning and Tracking, Masters Thesis, Computer Science, Aalborg University, 1998. 19 SOE8 10