risk management in software projects josé onofre montesa andrés universidad politécnica de...
Post on 20-Dec-2015
214 views
TRANSCRIPT
Risk management in Software
Projects
José Onofre Montesa AndrésUniversidad Politécnica de
ValenciaEscuela Superior de Informática
Aplicada2003-2004
GpiI-3C Risk management in Software Projects 2
Índice
• Failure and root causes.• Risk Definition• Formas en las que se afrontan las causas de
las desviaciones• Elementos de la Gestión de Riesgos
– Identificar los factores de Riesgo– Evaluar la probabilidad y el efecto– Desarrollo de estrategias para mitigar los riesgos
• Monitorizar los factores de riesgo
GpiI-3C Risk management in Software Projects 3
Failure and root causes.
• Software projects fail if:– Software never runs.– Don’t accomplish same expected
functions.– Software isn't delivered on time.– Higher cost than expected.
• Reasons:– High level of complexity (communications,
interrelation with other systems, etc..)– Uncertainty. It wasn’t clear the objective.
GpiI-3C Risk management in Software Projects 4
Risk Definition (Fairley)
• Risk is a potential problem.• Problem is a risk that has materialized.• By a problem, we mean an undesirable
situation that will require time and resources to correct. – (may be uncorrectable).
• A risk is characterized by:– The probability that occur (0<P<1)– A loss associated
GpiI-3C Risk management in Software Projects 5
Risk factors fall into two categories
– Generic risks, common to all software projects, then we tray to improve the organization to overcome this risks or we have a check list.
– Project specific risks.
• This are complementary points of view we must act on both.
GpiI-3C Risk management in Software Projects 6
Most Common Software Risks (1) (Caper Jones)
• Ambiguous improvement targets.(4)• Creeping users requirements.(9)• Crowded office conditions.(10)• Excessive schedule pressure.(13)• Excessive time to market.(14)• Inaccurate cost estimating.(19)• Friction between:
– Client and software contractors.(16)– Software management and senior executives.
(17)
GpiI-3C Risk management in Software Projects 7
Most Common Software Risks (2) (Caper Jones)
• Inadequate compensation plans.(24)• Inadequate configuration control and project
repositories.(25)• Inadequate Curricula (S.E., S.M.)(26, 27).• Inadequate package acquisition methods.
(29)• Inadequate software policies and standars.
(31)• Inadequate tolls and methods (project
management, Quality assurance, software engineering, technical documentation…)(34-37)
GpiI-3C Risk management in Software Projects 8
Most Common Software Risks (3) (Caper Jones)
• Lack of reusable code, data, test, human interfaces.(41-47)
• Lack of specialization (48).• Low user satisfaction(53).• Low productivity.(50)• High maintenance costs.(18)• Partial live cycle definitions.(57)• poor technology investments.• Silver bullet syndrome.(62)
GpiI-3C Risk management in Software Projects 9
Specific risk causes.
• “When a project is successful, it is not because there are no problems, but because the problems were overcome .”
• We can act:– Reactive: we wait problems and then we
act on them.– Proactive: We identify potential problems
and act in anticipation
GpiI-3C Risk management in Software Projects 10
Risk management elements
• Different techniques to work whit risk.– The spiral life cycle.– Check lists– Risk management.
• This methods can work all together.
GpiI-3C Risk management in Software Projects 11
Risk management procedures
• Identify risk factors• Asses risk probabilities and effects on the
project• Develop strategies to mitigate identify
risks• Monitoring Risk factors• Invoke a contingence plan.• Manage the crisis.• Recovery from a crisis.
» Fairley, R. IEEE Software Mayo 1994
GpiI-3C Risk management in Software Projects 12
Identify risk factors
• You must visualize the project development and identify “wrong” things.
• If you have a checklist with problems in other projects you work then revise that list.– “Who don’t know their past is
commended to repeat”
GpiI-3C Risk management in Software Projects 13
• You must difference cause (risk factors), problems and symptoms.
• Whether you identify a situation as a risk or an opportunity depends on your point of view.
• Is the glass half full or half empty?– Situations with high potential for failure
often have the potential for high pay back.
GpiI-3C Risk management in Software Projects 14
Asses risk probabilities and effects on the project
• Evaluate the probability of this problem.• Evaluate the effect the problem would
have on the project desired outcome.• Classify risks with the Risk exposure,
calculated as:– Probability * Effect
• As a consecuence we will identify more important risks.
GpiI-3C Risk management in Software Projects 15
Evaluación de la probabilidad de que se de el
problema.• Not all the problems have the same
probability.• Some times evaluating the
probability is something difficult, use– Similar cases .– Optimist, pessimist and more probable.– Remember the Murphy law:
• “if something can go wrong, it will do”
• We can use simulation tools.
GpiI-3C Risk management in Software Projects 16
Develop strategies to mitigate identify risks
• Two types of strategies:– Action planning.
• Addresses risks that can be mitigated by immediate response
– Contingency planning.• We accept the risk and we plan and control
the risk.
GpiI-3C Risk management in Software Projects 17
Action planning
• We minimize or vanish the risk.• We take action before the problem
will materialize.– Example:
• Problem: We can have problem using new tolls.
• Action: We hire a experienced worker whit this tools
GpiI-3C Risk management in Software Projects 18
Contingency planning
• We accept the risk and we prepare a plan and we will use this if the risk is materialized.
• The actions to take are:– Identify variables to be control in order to
detect that the problem is here.– Create an action plan to be used during the
crisis, as a consequence of this problem.– Planning the crisis recovery.
GpiI-3C Risk management in Software Projects 19
Monitoring Risk factors
• We observe identify symptoms, grouped.
• We must quantify in a precise manner with objective, timely and accurate metrics.
• We must have a clear control limits• We need a tradability between risk
factors and risks.
GpiI-3C Risk management in Software Projects 20
Invoke a contingence plan
• When a quantitative risk indicator crosses a predetermined threshold.
• Usually you can have different levels, – At first levels the operative level take
action, – If can’t correct the situation then the
contingency plan will start.
GpiI-3C Risk management in Software Projects 21
Manage the crisis
• Despite a team’s best effort, the contingence plan may fail, in which case project enters crisis mode
GpiI-3C Risk management in Software Projects 22
Recovery from a crisis
• After a crisis certain actions are required:– Reward personnel who have worked in
burnout mode,– Reevaluating cost and schedule in light
of the drain on resources from managing the crisis.
GpiI-3C Risk management in Software Projects 23
Bibliografía
• Fairley, R. “Risk Management for Software Development” en Software Engineering editado por Dorffman, M y Thayer, R.H., IEEE Computer Society, 1997
• Fairley, R. “Risk Management for Software Projects”, IEEE Software, Mayo 1994
• Jones, C. Assessment and Control of Software Risks. Yourdon Press, Prentice Hall, 1994.