SPM_Unit-I-1

Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 86

SOFTWARE PROJECT MANAGEMENT

(EIT-470/ECA-555)

Dr. Raghuraj Singh, Professor


Computer Science & Engineering Department
Harcourt Butler Technical University, Kanpur
Email: rscse@rediffmail.com
Mobile: 9415153745
Syllabus
UNIT-I: Introduction and Software Project
Planning
Fundamentals of Software Project Management
(SPM), Need Identification, Vision and
Scope Document, Project Management
Cycle, SPM Objectives, Management
Spectrum, SPM Framework, Software
Project Planning, Planning Objectives,
Project Plan, Types of project plan,
Structure of a Software Project
Management Plan.
Syllabus
UNIT-II: Project Organization and Scheduling
Project Elements, Work Breakdown Structure
(WBS), Types of WBS, Functions, Activities and
Tasks, Project Life Cycle and Product Life
Cycle, Ways to Organize Personnel, Project
schedule, Scheduling Objectives, Building the
project schedule, Scheduling terminology and
techniques, Network Diagrams: PERT, CPM,
Bar Charts: Milestone Charts, Gantt Charts.
Syllabus
UNIT-III: Project Monitoring and Control
Dimensions of Project Monitoring & Control,
Earned Value Analysis, Earned Value
Indicators: Budgeted Cost for Work
Scheduled (BCWS), Cost Variance (CV),
Schedule Variance (SV), Cost Performance
Index (CPI), Schedule Performance Index
(SPI), Interpretation of Earned Value
Indicators.
Syllabus
UNIT-IV: Software Quality Assurance
Concept of Software Quality, Software Quality
Attributes, Software Quality Metrics and
Indicators, Software Quality Assurance (SQA),
SQA Activities, SQA Plans, Software Quality
Frameworks, ISO 9000 Models, SEI Capability
Maturity Model (CMM), Software Verification
and Validation, Formal SQA Approaches: Proof
of Correctness, Statistical Quality Assurance,
Cleanroom Process.
Syllabus
UNIT-V: Project Management and Project
Management Tools
Software Project Estimation, Estimation
Methods, Estimation Models, Decision Process.
Risk Management: Risks and Risk Types, Risk
Breakdown Structure (RBS), Risk Management
Process: Risk Identification, Risk Analysis, Risk
Planning, Risk Monitoring, Cost Benefit
Analysis, Software Project Management Tools:
CASE Tools, Planning and Scheduling Tools
like MS-Project.
Books
• B. Hughes and M. Cotterell, Software Project
Management, TMGH Publication.
• Kathy Schwalbe, Information Technology
Project Management, Vikas Pub. House.
• S. A. Kelkar, Software Project Management,
PHI Publication.
• R. S. Pressman, Software Engineering,
McGraw Hill, VI Edition.
• I. Sommerville, Software Engineering,
Addison Wesley, VII Edition.
Software
Project Management
This course is an introduction to project
management. The course provides the
concepts and tools necessary for
managing complex projects, with a
particular focus on managing software
development projects and the software
quality.

(Everything you ever wanted to know about


how to get things done!)
Motivations
Most of the courses in Computer Science &
Engineering focus on the technical aspects
of software development (how to do testing,
how to write requirements, how to model
systems) or on notations (UML, Java, …)

However, in order to build good software, you


need a well defined and managed
process…
Motivations
Some Examples:

• The techniques to do testing are useless if you


don’t have time to do the testing (because, for
instance, you planned the project wrong and
are late with development)

• Writing good requirements is no good if you


