Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Project
Management
1
Syllabus
2
2. S/w Project Estimation (25)
Work Break Down for Project Estimation & setting
Milestones
Different methods of estimation
COCOMO model
Delphi cost estimation
Function point analysis.
Project Management through Microsoft Project(Ms-Project)・
Introduction
Gantt Chart
PERT Chart
Usage of Microsoft Project for Estimation and Management
Software Project Metrics
(Size Oriented, Software Measurement, Function Oriented,
Object Oriented Metrics)
Project Scheduling, tracking & Progress reporting
3
3. Risk Management(10)
Identification of Risks
Risk Management Process: Risk identification, Risk analysis,
Risk planning, Risk monitoring, Risk Closure
4. Software Quality Management & Control(20)
Quality Assurance & Standards ; The SEI Capability Maturity
Model CMM;
Concept of Software Quality, Software Quality Attributes,
Software Quality Metrics and Indicators,
Quality assurance & Validation plan (SQA
Activities , reviews, walkthroughs, inspection, testing)
Automation to improve Quality in testing
Defect Management
4
5. Configuration Management(CM)(13)
Configuration management & Maintenance plan
Change Management
Version and Release Management
Configuration Management Tools
6. S/W Team Management(12)
Team Structure & Staff development plan
Characteristics of Performance management
High performance Directive and collaborative styles
Team Communication
Group Behavior
Managing customer expectations
5
7. Project Management Tools (8)
Project management tool like MS Project
Assignment can be given based on the tool
6
Software Project Management
Program – set of instructions
Software
• Computer instructions or data. Anything that can be stored
electronically is software.
• Collection of programs to achieve some goal.
Project
• A project is a sequence of unique, complex and connected activities
having one goal or purpose and that must be completed in a specific
time within budget and according to requirement specifications.
• A temporary efforts undertaken to create a unique product, service or
result.
7
Software Project Management
• Examples of project
1. A plan or proposal; a scheme.
2. An extensive task undertaken by a student or group
of students to apply, illustrate, or supplement
classroom lessons.
3. A housing project.
8
Management
Project Management
10
Software Project Management
Project Management is the application of knowledge, skills,
tools and techniques to project activities to meet project
requirements. The PMBOK lists nine knowledge areas of PM
Integration Management
Scope Management
Time Management
Cost Management
Quality Management
Human Resource Management
Communication Management
Risk Management
Procurement Management
11
Who needs software?
Most softwares are built in organizations for people with
specific needs.
12
Who builds software?
Software is typically built or develop by a team of
software engineers, which includes:
13
Important Aspects
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
14
1.1 Overview of Software Project Management
Important Aspects of SPM - 4 P’s
People
Process
16
1.Stakeholders
Senior managers: who define the business issues that often have
significant influence on the project.
Project (technical) managers : who must plan, motivate,
organize, and control the practitioners who work on software.
Practitioners/Programmers : who deliver the technical skills that
are necessary to engineer a product or application.
Customers : who specify the requirements for the software to be
engineered and other stakeholders who have a peripheral interest
in the outcome.
End-users : who interact with the software once it is released for
use.
17
2. Team Leader/Project Manager
19
3. Software Team
Team structure depends on
20
3. Software Team
There are seven factors for planning a software
team
1. Ways to handle difficulties in problems
2. Size of resultant program in LOC or FPs
3. Time that team will stay together
4. Degree to which problem can be modularized
5. Required quality and reliability of system to be
built
6. Rigidity of delivery date
7. Degree of communication required for project.
21
4. Agile Team
Agile (Responsive) team means small and highly motivated
team that adopts many characteristics of successful projects
and avoided many toxin that create problems.
It focus on individual competency and group collaboration
with team.
Self organizing team.
Involvement of end users or customers from very first phase
of development.
It uses closed, random, open and synchronous paradigm for
project organization.
22
Organizational paradigm for Project organization
23
Organizational paradigm for Project organization
Synchronous Paradigm :
It relies on Compartmentalization of a problem and
organize team member to work on piece of problem to
achieve communication between them.
In agile team planning is minimal & team is allowed to
select own approach and organizational standards.
It also conduct daily team meetings to coordinate and
synchronize the work that must be achieved for that day.
Information obtained from daily meetings, team adopts its
approach.
Continuous self organization and collaboration move agile
team towards completion of software increment.
24
5. Coordination & Communication Issues
There is need of proper communication and coordination
of software team to avoid trouble in development process.
Project team must communicate with existing software and
confirm predefined constraints imposed by system.
To avoid uncertainty, interoperability, team must use
formal as well as informal communication among team
members and between multiple teams.
Formal communication is achieved through writing,
meeting and other relative communication channels.
Informal communication is more personnel. Software team
can share their ideas, ask help as problem arise and interact
with team members on daily basis.
25
2.Product
Software Scope
Problem Decomposition
26
Software Scope
Software project scope must be understandable at the management
and technical levels.
27
Problem Decomposition
Problem decomposition is mainly focus on software
requirement analysis. Need to partition problem
into smaller problem that will be more manageable
software functions. Because that will used to make
estimation about cost and schedule.
It is mainly applied on two areas
1. The functionality that must be delivered
2. The process that will be used to deliver it.
28
Problem Decomposition
Sometimes called partitioning or problem
elaboration.
Once scope is defined
1.It is decomposed into constituent functions.
2.It is decomposed into user-visible objects.
3.It is decomposed into a set of problem classes.
Decomposition process continues until all
functions or problem classes have been defined.
29
3.Process
Software
Engineer
uses
Produces
Process Product
30
3. Process
Project manager decide which process model is most
appropriate for
1. Customer who have requested the product and
people, who will do the work.
2. Characteristics of product itself.
3. Product environment in which software team will
work.
31
3. Process
1. Melding Product and Process:
Project manager decides the set of framework
activities that defined by software organization
are
Communication
Planning
Modeling
Construction
Deployment
32
3. Process
2. Process Decomposition
Software team have significant degree of flexibility to
choose software process models
For small scale project use linear sequential model
If deadline is tight use incremental strategy
If time constraints are tight and problem can be heavily
computerized use RAD model
Once process model is chosen apply framework like
communication, planning, modeling, engineering and
deployment.
33
3.Process
Task required for Small Scale project for
communication activity
1. Develop list of clarification issues
2. Meet with customer to address clarification issues
3. Jointly develop a scope standers
4. Receive statement of scope with all concerns
5. Modify the statement of scope if required.
34
3.Process
Task required for large Scale project for communication
activity
37
1.Start on right foot
This is achieved by working hard to understand
problem.
Set objectives and expectations for everyone who
involves in project
It helps to build right team and giving the authority
and technology to do the job .
38
2.Maintain Momentum
Many project get good start & then slowly disintegrate
To maintain momentum, project manager must
provide incentives to keep turnover of personnel
Project Manager should motivate team members
Sr. Manager should do everything possible to stay out
of the team way.
39
3. Track Progress
Need to track the progress e.g. models, source code,
test cases etc.
Focus on quality assurance part
Also focus on software process and project metrics
40
4. Mark smart decisions
Decision of project manager and software team should
be kept simple
Whenever possible use existing software components
Avoid routine interfaces when standerd approaches
available
Identify and avoid risks
41
5.Conduct a postmortem analysis
Evaluate planned and actual schedule
Collect and analyze software metrics
Get feedback from team members and customers
Record findings in written form.
42
1.2 Project Organization
People Organization
Team Organization
Organizational Paradigm
Molding Product & Process
Reel’s Common sense Approach to Projects
43
People Organization
It is nothing but applying human resources to a project.
For applying human resources number of possibilities
will be there based on skills, number of functions,
processes, teams etc.
n<task
n>task
n=task
44
Team Organization
Best team structure depends on management style of an organization.
There are three form of team organization that will be totally depends
upon skill level and problem difficulty.
45
Team Organization
2. Controlled Decentralized (CD) –
Primary leader coordinate main task & secondary leader that have
responsibility for subtasks.
Problem solving is group activity.
Team leader makes partition of tasks to implement solution
among subgroups.
vertical as well as horizontal communication.
3. Controlled Centralized (CC)-
All the work like problem solving & internal team coordination
managed by team leader.
coordination between team leader & member is vertical.
46
Organizational Paradigm
1. Closed Paradigm
2. Random Paradigm
3. Open Paradigm
4. Synchronous Paradigm
47
Melding Product & Process
Planning start with melding of product & process. Any organization
adopted following set of framework activities
1.Customer Communication – required to establish requirement
elicitation between developer and customer.
2. Planning – required for defining resources, time period & other
project related information.
3. Risk Analysis – Assess both technical as well as business risks.
4. Engineering – required for building one or more representation of
application(s).
5.Construction and Release – task required for constructing, testing,
installing & providing users support.
6. Customer Evaluation – Tasks required to obtain customer feedback
based on evaluation of software representation created during the
engineering activities & implemented during construction activity.
48
1.3 Planning A Software Project
49
1.Software Scope & feasibility
Software scope in nothing but the functions or features
that are to be delivered to end users, the data that are
input and output, content that are presented to users.
Scope is defined by using two techniques
1. A narrative description of software scope is delivered
after communication with stakeholders.
2. A set of use cases is developed by end users.
50
2.Resources
Description of Resource
A statement of availability of resources
Time when resource will required
Duration of time that resource will applied
Software
Number Tools
Skills
Hardware
Tools
People Environment
Location
Network
Project Resources
Off-The-Shelf New
Components Reusable Components
Software
Full Partial
Experience Experience
Components Components
51
1 Human Resources
Human resources depends on the size of project i.e. it
must be in Person-month.
Human resources determined only after an estimation
of development is made.
For estimation PM use COCOMO,FPA , Delphi etc.
52
2.Reusable Software Resources
It mainly focus on reusability.
Bennatan suggests four software resources categories that
should be considered as planning proceeds
1.Off-the-shelf-components
2.Full experience components
3.Partial experience components
4.New Components
53
3.Environmental Resources
Environment that supports a software project is
called software engg. Environment (SEE)
including software and hardware.
Hardware provide platform that supports
software to produce work product.
Project Manager must described time window for
hardware & software and also verify this
resources will be available or not.
54
Project Management Life Cycle
55
PMLC
1. Project Initiation
Conceiving and Define Project
56
The project manager takes the information provided and creates
a Project Charter. The Project Charter authorizes the project and
documents the initial requirements for the project.
It generally includes information such as...
Project purpose, vision, and mission
Measurable objectives and success criteria
High level project description, requirements, and risks
Summary milestone schedule and budget
Name and authority of the project sponsor
An important part of starting your project off right is performing
astakeholder analysis. Understanding which people or organizations
will be impacted by or can influence your project is critical for ensuring
your project's success.
57
2. Project Planning
Begin with WBS
Estimation
Schedule(WBS)
Resources
58
The purpose of the Project Planning Phase is to determine the approach you
will take and define all the details of how the project will be done.
Project Planning has two parts...
Strategic Planning
Implementation Planning.
During Strategic Planning you develop the overall approach to the project.
During Implementation Planning you figure out all the details of how the
project will be done.
A good way to visualize this is to think of your project as a family vacation.
During Project Initiation you determine where you want to go (your
mission).
During Strategic Planning, you decide whether you want to fly there or
drive (your approach).
Let's say you decide to drive. In that case, during Implementation Planning
you would map out your route, identify which hotels you will stay at along
the way, determine how long each leg of the trip will take, and so on (all the
details).
59
3. Project Execution
• Planning for the final testing, production, and support.
60
4. Project Closure
Written formal project review report
The purpose of the Project Closure Phase is to formally close the project.
During Project Closure, there are several key activities that need to be
performed...
Verify that the completion criteria are met
Create a project closure report
Collect and archive project artifacts
Perform a project postmortem
Many projects skip this phase. Once the Execution Phase is complete, they
simply move on. It's unfortunate since they really don't know if the project
objectives have been met, don't organize the project artifacts to be easily
found for future project's reference, and don't identify the key issues and
lessons learned by the project that can be applied to future projects.
Performing Project Closure will benefit both your company and your career.
If you do this well, you will set yourself up to lead high-visibility, business-
critical projects. So make sure your projects go through the full project
management life cycle. 61
Chap. 3.
Risk Management(10)
Identification of Risks
Risk Management Process: Risk identification,
Risk analysis,
Risk planning, Risk monitoring, Risk Closure
62
Introduction
“If you don’t actively attack the risks, they will actively
attack you”.
Risks concerns future happenings
Risk involves change such as changes of mind,
opinion, actions or places.
Risk Management
SEI identifies seven principles that provide a
framework to achieve effective risk
management.
67
Risk Analysis
There are three categories of risks
1. Project Risk
2. Technical Risk
3. Business Risk
1.Project Risk
2.Technical Risk
- It is mainly focus on Design phase & coding phase of SDLC
- Threats the quality as well as time period
- it will identified by considering design, implementation, interface,
verification & maintenance problems.
-It is mainly focus on technical aspects of the software components.
68
Risk Analysis
3. Business Risk
- Breaks the viability (capability) of the software
- There are five business Risks
- There are five types of business risk
i) Market Risks- Build excellent product or system that no
one really wants.
ii) Strategic Risk- build a product that no longer fits into
overall business strategy for the company.
iii) Sales Risk- Build the product that sales force doesn't
understand how to sell.
iv) Management Risk- due to support, change in people,
change in focus.
v) Budget Risk- loosing budgetary or personnel commitment.
69
Risk Analysis
There are also three general categories of risks
70
Identification of Risks
Risk identification is systematic approach to specify
threats in plan by considering estimate, schedule, resource
allocation etc.
By identify known & predictable risk project manager can
avoid them & whenever possible control them.
There are two types of risks for each of the categories
1. Generic Risks
- This is potential threat to every software.
2. Product-Specific Risks
- This is identified only by those with clear understanding
of technology, the people & the environment i.e. specific
software to be built.
- for identification of this risk project manager can review
project plan, scope statement.
-Project Manager can use risk item checklist 71
Risk Item Checklist
1. Product Size- overall size
2. Business Impact- constraint by management or
marketplace
3. Customer Characteristics- sophistication of customer as
well as developer’s ability to communicate customer in
timely manner.
4. Proceeds Definition- degree of process & followed by
development organization
5. Development Environment- availability
& quality of tools to be used to build the product
6. Technology to be built- Complexity of the system to be
built & newness of technology
7. Staff size & Experience- overall technical & project
experience of software engineers who will do the work.
72
Assessment of Overall Project Risk
1. Have top software & customer managers formally
committed to support the project?
2. Are end-users enthusiastically committed to the
project and the product to be built?
3. Are requirement fully understood by the software
engineering team & its customers?
4. Have customers been involved fully in the definition
of requirements?
5. Do end-users have realistic expectations?
73
Assessment of Overall Project Risk
6. Is project scope stable?
7. Does the software engineering team have the
right mix of skills?
8. Are project requirements stable?
9. Does the project team have experience with the
technology to be implemented?
10. Is the number of people on the project team
adequate to do the job?
11. Do all customer/user constituencies agree on the
importance of the project and on the
requirements for the system/product to be built?
74
Risk Components & Drivers
1. Performance Risk- the degree of uncertainty that
the product will meet its requirements and be fit
for its intended use.
2. Cost Risk- the degree of uncertainty that the
project budget will be maintained.
3. Support Risk- the degree of uncertainty that the
resultant software will be easy to correct, adapt &
enhance.
4. Schedule Risk- the degree of uncertainty that the
project schedule will be maintained & that the
product will be delivered on time.
75
Risk Components & Drivers
Impact of each risk driver on the risk component is
divided into four impact categories
1. Negligible
2. Marginal
3. Critical
4. catastrophic
76
Category/ Performance Support Cost Schedule
Components
Catastrophic 1 Failure to meet the requirement would Failure results in increased cost & schedule delays
(1) result in the mission failure with expected values in excess of Cost & size
Marginal 1 Failure to meet the requirements would Costs, impacts and/or recoverable schedule slips
(3) result in degradation of secondary mission with expected value of cost and size
2 Minimal to small Responsive Sufficient financial Realistic achievable
reduction in technical software support resources schedule
performance
Negligible 1 Failure to meet the requirement would Error results in minor cost and/or schedule impact
(4) create inconvenience or nonoperational with expected value less than size and cost
impact
77
Risk Projection
It is also called risk Identification and it is used by two
ways
78
Steps of Risk Projection
1.Establish a scale that reflects the perceived probability
of risk
2. Delineate the consequences of the risk
3.Estimate the impact of the risk on the project and the
product
4.Note the overall accuracy of the risk projection so that
there will be no misunderstandings
79
Risk Projection : Develop Risk Table
Risk table provides a project manager with a simple
technique for risk projection
Risks Category Probability Impact RMMM
80
RMMM:
Risk Mitigation, Monitoring & Management
81
Risk Mitigation
For Risk Mitigation (improvement) following steps
will be taken
1. Meet with current staff to determine causes for
turnover like poor working conditions, low pay,
competitive job market etc.
2. Mitigate those causes that are under our control
before the project starts.
3. Once the project commences, assume turnover will
occur & develop techniques to ensure continuity
when people leave.
82
Risk Mitigation
4.Organize project teams so that information about each
development activity is widely dispersed.
5.Define a documentation standards and establish
mechanism to ensure that documents are developed in
a timely manner.
6. Conduct peer reviews off all work.
7. Assign a backup staff members for every critical
technologist.
83
Risk Monitoring
Project tracking with following primary activities
1. Assess whether predicted risk
2. Assure about risk aversion
3. Collect useful information for future risk
84
Risk Monitoring
For monitoring risks, and in case of high turnover
following factors should be monitored
1. General attitude of team members based on project
pressure.
2. The degree to which the team has jelled (shape-up).
3. Interpersonnel relationship among team members.
4. Potential problems with compensation and benefits.
5. The availability of jobs within the company and outside it.
85
RMMM
Risk Management must be included in software
project plan or apply separate RMMM Plan
RMMM Plan documents all work performed as a
part of risk analysis and is used by the Project
Manager as a part of overall project plan.
Some team focus on RIS (Risk Information
Sheet)instead of RMMM.
RIS is maintained using database system so creation
entry, priority order, searches and other analysis
takes place.
86
RIS
Risk Id, Date, probability and Impact
Description
Refinement/Context
Mitigation/monitoring
Management
Current status (Include Date)
Originator and Assigned
87
Risk Management Steps
Risk management model
Risk Identification
Risk
Assessment Risk Analysis
Passive
activity
Risk Risk Prioritization
Management
Check Lists
Risk
Decision Driver Analysis
Identification
Assumption Analysis
Decomposition
Identification of Risk
Risk identification consists of listing all of the risks that can adversely
affect the successful execution of the project.
Identifying risk early provides the management with a lot of time to
efficiently handle the risks.
Risk identification is a systematic attempt to specify threats to the
project plan.
By identifying known and predictable risks, the project manager takes
a first step towards avoiding them when possible and controlling them
when necessary.
One method for identifying risks is to create a risk item checklist.
Analysis of Risk
1. Risk analysis is the next task that involve the subjective analysis of the risks
identified.
2. Risk analysis can be done by estimating the worst case value of the size and all the
cost drivers and then estimating the project cost from these values.
3. Using the worst case effort estimate, the worst case schedule can easily be obtained.
4. The other approaches for risk analysis includes studying the probability and the
outcome of possible decisions (decision analysis).
5. Understanding the task dependencies to decide critical activities and the
probability and cost of their not being completed on time (network analysis).
6. Risks on various quality factors for reliability and usability (quality factor analysis).
7. Evaluating the performance early through simulation, etc. if there are strong
performance constrains on the system (performance Analysis).
Prioritize the Risks
The purpose of this step is to answer the following questions and
initiate any immediate action that might be required:
Is this a previously reported defect, or is it new?
What priority should be given to fixing this defect?
What steps should be taken to minimize the impact of the defect prior to a
fix? For example, should other users be notified of the problem? Is there a
work-around for the defect?
A suggested prioritization method is a three-level method, as follows:
Critical: Would cause the software to stop.
Major: Would cause an output of the software to be incorrect.
Minor: Something wrong, but it does not directly affect the user of the
system, such as a documentation error or cosmetic GUI error.
Respond to Risks
1. Next step is to respond to the risk based on prioritization
of risk
2. which involve identification of solution of the risk
3. Management people with an expertise involve in this
process.
Resolve, Monitor and Managing the Risks
Plans are developed for each identified risks that needs to be controlled.
Many risks might be combined together for the purpose of planning,
if they require similar treatment. A basic risk management plan has
five component.
1. Why the risk is important and why it should be managed;
2. What should be delivered regarding risk management and when
3. Who is responsible for performing the different risk management
activities.
4. How will the risk be adopted or the approach be taken.
5. How many resources are needed.
Risk Management Planning & Monitoring
RM planning
Milestone Tracking
Top-10 Tracking
Risk
Monitoring
Risk reassessment
Corrective Action
Monitoring the Risks
Risk monitoring is the activity of monitoring the status of
various risks and their control activities.
Like project monitoring, it is performed through the entire
duration of the project like many monitoring activities, a
checklist is useful for monitoring.