Software Project Management

Lifecycles and Processes - Mapping

•1

Today’s Lecture
• 1. Phases in Detail
– Step-by-step of typical software project
• 2. Choosing Software Project Lifecycle

•2

•1
Time Allocation by Phase
• Remember the 40-20-40 Rule
• Specification-Implementation-Test
Planning Code & Integration &
Unit Test Test
Commercial 25% 40% 35%
DP
Internet 55% 15% 30%
Systems
Real-time 35% 25% 40%
Systems
Defense 40% 20% 40%
Systems
Bennatan, E.M, “On Time Within Budget”
3

•3

Time Allocation by Phase

Activity Small Project Large Project
(2.5K LOC) (500K LOC)
Analysis 10% 30%

Design 20% 20%

Code 25% 10%

Unit Test 20% 5%

Integration 15% 20%

System test 10% 15%

McConnell, Steve, “Rapid Development”

4

•4

•2
Activities by % of Total Effort

NASA’s “Manager’s Handbook for Software Development”

5

•5

Potential Deliverables by Phase

•6

•3
Concept Exploration
• The “Why” phase
• Not a “mandatory formal” phase
– Sometimes called the “pre-project” phase
• Collecting project ideas
– Then the “funneling” process
• Project Justification
– ROI
– Cost-benefit analysis
– Project Portfolio Matrix
• Initial planning and estimates
7

•7

Software Projects – In general

•8

•4
Concept Exploration
• Possibly includes Procurement Management:
• RFP Process
• Vendor selection
• Contract management
• Gathering the initial team
– Including PM if not already on-board
• Identify the project sponsor
– Primary contact for approval and decision making
• Potential Phase Outputs:
– Concept Document, Product Description, Proposal,
SOW, Project Charter
9

•9

Requirements
• The “What” phase
• Inputs: SOW, Proposal
• Outputs:
– Requirements Document (RD)
• a.k.a.Requirements Specification Document (RSD)
• Software Requirements Specification (SRS)
– 1st Project Baseline
– Software Project Management Plan (SPMP)
– Requirements Approval & Sign-Off
• Your most difficult task in this phase

10

•10

•5
2 Types of Requirements
– Functional (behavioral)
– Features and capabilities
– Non-functional (a.k.a. “technical”) (everything else)
– Usability
» Human factors, help, documentation
– Reliability
» Failure rates, recoverability, availability
– Performance
» Response times, throughput, resource usage
– Supportability
» Maintainability, internationalization
– Operations: systems management, installation
– Interface: integration with other systems
– Other: legal, packaging, hardware
11

•11

Analysis & Design

• The “How” Phases
• Inputs: Requirements Document
• Outputs:
– Functional Specification
– Detailed Design Document
– User Interface Specification
– Data Model
– Prototype (can also be done with requirements)
– Updated Plan (improved estimates; new baseline)

12

•12

•6
Development
• The “Do It” phase
• Coding & Unit testing
• Often overlaps Design & Integration phases
– To shorten the overall schedule
– PM needs to coordinate this

13

•13

Integration & Test

• Evolves from Dev. Phase
• Often done as 2 parallel phases
– Partial integration & initial test
• Starts with integration of modules
• An initial, incomplete version constructed
• Progressively add more components

14

•14

•7
Integration & Test
• Tests
– Integration testing
– Black & White-box testing
– Load & Stress testing
– Alpha & Beta testing
– Acceptance testing
• Other activities
– Final budgeting; risk mgmt.; training;
installation preparation; team reduced
15

•15

Deployment & Maintenance

• Installation depends on system type
– Web-based, CD-ROM, in-house, etc.
• Migration strategy
• How to get customers up on the system
– Parallel operation
• Deployment typically in your project plan,
maintenance not

16

•16

•8
Deployment & Maintenance
• Maintenance
– Fix defects
– Add new features
– Improve performance
• Configuration control is very important here
• Documents need to be maintained also
• Sometimes a single team maintains multiple
products

17

•17

Lifecycle Planning
• Lifecycle Management or SDLC
• Greatly influences your chance of success
• Three primary lifecycle model components
– Phases and their order
– Intermediate products of each phase
– Reviews used in each phase

18

•18

•9
Lifecycle Planning
• Different projects require different approaches
• You do not need to know all models by name
• You should know how that if given a certain
scenario what sort of SDLC would be appropriate
• There are more than covered here
• A lifecycle is not a design, modeling or
diagramming technique
– The same technique (UML, DFD, etc) can be used with
multiple lifecycles
19

•19

Pure Waterfall
• The “granddaddy” of models
• Linear sequence of phases
– “Pure” model: no phases overlap
• Document driven
• All planning done up-front

20

•20

•10
Code-and-Fix
• “Code-like-Hell”
• Specification (maybe), Code (yes), Release
(maybe)
• Advantages
– No overhead
– Requires little expertise
• Disadvantages
– No process, quality control, etc.
– Highly risky
• Suitable for prototypes or throwaways
21

