3.

1 THE MANAGEMENT
SPECTRUM
Effective software project
management focuses on the four Ps
The People
The Product
The Process
The Project

THE W5HH PRINCIPLE

Why is the system being
developed?
What will be done, by when?
Who is responsible for a
function?
Where are they organizationally
located?
How will the job be done
technically and managerially?
How much of each resource is

3.2 The People

In a study published by the IEEE
[CUR88], the engineering vice
presidents of three major technology
companies were asked the most
important contributor to a successful
software project. They answered in
the following way:
VP 1: I guess if you had to pick one
thing out that is most important in

3.2.1 The Players

Senior managers who define the business issues that often
have significant influence on the project.
Project (technical) managers who must plan, motivate,
organize, and control the practitioners who do software
work.
Practitioners who deliver the technical skills that are
necessary to engineer a product or application.
Customers who specify the requirements for the software
to be engineered and other stakeholders who have a
peripheral interest in the outcome.
End-users who interact with the software once it is released
for production use.

3.2.2 Team Leaders

Motivation. The ability to encourage technical
people to produce to their best ability.
Organization. The ability to mold existing
processes (or invent new ones) that will enable the
initial concept to be translated into a final product.
Ideas or innovation. The ability to encourage
people to create and feel creative even when they
must work within bounds established for a
particular software product or application.

 Characteristics that define an effectiveness of the

project manager emphasizes on four key traits:
Problem solving.- An effective software project
manager can diagnose the technical and
organizational issues that are most relevant,
systematically structure a solution or properly
motivate other practitioners to develop the
solution, apply lessons learned from past projects
to new situations, and remain flexible enough to
change direction if initial attempts at problem
solution are fruitless.
Managerial identity.- A good project manager
must take charge of the project. She must have
the confidence to assume control when necessary
and the assurance to allow good technical people
to follow their instincts.

3.2.3 The Software Team

The following options are available for
applying human resources to a
project that will require n people
working for k years:
1. n individuals are assigned to m different
functional tasks, relatively little combined
work occurs; coordination is the
responsibility of a software manager who
may have six other projects to be
concerned with.

 The best team structure depends on the management

style of your organization, the number of people who will
populate the team and their skill levels, and the overall
problem difficulty.
There are three generic team organizations:
Democratic decentralized (DD). This software
engineering team has no permanent leader. Rather, "task
coordinators are appointed for short durations and then
replaced by others who may coordinate different tasks."
Decisions on problems and approach are made by group
consensus. Communication among team members is
horizontal.
Controlled decentralized (CD). This software engineering
team has a defined leader who coordinates specific tasks
and secondary leaders that have responsibility for subtasks.
Problem solving remains a group activity, but
implementation of solutions is partitioned among subgroups
by the team leader. Communication among subgroups and
individuals is horizontal. Vertical communication along the

There are seven project factors that should

be considered when planning the structure
of software engineering teams:
The difficulty of the problem to be solved.
The size of the resultant program(s) in lines of
code or function points
The time that the team will stay together (team
lifetime).
The degree to which the problem can be
modularized.
The required quality and reliability of the system
to be built.
The rigidity of the deployment date.
The degree of sociability (communication)
required for the project.

There are four organizational paradigms for software

engineering teams:
1.A closed paradigm structures a team along a
traditional hierarchy of authority . Such teams can work
well when producing software that is quite similar to past
efforts, but they will be less likely to be innovative when
working within the closed paradigm.
2. The random paradigm structures a team loosely and
depends on individual initiative of the team members.
When innovation or technological break-through is
required, teams following the random paradigm will excel.
But such teams may struggle when orderly performance
is required.

3. The open paradigm attempts to structure a team in a

manner that achieves some of the controls associated with
the closed paradigm but also much of the innovation that
occurs when using the random paradigm. Work is
performed collaboratively, with heavy communication and
consensus-based decision making the trademarks of open
paradigm teams. Open paradigm team structures are well
suited to the solution of complex problems but may not
perform as efficiently as other teams.
4. The synchronous paradigm relies on the natural
compartmentalization of a problem and organizes team
members to work on pieces of the problem with little active
communication among themselves.

3.2.4 Coordination and

Communication Issues
Formal, impersonal approaches include software
engineering documents and deliverables (including
source code), technical memos, project milestones,
schedules, and project control tools , change requests
and related documentation, error tracking reports, and
repository data
Formal, interpersonal procedures focus on quality
assurance activities applied to software engineering
work products. These include status review meetings
and design and code inspections.
Informal, interpersonal procedures include group
meetings for information dissemination and problem
solving and collocation of requirements and

 Electronic communication encompasses electronic

mail, electronic bulletin boards, and by extension, videobased conferencing systems.
Interpersonal networking includes informal discussions
with team members and those outside the project who
may have experience or insight that can assist team
members.

