UNIT-II

PROJECT SCHEDULING

PROJECT SCHEDULING
Scheduling is an inexact process in that it tries to
predict the future. While it is not possible to know with
certainty how long a project will take, there are
techniques that can increase your likelihood of being
close. If you are close in your planning and estimating,
you can manage the project to achieve the schedule by
accelerating some efforts or modifying approaches to
meet required deadlines.

PROJECT SCHEDULING
In order to schedule the project activities, a software project
manager needs to do the following:
1.

Identify all the tasks needed to complete the project.

2.

Break down large tasks into small activities.

3.

Determine the dependency among different activities

4.

Establish the most likely estimates for the time durations

necessary to complete the activities.

5.

Allocate resources to activities.

6.

Plan the starting and ending dates for various activities.

7.

Determine the critical path.

PROJECT SCHEDULING
-WORK BREAK DOWN STRUCTURE
WBS is used to decompose a given task set recursively into small
activities. WBS provides a notation for representing the major
tasks needed to be carried out in order to solve a problem.
MISRequirements
application
Graphical user
specification
interface part

PROJECT SCHEDULING
-WORK BREAK DOWN STRUCTURE
The WBS should be designed with consideration for its eventual
uses. Your WBS design should try to achieve certain goals:

Be compatible with how the work will be done and how costs and
schedules will be managed,

Give visibility to important or risky work efforts,

Allow mapping of requirements, plans, testing, and deliverables,

Foster clear ownership by managers and task leaders,

Provide data for performance measurement and historical

databases, and

Make sense to the workers and accountants.

PROJECT SCHEDULING
-ACTIVITY NETWORKS AND CRITICAL PATH METHOD
PERT and CPM have similarities in terms of concepts and
methodology, a basic difference exists between the two techniques.
PERT is useful for analysis project scheduling problem in which the
completion time of the different activities, and therefore the whole
project, is not certain. On the other hand CPM is most appropriately
used in projects in which the activity durations are known with
certainty. This technique is basically concerned with obtaining the
tradeoffs between the project duration and cost. Thus, whereas
variation in the project time is inherent in the projects where PERT is
used, the time is systematically varied where CPM is employed. In
essence, then while PERT is probabilistic in nature and as such is used
more in research and development projects, the CPM is a
deterministic technique.
PERT and CPM are suitable for any situation where:
a) The project consists of well-defined collection of activities or
tasks.
b) The activities can be started and terminated independently of

PROJECT SCHEDULING

-PERT - CPM

PROJECT SCHEDULING

-PERT - CPM
SN

NODES

EARLIEST LATEST
TIME
TIME
(Emax)
(Emin)

SLACK

TA
TB
TC
TD
TE
TF
TG
TH

10

16

16

26

26

23

24

29

29

2
3
4
5
6
7
8

PROJECT SCHEDULING

-PERT - CPM

PROJECT SCHEDULING
-GANTT CHARTS
A Gantt chart is a horizontal bar or line chart which will
commonly include the following features:
activities identified on the left hand side;
time scale is drawn on the top (or bottom) of the chart;
a horizontal open oblong or a line is drawn against each
activity indicating estimated duration;
dependencies between activities are shown;
at a review point the oblongs are shaded to represent the
actual time spent (an alternative is to represent actual
and estimated by 2 separate lines);
a vertical cursor (such as a transparent ruler) placed at
the review point makes it possible to establish activities
which are behind or ahead of schedule.

Sample Intranet
Organized by Phase

Intranet WBS in Tabular Form

1.0 Concept
1.1 Evaluate current systems
1.2 Define Requirements
1.2.1 Define user requirements
1.2.2 Define content requirements
1.2.3 Define system requirements
1.2.4 Define server owner requirements
1.3 Define specific functionality
1.4 Define risks and risk management approach
1.5 Develop project plan
1.6 Brief Web development team
2.0 Web Site Design
3.0 Web Site Development
4.0 Roll Out
5.0 Support

INTRANET PROJECT WITH GANTT

CHART

STAFFING
Once the effort required to develop a software has been
determined, it is necessary to determine the staffing
requirement for the project. Putman was the first to study
the problem of what should be a proper staffing pattern
for software projects. He extended the work of Nordon
who earlier investigated the staffing pattern of general
research and development type of projects. In order to
appreciate the staffing pattern of software projects, we
must first understand Nordons and Putmans result.

STAFFING- Nordons work

According to Nordon the equation of rayleigh
curve is as follows:
E = K/td2 * t * e t2/2td2
Where E is the effort required at time t. E is an of
the number of developers at any particular time
during the duration of the project. K is the area
under the curve. And td is the time at which the
curve attains its maximum value.
But this equation is applicable for R&D type of
project.

STAFFING- Putmans work

Putman derived the following expression:
L=CkK1/3td4/3
Where
K is the total effort expended in the product development and L is
the product size in KLOC.
Td corresponds to the time of system integration and testing.
Therefore, td can be approximately considered as the time required
to develop the software.
C is the state of technology constant and reflects constraints that
k
impede the progress of the programmer. Typical values of C k = 2 for
poor development environment, poor documentation etc. C k = 8 for
good and Ck = 11 for an excellent one.

