Software Engineering

1
Software Engineering

• Project Scheduling and Tracking

2
Objectives

1. To summarize the purpose of project planning.
2. To examine the scheduling and tracking stage of
   project planning.
3. To focus on the scheduling techniques available
   to a project planner.

3
Steps in Project Planning

• Scopeunderstand the problem and the work that
  must be done.
• Estimationhow much effort? how much time?
• Riskwhat can go wrong? how can we avoid it? what
  can we do about it?
• Schedulehow do we allocate resources along the
  timeline? what are the milestones?
• Control strategyhow do we control quality? how
  do we control change?

Project Scope Estimates Risks Schedule Control
strategy
Software Project Plan
4
Scheduling

• Definition Once the scope, process model, work
  estimates and deadline are in place the schedule
  is used to connect them into a network of SE
  tasks.
• Many SE tasks can be undertaken simultaneously
  (parallelism) and some may have a profound effect
  on subsequent tasks (dependency). Difficult to
  manage without a schedule.
• Excessive or irrational schedules are probably
  the single most destructive influence in all of
  software. Capers Jones
• I love deadlines. I love the whooshing sound
  they make as they fly by. Douglas Adams
• 90-90 Rule. The first 90 of a project is
  complete in 90 of the scheduled time. The other
  10 is also completed in 90 of the time.

5
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 result
  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

6
Dealing with Unrealistic Deadlines

• Any commander in chief who undertakes to carry
  out a plan which he considers defective is at
  fault he must put forth his reasons, insist on
  the plan being changed, and finally tender his
  resignation rather than be the instrument of his
  armys downfall. Napoleon
• Strategy for dealing with unrealistic externally
  imposed deadlines
• Perform detailed estimates using historical data.
• Using an incremental process model create a
  documented plan to deliver critical functionality
  within the deadline but delay other functionality
  till later.
• Meet with the customers and managers. Indicate
  the percentage improvement over previous projects
  required to meet the deadline. Offer the
  incremental plan as an alternative.

7
Scheduling Principles

• CompartmentalizationDefine manageable and
  distinct subtasks. Both the product and the
  process are decomposed.
• InterdependencyIndicate task interrelationships.
  Some occur in sequence, others in parallel.
• Time Allocation Each task is allocated some
  number of work units.
• Effort validationBe sure resources are
  available. No more than the total allocated
  hardware and people are scheduled at any given
  time.
• Defined responsibilitiesEach task must be
  assigned to specific people.
• Defined outcomesEach task must have an output
  (work products which combine to become
  deliverables)
• Defined milestonesWork products become
  milestones once reviewed for quality and approved.

8
People vs. Productivity

• Mongolian Horde Adding people to a late project
  makes it later.
• Often productivity is related to the number of
  communication paths amongst team members.
• If people must be added to a late project, they
  should be assigned to work that is highly
  compartmentalized.
• An empirical relationship (from the software
  equation)
• where L is lines of code, E is development effort
  (in person months), P is a productivity parameter
  between 2000 and 12000 (reflects a variety of
  quality factors) and t is development time in
  years.
• Example A complex real-time software project
  estimated at 33000 LOC. Completion in 1.3 years
  requires 8 people but 1.75 years requires only
  3.8 people.
• Relationship between number of people and
  productivity is non-linear.

9
Defining Task Sets

• Given a particular process, the set of tasks that
  populate that process, and are appropriate to the
  project, must be established.
• STEP 1 Determine the type of project
• Concept Development. Initiated to explore a new
  business concept, application or technology.
• New Application Development. Undertaken as a
  consequence of a specific customer request.
• Application Enhancement. Existing software
  undergoes major modification observable by the
  end-user.
• Application Maintenance. Correct, adapt or extend
  existing software in ways not immediately obvious
  to the end-user.
• Reengineering. Rebuilding an existing (legacy)
  system in whole or in part.

10
Degree of Rigour

• The task set will depend in size and complexity
  on the degree of rigour required
