1 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Managing a...
-
Upload
tamsyn-cain -
Category
Documents
-
view
215 -
download
0
Transcript of 1 / 48 ©Jozef De Man 2008-2009 Managing a small Software Project A quick Guide ed 2 Managing a...
Managing a small Software ProjectA quick Guide ed 2
1 / 48©Jozef De Man 2008-2009
Managing a small Software ProjectA quick Guide
Prof. Dr. ir J. De Man
Managing a small Software ProjectA quick Guide ed 2
2 / 48©Jozef De Man 2008-2009
Introduction
This is a quick guide to project management for small sofware projects.It is a light-weight interpretation of general project management practices tailored to the specific needs of software projects.This is an adaptation of the Capability Maturity Model Integration (CMMI) for Development edition 1.2.http://www.sei.cmu.edu/cmmi/
Software development is not only a technical activity requiring technical skills but also a business activity requiring (project) management skills
Managing a small Software ProjectA quick Guide ed 2
3 / 48©Jozef De Man 2008-2009
Content
A few words about: Process Model – CMMI Development Model – Agile
What is a project?
Process Areas Measurements Requirements Management Project Planning / Monitoring and Control Quality Assurance Configuration Management Risk Management Process Improvement
Managing a small Software ProjectA quick Guide ed 2
4 / 48©Jozef De Man 2008-2009
CMMI Staged Representation5 Maturity Levels
22Managed
Projects haveDisciplined
Process
33Defined
OrganizationalStandardProcess
44QuantitativelyManaged
Measured,Predictable
Process
55Optimizing
ContinuouslyImprovingProcess
A Maturity Level is assigned toan organization and is anevolutionary plateau in process maturity
Practices at a lower level must beestablished to enable practices at
a higher level to be efficient and effectivehttp://www.sei.cmu.edu/cmmi
11Initial
Ad hocChaotic
Managing a small Software ProjectA quick Guide ed 2
5 / 48©Jozef De Man 2008-2009
CMMIProcess Areas by Maturity Level (Staged)
Requirements Management*Project Planning*Project Monitoring and Control*Supplier Agreement ManagementMeasurement and AnalysisProcess and Product Quality Assurance*Configuration Management*
2 Requirements DevelopmentTechnical SolutionProduct IntegrationVerificationValidationOrganizational Process Focus*Organizational Process Definition + IPPDOrganizational TrainingIntegrated Project Management + IPPDRisk Management*Decision Analysis and Resolution
3
Organizational Process PerformanceQuantitative Project Management
4 Organizational Innovation and DeploymentCausal Analysis and Resolution
5
Process Areas at lower levelmust be addressed beforeProcess Areas at higher levels
IPPD = Integrated Product and Process Development
*Process Areas addressed in this guide
Managing a small Software ProjectA quick Guide ed 2
6 / 48©Jozef De Man 2008-2009
CMMIGeneric Goals and Practices
Generic Practices to be applied to EACH process area GP2.1 Establish an organizational policy GP2.2 Plan the process GP2.3 Provide resources GP2.4 Assign Responsibility GP2.5 Train people GP2.6 Manage Configurations GP2.7 Identify and involve relevant stakeholders GP2.8 Monitor and control the process GP2.9 Objectively evaluate adherence GP2.10 Review status with higher level management
Stakeholder = individual or group affected by or accountable for the outcome of an activity
Policy = guiding principle, typically established by higher management
Managing a small Software ProjectA quick Guide ed 2
7 / 48©Jozef De Man 2008-2009
http://agilemanifesto.org/
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation
Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Kent BeckMike Beedle
Arie van BennekumAlistair Cockburn
Ward CunninghamMartin Fowler
James GrenningJim HighsmithAndrew HuntRon Jeffries
Jon KernBrian Marick
Robert C. MartinSteve Mellor
Ken SchwaberJeff SutherlandDave Thomas
We still value the items on the right
Managing a small Software ProjectA quick Guide ed 2
8 / 48©Jozef De Man 2008-2009
What is a Project?
Delivers one or more products/services to a customer
Has a definite beginning and end
Involves interacting resources (people, tools, material)
Typically operates according to a plan, specifying The product(s) to be delivered The work to be done The required resources and funds The schedule for doing the work
Managing a small Software ProjectA quick Guide ed 2
9 / 48©Jozef De Man 2008-2009
ProjectBasic Decision Gates
StartGate
CommitGate
EndGate
Planning Execution
Develop Business CaseVision Statement
Define RequirementsManage Risks
Develop initial planCommit Adequate Resources
Is there a business case with acceptable risk to
continue with the project?
Is the product ready for delivery to the customer?
Initiation Closure
Managing a small Software ProjectA quick Guide ed 2
10 / 48©Jozef De Man 2008-2009
Four essentialDimensions
Scope
Cost
Schedule
Quality
FunctionalRequirements
Non-FunctionalRequirements • What is the order of priority?
• What are the targets?• Which dimensions are fixed?• Which dimensions can be renegotiated
during the project?
Managing a small Software ProjectA quick Guide ed 2
11 / 48©Jozef De Man 2008-2009
Measurement and AnalysisGlobal Performance
Priorities along schedule, cost, scope and quality are based on business objectives defined by higher management
Metrics must be defined to quantitatively express performance along these four dimensions (key performance indicators), e.g.
Schedule overrun = actual duration – planned duration
Margins must be defined within which the project must be managed, e.g.
Schedule adherence < 1 week
Estimates of the key performance indicators (KPIs) are maintained during the project and higher management must be asked to intervene if the project is estimated to go beyond one of the margins
Managing a small Software ProjectA quick Guide ed 2
12 / 48©Jozef De Man 2008-2009
MeasurementsQuality
Also non-functional requirements of the product must be documented and expressed quantitatively
Examples: Coverage of test cases in terms of features and code Number of test case executed and passed Number of known, unresolved defects in the product
Performance against quality targets is an aspects determining readiness for delivery of the product to the customer
Managing a small Software ProjectA quick Guide ed 2
13 / 48©Jozef De Man 2008-2009
MeasurementsKPI Examples
Schedule Overrun Actual duration – Planned duration
Budget Overrun Actual effort spent – Original budgeted effort
Feature Churn # features added/deleted during execution
Quality # test cases passed successfully / # test cases planned
Managing a small Software ProjectA quick Guide ed 2
14 / 48©Jozef De Man 2008-2009
MeasurementPractical Guide
Derive metrics from goals Identify goals of the project Identify simple metrics to quantify the goals Define mechanisms to collect/report measurements Do it
Remember Metrics must be useful Keep it simple
Managing a small Software ProjectA quick Guide ed 2
15 / 48©Jozef De Man 2008-2009
RequirementsTypes
Functional requirements Describe the functionality of the system Typically expressed in terms of nouns and verbs
Non-functional requirements Describe properties of the system and its actions Typically expressed in terms of adjectives Include the “-ilities” of the system
Constraints Are externally imposed and cannot be negotiated, e.g. legal
obligations
Managing a small Software ProjectA quick Guide ed 2
16 / 48©Jozef De Man 2008-2009
RequirementsActivities
Elicitation - identify sources of requirements and obtain requirements
Documentation - write down the requirements in a way that is understandable for all stakeholders
Negotiation - reconcile conflicting interests of stakeholders
Classification - identify (hierarchical) relationships, taxonomy, traceability, priority,…
Analysis - understand the requirements, identify possible conflicts, overlaps, ambiguities
Allocation - to components of the product/solution
Modeling - abstract representation supporting formal analysis
Managing a small Software ProjectA quick Guide ed 2
17 / 48©Jozef De Man 2008-2009
Requirements DocumentationHierarchy/Granularity
Vision - One page general description of the objectives and scope to provide a common direction to the entire team
Feature/Requirements List - Index with one sentence for each requirement to serve as a basis for classification
Requirements Specification - detailed specification of each requirement (e.g. detailed specification of protocols)
Managing a small Software ProjectA quick Guide ed 2
18 / 48©Jozef De Man 2008-2009
Requirements DocumentationFeatures
The definition of the product must be broken down in “features”
Features are more or less independent characteristics of the product
It must be possible to implement features incrementally To develop value as quickly as possible To enable tracking of progress To enable renegotiation of scope during project
Managing a small Software ProjectA quick Guide ed 2
19 / 48©Jozef De Man 2008-2009
Requirements DocumentationFeature List
Features are documented in a Feature List which is maintained during the course of the project
The initial Feature List documents the “target” for scope
A Feature List involves for each feature Name Description Cost Estimate (rough estimate - high,medium,low) Customer Value Estimate (need-to-have, nice-to-have) Risk level (level of uncertainty of feasibility/cost) Dependencies on other features Project increment/iteration
Managing a small Software ProjectA quick Guide ed 2
20 / 48©Jozef De Man 2008-2009
Requirements ManagementTraceability
Establish a simple mechanism to maintain traceability from requirement to implementation
Examples Features > Code Modules Features > Test Cases Bug reports > affected items
The goal is to answer questions like What is the test coverage of a feature? Is a feature completely implemented? Have all corrections associated with a bug report been
implemented?
Managing a small Software ProjectA quick Guide ed 2
21 / 48©Jozef De Man 2008-2009
Project PlanningAssign Responsibility
Project Manager
But also Requirements/Feature Manager Development Manager, Test Manager Build / Configuration Manager Quality Manager Process Improvement Manager Risk Manager Measurements Manager
NotesSeveral roles can be performed by one personRoles must be assigned early in the planning phase
Managing a small Software ProjectA quick Guide ed 2
22 / 48©Jozef De Man 2008-2009
Project PlanningIterations
The execution of a project happens in iterations/increments
Essential characteristics of each iteration Period (duration) Available Resources Features to be implemented
StartGate
CommitGate
EndGate
Planning Execution
Iteration1
Iteration3
Iteration2
……….
Managing a small Software ProjectA quick Guide ed 2
23 / 48©Jozef De Man 2008-2009
Project PlanningIdentify Activities / Work Products
Consider mainstream Requirements, feature lists, design artefacts, code modules,
test cases, …
But also supporting functions Build / Configuration Management of code and documents Risk Management Planning and Monitoring Requirements Management Measurement and Analysis Quality Assurance of Product and Process Process Improvement / Definition Training
Managing a small Software ProjectA quick Guide ed 2
24 / 48©Jozef De Man 2008-2009
Project PlanningIdentify attributes of activities / work productsA few examples:
Reviews Duration Number of participants Frequency “Size” – number of slides in presentation
SW Build Effort Duration Frequency Required resources
Managing a small Software ProjectA quick Guide ed 2
25 / 48©Jozef De Man 2008-2009
Project PlanningEstimate attribute values and cost
For example for reviews Duration 1 hour Number of participants 5 Frequency monthly Number of slides in presentation 20
Derive estimated of required effort Effort spent in meeting + preparation
Notes: Estimates tend to be more accurate if “objective” attributes
are identified first and required effort is derived based on attribute values
Accuracy of initial estimates may be low
Managing a small Software ProjectA quick Guide ed 2
26 / 48©Jozef De Man 2008-2009
Project PlanningScheduling
Consider for the first increment Available effort budget Estimated period Effort for supporting functions
And determine the features to be implemented in the first iteration based on
Customer value, estimated cost, risk
Negotiate and obtain commitment on resources based on Project Requirements Available skills Personal interest
Managing a small Software ProjectA quick Guide ed 2
27 / 48©Jozef De Man 2008-2009
Project Monitoring and ControlMonitoring
Monitoring the project involves Keeping people aware of their commitments Verifying actual performance against plan Adapting the plan as required Improving the way of working based on experience gained in
the project (and previous projects)
To enable this, it is essential that mechanism are established to monitor actual performance versus the original plan
Managing a small Software ProjectA quick Guide ed 2
28 / 48©Jozef De Man 2008-2009
Project Monitoring and ControlCorrective Actions
Monitor performance at the level of the attribute values
E.g. for project reviews Actual duration, frequency, number of participants, size
If actual performance deviates from the plan it is now possible to take corrective action at the process level and adjust either the plan or actual performance at the attribute level
You can propose changes in the attribute values and get accurate estimates for the impact on performance assuming the other values will not change, e.g.
Change frequency, content, duration, # of participants
Managing a small Software ProjectA quick Guide ed 2
29 / 48©Jozef De Man 2008-2009
Project Monitoring and ControlProject Review/Meetings Types
Decision Reviews at Decision Gates to decide Go / No Go for project at Commit Gate Delivery of product at End Gate
Iteration Reviews between iterations to accept end of previous iteration and decide to start the next iteration
Kick-off meetings with the entire team at the beginning of the project or an iteration
Periodic Meetings Team meetings Progress reviews at project level Reviews with higher Management / External Stakeholders
Managing a small Software ProjectA quick Guide ed 2
30 / 48©Jozef De Man 2008-2009
Project Monitoring and Control – Decision GatesCommit Gate Checklist - sample
Feature List available? Risk repository available, risks analyzed and risk handling
actions planned? Targets established for features, quality, schedule and
budget? Are the “boundary conditions” for the project team
established? Initial Plan available
Responsibilities Activities / Work Products, their attributes and estimates Schedule Allocation of resources to activities / work products committed
Are the risks acceptable to proceed?
Managing a small Software ProjectA quick Guide ed 2
31 / 48©Jozef De Man 2008-2009
Project Monitoring and Control - Decision GatesEnd Gate Checklist - sample
Are all committed features implemented? Does the product meet its quality targets? Is the business case still valid? Are all legal and regulatory issues resolved? Are plans and resources in place to support the product? Are the risks acceptable to deliver the product to the
customer?
Managing a small Software ProjectA quick Guide ed 2
32 / 48©Jozef De Man 2008-2009
Project Monitoring and ControlIteration Reviews
Goals Verification committed targets have been met Risk (re-)assessment Lessons-learned: what did we do well?
What can be improved? Keep focus
At iteration reviews Process changes can be introduced The Feature List can be updated The project plan is revised
Managing a small Software ProjectA quick Guide ed 2
33 / 48©Jozef De Man 2008-2009
Project Monitoring and ControlProject/Iteration Kick-Off
Goals Re-enforce a common vision Higher management to demonstrate its commitment to the
project
Entire project team and higher management are invited
Project Management presents Vision Features Quality targets Schedule The process to be followed
Managing a small Software ProjectA quick Guide ed 2
34 / 48©Jozef De Man 2008-2009
Project Monitoring and ControlProject/Team Meetings
Goals Review progress Identify issues and take action to resolve them Decide on escalation of issues if required
Format Weekly meetings with project team to review overall
progress Daily Team meetings (Scrum meetings) for fast direct
communication and avoid delays associated with email
Managing a small Software ProjectA quick Guide ed 2
35 / 48©Jozef De Man 2008-2009
Project Monitoring and ControlManagement Reviews
Goal Provide higher management visibility on project progress Obtain commitment for actions that are beyond the
responsibility of the project team
Typical content Key features Latest estimate of project in terms of schedule, cost, scope
and quality Main achievements Issues that require higher management attention Next steps
Managing a small Software ProjectA quick Guide ed 2
36 / 48©Jozef De Man 2008-2009
Project Monitoring and ControlData Management - Establish a Project Portal
It is important that all members of the project have instant access to the latest edition of data relevant to the project
Feature List Risk List Action Points Planning / tracking Meeting minutes …
A “Project Portal” must therefore be established to manage project data and support efficient communication
The portal must also refer to the Process Assets Library of the project
Managing a small Software ProjectA quick Guide ed 2
37 / 48©Jozef De Man 2008-2009
Quality AssuranceProduct and Process
Product Quality Assurance Actions to ensure and verify that the quality requirements of
the product are satisfied These actions are typically performed as part of the
“mainstream” project: document reviews, testing activities at various levels.
Process Quality Assurance Actions to ensure and verify objectively that actions for
product quality assurance are executed as planned and effective
These actions are typically performed by a separate Quality function to ensure objectivity
Managing a small Software ProjectA quick Guide ed 2
38 / 48©Jozef De Man 2008-2009
Quality AssuranceQuality Manager Role
Ensure that the Project Manager not only considers schedule and content but also quality
Monitors whether the process (agreements made in the project) is followed and analyzes deviations
Coaches project members in the process
Considers adjustments of the process if required
Report quality issues to senior management
Managing a small Software ProjectA quick Guide ed 2
39 / 48©Jozef De Man 2008-2009
Configuration ManagementOverview
Configuration Management involves Identification of items to be placed under CM Establishing a repository for items (code, test cases,
requirements, technical and project documents,..) Ensuring the most current version of each item is available Managing changes to items in an efficient and controlled
fashion Audit integrity of the configurations, e.g. have all approved
changes been implemented?
Managing a small Software ProjectA quick Guide ed 2
40 / 48©Jozef De Man 2008-2009
Risk ManagementUncertainty
A project faces many uncertainties Feasibility of implementation Volatility of the requirements Accuracy of effort estimates Availability of resources Dependencies on external partners ….
A risk is a potential problem that has not yet turned into an actual problem
Risk Management deals with risks and not with problems
Managing a small Software ProjectA quick Guide ed 2
41 / 48©Jozef De Man 2008-2009
Risk ManagementPurpose
Before Commit Gate Identify risks Plan risk handling actions Plan for risk reduction during the execution of the project
E.g. implement high-risk features first Establish adequate visibility on risk as input for decision
During Execution Monitor risks and re-assess periodically Monitor and replan mitigation actions as required Take corrective actions if risks materialize as problems
Managing a small Software ProjectA quick Guide ed 2
42 / 48©Jozef De Man 2008-2009
Risk ManagementRisk Register
Risks and related attributes are maintained in a risk register
Risk Attributes Likelihood of occurrence Number of occurrences (optional) Impact/cost of occurrence Cost/Impact of actions
Risk ranking is used to select type of action
Managing a small Software ProjectA quick Guide ed 2
43 / 48©Jozef De Man 2008-2009
Risk ManagementRisk Statement
A well-written risk statement facilitates risk management
It typically contains two components: A condition An undesirable effect cause by that condition
To be a risk, the condition must not yet be satisfied, otherwise it is a problem
Managing a small Software ProjectA quick Guide ed 2
44 / 48©Jozef De Man 2008-2009
Risk ManagementActions
Avoidance Take action to reduce the likelihood that the risk materializes
Mitigation Take action to reduce the negative impact of a risk in case it
materializes
Nothing Accept the risk
Managing a small Software ProjectA quick Guide ed 2
45 / 48©Jozef De Man 2008-2009
Process DefinitionEstablish a “Process Assets Library”
A “Process Assets Library” is the all information that enable project members to perform their tasks more efficiently and effectively
In includes Templates for documents (e.g. the risk list) Templates for meeting presentations, reports Standards (e.g. rules for configuration management, naming
conventions, coding rules,…) Procedures (e.g. how build the product) User guides for tools Recommended attributes of activities (frequency of reviews,
duration of reviews,…) …
Managing a small Software ProjectA quick Guide ed 2
46 / 48©Jozef De Man 2008-2009
Process Improvement
You must continuously improve your way of working
This must happen in a controlled fashion Project members must follow agreed rules Everybody can submit proposals for improvements Proposals are evaluated, approved and implemented quickly New rules must only be followed after agreement
Recommendations Take time to discuss and agree improvements at project
meetings Communicate changes (e.g. via kick-off meetings) Document changes in the Process Assets Library Share improvements with fellow project
Managing a small Software ProjectA quick Guide ed 2
47 / 48©Jozef De Man 2008-2009
Process ImprovementTwo Levels
Organization Lessons-learned in projects, appraisals of the process and
other inputs are used to document improvements for use by later projects (organizational learning)
Project If a project is executed in iterations, lessons learned in an
iteration can be used for improvements in the next iteration Iteration Reviews must be used to evaluate possible
improvements and decide whether they can be applied immediately
Process Improvements must be clearly communicated to all members
Managing a small Software ProjectA quick Guide ed 2
48 / 48©Jozef De Man 2008-2009
SummaryKey Points
Perform Software development as a PROJECT
Deliver a functioning product early and frequently
Keep focus on the customer
Ensure efficient and effective communication between all stakeholders
Stick to a common way of working and continuously improve it