Software Project Management

MCA 2nd Semester

 Syllabus
• Unit 1: Introduction to SPM and Project Planning
• What is a Software Project? Software Project versus Other
Projects
• Importance of SPM, Activities in SPM
• Project Success, and Failure
• What is Management?
• Traditional and Modern Management Practices
• Steps in Project Planning
• Selection of Project
• Identify Project Scope, Objectives, Infrastructure
• Analyze Project Characteristics, Project Products, and Activities
• Estimate Efforts
• Identify Risks
• Unit 2: Project Evaluation and Selection of Project
Approach
• Introduction to Project Evaluation
• Evaluation of Individual Projects
• Technical and Cost Benefit Analysis
• Risk Evaluation
• Software Process Models
• Introduction to Software Process Model
• Choice of Software Process Model
• The Waterfall Model, The Spiral Model
• Software Prototyping, V-Process
• Incremental Delivery, Rapid Application Development
• Agile Methods: Scrum, Sprint, Extreme Programming
Unit 3: Software Effort Estimation and Activity Planning
Basis for Software Estimation, Software Effort Estimation Techniques
Top-down and Bottom-up Approach, Parametric Models
Albrecht Function Point Analysis
COCOMO II, A Parametric Model
Activity Planning
Objectives of Activity Planning
Project Schedules,
Sequencing and Scheduling Activities
Network Planning Models
Time Dimension
Identifying Critical Path
Unit 4: Risk Management, Resource Allocation, Software Project
Testing
Risk Management: Introduction
Nature of Risk, Categories of Risk
A framework for dealing with Risk, Assessment of Risks
Applying the PERT Technique
Resource Allocation
Nature of resources
Identifying Resource Requirements
Scheduling Resources
Publishing Resource and Cost Schedule
Creating Critical Paths
Software Project Testing
Important concepts of software project testing
Testing objectives
Testing life cycle
Testing strategies
Black Box Testing Techniques
White Box Testing Techniques
Web Based Testing Techniques
Regression testing
Unit 5: Monitoring and Control, Software Quality
Creating the Framework
Collecting the Data
Review, Project Termination Review, Visualizing Progress
Cost Monitoring
Prioritizing Monitoring
Getting the Project Back to Target
Change Control
Software Quality
Importance of Software Quality
Place of Software Quality in Project Planning
Software Quality Characteristics
ISO 9126 Standard for Software Quality
Quality Plan for a Project
 What is project
• A project is Planned set of interrelated tasks to be
executed over a fixed period and within certain cost and
other limitations Key characteristics that distinguish
projects as follows:
Software project vs other types of project
 Software Project

A Software Project is the complete procedure of

software development from requirement gathering to
testing and maintenance, carried out according to the
execution methodologies, in a specified period of time
to achieve intended software product.
 What is management?
management is achieving goals in a way that makes the best use of all resources

This involves the following activities:

• Planning – It is the basic function of management. “Planning is
deciding in advance - what to do, when to do & how to do. It
bridges the gap from where we are & where we want to be”.
“deciding what is to be done”
• Organizing – It is the process of bringing together physical,
financial and human resources and developing productive
relationship amongst them for achievement of organizational goals.
“making arrangements”
• Staffing – It is the function of manning the organization structure
and keeping it manned. Manpower, training“selecting the right
people for the job”
• Directing – Supervision, Motivation, Leadership, Communication.
“giving instructions”
• Controlling –The purpose of controlling is to ensure that
everything occurs in conformities with the standards.
• Monitoring – checking on progress

• Innovating – coming up with solutions when problems

emerge

• Representing – liaising with clients, users, developers and

other stakeholders
 What is Project
Management?

• Project Management is the discipline of planning, organizing, motivating,

and controlling resources to achieve specific goals

• Project management is a methodical approach to planning and

guiding project processes from start to finish.
 Why Project
Management?

• Better control of financial, physical, and human

resources
• Improved customer relations
• Shorter development times
• Lower costs
• Higher quality and increased reliability
• Improved productivity
• Better internal coordination
 Activities covered by project
management

Feasibility study
Is project technically feasible and worthwhile from a business
point of view?
Planning
Only done if project is feasible
Execution
Implement plan, but plan may be changed as we go along
 ‘Step Wise’ - an overview
0.Select
1. Identify project 2. Identify project
project objectives infrastructure