Software Quality Assurance

A planned and systematic pattern of all

actions necessary to provide adequate
confidence that the item or product conforms
to established technical requirements.
IEEE STD 610.12-1990

Software Quality Assurance

SQA is the function that (through measurement and analysis)

works to continually improve process, methods, procedures,
and standards so that management can be assured that when
their staff follows those methods, procedures and standards
they will be able to consistently deliver products that both meet
requirements and are fit for use.

Provides management with appropriate visibility into the process

being used and the products being built
Verifies compliance with project requirements
Involves
Reviewing or auditing products and processes
Providing appropriate visibility to affected groups and Senior
Management
Identifying, documenting, and tracking noncompliance issues
Based on a documented plan and processes

Software Quality Assurance

Quality is a management responsibility and SQA provides

visibility for senior /project management and customers into
the processes being used by the software projects to
assure high-quality deliverable products.
Each project is responsible for assuring the delivery of
high-quality technical products and services.
The activities for validating and verifying the technical
correctness of software products is the project
management and development teams responsibility.
This is realized by conducting peer reviews,
management reviews, thorough testing before product
release, etc.
SQA also helps the project team understand the quality
requirements for following the defined project processes.

Who should be concerned

People involved in planning and
implementing SQA within their project or
area of responsibility, specifically:

Project Managers, Project Software Managers, and

Task Leaders who evaluate, plan and implement
SQA within their project, as well as:
Software Engineers and Testers who work with
the SQA group
SQA engineers and members of related
software groups.

SQA Functions

Ensures SQA activities exist for all software

development and maintenance projects
Objectively and independently verifies that all
software products and activities adhere to the
applicable standards, procedures, and requirements
Seeks to resolve non-compliance issues with the
software project

For issues not resolvable within the software project, the

SQA function escalates the issue to an appropriate level of
management

Acts in an advisory role in clarifying and

understanding applicable software procedures and
practices

Barriers to SQA

Lack of understanding of the role of SQA

Lack of buy-in to the concept that SQA adds
value
Lack of process makes it impossible for SQA
to verify compliance
Lack of training in SQA functions
Misconception that SQA is responsible for
quality

SQA and Successful Projects

Develop a process focus.

Formulate an agreement with Senior Management to

establish an informed, independent SQA group.

In order to be successful QA must:

Operate within the scope of the project and respect the

confidentiality of the workgroups that you support.

Have unrestricted access to project information, activities,

results and

Provide visibility to Senior Management as to process

capability (CMM), process compliance and product quality.

SQA Key Process Areas Goals

Software quality assurance activities are

planned
Adherence of software products and
activities to the applicable standards,
procedures, and requirements is verified
objectively
Affected groups and individuals are
informed of software quality assurance
activities and results
Noncompliance issues that cannot be
resolved within the software project are

Instructions
1
2
3
4
5
6
7
8

Establishment of SQA
Planning SQA
Software Engineering Activities Evaluations
Software Engineering Work Products Evaluations
Reporting SQA Activities
Corrective Action System
Measuring SQA Status
Review of SQA Program

1 - Establishment of SQA

SQA group is established and fully integrated

with project activities
SQA group has independent reporting chain
to Senior Management for non-conformance
or non-compliance issues
SQA group has authority to take oversight
action

2 - Planning SQA

SQA group shall plan the project SQA activities

Plan reviewed by affected groups

Plan is managed and controlled
SQA activities conducted in accordance with the plan

SQA group participates in reviewing projects

plans, standards, and procedures

Compliance with Company policy

Compliance with externally imposed
standards/requirements
Standards appropriate for project use
Topics required in Software Development Plan (SDP)
Other project directed issues

SQA Planning Process

Analyze
Requirements
Understand
Development
Methodology
Understand
Project
Organization
Analyze Plan
Content/Format
Requirements

Plan by
Identifying
applicable
activities
Identifying
applicable
procedures
Scheduling
activities

Document/
update
planning in
quality plan
and other
standards

Distribute quality
plan for
Peer review
Product Assurance
management
review
Development
manager review
No

Comments
?
Yes

Resolve
Comments

Obtain sign-off
Implement
planned
activities

3 - Software Engineering Activities

Evaluations
SQA group verifies
Compliance with the SDP, and the designated
standards and procedures
Results are documented and a summary of
the evaluation is provided
Deviations are identified, corrective actions
are assigned, and tracked to closure

4 - Software Engineering Work Products Evaluations

Verify plans, standards, procedures are in place and can

be used to review and audit the project
Evaluate designated work products
Deliverable software products are evaluated prior to
customer delivery
Software engineering work products are evaluated
against designated standards and contractual
requirements.
Software engineering work products are produced in
accordance with the applicable procedures
The results of the evaluations shall be documented so
that a summary of the evaluations is provided and
deviations are identified, corrective actions are assigned
and tracked to closure.

SQA Process/Product
Evaluation
Perform
Process
Evaluation
Using detailed
checklists

Document
findings
and
anomalies
Shipping
recommend
ation for
deliverables

