Software Project Management
Software is everyday more present in any activity, and even more will be in the future.
We can say: We will need more and more software.
- Well educated developers (technically and socially).
- Better engineering (usage of a process, continuous process improvement, helping tools)
- Appropriate Technologies (object oriented programming, components)
- Reuse (of processes and programs)
From IEEE glossary:
"Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system"
So, the software is not only a program with it’s own data, but also the world of informations around it, preceding the software (requirements, specification, models…) and following it (documentation).
Software have as target:
- a particular customer
- general market
and can be developed:
- as a new project,
- as a configuration of something already done,
- using parts of a previous work.
Software is a systematically developed technological product characterized by a defined set of properties.
From IEEE glossary:
"A combination of computer instructions and data definitions that enable computer hardware to perform computational or control functions"
A program is the main part of a software, when we have only a program we have a legacy software.
Software is not the same engineering product, it has some particular property:
- software is immaterial
- common sense cannot always help
- a metaphor as software maintenance can be misleading
- a copy is not different from the original (but the original is still there in the shop!! It is different from stealing!)
- software is not build but developed
- reuse is attractive if effort for reusing is limited
- often developers (1) overestimate own capacity or (2) underestimate project complexity (or both!).
- software building blocks are immaterial
- used languages influence software properties
- software is a complex product
- costs are necessary hight
- software reflect reality
- based on a model of reality
- must change with it
- is no a linear function
- hard to test
"The software should deliver the required functionality and performance to the user and should be maintainable, dependable and acceptable
|Maintainable:||software must be modifiable to follow reality evolutions|
|Dependable:||we want to trust software|
|Efficient:||efficient resource usage|
|Acceptable:||must be accepted by the user, so must be understandable, usable and compatible with other customers systems.|
"Software engineering is an engineering discipline that is concerned with all aspects of software production"
… or better software development.
Software engineering should take a systematic and organized approach, use tools and techniques tailed to the problem and to system limits and available resources.
From IEEE glossary:
- The application of a systematic, disciplined, quantifiable approach to the developement, operation and manteniance of software; that is, the application of application engineering to software.
- The study of approaches as in (1)
Something very abstract, Prof. suggests:
"Software engineering is any activity for developing or modifying software"
As any other engineering activity, we have to:
- cost is the most important factor
- standard exists to be used
- modularity is good
- support quality.
We want to produce successful software.
So, both software and process must be:
but problem arise because of:
- complexity of algorithms and hard understandability of programs
- quantity is a crucial factor, we must use abstraction.
"Structured approaches to software developement which include system models, notation, rules, design advice and process guidance"
Software engineering use:
- graphical models to describe the system
- well defined rules
- hints for best practices
- process guidance, step to step
Methods, Languages e Tools connected by common concepts.
Methods are: OOD, OOH, refactoring, …
Languages: Java, UML, C++, …
Tools: R. Rose, Eclipse, Poseidon, …
concepts are: objects, messages, inheritance, classes, …
Every software is developed in steps, every step represents wishes.
Components are tested individually, then throughout the integration following a predefined structure we have the final product.
Software is put in operations, and modified or corrected according to the needs.
At the end of the life cycle can be a retirement or substitution phase.
Time lapse from the conception to the retirement of software.
Software life consists of some default phases: concept, requirements, design, implementation, test, installation and checkout, operation and maintenance, and sometime retirement or substitution.
|Top level design|
|Coding e test|
|Integration, test, Acceptance|
- Which are customers problems?
- How can software help solving them?
- Which are main software functionality?
- Which are software requirements?
Requirements are the contract between customer and developer.
Requirement Specification is the foundation of the following development, so must be well done.
(better stressing the customer 20 times before, to be sure having the right idea, then arguing later)
- Define software components.
- Design architecture.
- Define interfaces between components.
- Define components functionality.
Design produces Software Architecture
When components are coded, it’s time to test.
- Every component is tested following the specification (unit test).
- Identified errors are corrected.
This phase ended with coded and tested components.
- Components are assembled following the architecture.
- Interfaces are tested (integration test).
- Acceptance Test verify software and customer environment compatibility.
This phase end with the (delivered system).
This phase starts with the system installation in the client environment and the subsequent putting in operation.
The Maintenance phase consists in the correcting of errors arose during installation and subsequent use.
Software is immutable in an evolving reality, so it can be old.
We have to start thinking of a substitution with some advance:
Quality ^ | ' ' ' | * *'* ' ' + | * ' * ' * * ' + | * ' * ' * * ' + | * ' * ' * * ' + | * ' * * * + | * ' ' ' +* | * ' ' '+ * |* ' ' + ----------------o---------------o----------------------o-------------------> Time Developement Maintenance Reeginering New Developement
Software engineering costs vary depending on:
- type of system
- requirements (performance, quality, reliability, …)
Cost distribution depends on the model used, but in general:
|60% Developement||40% Test|
|in waterfall model:|
- 60% Developement
- 15% Specification
- 25% Design
- 20% Implementation
- 40% Integration & Test
|in iterative development:|
- 10% Specification
- 60% Iterative developement
- 30% System test
|in component based development:|
- 20% Specification
- 30% Components development
- 50% Integration and test
- Software is a complex product (tell it to the customer).
- Software properties make development hard (see over).
- Software must be developed in a systematic manner => Software Engineering.
- Software use languages, tools and methods based on common concepts.
- Software development is a stepwise process (activities and phases).
Project management connects and coordinates any activity in the project development:
___________ Documents _______________ / Quality \ <--------------- / Configuration \ \ Assurance / | and Change | ´´´´´´´´´´´ >--------. \ Management / ^ Reports _\____________ ´´´´´´´´´´´´´´´ | / System \ ^ | \ Construction / | Plan \ ´´´´´´´´´´´´´´ | Data Plan \ Y / Data \ ________________________ / Achievement \_\ | |\ <-' Data / | Project Management | | |______________________| | \______________________\|
A project is a set of activities, interactions and results aimed at achieving a defined goal, provided limited resources and limited time.
Or by Kerzner 2002:
"Any series of activities and tasks that have a specific objective to be completed within certain specification, have a defined start and end dates, have founding limits (if applicable) and consume resources (money, people, equipment, …)"
A project is defined by a temporary limited and unique task that provide answers to the following questions:
- What? – Define goals.
- When? – Time: start, end.
- Who? – Teams.
- Whereby? – Resources.
- How? – Project organization and model.
- Manager: responsible of the development project (from inside).
- Team members: Analyst, Architect, Programmer, Tester, Configuration Manager, Reviewer, …
- Client/Customer: Placer orders, decide and accept.
- Users: yes… involve them.
- Development Organization: place, cafè, hardware, contracts, …
We have mainly three kinds of project:
- Internal project: client and developers are part of the same organization, software will be used internally and conflicts are solved by the chief.
- Ordered project: client and developer agree on a contract, conflicts may be solved juridically.
- Development project: client is the marketing division, and product is offered and sold by the company, money came from a development budget.
Often a project is a mixture of these three kinds.
A task oriented definition could be (Thayer 1987):
"A system of procedures, practices, technologies and know-how that provides the planning, organizing, staffing, directing and controlling, necessary to successfully manage an engineering project."
A goal oriented definition could be (Sommerville):
"Concerned with activities involved in ensuring that software is delivered on time and within budget and in accordance with the requirements of the organizations developing and procuring the software."
Projects mainly fail because of:
- improper management
- fixation of first estimate
- wrong level of details
- first-time-seen tools
- too many people
- poor communication
- rewarding the wrong actions
IT projects fail too because of:
- ill-defined or changing requirements
- poor planning / management
- uncontrolled quality
- unrealistic expectation / inaccurate estimate
- naive adoption of a new technology
Problems are the same:
- software is immaterial
- there is no standard process
- experience transition is difficult (better having a superposition lapse with two project managers)
- start coding without analysis
- do not define requirements and quality goals
- do not follow a process model
- set unrealistic deadlines (knowing that)
- use first-time-seen tools
- do not manage risks
- do not check project deliverables
- do not test systematically
- small teams
- risk management
- good manager
- good communication
- right person for the right work
- clear requirements
- user involvement
- realistic and up-to-date schedule
We want to: Produce all deliverables with required quality within time and resources.
We’d like also to:
- give a positive impression
- acquire know-how
- think reusable
- keep an attractive working environment (Google balloons)
Project management activities are mainly four:
Project management areas are:
- Scope – how much?
- Work – what?
- Quality – how?
- People – who?
- Risk – what if?
- define goals
- analyze environment
- structure tasks/activities to be performed
- panning quality issues
- preparing the schedule
- planning resources
- planning costs and budget
- planning risk management
- define roles
- delegate authority and responsibility
- set up a communication structure
- select people
- engage a team
- promoting people
- motivate people
- solve conflicts
- release the team
- define measures to control quality, deadlines, resources and costs
- measure project progresses
- identify the risks
- evaluate the risks
- define mitigation and contingency measures
Project manager needs:
- procedures to measure project progress
- procedures to estimate costs
- procedures to plan activities, schedule, …
- to understand the development process
- to have realistic estimation if own abilities
- to have experience
- to work in an appropriate environment
To do this, a good project manager should have:
- Technical skills (rised from the ranks)
- economical, application, software engineering, …
- Project management skills
- planning, estimating, controlling, time-managing, negotiating, …
- Leadership skills
- communication, decision, delegation, motivation, moderation, …
- Personal skills
- responsibility, toughness, team spirit, patience, ability to communicate, fairness, …
- experience and education
- learning by doing school
- expectation of senior management
- no time, no personnel, …
- expectation of the client
- specify better, with the client…
- team members
- they should work systematically, follow standards, documents results
- own demand
- management and technical work
Project development is a continuous activity, composed of three phases regardless the model used:
- Initial phase
- Final phase
Time from the order to the start of development.
- defining scope
- planning project
- analyzing the environment
- setting up structures and information for the project running
Deliverables are produced according the plan, every phase is financed individually and structured following a process model.
The project is finished in a controlled manner, tasks to be performed after the project end are identified and assigned.
Experience is collected and documented.
Rough plot of resource distribution:
Required resources ^ | ' * * ' | ' * * ' | ' * * ' | ' * * ' | *' *' | * ' '* | * ' ' * | * ' ' * | * ' ' * -------------------o-----------------------------o---------------------> Time Initial phase Development phase Final phase Planning Controlling Terminating
Project management is a prerequisite for a successful project and must be a whole time continuous activity.
Main tasks of project management are:
- team management
- risk management
Project managers must have the right skills (social, technical, …)
A project must follow a structured path:
- starting phase
- development phase
- final phase
In the initial phase the project manager has to define the project goals, estimate resources (personnel and skills), estimate costs and time, identify risks and provide a communication and work infrastructure.
Sometime when costs and deadline are known, project manager must plan backwards.
At first we must define all projects goals and deliverables working in co-operation with the customer.
Then we have to evaluate the first draft, assessing the technical feasibility and economics factors as Return On Investments.
We start then planning the project, the project definition phase consists of:
- defining project organization,
- assigning responsibilities
- identifying risks
We have to communicate pertinent information to all stake-holders.
And we have always to remember, in any project, at any time, we have the no-go option!
Initial phase begins when:
- a customer asks a quotation based on a tender document.
- Somebody has a product idea
Someone (project manager) has to collect enough information for a sensible go/no-go decision, money and time needed for this phase are usually a development organization effort.
Initial phase ends when:
- we start the project
- we decide not to go.
Rough graph of uncertainty in the project:
HIGH ^ Uncertainty | ' ' | * * * *' * . ' | Rough Goal * ' | ' * ' | ' * | ' Project ' * | Pre-Study ' Definition ' * | ' ' * | ' ' * . | ' ' * * * * * LOW |------------o------------o-------------------------------> Time Initial Phase Planning, Execution, ...
A project goal is everything the project has to produce and deliver.
All stake-holders have to be involved in the goals definition phase.
Good projects have:
- Precise goals and requirements
- Quantifiable goals
- Achievable goals
Goals can be contradictory, especially in big and complex projects.
Contradictions have to be identified and resolved, and project manager has to ensure the achievability of goals.
For example: Money, Quality and Time:
Time <---- \ \ O O O O ----> Quality O O / Costs / <------
All the goals form the definition sheet, sometime is useful include in the formulation non-goals too.
Goal: Write english docs.
non-Goal: Translate docs in other languages.
Scope management is the phase dedicated to defining and controlling what is included in the project and what is not.
We have to deliver all we have planned and nothing more.
Scope management ensure development is not late for wrong directed efforts.
Scope management has a mayor rule in backwards projects (defined deadline and costs).
At the end of this phase we have the Requirement Specification sheet.
Project scope can be subject of changes, enhancements, new requirements, errors, …
Any new information must follow a common path:
___________________ ( Technical impact, ) ( Budget, Market, ) ---------------- ( Schedule, ... ) | Request change | / ``````````````````` ---------------- ---> ---------------- * REJECT | Analyze change | / * POSTPONE ---------------- ---> ---------------- / | Decide change | ---------------- \ * ACCEPT -> Implement
- Motivation: Why? ROI, …
- Goals: goals, sub-goals, time, costs, quality
- Products & deliverables: What?
- Description: Tasks, cost estimation, Milestones
- Stake-holders & organization: customer, manager, team, controller, …
- Major Risks: results of an initial risk assessment.
- Is each goal is:
- defined explicitly and accurately?
- Important non-goals are defined?
- Contradictions are resolved?
- Schedule and budget estimation are realistic?
- Stake-holders accept goals and estimation?
- Important risks are identified and assessed?
Essential phase, we should make a sound go/no-go decision.
Initial phase (afters goals and scope definition) produces:
- project definition
- initial project plan
The initial phase consumes real resources.
Project planning is probably the most time-consuming activity in project management, it consists in a continuous activity from the initial concept to the system delivery, and must be revised as new information becomes available.
A plan is a model of the future, so it’s never correct, but we have to do our best to follow the plan.
If we do not plan we have no sound bases for:
- estimating duration and budget
- controlling what we have done and what is left.
Plans are more important in highly dynamical environment and if something is unclear.
What should we plan?
- Deliverables (quality)
- Resources (people and budget)
- Work (what, which order)
We have to answer the following questions:
- Why do we run the project?
- What do we have to do?
- How much money and other resources do we need?
- Who is doing what?
- When do we start and when are we finished?
From the IEEE glossary:
"A project plan is a document that describes the technical and management approach to be followed for a project"
Typically a plan describes:
- the work to be done,
- the resources required,
- the methods to be used,
- the procedures to be followed,
- the schedules to be met,
- and the way the project will be organized.
Different plans exist:
- Quality, Validation, Configuration, Management, Training, …
Activities are the unit of work in a project, if an activity is big, can be decomposed in sub-activities till reaching the atomic-activity level (activity that can be performed by a few people in a short time, with well defined inputs and outputs).
S.M.A.R.T properties of activities
- Specific: goal oriented.
- Measurable: we must measure progresses.
- Assignable: one responsible.
- Ralistic: on time and resources.
- Time related: deadline.
A work package is an activity that can be performed by a single person or a small group in 2-4 weeks. A work package must have clear (visible) results that can be checked against its requirements.
A work package memory is composed by:
- effort estimation
- actual cost
Work packages are a sort of contract between project manager and developers.
Estimation of global remaining efforts, controlling and work balancing are based on work packages.
Milestones are defined points in time during the project where defined results have to be available.
A milestone consists of:
- defined results
- quality attributes
- eventually an external milestone committee
Based on the quality perceived, the customer (steering committee) can decide to continue (staring a new phase) or cancel the project.
There are two common kinds of milestones:
- External (gate with go/no-go decision)
- Internal (controlling)
Before planning we have to identify every activity needed to reach our goals.
Experience shows that a graphical visualization can help.
The Work Breakdown Structure consists of a tree of activities of descending load, ending with atomic activities as leafs.
Activities are decomposed by phases and by components:
1. Project (1) ( Develop Software ) ------- / \ / / \ \ / \ / / \ \ 2. Main Tasks (1.1) (1.2) (Requirements) (Design) (Implementation) (Tests) ---------- / \ \ | : : : / \ \ | 3. Sub-Tasks (1.1.1) (1.1.2) (1.2.3) o- Interview with customer --------- : / \ : o- Create Req. Spec. : / \ : : 4. Work Packages (220.127.116.11) (18.104.22.168) -------------
Decomposition can follow a top-down approach:
Project + decomposition criteria => main tasks => work packages
or a bottom-up approach:
Activities are collected, a part-of relationship is defined, a WBS draft is drawn and then completed with missing activities.
We can check if a WBS is complete with two rules:
- Disjunction rule: all activities of a level must be completely distinct.
- Completion rule: any decomposition must cover every aspect of the parent activity.
We can check if an activity is truly atomic controlling if:
- we are able to measure the progress,
- start and stop dates are defined,
- we can estimate costs and duration,
- work can be performed independently from other activities.
A work package can be further decomposed in tasks in a subsequent planning.
At the end of the WBS we have to check for completeness/overload against the goals/non-goals.
The WBS are an important activity, that, if performed completely, can provide the basis for:
- cost estimation
- resource allocation
- project tracking e controlling
Better design a WBS chart jointly with all the team members:
- common understanding,
- common terminology,
- use synergies,
- motivate people,
- publicize overall project goals.
Once we have a complete WBS we have to find out and explicitate logical and temporal sequences between the activities.
We have to do:
- precedence planning,
- duration estimation.
We have some method at different deepness to clarify the situation.
|Milestone list:||A simple list of the most important events and related functionalities.|
|Bar chart (Gantt chart):|
|Every activity has a start and end time, the resulting bar is placed on a calendar.
Precedences and time overlapping activity are clearly visible.
|Activity network plan:|
|Same as Bar chart, but is possible to express also logical precedences between work packages.
On an Activity network plan is possible to find out easily the critical path in the project.
The critical path in a project is a sequence of non overlapping activities that, if delayed, imply all the project is delayed.
As for a recipe:
- set water and salt of the ring
- make the sauce
- when water boils, put pasta
- wait past is "al dente", put out water and put in sauce
… and eat!
we can estimate the duration of the activities:
- set water and salt of the ring: 1 min, no dependencies
- make the sauce: 5 min, no dependencies
- when water boils, put pasta: 10 min, can-start-if-done set water and salt of the ring
- wait past is "al dente", put out water and put in sauce: 10 min, can-start-if-done when water boils, put pasta, and can-stop-if-done make sauce.
in this case the critical path is:
- set water and salt of the ring (1)
- when water boils, put pasta (10)
- wait past is "al dente", put out water and put in sauce (10)
So the make sauce activity can be started late or extended (for a maximum of 16 minutes together) without affecting the project deadline.
But, if we want a complex sauce, lets say, that require 30 minute work, than the critical path is only the make the sauce activity, we can see: 1 min + 10 min + 10 min = 21 min (pasta time) < 30 min but the sauce must be ready when past is "al dente" !!!
In this simple example we have already a good example of the importance of good estimations, only with a good estimation we can follow the deadline.
Let see some algorithm:
- Every activity has:
- a duration d
- we will calculate:
- an Early Start Time EST and an Early Finish Time EFT
- a Late Start Time LST and a Late Finish Time LFT
We proceed with two steps (from Dijkstra shortest path):
- EST(start) = 0
we start NOW
- EFT(i) = EST(i) + d(i)
we will finish as soon as possible
- EST(j) = max(EFT(pj)) where pj are all j predecessor.
we can start the next step only when all predecessor are done, that is when the last predecessor is done
- LFT(end) = EFT(end)
we cannot do better
- LST(i) = LFT(i) – d(i)
to be in time we should start right what we have estimated before
- LFT(j) = min(LST(sj) where sj are all j successors.
a previous activity must be finished before the first subsequent start
Done this we have an important information, the Slack Time of every activity:
ST(i) = LST(i) – EST(i) = LFT(i) – EFT(i)
that is the time an activity can be moved without affecting project duration.
Activities with no Slack Time (ST == 0) are on the critical path, and should be carefully monitored.
We have to plan:
- human resources,
- technical resources,
We have to plan required skills for the project development in advance, keeping in mind that both overloaded people and enormous teams are not a Good Thing (TM).
No solution here!
There are a quite number of tools aimed to help the project manager planning and monitoring work, they help in visualization, automatic report generation, agenda reminders, shortest path calculation and so on.
Plans are the foundation for a running project.
Investments in planning is a Good Thing (TM).
- publicize the plan,
- work to follow the plan.
Choose and use the right tools.
Common errors are:
- no planning
- too detailed planning
- only time schedule plan
Project manager don’t like planning because:
- it takes time
- you have to think
- you have to use paper and pencil
- you are bounded in a systematic procedure
- they will see you are late!
We have to manage risks because:
- no project has no risk
- especially first-of-its-kind has hight risk
so we have to identify and assess risks.
Often project manager doesn’t like thinking about risks and sometime risk managing techniques are not known.
A software risk is a potential problem with a likelihood and an effect.
There are more kind of risks:
- Project risk, effecting the schedule,
- Product risk, effecting quality and performances,
- Business risk, effecting the procuring or the selling of something.
Risk management aims at identifying and planning to minimize risks effect on the project.
Definition of Risk Engineering from SEI:
Cover all activities that are necessary in order that risks do not become problems.
- Risk Engineering
- Risk Analysis
- Risk Management
Set up a culture where risks are: identified, assessed, communicated and managed proactively.
The other why is called "Crisis management".
Risk management is a continuous process based on good communication:
Identification / \ _ / \ /' / Comm \ \ | Monitoring unic Analyzing | \ \ ation / |/. \ / \ / - Planning -
Identification is difficult, we have to look in the future.
Experience of former project can help:
We should collect the experience!! Learning by doing.
A good method is to use check lists covering the most important aspects of a project:
The goal of risk analysis is to assess and prioritize risks.
We assign a discrete value at risk’s likelihood and effect:
We consider three main measures in risk planning:
|we try to reduce likelihood.|
|we try to reduce effects.|
|what to do if risk arise.|
To chose the right measure we can use a common assessment formula:
Risk Value = Likelihood * Effect _____________________________________________________ |\_____ L | (3) | (2) | (1) | | E \______ | High | Moderate | Low | |_____________\|___________|____________|___________| | (3) | H H H H H | H H H H H | | | Catastrophic | H H H H H | H H H H H | M M M M | |______________|___________|____________|___________| | (2) | H H H H H | | | | Serious | H H H H H | M M M M | L | |______________|___________|____________|___________| | (1) | | | | | Tolerable | M M M M | L | L | |______________|___________|____________|___________|
|L*E:||Likelihood * Effect|
|1*3:||minimization + contingency|
|3*1:||nothing or avoidance|
|2*2:||avoidance + minimization|
|2*3:||avoidance + contingency|
|3*2:||avoidance + minimization|
Assess identified risk regularly to monitor probability and effect changes, better during a periodic meeting.
Good communication is a prerequisite of effective risk management, all relevant people must be involved and informed (customer, steering committee, upper management).
We’d like to have a risk proactive culture.
Experience in risk management is very important, we can accumulate experience in a useful way with a detailed status report.
Risks are identified and communicated.
Measures are planned proactively.
Continuos assessment of the situation.
We can learn from the past.
Every project has risks
Risk management is:
- identify risks
- plan a measure
- assess the situation again
Checklist are a simple and useful technique.
We aim to a culture of risk-talking management.
Project controlling techniques provide metrics and measurement procedures to assess the actual project progress, useful to compare actual results to planned schedule and budget.
This append by establishing controlling standards and producing a periodical project status report, for just-in-time control measures and future reference.
Controlling, naturally, is a continuous process!
Main roles involved in controlling are:
- Customer (wait and hope)
- Project Owner (informs about Progresses, External Milestones)
- Project Manager (informs about Internal and External Milestones)
- Programmer (informs about work progress)
We can summarize in the following graph the control cycle:
+--------------+ | +----------+ | / BIG CHANGE | | Project | |<---------------------------------- | | Planning | | \ change the plan | | +----------+ | | +--------------+ | | | | +------------+ small +-----+----+ | | Corrective |<---------| Analize | | +------| control | change | Resoults | | | | Measures | +----+-----+ | | +------------+ /|\ \|/ \|/ | ' ' +------+-------+ .//---------\\. | +----------+ | // Realization \\ | |Comparison| | | of Plan and | | |to Plans | | | Control | | +----------+ | \\. Measures .// +-------+------+ \\----+----// /|\ | | | +-----------+ | | \ | Measuring | | +------------->| Project |------------+ / | Progesses | +-----------+
We need to know as soon as possible if there are deviations from the schedule in the project development, to do this our most important unit of control are the work packages.
We need to monitor every week the effort spent on every package. To do this in a big project we need a supporting tool.
We define a set of indicators:
actual effort Degree Of Completion = ------------------- EfS planned effort
This DoF indicator, based on the actual effort is very dependent from a good planning… and planning is rarely SO good.
We can create a new parameter, the estimate to complete, an estimate that we hope to be more precise in going on in the project.
Using the estimate to complete we can have a more realistic forecast final effort as:
forecast final effort = actual effort + estimate to complete
and then a new Degree Of Completion formula can be:
actual effort Degree Of Completion = ------------------------- ETC forecast final effort
Sometime in a big project is not possible to have actual data every week (estimate to complete and actual effort)
Another useful parameter can be the earned value, based only on the, estimate to complete and the initial planned effort:
earned value = planned effort – estimate to complete
So the new Degree Of Completion formula is:
earned value Degree Of Completion = ------------------ EV planned effort
We can summarize the meaning of the three Degree Of Completion formulas:
actual effort actual work done, Degree Of Completion = ------------------- = normalized by planned EfS planned effort efforts actual effort actual degree of Degree Of Completion = ------------------------- = completion in the ETC forecast final effort updated deadline earned value degree of completion Degree Of Completion = ------------------ = based only on the latest = EV planned effort estimate to complete 1 estimate to complete = 11 - ------------------------ 1 planned effort '''
As for time, we need to monitor costs too, we ca do this using a few parameters:
C_a = accumulated costs = labour + investments costs
C_frc = forecasted reminder costs to complete the project = entered commitments + cost to complete
A we have an estimate of total costs as forecasted Total costs, a sum of:
C_ftc = C_a + C_frc = what spent + what we will spend
An easy but important visualization tool is the Trend Analysis graph:
Forecasted Competion . Date /|\ +------------------------------------------------------+ +------+---------------+ | //| | **** | Requirements | | // | +------+---------------+ | // | | ++++ | Architecture | 30/05+----------------------------------------------// | +------+---------------+ | ++ // | | | +++ // | | |++++++++++++++++++ // | | | // | | | // | | 15/05+----------------------------------// | | | ********* // | | | | *** **** // | | | |******* // | | | | // | | | | // | | | 30/04+----------------------// | | | | // | | | | | // | | | | | // | | | | | // | | | | | // | | | | 15/04+----------// | | | | | // | | | | | | // | | | | | | // | | | | | | // | | | | | |// | | | | | +-----------+-----------+-----------+-----------+------+--> Reporting 15/05 30/04 15/05 30/05 dates
Analyzing the graph we can see that:
- initial forecasts are too optimistic,
- architecture forecast are reviewed late, only after a week we know requirements will be late.
If we are late we must do something, various ways are possible:
- Planned deliverables cannot be produced:
- increase productivity (motivation, control),
- increase resources (beware communication overhead of big staffs),
- reduce deliverables.
- Completion date will be exceeded:
- increase resources,
- reduce deliverables,
- concentrate efforts on the critical path (to reduce the overall duration).
- Planned costs will be exceeded:
- delegate to (cheep) subcontractors,
- reduce the quality.
We always have to inform the customer of the various possibilities and agree on a modification (deadline, quality or cost).
Project monitoring and controlling are continuous activities.
Monitoring is possible only with a plan (strange no?).
A comparison between plan and actual status must be the basis of a control measure.
We ha to collect actual performance data for future reference.
Controlling is based on work packages, work and schedules.
A software development process is an activity composed by (possibly overlapping) steps that translate user needs in a software product:
- user needs are translated in software requirements,
- requirements are translated in design,
- design is implemented in code,
- code is tested,
- (sometime) software is installed and checked onsite.
Before we can start a software development project we have to answer the following questions:
- What is the scope and what are the goals of the project?
- What are the resources and the time we need to produce the project deliverables?
- How should we organize the project?
- Is there a process model we have to apply?
- Should we customize the chosen process model?
- What language, methods and tools are we going to use?
- What are the skills we need during the project?
Coding and correcting together with ad-hoc tests are the only activities performed consciously (sometime as in the italian politic way, ad-hoc tests are inexistent, the only test is it runs!).
At the end, system as no guaranties to conform to the real requirements, coding and correction is a domino effort increasing with time, and normally, documentation lacks.
But this is the most common model perhaps!
Waterfall model is well know model supporting project management:
- System Analysis
- System Specification
- System Design
- Module Specification and Design
- Code and Module-Test
- Integration and System Test
- Operation and Maintenance
Every time an error is found control go back to the originating step. The problem is that user feedback comes often too late.
The basic idea is: we won’t develop the system as a whole.
Feedback is possible in short time, but due to the absence of an executable system is based only on a good requirement specification.
Iterative development is defined as a:
"Controlled continuous revision of software aiming at correcting errors early and integrate improvements"
"We get things wrong before we get them right"
Main differences to the waterfall model are:
- Requirements are a moving material:
- software usage induces software requirement modification.
- Maintenance activities are integrated in the development process.
RUP is a generic process model and has to be customized before application.
It is based on use cases and prototyping:
Prototypes are good for:
- minimize risks
- demonstrate progresses
The process is intrinsically incremental and use UML formalism whenever possible.
RUP defines 4 development phases and a set of disciplines.
Any discipline is performed in any phase, and phases can be iterated more times.
RUP assumes software is conceived in an object oriented manner.
RUP is organized in two dimensions:
- Work (disciplines):
- how do what,
- Requirement -> Analysis & Design -> Implementation -> Test cycle,
- project management, environment, configuration and change management.
- work is organized in subsequent phases,
- each phase complete with a successful milestone test.
Product development is done in several development cycles, each cycle consists of 4 phases and deliver a product release, each phase can require several iterations.
RUP phases are:
- define project goals, deliverables and costs,
- check high risk requirements.
- identify use cases,
- make a risk analysis,
- define: success criteria (important deliverables), resources and important milestones.
Should we start (continue) the project?
- Vision document
- Model of the application domain <— we need a domain expert!!
- Important requirement list (10%-20% of all use cases).
- Draft project plan with important milestones.
- Draft costs estimation.
- List of deliverables.
- Glossary of common terms: communication is important both with client and collaborators.
- Project was started
- Analyze and understand the application domain.
- Design the software architecture.
- Eliminate high project risks.
- Work out use cases in detail.
- Identify and formulate non-functional requirements.
- Construction of the first prototype.
- Creating the project plan.
Do we know what to deliver?
Do we have an appropriate architecture?
Can we control the risks?
- Top level architecture:
- All use cases are identified, 80% already are detailed.
- Model of the application domain.
- Chosen development technology.
- Non-functional requirements.
- Inspection report:
- software architecture,
- most important use cases.
- Revisited Project Plan.
- Project plan and defined architecture.
- Implementing the project based on the architecture.
- Select use cases to implement.
- Detail use case (if necessary).
- Revise architecture (if necessary).
- Implement the use case.
- Test the resulting system.
Can we use the system?
- Tested system.
- User documentation.
- System documentation of developed release.
- Beta release of the software
- Correct errors.
- Integrate user feedback in the system.
- Measure system quality
- If necessary, improve development process.
Are all requirements implemented?
Do we have to perform a further cycle?
The process is represented by a workflow.
Workflow is populated by roles
A role perform an activity and is responsible for an artifact.
The artifact is the memory of the project.
Disciplines in RUP are four:
- Business Modeling
- Analysis and Design
The first discipline, Business Modeling is to be performed with a Business domain expert and lies out our goals.
- Describe what the system should do
- Define boundaries of the system (scope)
- Identify non-functional requirements
- Use Cases
- Non-functional requirements
- requirements, design model of preceded iterations.
- Define how the system should be build.
- Use Case design:
- Identify the influence of use cases to object model.
- Work out dynamical use cases as interaction diagrams.
- Development / Revision of the object model:
- Revising existing class diagram.
- Define a package structure.
- Architectural design:
- Define top level architecture.
- Map classes / packages on components.
- Revised design model.
- Design model.
- Implement all classes.
- Ensure specification adherence.
- Generate code framework from model design (automatic if possible).
- Implement operation and other missing parts.
- Perform class test (unit test).
- Integrate tested classes in the existing environment.
- Working tested system.
Project my differ vastly, RUP can be customized in regard of:
- project kind,
- complexity and size,
- culture of the organization.
We can evaluate how many:
- Artifact and Document produce: we should produce only what is a value for the organization.
- Workflow and Roles activate: in small project activities and roles can be combined.
RUP as a sum of many years of processes,
- Excellent configuration and change management (TOOLS)
- High management abilities
- Know of in OOD and related languages (UML).
- Deep monitoring and controlling.
- Excellent documentation for the future.
- Difficult to customize due to the numerous predefined interactions (customization means less tool support).
- Unstable definition of the process (and so hard replication).
- Stable, suggested work order (sometime cannot fit).
Develop software is hard, everyone has a own best way.
Due to immaterial ground, invisible results, often software is the biggest problem in a complex system (Train, Airplane, Rocket, ..)
Software Engineering Institute was founded by the Department of Defense of USA to:
- Analyze software development in industry
- Analyze research on software engineering
- Develop method for process improvement
- Transfer research into practice
- Do consulting service.
CMM define a set of four levels of maturity for organization, every level contains previous levels:
- (1) Initial (uncontrolled)
- disciplined process -> (2) repeatable (project and configuration management)
- standard, consistent process -> (3) defined (formally defined process)
- predictable process -> (4) managed (measured process)
- continuously improving process -> (5) optimizing (optimized process)
- a well defined evolutionary plateau on the path to becoming a mature organization,
- each level is a foundation for a continuous improvement process.
- a set of related practices performed to achieve a set of goals,
- each area reside in a given maturity level,
- process areas define the process capability of the organization.
- Documentation of software estimates for planning and tracking
- Planning of software project activities
- Agreement of affected group and individuals for commitments
Commitment to perform:
- Designated responsible project manager for negotiating commitments and developing the project plan.
- The project follow a written organizational policy for planning.
Ability to perform:
- Existence of a documented and approved statement of work.
- Assignment of responsibilities for developing the project plan.
- Adequate funding and resources for the project planning.
- Training of individuals involved in project planning.
- Participation of the software engineering group on the project proposal team.
- Software project planning is initiated early and in parallel with overall project planning.
- Participation of the software engineering group in the project’s life.
- Commitments are reviewed with senior management in a documented procedure.
- A (project-specific) software life cycle with predefined stages is identified or defined.
- The software development plan is developed in a documented manner.
- The plan for the software project is documented.
- Software products are identified and configuration management is set.
- Size estimates are derived following a documented procedure.
- Effort and cost estimates are from a documented procedure.
- Critical computer resources are defined from a documented procedure.
- Software schedule is derived from a documented procedure.
- Risks are identified, assessed and documented.
- Tool supporting the project are prepared.
- Planning data are recorded.
Measurement and analysis:
- Measurements provide the status of the software planning activities
- Activities are reviewed with senior management periodically.
- Activities are reviewed with project manager on a periodic or event-based basis.
- Software quality is reviewed by a specific group that release a report.
- Uncontrolled process
- No standards
- Overcommitment, frequent out of time/budget
- Dependence on individuals (heroes)
- Constant firefighting
- Some experience is collected and process has some guidelines
- Each project is managed as individual
- No organization-wide standards
- Key process areas:
- Requirement management
- Project Planning
- Project Tracking
- Subcontractor management
- Quality insurance
- Configuration management
- Process management is institutionalized (software engineering process group).
- Process is formally defined
- There is an organization-wide standard process usage
- Key process areas:
- Organization process focus
- Organization process definition
- Training program
- Integrated software management
- Software product engineering
- Inter-group coordination
- Peer reviews
- Metrics are defined and used
- Quantitative goals are defined
- Variation occurs within known bounds
- Key process areas:
- Quantitative process management
- Software quality management
- Processes are continuously optimized
- Both process and technology changes are managed
- Key process areas:
- Defect prevention
- Technology change management
- Process change management
- Software success factors
- What is Software
- What is a program
- Software properties
- Good software properties
- What is software engineering
- Software engineering goals
- Software engineering methods
- System triangle
- Software life cycle
- Software engineering panorama summary
- Software Project Management
- What is a Project
- What is project management
- Why do projects fail
- Success factors
- Goals of project management
- Project management overview
- Project management phases
- Project management summary
- Starting a project
- Initial phase
- Project planning
- Risk management
- Project controlling
- Software process models
- Code and Fix (the italian politics way)
- Waterfall model
- Incremental development
- Iterative development
- Rational Unified Process
- Software Process Improvement