don’t have a controlled process, for instance,
to accept changes and revisions.
Motivations
… moreover, if you want to develop
Quality software on time and on
budget, there is no way you can do it
without managing the development
process.
Who Needs Software?
• Most of the software are built in organizations
for people with specific needs.
– A stakeholder is anyone who has an interest (or
stake) in the software being completed.
– A user is someone who will need to use the
software to perform certain tasks.
– Sometimes stakeholders will also be the users; but
often the stakeholder will not use the software.
• For example, a senior manager (like a CEO in a
company) will usually have a stake in the software that is
built, even if he won’t ever use it.
Who Builds Software?
• Software are typically built by a team of
Software Engineers, which includes:-
– Business Analysts or Requirements Analysts
who talk to users and stakeholders, plan the
behavior of software and write software
requirements.
– Designers and Architects who plan for the
technical solution.
– Programmers who write the code.
– Testers who verify that the software meets its
requirements and behaves as expected.
– Support Team which does installation, training and
maintenance.
What is a Project ?
A project is a temporary endeavor undertaken to
create a unique product, service, or result
What is a Project ?
• Temporary
– definitive begin and end (either because the goals are
met or the project is closed).
– projects’ results are not necessarily temporary (see
project and product lifecycle)
• Unique product, service, or result
– A product which is quantifiable (e.g. a component, …)
– A capability to perform a service, such a business
function.
– A result, such as knowledge (collected in documents,
presentation, …)
• Progressive elaboration
– Development by steps and in increments.
Project and Operational Work
Work can be categorized either as project or
operational work.
• Common characteristics
– Performed by people.
– Limited resources.
– Planned, executed, and controlled.
• Differences
– Project: obtain goals and terminate.
– Operational Work: sustain the business.
Examples
• Cooking dinner OW
• Preparing a dinner for friends PR
• Mass producing a car OW
• Designing a car PR
• Publishing papers OW
• Developing a software system PR
Project Management
… requires fundamental competencies and skills:
• How to estimate the time it will take to
complete a task? (Schedule)
• How much to be charged for a project?
(Cost)
• How to deal with people in the project team,
e.g. keep them motivated? (Organize)
• How to assess whether the project is on time,
on budget, and on schedule? (Monitoring)
• How to control the quality of the final
output? (Control)
Project Management
• The Project Manager (PM) plans and guides the
software project.
– The PM is responsible for identifying the users and
stakeholders and determining their needs.
– The PM coordinates the team, ensuring that each
task has an appropriate software engineer assigned
and that each engineer has sufficient knowledge to
perform it.
– To do this well, the project manager must be familiar
with every aspect of software engineering.
Detailed Project Report (DPR)
• DPR is the output of planning and design phase of a
project.
• DPR is a very detailed and elaborated plan for a
project indicating overall programme, different roles and
responsibilities, risk and their management plan,
activities and resources required for the project.
• DPR is the basic of specification, contract drawings,
detailed technical feasibility, financial feasibility, and
execution of project from practical point of view
• DPR is a final, detailed appraisal report on the project
and a blue print for project execution and eventual
operation.
Statement of Work (SOW)
• Statement of Work (SOW) is made at the outset of
a project.
• SOW outlines everything that needs to go into
your project.
• Introduction, purpose, scope, schedule, tasks,
milestones, deliverables, standards & testing,
requirements, payments, success criteria etc.
• A thorough and well-written SOW will set you up to
successfully lead a project over the finish line on
schedule and within budget.
Identifying Needs
• The project manager drives the scope
of the project.
– The project manager should identify and
interact to the main stakeholders.
– The effective way to show stakeholders
that their needs are understood and that
those specific needs will be addressed is a
vision and scope document.
Vision and Scope Document
Template for the Vision and
Scope Document
Laws of Project Management
• Projects progress quickly until they are 90%
complete and then they remain at 90% complete
forever.
• When things are going well, something will go
wrong. When things just can’t get worse, they will.
• When things appear to be going better, you come
to know that you overlooked something.
• If project content is allowed to change freely, the
rate of change will exceed the rate of progress.
• Project teams detest (hate) progress reporting
because it manifests (express) their lack of
progress.
Project Management Cycle
• Deals with the management techniques
required to

Plan Organize