Originator
Resolves
Anomalies

SQA
Reviews
Updates
and
Changes

Perform
Product
Evaluation
Using
detailed
checklists

No

Nonconcurrence
issues exist
?

No

Yes

Need to
Elevate
Issues
?
Yes

Elevate Issues
to
Management

Ship or
Release
Product
Docume
nt
complia
nce

5 - Reporting SQA Activities

Findings from evaluations are reported

SQA activities and their status are reviewed
with the PM
At a minimum, the following is reported:

A summary of the results of the evaluations

performed since the last review
The measurements described in Instruction 7
SQA issues and concerns

6 - Corrective Action System

Verify corrective action system in closedloop

Deviations are identified, documented,

assigned, and tracked to closure

Monitor deviations

Deviations resolved at project team level

Escalation of noncompliance to Senior
Management

7 - Measuring SQA Status

SQA group measures its performance and

reviews with project management
Measurements tracked against the plan

Completion of SQA milestones

SQA work completed (effort and funds
expended)
Number of product audits and activity
evaluations completed

8 - Review of SQA Program

SQA group conducts periodic reviews with

customers SQA
Experts independent of the projects SQA
evaluate effectiveness of that projects
SQA function on an annual basis in
accordance with:
The results of this evaluation are
distributed to the project manager, the
project software manager, and senior
management within the Group.

RISK MANAGEMENT
Risk is defined as "The possibility of suffering
harm or loss; danger.
Risk management is the planned control of risk.
It involves monitoring the success of a
project, analyzing potential risks, and making
decisions about what to do about potential
risks.

RISK MANAGEMENT
Risks in Software Project Management
Dr. Barry W. Boehm in his article "Software Risk
Management: Principles and Practices lists the
following top 10 software risk items:

Personnel Shortfalls

Unrealistic schedules and budgets

Developing the wrong functions and properties

Developing the wrong user interface

Gold-plating

Continuing stream of requirements changes

Shortfalls in externally furnished components

Shortfalls in externally performed tasks

Real-time performance shortfalls

Straining computer-science capabilities

RISK MANAGEMENT
How to Manage
Dr. Boehm describes risk management as being comprised of
the following activities:
Risk Assessment (figuring out what the risks are and what
to focus on)

- making a list of all of the potential dangers that will affect the
project
- assessing the probability of occurrence and potential loss of each
item listed
- ranking the items (from most to least dangerous)

Risk Control (doing something about them)

- coming up with techniques and strategies to mitigate the highest

ordered risks
- implementing the strategies to resolve the high order risks factors
- monitoring the effectiveness of the strategies and the changing
levels of risk throughout the project

RISK MANAGEMENT
How to Manage general concept

RISK MANAGEMENT
Risk Identification:
The project manager needs to anticipate the risks in the project as
early as possible so that the impact of the risks can be minimized
by making effective risk management plans.
There are three main categories of risks which can affect a software
project as follows:
Project Risk: Project risks concern various forms of budgetary,
schedule, personnel and customer related problems.
Technical Risk: Technical risks concern potential design,
implementation, interfacing, testing, and maintenance problems. It
also include ambiguous specification, incomplete specification,
changing specification, technical uncertainty and obsolescence.
Business Risk: This type of risk include risks of building and
excellent product that no one wants, losing budgetary or personnel
commitments.

RISK MANAGEMENT
Risk Assessment/Analysis:
The objective of risk assessment is to rank the risks in terms of their
damage causing potential. For risk assessment, first each risk
should be rated in tow ways:
1.

The likelihood of a risk coming true(r)

2.

The consequence of the problems associated with that risk (s).

Based on these two factors, the priority of each risk can be

computed.
p=r*s
Where p is the priority with which the risk must be handled, r is the
probability of the risk becoming true, and s is the severity of
damage caused due to the risk becoming true. If all identified
risks are prioritized, then the most likely and damaging risks can
be handled first and more comprehensive risk abatement
procedures can be designed for these risks.

RISK MANAGEMENT
Risk Assessment/Analysis:

RISK MANAGEMENT
Risk Assessment/Analysis:

RISK MANAGEMENT
Risk Containment/Planning:
After all the identified risks of a project are assessed, plans must be made to
first contain the most damaging and the most likely risks. There are three
main strategies to plan for risk containment.

Avoid the risk: Risks can be avoided in several ways, such as discussing with
the customer to change the requirements to reduce the scope of the work,
giving incentives to the developers to avoid the risk of the manpower
turnover.
Transfer the risk: This strategy involves getting the risky component
developed by a third party, buying insurance cover and so on.
Risk reduction: This involves planning ways to contain the damage due to a
risk. The most important thing to do in addressing technical risks is to build
a prototype that tries out pieces of the technology that you are trying to
use.

RISK MANAGEMENT
Risk Containment/Planning:

RISK MANAGEMENT
Risk Containment/Planning:

RISK MANAGEMENT
Risk monitoring :

Assess each identified risks regularly to decide

whether or not it is becoming less or more
probable.

Also assess whether the effects of the risk have

changed.

Each key risk should be discussed at

management progress meetings.

RISK INDICATORS