3. Analyse
project
characteristics
Review
4. Identify products
and activities

5. Estimate effort
Lower for activity For each
level activity
detail 6. Identify activity
risks
10. Lower level
7. Allocate
planning
resources

8. Review/ publicize
9. Execute plan plan 16
 Step Wise – An Overview

• Step 0: Select project

• Step 1: Identify project scope and objectives
• Step 2: Identify project infrastructure
• Step 3: Analyze project characteristics
• Step 4: Identify project products and activities
• Step 5: Estimate effort for each activity
• Step 6: Identify activity risks
• Step 7: Allocate resources
• Step 8: Review/publicize plan
• Step 9: Execute plan
• Step 10: Execute lower levels of planning
 Step 1: Identify Project Scope and
Objectives
• Step 1.1 Identify objectives and practical
measures of the effectiveness in meeting those
objectives
• Step 1.2 Establish a project authority
– To ensure the unity of purpose among all persons
concerned
• Step 1.3 Identify all stakeholders in the project
and their interests
• Step 1.4 Modify objectives in the light of
stakeholder analysis
• Step 1.5 Establish methods of communication
between all parties
 Step 2: Identify Project Infrastructure

• Step 2.1 Identify relationship between the

project and strategic planning
– To prioritize project components
– To establish a framework within which the system
fits
– To ensure the hardware and software standards are
followed
• Step 2.2 Identify installation standards and
procedures
– more appropriate name: “Identify standards and
procedures related to the software project”
• Step 2.3 Identify project team organization
Step 3: Analyse Project Characteristics

• Step 3.1 Distinguish the project as either objective-

driven or product-driven
• Step 3.2 Analyse other project characteristics
(including quality-based ones)
• Step 3.3 Identify high level project risks
• Step 3.4 Take into account user requirements
concerning implementation
 Step 3: Analyse Project
Characteristics (cont’d)
• Step 3.5 Select general lifecycle approach in the light
of the above
• Step 3.6 Review overall resource estimates
Up to this stage,
– the major risks of the project are identified
– the overall approach of the project is decided
So, it is a good place to re-estimate the required effort and
other resources for the project
 Step 4: Identify Project Products and
Activities
• Step 4.1 Identify and describe project products
– Identify all the products related to the project
– Account for the required activities
• Step 4.2 Document generic product flows
– See book Product Flow Diagram (flow of modules)
• Step 4.3 Recognize product instances
• Step 4.4 Produce an ideal activity network
– Activity network shows the tasks that have to be carried
out as well as their sequence of execution for the creation
of a product from another
– Draw activity network diagram (flow of activities)
• Step 4.5 Modify the ideal to take into account need
for stages and checkpoints
– To check compatibility of products of previous activities
– Draw sequence diagram
Step 5: Estimate Effort for Each Activity

• Step 5.1 Carry out bottom-up estimates

– need to estimate staff effort, time for each activity,
and other resources
• Step 5.2 Revise plan to create controllable
activities
– need to break a task into a series of manageable
sub-tasks
 Step 6: Identify Activity Risks

• Step 6.1 Identify and quantify the risks of each

activity
• Step 6.2 Plan risk reduction and contingency
measures where appropriate
• Step 6.3 Adjust overall plans and estimates to
take account of risks
 Step 7: Allocate Resources (Staffing)
• Step 7.1 Identify and allocate resources
– type of staff needed for each activity
– staff availabilities are identified
– staff are provisionally allocated to task
• Step 7.2 Revise plans and estimates to take
into account resource constraints
– staffing constraints
– staffing issues
 Software Life Cycle Models/
SOFTWARE PROCESS MODELS
• Help in the software development

• Guide the software team through a set of

framework activities

• Process Models may be linear, incremental or

evolutionary
 THE WATERFALL
MODEL
• Used when requirements are well understood
in the beginning
• Also called classic life cycle
• A systematic, sequential approach to Software
development
• Begins with customer specification of
Requirements and progresses through
planning, modeling, construction and
deployment
Sequential model encompasses the following activities:
• System/information engineering and modeling.
Because software is always part of a larger system (or business), work begins by
establishing requirements for all system elements and then allocating some subset of
these requirements to software.
This system view is essential when software must interact with other elements such as
hardware, people, and databases.

