PLANNING AND SCHEDULING

MODULE –II
 Topics to be covered

• Software requirements specification

• software prototyping
• software project planning, scope, resources
• software estimation
• empirical estimation models
• planning, risk management
• software project scheduling
• object-oriented estimation and scheduling.
 Software Requirement Specifications

• A software requirements specification (SRS) is

a document that captures complete
description about how the system is expected
to perform.
• It is usually signed off at the end of
requirements engineering phase.
Characteristics of good SRS
Properties of a good SRS document

• Concise
• Structured
• Black-box view
• Conceptual integrity
• Verifiable
 Structure of SRS

• 1. Introduction
(i) Purpose of this document
(ii) Scope of this document
(iii) Overview
2. General description
3. Functional Requirements
4. Interface Requirements
5. Performance Requirements
6. Design Constraints
7. Non-Functional Attributes
8. Preliminary Schedule and Budget
9. Appendices
 System prototyping
•Prototyping is the rapid development of a system.
•In the past, the developed system was normally
thought of as inferior in some way to the required
system so further development was required.
•Now, the boundary between prototyping and normal
system development is blurred.
•Many systems are developed using an evolutionary
approach

Lecture 10 - Prototyping 9
 Why bother?
• The principal use is to help customers and
developers understand the requirements for
the system
• Requirements elicitation: users can experiment
with a prototype to see how the system supports
their work
• Requirements validation: The prototype can reveal
errors and omissions in the requirements

• Prototyping can be considered as a risk

reduction activity which reduces 1
requirements risks 0
 Prototyping benefits
•Misunderstandings between software users and
developers are exposed
•Missing services may be detected and confusing
services may be identified
•A working system is available early in the process
•The prototype may serve as a basis for deriving a
system specification
•The system can support user training and system
testing
 Establish Define
Develop Evaluate
prototype prototyp
prototyp prototyp
objective e
e e
s functiona
lity

Prototypin Outline Executabl Evaluatio

g plan definitio e n
n prototype report
 Prototyping benefits
•Improved system usability
•Closer match to the system needed
Improved design quality
•Improved maintainability
• Fewer bugs and extensibility issues

• Reduced overall development effort

Lecture 10 - Prototyping 1
3
 Two different approaches
•Evolutionary prototyping:
• an initial prototype is produced and refined through a
number of stages to the final system
•Throw-away prototyping:
• a practical implementation of the system is produced to
help discover requirements problems and then
discarded
• the system is then developed using some other
development process

Lecture 10 - Prototyping 1
4
 Prototyping objectives

• The objective of evolutionary prototyping

is to deliver a working system to end-users
• The development starts with those requirements
which are best understood.

• The objective of throw-away prototyping is

to validate or derive the system requirements
• The prototyping process starts with those
requiements which are poorly understood

9
 Evolutionary Delivered
prototyping system
Outline
Requirements
Throw-away Executable Prototype +
Prototyping System Specification
 Evolutionary prototyping
• Must be used for systems where the
specification cannot be developed in
advance e.g. AI systems and user interface
systems
• Based on techniques which allow rapid
system iterations
• Verification is impossible as there is no
formal specification
•Validation means demonstrating the adequacy of
the system - does what it says on the tin
Develop abstract Build prototype Use prototype
specification system system

Deliver YES System

system adequate?
Evolutionary prototyping advantages
Accelerated delivery of the system
Rapid delivery and deployment are sometimes
more important than functionality or long-term
software maintainability

User engagement with the system

Not only is the system more likely to meet user
requirements, they are more likely to commit to the use
of the system

Lecture 10 - Prototyping
 Evolutionary prototyping
Specification, design and implementation are inter-
twined
The system is developed as a series of increments
that are delivered to the customer
Techniques for rapid system development are used
such as CASE tools and 4GLs
User interfaces are usually developed using a
GUI development toolkit

Lecture 10 - Prototyping
Evolutionary prototyping problems
Management problems
Existing management processes assume a waterfall model
of development
Specialist skills are required which may not be available in
all development teams

Maintenance problems
Continual change tends to corrupt system structure so
long-term maintenance is expensive

Contractual problems
 Throw-away prototyping
•Used to reduce requirements risk
•The prototype is developed from an initial
specification, delivered for experiment then discarded
•The throw-away prototype should NOT be
considered as a final system
• Some system characteristics may have been left out
There is no specification for long-term
maintenance
• The system will be poorly structured and difficult to
maintain Lecture 10 - Prototyping 16
 Outline Develop Evaluate Specif
requirements prototyp y
e prototyp system
Reusable e
components

Delivered
Develo Validate softwar
p system e
softwar system
e
 Prototype delivery
