Manejo de Riesgos de Software
Dr. Pedro Mejia Alvarez
CINVESTAV-PN
Pedro Mejia Alvarez CINVESTAV-PN
Manejo de Riesgos de Software
1
Manejo de Riesgos de Software
1.
2.
3.
4.
5.
6.
7.
8.
Riesgos del proyecto.
Riesgos del producto.
Riesgos del negocio.
Administración de riesgos.
Identificación de riesgos.
Análisis de riesgos.
Planeación de riesgos.
Monitorización de riesgos.
Pedro Mejia Alvarez CINVESTAV-PN
Manejo de Riesgos de Software
2
Manejo de Riesgos en el Desarrollo de
Software
• En el desarrollo de software existen una gran cantidad de riesgos
que pueden comprometer la exitosa terminación del proyecto o
del producto, o que pueden hacer que éste se retrase.
• El manejo de riesgos comienza desde el momento en que el
cliente requiere el proyecto.
• El administrador del proyecto y el analista de requerimientos,
son los primeros que deben llevar a cabo un estudio de los
riesgos del desarrollo del proyecto.
Pedro Mejia Alvarez CINVESTAV-PN
Manejo de Riesgos de Software
3
Manejo de Riesgos en el Desarrollo de
Software
• Los riesgos pueden afectar la calidad del software y alterar su
desarrollo. Un manejo efectivo de los riesgos permite
anticiparse a los riesgos antes de que estos ocurran, o a tratar
sus posibles consecuencias, en caso de que no se hayan
podido anticipar y tratar.
• El resultado del análisis de riesgos debe ser documentado
junto con sus posibles consecuencias.
• En general se puede considerar que un riesgo es un factor que
altera de forma negativa el desarrollo del software, que afecta
su calidad, su costo o su fecha de terminación.
Pedro Mejia Alvarez CINVESTAV-PN
Manejo de Riesgos de Software
4
Categorías de los Riesgos
Existen tres categorías en las que se puede clasificar a los
riesgos:
• Riesgos del proyecto: son aquellos que afectan al plan (o
calendario) del proyecto o a sus recursos. Un ejemplo de este
tipo de riesgos, puede ser la perdida de un programador
experimentado.
• Riesgos del producto: son riesgos que afectan la calidad o el
desempeño del software por desarrollar. Un ejemplo de este
tipo de riesgo puede ser el fallo de un componente comprado.
• Riesgos del negocio: son riesgos que afectan a la organización
que desarrolla el software. Por ejemplo, la introducción al
mercado a un producto similar al que se está desarrollando.
Pedro Mejia Alvarez CINVESTAV-PN
Manejo de Riesgos de Software
5
Categorías de los Riesgos
• Existe una relación entre estos 3 tipos de riesgos. Por
ejemplo, la salida de un programador experimentado del
proyecto puede producir un riesgo en el proyecto pero
también puede producir un riesgo en el producto, ya que la
calidad de este puede verse afectada en caso de que otro
programador con menos experiencia sea contratado para
reemplazar al anterior.
• Finalmente, la salida de este programador también puede
afectar al negocio, ya que la organización quizás invirtió
dinero en su entrenamiento y su experiencia ya no será
aprovechada por la organización. Es un hecho entonces,
que un solo riesgo puede ser de varios tipos.
Pedro Mejia Alvarez CINVESTAV-PN
Manejo de Riesgos de Software
6
Ejemplos de tipos de riesgos
Riesgo
Perdida de personal
Tipo de Riesgo
Proyecto
Descripción
Empleados experimentados salen del proyecto antes de que
éste termine.
Cambios en la organización
Proyecto
Se dan cambios en la organización que lleva a cambios en las
prioridades
No disponibilidad de hardware
Proyecto
Hardware que es esencial en el proyecto no se entrega a
tiempo
Cambios en los requerimientos
Proyecto y
Hay un número de cambios mayor a los anticipados.
Producto
Retrasos en la especificación
Proyecto y
Producto
Las especificaciones de interfaces necesarias no están
disponibles cuando se requieren.
Mala estimación del costo
Proyecto y
El tamaño o costo del proyecto no se estima correctamente.
o tamaño
Producto
Bajo desempeño en las
Producto
Herramientas CASE que ayudan al diseño no se comportan
como se había planeado.
Cambios en la tecnología
Negocio
La tecnología sobre la que se comenzó el proyecto ha sido
superada por la nueva tecnología.
Competencia del producto
Negocio
Otro producto similar al que está desarrollándose sale al
Pedro Mejia Alvarez CINVESTAV-PN
mercado antes.
7
Manejo de Riesgos de Software
herramientas
Administración de los Riesgos
• La administración de riesgos es importante por las consecuencias que
pueda derivar cada riesgo, y también por que existen pocos proyectos
de software sin riegos.
• Los riesgos aparecen principalmente por requerimientos pobremente
definidos, por la dificultad de predecir los costos y tiempos de
desarrollo, por la excesiva dependencia de en la habilidad particular de
cada persona involucrada en el desarrollo y también por los constantes
cambios en los requerimientos debidos a cambios en la necesidades de
los clientes.
• Es necesario identificar los riesgos, anticiparse a ellos, entender el
impacto que pueden causar, en caso de que aparezcan, y evitar sus
consecuencias. Así mismo, es necesario trazar planes de contingencia
para remediar los efectos de los riesgos.
Pedro Mejia Alvarez CINVESTAV-PN
Manejo de Riesgos de Software
8
Administración de los riesgos
El proceso de administración de riesgos puede observarse en
la Figura 1.10. Este proceso contiene las siguientes fases:
• Identificación: En esta etapa se identifican posibles riesgos
del proyecto, producto o negocio.
• Análisis: En esta etapa se estudia la posibilidad de
ocurrencia y las consecuencias de los riesgos.
• Planeación: En esta etapa se planea para evitar los riesgos
o para minimizar sus consecuencias en caso de que
aparezcan.
• Monitorización: Los efectos de los riesgos se monitorizan
constantemente para llevara cabo los planes propuestos.
Pedro Mejia Alvarez CINVESTAV-PN
Manejo de Riesgos de Software
9
Administración de Riesgos
• El proceso de administración de riesgos es un proceso
iterativo el cual continúa durante todo el proyecto.
• Una vez que se leva a cabo la planeación, los riesgos son
monitorizados.
• Si durante el desarrollo llega información adicional sobre
algún riesgo, estos deberán ser analizados nuevamente y se
deben establecer nuevas prioridades.
• Los planes de contingencia deben ser modificados a
medida que surja nueva información sobre algún riesgo.
• La salida del proceso deberá estar documentada en un plan
de administración de riesgos, el cual debe incluir los
reportes de riesgos encontrados y la solución adoptada
ante tal riesgo.
Pedro Mejia Alvarez CINVESTAV-PN
Manejo de Riesgos de Software
10
Proceso de Administración de Riesgos
Identificacion
de Riesgos
Analisis
de Riesgos
Planeacion
de Riesgos
M onitorizacion
de Riesgos
Lista de riesgos
potenciales
Lista de riesgos
con prioridades
Planes de
contingencia
Evaluación de
Riesgos
Pedro Mejia Alvarez CINVESTAV-PN
Manejo de Riesgos de Software
11
Identificación de Riesgos
• La identificación de riesgos el la primera fase del
proceso de administración de riesgos. Esta fase
permite descubrir los riesgos en el proyecto, sin
priorizarlos ni analizarlos.
• Los riesgos se identifican principalmente cuando
no se tiene bien claro cuales serán las
consecuencias de alguna decisión. La experiencia
de proyectos anteriores ayuda en gran parte a
encontrar los riesgos.
Pedro Mejia Alvarez CINVESTAV-PN
Manejo de Riesgos de Software
12
Identificación de Riesgos
• Riesgos de la tecnología. Estos son riesgos que se derivan
del software o hardware que se utiliza durante el desarrollo
del software.
• Riesgos de la gente. Estos son riesgos asociados a la gente
involucrada en el desarrollo.
• Riesgos organizacionales. Estos son riesgos que se derivan
del ambiente organizacional en donde el software se
desarrolla.
• Riesgos técnicos. Estos son riesgos que se derivan de los
conocimientos técnicos que deben adquirirse para poder
llevar a cabo el desarrollo del software. En este caso, podría
ser que las herramientas CASE adquiridas no incluyen los
métodos de diseñó requeridos.
Pedro Mejia Alvarez CINVESTAV-PN
Manejo de Riesgos de Software
13
Identificación de Riesgos
• Riesgos en los requerimientos. Estos son riesgos que
ocurren cuando los clientes solicitan cambios en los
requerimientos, y del proceso que permite llevar estos
cambios a cabo.
• Riesgos de estimaciones. Estos son cambios que se
derivan de la administración de proyecto y que
provienen de las estimaciones de los recursos, tiempos
y costos necesarios para desarrollar el software.
Es importante no solo identificar el riesgo, sino también
señalar cual podría ser su efecto y cual seria su posible
causa.
Pedro Mejia Alvarez CINVESTAV-PN
Manejo de Riesgos de Software
14
Análisis de Riesgos
• Durante el proceso de análisis de riegos es necesario
considerar a cada riesgo por separado y llevar a cabo un
estudio de su probabilidad de ocurrencia y de sus
consecuencias.
• No existe una forma fácil de llevar a cabo este análisis y la
experiencia juega un papel vital en este proceso. Los
estimados en este proceso no tienen que ser precisamente
datos exactos sino aproximaciones. Por ejemplo, la
probabilidad de ocurrencia del riesgo se considera baja
(menor al 10%), moderada (del 10% al 30 %), alta (del 20% al
70 %), o muy alta (del 70% al 100%). Igualmente los efectos de
los riesgos podrían clasificarse como, insignificantes,
moderados, serios, o catastróficos.
Pedro Mejia Alvarez CINVESTAV-PN
Manejo de Riesgos de Software
15
Análisis de Riesgos
• En base a esta clasificación, se deben tabular los resultados de este
proceso de análisis utilizando una tabla en donde se ordenen los riesgos
(y se les asigne prioridad) de acuerdo a su seriedad.
• La Figura 1.12 ilustra este análisis para los riesgos identificados en la
Figura 1.11. Los datos incluidos en las figuras son arbitrarios, sin embargo,
en un proyecto real, estos datos deberán considerar información detallada
sobre el proyecto, el proceso, la organización y las técnicas utilizadas. La
probabilidad de los riegos y sus efectos podrían cambiar conforme mas
información es recolectada, con lo cual estas tablas deben ser
actualizadas. Es recomendable identificar y monitorizar con cuidado los
riegos que se consideren con efectos catastróficos y serios y cuya
probabilidad de ocurrencia sea alta.
Pedro Mejia Alvarez CINVESTAV-PN
Manejo de Riesgos de Software
16
Clasificación de Riesgos
Tipo de Riesgo
Posible Riesgo
Tecnología
La base de datos usada en el sistema no puede procesar tantas transacciones como se había planeado.
Algunos de los componentes que se están reutilizando tienen defectos.
Gente
Personal clave del proyecto deja la organización.
No hay cursos de entrenamiento para el personal actualmente.
No se encuentra personal capacitado para algunas etapas del proyecto.
Organizacional
La organización se re-estructura y cambian al jefe del proyecto a otra área.
Los problemas financieros de la organización llevan a reducir el personal asignado al proyecto.
Técnicos
Las herramientas CASE son difíciles de usar, y retrasan el diseño.
No todo el personal conoce el lenguaje JAVA que se utilizara en el proyecto.
Requerimientos
Los cambios en los requerimientos obligan a hacer más cambios en el diseño de los planeados.
Algunos requerimientos que se llevaron al diseño no fueron realmente los que el cliente los propuso.
Estimación
El tiempo de pruebas de software no se estimo adecuadamente.
El costo del entrenamiento
personal
noCINVESTAV-PN
se considero.
Pedrodel
Mejia
Alvarez
Manejo de Riesgos de Software
17
Análisis de Riesgos
Riesgo
Probabilidad
Efectos
Los problemas financieros de la organización llevan a reducir el personal asignado al Baja
proyecto
Catastróficos
No se encuentra personal capacitado para algunas etapas del proyecto.
Alta
Catastróficos
Personal clave del proyecto deja la organización.
Alta
Catastróficos
La base de datos usada en el sistema no puede procesar tantas transacciones como se Moderada
había planeado.
Seria
Algunos de los componentes que se están reutilizando tienen defectos.
Moderada
Seria
No hay cursos de entrenamiento para el personal actualmente.
Moderada
Seria
La organización se reestructura y cambian al jefe del proyecto a otra área.
Moderada
Seria
Los cambios en los requerimientos obligan a hacer más cambios en el diseño de los Moderada
planeados.
Seria
Algunos requerimientos que se llevaron al diseño no fueron realmente identificados como Baja
los que el cliente los propuso.
Seria
No todo el personal conoce el lenguaje JAVA que se utilizara en el proyecto.
Baja
Seria
Las herramientas CASE son difíciles de usar, y retrasan el diseñó.
Baja
Tolerable
El tiempo de pruebas de software no se estimo adecuadamente.
Moderada
Tolerable
Baja
Insignificante
Pedro Mejia Alvarez CINVESTAV-PN
Manejo de Riesgos de Software
El costo del entrenamiento del personal no se considero.
18
Planeacion de Riesgos
El proceso de planeación de riesgos considera que cada riesgo ha sido
identificado e identifica estrategias para manejarlos. No existe un proceso
estándar para esta etapa, sin embargo Somerville propone las siguientes
estrategias para la planeación de los riegos:
• Estrategias de evasión de riesgos. Estas estrategias están diseñadas para
evitar que ocurran los riesgos. Un ejemplo de estrategia podría ser la
presentada en la Figura 1.13 para tratar con componentes defectuosos.
• Estrategias de minimización. Estas estrategias permiten minimizar los
efectos de los riesgos. Un ejemplo de esta estrategia podría ser la que se
sigue para el personal enfermo, descrito en la Figura 1.13.
• Planes de contingencia. Estas estrategias permiten prepararse para el
caso en que ocurran los riesgos contemplados. Una estrategia de este tipo,
se presenta en la Figura 1.13, para el caso de que existan problemas
financieros en la organización.
Es difícil plantear una estrategia que minimice por completo los efectos de un
riesgo o que los evite. En la mayoría de las ocasiones lo que se propone con
las estrategias es una minimización de estos efectos.
Pedro Mejia Alvarez CINVESTAV-PN
Manejo de Riesgos de Software
19
Estrategias para Manejo de Riesgos
Riesgo
Problemas financieros
en la organización
Estrategia
Preparar un informe a la organización que detalle como el proyecto está contribuyendo a las metas de
la organización, y de que forma se obtendrán beneficios.
Problemas de
reclutamiento de
personal
Alertas a los clientes de posibles retrasos, así como un informe de sus posibles consecuencias.
Enfermedades en el
personal
Componentes
defectuosos
Cambios en los
requerimientos
Reorganizar al equipo de trabajo, para minimizar las consecuencias de la enfermedad del personal.
Reestructuración
organizacional
Desempeño de la Base
de datos
Estimación errónea del
tiempo de desarrollo
Preparar un informe que indique las consecuencias de la reestructuración, sus efectos económicos y
técnicos.
Investigar la posibilidad de comprar una base de datos más eficiente.
Reemplazar componentes defectuosos con otros de reconocida confiabilidad, aunque estos sean más
costosos.
Realizar un estudio de que permita rastrear los requerimientos hacia el diseño y la implementación, para
verificar el impacto potencial de estos cambios.
Investigar la posibilidad de comprar componentes y reutilizarlos.
Investigar la posibilidad de contratar más personal para terminar a tiempo.
Pedro Mejia Alvarez CINVESTAV-PN
Manejo de Riesgos de Software
20
Monitorización de Riesgos
• La monitorización de los riesgos permite verificar cuales son los
riesgos que ocurren y cuales son sus efectos. Esto permite
comprobar si las predicciones hechas fueron acertadas, y si las
estrategias planteadas para reducir sus efectos realmente
funcionaron.
• La monitorización de los riesgos debe ser un proceso continuo
durante todo el desarrollo del proceso, aun cuando el software se
encuentre en funcionamiento.
• Cada riesgo y sus efectos (ocurran estos o no) debe ser
documentado a fin de que esta experiencia sea utilizada en futuros
proyectos. Así mismo, es importante reportar las causas que
llevaron a su ocurrencia.
Pedro Mejia Alvarez CINVESTAV-PN
Manejo de Riesgos de Software
21
Preguntas
• Que es la administracion de riesgos?
• En que puede ayudarnos dentro del
proyecto ?
• Cuando debe llevarse a cabo ?
• Como se debe llevar a cabo ?
• Apuntes de Barry Boehm (USC).
10/14/05
©USC-CSE
22
Administracion de Riesgos de Software (Boehm)
Risk
Identification
Risk
Assessment
Risk
Analysis
Risk
Prioritization
Risk
Management
Risk mgmt
Planning
Risk
Control
Risk
Resolution
Risk
Monitoring
10/14/05
Checklists
Decision driver analysis
Assumption analysis
Decomposition
Performance models
Cost models
Network analysis
Decision analysis
Quality factor analysis
Risk exposure
Risk leverage
Compound risk reduction
Buying information
Risk avoidance
Risk transfer
Risk reduction
Risk element planning
Risk plan integration
Prototypes
Simulations
Benchmarks
Analyses
Staffing
Milestone tracking
Top-10 tracking
Risk reassessment
Corrective action
©USC-CSE
23
Risk Identification Techniques
• Risk-item checklists
• Decision driver analysis
– Comparison with experience
– Win-lose, lose-lose situations
• Decomposition
–
–
–
–
Pareto 80 – 20 phenomena
Task dependencies
Murphy’s law
Uncertainty areas
• Model Clashes
10/14/05
©USC-CSE
24
Top 10 Risk Items: 1989 and 1995
1995
1989
1.
Personnel shortfalls
1.
Personnel shortfalls
2.
Schedules and budgets
2.
Schedules, budgets, process
3.
Wrong software functions
3.
COTS, external components
4.
Wrong user interface
4.
Requirements mismatch
5.
Gold plating
5.
User interface mismatch
6.
Requirements changes
6.
7.
Externally-furnished
components
Architecture, performance,
quality
7.
Requirements changes
8.
Externally-performed tasks
8.
Legacy software
9.
Real-time performance
9.
Externally-performed tasks
10. Straining computer science
10/14/05
10. Straining computer science
©USC-CSE
25
Example Risk-item Checklist: Staffing
•
•
•
•
•
•
•
•
•
Will you project really get all the best people?
Are there critical skills for which nobody is identified?
Are there pressures to staff with available warm bodies?
Are there pressures to overstaff in the early phases?
Are the key project people compatible?
Do they have realistic expectations about their project job?
Do their strengths match their assignment?
Are they committed full-time?
Are their task prerequisites (training, clearances, etc.) Satisfied?
10/14/05
©USC-CSE
26
Risk ID: Examining Decision Drivers
•
Political versus Technical
– Choice of equipment
– Choice of subcontractor
– Schedule, Budget
– Allocation of responsibilities
•
Marketing versus Technical
– Gold plating
– Choice of equipment
– Schedule, budget
•
Solution-driven versus Problem-driven
– In-house components, tools
– Artificial intelligence
– Schedule, Budget
•
Short-term versus Long-term
– Staffing availability versus qualification
– Reused software productions engineering
– Premature SRR, PDR
•
10/14/05
Outdated Experience
©USC-CSE
27
Potential Win-lose, Lose-lose Situations
“Winner”
• Quick, cheap, sloppy product
• Developer
• Customer
• Developer
• Lots of bells and whistles
• Customer
• Developer
• Driving too hard a bargain
Loser
• User
• Customer
• Developer
• Customer
Actually, nobody wins in these situations
10/14/05
©USC-CSE
28
Watch Out For Compound Risks
•
•
•
•
•
Pushing technology on more than one front
Pushing technology with key staff shortages
Vague user requirements with ambitious
schedule
Untried hardware with ambitious schedule
Unstable interfaces with untried
subcontractor
Reduce to non-compound risks if possible
•
10/14/05
Otherwise, devote extra attention to
compound- risk containment
©USC-CSE
29
The Top Ten Software Risk Items
Risk Item
Risk Management Techniques
1. Personnel Shortfalls
Staffing with top talent; key personnel
agreements; incentives; team-building; training;
tailoring process to skill mix; peer reviews
2. Unrealistic schedules
and budgets
Business case analysis; design to cost; incremental
development; software reuse; requirements descoping;
adding more budget and schedule
3. COTS; external components
Qualification testing; benchmarking; prototyping;
reference checking; compatibility analysis; vendor
analysis; evolution support analysis
4. Requirements mismatch;
gold plating
Stakeholder win-win negotiation; business case
analysis; mission analysis; ops-concept formulation;
user surveys; prototyping; early users’ manual;
design/develop to cost
5. User interface mismatch
Prototyping; scenarios; user characterization
(functionality, style, workload)
10/14/05
©USC-CSE
30
The Top Ten Software Risk Items (Concluded)
6. Architecture, performance,
quality
Architecture tradeoff analysis and review boards;
simulation; benchmarking; modeling; prototyping;
instrumentation; tuning
7. Requirements changes
High change threshold; information
hiding; incremental development (defer
changes to later increments)
8. Legacy software
Design recovery; phaseout options analysis;
wrappers/mediators; restructuring
9. Externally-performed
tasks
Reference checking; pre-award audits;
award-fee contracts; competitive design
or prototyping; team-building
10. Straining Computer
Science capabilities
Technical analysis; cost-benefit analysis;
prototyping; reference checking
10/14/05
©USC-CSE
31
Network Schedule Risk Analysis
2, p = 0.5
6, p = 0.5
2, p = 0.5
...
4 months
...
...
...
4
6, p = 0.5
4 Equally Likely Outcomes
2
2
2
6
6
6
2
6
6
6
10/14/05
EV = 4 months
2
_6_
20
EV = _20_ = 5 MONTHS
4
©USC-CSE
32
Prioritizing Risks: Risk Exposure
Risk Exposure - (Probability) (Loss of Utility)
Check
Utility Loss Estimate
Major
Risk
Risk Probability
High
Low
10/14/05
Check
Probability
Estimate
Little
Risk
Low
©USC-CSE
Loss of Utility
High
33
Risk Exposure Factors
(Satellite Experiment Software)
Unsatisfactory Outcome (UO)
A. S/ W error kills experiment
B. S/ W error loses key data
C. Fault tolerance features cause unacceptable
performance
D. Monitoring software reports unsafe condition
as safe
E. Monitoring software reports safe condition
as unsafe
F. Hardware delay causes schedule overrun
G. Data reduction software errors cause extra
work
H. Poor user interface causes inefficient
operation
I. Processor memory insufficient
J. DBMS software loses derived data
10/14/05
Prob (UO)
3-5
©USC-CSE
Loss (UO)
10
Risk Exposure
30 - 50
3-5
8
24 - 40
4-8
7
28 - 56
5
9
45
5
3
15
6
4
24
8
1
8
6
5
30
1
7
7
2
2
4
34
Risk Exposure Factors and Contours: Satellite Experiment
Software
10/14/05
©USC-CSE
35
Risk Reduction Leverage (RRL)
RRL -
RE BEFORE - RE AFTER
RISK REDUCTION COST
· Spacecraft Example
LONG DURATION
TEST
LOSS (UO)
PROB (UO) B
RE B
$20M
0.2
$4M
PROB (UO)
A
REA
0.05
$1M
COST
$2M
RRL
10/14/05
4-1
2
= 1.5
©USC-CSE
FAILURE MODE
TESTS
$20M
0.2
$4M
0.07
$1.4M
$0.26M
4- 1.4
= 10
0.26
36
Software Risk Management
10/14/05
©USC-CSE
37
Risk Management Plans
For Each Risk Item, Answer the Following Questions:
1. Why?
Risk Item Importance, Relation to Project Objectives
2. What, When?
Risk Resolution Deliverables, Milestones, Activity Nets
3. Who, Where?
Responsibilities, Organization
4. How?
Approach (Prototypes, Surveys, Models, …)
5. How Much?
Resources (Budget, Schedule, Key Personnel)
10/14/05
©USC-CSE
38
Risk Management Plan: Fault Tolerance
Prototyping
1. Objectives (The “Why”)
– Determine, reduce level of risk of the software fault tolerance features causing
unacceptable performance
– Create a description of and a development plan for a set of low-risk fault tolerance
features
2. Deliverables and Milestones (The “What” and “When”)
– By week 3
1.
2.
3.
4.
5.
Evaluation of fault tolerance option
Assessment of reusable components
Draft workload characterization
Evaluation plan for prototype exercise
Description of prototype
– By week 7
6.
7.
8.
9.
Operational prototype with key fault tolerance features
Workload simulation
Instrumentation and data reduction capabilities
Draft Description, plan for fault tolerance features
– By week 10
10. Evaluation and iteration of prototype
11. Revised description, plan for fault tolerance features
10/14/05
©USC-CSE
39
Risk Management Plan: Fault Tolerance Prototyping (concluded)
•
Responsibilities (The “Who” and “Where”)
– System Engineer: G. Smith
• Tasks 1, 3, 4, 9, 11, support of tasks 5, 10
– Lead Programmer: C. Lee
• Tasks 5, 6, 7, 10 support of tasks 1, 3
– Programmer: J. Wilson
• Tasks 2, 8, support of tasks 5, 6, 7, 10
•
Approach (The “How”)
–
–
–
–
–
•
Design-to-Schedule prototyping effort
Driven by hypotheses about fault tolerance-performance effects
Use real-time OS, add prototype fault tolerance features
Evaluate performance with respect to representative workload
Refine Prototype based on results observed
Resources (The “How Much”)
$60K - Full-time system engineer, lead programmer, programmer (10 weeks)*(3
staff)*($2K/staff-week)
$0K - 3 Dedicated workstations (from project pool)
$0K - 2 Target processors (from project pool)
$0K - 1 Test co-processor (from project pool)
$10K - Contingencies
$70K - Total
10/14/05
©USC-CSE
40
Risk Monitoring
Milestone Tracking
– Monitoring of risk Management Plan Milestones
Top-10 Risk Item Tracking
– Identify Top-10 risk items
– Highlight these in monthly project reviews
– Focus on new entries, slow-progress items
Focus review on manger-priority items
Risk Reassessment
Corrective Action
10/14/05
©USC-CSE
41
Project Top 10 Risk Item List: Satellite Experiment Software
Risk Item
Mo. Ranking
This Last #Mo.
Risk Resolution Progress
Replacing Sensor-Control Software
Developer
1
4
2
Top Replacement Candidate Unavailable
Target Hardware Delivery Delays
2
5
2
Procurement Procedural Delays
Sensor Data Formats Undefined
3
3
3
Action Items to Software, Sensor Teams;
Due Next Month
Staffing of Design V&V Team
4
2
3
Key Reviewers Committed; Need FaultTolerance Reviewer
Software Fault-Tolerance May
Compromise Performance
5
1
3
Fault Tolerance Prototype Successful
Accommodate Changes in Data
Bus Design
6
-
1
Meeting Scheduled With Data Bus
Designers
Testbed Interface Definitions
7
8
3
Some Delays in Action Items; Review
Meeting Scheduled
User Interface Uncertainties
8
6
3
User Interface Prototype Successful
TBDs In Experiment Operational
Concept
-
7
3
TBDs Resolved
Uncertainties In Reusable
Monitoring Software
-
9
3
Required Design Changes Small,
Successfully Made
10/14/05
©USC-CSE
42
Descargar

Manejo de Riesgos de Software