MC1802-Software Project Management: Nisha R.S. Lecturer, Dept. of CA
MC1802-Software Project Management: Nisha R.S. Lecturer, Dept. of CA
Management
NISHA R.S.
Lecturer,
Dept. of CA.
Course Objectives
Understand the fundamental principles of Software Project
management & will also have a good knowledge of
responsibilities of project manager and how to handle these.
Introduction
Project – Definition
In the broadest sense, a project is a specific,
finite task to be accomplished. Any activity
that results in a deliverable or a product.
Finite
Fixed timeline, start date, end date, milestone dates
Limited
Budget, Resources, Time
Life Cycle
Recognizable sequence of phases
Product
Project People
Requirement
Analysis
System
Design
Coding
Testing
Maintenance
Waterfall Model
classical
one-shot approach
effective control
limited scope of iteration
long cycle time
not suitable for system of high
uncertainty
V Model
Maintenance
Unit and
Program Design
Integration Testing
Coding
V Model
Additional validation process
introduced
Relate testing to analysis and design
Loop back in case of discrepancy
Spiral Model (adapted from Boehm 1987)
Spiral Model
Evolutionary approach
Iterative development combined with
risk management
Risk analysis results in “go, no-go”
decision
Spiral Model
Four major activities
Planning
Risk analysis
Engineering
Customer evaluation
Prototyping Model
Goals
meet users’ requirements in early stage
reduce risk and uncertainty
Classification of Prototype
Throw-away
After users agree the requirements of the
system, the prototype will be discarded.
Evolutionary
Modifications are based on the existing
prototype.
Incremental
Functions will be arranged and built
accordingly.
Prototyping Model
YES
User
Build prototype
satisfaction
NO
User feedback
Benefits of Prototyping
Learning by doing
Improved communication
Improved user involvement
Clarification of partially-known
requirements
Prototyping Sequences
Requirements gathering
Quick design
Prototype construction
Customer evaluation
Refinement
Loop back to quick design for fine tuning
Product engineering
Benefits of Prototyping
Demonstration of the consistency and
completeness of a specification
Reduced need for documentation
Reduced maintenance costs
Feature constraint
Production of expected results
Drawbacks of Prototyping
Users sometimes misunderstand the
role of the prototype
Lack of project standards possible
Lack of control
Additional expense
Close proximity of developers
Forms of Prototypes
Mock-ups
Simulated interaction
Partial working model
Incremental Model
Break system into small components
Implement and deliver small
components in sequence
Every delivered component provides
extra functionality to user
Incremental Model
NO
YES
Iterative Model
Deliver full system in the beginning
Enhance functionality in new releases
Iterative Model
Design system
n = n+1
version n NO
YES
Why Have Project Phases and
Management Reviews?
Domain Processes
Scope Planning and the Scope
Statement
A scope statement is a document used
to develop and confirm a common
understanding of the project scope. It
should include
a project justification
a brief description of the project’s products
a summary of all project deliverables
a statement of what determines project
success
Scope Planning and the Work
Breakdown Structure
1.0 Concept
1.1 Evaluate current systems
1.2 Define Requirements
1.2.1 Define user requirements
1.2.2 Define content requirements
1.2.3 Define system requirements
1.2.4 Define server owner requirements
1.3 Define specific functionality
1.4 Define risks and risk management approach
1.5 Develop project plan
1.6 Brief web development team
2.0 Web Site Design
3.0 Web Site Development
4.0 Roll Out
5.0 Support
Approaches to Developing
WBSs
Using guidelines: Some organizations,
like the DOD, provide guidelines for
preparing WBSs
The analogy approach: It often helps to
review WBSs of similar projects
The top-down approach: Start with the
largest items of the project and keep
breaking them down
The bottoms-up approach: Start with
the detailed tasks and roll them up
Basic Principles for Creating WBSs
1.A unit of work should appear at only one place in
the WBS.
2. The work content of a WBS item is the sum of
the WBS items below it.
3. A WBS item is the responsibility of only one
individual, even though many people may be
working on it.
4. The WBS must be consistent with the way in
which work is actually going to be performed; it
should serve the project team first and other
purposes only if practical.
5.Project team members should be involved
in developing the WBS to ensure
consistency and buy-in.
6. Each WBS item must be documented to
ensure accurate understanding of the scope
of work included and not included in that
item.
7. The WBS must be a flexible tool to
accommodate inevitable changes while
properly maintaining control of the work
content in the project according to the
scope statement.
Scope Verification and Scope
Change Control
It is very difficult to create a good scope
statement and WBS for a project
It is even more difficult to verify project
scope and minimize scope changes
Many IT projects suffer from scope
creep and poor scope verification
Factors Causing IT Project
Problems
Factor Rank
Lack of user input 1
Incomplete requirements and specifications 2
Changing requirements and specifications 3
Lack of executive support 4
Technology incompetence 5
Lack of resources 6
Unrealistic expectations 7
Unclear objectives 8
Unrealistic time frames 9
New Technology 10
Suggestions for Improving User
Input
Insist that all projects have a sponsor
from the user organization
Have users on the project team
Have regular meetings
Deliver something to project users
and sponsor on a regular basis
Co-locate users with the developers
Suggestions for Reducing
Incomplete and Changing
Requirements
Develop and follow a requirements management process
Employ techniques such as prototyping, use case
modeling, and Joint Application Design to thoroughly
understand user requirements
Put all requirements in writing and current
Create a requirements management database
Provide adequate testing
Use a process for reviewing requested changes from a
systems perspective
Emphasize completion dates
Unit III
Software Development
Software Size and Reuse
Estimating
Idea:
software is better measured in terms
of the number and complexity of the
functions that it performs
Function points measure categories of
end-user business functions
Function Point Process Steps
Primary disadvantage:
subjective classification of algorithmic
complexity
Object Points
Scheduling Activities
Project management resource
activities.
• Personal
• Organizational
• System
• PERSONAL
It deals with all conflicts involving people in or
related to the project.
• ORGANIZATIONAL
It deals with conflicts due to varying
organizational goals and the different
management styles of the project and resource
supplying organizations.
• SYSTEM
It deals with the product, facility, or other
non people interfaces developed by the project.
Organizational structure:
Functional organizations
Matrix organizations
Projectized organizations
D=7 5 F=2