Control Monitor
Project Management Cycle
Project Management Cycle
• Plan the Project
– What are the deliverables?
– What tasks are needed to produce the
deliverables?
– What resources are needed and for how
long?
– What will the project cost?
• Organize/Schedule the Project
– Who will work on it?
– When are they available?
– What other resources are needed?
– How can the resources be acquired and used?
Project Management Cycle Ctd..
• Monitor & Control the Project
– What happened since the last time
project plan was updated?
– What is the effect on the schedule?
– What problems or opportunities need to be
addressed?
– Are we on time and within budget?
Software Project Management
Uses concepts and techniques for
•Management of people, process & problems.
•Managing S/W product & process through
metrics.
•Estimation of efforts, cost, schedule etc.
•Risk analysis for overall project success.
•Quality assessment and control.
•Software Quality Assurance (SQA).
•Formal Technical Reviews (FTR).
SPM Objectives
• To explain the main tasks undertaken by
project managers.
• To introduce software project management
and to describe its distinctive characteristics.
• To discuss project planning and the planning
process.
• To show how graphical schedule
representations are used.
• To discuss the notion of risks and the risk
management process.
Software Project Management
• SPM is concerned with activities to
ensure that software is delivered on
time, as per schedule, within the
budget, and in accordance with the
requirements.
• Project management is needed due to
budget and schedule constraints.
Management Spectrum
4 P’s
• People
• Product
• Process
• Project
People
The people management model defines the
following key practice areas for s/w people.
 Recruiting/Selection.
 Performance management.
 Training (TNA).
 Motivation/Compensation.
 Career development.
 Organization.
 Work design.
 Team/culture development.
Productivity and People
Software Team Roles
Product
Before planning a project
 Product objectives and scope should be
established.
 Alternative solutions should be considered.
 Technical & management Constraints
should be identified.
Product Dimensions
• Software scope
– Context.
– Information objectives.
– Functions.
– Performance.
• Problem decomposition
– Partitioning or problem elaboration.
– Focus is on functionality to be delivered and the
process used to deliver it.
Process
Framework activities populated with
different task sets.
 Tasks milestones.
 Work products.
 Quality assurance points.
 Umbrella activities like
 Software quality assurance.
 Software configuration management.
Process Dimensions
• What it is?
• Who does it?
• Why it is important?
• What are the steps?
• What is the work product?
• How to ensure that product has been
built right?
5WHH Principle
• Why is the system being developed (Scope) ?
• What will be done (Business Functions) ?
• When it will be done (Schedule) ?
• Who is responsible for a function (Resource)?
• Where are they organizationally located?
• How will the job be done technically and
managerially?
• How much of each resource is needed
(Estimation)?
Project
To avoid the problems that jeopardize the
successfulness of the project
 Start on the right foot: understand the problem,
set the realistic objects & expectations, build the
right team etc.
 Maintain momentum.
 Track the progress regularly.
 Make smart and appropriate decisions.
 Conduct a postmortem analysis: Establish a
consistent mechanism to extract lessons learnt
for each project.
SPM Framework
Includes conduction of all such activities
and tasks that are necessary for
successful completion of the software
project.
SPM Framework
SPM Framework Activities
SPM Phases
Project Management Tasks
• Project Initiation.
• Project Planning.
• Project Monitoring.
• Project Control.
• Evaluation of Alternatives
• Taking and Communicating Decisions.
• Motivating.
• Liaison with all concerned.
Project Initiation
• Study customer order with care.
• Investigate needs/business objectives.
• Find the constraints and opportunities.
• Select development strategy for
considering alternatives.
• Revalidate estimates.
• Develop and review initial project plan.
• Arrange for resources.
• Organize the team.
• Begin the project with a kick-off.
Project Kick-off
• Needed for creating a team spirit right-
up-front and for achieving a common
understanding of project requirements.
• Following type of aspects are shared
and discussed
- Customer commitments.
- Project plan and milestones.
- Risks.
- Performance measures.
- Inter-group commitments.
- Baselines.
Who should attend Kick-off