•Developers may be pressurised to deliver a throw-away
prototype as a final system
•This is crazy talk (by business heads)!!
• It may be impossible to tune the prototype to meet non-
functional requirements
• The prototype is inevitably undocumented
• The system structure will be degraded through changes
made during development
• Normal organisational quality standards may not have been
applied

Lecture 10 - Prototyping
 Rapid prototyping techniques
•Various techniques may be used for
rapid development
• Dynamic high-level language development
Database programming
• Component and application assembly

•These are not exclusive techniques - they are

often used together
•Visual programming is an inherent part of
most prototype development systems
Lecture 10 - Prototyping
 Dynamic high-level languages
• Languages which include powerful data
management facilities e.g. Java, Prolog,
Python
• Need a large run-time support system. Not
normally used for large system development
• Some languages offer excellent UI
development facilities
• Some languages have an integrated
support environment whose facilities may
be used in the prototype
Choice of prototyping language
•What is the application domain of the
problem? What user interaction is
required?
•What support environment comes
with the language?
•Different parts of the system may be
programmed in different languages. However,
there may be problems with language
communications
Lecture 10 - Prototyping
Component and application assembly
•Prototypes can be created quickly from a set
of reusable components plus some
mechanism to ‘glue’ these component
together
•The composition mechanism must include
control facilities and a mechanism for component
communication
•The system specification must take into
account the availability and functionality of
existing components
Lecture 10 - Prototyping
 Prototyping with reuse
Application level development
Entire application systems are integrated with the prototype so
that their functionality can be shared
For example, if text preparation is required, a standard word
processor can be used

Component level development

Individual components are integrated within a standard
framework to implement the system
Framework can be a scripting language or an integration
framework such as CORBA.

Lecture 10 - Prototyping 23
 Reusable Component
software Executabl
e
components compositio
prototype
n
framework
Control and
integration code
 Visual programming

• Scripting languages where the prototype

is developed by creating a user interface
from standard items and associating
components with these items
• A large library of components exists to
support this type of development
• These may be tailored to suit the
specific application requirements
• Visual basic is actually good for
 User interface prototyping
•It is impossible to pre-specify the look and feel of a
user interface in an effective way. prototyping is
essential
•UI development consumes an increasing part of
overall system development costs
•User interface generators may be used to ‘draw’
the interface and simulate its functionality with
components associated with interface entities
•Web interfaces may be prototyped using a web
site editor
Lecture 10 - Prototyping
 Project planning

• Software project planning is task, which is

performed before the production of software
actually starts.
• It is there for the software production but
involves no concrete activity that has any
direction connection with software
production; rather it is a set of multiple
processes, which facilitates software
production
 Factors effecting planning

• Project complexity
• Project size
• degree of structural uncertainty
Project planning process
 Software scope and feasibility
Software scope describes
• the functions and features that are to be
delivered to end users
• the data that are input and output
• the “content” that is presented to users as a
consequence of using the software
• and the performance, constraints, interfaces,
and reliability that bound the system.
 Scope is defined using one of two
techniques
1. A narrative description of software scope is
developed after communication with all
stakeholders.
2. A set of use cases is developed by end users
 Resources

• Human resources
• Reusable software resources
• Environmental resources
 Software project estimation

• Software cost and effort estimation will never

be an exact science.
• Too many variables
—human, technical, environmental, political
—can affect the ultimate cost of software and
effort applied to develop it.
• To achieve reliable cost and effort estimates, a
number of options arise
1. Delay estimation until late in the project
(obviously, we can achieve 100 percent accurate
estimates after the project is complete!).
2. Base estimates on similar projects that have
already been completed.
3. Use relatively simple decomposition techniques
to generate project cost and effort estimates.
4. Use one or more empirical models for software
cost and effort estimation.
 Decomposition techniques

• Software Sizing
• Problem-Based Estimation
• Process-Based Estimation
• Estimation with Use Cases
• Reconciling Estimates
 Software Sizing
The accuracy of a software project estimate is
predicated on a number of things:
(1) the degree to which you have properly
estimated the size of the product to be built
(2) the ability to translate the size estimate into
human effort, calendar time, and dollars
(3) the degree to which the project plan reflects the
abilities of the software team; and
(4) the stability of product requirements and the
environment that supports the software
engineering effort
 Putnam and Myers suggest four different
approaches to the sizing problem:
• Fuzzy logic sizing
• Function point sizing.
• Standard component sizing.
• Change sizing
 Problem-Based Estimation

LOC and FP data are used in two ways during

software project estimation:
(1) as estimation variables to “size” each
element of the software and
(2) as baseline metrics collected from past
projects and used in conjunction with
estimation variables to develop cost and effort
projections
 Estimating three point value

• A three-point or expected value can then be

