Ch24 by chenmeixiu


									           Chapter 24
Project Scheduling and Tracking

   What is it? - Create a network of software engineering tasks
    that will enable you to get the job done on time.
   Assign responsibility for each task, make sure it gets done
    and adapt the network as risks become reality.
   Who does it? – Project managers at project level and
    software engineers at individual level.
   Why? – to build a complex system, many tasks run in
    parallel. One task may affect another and so on…..
   Also to access the progress of project.
   Steps – Effort and duration are allocated to each task..
   Product – Project schedule and related information is

             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
   Human difficulties that could not have been foreseen in
   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
   Asked to build real time controller for medical instrument.
   To be introduced in market in nine months.
   Project manager concludes that it will take min 14 mnths.
   Recommendations:
       Perform detail estimates using past data. Determine effort and
        duration for this project.
       Using SDLC, Develop s/w engg. Strategy that will deliver critical
        functionality by imposed deadline. Document the plan.
       Meet the customer and explain why deadline is impossible. Mention
        % improvements that would be required.
       Offer the incremental development strategy as an alternative.

                  Project Scheduling
   Distributes effort across planned project duration by
    allocating effort to specific s/w engg. Tasks.
   Schedule evolves over time.
   During early stages macroscopic schedule is developed.
   As project gets underway, each entry refined into detailed
   Viewed in two different perspectives.
       End-date is already established.
       Organization distribute effort within this time frame.
       Second, rough chronological bounds discussed but end-date set
        by s/w organization after analyzing best use of resources…

              Scheduling Principles
   Compartmentalization— define distinct tasks, both project
    and process are decomposed.
   Interdependency—indicate task interrelationship, Some
    tasks must occur in sequence while others in parallel.
   Time Allocation – Each task allocated some number of work
    units. Also a start date and end date for each task.
   Effort validation—No more than allocated number of people
    have been scheduled at any given time.
   Defined responsibilities—people must be assigned
   Defined outcomes—each task must have an output
    (Normally a work product)
   Defined milestones—review for quality (When one or more
    work products are reviewed for quality)
Relationship betn. People and Effort
   Putnam-Norden-Reyleigh (PNR) curve provides
    indication of relationship between effort applied and
    delivery time for a s/w project.
   To indicates least time for delivery (Delivery time that will
    result in least effort expended)
   Ea Effort required to achieve nominal delivery time td
   Although we can accelerate curve rises sharply..
   Delivery time can not be compressed beyond 0.75 td
   We can gain by using fewer people over a somewhat
    longer time span to accomplish the same objective.

                  Effort and Delivery Time

Ef fort
                                Ea = m ( t d 4 / t a 4 )

           Impossible                 Ea = eff ort in person-months
             region                   t d = nominal deliv ery time for schedule
                                      t o = optimal development time (in terms of cost)
                                      t a = actual delivery time desir ed


                           td                          to                         development time
          Tmin = 0.75T d

         Effort Allocation
                ―front end‖ activities
40-50%              customer communication (2-3%)
                    analysis (10-15 %)
                    design (20-25 %)
                    review and modification
                construction activities
15-20%              coding or code generation
                testing and installation
                    unit, integration
                    white-box, black box
