Software Project Management
Learning Objectives
By the end of the lecture you should be able to:
•Comprehend various aspects of Project Management
•Describe how organizations should decide on the SW development processes
at the outset
•Explain a SW project can be tracked during its lifecycle
•Explain what are Quality, Quality Control and Quality Assurance and how Orgs
are managing
•Explain why configuration management is essential and how the same can be
managed
•Describe nuances of risk management related to a project
•Describe how a metrication plan can help keeping a measure on project health
Software Project Planning
The overall goal of project planning is to establish a pragmatic strategy for controlling,
tracking, and monitoring a complex technical project.
Why?
So the end result gets done on time, with quality!
The 4 P’s
• People — the most important element of a successful project
• Product — the software to be built
• Process — the set of framework activities and software engineering tasks to get the job
done
• Project — all work required to make the product a reality
People
• Recruiting
• Selection
• Performance management
• Training
• Compensation
• Career development
• Organization and work design
• Team culture development
• Organizations that achieve high level of maturity in the People Management have a higher
likelihood of implementing effective Softtware Engineering practices
2
People
• Cohesiveness
– Common goal, common culture – ‘sense of eliteness’ – well jelled
– Toxic environment
• Frenzied atmosphere – plan
• High frustration, friction – empower
• Poor coordination of processes – define
• Unclear definition of roles – accountability
• Continuous and repeated exposure to failures – corrective approach
The following factors must be considered when selecting a
software project team structure ...
• 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 delivery date
• the degree of sociability (communication) required for the project
3
Product
• Product objectives and scope to be established
• Alternative solutions to be considered
• Technical constraints
• To arrive at
– Reasonably accurate estimate
– Effective risk assessment
– Realistic task breakdown
– Manageable schedule
• Software Scope
– Context – part of larger system, product, business
– Information objective – input / output
– Function –
– Performance – any special requirement
• Unambiguous, bounded, constraints specified
4
Process
• Provides a framework for comprehensive plan
• Common Process Framework activities are applicable to all projects
• Different task set for projects - Tasks, milestones, work products, quality assurance points
• Umbrella activities – sqa, scm, measurement –overlay the process
• Bringing Product and Process Together
• Fitting the product items under the process phases ( framework activities )
Project
• Guidelines for success
– Spend time on analysing problem
– Make realistic objectives for everybody – start on a achievable target
– Maintain pace
– Track progress
– Appropriate decisions – make-or-buy, keep it simple
– Post mortem analysis
5
Boehm’s 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 (e.g., people, software, tools, database) will be needed?
Project
Factors that influence the end result ...
•size
• delivery deadline
• budgets and costs
• application domain
• technology to be implemented
• system constraints
• user requirements
• available resources 6
Project Management Concerns
product quality?
risk assessment?
measurement?
cost estimation?
project scheduling?
customer communication?
staffing?
other resources?
project monitoring?
Why Projects Fail?
• an unrealistic deadline is established
• changing customer requirements
• an honest underestimate of effort
• predictable and/or unpredictable risks
• technical difficulties
• miscommunication among project staff
• failure in project management
7
Software Project Management
• Software Project Plan (SPP)
– Project Defined Process (PDP)
– Software Project Tracking Plan (SPTP)
– Software Configuration Management Plan (SCMP)
– Software Quality Assurance Plan (SQAP)
– Risk Management Plan (RMP)
– Metrication Plan (MP)
Project Defined Process
• Define the processes that will be adopted for SW development including
– SDLC Lifecycle
– Tailoring
– Client mandate (to use their QMS / tools)
– Onsite / offshore requirement
8
Software Project Tracking
Why Are Projects Late?
• an unrealistic deadline established by someone outside the software development
group
• changing customer requirements that are not reflected in schedule changes;
• an honest underestimate of the amount of effort and/or the number of resources
that will be required to do the job;
• predictable and/or unpredictable risks that were not considered when the project
commenced;
• technical difficulties that could not have been foreseen in advance;
• human difficulties that could not have been foreseen in advance;
• miscommunication among project staff that results in delays;
• a failure by project management to recognize that the project is falling behind
schedule and a lack of action to correct the problem
Scheduling Principles
• compartmentalization—define distinct tasks
• interdependency—indicate task interrelationships
• effort validation—be sure resources are available
• defined responsibilities—people must be assigned
• defined outcomes—each task must have an output
• defined milestones—review for quality
Define a Task Network
I.5a
I.3a
Concept
Tech. Risk
Implement.
Assessment
I.1 I.2 I.3b I.4 I.5b I.6
Concept Integrate Customer
Concept Concept Tech. Risk Proof of
Implement. a, b, c Reaction
scoping planning Assessment Concept
I.3c I.5c
Tech. Risk Concept
Assessment Implement.
Three I.3 tasks are Three I.3 tasks are
applied in parallel to applied in parallel to
3 different concept 3 different concept
functions functions
10
Effort Allocation
• “front end” activities
40--50%
40 – customer communication
– analysis
– design
– review and modification
• construction activities
15--20%
15 – coding or code generation
• testing and installation
– unit, integration
– white-box, black box
30--40%
30 – regression
11
Use Automated Tools to
Derive a Timeline Chart
Work tasks week 1 week 2 week 3 week 4 week 5
I.1.1 Identify need and benefits
Meet with customers
Identify needs and project constraints
Establish product statement
Milestone: product statement defined
I.1.2 Define desired output/control/input (OCI)
Scope keyboard functions
Scope voice input functions
Scope modes of interaction
Scope document diagnostics
Scope other WP functions
Document OCI
FTR: Review OCI with customer
Revise OCI as required;
Milestone; OCI defined
I.1.3 Define the functionality/behavior
Define keyboard functions
Define voice input functions
Decribe modes of interaction
Decribe spell/grammar check
Decribe other WP functions
FTR: Review OCI definition with customer
Revise as required
Milestone: OCI defintition complete
I.1.4 Isolate software elements
Milestone: Software elements defined
I.1.5 Research availability of existing software
Reseach text editiong components
Research voice input components
Research file management components
Research Spell/Grammar check components
Milestone: Reusable components identified
I.1.6 Define technical feasibility
Evaluate voice input
Evaluate grammar checking
Milestone: Technical feasibility assessed
I.1.7 Make quick estimate of size
I.1.8 Create a Scope Definition
Review scope document with customer
Revise document as required
Milestone: Scope document complete
12
Software Quality Assurance
Definition of Quality
• Meeting requirements - Producer’s view
• Fitness for purpose - Customer’s view
• Fitness for use (Juran)
• Compliance with specified requirements (Crosby)
• Freedom from defects, imperfections or contamination
• Customer satisfaction
• Delighting Customers
The totality of characteristics of an entity that bear on its ability to satisfy
stated and implied needs. - ISO 8402(Vocabulary)
Need for Quality
• Provides the means for staff to perform their tasks right the first time
• Helps to maintain consistency in the quality of the products or services.
• Brings clarity and transparency to duties and responsibilities
• Improve traceability
Prevent defects and thereby reduce rework
Disadvantages of not following Quality
• Land up with a dissatisfied customer
• Totally mess up the job
• Multiple rounds of rework needed
• Maintenance of the system becomes difficult
• Earn a bad reputation in the market
• People are busy fire fighting rather than upgrading their skills
Some Quality Terminologies
Quality Assurance
All those planned and systematic activities implemented within a quality system
and demonstrated as needed to provide adequate confidence that an entity will
fulfill requirements for quality.
Quality Control
The operational techniques and activities that are used to fulfill requirements for
quality
14
Why SQA Activities Pay Off?
cost to find
and fix a defect
100 60.00-100.00
log
scale
10 10.00
3.00
1.50
1.00
1 0.75
Design test field
Req. system use
code test
15
Difference between QA and QC
Quality Assurance Quality Control
• Process Product
Reactive
• Proactive
Line function
• Staff function
Find defects
• Prevent defects
Examples of QA and QC
Quality Assurance Quality Control
• Quality Audit Walkthrough
• Defining Process Testing
• Selection of tools Inspection
• Training Checkpoint review
In Summary
• general objective: reduce the “variation between samples” ... but how does this
apply to software?
• quality control: a series of inspections, reviews, tests
• quality assurance: analysis, auditing and reporting activities
• cost of quality
– appraisal costs
– failure costs
– external failure costs
16
Software Quality Assurance
SQA Process Formal
Definition & Technical
Standards Reviews
Analysis
& Test
Reporting Planning
& Review
Measurement
17
What Are Reviews?
• a meeting conducted by technical people
for technical people
• a technical assessment of a work product
created during the software engineering
process
• a software quality assurance mechanism
• a training ground
18
The Players
review
leader standards bearer (SQA)
producer
maintenance
oracle
recorder reviewer
user rep
19
Conducting the Review
1. be prepared—evaluate
product before the review
2. review the product, not
the producer
3. keep your tone mild, ask
questions instead of
making accusations
4. stick to the review agenda
5. raise issues, don't resolve them
6. avoid discussions of style—stick to technical
correctness
7. schedule reviews as project tasks
8. record and report all review results
20
Metrics Derived from Reviews
inspection time per page of documentation
inspection time per KLOC or FP
inspection effort per KLOC or FP
errors uncovered per reviewer hour
errors uncovered per preparation hour
errors uncovered per SE task (e.g., design)
number of minor errors (e.g., typos)
number of major errors
(e.g., nonconformance to req.)
number of errors found during preparation
21
Statistical SQA
• collect information on all
defects
Product • find the causes of the
& Process defects
• move to provide fixes for
the process
measurement
... an understanding of how
to improve quality ...
22
Implementation of SQA
PDCA Cycle:
ACT PLAN
CHECK DO
ETVX Paradigm:
•E - Entry criteria
•T - Tasks
•V - Validation criteria
•X - Exit criteria
23
Implementation tools - Policy, Procedures, Standards, Guidelines
• Policy - basic goal of the organization to be achieved through the quality system
• Procedures - well defined steps to be followed throughout the organization for carrying
out different activities
• Standards - fixed formats, templates, coding standards to be followed for specific activities
• Guidelines - generic directions for some activities
Implementation Roles
• Software Engineering Process Group • Software Quality Assurance Group (SQAG)
(SEPG)
• Project Quality Advisor (PQA)
• Software Change Control Board (SCCB)
• External Quality Advisor (EQA)
Software Configuration Management
The “First Law”
No matter where you are in the system life cycle, the system will
change, and the desire to change it will persist throughout the life
cycle.
Bersoff, et al, 1980
24
What Are These Changes?
changes in
business requirements
changes in
technical requirements
changes in
other
user requirements documents
software models
Project
Plan
data
Test
code
25
The Software Configuration
programs documents
The pieces data
26
Effort Allocation
• Configuration item - A configuration item is a part of a system
which is treated as a unit for the purpose of coordinating the
development and control of the system delivery process. The range
of configuration items that must be managed is wide, spanning the
entire life cycle.
• Management
– Version - instance of an item that has reached a stable state
with a defined set of functional capabilities and is worth
preserving
– Revision - A modified form of a controlled item which has been
created to correct, perfect, or adapt the item to a changing
environment
– Variant - A variant represents an item’s need to meet conflicting
requirements at the same time e.g. multiple OS
27
Change & SCM
Software Engineering
SCM
tools • identification
methods • version control
• change control
procedures
• auditing
a TQM foundation • reporting
• construction
28
Change Control Process—I
need for change is recognized
change request from user
developer evaluates
change report is generated
change control authority decides
request is queued for action
change request is denied
user is informed
change control process—II
29
Change Control Process-II
assign people to SCIs
check-out SCIs
make the change
review/audit the change
establish a “baseline” for testing
change control process—
process—III
30
Change Control Process-III
perform SQA and testing activities
check-in the changed SCIs
promote SCI for inclusion in next release
rebuild appropriate version
review/audit the change
include all changes in release
31
Auditing
Change
Requests SQA
Plan
SCIs
SCM Audit
32
Risk Management
Project Risks
What can go wrong?
What is the likelihood?
What will the damage be?
What can we do about it?
33
Reactive Risk Management
– project team reacts to risks when they occur
– mitigation—plan for additional resources in anticipation of fire fighting
– fix on failure—resource are found and applied when the risk strikes
– crisis management—failure does not respond to applied resources and project is
in jeopardy
Proactive Risk Management
• formal risk analysis is performed
• organization corrects the root causes of risk
– TQM concepts and statistical SQA
– examining risk sources that lie beyond the bounds of the software
– developing the skill to manage change
34
Risk Management Paradigm
control
track
identify
plan
analyze
35
Building a Risk Table
Risk Probability Impact RMMM
Risk
Mitigation
Monitoring
&
Management
36
Building the Risk Table
• Estimate the probability of occurrence
• Estimate the impact on the project on a scale of 1 to 5, where
– 1 = low impact on project success
– 5 = catastrophic impact on project success
• sort the table by probability and impact
Risk Mitigation, Monitoring and Management
• mitigation—how can we avoid the risk?
• monitoring—what factors can we track that will enable us to determine if the risk is becoming more
or less likely?
• management—what contingency plans do we have if the risk becomes a reality?
Risk Due to Product Size
Attributes that affect risk:
• estimated size of the product in LOC or FP?
• estimated size of product in number of programs,files and transactions?
• percentage deviation in size of product from average from previous products?
• size of database created or used by the product?
• number of users of the product?
• number of projected changes to the requirements for the product? before
delivery? after delivery?
• amount of reused software? 37
Risk Due to Business Impact
Attributes that affect risk:
• effect of this product on company revenue?
• visibility of this product by senior management?
• reasonableness of delivery deadline?
• number of customers who will use this product
• interoperability constraints
• sophistication of end users?
• amount and quality of product documentation that
must be produced and delivered to the customer?
• governmental constraints
• costs associated with late delivery?
• costs associated with a defective product?
38
Risks Due to the Customer
Questions that must be answered:
• Have you worked with the customer in the past?
• Does the customer have a solid idea of requirements?
• Has the customer agreed to spend time with you?
• Is the customer willing to participate in reviews?
• Is the customer technically sophisticated?
• Is the customer willing to let your people do their
job—that is, will the customer resist looking over your
shoulder during technically detailed work?
• Does the customer understand the software
engineering process?
39
Risks Due to Process Maturity
Questions that must be answered:
• Have you established a common process framework?
• Is it followed by project teams?
• Do you have management support for
software engineering
• Do you have a proactive approach to SQA?
• Do you conduct formal technical reviews?
• Are CASE tools used for analysis, design and
testing?
• Are the tools integrated with one another?
• Have document formats been established?
40
Technology Risks
Questions that must be answered:
• Is the technology new to your organization?
• Are new algorithms, I/O technology required?
• Is new or unproven hardware involved?
• Does the application interface with new software?
• Is a specialized user interface required?
• Is the application radically different?
• Are you using new software engineering methods?
• Are you using unconventional software development
methods, such as formal methods, AI-based approaches,
artificial neural networks?
• Are there significant performance constraints?
• Is there doubt the functionality requested is "do-able?"
41
Staff/People Risks
Questions that must be answered:
• Are the best people available?
• Does staff have the right skills?
• Are enough people available?
• Are staff committed for entire duration?
• Will some people work part time?
• Do staff have the right expectations?
• Have staff received necessary training?
• Will turnover among staff be low?
42
Recording Risk Information
Project: Embedded software for XYZ system
Risk type: schedule risk
Priority (1 low ... 5 critical): 4
Risk factor: Project completion will depend on tests which require
hardware component under development. Hardware component
delivery may be delayed
Probability: 60 %
Impact: Project completion will be delayed for each day that
hardware is unavailable for use in software testing
Monitoring approach:
Scheduled milestone reviews with hardware group
Contingency plan:
Modification of testing strategy to accommodate delay using
software simulation
Estimated resources: 6 additional person months beginning 7-7-1-96
43
Metrication
Measurement & Metrics
... collecting metrics is too hard ...
it's too time-consuming ... it's too
political ... it won't prove anything ...
Anything that you need to
quantify can be measured in
some way that is superior to
not measuring it at all ..
Tom Gilb
44
Why do we Measure?
• To characterize
• To evaluate
• To predict
• To improve
45
A Good Manager Measures
process
process metrics
project metrics
measurement
product metrics
product
What do we
use as a
basis?
• size?
• function?
46
Why do we Measure?
•To characterize
•To evaluate
•To predict
•To improve
Process Metrics
• majority focus on quality achieved as a consequence of a repeatable or
managed process
• statistical SQA data
– error categorization & analysis
• defect removal efficiency
– propagation from phase to phase
• reuse data
• Effort/time per S/W Engineering task
• Errors uncovered per review hour
• Scheduled vs. actual milestone dates
• Changes (number) and their characteristics
• Distribution of effort on SE tasks
• Profitability
47
Product Metrics
• focus on the quality of deliverables
• complexity of the design
– internal algorithmic complexity
– architectural complexity
– data flow complexity
• Defect Density (#defects/unit size)
Process and Product metrics are calculated for Projects and then they are
rolled up to get the Organizational baseline (the Organization level metrics
Metrics Guidelines
• Use common sense and organizational sensitivity when
interpreting metrics data.
• Provide regular feedback to the individuals and teams who have
worked to collect measures and metrics.
• Don’t use metrics to appraise individuals.
• Work with practitioners and teams to set clear goals and
metrics that will be used to achieve them.
• Never use metrics to threaten individuals or teams.
• Metrics data that indicate a problem area should not be
considered “negative.” These data are merely an indicator for
process improvement.
48
Normalization for Metrics
Typical Size-Oriented Metrics Typical Function-Oriented Metrics
• errors per KLOC (thousand • errors per FP (thousand lines
lines of code) of code)
• defects per KLOC • defects per FP
• $ per LOC • $ per FP
• page of documentation per • pages of documentation per FP
KLOC • FP per person-month -
• errors / person-month Productivity
• LOC per person-month
49
Measuring Quality
• Correctness — the degree to which a program operates according to specification
• Maintainability—the degree to which a program is amenable to change
• Integrity—the degree to which a program is resistant to outside attack
• Usability—the degree to which a program is easy to use
Defect Removal Efficiency
DRE = (errors) / (errors + defects)
where , errors = problems found before release
defects = problems found after release
Managing Variation
6
Er, Errors found/ rev iew hour
The mR Control 4
Chart 3
0
1 3 5 7 9 11 13 15 17 19
Project s 50
