CMPS 157, Systems Analysis
Chapter 71
Dr. Dennis Vickers
Section 1: May 5.
Section 2: May 6.
Chapter 7: Project Scheduling and Tracking
Overview: Most instances of software delivered late are examples of:
1. An unrealistic deadline established by someone outside the development
group.
2. Changing requirements mid-stream.
3. Overoptimistic estimate of resources needed,
4. Risks encountered during the course of the project,
5. Technical difficulties,
6. Miscommunications,
7. Project begins slipping and there is no corrective action.
Software Project Scheduling Basic Principles:
1. Compartmentalization: The product requirements are refined and the project
processes are decomposed into more manageable units.
2. Interdependency: Identify how tasks are interdependent and schedule
accordingly.
3. Time allocation: Assign work units to each task (low, high) and schedule (start
finish),
4. Effort validation: Verify that the project schedule fits the workers schedules
(e.g. no one has 26 hours of work to do in a day).
5. Defined responsibilities: Every task is someone’s responsibility,
6. Defined outcomes: Every task has a defined outcome such that one can tell
easily when the task is complete.
7. Defined milestones: The project is divided into milestone, which are
themselves defined in terms of verifiable task completions.
The Relationship between People and Effort: When people work together the net
productivity of the team is not simply the cumulative productivity of each individual.
The text suggests that individual productivity will drop by a factor related to the
number of communication paths (e.g. four team members = six paths). Clearly team
productivity is not simply individual productivity added up, and clearly
communication is a factor, but there are other considerations too—internal mentoring
improving productivity, application of specializations and past experiences. The text
also concludes that a smaller team working a longer time will accomplish more than a
larger team working a shorter time, based on the equation:
E = L3 / P3t4
1
Software Engineering, A Practitioner’s Approach, Roger S. Pressman, fifth edition
Where L = the lines of code delivered (unit = LOC), E = development effort (unit =
person months), t = elapsed time for the work (unit = calendar months) and P is a
productivity factor.
Effort Distribution: The traditional percentages of project resources assigned to
major phases are:
 40% Requirements and Design
 20% Code development
 40% Testing
This called the 40-20-40 rule. The larger the project, the more you shift resources to
requirements and design.
Defining a task set of a software development project:
A task set is a collection of software engineering work tasks, milestones, and
deliverables that must be accomplished to complete a particular project. The task set
for a project can be defined more or less rigorously. The utmost rigor is when every
task is explicitly defined, assigned, tracked, and closed. The utleast rigor is when the
broad steps are in the project plan but otherwise the developers make up the details as
they go along. The various levels may be defined as:
 Casual,
 Structured,
 Strict,
 Quick Reaction.
How do you know which is best?
Adaptation Criteria
Size of project
Number of users
Business criticality
Longevity
Stability of requirements
Ease of communication
Maturity of technology
Performance constraints
Embedded/non
Project staffing
Interoperability
Reengineering
Grade
Weight
1.2
1.1
1.1
0.9
1.2
0.9
1.2
0.9
0.9
1.0
1.1
1.2
Conc
0
0
0
0
0
1
1
0
1
1
0
0
N Dev
1
1
1
1
1
1
1
1
1
1
1
0
Enhan
1
1
1
1
1
1
0
1
1
1
1
0
Maint
1
1
1
0
1
1
0
0
0
1
1
0
Reeng
1
1
1
0
1
1
1
1
1
1
1
1
Product
To answer that question explicitly, construct a Task Set Selector Table.2 Conc, N Dev,
Enhan, Maint, Reeng are types of projects, namely Concept development, New
application development, Application enhancement, Application maintenance,
Reengineering (defined further on page 173). To use the table, assign a grade for each
factor in the left column, ranging from 1 (overall methodological and documentation
requirements are minimal) to 5 (overall methodological and documentation
requirements are substantial), multiple across, and computer the average. The Task
Set Selector (TSS) is the average of the products. A TSS less than 1.2 indicates casual
project management will suffice. A TSS greater that 1.0 but less that 3.0 indicated a
2
See Adaptable Process Model, R.S. Pressman & Associates, 1999.
structured approach is best. A TSS at the high end of that range, or higher indicates
strict project management is needed.
Selecting Software Engineering Tasks:
At this point, an overall development methodology appropriate for the product, the
customer group, and the development team – linear sequential, iterative, prototyping,
incremental, or one of the others. The methodology will structure the task set, creating
a macroscopic schedule.
The macroscopic schedule is then broken down further by task refinement. The
technique presented in Chapter 3 is workable:
 Develop a set of framework activities that are performed for each macro
process.
 For each macro process design a series of tasks to accomplish each framework
activity.
In chapter 7 Pressman uses a process design language approach (another alternative).
Defining a task network:
A task network is a representation of the tasks in a plan with the interdependencies
and required sequences identified.
When all of the tasks in the project and all interdependencies and required sequences
are identified, the longest (in duration, not number) chain of tasks that are required to
be in sequence is the critical path. Any slippage in the task in the critical path affects
the completion date of the project. Tasks outside the critical path can slip without
affecting the project delivery date, if they can be caught up through supplemental
work.
The Gantt chart (named for Henry Gantt) is one way to depict the tasks and timelines
in a project schedule. Project tables are a supplemental way to depict the work
concerns regarding tasks (planned start date, actual start date, planned complete,
actual complete, assigned person, and so on).
Tracking the Schedule:
Keeping track of progress on the project schedule, and making appropriate
adjustments, is an important part of project management. Variations from the
schedule should be dealt with as soon as possible.
Time-boxing is a method for adjusting a project schedule to insure delivery of a
functional (though maybe not fully featured product) on schedule. It involves
identifying when work on a component must be complete if the project delivery date
is to hold. When that date arrives, those working on the component move on;
remaining work is delayed.
Earned Value Analysis is a method to describe what progress a project has made. It
is intended to overcome difficulties associated with the traditional ‘percent complete’
measures.
Using this method, the Schedule Performance Index (SPI) equals the
Budgeted Cost of Work Performed (BCWP) divided by the
Budgeted Cost of Work Scheduled (BCWS).
The Schedule Variance (SV) = BCWP – BCWS.
Percent scheduled for completion is BCWS/ Budget at Completion (BAC)
Percent complete = BCWP/BAC
The actual cost of work performed ACWP, the sum of the effort actually expended on
work tasks that are complete at a point on the project schedule.
The Cost Performance Index (CPI) is BCWP/ACWP.
And the Cost Variance is BCWP – ACWP.