• System engineering and analysis encompass requirements gathering at the system

level with a small amount of top level design and analysis. Information engineering
encompasses requirements gathering at the strategic business level and at the
business area level.

• Software requirements analysis.

The requirements gathering process is intensified and focused specifically on
software. To understand the nature of the program(s) to be built, the software engineer
("analyst") must understand the information domain
for the software, as well as required function, behavior, performance,
and interface. Requirements for both the system and the software are documented and
reviewed with the customer.
Design
Software design is actually a multistep process that
focuses on four distinct attributes of a program: data
structure, software architecture, interface representations,
and procedural (algorithmic) detail. The design process
translates requirements into a representation of the
software that can be assessed for quality before coding
begins. Like requirements, the design is documented and
becomes part of the software configuration.

Code generation
The design must be translated into a machine-readable
form. The code generation step performs this task. If
design is performed in a detailed manner, code generation
can be accomplished mechanistically.
Testing
Once code has been generated, program testing begins. The testing
process focuses on the logical internals of the software, ensuring that all
statements have been tested, and on the functional externals; that is,
conducting tests to uncover errors and ensure that defined input will
produce actual results that agree with required results.

Support
Software will undoubtedly undergo change after it is delivered to the
customer (a possible exception is embedded software). Change will occur
because errors have been encountered, because the software must be
adapted to accommodate changes in its external environment (e.g., a
change required because of a new operating system or peripheral device),
or because the customer requires functional or performance
enhancements. Software support/maintenance reapplies each of the
preceding phases to an existing program rather than a new one.
• The model implies that you should attempt to
complete a given stage before moving on to the next
stage

• Does not account for the fact that requirements

constantly change. It also means that customers can
not use anything until the entire system is complete.

• Surprises at the end are very expensive

• Therefore, this model is only appropriate when the

requirements are well-understood and changes will
be fairly limited during the design process.
 Limitations of the
waterfall model
• Problems:
1. Real projects are rarely follow the sequential model.

2. Difficult for the customer to state all the requirement

explicitly.

3. Assumes patience from customer - working version of

program will not available until programs not getting change
fully.
When to use the waterfall model
This model is used only when the requirements are
very well known, clear and fixed.
Product definition is stable.
Technology is understood.
There are no ambiguous requirements
Ample resources with required expertise are available
freely and The project is short.
In Waterfall model, very less customer interaction is involved during the
development of the product. Once the product is ready then only it can be
demonstrated to the end users.
Once the product is developed and if any failure occurs then the cost of fixing
such issues are very high, because we need to update everything from
document till the logic.
 Evolutionary Process
Model
• Produce an increasingly more complete
version of the software with each iteration.
• Evolutionary Models are iterative.
• Evolutionary models are:
– Prototyping
– Spiral Model
Evolutionary Process
Models : Prototyping
 Prototyping
• Prototyping start with communication, between a
customer and software engineer to define overall
objective, identify requirements and make a boundary.
• Going ahead, planned quickly and modeling (software
layout visible to the customers/end-user) occurs.
• Quick design leads to prototype construction.
• Prototype is deployed and evaluated by the customer/user.
• Feedback from customer/end user will refine requirement
and that is how iteration occurs during prototype to satisfy
the needs of the customer.
• Best approach when:
– Objectives defines by customer are general but does not
have details like input, processing, or output
 Prototyping (cont..)
 Prototype can be serve as “the first system”.
 Both customers and developers like the prototyping paradigm.
 Customer/End user gets a feel for the actual system
 Developer get to build something immediately.

Problem Areas:
 Customer cries foul and demand that “a few fixes” be applied to
make the prototype a working product, due to that software
quality suffers as a result.
 Developer often makes implementation in order to get a
prototype working quickly without considering other factors in
mind like OS, Programming language, etc.

Customer and developer both must be agree that the prototype is

built to serve as a mechanism for defining requirement.
 Spiral Model

• Spiral models uses prototyping as a risk reduction mechanism but, more

important, enables the developer to apply the prototyping approach at each
stage in the evolution of the product.

• It maintains the systematic stepwise approach suggested by the classic life

cycle but also incorporates it into an iterative framework activity.
• If risks cannot be resolved, project is immediately terminated
Problem Area:
• It may be difficult to convince customers (particularly in contract
situations) that the evolutionary approach is controllable.
• If a major risk is not uncovered and managed, problems will undoubtedly
occur.
 Spiral Model
