Transcript MBDA Software Engineering Training Course

Module Objectives
• At the end of this module students should:
•
•
•
•
•
•
•
•
Describe the major activities in software project management,
Prescribe organisational structures appropriate to software projects,
Understand the basic principles for planning and scheduling a project,
Define the basic mechanisms for project control,
Understand the principles of software risk management,
Develop an appropriate approach to software estimation,
Identify the principle issues involved in managing software reuse,
Understand the issues involved in team recruitment and management
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
1
Topics Covered
•
•
•
•
•
•
•
Project Planning and Scheduling
Project Control
People Management
Risk Management
Software Estimation
Reuse Management
Requirements Control
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
2
What’s So Difficult about Software
Management?
© Copyright De Montfort University 2001 All Rights Reserved
Nature of a Project
• Creates Change
• Has Composite Goals
– Human, Technical, Structural
•
•
•
•
•
Is Unique
Is limited in time and scope
Involves a variety of resources
May be large or complex
May involve several phases.
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
4
What’s special about software projects?
•
•
•
•
•
•
Intangible
Complex
No standard processes
More skill-dependent
Often greater social effect
Flexibility
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
5
Therefore..
• Greater chance of failure.
• Greater Uncertainty.
• Greater Chance of being affected by
organisational change.
• ...
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
6
Problems with Software Projects
•
•
•
•
•
•
•
Estimating!
Measuring!
Communicating!
Negotiating!
Resourcing!
Marketing!
Training!
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
7
The Project Manager’s Role
© Copyright De Montfort University 2001 All Rights Reserved
What is Management?
•
•
•
•
•
•
•
•
Planning
Organising
Staffing
Directing
Monitoring
Controlling
Innovating
Representing
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
9
persuasive
communicator
technically competent
effective planner
The Project
Manager
good project trainer
effective manager of
teams
organisationally powerful
good controller
sensitive to the problems
of change
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
10
The Project Lifecycle
• Describe a typical project Lifecycle
• Where does software project management
start?
• Where does it end?
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
11
Software Project Management Activities
© Copyright De Montfort University 2001 All Rights Reserved
Time Billing System
• You have been given the brief for the Time
Billing System
• Consider
– When problems do you envisage with this
project?
– What questions would you ask?
– What initial activities would you undertake as
project manager?
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
13
What Management Practice should be in
place?
• Project Planning, Control and Tracking
Methods
• Software Quality Management
• Software Configuration Management
• Quantitative Management
• Training.
– Consider the CMM ….
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
14
Software Capability Maturity Model
•
1)Initial.
–
•
2) Repeatable.
–
•
The software process for both management and engineering activities is documented,
standardized, and integrated into a standard software process for the organization. All projects
use an approved, tailored version of the organization's standard software process for developing
and maintaining software.
4) Managed.
–
•
Basic project management processes are established to track cost, schedule, and functionality.
The necessary process discipline is in place to repeat earlier successes on projects with similar
applications.
3) Defined.
–
•
The software process is characterized as ad hoc, and occasionally even chaotic. Few processes
are defined, and success depends on individual effort and heroics.
Detailed measures of the software process and product quality are collected. Both the software
process and products are quantitatively understood and controlled.
5) Optimizing.
–
Continuous process improvement is enabled by quantitative feedback from the process and
from piloting innovative ideas and technologies.
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
15
Project Planning Activities
•
•
•
•
•
•
•
•
Identify project scope and objectives
Identify project infrastructure
Analyse project characteristics
Identify project products and activities
Estimate effort for each activity
Identify activity risks
Allocate resources
Review and publicize plan
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
16
Identify project scope and objectives
• Identify objectives and measures of
effectiveness
• Establish a project authority
• Identify stakeholders in the project
• Modify objectives in light of stakeholder
analysis
• Establish methods of communication
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
17
Identify project infrastructure
• Establish relationship between project and
organisation
• Identify standards and procedures
– Project planning and control
– Configuration management
– Quality
• Identify project team organisation
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
18
Analyse project characteristics
• Analyse nature of software product
• Identify high level project risks
• Take into account client’s standards and
requirements
• Select lifecycle approach
• Review overall resource requirements
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
19
Identify project products and activities
• Identify and describe project products
(product breakdown structure)
• Document generic product flow
• Recognise product instances
• Produce ideal activity network
• Modify to take into account need for stages
and checkpoints
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
20
Estimate effort for each activity
• Carry out bottom up estimates
• Revise plans in light of estimates
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
21
Identify activity risks
• Identify and quantify activity-based risks
• Plan risk reduction and contingency
measures
• Adjust plans and estimates to take account
of risks
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
22
Allocate Resources
• Identify and allocate resources
• Revise plans and estimates to account for
resource constraints
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
23
Review and Publicize Plan
• Review quality aspects of project plan
• Document plans and obtain agreement
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
24
Organisational Structures
© Copyright De Montfort University 2001 All Rights Reserved
Organisational Structure
• Organisational structure is required to
enable:
– managerial control
– technical control
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
26
Steering Committee
• Focuses on managerial control
• Receives details of project through
reporting process
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
27
Steering Committee Membership
•
•
•
•
•
•
•
•
•
Organisational board member
Finance
IT management
Project manager
Suppliers
Sub-project manager
Quality manager
Risk manager
Estimator
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
28
Steering Committee
Project Manager
Sub-project
Sub-project
Contract Manager
Sub-project
Sub-contractors
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
29
Steering Group Agenda
•
•
•
•
•
•
•
•
Project status
Changes to:
•
•
•
•
Actions taken / required
Responsibilities
Causes
Future issues
Objectives
Scope
Risks
Benefits
Costs
Schedules
Staffing
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
30
Managing Large Scale Projects
•
Extra Work
•
•
•
•
Education
managing physical resources
testing
file conversion
•
Problems
•
•
•
•
Staffing - turnover
Changes
Organisational change
intra-organisational co-ordination
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
31
Managing Large Scale Projects
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Delivery Strategies
Monolithic
version/release
`evolutionary / fast track
Project Culture
technical
‘logo’
marketing
project induction
‘timeout’
Managing stakeholders
Negotiation
reviews
Briefing
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
32
Steering Committee
Project Management
Sub-projects
= link persons
use of e-mail
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
33
Large Projects
•
Mandatory formal project management.
•
Standard
•
More detailed steering committee involvement.
•
Project management 20-30% of development effort.
•
Need for clerical support
•
Essential use of project management tools
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
34
Activity Planning
© Copyright De Montfort University 2001 All Rights Reserved
Planning Goals
• Ensure appropriate resources will be ready when required;
• Avoid different activities competing for same resources;
• Produce detailed schedule showing which staff carry out
which activity
• Produce detailed plan against which achievement can be
measured,
• Produce timed cash flow forecast;
• Replan project during its lifer to correct drift from target.
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
36
Defining Activities
• Activities
–
–
–
–
Have clearly defined start and end point
Require forecastable resources
Forecastable duration
May have precedence requirements
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
37
Identifying Activities
• Activity-based approach
–
–
–
–
List all activities (brainstorm)
Sub-divide project
Create work breakdown structure
Create task catalogue
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
38
Identifying Activities
• Product Based Approach
–
–
–
–
Used in PRINCE2
Product Breakdown Structure
Product Flow Diagram
List of Activities identified from
transformations
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
39
Product Breakdown Structure
Project
Management
Application
Design
Technical
Education
Quality
User
Operations
Testing
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
40
ToR
Acceptance
Criteria
Requirements
Design
Test
Application /
Product
Education
User
Release
System
Product Flow Diagram
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
41
The transition between product (s) involves numerous activities.
DESIGN
again, very high
level
program system
APPLICATION
These activities, which have durations and dependencies, can be identified
from the transitions between products at a detailed level from product flows
within the product breakdown structure.
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
42
The activities can be listed:Ref
Activity Description
05
10
20
30
Produce stage plans
Produce requirements
Identify enhancements
Produce acceptance criteria
Duration
(days)
3
15
5
5
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
Dependencies
05
10
05
43
The activities can then be ordered on a PERT activity network:
30
05
10
30
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
44
Activity Network
4
B
D
3
3
G
1
A
2
E
2
C
4
F
1
2
3
4
5
6
7
8
9
10
A
B
C
D
E
F
G
Technical Plan
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
45
Each activity becomes a box:-
EARLIEST START TIME
REF
LATEST START TIME
DURATION
EARLIEST FINISH TIME
ACTIVITY DESCRIPTION
TOTAL FLOAT
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
LATEST FINISH TIME
46
Critical Path
• A line which passes through all activities which has
zero float.
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
47
Resource Allocation
• We then need to allocate activities to resource
(people) 
Technical Plan
• Resources allocated in order of float - activities with
floats may have to wait.
• But we haven’t got unlimited resources
•  resource smoothing
•
move activities within their floats
•
change resource allocation
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
48
SSADM Version 4
Step 310
Define required
system processing
Stage 3: Definition of Requirements
am end c l DFD to
agree w ith BS O a nd LDS
(this giv es required
sys tem DFD)
Step 330
Derive system
functions
Step 350
Develop
specification
prototypes
use r.s . DFD and
LDM for
reference
Step 360
Develop
processing
specification
Step 380
Assemble
requirements
specification
require d syste m
LDM prepare d
use r.s . DFD to identify
update & e nquiry functions
refer to r.s. LDM as necessa ry
Step 340
Enhance required
data model
Step 370
Confirm system
objectives
RJP/SSADM 3/PP
Step 320
Develop required
data model
validate and
enhanc e LDM
from RDA
use r.s . DFD and LDM as input s to
entity/e vent m odelling, creat ing ELHs,
EAPs and ECDs
update require d syste m LDM
as necessa ry
cross c hec k LDM agains t all
othe r products
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
49
Stage
Description
310
Define required
processing
Develop required data model
Derive system functions
Enhance required data model
Develop
specification
prototypes
Develop
processing
specification
Confirm system objectives
Assemble
requirements
specification
320
330
340
350
360
370
380
Analyst
(days)
system 3
User
(days)
1
Programmer
(days)
Manager
(days)
2
8
4
4
1
2
1
8
1
1
2
2
2
1
1
1
1
10
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
1
50
Project Control
© Copyright De Montfort University 2001 All Rights Reserved
Project Control
• Monitoring and controlling the Project to
ensure that it stays on course and
reacts to unexpected events. Project
control is the core of the Project
Manager's effort on the project,
handling the day-to-day management of
the project.
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
52
Project Control Activities
• authorising work to be done
• gathering progress information about
that work
• watching for changes
• reviewing the situation
• reporting
• taking any necessary corrective action.
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
53
THE CONTROL CYCLE
DATA
CAPTURE
QUALITY
REVIEW
INTERPRETATION
STAGE
PRODUCT
PROJECTION
PROBLEMS
DEVELOPMENT
IMPACT
ANALYSIS
CORRECTIVE
ACTION
REPLANNING
QUALITY
PLANS
REPORTING
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
54
Report Type
Oral formal
regular
Oral formal
ad-hoc
Written
formal
regular
Written
formal adhoc
Oral informal
ad-hoc
Examples
Weekly or monthly
progress meetings
End-of-stage review
meetings
Job sheets, time
sheets, progress
reports
Exception reports,
change reports.
Comments
While report may be oral, formal
written minutes should be kept
Will generate written reports
Canteen discussion,
Social interaction
Provides early warning
Weekly using forms
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
55
Visualising Progress
•
•
•
•
Gantt Chart
Slip Chart
Ball Charts
Timeline
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
56
Approaches to getting back on target
•
•
•
•
•
Get more people
Revise targets
Revise deadline
Cut quality
Use alternative method (e.g. Rapid
Application Development)
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
57
Software Risk Management
© Copyright De Montfort University 2001 All Rights Reserved
Risk Management is a Core Activity
• Software Management is about risk
management
– Maintaining a tolerance for uncertainty and
learning;
– Expecting and reacting to changing context;
– Structuring project management around risk
management;
– Understanding the relationship of the project to
organisational risk (internal and external).
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
59
What is Risk Management?
• Risk:
– The possibility of suffering harm or loss,
danger.
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
60
Risk is not bad
• Risk in itself is not bad; risk is essential to progress, and
failure is often a key part of learning. But we must learn to
balance the possible negative consequences of risk against
the potential benefits of its associated opportunity."
• [Van Scoy, Roger L. Software Development Risk:
Opportunity, Not Problem. Software Engineering Institute,
CMU/SEI-92-TR-30, ADA 258743, September 1992]
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
61
A loss associated with the event
• Loss of time, quality,control, understanding
– e.g. Requirements change
• Risk Impact
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
62
The likelihood that the event will occur
• Estimate probability that event will occur
– e.g. New machine not delivered on time.
• Risk probability
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
63
The degree to which we can change the
outcome
• Minimising effect of event occuring.
• Avoid the event occuring.
• Risk Control
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
64
Quantification
• Risk exposure =
– Risk impact x risk probability
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
65
Risk Types
• Generic
• Project-specific
• Involuntary
• Voluntary
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
66
Risk Management Activities
• Risk Assessment
– Risk Identification
– Risk Analysis
– Risk Prioritisation
• Risk Control
– Risk reduction
– Risk management planning
– Risk resolution
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
67
Risk Identification
• Checklists
• Decomposition
• Assumption Analysis
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
68
Boehm’s Risk List
•
•
•
•
•
•
•
•
•
•
Personnel shortfalls
Unrealistic schedules and budgets
Developing the wrong software functions
Developing the wrong user interface.
Gold plating
Continuing stream of requirement changes.
Shortfalls in externally furnished components.
Shortfalls in externally performed tasks.
Real time performance shortfalls
Straining computer science capabilities.
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
69
Risk Factors (Hughes and Cotterell)
•
•
•
•
•
•
•
•
•
Application
Staff
Project
Project Methods
Hardware/Software
Changeover
Supplier
Environment
Health and Safety
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
70
MANAGEMENT
Actors
Technology
Structure
communication,
authority,
systems of work
flow
Tasks
know-how and tools
what is being done?
PROJECT
Actors
Structure
Technology
Tasks
SYSTEM
Actors
Technology
Structure
Tasks
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
71
Risk Analysis
•
•
•
•
•
Performance models
Cost models
Network Analysis
Decision Analysis
Quality Analysis
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
72
Risk Prioritisation
• Risk Exposure
• Compound risk reduction
– A priority scheme enables you to devote your
resources only to the most threatening risks
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
73
Risk Reduction
• Hazard Prevention
• Likelihood reduction
• Risk reduction leverage
– Avoid the risk
– Transfer the risk
– Assume the risk
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
74
Risk Leverage
• (Risk exposure before reduction - risk
exposure after reduction) / (cost of risk
reduction)
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
75
Risk Management Planning
• Contingency Planning
• Risk element planning
• Risk plan integration
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
76
Risk Resolution
• Risk mitigation
• Risk Monitoring and reporting
• Risk reassessment
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
77
Improving Risk Management
• Use qualitative and well as quantitative Data
• Collect your own historical data (Don’t rely on
other people’s)
• Avoid false sense of objectivity
• Quantify risk in a meaningful way
• Take into account values, beliefs and bias
• Look at risk throughout software development life
cycle
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
78
Seven Principles of Risk Management
(SEI)
•
Global perspective
– Viewing software development within the context of the larger systems-level
definition, design, and development.
– Recognizing both the potential value of opportunity and the potential impact of
adverse effects.
•
Forward-looking view
– Thinking toward tomorrow, identifying uncertainties, anticipating potential
outcomes.
– Managing project resources and activities while anticipating uncertainties.
•
Open communication
– Encouraging free-flowing information at and between all project levels.
– Enabling formal, informal, and impromptu communication.
– Using processes that value the individual voice (bringing unique knowledge and
insight to identifying and managing risk).
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
79
Seven Principles of Risk Management
(SEI)
•
Integrated management
–
Making risk management an integral and vital part of project management.
– Adapting risk management methods and tools to a project's infrastructure and
culture.
•
Continuous process
– Sustaining constant vigilance and identifying and managing risks routinely through
all phases of the project's life cycle.
•
Shared product vision
– Mutual product vision based on common purpose, shared ownership, and collective
communication and focusing on results.
•
Teamwork
– Working cooperatively to achieve common goal.
– Pooling talents, skills, and knowledge.
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
80
Build your own management data
• Quality
• Estimation
• Risk Management
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
81
Software Effort Estimation
© Copyright De Montfort University 2001 All Rights Reserved
Why is Estimating So Difficult?
• Think of some things you have to estimate: Are you
generally accurate? Are your estimates generally
optimistic?
• People often underestimate times and distances. Why is
this?
• Should we rely on people’s subjective estimates of
programming tasks?
• Often accurate estimates of the size of a software project
are so large as to be dismissed as unrealistic, or put the
client off. Is there a compromise possible?
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
83
What are we trying to estimate?
•
•
•
•
•
•
•
•
•
•
•
•
•
Staff resources
Analysis
Programming
Documentation
Management
Computer resources
Terminals
Disk space requirements
CPU time
Overheads
Support
Meetings
Performance assessment
Project control systems
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
84
Properties of an Estimating Method
• Gives early guidance to the size of a project with an
accuracy of +/- 30%,
• Should be easy to use,
• Should give consistent results,
• Uses agreed rules,
• Is supported by tools.
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
85
Who should do the estimating?
•
•
•
•
•
Development Team
Consultant Project Estimator
Project Manager
Customer
Steering Committee
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
86
Approaches to Estimating
• Estimates made by an expert. An expert in the business field and the
programming language provides estimates.
• Estimates made using reasoning by analogy. A similar type of project
is examined and compare to the new project.
• Estimates based on price-to-win. The amount the client can afford is
considered, and competitive bidders are undercut.
• Estimates based on available capacity. If we have limited staff
resources then that may determine what we can do.
• Estimates based on use of parametric methods. Parametric methods
use equations to derive estimate which contain constants derived from
statistical studies of a large number of projects.
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
87
Software Cost Estimation Models
Sizer Stage
NOT BASED ON LINES OF CODE
Productivity
Stage
Based on lines
of code
Based on
function points
Based on
functional
primitives
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
etc.
88
Function Point Analysis
• Count logical functions
–
–
–
–
–
External inputs
- screens
External outputs
- report
Logical master files
Enquiry transactions
Interfaces to other applications
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
89
Multiply by weightings to obtain
unadjusted function points
Type of Function Point
External Input
External Output
Logical Internal File
External Interface File
External Inquiry
Weighting
Simple
3
4
7
5
3
Average
4
5
10
7
4
Complex
6
7
15
10
6
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
90
Function Point Analysis
• Calculate processing complexity adjustment
•
•
•
•
•
•
•
Data communications
Performance
Transaction rate
End-user efficiency
Complex processing
Installation ease
Multiple sites
Distributed functions
Heavily used configuration
On-line data entry
On-line update
Re-usability
Operational ease
Facilitate change
• Calculate adjusted function point measure
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
91
Productivity Estimating Methods
• Static Approaches
• A Static, single variable approach uses one constant
(derived from previous studies) and makes no allowance
for influencing factors:
L = Line of Code (previously estimated)
E = 1.4L 0.93
Effort (m months)
DOC = 30.4L 0.90 Documentation (# pages)
D = 4.6L 0.26
Duration (months)
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
92
• A Static, multivariable approach adds variables to
represent the factors that can influence productivity:
•
•
•
E = 5.22 0.91
D = 4.12 0.36
I =  Wi Xi
Xi =  -1,0,1 
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
93
• A Dynamic, multivariable assumes that there are a finite
number of problems, that each solved problem has an
effect on others, and that a decision can remove unsolved
problem. For example, once we’ve programmed one
insert/amend/update program we can model the rest on it
and produce them faster.
• Examples are the Norden / Rayleigh Manpower
Distribution Model and the Putman Model for Software
Development.
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
94
Object Points
• Number of separate screens
• Number of reports
• Number of 3GL modules needed to
supplement 4GL code
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
95
COCOMO 2
• Early prototyping level
– PM = (NOP x (1 - %reuse/100))/PROD
• Early design level
– PM = A x Size B X M X PMm
• Post-architecture level
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
96
COCOMO2 Cost Drivers
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
RELY: Required software reliability
DATA: Database size
CPLX: Product complexity
DOCU Extent of documentation required
RUSE Required percentage of reusable components
TIME: Execution time constraint.
STOR: Main storage constraint.
PVOL: Volatility of development platform
ACAP: Analyst capability.
AEXP: Application experience.
PCAP: Programmer capability
PEXP Programmer experience in project domain
LTEX Language and tool experience
PCON Personnel continuity
TOOL: Use of Software Tools
SCED: Schedule Constraint.
SITE Extent of multi-site working and quality of site communications
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
97
Cost Driver
RELY
DATA
CPLX
STOR
TIME
PVOL
ACAP
AEXP
PCAP
PEXP
LTEX
SITE
TOOL
SCED
Very Low
0.75
0.7
Low
0.88
0.94
0.85
1.46
1.29
1.42
1.21
1.14
1.24
1.24
1.23
0.87
1.19
1.13
1.17
1.1
1.07
1.1
1.1
1.08
Nominal
1
1
1
1
1
1
1
1
1
1
1
1
1
1
High
1.15
1.08
1.15
1.11
1.06
1.15
0.86
0.91
0.86
0.9
0.95
0.91
0.91
1.04
Very High
1.4
1.16
1.3
1.3
1.21
1.3
0.71
0.82
0.7
Extra High
1.65
1.66
1.56
0.82
0.83
1.1
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
98
Software Reuse Management
© Copyright De Montfort University 2001 All Rights Reserved
Why Reuse?
•
•
•
•
•
Cost saving
Increased speed of development
Increased reliability
Increased quality
Better standards compliance through
componentisation.
• Reduced process risk
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
100
What to Reuse
•
•
•
•
•
Specifications
Design
Class Definitions
Source Code
Data Structures.
– Reuse involves more that just some subroutines
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
101
What Inhibits Reuse?
• Conflict with time and budget priorities
• Developers do not know what is available to be
reused
• ‘Not invented here’ syndrome
• Reuse assets do not meet performance needs
• Reuse across team boundaries raise coordination
and ownership issues
• Version management problems
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
102
Traditional Approach to Reuse
• Centralised library
• Incentive scheme
• Lack of documentation
– leads to reuse junkyard.
• Reuse must be senstive to the organisational
culture and incentive-compatible
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
103
Dimensions of Reuse
• Organisational
• Reuse Production
• Reuse funding
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
104
Requirements
• Supporting tools
• Supporting metrics
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
105
Organisational Models
• Library - passive library of components, minimal
certification.
• Curator - quality certification, marketing and component
funding.
• Product Centre - identifies, acquires, stores components
• Expert Services - reuse experts loaned out.
• Team Producer - decentralised reuse teams
• Reuse factory - application teams just assemble
components
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
106
Where should reuse be focussed?
•
•
•
•
•
Pre-project domain analysis
In project domain analysis
In project generalisation
Post-project generalisation
Next project generalisation
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
107
Funding Models
• Overhead
– pooled with other overheads
• Tax
– flat reuse levy on all application projects e.g. %
of total project costs
• Pay-for-components
– needs cost sharing bank
• Activity-based costing
– charge according to degree of consumption
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
108
Reuse Process: Creating Reusable Assets
•
•
•
•
•
Creating new assets
Analysing existing systems
Assessing proposed asset
Verifying new asset
Assessing technology trends
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
109
Using Reusable Assets
• Match Requirements with Reusable assets
• Building Products
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
110
Support Reusable Assets
•
•
•
•
•
Certify new asset
Gather reuse statistics and feedback
Classify and version manage assets
Train applications staff
Answer reuse questions
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
111
Manage Reusable Assets
• Define reuse policy
• Deal with reuse conflicts
• Review new asset procurement and
development proposals
• Obtain funding.
• Control funding, collect revenue, allocate
reuse grants to teams.
• Market reuse
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
112
Reuse Points
• Reuse adds costs (11 -380% more to make a
component reusable).
• Costs and risks of reuse consumption need
to be shifted outside application projects.
• Reuse program must be compatible with
software development culture and
incentives.
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
113
People Management
© Copyright De Montfort University 2001 All Rights Reserved
Issues
•
•
•
•
•
•
•
•
Groups and teams
Motivation
Use of Consultants
Targets and overtime
Recruitment
Personality Types
Business/ IT gap
Appraisals
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
115
Team Members
• Driver
– Develops ideas innovates,
– Predicts future,
– Wants to see things changed.
• Planner
– Logical thinker
– Takes ‘required future’ turns it into actions that the team
can do.
– Well-organised
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
116
Team Members
•
•
•
Enabler
– Interested in personal values.
– ‘Sales’ person. Outgoing, persuasive.
Executive
– Realists - turn action into results
– Want to get on and do it.
– What needs attention now
– Makes effort to assure that team works in harmony to get things done.
Controller
– Analytical thinker
– Enjoys detail - like costs and benefits
– Spots errors
– Monitors progress
– Assesses against objectives
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
117
Appraisals
• Clarify Purpose
– promotion review
– training review
• Establish clear performance standards
–
actual job responsibility
• Monitor performance and provide ongoing feedback
– use mini-appraisals
– proper supervision
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
118
Appraisals
• Conduct a written evaluation
– clear, unambiguous
– supported by examples
• Take time to do it
• Problems
– unclear standards
– lack of preparation
– no ongoing performance feedback
– lack of knowledge
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
119
Business/IT Gap
• Perceptions - users
• IT people earn large salaries.
• Projects fail.
• Slaves to methodology.
• Secret budgeting.
• Separate location.
• Technical / education.
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
120
Business / IT Gap
• Perceptions - IT
• Our systems are too good for you stupid users.
• We know what you need.
• Users can’t make their minds up.
• Users don’t understand technical difficulties.
• Is there any wonder there are communications
problems?
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
121
People Capability Maturity Model
•
Level 2 Key Practices

Work Environment

Communication

Staffing

Performance Management

Training

Compensation
•
Level 3 Key Practices

Knowledge and Skills Analysis

Work Force Planning

Competence Development

Career Development

Competence-Based Practices

Participatory Culture
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
122
People Capability Maturity Model
•
Level 4 Key Practices

Mentoring

Team Building

Team-Based Practices

Organizational Competence Management

Organizational Performance Alignment
•
Level 5 Key Practices

Personal Competence Development

Coaching

Continuous Work Force Innovation
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
123
The Human Factor
• Software engineering projects fail because
of bad management rather than bad
technology.
• "IT depends on people. It is a very skill and - people intensive game, and if you lose
your critical people there is no way you can
make it" T Barber, ICI Paints.
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
124
The Human Factor
•
•
•
•
•
•
•
•
•
•
Project managers do not understand users needs
Project scope is ill-defined
Project changes are managed poorly
Chosen technology changes
Business needs change
Deadlines are unrealistic
Users are resistant
Sponsorship is lost
Project lacks people with appropriate skills
Managers ignore best practice and lessons learnt
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
125
Conclusions
• Software engineering project management
IS software engineering risk management.
• Measurement is essential.
• Put people first.
• Consider reuse as a standard part of
software engineering
INFO3013 Systems Development
Management
© Copyright De Montfort
University 2001 All Rights Reserved
126