• Project Manager.
• Team members.
• Steering committee members.
• Members of interface groups.
• Customer.
Project Planning
• Process of determining a reasonably
detailed way to go from inputs to outputs.
• A Project plan specifies the following
- What work will be done (Scope).
- When will it be accomplished (Schedule).
- Who will do the work (Resources).
- How will it be done (Process).
- How much will it cost (Budget).
- How will the status be reported (Monitor).
- How will the progress be reviewed (Control).
- In general, How will it be managed (Manage).
Project Plan
Project plan should include
•Project Objectives.
•Customer and Management Requirements.
•Inputs.
•Work Breakdown Structure (WBS).
•Deliverable Breakdown Structure.
•Acceptance Criteria.
•Methodology to be used.
Project Plan
• Human Resource Requirements.
• Dependencies in the Plan.
• Estimation.
• Risk Analysis.
• Project Organization.
• Quality Assurance Approach.
• Customer Feedback.
• Periodic Reporting and Reviews.
• Other Plans and Attachments.
Project Monitoring
• Recording Project Data
- Elapsed time.
- Work achieved.
- Resource Cost.
- Resource expanded.
- Other factors such as staff turnover, sickness,
training, breakdowns etc.
• Comparison with Budget vs Actual
- Cost, Schedule, Resources.
• Project reporting
- Product factors.
- People factors.
- Process factors.
- Resource factors.
- Environment factors.
Project Control
• Types of Review Meetings
- Internal project meetings.
- Project steering meetings.
- Customer review meetings.
- Issue resolution meetings.
• Project Evaluation
- Deviation due to performance.
- Deviation due to changed objectives.
- Risk management issues.
• Corrective Actions for Better Results
- Justification of project existence.
- Realloaction of resources.
- Rescheduling.
- Overtimes and costs.
Project Liaison

Customer

Steering
Quality
Committee

Supplier Training
Project
Manager

Team
Finance
Members

Resources Legal
A Typical Project Organization

Steering Committee
Customer

Project Manager

Development Team Configuration Team


Quality Team Leader
Leader Leader

Team Members
Project Responsibilities
(Customer)
• Giving requirements and requirement
clarifications.
• Providing agreed inputs such as
acceptance criteria, test data, etc.
• Accepting deliverables.
Project Responsibilities
(Steering Committee)

• Reviewing and approving


- Project plan (estimations, costs, schedules).
- Requirements change requests.
• Reviewing the project status.
• Resolving the project issues.
Project Responsibilities
(Project Manager)
• Initiating the project.
• Understanding project requirements.
• Planning, estimation and scheduling of
the project.
• Identifying training needs and planning
for training.
• Accepting project inputs.
• Moderating work-products (from review
and testing).
Project Responsibilities
(Project Manager)
• Reporting, monitoring and reviewing
status.
• Resolving issues.
• Maintaining action log.
• Liaison with customer and seeking
feedback.
• Releasing deliverables.
• Closing of project.
Project Responsibilities
(Development Team Leaders)

• Understanding system requirements.


• Defining requirements.
• Performing high level design.
• Delivering work products.
• Reporting status and resolving issues.
• Ensuring project filing.
Project Responsibilities
(Quality Team Leader)

• Upholding organizational policies.


• Adhering to project methodologies.
• Performing review and test.
Project Responsibilities
(Configuration Team Leader)

• Controlling configuration library.