Couples iterative nature of prototyping with the controlled and
systematic aspects of the linear sequential model

• It provide potential for rapid development of increasingly

more complete version of the software.
• Using spiral, software developed in as series of evolutionary
release.
– Early iteration, release might be on paper or prototype.
– Later iteration, more complete version of software.
• Evolutionary process begins in a clockwise direction,
beginning at the center risk.
• First circuit around the spiral might result in development of a
product specification. Subsequently, develop a prototype and
then progressively more sophisticated version of software.
• Unlike other process models that end when software is
delivered.
• It can be adapted to apply throughout the life of software.
Spiral model
Spiral sectors
model of the
software process
Determine objectives
Evaluate alternatives
alternatives and identify, resolve risks
constraints Risk
analysis
Risk
analysis
Risk
analysis Opera-
Prototype 3 tional
Prototype 2 protoype
Risk
REVIEW analysis Proto-
type 1
Requirements plan Simulations, models, benchmarks
Life-cycle plan Concept of
Operation S/W
requirements Product
design Detailed
Requirement design
Development
plan validation Code
Design Unit test
Integration
and test plan V&V Integr ation
Plan next phase test
Acceptance
Service test Develop, verify
next-level product
 Spiral model sectors

• Objective setting
– Specific objectives for the phase are identified
• Risk assessment and reduction
– Risks are assessed and activities put in place to reduce the
key risks
• Development and validation
– A development model for the system is chosen which can
be any of the generic models
• Planning
– The project is reviewed and the next phase of the spiral is
planned
 The Incremental Model
• The incremental model combines elements of the linear
sequential model (applied repetitively) with the iterative
philosophy of prototyping.

• For example, word-processing software developed using the

incremental paradigm might deliver basic file management,
editing, and document production functions in the first
increment; more sophisticated editing and document
production capabilities in the second increment; spelling
and grammar checking in the third increment; and advanced
page layout capability in the fourth increment. It should be
noted that the process flow for any increment can
incorporate the prototyping paradigm.
Incremental Process Model

C- Communication
P - Planning
M – Modeling
C - Construction
D - Deployment

Delivers software in small but usable pieces, each piece builds on pieces
already delivered
 The Incremental Model
• Rather than deliver the system as a single delivery, the
development and delivery is broken down into increments with
each increment delivering part of the required functionality.
• First Increment is often core product
– Includes basic requirement
– Many supplementary features (known & unknown) remain
undelivered
• A plan of next increment is prepared
– Modifications of the first increment
– Additional features of the first increment
• It is particularly useful when enough staffing is not available for
the whole project
• Increment can be planned to manage technical risks.
• Incremental model focus more on delivery of operation product
with each increment.
 The Incremental Model

• User requirements are prioritised and the

highest priority requirements are included in
early increments.
• Once the development of an increment is
started, the requirements are frozen though
requirements for later increments can
continue to evolve.
• Customer value can be delivered with each
increment so system functionality is available
earlier.
 Advantages of Incremental
model:
• Generates working software quickly and early during the
software life cycle.
• This model is more flexible – less costly to change
scope and requirements.
• It is easier to test and debug during a smaller iteration.
• In this model customer can respond to each built.
• Lowers initial delivery cost.
• Easier to manage risk because risky pieces are identified
and handled during it’d iteration
 Disadvantages of Incremental
model:
• Needs good planning and design.
• Needs a clear and complete definition of the
whole system before it can be broken down
and built incrementally.
 Rapid Application Development (RAD) Model

Makes heavy use of reusable software components with an extremely short

development cycle
 Rapid application development (RAD)
Rapid application development (RAD) is an incremental software
development process model that emphasizes an extremely short
development cycle.

When the requirements are fully understood and the component-based

construction approach is adopted then the RAD model is used.

The RAD model is a “high-speed” adaptation of the linear sequential

model in which rapid development is achieved by using component-
based construction.

If requirements are well understood and project scope is constrained, the

RAD process enables a development team to create a “fully functional
system” within very short time periods (e.g., 60 to 90 days) Used
primarily for information systems applications, the RAD approach
encompasses the following phases
 RAD model Phases
