Download Project management

Software Engineering
Project Management
Software project management
Concerned with activities involved in
ensuring that software is delivered on
time and on schedule and in accordance
with the requirements of the
organisations developing and procuring
the software
The Aim of Project Management
To complete a project:
•
•
•
•
•
On time
On budget
With required functionality
To the satisfaction of the client
Without exhausting the team
Planning

Inadequate planning leads to frustration towards the
end of the project & poor project performance
Project Start
Project End
Triple Contraint
Time
Software
Cost
Quality
Management tasks
Planning

Organizing

Staffing

Directing

Controlling
… and dealing with deviations from the plan

“Plan the work and work the plan”
Project staffing

May not be possible to appoint the ideal
people to work on a project
• Project budget may not allow for the use of highlypaid staff
• Staff with the appropriate experience may not be
available
• An organisation may wish to develop employee skills
on a software project

there is an international shortage of skilled
IT staff
Software is Built by Teams
•
Best size for a team is 3 to 8 people
• Team members may include:
developers (from trainee to expert)
domain experts
graphic or interface designers
software librarians
testers
• Teams must have:
administrative leadership (manager)
technical leadership
Time distribution
20%
Non-productive
activities
30%
Working alone
50%
Interaction with
other people
Office layout
Meeting
room
Office
Office
Communal
area
Office
Window
Office
Office
Office
Of fice
Of fice
Shared
documentation
Human needs hierarchy
Selfrealization needs
Esteem needs
Social needs
Safety needs
Physiological needs
Team structure
(a)
management structure
(b)
communication pattern
Team structure
Project manager
Senior engineers
Junior engineers
(a)
management structure
(b)
communication pattern
Personality types

Task-oriented.
•

Self-oriented.
•

The motivation for doing the work is the work itself;
The work is a means to an end which is the achievement of
individual goals - e.g. to get rich, to play tennis, to travel
etc.;
Interaction-oriented
•
The principal motivation is the presence and actions of
co-workers. People go to work because they like to go to
work.
Software Business Questions
• You are employed for company X writing software.
When you leave, who owns your work? What use can you
make of the work?
• You work free-lance for company X. When you finish,
who owns your work? What use can you make of the work?
• You are a student on CS 502. What you finish what use
can you make of your project work? What use can
University make of it?
Read the contract!
PROJECT SCHEDULING
Project scheduling / Project planning




Split project into tasks and estimate time and
resources required to complete each task
Organize tasks concurrently to make optimal
use of workforce
Minimize task dependencies to avoid delays
caused by one task waiting for another to
complete
Dependent on project managers intuition and
experience
Scheduling problems




Estimating the difficulty of problems and hence the
cost of developing a solution is hard
Productivity is not proportional to the number of
people working on a task
Adding people to a late project makes it later because
of communication overheads
The unexpected always happens. Always allow
contingency in planning
Task durations and dependencies
Task
T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
T11
T12
Duration (da ys)
8
15
15
10
10
5
20
25
15
15
7
10
Dependencies
T1 (M1)
T2, T4 (M2)
T1, T2 (M3)
T1 (M1)
T4 (M5)
T3, T6 (M4)
T5, T7 (M7)
T9 (M6)
T11 (M8)
Activity network
8 days
15 days
M1
T3
15 days
T9
T1
25/7/99
4/7/99
start
14/7/99
5 days
4/8/99
25/8/99
T6
M4
M6
M3
7 days
20 days
15 days
T7
T2
25/7/99
10 days
M2
T4
T11
10 days
M7
T5
5/9/99
11/8/99
T10
18/7/99
M8
15 days
10 days
T12
M5
25 days
T8
Finish
19/9/99
Staff allocation
4/7
Fred
11/7
18/7
25/
1/8
8/8
15/8 22/8
29/8
5/9
T4
T8
T11
T12
Jane
T1
T3
T9
Anne
T2
T6
Jim
M ary
T7
T5
T10
12/9
19/9
Example: a compiler project
Compiler
project
Design
Scanner
Code
Parser
Integrate
and test
Code
generator
Write
manual
Example: a compiler project
March 7
build
scanner
Jan 1
start
Jan 3
design
March 7
build
parser
March 7
build code
generator
March 7
write
manual
Nov 14
integration
and testing
finish
Mar 17+
Activity bar chart
Staff allocation chart
RISK MANAGEMENT
Risk management