•21

Spiral

22

•22

•11
Evolutionary Prototyping
• Design most prominent parts first
– Usually via a visual prototype
• Good for situations with:
– Rapidly changing requirements
– Non-committal customer
– Vague problem domain
• Provides steady, visible progress
• Disadvantages
– Time estimation is difficult
– Project completion date may be unknown
– An excuse to do “code-and-fix” 23

•23

Staged Delivery
• Waterfall steps through architectural design
• Then detailed design, code, test, deliver in stages
• Advantages
• Customers get product much sooner
• Tangible signs of progress sooner
• Problems discovered earlier
• Increases flexibility
• Reduces: status reporting overhead & estimation error
• Disadvantages
• Requires more planning (for you the PM)
• More releases increase effort (and possible feature creep)
• How’s this differ from Evolutionary Prototyping?
24

•24

•12
V Process Model

25

•25

RAD
• Rapid Application Development
• Popular in the 80’s
– 1. Joint Requirements Planning (JRP)
– 2. Joint Application Design (JAD)
– 3. Construction
• Heavy use of tools: code generators
• Time-boxed; many prototypes
– 4. Cutover
• Good for systems with extensive user input
available

26

•26

•13
COTS
• Commercial Off-The-Shelf software
• Build-vs.-buy decision
• Advantages
– Available immediately
– Potentially lower cost
• Disadvantages
– Not as tailored to your requirements
• Remember: custom software rarely meets its ideal
(so compare that reality to COTS option)
27

•27

XP: eXtreme Programming

• Not a Microsoft product
• Part of movement called “Agile
Development”
• A “Lightweight” methodology
• A bit counter-culture
• Currently in vogue
• Motto: “Embrace Change”
• Highly Incremental / Iterative
28

•28

•14
eXtreme Programming

29

•29

Rational Unified Process

30

•30

•15
Choosing Your Lifecycle
• Varies by project
• Opt for “iterative” or “incremental”
• How well are requirements understood?
• What are the risks?
• Is there a fixed deadline?
• How experienced is the team or customer?

31

•31

PROCESS GROUPS
AND
KNOWLEDGE AREAS

. 32

•32

•16
PM Knowledge Areas & Process Groups
PM Process Initiating Process Planning Process Group Executing Process Group Monitoring & Controlling Closing
Groups / Group Process Group Process
Knowledge Area Group
Processes

Project Develop Project Charter Develop Project Management Plan Direct and Manage Project Monitor and Control Project Work Close Project
Management Develop Prelim Project Execution Integrated Change Control
Integration Scope Statement

Project Scope Scope Planning Scope Verification

Management Scope Definition Scope Control
Create WBS

Project Time Activity Definition & Sequencing Schedule Control

Management Resource Estimating
Duration Estimating
Schedule Development

Project Cost Cost Estimating Cost Control

Management Cost Budgeting

Project Quality Quality Planning Perform Quality Assurance Perform Quality Control
Management

Project HR Human Resources Planning Acquire Project Team Manage Project Team
Management Develop Project Team

Project Communications Planning Information Distribution Performance Reporting

Communications Manage Stakeholders
Management

Project Risk Risk Management Planning Risk Monitoring and Control

Management Risk Identification
Qualitative / Quantitative Risk
Analysis
Risk Response Planning

Project Procurement Plan Purchases and Acquisitions Request Seller Responses Contract Administration Contract Closure
Management Plan Contracting Select Sellers

•33

Knowledge Areas

34

•34

•17
Project Management Knowledge Areas
• An area of project management defined by its knowledge
requirements and described in terms of its associated process,
practices, inputs, outputs, tools and techniques
• Identified knowledge areas (the ‘things’)
1. Project Integration Management
2. Project Scope Management
3. Project Time Management
4. Project Cost Management
5. Project Quality Management
6. Project Human Resource Management
7. Project Communications Management
8. Project Risk Management
9. Project Procurement Management 35

•35

1. Project Integration Management

• effective integration of the processes required to
accomplish project objectives
• processes include
1. project charter development
2. preliminary project scope statement development
3. project management plan development
4. project execution
5. monitoring and control of project work

•36

•18
2. Project Scope Management
• defines and controls what is and is not included in
the project
• processes include
1. scope planning
2. scope definition
3. creation of a Work Breakdown Schedule
4. scope verification
5. scope control

•37

3. Project Time Management

• includes processes required for the timely
completion of a project
• processes include
1. defining activities
2. sequencing activities
3. estimating resource activities
4. estimating duration of activities
5. developing the project schedule
6. controlling the project schedule

•38

•19
4. Project Cost Management
• planning, estimating, budgeting and controlling
costs to ensure the project can be completed within
the approved budget
• processes include
1. cost estimating
2. cost budgeting
3. cost control

•39

5. Project Quality Management