• Business modeling. The information flow among business functions is
modeled in a way that answers the following questions: What information
drives the business process? What information is generated? Who
generates it? Where does the information go? Who processes it?
Business modeling – Information flow among business is working.
Ex. What kind of information drives?
Who is going to generate information?
From where information comes and goes?

• Data modeling. The information flow defined as part of the business modeling phase
is refined into a set of data objects that are needed to support the business. The characteristics
(called attributes) of each object are identified and the relationships between
these objects defined.

Data modeling – Information refine into set of data objects that are needed to support business.
Process modeling. The data objects defined in the data modeling
phase are transformed to achieve the information flow necessary to
implement a business function. Processing descriptions are created for
adding, modifying, deleting, or retrieving a data object.

Application generation. RAD assumes the use of fourth generation

techniques Rather than creating software using conventional third
generation programming languages the RAD process works to reuse
existing program components (when possible) or create reusable
components (when necessary). In all cases, automated tools are used to
facilitate construction of the software.

Testing and turnover. Since the RAD process emphasizes reuse,

many of the program components have already been tested. This
reduces overall testing time. However,
new components must be tested and all interfaces must be fully exercised.
 RAD model
– Process modeling – Data object transforms to information flow necessary to
implement business.

• If requirement are well understood and project scope is

constrained then it enable development team to create “ fully
functional system” within a very short time period.
Advantages of the RAD model

• Reduced development time.

• Increases reusability of components
• Quick initial reviews occur Encourages
customer feedback
• Integration from very beginning solves a lot of
integration issues.
 Disadvantages of RAD model
• Depends on strong team and individual
performances for identifying business
requirements.
• Only system that can be modularized can be
built using RAD
• Requires highly skilled developers/designers.
• High dependency on modeling skills
• Inapplicable to cheaper projects as cost of
modeling and automated code generation is very
high
MODELS STRENGTH WEAKNESS TYPES OF PROJECT
For well-understood
Simple approach.
problem.
Simple. Do not allow changes.
Waterfall Short duration project.
Easy to execute. Cycle time is too long.
Model Automation of
Intuitive & logical. User feedback is not
adjusting manual
allowed.
system.
Helps in requirement System With massive
Possibly higher cost.
Prototyping elicitation. users.
Do not allow labour
Model Reduce the risk. Uncertainty in
charges.
Lead to a better system. requirement.
Each Iteration Can
Have Planning Over
Head.
Regular/Quick Cost may increase as For a business where
delivery. work done in one time is of the essence.
Iterative Enhancement
Reduces risk. iteration may have to Where the risk of the
Model
accumulate Changes. be undone later. long project can be
prioritizes requirement. System design & taken.
structure may suffer as
frequent changes are
made.
No strict standard for
Control project risk. software development.
Spiral Project build on
Very flexible. No particular began
Model untested assumptions
Less document needed. and ending of the
particular phase
 Lines of Code (LOC)

LOC is the simplest among all metrics available to estimate project size. This
metric is very popular because it is the simplest to use.

Using this metric, the project size is estimated by counting the number of
source instructions in the developed program.
Size Estimation
 Function Point Analysis
Function point metric was proposed by Alan Albrecht
while working for IBM, recognized the problem in size
measurent in the 1970s . This metric overcomes
many of the shortcomings of the LOC metric

One of the important advantages of using the

function point metric is that it can be used to easily
estimate the size of a software product directly from
the problem specification.

The conceptual idea behind the function point metric

is that the size of a software product is directly
dependent on the number of different functions or
features it supports.
14 factors for calculating Complexity adjustment factor with scale 0 to 5
A software project was estimated at 352 Function Points (FP).

A four person team will be assigned to this project consisting of an architect,

two programmers, and a tester. The salary of the architect is ` 80,000 per
month, the programmer ₹ 60,000 per month and the tester ₹ 50,000 per
month.

The average productivity for the team is 8 FP per person month. Find the
cost of the project.

Solution

FP = 352
Average FP = 8 per person per month
4 person team is assigned to the project which is consist of an architect( ₹
80,000 per month), two programmers(₹ 60,000 per person per month), and a
tester(₹ 50,000 per month). So, 352 / (8 * 4) = 11 months

projected cost of the project = (1 architect + 2 programmer + 1 tester) * 11

= (80000 + 2 * 60000 + 50000) * 11

= ₹ 2750000.