A risk is a probability that some adverse
circumstance will occur.
•
•
•

Project risks affect schedule or resources
Product risks affect the quality or performance of the
software being developed
Business risks affect the organisation developing or
procuring the software
Risk management is concerned with
identifying risks and drawing up plans to
minimize their effect on a project.
Software risks
Risk
Staff turnover
Risk type
Project
Management change
Project
Hardware unavailability
Project
Requirements change
Project and
product
Specification delays
Project and
product
Project and
product
Product
Size underestimate
CASE t ool underperformance
Technology change
Product comp etition
Business
Business
Description
Experienced staff will leave the
projec t before it is finished.
There will be a change of
organisational management with
different priorities.
Hardware which is essential for the
projec t will not be delivered on
schedule.
There will be a larger numb er of
changes to the requirements than
anticipated.
Specifications of essential interfaces
are not available on schedule
The size of the system has been
underestimated.
CASE t ools which support the
projec t do not perform as anticipated
The underlying technology on which
the system is b uilt is superseded by
new technology.
A competitive product is marketed
before the system is completed.
The risk management process
Risk
identification
Risk analysis
Risk planning
Risk
monitoring
List of potential
risks
Prioritised risk
list
Risk avoidance
and contingency
plans
Risk
assessment
The risk management process

Risk identification
•

Risk analysis
•

Assess the likelihood and consequences of these risks
Risk planning
•

Identify project, product and business risks
Draw up plans to avoid or minimise the effects of the risk
Risk monitoring
•
Monitor the risks throughout the project
Risk identification
Examples of different risk types
Risk type
Possible risks
Technology
The database used in the system cannot process as many transactions per
second as expected. (1)
Reusable software components contain defects that mean they cannot be
reused as planned. (2)
People
It is impossible to recruit staff with the skills required. (3)
Key staff are ill and unavailable at critical times. (4)
Required training for staff is not available. (5)
Organizational
The organization is restructured so that different management are responsible
for the project. (6)
Organizational financial problems force reductions in the project budget. (7)
Tools
The code generated by software code generation tools is inefficient. (8)
Software tools cannot work together in an integrated way. (9)
Requirements
Changes to requirements that require major design rework are proposed. (10)
Customers fail to understand the impact of requirements changes. (11)
Estimation
The time required to develop the software is underestimated. (12)
The rate of defect repair is underestimated. (13)
The size of the software is underestimated. (14)
Risk analysis



Assess probability and seriousness of
each risk
Probability may be very low, low,
moderate, high or very high
Risk effects might be catastrophic,
serious, tolerable or insignificant
Risk types and examples
Risk
Probability
Effects
Organizational financial problems force reductions in the project Low
budget (7).
Catastrophic
It is impossible to recruit staff with the skills required for the
project (3).
High
Catastrophic
Key staff are ill at critical times in the project (4).
Moderate
Serious
Faults in reusable software components have to be repaired
before these components are reused. (2).
Moderate
Serious
Changes to requirements that require major design rework are
proposed (10).
Moderate
Serious
The organization is restructured so that different management
are responsible for the project (6).
High
Serious
The database used in the system cannot process as many
transactions per second as expected (1).
Moderate
Serious
Risk types and examples
Risk
Probability
Effects
The time required to develop the software is underestimated
(12).
High
Serious
Software tools cannot be integrated (9).
High
Tolerable
Customers fail to understand the impact of requirements
changes (11).
Moderate
Tolerable
Required training for staff is not available (5).
Moderate
Tolerable
The rate of defect repair is underestimated (13).
Moderate
Tolerable
The size of the software is underestimated (14).
High
Tolerable
Code generated by code generation tools is inefficient (8).
Moderate
Insignificant
Risk planning


Consider each risk and develop a strategy to
manage that risk
Avoidance strategies
•

Minimisation strategies
•