• Enforcing change control.
• Approving change requests.
• Holding custody of change requests.
• Doing change impact analysis.
• Making customer release.
Software Project Planning
• Probably the most time-consuming project
management activity.
• Continuous activity from initial concept
through to system delivery.
• Plans must be regularly revised as new
information becomes available.
• Various types of plans may be developed to
support the main software project plan which
is about schedule and budget.
Software Project Planning
• Provides a framework for the project.
– Software scope.
– Resources.
– Expectations.
• Make it possible to generate reasonable
estimates for
– Resources.
– Schedules.
– Costs.
Why a Project Plan?
• Forces the making of necessary
decisions.
– Estimates, scheduling, budgeting.
• Communicates decisions to others.
• Checklist / action plan
• Who, what, when, why, where, how
• The ”rules” of the project written in text,
no misinterpretation.
Project Planning
The Project Plan
• The very minimal project plan deal with
– Project objectives.
– Project deliverables.
– Project schedule.
– Supporting plans.
Types of Project Plan
Support Project Plans
Planning Objectives
• To provide a framework that allows
software manager to make an estimate
of resources, cost, and schedule.
• Project outcomes should be bounded
by 'best case' and 'worst case'
scenarios.
• Estimates should be updated as the
project progresses.
Project Plan Contents
• A Statement of Work (SOW) that describes all
work products to be produced and a list of
people who will perform that work.
• A Resource List that contains all resources
needed for the product and their availability.
• A Work Breakdown Structure (WBS) and a
set of estimates.
• A project Schedule.
• A Risk Plan that identifies any risks that might
be encountered and indicates how those risks
would be handled should they occur.
Statement of Work
• The statement of work (SOW) is a detailed
description of all the work products which
will be created over the course of the project.
It includes:-
– A list of features that will be developed.
– A description of each intermediate
deliverable or work product.
– The estimated effort involved for each work
product.
Resource List
• The project plan should contain a list of all
resources that will be used on the project.
– A resource is a person, hardware, room or
anything else that is necessary for the
project but limited in its availability.
– The resource list should give each
resource a name, a brief one-line
description, and the availability & cost (if
applicable).
Purpose of a Project Plan
• To achieve clear goals that can be described by
documented deliverables.
• Intermediate deliverables like
– Design documents.
– Application source code.
– Approvals of intermediate work.
– Quality assurance proofs.
• Final deliverables like
– Product and/or service.
– Customer/client satisfaction.
– Profit for the developers.
Purpose of a Project Plan
• Forces management to consider all the activities
and phases of a project.
• Project Plan is used for communication of
• Information about the scope and structure of a
project
• What, how, why and when must be done.
• Information for participants and stakeholders.
• The Project Plan is used to
• schedule and organize the activities.
• request appropriate time and budget.
• track project progress.
Structure of a Software Project
Management Plan

0. Front Matter
1. Introduction
2. Project Organization
3. Managerial Process
4. Technical Process
5. Work Elements, Schedule, Budget
6. Optional Inclusions
SPMP Part 0: Front Matter

• Title Page
• Revision sheet (update history)
• Preface: Scope and purpose
• Tables of contents, figures, tables
SPMP Part 1: Introduction
1.1 Project Overview
Executive summary: description of project,
product summary.
1.2 Project Deliverables
All items to be delivered, including delivery
dates and location.
1.3 Evolution of the SPMP
Plans for anticipated and unanticipated
change.
1.4 Reference Materials
List of materials referenced in SPMP.
1.5 Definitions and Acronyms
SPMP Part 2: Project Organization

2.1 Process Model


Relationships among project elements.
2.2 Organizational Structure
Internal management, organization chart.
2.3 Organizational Interfaces
Relations with other entities.
2.4 Project Responsibilities
Major functions and activities; nature of
each; who’s in charge.
SPMP Part 3: Managerial Processes
3.1 Management Objectives and Priorities
Philosophy, goals and priorities.
3.2 Assumptions, Dependencies, Constraints
External factors.
3.3 Risk Management
Identifying, assessing, tracking,
contingencies for risks.
3.4 Monitoring and Controlling Mechanisms
Reporting mechanisms and formats,
information flows, reviews.
3.5 Staffing Plan
Needed skills (what?, how much?, when?)
SPMP Part 4: Technical Process

4.1 Methods, Tools and Techniques


Computing system, development method,
team structure, etc. Standards, guidelines,
policies.
4.2 Software Documentation
Documentation plan, including milestones,
reviews and baselines.
4.3 Project Support Functions
Plans for functions (quality assurance,
configuration management).
SPMP Part 5: Work Elements
5.1 Work Packages (Work breakdown structure)
Project decomposed into tasks; definitions of tasks.
5.2 Dependencies
Precedence relations among functions, activities and
tasks.
5.3 Resource Requirements
Estimates for resources such as personnel, computer
time, special hardware, support software.
5.4 Budget and Resource Allocation
Connect costs to functions, activities and tasks.
5.5 Schedule
Deadlines, accounting for dependencies, required
milestones.
Unit-I

Thanks!

You might also like