computed. The expected value for the
estimation variable (size) S can be computed
as a weighted average of the optimistic (sopt),
most likely (sm), and pessimistic (spess)
estimates. For example,
Process-Based Estimation
 Estimation with Use Cases
developing an estimation approach with use cases is
problematic for the following reasons:
• Use cases are described using many different formats
and styles—there is no standard form.
• Use cases represent an external view (the user’s view)
of the software and can therefore be written at many
different levels of abstraction.
• Use cases do not address the complexity of the
functions and features that are described.
• Use cases can describe complex behavior (e.g.,
interactions) that involve many functions and features.
Estimating LOC or FP
 Empirical estimation models
• Empirical estimation is a technique or model
in which empirically derived formulas are used
for predicting the data that are a required and
essential part of the software project planning
step.
• These techniques are usually based on the
data that is collected previously from a project
and also based on some guesses, prior
experience with the development of similar
types of projects, and assumptions. It uses the
size of the software to estimate the effort.
The Structure of Estimation Models

• A typical estimation model is derived using

regression analysis on data collected from past
software projects.

•where A, B, and C are empirically derived constants, E

is effort in person-months, and ev is the estimation
variable (either LOC or FP).
 The COCOMO II Model

• The name COCOMO, for COnstructive COst

Model.
• It has evolved into a more comprehensive
estimation model, called COCOMO II.
COCOMO II is actually a hierarchy of estimation
models that address the following areas:
• Application composition model. Used during the
early stages of software engineering, when
prototyping of user interfaces, consideration of
software and system interaction, assessment of
performance, and evaluation of technology maturity
are paramount.
• Early design stage model. Used once requirements
have been stabilized and basic software architecture
has been established.
• Post-architecture-stage model. Used during the
construction of the software.
COCOMO II Model Sizing Estimates

• Three different sizing options are available as

part of the model hierarchy: object points,
function points, and lines of source code.
• like function points, the object point is an
indirect software measure that is computed
using counts of the number of
(1) screens (at the user interface),
(2) reports, and
(3) components likely to be required to build the
application
The Software Equation
• You should note that the software equation
has two independent parameters:
(1) an estimate of size (in LOC) and
(2) an indication of project duration in calendar
months or years.
 Risk management

There are three main classifications of risks

which can affect a software project:
• Project risks
• Technical risks
• Business risks
Other forms of risks
• Known risks
• Predictable risks
• Unpredictable risks
 Principle of Risk Management

• Global Perspective
• Take a forward-looking view
• Open Communication
• Integrated management
• Continuous process
 Risk identification
• One method for identifying risks is to create a
risk item checklist. The checklist can be used for
risk identification and focuses on some subset of
known and predictable risks in the following
generic subcategories
• Product size—risks associated with the overall
size of the software to be built or modified.
• Business impact—risks associated with
constraints imposed by management or the
marketplace
• Stakeholder characteristics—risks associated
with the sophistication of the stakeholders and
the developer’s ability to communicate with
stakeholders in a timely manner.
• Process definition—risks associated with the
degree to which the software process has been
defined and is followed by the development
organization.
• Development environment—risks associated
with the availability and quality of the tools to be
used to build the product.
• Technology to be built—risks associated with
the complexity of the system to be built and
the “newness” of the technology that is
packaged by the system.
• Staff size and experience—risks associated
with the overall technical and project
experience of the software engineers who will
do the work.
 Assessing Overall Project Risk
• The following questions have been derived
from risk data obtained by surveying
experienced software project managers in
different parts of the world . The questions are
ordered by their relative importance to the
success of a project.
1. Have top software and customer managers
formally committed to support the project?
2. Are end users enthusiastically committed to
the project and the system/ product to be
built?
3. Are requirements fully understood by the software
engineering team and its customers?
4. Have customers been involved fully in the
definition of requirements?
5. Do end users have realistic expectations?
6. Is the project scope stable?
7. Does the software engineering team have the right
mix of skills?
8. Are project requirements stable?
9. Does the project team have experience with
the technology to be implemented?
10. Is the number of people on the project team
adequate to do the job?
11. Do all customer/user constituencies agree
on the importance of the project and on the
requirements for the system/product to be
built?
 Risk Components and Drivers
The risk components are defined in the following manner:
• Performance risk—the degree of uncertainty that the
product will meet its requirements and be fit for its
intended use.
• Cost risk—the degree of uncertainty that the project
budget will be maintained.
• Support risk—the degree of uncertainty that the
resultant software will be easy to correct, adapt, and
enhance.
• Schedule risk—the degree of uncertainty that the project
schedule will be maintained and that the product will be
delivered on time
 Risk projection
• Risk projection, also called risk estimation, attempts
to rate each risk in two ways—
(1) the likelihood or probability that the risk is real
and
(2) the consequences of the problems associated with
the risk, should it occur.
 four risk projection steps