30-40%              regression

    Defining Task set for a s/w project
   No single task set is appropriate for all projects.
   Task set is collection of s/w engg. Work tasks,
    milestones, and work products.
   It should not burden the team with unnecessary work.
   Task set will vary depending upon project type and
    degree of rigor with which s/w team decides to do the

        Taxonomy of s/w project types
   Concept development projects – Initiated to explore new business
    concept or application of some new technology.
   New Application Development – Taken as consequence of specific
    customer request.
   Application enhancement projects – Existing s/w undergoes major
    modifications to function, performance or interfaces.
   Application maintenance projects – Correct, adapt, or extend
    existing software
   Reengineering Projects – Undertaken with the intent of rebuilding
    an existing (legacy) system in whole or part.

                A Task Set Example
   Concept development projects are approached by following
   Concept Scoping: Determines overall scope of project.
   Preliminary concept planning: Organizations ability to
    undertake the work implied by project scope.
   Technology Risk Assessment: Evaluates risk associated
    with technology implementation.
   Proof of concept: Validity of new technology in s/w context.
   Concept Implementation: Concept implementation reviewed
    by customer and used for ―Marketing‖ purpose
   Customer Reaction: Feedback on new technology by
                 Task Set Refinement
           1.1   Concept scoping determines the overall scope of the project.
                 Task definition: Task 1.1 Concept Scoping
                 1.1.1         Identify need, benefits and potential customers;
                 1.1.2         Define desired output/control and input events that drive the application;
                               Begin Task 1.1.2
                            FTR (Formal Tech Review) : Review written description of need
                            Derive a list of customer visible outputs/inputs
                            FTR: Review outputs/inputs with customer and revise as required;
                               end task Task 1.1.2
                 1.1.3         Define the functionality/behavior for each major function;
                               Begin Task 1.1.3
                            FTR: Review output and input data objects derived in task 1.1.2;
                            Derive a model of functions/behaviors;
                            FTR: Review functions with customer and revise as required;
                               end task Task 1.1.3
                 1.1.4         Isolate those elements of the technology to be implemented in software;
                 1.1.5         Research availability of existing software;
is refined to    1.1.6         Define technical feasibility;
                 1.1.7         Make quick estimate of size;
                 1.1.8         Create a Scope Definition;
                 End Task definition: Task 1.1

                 Defining a Task Network
   Individual tasks and subtasks have interdependencies based on their
   Concurrent tasks must be coordinated when later tasks require their
    work products.
   A task network/ activity network is a graphic representation of the task
    flow for a project.
   It depicts major software engg. Tasks.
   Concurrent nature of s/w engg. Leads to important scheduling
   Project manager should aware the tasks that lie on critical path.
   Following schedule is macroscopic.
   Each activity shown should be expanded.

Define a Task Network

   PERT (Program Evaluation and Review Tech.) and CPM
    (Critical Path Method) are two techniques applied to s/w dev.
   Both techniques driven by
       Estimation of effort.
       Decomposition of product function.
       Selection of appropriate process model and task set.
       Decomposition of tasks.
   Interdependencies can be defined using a task network as
    WBS (Work Breakdown Structure)
   Both PERT and CPM allow s/w manager to
       Determine critical path – chain of tasks that determine project duration
       Establish most likely time estimates for individual tasks
       Calculate time ―window‖ for particular task.
                      Timeline Charts
   Planner begins with set of tasks.
   If automated tools are used WBS is input as task n/w.
   Effort, duration, start date are then specified for each task.
   With this a timeline chart or Gantt chart is generated.
   Separate charts can be developed for each project function
    or for each individual.
   Work tasks on left hand column.. Horizontal bars indicate
    duration of task. Diamonds indicate milestones.
   This will generate project table – Tabular listing of project
   Project tables enable manager to track project progress.

              Timeline Charts

Tasks      Week 1   Week 2   Week 3   Week 4   Week n

 Task 1
 Task 2
 Task 3
 Task 4
 Task 5
 Task 6
 Task 7
 Task 8
 Task 9
 Task 10
 Task 11
 Task 12

Use Automated Tools to Derive a Timeline Chart

                    Schedule Tracking
    Project Schedule provides roadmap for project manager.
    Tracking of schedule is accomplished in following ways:
1.   Conduct periodic project status meetings in which each team member
     reports progress and problems.
2.   Evaluate the results of all reviews conducted throughout the software
     engineering process.
3.   Determine whether formal project milestones (the diamonds shown in
     Figure 24.3) have been accomplished by the scheduled date.
