Scheduling

SCHEDULING Root causes of failing of schedule 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 the number of resources. Predictable and unpredictable risks that were not considered when project commenced. Technical difficulties that could not have been foreseen in advance Miscommunication among project staff that result delays.

Comments on “Lateness” 







Perform a detailed estimate using historical data from past projects. Determine the estimated effort and duration for the project. Using an incremental process model ,develop a software engineering strategy that will deliver critical functionality by the imposed deadline , but delay other functionality until later. Meet with the customer and explain why the imposed deadline is unrealistic. Be certain to note that all estimates are based on performance on past projects. Offer the incremental development strategy as an alternative (increase budget and bring additional resource)

Basic principles  Compartmentalization

– the project must be compartmentalized into a number of manageable activities and tasks. To accomplish compartmentalization both the product and the process are decomposed.  Interdependency - the interdependency of each compartmentalized activity or task must be determined .some tasks must occur in sequence while others can occur in parallel.

Basic principles  Time

allocation - each task to be scheduled must be allocated some number of work units. in addition each must be assigned a start date and a completion date .  Effort validation - every project has a defined number of staff numbers. 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.

Basic principles  Defined

responsibilities – every task that is scheduled should be assigned to a specific team member.  Defined outcomes - every task that is scheduled should have defined outcome.  Defined milestones - every task or group of tasks should be associated with a project milestone.

Defining a task set A

task set is a collection of software engineering work tasks , milestones and deliverables that must be accomplished to complete a particular project.  Task set are designed to accommodate different types of projects and different degrees of rigor.  Concept

development projects - that are initiated to explore some new business concept or application of some new technology.  New application development projects - that are undertaken as a sequence of a specific customer request.

Defining a task set  Application

enhancement projects - that occur when existing software undergoes major modification to function, performance or interface.  Application maintenance projects - that correct ,adapt or extent existing software in ways that may not be immediately obvious to the end user.  Reengineering projects - that are undertaken with the intent of rebuilding an existing system in whole or in part.

Degree of rigor  Even

for a project of a particular type , the degree of rigor with which the software process is applied may vary significantly. The degree of rigor is a function of many project characteristics.  Casual-all process framework activities are applied, but only a minimum task set is required .

Degree of rigor  Structured

- the process framework activities are applied for this project. framework activities and related tasks appropriate to the project type will be applied and activities necessary to ensure high quality.  Strict - the full process will be applied for this project with a degree of discipline that will ensure high quality.  Quick reaction - the process frame work will be applied for this project , but because of emergency situation only those tasks essential to maintaining good quality will be applied.

Adaptation criteria  Adaptation

criteria are used to determine the recommended degree of rigor with which the software process should be applied on a project. Eleven Adaptation criteria are defined for software projects:  Size of project  Number of potential users  Mission criticality  Application longevity  Stability of requirements

Adaptation criteria  Ease

of customer  Maturity of application technology  Performance constraints  Embedded and non embedded characteristics  Project staff  Reengineering factors

scheduling  Scheduling

of a software project does not differ greatly from scheduling of any multitask engineering effort.  PERT and CPM are two project scheduling method that can be applied to software development.  Both PERT and CPM provide quantitative tools that allow software planner to  Determine

the critical path (duration of project)  Establish “most likely” time estimate for individual tasks by applying statistical models

scheduling  Calculate

“boundary time” that define a time “window” for a particular task

 Important  The

boundary times

earliest time that a task can begin  The latest time for task initiation  The earliest finishing time  The latest finishing time  The total float- the surplus time allowed in scheduling tasks so that the network critical path is maintained on schedule.