3.3 The Product

3.3.1 Software Scope

Context. How does the software to be built fit into a

larger system, product, or business context and what
constraints are imposed as a result of the context?
Information objectives. What customer-visible data
objects are produced as output from the software? What
data objects are required for input?
Function and performance. What function does the
software perform to transform input data into output? Are
any special performance characteristics to be addressed?

3.4 THE PROJECT

Below mentioned signs indicate that
an information systems project is not
in proper order
1. Software people dont understand
their customers needs.
2. The product scope is poorly defined.
3. Changes are managed poorly.
4. The chosen technology changes.
5. Business needs change [or are illdefined].
6. Deadlines are unrealistic.

3.5 CRITICAL PRACTICES

Formal risk management. What are the top ten
risks for this project? For each of the risks, what is
the chance that the risk will become a problem
and what is the impact if it does?
Empirical cost and schedule estimation. What
is the current estimated size of the application
software (excluding system software) that will be
delivered into operation? How was it derived?
Metric-based project management. Do you
have in place a metrics pro-gram to give an early
indication of evolving problems? If so, what is the
cur-rent requirements volatility?

 Earned value tracking. Do you report monthly

earned value metrics? If so, are these metrics
computed from an activity network of tasks for the
entire effort to the next delivery?
Defect tracking against quality targets. Do
you track and periodically report the number of
defects found by each inspection (formal technical
review) and execution test from program inception
and the number of defects currently closed and
open?
People-aware program management. What is
the average staff turnover for the past three
months for each of the suppliers/developers
involved in the development of software for this
system?

MEASURES, METRICS, AND