The probability that the risk will arise is reduced
The impact of the risk on the project or product will be
reduced
Contingency plans
•
If the risk arises, contingency plans are plans to deal with
that risk
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
Risk type
Potential indicators
Technology
Late delivery of hardware or support software; many reported
technology problems.
People
Poor staff morale; poor relationships amongst team members;
high staff turnover.
Organizational
Organizational gossip; lack of action by senior management.
Tools
Reluctance by team members to use tools; complaints about
CASE tools; demands for higher-powered workstations.
Requirements
Many requirements change requests; customer complaints.
Estimation
Failure to meet agreed schedule; failure to clear reported
defects.
Feasibility Study
Before beginning a project, a short, low-cost study to identify
•
Client
•
Scope
•
Potential benefits
•
Resources needed:
staff, time, equipment, etc.
•
Potential obstacles
Where are the
risks? How can they be minimized?
Scope
What are the boundaries of the project?
Examples:
• Static web pages with open access on the Web [Web
Profiler]
• Used by the general public [Digital Collections]
• Varying data formats [Legal Information]
• Thousands of sensors [Data mining]
•
Support for Windows, Mac, Unix [SALSA]
Potential Benefits
Why are you doing this project?
Examples
• Create a marketable product
• Improve the efficiency of an organization
• Control a system that is too complex to control
manually
• New or improved service
• Safety or security
Resources
Examples:
Staff: 5 to 7 students, with some help. How many
hours per week? What skills do people have?
Time: Must be completed by end of semester,
including operational system, documentation,
presentation
Equipment and software: What special needs are
there?
Client: Will the client be sufficiently available and
helpful?
Feasibility Report
A written document
• For a general audience: client, financial management,
technical management, etc.
•
Short enough that everybody reads it
•
Long enough that no important topics are skipped
Looking for a well written, well presented document.
Failure to Cancel a Project
Example: University F developed a novel programming language.
• From 1985 to 1989, this was a promising language for simple
programming of window-based applications
• By 1990, clearly not gaining acceptance beyond University F
• But development continued for many more years (about $500K)
Not cancelled because ...
Too Big to Cancel!
Example: University A has antiquated administrative
systems. Senior management decides to replace them all
with commercial packages from X. The timetable and
budget are hopelessly optimistic.
• Staff get dispirited.
• The Chief Information Officer finds another job.
• A new Chief Information Officer is appointed.
What should she do?
We are doing it the Wrong Way!
Example: University B has a (big) joint project
with Company Y to develop a new computer
operating system.
After two years work, a junior software developer
persuades the university leader that the technical
approach is wrong.
• What should the university do?
• What should the company do?
How to Stop Gracefully
• It is harder to cancel a project than to start it.
• It is harder to withdraw a service than introduce it.
Considerations
• The proponents of the system must now reverse their public
stance.
=> Management of expectations
• Users of the service need a migration strategy.
• Technical staff must have a graceful path forward.
Time to Complete a Software
Project
Large software projects typically take at least two years from start to
finish
• Formative phase -- changes of plan are easy to accommodate
• Implementation phase -- fundamental changes are almost
impossible
Yet many things can change in two years.
Changing Requirements and
Design
Example: The CNRI Handle System -- a high performance,
distributed system to map names to resources (1994-99).
•
•
•
•
In 1994 only web browser was Mosaic
In 1994 Java did not exists
In 1994 mirroring and caching utilities were not available
In 1994 commercial interest was limited
Design decisions made in 1994 had to be changed. Software was
rewritten and greatly improved in 1998/9.
If a job's worth doing, it's worth doing twice!
Changes of Leadership
Many projects are wasted because of management
changes
Example: In 1988, Company W gave University D
$1,000,000 to port a new operating system to its personal
computers. The work was well done, on time.
• Company W changed its president and senior technical
staff during the project. The work was wasted.
• A decade later and several presidents later, Company W
is releasing a modern version of the same operating
system.
Case study:
Nokia software factories
• Geographically distributed environment
• typical project: 100 developers working in three to four sites
• synchronous work not possible (differences in time zones)
• Product family architecture
• architecture developed for an entire family, and components
developed to be used in all family members
• Concurrent engineering
• components developed concurrently at different sites,
retrieved from the various sites and combined in a central
location
• Use of tools
• process is tool supported (for requirements engineering,
design, coding, version management, configuration
management, and testing)
COST ESTIMATION
Cost estimation

We need predictive methods to
estimate the complexity of
software before it has been
developed
• predict size of the software
• use it as input for deriving the required
effort
Typical cost driver categories

