INGENIERÍA DE SOFTWARE CURSO 2005 PRÁCTICA 2 Parte Uno = Gestión de riesgo

Anuncio
INGENIERÍA DE SOFTWARE
CURSO 2005
PRÁCTICA 2
Parte Uno = Gestión de riesgo
1. Proporcione un ejemplo donde se utilice una política reactiva de
tratamiento de riesgos y que muestre los inconvenientes que
pueden surgir. Es posible encontrar un ejemplo donde la política
reactiva funciones de manera aceptable? (trate de encontrarlo)
2. Describa la diferencia entre un “riesgo conocido” y un “riesgo
predecible”.
3. Los tipos de riesgos que pueden aparecer en un proyecto de
software dependen de éste y el entorno de la organización que
resuelve el problema. Sin embargo existen algunos riesgos que
pueden catalogarse de universales, a continuación se describen
algunos de ellos, su tarea es identificar el impacto que podría
tener, si es un riesgo asociado al proyecto, al producto o al
negocio y un posible plan de contingencia. Para ello puede ser
necesario que enmarque el riesgo dentro de un proyecto.
a. Rotación del personal (deja el proyecto antes que este
finalice)
b. Cambio de administración en la organización
c. Cambio en los requerimientos
d. Retrasos en la especificación
e. Subestimación de tamaño
f. Bajo desempeño de las herramientas de software
g. Cambio de tecnología
h. Competencia del producto.
4. Describa dos riesgos asociados a cada uno de los siguientes tipos,
defina la probabilidad de ocurrencia que podrían tener en un
proyecto de gestión que Ud. inicie. Para ello, y de acuerdo a su
experiencia práctica, catalóguese como: principiante (solo hice
sistemas en la Universidad), intermedio (resolví algún problema
sencillo de la vida real), con experiencia (resolví más de tres
problemas de la vida real). Los tipos de riesgo son:
a. Tecnológicos
b. Organizacionales
c. Personal (de desarrollo)
d. Estimación
e. Requerimientos
f. Herramientas
5. Se le ha pedido que construya un software que soporte la
liquidación de sueldos para cualquier empresa PYME de la
Argentina. El propósito es generar un equivalente al Tango, que
sea configurable por cada usuario (de manera de adaptarlo a sus
necesidades) y que además respete los convenios colectivos de
diferentes asociaciones gremiales.
Además, se piensa ir
incorporando al sistema nuevos convenios los que estarán
disponibles en diferentes versiones de la herramienta generada.
Realizando todas las suposiciones que considere oportunas defina
una lista de riesgos asociados a la construcción de este software,
para ello puede considerar que trabaja en equipo y UD define la
modalidad de trabajo.
6. UD es el jefe de proyectos de una gran compañía de software. Se
le ha pedido que dirija a un equipo que está desarrollando un
software de un procesador de texto de última generación (se
describe a continuación sus principales características).
Construya una tabla de riesgos para el proyecto.
ENTRE LAS CARACTERÍSTICAS PECULIARES DEL PRODUCTO ESTÁN LA
INTRODUCCIÓN DE INFORMACIÓN A TRAVÉS DE LA VOZ ASÍ COMO DEL
TECLADO; CARACTERÍSTICAS EXTREMADAMENTE SOFISTICADAS DE
EDICIÓN AUTOMÁTICA DE COPIA; CAPACIDAD DE DISEÑO DE PÁGINA;
INDEXACIÓN AUTÁTICA Y TABLA DE CONTENIDOS.
7. A continuación se transcribe un fragmento (pag. 148 y 149
Ingeniería de Software. Teoría y Práctica, Pfleeger) de un ejemplo
de un sistema que falló. Esta información es correcta y extraída
del problema concreto.
LA JUNTA INVESTIGADORA D ELA FALLA DEL ARIANE-5, EXAMINÓ EL
SOFTAWARE, LA DOCUMENTACIÓN Y LOS DATOS OBTENIDOS ANTES Y
DURANTE EL VUELO PARA DETERMINAR QUE PROVOCÓ LA FALLA. SU
INFORMESEÑALA QUE LA LANZADERA COMENZÓ A DESINTEGRARSE 39
SEGUNDOS DESPUÉS DEL LANZAMIENTO DEBIDO A QUE EL ÁNGULO DE
ATAQUE SUEPRABA LOS 20 GRADOS, HACIENDO SEPARAR A LOS
IMPULSORES DE LA ETAPA PRINCIPAL DEL COHETE: ESTA SEPARACIÓN
DISPARÓ LA AUTODESTRUCCIÓN DE LA LANZADERA. EL ÁNGULO DE
ATAQUE
ESTABA
DETERMINADO
POR
EL
SOFTWARE
DE
LA
COMUPTADORA DE A BORDO,
SOBRE LA BASE DE DATOS
TRANSAMITIDOS POR EL SISTEMA DE REFERENCIA INICIAL ACTIVO, SRI2.
COMO SEÑALA EL INFORME SE SUPONÍA QUE SRI2 CONTENÍA DATOS DE
VUELO VÁLIDOS, PERO EN REALIDAD CONTENÍA UN PATRÓN DE BITS DE
DIAGNÓSTICO QUE FUE ERRÓNEAMENTE INTERPRETADO COMO DATOS
DE VUELO. LOS DATOS ERRÓNEOS SE INTEPRETARON COMO UNA FALLA
Y EL SRI2 SE DETUVO. NORMALMENTE LA COMPUTADORA DE A BORDO
HABRÍA CONMUTADO A OTRO SISTEMA INERCIAL DE REFERENCIA SRI1,
PERO ÉSTE TAMBIÉN ESTABA DETENIDO POR LA MISMA RAZÓN.
EL ERROR SE PRODUJO EN UN MÓDULO DE SOFTWARE QUE CALCULABA
RESULTADOS SIGNIFICATIVOS SOLAMENTE ANTES DEL DESPEGUE. TAN
PRONTO COMO EL LANZADOR DESPEGÓ, LA FUNCIÓN EJECUTADA POR
ESTE MÓDULO NO SERVÍA A PROPÓSITO ÚTIL ALGUNO, DE MODO QUE YA
NO ERA NECESARIO PARA EL RESTO DEL SISTEMA. SIN EMBARGO, EL
MÓDULO CONTINUÓ SUS CÓMPUTODS POR APROXIMADAMENTE 40
SEGUNDOS DE VUELO BASÁNDOSE EN UN REQUERIMIENTO PARA EL
ARIANE-4 QUE NO ERA NECESARIO EN EL ARIANE-5.
LOS EVENTOS INTERNOS QUE CONDUJERON A LA FALLA FUERON
REPRODUCIDOS POR CÁLCULOS DE SIMULACIÓN SOPORTADOS PRO
LECTURAS DE MEMORIA E INVESTIGACIÓN DEL SOFTWARE. POR LO
TANTO, LA DESTRUCCIÓN DEL ARIANE-5 PODRÍA HABERSE PREVENIDO SI
LOS GERENTES DEL PROYECTO HUBIERAN DESARROLLADO UN PALN DE
GESTIÓN DE RIESGOS, LO HUBIERAN REVISADO Y HUBIERAN
DESARROLLADO PLANES QUE EVITARAN O MITIGARAN EL RIESGO DE
CADA FACTOR IDENTIFICADO. LA PRIMERA ETAPA ES LA IDENTIFICACIÓN
DE RIESGOS.
EL PROBLEMA POSIBLE CON LA REUTILIZACIÓN DEL
SOFTWARE DEL ARIANE-4 PODRÍA HABER SE IDENTIFICADO MEDIANTE
UNA DESCOMPOSICIÓN DE FUNICIONES: ALGUIEN HABRÍA RECONOCIDO
TEMPRANAMENTE QUE LOS REQUERIMIENTOS DEL ARIANE-5 ERAN
DIFERENTES DE LOS DEL ARIANE-4. O UN ANÁLISIS DE LAS
SUPOSICIONESHABRÍA REVELADOQUE LOS SUPUESTOS PARA EL SRI EN
ARIANE-4 ERAN DIFERENTES DE AQUELLOS PARA EL ARIANE-5……el
problema sigue.
A su juicio que riesgos deberían haberse identificados como
más importantes y, someramente, describa los planes de
contingencia. Luego determine los riesgos potenciales, que
quizá quedaron por debajo de la línea de corte, que se
generaron a partir de la destrucción de Ariane-5.
8. En que contexto un riesgo puede llevar a la cancelación de un
proyecto. Cancelar un proyecto es equivalente a no llevarlo a
cabo?
9. Muestre con un ejemplo un proyecto en el que UD decide no
aceptarlo como resultado del análisis de riesgo.
10. Como afecta al análisis de riego a la calidad y viceversa?.
Parte Dos = Planificación y calidad
Algunas consideraciones: los ejercicios que se plantean a continuación necesitan de
investigación para poder ser respondidos correctamente. La bibliografía de IS e
Internet son buenas fuentes de información.
11. ¿Que es la planificación?
¿Qué son los hitos en la
planificación? ¿Para que sirven?
12. ¿Cómo afecta la planificación a la calidad y viceversa?
13. Los límites irracionales son un hecho consumado del negocio
del software, ¿Cómo procedería si se encuentra en esta
situación?
14. ¿Hay algún caso en el que un hito de un proyecto no está
sujeto a una revisión? Si es así, proporciones ejemplos.
15. Utilizando una herramienta adecuada, por ejemplo MSProyect, desarrolle la planificación del problema 5. Para ello
plantee todas la actividades que involucra el proceso de
Ingeniería del sistema, y determine:
a. los plazos de ejecución de cada tarea
b. El personal involucrado (para ello defina previamente su
plantilla de personal, y disponibilidad de la misma).
c. El hardware necesario y su disponibilidad.
d. Plantee una fecha temprana, una tardía y una óptima.
Por último, discuta los resultados obtenidos con sus
compañeros.
16. Ídem anterior pero utilizando ahora el ejercicio 6.
Descargar