2. Deliverables by Phase
Possible Deliverables by Phase
Concept Document
Statement of Work (SOW)
Project Charter
RFP & Proposal
Software
Requirements Document (Software Requirements Specification)
Concept
Work Breakdown Structure (WBS)
Requirements Functional Specification ( Top Level Design Specification)
Entity Relationship Diagram
Data Flow Diagram
Analysis Detailed Design Specification
Object Diagrams
Detailed Data Model
Project Development Plan
(Software Development Plan ) Design Coding Standards
Baseline Project Plan Working Code
Quality Assurance Plan Unit Tests
Configuration Management Plan
Coding and
Risk Management Plan
Debugging Acceptance Test Procedures
Tested Application
Integration Plan Systems
Detailed SQA Test Plan Testing Maintenance Specification
SQA Test Cases Deployed Application
Deployment &
User Documentation Maintenance
Training Plan
2
3. Risk management
Risk management is concerned with identifying
risks and drawing up plans to minimise their
effect on a project.
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
4. Software risks
Risk Risk type Description
Staff turnover Project Experienced staff will leave the
project before it is finished.
Management change Project There will be a change of
organisational management with
different priorities.
Hardware unavailability Project Hardware which is essential for the
project will not be delivered on
schedule.
Requirements change Project and There will be a larger number of
product changes to the requirements than
anticipated.
Specification delays Project and Specifications of essential interfaces
product are not available on schedule
Size underestimate Project and The size of the system has been
product underestimated.
CASE tool under- Product CASE tools which support the
performance project do not perform as anticipated
Technology change Business The underlying technology on which
the system is built is superseded by
new technology.
Product competition Business A competitive product is marketed
before the system is completed.
5. The Risk Management Process
• Risk identification
– Identify project, product and business risks
• Risk analysis
– Assess the likelihood and consequences of these
risks
• Risk planning
– Draw up plans to avoid or minimise the effects of
the risk
• Risk monitoring
– Monitor the risks throughout the project
6. The risk management process
Risk Risk analysis Risk planning Risk
identification monitoring
List of potential Risk avoidance Risk
Prioritised risk and contingency
risks list assessment
plans
8. Risks and risk types
Risk type Possible risks
Technology The database used in the system cannot process as many
transactions per second as expected.
Software components which should be reused contain defects
which limit their functionality.
People It is impossible to recruit staff with the skills required.
Key staff are ill and unavailable at critical times.
Required training for staff is not available.
Organisational The organisation is restructured so that different management
are responsible for the project.
Organisational financial problems force reductions in the project
budget.
Tools The code generated by CASE tools is inefficient.
CASE tools cannot be integrated.
Requirements Changes to requirements which require major design rework are
proposed.
Customers fail to understand the impact of requirements
changes.
Estimation The time required to develop the software is underestimated.
The rate of defect repair is underestimated.
The size of the software is underestimated.
9. 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
– insignificant
10. Risk analysis
Risk Probability Effects
Organisational financial problems force reductions Low Catastrophic
in the project budget.
It is impossible to recruit staff with the skills High Catastrophic
required for the project.
Key staff are ill at critical times in the project. Moderate Serious
Software components which should be reused Moderate Serious
contain defects which limit their functionality.
Changes to requirements which require major Moderate Serious
design rework are proposed.
The organisation is restructured so that different High Serious
management are responsible for the project.
The database used in the system cannot process as Moderate Serious
many transactions per second as expected.
The time required to develop the software is High Serious
underestimated.
CASE tools cannot be integrated. High Tolerable
Customers fail to understand the impact of Moderate Tolerable
requirements changes.
Required training for staff is not available. Moderate Tolerable
The rate of defect repair is underestimated. Moderate Tolerable
The size of the software is underestimated. High Tolerable
The code generated by CASE tools is inefficient. Moderate Insignificant
11. Risk planning
Consider each risk and develop a strategy to
manage that risk
Avoidance strategies
The probability that the risk will arise is reduced
Minimisation strategies
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
12. Risk management strategies
Risk Strategy
Organisational Prepare a briefing document for senior management showing
financial problems how the project is making a very important contribution to the
goals of the business.
Recruitment Alert customer of potential difficulties and the possibility of
problems delays, investigate buying-in components.
Staff illness Reorganise team so that there is more overlap of work and
people therefore understand each other’s jobs.
Defective Replace potentially defective components with bought-in
components components of known reliability.
Requirements Derive traceability information to assess requirements change
changes impact, maximise information hiding in the design.
Organisational Prepare a briefing document for senior management showing
restructuring how the project is making a very important contribution to the
goals of the business.
Database Investigate the possibilit y of buying a higher-performance
performance database.
Underestimated Investigate buying in components, investigate use of a program
development time generator.
13. 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
14. Risk factors
Risk type Potential indicators
Technology Late delivery of hardware or support software, many
reported technology problems
People Poor staff morale, poor relationships amongst team
member, job availability
Organisational organisational 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
16. Software Measurement
Objectives
– Assessing status
• Projects
• Products for a specific project or projects
• Processes
• Resources
– Identifying trends
• Need to be able to differentiate between a healthy project and one
that’s in trouble
– Determine corrective action
• Measurements should indicate the appropriate corrective action, if
any is required.
16
17. Software Measurement Objectives
• Types of information required to understand,
control, and improve projects:
– Managers
• What does the process cost?
• How productive is the staff?
• How good is the code?
• Will the customer/user be satisfied?
• How can we improve?
– Engineers
• Are the requirements testable?
• Have all the faults been found?
• Have the product or process goals been met?
• What will happen in the future?
17
18. The Scope of Software Metrics
– Cost and effort estimation
– Productivity measures and models
– Data collection
– Quality models and measures
– Reliability models
– Performance evaluation and models
– Structural and complexity metrics
– Capability-maturity assessment
– Management by metrics
– Evaluation of methods and tools
18
19. The Scope of Software Metrics
• The Scope of Software Metrics – some
details
– Possible productivity model
Productivity
Cost
Value
Personnel Resources Complexity
Quality Quantity
Time HW Env Problem
Reliability Defects Size Functionality Cnstrst difficulty
Money SW
19
20. The Scope of Software Metrics
• The Scope of Software Metrics – some
details
– Software quality model
Use Factor Criteria
Communicativeness
Usability
Accuracy
Product Reliability
Operatio Consistency
n
Efficiency Device Efficiency
Accessibility
Reusability Metrics
Completeness
Product Maintainability Structuredness
Revisio Conciseness
n Portability
Device Independence
Testability Legibility
Self-descriptiveness
20
Traceability
22. Measurement Basics
• Direct and Indirect Measurement
– Direct measure – relates an attribute to a number or
symbol without reference to no other object or attribute
(e.g., height).
– Indirect measure
• Used when an attribute must be measured by combining
several of its aspects (e.g., density)
• Requires a model of how measures are related to each
other
22
23. Measurement Basics
• Direct and Indirect Measures for Software – examples
– Direct
• Length or source code (lines of code)
• Duration of testing process
• Number of defects discovered during test
• Time a developer spends on a project
– Indirect
• Programmer productivity (LOC/workmonths of effort)
• Module defect density (number of defects/module size)
• Defect detection efficiency (# defects detected/total defects)
• Requirements stability (initial # requirements/total # requirements)
• Test effectiveness ratio (number of items covered/total number of items)
• System spoilage (effort spent fixing faults/total project effort)
23
25. Software product quality metrics
• The quality of a product:
- the “totality of characteristics that bear on its
ability to satisfy stated or implied needs”.
Metrics of the external quality attributes
producer’s perspective: “conformance to
requirements”
customer’s perspective: “fitness for use”
- customer’s expectations
26. Quality metrics
• Two levels of software product quality
metrics:
Intrinsic product quality
Customer oriented metrics
27. Intrinsic product quality metrics:
Reliability: number of hours the software can run
before a failure
Defect density (rate):
number of defects contained in software, relative
to its size.
Customer oriented metrics:
Customer problems
Customer satisfaction
28. Intrinsic product quality metrics
Reliability --- Defect density
• Correlated but different!
• Both are predicted values.
• Estimated using static and dynamic models
Defect: an anomaly in the product (“bug”)
Software failure: an execution whose effect is not conform to
software specification
30. MTBF (Mean Time Between Failures):
the expected time between two successive failures of a system
expressed in hours
a key reliability metric for systems that can be repaired or restored
(repairable systems)
applicable when several system failures are expected.
For a hardware product, MTBF decreases with the its age.
31. MTTF (Man Time To Failure):
the expected time to failure of a system
in reliability engineering metric for non-repairable systems
non-repairable systems can fail only once; example, a satellite is not repairable.
Mean Time To Repair (MTTR): average time to restore a system after a failure
When there are no delays in repair: MTBF = MTTF + MTTR
Software products are repairable systems!
Reliability models neglect the time needed to restore the system after a failure.
with MTTR =0 MTBF = MTTF
Availability = MTTF / MTBF = MTTF / (MTTF + MTTR)
32. 3.1.2. Defect rate (density)
Number of defects per KLOC or per Number of Function Point,
in a given time unit
Example:
“The latent defect rate for this product, during next four years, is 2.0
defects per KLOC”.
Crude metric: a defect may involve one or more lines of code
Lines Of Code
-Different counting tools
-Defect rate metric has to be completed with the counting method for LOC!
-Not recommended to compare defect rates of two products written in
different languages
33. Reliability or Defect Rate ?
Reliability:
often used with safety-critical systems such as: airline traffic control systems,
avionics, weapons.
(usage profile and scenarios are better defined)
Defect density:
in many commercial systems (systems for commercial use)
• there is no typical user profile
• development organizations use defect rate for maintenance cost and
resource estimates
• MTTF is more difficult to implement and may not be representative of all
customers.
34. Customer Oriented Metrics
Customer Problems Metric
Customer problems when using the product:
valid defects, usability problems, unclear documentation, user errors.
Problems per user month (PUM) metric:
PUM = TNP/ TNM
TNP: Total number of problems reported by customers for a time period
TNM: Total number of license-months of the software during the period
= number of install licenses of the software x number of months in the period
35. 3.2.2. Customer satisfaction metrics
Often measured on the five-point scale:
1. Very satisfied
2. Satisfied
3. Neutral
4. Dissatisfied
5. Very dissatisfied
IBM: CUPRIMDSO
(capability/functionality, usability, performance, reliability,
installability, maintainability, documentation /information,
service and overall)
Hewlett-Packard: FURPS
(functionality, usability, reliability, performance and service)
36. Overview of Project Management
Project Concept & Definition Benefit Delivery
Management Project P
Es g Phase or Stage
Planning t im
ati
End
n
Re g
R
so
ur
cin
Pla Mobilis- Management, Control
nin n
ation & Reporting QA
g
Benefit Tracking & Management
Quality Management
Risk Management
Issue Management
Scope & Change Control
Configuration Management
Documentation Control
Team building, Collaboration and Internal Communication
Organisational Change Management
External Communication
Procurement & Accounting
Subcontractor Management
39. Reasons for Project Failure
1. Poor project and program management discipline
2. Lack of executive-level support
3. No linkage to the business strategy
4. Wrong team members
5. No measures for evaluating the success of the project
6. No risk management
7. Inability to manage change
42. Seven Traits of Good Project
Managers
Trait 1
Enthusiasm for the project
Trait 2
Ability to manage change effectively
Trait 3
A tolerant attitude toward ambiguity
Trait 4
Team – building and negotiating skills
43. Seven Traits of Good Project
Managers
Trait 5
A customer-first orientation
Trait 6
Adherence to the priorities of business
Trait 7
Knowledge of the industry or technology
44. Project Management
• Project Management
– The “application of knowledge, skills, tools and
techniques to project activities to meet project
requirements.”
• 9 Knowledge areas
57. Work Breakdown Structure (WBS)
• Breaks large project into manageable units
– Total project
– Subprojects
– Milestones (completion of an important set of work
packages)
– Major activities (summary tasks)
– Work packages (tasks, activities, work elements)
59. WBS
• Helps to:
– Identify all work needing to be done
– Logically organize work so that is can be scheduled
– Assign work to team members
– Identify resources needed
– Communicate what has to be done
– Organize work using milestones
64. Complexity of Scheduling Project
Activities
• Large number of activities
• Precedence relationships
• Limited time of the project
64
65. Importance of Project Schedules
Managers often cite delivering projects on time
as one of their biggest challenges
Average time overrun from 1995 CHAOS
report was 222%
Time has the least amount of flexibility; it
passes no matter what
Schedule issues are the main reason for
conflicts on projects, especially during the
second half of projects
66. Conflict Intensity over the Life of A Project
0.40
0.35
0.30
Conflict Intensity
Schedules
0.25 Average
Total Conflict
Priorities
Manpower
0.20 Technical opinions
Procedures
0.15 Cost
Personality conflicts
0.10
0.05
0.00
Project Early Phases Middle Phases End Phases
Formation
67. Project Time Management Processes
Project time management involves the
processes required to ensure timely
completion of a project, including:
Activity definition
Activity sequencing
Activity duration estimating
Schedule development
Schedule control
68. Where Do Schedules Come From?
Defining Activities:
Project schedules grow out of the basic
documents that initiate a project
Project charter includes start and end dates and
budget information
Activity definition involves developing a more
detailed PLANS and supporting explanations
to understand all the work to be done
69. Activity Sequencing
Involves reviewing activities and determining
dependencies
Mandatory dependencies: inherent in the nature of
the work; hard logic
Optional dependencies: defined by the project
team; soft logic
We must determine dependencies in order to
use critical path analysis
70. Project Network Diagrams
Project network diagrams are the preferred
technique for showing activity sequencing
A project network diagram is a schematic
display of the logical relationships among,
or sequencing of, project activities
72. Arrow Diagramming Method (ADM)
Also, called activity-on-arrow (AOA) project
network diagrams
Activities are represented by arrows
Nodes or circles are the starting and ending
points of activities
Can only show finish-to-start dependencies
73. Process for Creating AOA Diagrams
1. Find all of the activities that start at node 1. Draw their finish
nodes and draw arrows between node 1 and those finish
nodes. Put the activity letter or name and duration estimate on
the associated arrow
2. Continue drawing the network diagram, working from left to
right. Look for bursts and merges. Bursts occur when a single
node is followed by two or more activities. A merge occurs
when two or more nodes precede a single node
3. Continue drawing the project network diagram until all activities
are included on the diagram that have dependencies
4. As a rule of thumb, all arrowheads should face toward the right,
and no arrows should cross on an AOA network diagram
74. Project Planning When Activity
Times are Known
• Inputs
– list of the activities that must be completed
– activity completion times
– activity precedence relationships
74
75. Project Planning When Activity
Times are Known continued
• Outputs
– graphical representation of project
– time to complete project
– identification of critical path(s) and activities
– activity and path slack
– earliest and latest time each activity can be started
– earliest and latest time each activity can be completed
75
80. Activity Slack Time
TES = earliest start time for activity
TLS = latest start time for activity
TEF = earliest finish time for activity
TLF = latest finish time for activity
Activity Slack = TLS - TES = TLF - TEF
80
81. Precedence Diagramming Method (PDM)
Activities are represented by boxes
Arrows show relationships between
activities
More popular than ADM method and used
by project management software
Better at showing different types of
dependencies
83. Activity Duration Estimating
After defining activities and determining their
sequence, the next step in time management
is duration estimating
Duration includes the actual amount of time
worked on an activity plus elapsed time
People doing the work should help create
estimates, and an expert should review them
84. Schedule Development
Schedule development uses results of the
other time management processes to
determine the start and end date of the project
and its activities
Ultimate goal is to create a realistic project
schedule that provides a basis for monitoring
project progress for the time dimension of the
project
Important tools and techniques include Gantt
charts, PERT analysis, and critical path
analysis
86. Critical Path Method (CPM)
CPM is a project network analysis technique
used to predict total project duration
A critical path for a project is the series of
activities that determines the earliest time by
which the project can be completed
The critical path is the longest path through
the network diagram
87. Finding the Critical Path
First develop a good project network
diagram
Add the durations for all activities on each
path through the project network diagram
The longest path is the critical path
89. More on the Critical Path
If one of more activities on the critical path
takes longer than planned, the whole project
schedule will slip unless corrective action is
taken
Misconceptions:
The critical path is not the one with all the critical
activities; it only accounts for time
There can be more than one critical path if the
lengths of two or more paths are the same
The critical path can change as the project
progresses
90. Using Critical Path for Schedule Trade-offs
Knowing the critical path helps you make
schedule trade-offs
Free slack or free float is the amount of time
an activity can be delayed without delaying the
early start of any immediately following
activities
Total slack or total float is the amount of time
an activity may be delayed from its early start
without delaying the planned project finish
date
91. Techniques for Shortening a Project Schedule
Shortening durations of critical tasks by
adding more resources or changing their
scope
Crashing tasks by obtaining the greatest
amount of schedule compression for the
least incremental cost
Fast tracking tasks by doing them in parallel
or overlapping them
93. What are Gantt and PERT?
Gantt and PERT charts are both “CPM”
(Critical Path Method) tools to:
• manage the tasks involved in big and
complex projects
• let project managers organise time,
people, equipment and money
• ensure the right people and equipment are
in the right place and the right time
• allow managers to monitor the progress of
a project 93
94. Gantt Basics
• Basically, a timeline with tasks that can be
connected to each other
• Note the spelling!
• It is not all-capitals!
• Can be created with simple tools like Excel, but
specialised tools like Microsoft Project make life
easier
94
95. Making a Gantt chart
• Step 1 – list the tasks in the project
95
97. Making a Gantt chart
• Step 3 – add dependencies (which tasks
cannot start before another task finishes)
97
98. Notes
•The arrows indicate dependencies.
•Task 1 is a predecessor of task 2 – i.e. task 2 cannot start before task 1 ends.
•Task 3 is dependent on task 2. Task 7 is dependent on two other tasks
•Electrics, plumbing and landscaping are concurrent tasks and can happen at
the same time, so they overlap on the chart. All 3 can start after task 4 ends.
•Task 9 has zero duration, and is a milestone
98
99. Making a Gantt chart
• Step 4 – find the critical path
The critical path is the sequence of tasks from beginning to end that takes
the longest time to complete.
Any task on the critical path is called a critical task.
No critical task can have its duration changed without affecting the end
date of the project.
99
100. PERT basics
• PERT is an acronym so it’s in capital letters
• Gantt is a name, so only has an initial capital
• In Gantt chart, the length of a task’s bar is
proportional to the length of the task. This rarely
applies to PERT charts.
• There are a few different “flavours” of PERT and
Gantt charts…
100
101. PERT charts
This PERT chart follows the “Activity on Arrow” style.
•The tasks are shown by arrows. Task name are shown by letters,
in this case.
•The circles are called nodes. The nodes indicate the start or end of
tasks.
•Task durations are the shown by the numbers.
101
102. ‘Activity on Node’ style PERT
Activity on Node is a different flavour of PERT: this time
the nodes are tasks, and the arrows are merely
connectors.
The examiners prefer very simple PERT charts –
102
sometimes hybrid beasts that defy categorisation.
104. • 1: Which tasks are on the critical path?
• 2: What is the slack time for tasks C, D and G?
• 3: Task C is delayed by one day. What impact would
this have on the completion date of the project? Why?
• 4: Task A will be delayed by 2 days because some
equipment has arrived late. If the project manager
wants to finish the project on time he will need to
shorten the duration of one or more of the tasks. How
can he achieve this?
• 5: The project manager reduces the durations of tasks
D and F by one day each. How will this affect the
finishing date of the project?
104
105. 1: Which tasks are on the critical path?
Possible paths:
A,B,C,E,I = 2+3+1+4+3 = 13 days
A,B,D,F,I = 2+3+3+3+3 = 14 days
A,G,H,I = 2+2+5+3 = 12 days
ANSWER: A,B,D,F,I
105
106. 2: What is the slack time for tasks C, D and G?
TASKS C and D…
Path C,E = 5 days, Path D,F = 6 days
Difference (slack) = 1 day for tasks C or E
compared to D,F
TASK G…
Path B,C,E = 8 days. Path B, D, F = 9 days
Path G, H = 7 days.
So G & H have 2 days’ slack between them.
B,C or E have 1 day’s slack. 106
B,D,F have no slack.
107. 3: Task C starts one day late. What impact would
this have on the completion date of the
project? Why?
No impact, because task C has
one day’s slack (as discovered
in previous question!)
107
108. 4: Task A will be delayed by 2 days because some
equipment has arrived late. If the project manager still
wants to finish the project within the original time frame,
he will need to shorten the time for one or more of the
tasks. What steps can he take to reduce the number of
days allocated to a task?
The answer has NOTHING to do with the
chart! Just say how jobs can be finished
more quickly, e.g. bringing in extra
workers from slack tasks, working longer
hours, working weekend, streamlining
work practices, automating tasks etc.
108
109. • 5: The project manager decides to reduce the time needed for tasks
D and F by one day each. How effective will this reduction be in
achieving his aim of maintaining the original finish time for the
project?
It is only partially effective. Reducing tasks D and F by
one day each means the path A,B,D,F,I is now 12 days
long. However, path A,B,C,E,I is still 13 days so it
becomes the longest path, and therefore becomes the
new critical path.
The project is now 13 days long instead of 14, a saving
of only one day.
109
110.
111. Project Management Software
• There are a number of project management software tools
available to help in the planning and control of large
software development projects.
– E.g. MS Project is a CASE software tool for Project
Management
• Most tools include functions to plan, schedule and control,
but decision-making still has to be done by the project
manager.
112. Project Management Software
• Benefits of project management software:
– Calculate project schedule
– Resource smoothing
– Automatic generation of reports and charts
• Limitations of project management software
– Allocation of resources to tasks
– Estimation of tasks durations
– Make decisions