• Casual. All basic principles of SE are
  applicable. Umbrella activities, documentation
  and the task set are reduced. Low ceremony.
• Structured. Framework activities, related tasks
  and umbrella activities appropriate to the
  project are conducted in a streamlined manner.
• Strict. Full process applied with absolute
  discipline. High ceremony.
• Quick Reaction. In an emergency situation only
  those tasks essential to maintaining quality are
  applied. Back-filling (developing
  documentation, conducting additional reviews)
  done after delivery. Must not apply to more than
  10 of all work and is not the same as a project
  with strict deadlines.

11
Assessing Rigour

• STEP 2 Grade adaptation criteria on a scale of 1
  (small subset of process tasks and overall
  methodology at a minimum) to 5 (complete set of
  process tasks and methodology is substantial)
• 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 non-embedded characteristics
• Project staffing
• Reengineering factors

12
Task Selection

• STEP 3 Compute task set selector (TSS) value.
• Multiply the grade by a weight and entry point
  multiplier (particular to a project type).
• Calculate the average of all weighted adaptation
  criteria. This is the Task Set Selector value.
• Examples
• STEP 4 interpret TSS to determine overall degree
  of rigor

TSS Value TSS lt 1.2 1.0 lt TSS lt 3.0 TSS gt 2.4
Rigour casual structured strict
13
Selecting SE Tasks

• STEP 5 Select appropriate software engineering
  tasks
• Example Concept development tasks using an
  evolutionary model

Concept Planning Risk Assessment
Concept Scoping
Proof of Concept
Concept implementation
Customer Reaction
14
Scheduling

• SE scheduling not very different from any
  multi-task engineering effort.
• Program Evaluation and Review Technique (PERT)
  and Critical Path Methods (CPM) are project
  scheduling methods that determine
• Critical Path (chain of tasks that determine the
  duration of the project)
• Earliest time that a task can begin. All
  preceding tasks are completed in the shortest
  possible time.
• Latest time for task initiation that will not
  delay the project.
• Latest and earliest finish for the project
• Total float. The maximum slippage without overall
  delay.
• Implementation
• Automated tools.
• Often use a task network as input.

15
Define a Task Network

• Task (Activity) Network a graphical
  representation of the task flow and
  interdependencies for a project.

1.1 Concept Scoping
1.3a Risk Assess.
1.5a Concept Implement.
1.2 Concept Planning
1.3b Risk Assess.
1.4 Concept Proof
1.5b Concept Implement.
Integrate a, b, c
1.3c Risk Assess.
1.5c Concept Implement.
1.6 Customer Reaction
16
Effort Allocation

• 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

40-50
15-20
30-40
17
Gantt Chart
18
Tracking

• The project schedule provides a roadmap for tasks
  and milestones that must be tracked and
  controlled as the project proceeds.
• Techniques
• Hold Periodic project status meetings for all
  team members.
• Evaluate the results of all reviews.
• Determine whether formal project milestones have
  been accomplished by the scheduled date.
• Comparing actual start date to planned start date
  for each task.
• Meeting informally with practitioners to obtain
  their subjective assessment.
• Using earned value analysis to assess progress
  quantitatively.
• In dire straits managers will use time-boxing.
  When a task hits the boundary of its time box (-
  10) work stops and the next task begins.

19
Earned Value Analysis

• Enables quantitative assessment of the
  percentage of completeness of a project.
• Earned Value Metrics
• Budgeted Cost of Work Scheduled (BCWS) During
  estimation the work cost of each task is
  calculated.
• Budget at Completion (BAC)
• Budgeted Cost of Work Performed (BCWP) Sum of
  BCWS values for all work tasks actually
  completed.
• Actual Cost of Work Performed (ACWP) Sum of
  effort actually expended on work tasks performed
  to date.
• Schedule Performance Index (SPI) BCWP / BCWS
  Schedule Variance (SV) BCWP BCWS
• Cost Performance Index (CPI) BCWP / ACWP
  Cost Variance (CV) BCWP ACWP (measures cost
  savings/overruns)