4.   Compare actual start-date to planned start-date for each project task
     listed in the resource table (Figure 24.4).
5.   Meet informally with practitioners to obtain their subjective assessment
     of progress to date and problems on the horizon.
6.   Use earned value analysis (Section 24.6) to assess progress
                       More tracking
   If faced with severe deadline pressure, managers use a
    control technique as time-boxing.
   Time boxing recognizes that complete product can not be
    delivered by the deadline.
   An incremental paradigm is chosen and schedule is derived
    for each incremental delivery.
   Schedule for each task is then adjusted by working
    backward from delivery date for the increment.
   A ―box‖ is put around each task.
   When task hits boundary of its time box work stops and next
    task begins.
   Rather than stuck on task project proceeds towards delivery.
                 Progress on an OO Project-I
   Technical milestone: OO analysis completed
          All classes and the class hierarchy have been defined and reviewed.
          Class attributes and operations associated with a class have been defined
           and reviewed.
          Class relationships have been established and reviewed.
          A behavioral model has been created and reviewed.
          Reusable classes have been noted.
   Technical milestone: OO design completed
          The set of subsystems has been defined and reviewed.
          Classes are allocated to subsystems and reviewed.
          Task allocation has been established and reviewed.
          Responsibilities and collaborations have been identified.
          Attributes and operations have been designed and reviewed.
          The communication model has been created and reviewed.

              Progress on an OO Project-II
   Technical milestone: OO programming completed
           Each new class has been implemented in code from the design model.
           Extracted classes (from a reuse library) have been implemented.
           Prototype or increment has been built.
   Technical milestone: OO testing
           The correctness and completeness of OO analysis and design models
            has been reviewed.
           A class-responsibility-collaboration network has been developed and
           Test cases are designed and class-level tests have been conducted for
            each class.
           Test cases are designed and cluster testing is completed and the
            classes are integrated.
           System level tests have been completed.

            Earned Value Analysis (EVA)

   Earned value
       is a quantitative indication of progress
       Provides a common value scale for every task
       enables us to assess the ―percent of completeness‖ of a project
        using quantitative analysis rather than rely on a gut feeling
        ―provides accurate and reliable readings of performance from as
        early as 15 percent into the project.‖

                 Computing Earned Value-I
   The budgeted cost of work scheduled (BCWS) is determined
    for each work task represented in the schedule.
        BCWSi is the effort planned for work task i.
       To determine progress at a given point along the project schedule, the
        value of BCWS is the sum of the BCWSi values for all work tasks that
        should have been completed by that point in time on the project
   The BCWS values for all work tasks are summed to derive
    the budget at completion, BAC. Hence,
              BAC = ∑ (BCWSk) for all tasks k

                    Computing Earned Value-II
   Next, the value for budgeted cost of work performed (BCWP) is
        The value for BCWP 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.
   ―the distinction between the BCWS and the BCWP is that the former
    represents the budget of the activities that were planned to be completed
    and the latter represents the budget of the activities that actually were

   Given values for BCWS, BAC, and BCWP, important progress indicators
    can be computed:
             Schedule performance index, SPI = BCWP/BCWS
             Schedule variance, SV = BCWP – BCWS
             SPI is an indication of the efficiency with which the project is utilizing
              scheduled resources.

                     Computing Earned Value-III
   Percent scheduled for completion = BCWS/BAC
        provides an indication of the percentage of work that should have been
         completed by time t.

   Percent complete = BCWP/BAC
        provides a quantitative indication of the percent of completeness of the project
         at a given point in time, t.

   Actual cost of work performed, ACWP, is the sum of the effort actually expended
    on work tasks that have been completed by a point in time on the project
    schedule. It is then possible to compute
             Cost performance index, CPI = BCWP/ACWP
             Cost variance, CV = BCWP – ACWP
             CPI value of close to 1.0 indicates that project is within its defined budget.
             CV is cost saving / shortfall at particular stage of project.


To top