Product
•

Computer
•

e.g., are there execution time or storage constraints?
Personnel
•

e.g., reliability requirements or inherent complexity
e.g., are the personnel experienced in the application
area or the programming language being used?
Project
•
e.g., are sophisticated software tools being used?
Productivity measures


Size related measures based on some output
from the software process. This may be lines of
delivered source code, object code instructions,
etc.
Function-related measures based on an
estimate of the functionality of the delivered
software. Function-points are the best known
of this type of measure.
A byproduct

Function points used to measure the
relative power of different languages
• compute number of source lines required to
code a function point
• numbers range from 320 (assembler
languages), 128 (C), 91 (Pascal), 71 (Ada83),
53 (C++, Java), 6 (“spreadsheet languages”)
System development times
Analysis
Assembly code
High-level language
Assembly code
High-level language
3 weeks
3 weeks
Design
Coding
Testing
5 weeks
5 weeks
8 weeks
4 weeks
10
weeks
6 weeks
Documentation
Size
Effort
Productivity
5000 lines
1500 lines
28 weeks
20 weeks
714 lines/month
300 lines/month
2 weeks
2 weeks
Algorithmic cost modelling



Cost is estimated as a mathematical function of
product, project and process attributes whose
values are estimated by project managers:
•
Effort = A  SizeB  M
•
A is an organisation-dependent constant, B reflects the
disproportionate effort for large projects and M is a multiplier
reflecting product, process and people attributes.
The most commonly used product attribute for cost
estimation is code size.
Most models are similar but they use different values for
A, B and M.
Generic formula for effort
PM = c.KLOCk
Legend
• PM: person month
• KLOC: K lines of code
• c, k depend on the model
• k>1 (non-linear growth)
Initial estimate then calibrated using a number
of "cost drivers"
COCOMO


Size estimate based on delivered source
instructions, KDSI
Categorizes the software as:
• organic
• semidetached
• embedded

each has an associated formula for nominal
development effort based on estimated code
size
COCOMO nominal effort and
schedule equations
Development Mode
Organic
Semidetached
Embedded
Nominal effort
(PM)NOM=3.2(KDSI)1.05
(PM)NOM=3.0(KDSI)1.12
(PM)NOM=2.8(KDSI)1.20
Schedule
TDEV=2.5(PMDEV))0.38
TDEV=2.5(PMDEV))0.35
TDEV=2.5(PMDEV))0.32
COCOMO 81
Project
complexity
Formula
Description
Simp le
PM = 2.4 (KDSI)1.05  M
Well-understood
applications
developed by small teams.
Moderate
PM = 3.0 (KDSI)1.12 M
More complex projects where
team members ma y have limited
experience of related systems.
Embedded
PM = 3.6 (KDSI)1.20  M
Complex projects where the
software is part of a strongly
coupled complex of hardware,
software,
regulations
and
operational procedures.
COCOMO 2


COCOMO 81 was developed with the
assumption that a waterfall process would be
used and that all software would be developed
from scratch.
Since its formulation, there have been many
changes in software engineering practice and
COCOMO 2 is designed to accommodate
different approaches to software development.
COCOMO 2 models


COCOMO 2 incorporates a range of sub-models that
produce increasingly detailed software estimates.
The sub-models in COCOMO 2 are:
•
•
•
•
Application composition model. Used when software is
composed from existing parts.
Early design model. Used when requirements are available but
design has not yet started.
Reuse model. Used to compute the effort of integrating
reusable components.
Post-architecture model. Used once the system architecture
has been designed and more information about the system is
available.
Use of COCOMO 2 models
Application composition model




Supports prototyping projects and projects where there is
extensive reuse.
Based on standard estimates of developer productivity in
application (object) points/month.
Takes CASE tool use into account.
Formula is
•
PM = ( NAP  (1 - %reuse/100 ) ) / PROD
•
PM is the effort in person-months, NAP is the number of application
points and PROD is the productivity.
Object point productivity
Developer‫ص‬
s experience
and capability
Very low
Low
Nominal
High
Very high
ICASE maturity and
capability
Very low
Low
Nominal
High
Very high
PROD (NOP/month)
4
7
13
25
50