INDICATORS
Measure provides a quantitative indication of the
extent, amount, dimension, capacity, or size of
some attribute of a product or process.
A software metric relates the individual measures
in some way (e.g., the average number of errors
found per review or the average number of errors
found per person hour expended on reviews
An indicator is a metric or combination of metrics
that provide insight into the software process, a
software project, or the product itself

 Project indicators enable a software

project manager to (1) assess the
status of an ongoing project, (2) track
potential risks, (3) uncover problem
areas before they go critical, (4)
adjust work flow or tasks, and (5)
evaluate the project teams ability to
control quality of software work
products.

Software Project
Estimations
Estimation of resources ,cost and
schedule of software development
are very important. To make a
good estimate requires experience
and expertise to convert qualitative
measures to quantitative form.
Factors like Project size, Amount of
risk involved etc areaffecting the
accuracy and efficacy of estimates.

Estimation Techniques
The following are the different
techniques for estimation
Decomposition Technique
Empirical Estimation Models
Automated Estimation Tools

Decomposition
Technique
Here we subdivide the problem into
small problems. When all the small
problems are solved the main
problem is solved.
Lines of Code
Function Point
LOC (Lines of Code), FP(Function
Point) estimation methods consider
the size as the measure. In LOC the
cost is calculated based on the

Empirical Estimation
Models
Estimation models uses empirically
derived formulas to predict the
estimates. Here we conduct a study on
some completed projects. From those
observation we form some statistical
formulas. We can use this formulas to
estimate the cost of other projects.
The structure of empirical estimation
models is a formula, derived from data
collected from past software projects,
that uses software size to estimate

COCOMO
Stands for COnstructive COst MOdel
Introduced by Barry Boehm in 1981 in his book
Software Engineering Economics
Became one of the well-known and widely-used
estimation models in the industry
It has evolved into a more comprehensive
estimation model called COCOMO II
COCOMO II is actually a hierarchy of three
estimation models
As with all estimation models, it requires sizing
information and accepts it in three forms: object
points, function points, and lines of source code

Automated Estimation
Tools
The decomposition techniques and
the empirical estimation models can
be implemented using software.
These automated tools allow the
planner to estimate the cost and
effort and will also give important
information like delivery date
,staffing.

Make/Buy Decision
It is often more cost effective to acquire rather than develop
software
Managers have many acquisition options
Software may be purchased (or licensed) off the shelf
Full-experience or partial-experience software
components may be acquired and integrated to meet
specific needs
Software may be custom built by an outside contractor to
meet the purchasers specifications
The make/buy decision can be made based on the following
conditions
Will the software product be available sooner than
internally developed software?
Will the cost of acquisition plus the cost of customization
be less than the cost of developing the software internally?
Will the cost of outside support (e.g., a maintenance
contract) be less than the cost of internal support?

Software Project
Planning
Planning provides a road map for
the software development process.

Objective of Software Project

Planning
Software Scope
Resources
Objective of Software Project
Planning
The objective of software project

Software Scope
The first activity in software
project planning is the
determination of software scope. A
software project scope must be
unambiguous and understandable
at the management and technical
levels.The software scope means
the actual operation that is going
to carried out by the software and
its plus points and limitations.
Resources

Project Scheduling &

Tracking
Compartmentalization - the product and process must be

decomposed into a manageable number of activities and

tasks
Interdependency - tasks that can be completed in parallel
must be separated from those that must completed serially
Time allocation - every task has start and completion dates
that take the task interdependencies into account
Effort validation - project manager must ensure that on any
given day there are enough staff members assigned to
completed the tasks within the time estimated in the project
plan
Defined Responsibilities - every scheduled task needs to be
assigned to a specific team member
Defined outcomes - every task in the schedule needs to
have a defined outcome (usually a work product or
deliverable)
Defined milestones - a milestone is accomplished when one
or more work products from an engineering task have

Risk Management
Risk always involves two
characteristics:Uncertainty, Loss.If
the risk becomes a reality unwanted
loss will occur.
Software project Risk
Technical Risk
Business Risk
Software project Risk
Software project Risk threaten the
project plan.If the project risk

Technical Risk
Technical Risk threaten quality of the
software to be produced. The technical
risk occur when the problem is harder
to solve than we thought.

Business Risk
Business Risk threaten the viability of
the software to be built. ie, building
an excellent product that no one
really wants in the market. Building a
product that no longer fit into the

Risk MMM: Risk

Mitigation, Monitoring
and Management

Risk Mitigation
Risk mitigation is to avoid the risk and
is the best strategy. Here we should
take much care to avoid the
possibility of risk.
Risk Monitoring
As the project proceeds the risk
monitoring activity starts. This is to
find the occurrence of risk.
Risk Management

COCOMO formula
E = abKLOCbb
D = cbEdb
whereEis the effort applied in
person-months,Dis the development
time in chronological months and
KLOC is the estimated number of
delivered lines of code for the project
(express in thousands)

 E = aiKLOCbixEAF
whereEis the effort applied in
person-months andKLOCis the
estimated number of delivered lines
of code for the project

Analysis Principle
Requirements analysis is a software
engineering task that bridges the gap
between system level requirements
engineering and software design
problem recognition
evaluation and synthesis
modeling
specification
review

UNIT 4

Requirement
Engineering tasks
Inception

Inception means specifying beginning

of project. Most of software project
gets started because of business
need or when new market is
discovered.
Here stakeholders from business
community define business case for
idea and try to find breadth and depth

Elicitation
In Elicitation requirements are elict
from customers, users and others.
Also it will be find out from
customers, users and others what are
the product objectives what is to be
done to accomplish these objectives.
Moreover it is necessary to know how
product fits into business needs, and
how the product is used on a day to
day basis.
Requirement elicitation is difficult due
to following reasons. Problems of

Elaboration
The information obtained from the
customer during inception and
elicitation is expanded and refined
during elaboration.
Elaboration Focuses on developing a
refined technical model of software
functions, features and constraints.
It is driven by the creation and
refinement of user scenarios.

Negotiation
In negotiation phase reconciling of
conflicting requirement need to be
carried out. Here customer asked to
rank their requirements according to
their priority.
Using iterative approach
requirements are prioritized.
At the end theres no winner and loser
after completion of negotiation
activity.

Specification
Specification means different thing to
different people.
It can be written document, a set of
graphical models, a formal
mathematical model, a collection of
usage scenarios, a prototype, or any
combination of these.
It is the final work product produced
by the requirements engineer.
It serves as the foundation for
subsequent software engineering
activities.

Validation
Work products produced are assessed
for quality in this step.
A task which examines the
specification to ensure that all
software requirements have been
stated unambiguously.
That inconsistencies, omissions and
errors have been detected and
corrected.
That work products conform to the
standards established for the process,
project and the product.

Requirements Management
During requirements management, the
project team performs a set of activities to
identify, control, and track requirements
and changes to the requirements at any
time as the project proceeds
Each requirement is assigned a unique
identifier
The requirements are then placed into one
or more traceability tables
These tables may be stored in a database
that relates features, sources,
dependencies, subsystems, and interfaces
to the requirements.

Requirement Modeling
Scenario based modeling
Behavioral Modeling
Class-Based Modeling
Flow-oriented modeling

Scenario based modeling

Scenario based elements represents how

the user interacts with the system.
And the specific sequence of activities
that occur as the software is used.

Behavioral Modeling
Behavioral element depict how
external events change the state of
the system or the classes that reside
within it.

Class-Based Modeling
Class-based element modeling
represent the object the system will
manipulate and the operations that
will be applied to the objects that the
system will manipulate.
Also it represent the operation that
will be applied to the objects to effect
the manipulation.
Other than this it also represents
relationship between objects and

Flow-oriented modeling

It represents system as an information

transform and depicts how the data
objects are transformed as they flow
through various system functions.