1. Establish a scale that reflects the perceived

likelihood of a risk.
2. Delineate the consequences of the risk.
3. Estimate the impact of the risk on the project
and the product.
4. Assess the overall accuracy of the risk
projection so that there will be no
misunderstandings.
Developing a Risk Table
Risk concern
Assessing Risk Impact
 The RMMM plan

• Risk Mitigation
• Risk Monitoring
• Risk Management and planning
 Risk Mitigation

It is an activity used to avoid problems (Risk

Avoidance).
Steps for mitigating the risks as follows finding
out the risk.
• Removing causes that are the reason for risk
creation.
• Controlling the corresponding documents
from time to time.
• Conducting timely reviews to speed up the
work
 Risk Monitoring

• It is an activity used for project tracking.

It has the following primary objectives as
follows.
To check if predicted risks occur or not.
• To ensure proper application of risk aversion
steps defined for risk.
• To collect data for future risk analysis.
• To allocate what problems are caused by
which risks throughout the project.
 Risk Management and planning
• It assumes that the mitigation activity failed
and the risk is a reality. This task is done by
Project manager when risk becomes reality
and causes severe problems.
• If the project manager effectively uses project
mitigation to remove risks successfully then it
is easier to manage the risks.
• This shows that the response that will be
taken for each risk by a manager. The main
objective of the risk management plan is the
risk register.
 Project scheduling

• Software project scheduling is an action that

distributes estimated effort across the
planned project duration by allocating the
effort to specific software engineering tasks.
• Scheduling for software engineering projects
can be viewed from two rather different
perspectives.
• In the first, an end date for release of a
computer-based system has already (and
irrevocably) been established. The software
organization is constrained to distribute effort
within the prescribed time frame.
• The second view of software scheduling
assumes that rough chronological bounds have
been discussed but that the end date is set by
the software engineering organization.
 Basic principles

• Compartmentalization.
• Interdependency
• Time allocation
• Effort validation
• Defined responsibilities
• Defined outcomes
• Defined milestones
The Relationship Between People and
Effort
 Defining a task set for project
1. Concept development projects that are initiated to
explore some new business concept or application of
some new technology.
2. New application development projects that are
undertaken as a consequence of a specific customer
request.
3. Application modifications to function, performance, or
interfaces that are observable by the end user.
4. Application maintenance projects that correct, adapt, or
extend existing software in ways that may not be
immediately obvious to the end user.
5. Reengineering projects that are undertaken with the
intent of rebuilding an existing (legacy) system in whole.
 Task set example
• Concept development projects are
approached by applying the following actions:
1.1 Concept scoping determines the overall
scope of the project.
1.2 Preliminary concept planning establishes the
organization’s ability to undertake the work
implied by the project scope.
1.3 Technology risk assessment evaluates the
risk associated with the technology to be
implemented as part of the project scope.
1.4 Proof of concept demonstrates the viability
of a new technology in the software context.
1.5 Concept implementation implements the
concept representation in a manner that can
be reviewed by a customer and is used for
“marketing” purposes when a concept must
be sold to other customers or management.
1.6 Customer reaction to the concept solicits
feedback on a new technology concept and
targets specific customer applications.
Defining a task network
 Scheduling techniques
• Program evaluation and review technique (PERT) and
the critical path method (CPM) are two project
scheduling methods that can be applied to software
development.
• Both PERT and CPM provide quantitative tools that
allow you to (1) determine the critical path—the
chain of tasks that determines the duration of the
project,
(2) establish “most likely” time estimates for individual
tasks by applying statistical models, and
(3) calculate “boundary times” that define a time
“window” for a particular task.
Time-Line Charts
 Tracking the Schedule
Tracking can be accomplished in a number of different ways:
• Conducting periodic project status meetings in which each
team member reports progress and problems
• Evaluating the results of all reviews conducted throughout
the software engineering process
• Determining whether formal project milestones have been
accomplished by the scheduled date
• Comparing the actual start date to the planned start date for
each project task listed in the resource table.
• Meeting informally with practitioners to obtain their
subjective assessment of progress to date and problems on
the horizon
• Using earned value analysis to assess progress quantitatively
 Object oriented estimation
Lorenz and Kidd suggest the following approach:
1. Develop estimates using effort decomposition,
FP analysis, and any other method that is
applicable for conventional applications.
2. Using the requirements model, develop use
cases and determine a count. Recognize that
the number of use cases may change as the
project progresses.
3. From the requirements model, determine the
number of key classes.
 4. Categorize the type of interface for the
application and develop a multiplier for
support classes:

5. Multiply the total number of classes (key + support) by

the average number of work units per class. Lorenz and
Kidd suggest 15 to 20 person-days per class.
6. Cross-check the class-based estimate by multiplying
the average number of work units per use case