• all activities that determine quality policies,
objectives and responsibilities for the project to
satisfy the needs for which it was undertaken
• processes include
1. quality planning
2. performing quality assurance
3. performing quality control

•40

•20
6. Project Human Resource Management

• processes that organize and manage the project

team
• processes include:
1. human resource planning
2. acquiring the project team
3. developing the project team
4. managing the project team

•41

7. Project Communications Management

• activities to ensure project information is timely and

appropriately generated, collected, distributed,
stored, retrieved and disposed of
• processes include
1. communications planning
2. information distribution
3. performance reporting
4. managing stakeholders

•42

•21
8. Project Risk Management
• processes to increase the probability and impact of
positive events and decrease the probability and impact
of negative events
• updated throughout the project
• processes include
1. risk management planning
2. risk identification
3. qualitative risk analysis
4. quantitative risk analysis
5. risk response planning
6. risk monitoring and control

•43

9. Project Procurement Management

• processes to purchase/acquire the products, services
or results needed to perform the project work
• includes contract management and change control
processes to administer contracts or purchase orders
• processes include:
1. planning purchases and acquisitions
2. contract planning
3. requesting seller responses
4. selecting sellers
5. contract administration
6. contract closure

•44

•22
Project Management Framework

•45

•46

•23
Process Groups

47

•47

Project Management Process Groups

• A process is a series of actions directed toward a
particular result.
• Project management can be viewed as a number of
interlinked processes.
• The project management process groups include:
– Initiating processes
– Planning processes
– Executing processes
– Monitoring and controlling processes
– Closing processes

48

•48

•24
PMI Process Groups

Source: Project Management Institute

Taken from PMI handbook

•49

Project Initiation
• Initiating a project includes recognizing and starting a new
project or project phase.
• Some organizations use a pre-initiation phase, while others
include items such as developing a business case as part of the
initiation.
• The main goal is to formally select and start off projects.
• Key outputs include:
– Assigning the project manager.
– Identifying key stakeholders.
– Completing a business case.
– Completing a project charter and getting signatures on it.

•50

•25
Project Planning
• The main purpose of project planning is to guide
execution.
• Every knowledge area includes planning information
• Key outputs included:
– A team contract.
– A scope statement.
– A work breakdown structure (WBS).
– A project schedule, in the form of a Gantt chart with all
dependencies and resources entered.
– A list of prioritized risks (part of a risk register).

•51

Project Executing
• Project execution usually takes the most time and
resources.
• Project managers must use their leadership skills to handle
the many challenges that occur during project execution.
• Many project sponsors and customers focus on deliverables
related to providing the products, services, or results
desired from the project.
• A milestone report can keep the focus on completing major
milestones.

•52

•26
Project Monitoring and Controlling
• Involves measuring progress toward project
objectives, monitoring deviation from the plan,
and taking corrective action to match progress
with the plan.

• Affects all other process groups and occurs

during all phases of the project life cycle.

• Outputs include performance reports, requested

changes, and updates to various plans.

•53

Project Closing
• Involves gaining stakeholder and customer
acceptance of the final products and services.
• Even if projects are not completed, they should
be formally closed in order to reflect on what
can be learned to improve future projects.
• Outputs include project archives and lessons
learned, which are part of organizational process
assets.
• Most projects also include a final report and
presentation to the sponsor or senior
management.
•54

•27
Mapping the Process Groups to the
Knowledge Areas
• We can map the main activities of each PM process
group into the nine knowledge areas identified by
Project management body of knowledge

• Note that there are activities from each knowledge area

under the planning process group.

• All initiating activities are part of the project

integration management knowledge area.

•55

Relationships Among Process Groups and Knowledge Areas

•PMBOK® Guide 2004, p. 69

56

•56

•28
Relationships Among Process Groups and Knowledge Areas

57

•57

Difference between knowledge areas &Process Groups

• The process groups divide up the processes by function.
• Knowledge areas divide the same processes up by subject matter.
• Process groups concerned with actions you take on your project,
• Knowledge areas with the things you need to understand.
• Knowledge areas are more about helping you understand the
PMBOK® Guide material than about running your project.
• But that doesn't mean that every knowledge area has a process in
every process group, e.g., the Initiating process group only has two
processes, and they both show up in the Integration Management
knowledge area.
• The Risk Management knowledge area only has Planning and
Monitoring & Controlling processes.
• So process groups and knowledge areas are two different ways to
think about all of the processes, but they don't really overlap

•58

•29
Project Management Knowledge
Areas and Process Groups

with respect to

Software Projects

59

•59

PMI: Process Links

Taken from PMI handbook

•60

•30
PMI Phase Interactions

Design Phase
Initiating Planning
Processes Processes
Implementation Phase
Initiating Planning
Controlling Executing Processes Processes
Processes Processes

Controlling Executing
Closing Processes Processes
Processes

Closing
Processes

•61

Conclusion

62

•62

•31