INSTITUTO TECNOLOGICO DE

CHILPANCINGO

INGENIERIA DEL SOFTWARE

INVESTIGACION DOCUMENTAL DEL CONCEPTO DE
RIESGO Y MAPA MENTAL

IVAN ARTURO JUAREZ PARRA










Concepto de Riesgo
Cuando se considera el riesgo en el contexto de la ingeniera del software,
los tres pi lares conceptuales de Charette se hacen continuamente
evidentes. El futuro es lo que nos preocupa, qu riesgos podran hacer
que nuestro proyecto fracasara? El cambio es nuestra preocupacin
cmo afectarn l os cambios en los requisitos del cliente, en las
tecnologas de desarrol lo, en los ordenadores a las que van dirigidas, el
proyecto y todas las entidades relacionadas con l, al cumpli miento de la
planificacin temporal y al xito en general? Para terminar, nos
enfrentamos con elecciones qu mtodos y herramientas deberamos
emplear, cunta gente debera estar i mpli cada, qu i mportancia hay que
darle a la calidad?



1.Estrategias de riesgo reactivas y proactivas

Una estrategia considerablemente ms inteligente para el control del riesgo es ser
proactivo. La estrategia proactiva empieza mucho antes de que comiencen los
trabajos tcnicos. Se identifican los riesgos potenciales, se valoran su probabilidad y
su impacto y se establece una prioridad segn su importancia. Despus el equipo de
software establece un plan para controlar el riesgo. El primer objetivo es evitar el
riesgo, poco comn no se pueden evitar todos los riesgos. el equipo trabaja para
desarrollar un plan de contingencia que le permita responder de una manera eficaz y
controlada. A lo largo de lo que queda de este capitulo, estudiamos la estrategia
proactiva para el control de riesgos.
2.- Riesgos del software

Aunque ha habido amplios debates sobre la definicin adecuada para riesgo de
software, hay acuerdo comn en que el riesgo siempre implica dos caractersticas:
Incertidumbre: El aconteci miento que caracteri za al riesgo puede o no
puede ocurrir; por ejemplo, no hay riesgos de un 100 por ciento de
probabilidad.

Prdida: Si el riesgo se convi erte en una realidad, ocurri rn
consecuencias no deseadas o prdidas.
Cuando se anali zan los riesgos es i mportante cuantifi car el nivel de
incertidumbre y el grado de prdidas asociado con cada riesgo. Para
hacerlo, se consideran diferentes categoras de riesgos.

Los riesgos del proyecto amenazan al plan del proyecto. Es decir, si los
riesgos del proyecto se hacen realidad, es probable que la planificacin
temporal del proyecto se retrase y que los costos aumenten. Los riesgos
del proyecto identifican los problemas potenciales de presupuesto,
planificacin temporal, personal (asignacin y organi zacin), recursos.
cliente y requisitos y su i mpacto en un proyecto de software.

Los riesgos tcnicos amenazan l a cal i dad y la planificaci n temporal del
software que hay que producir. Si un riesgo tcnico se convierte en
realidad, la i mplementacin puede llegar a ser difci l o i mposible. Los
riesgos tcnicos identifi can problemas potencial es de diseo,
i mplementaci n, de interfaz. verificacin y de manteni miento. Adems. las
ambigedades de especificaciones, incertidumbre tcnica, tcnicas
anticuadas y las "tecnologas punta" son tambin factores de riesgo. Los
riesgos tcni cos ocurren porque el problema es ms dif ci l de resolver de
lo que pensbamos.

Los riesgos del negocio amenazan la viabil idad del software a construir
Los riesgos del negocio a menudo ponen en peligro ei proyecto o el
producto.

Los candidatos para los cinco principales riesgos del negocio son:


1. Construir un producto o sistema excelente que no quiere nadie en
realidad (riesgo de mercado),

2. Construir un producto que no encaja en la estrategia comercial
general de la compaa (riesgo estratgico),

3. Construir un producto que ei departamento de ventas no sabe
cmo vender

4. Perder el apoyo de una gestin experta debido a cambios de
enfoque o a cambios de personal (riesgo de direccin)

5. Perder presupuesto o personal asignado (riesgos de presupuesto).
Es extremadamente importante recal car que no siempre funciona una
categorizacin tan sencilla. Algunos riesgos son simplemente
imposibles de predecir.
Otra categori zacin general de los riesgos ha sido propuesta por Charette.
Los riesgos conocidos son todos aquellos que se pueden descubrir
despus de una cui dadosa evaluacin del plan del proyecto. del entorno
tcnico y comercial en el que se desarrolla el proyecto y otras fuentes de
informacin fables (p. ej.: fechas de entrega poco real istas. falta de
especificacin de requisitos o de mbi to del software. o un entorno pobre
de desarrol lo), los riesgos predecibles se extrapolan de la experiencia en
proyectos anteriores (ej.: cambio de personal, mala comunicacin con el
cliente. disminucin del esfuerzo del personal a medida que atienden
peticiones de manteni miento). Pueden ocurrir pero son extremadamente
difci les de identificar por adelantado.


3.- Identificacin del riesgo


La identificacin del riesgo es un intento sistemtico para especificar las
amenazas al plan del proyecto (esti maciones, planifi cacin temporal,
carga de recursos, etc). Identifi cando l os riesgos conocidos y predecibles,
el gestor del proyecto da un paso adelante para evitarlos cuando sea
posible y controlarlos cuando sea necesario.

Existen dos tipos diferenciados de riesgos para cada categora presentada
en el apartado anterior: genri cos y especficos del producto. Los riesgos
genricos son una amenaza potencial para todos los proyectos de
software. Los especficos de producto slo los pueden identificar los que
tienen una clara vi si n de la tecnologa. el personal y el entomo especfico
del proyecto en cuestin. Para identificar los riesgos especficos del
producto se examinan el plan del proyecto y la declaracin del mbito del
software y se desarrolla una respuesta a la siguiente pregunta: Qu
caractersticas especiales de este producto pueden estar amenazadas por
nuestro plan del proyecto' ?"

Tanto los riesgos genricos como los especficos del producto se deberan
identificar sistemti camente. Tom Gilb tiene toda la razn cuando dice: "Si
no atacas activamente a los riesgos. ell os te atacarn activamente a ti",
Un mtodo para identificar riesgos es crear una li sta de comprobacin de
elementos de riesgo. La lista de comprobacin se puede util i zar para
identificar riesgos y se enfoca en un subconjunto de riesgos conocidos y
predecibles en las siguientes subcategoras genri cas:
Tamao del producto: riesgos asociados con el tamao general del
software a construi r o a modificar.

Impacto en el negocio: riesgos asociados con las l i mitaci ones i mpuestas
por la gestin o por el mercado.

Caractersticas del cliente: riesgos asociados con la sofisti cacin del
cliente y la habil idad del desarrol lador para comunicarse con el cliente en
los momentos oportunos.

Defini cin del proceso: riesgos asociados con el grado de definicin del
proceso del software y su segui miento por la organi zacin de desarrol lo.

Entorno de desarrollo: riesgos asociados con la disponibi lidad y cal idad
de las herramientas que se van a emplear en la construccin del producto.

Tecnologa a construir: riesgos asociados con la compleji dad del sistema
a construi r y la tecnologa punta que contiene el sistema.

Tamao y experiencia de la planti lla: riesgos asociados con la
experiencia tcnica y de proyectos de los ingenieros del software que van
a reali zar el trabajo.

La lista de comprobacin de elementos de riesgo puede organi zarse de
diferentes maneras. Se pueden responder a cuestiones relevantes de cada
uno de los temas apuntados anteriormente para cada proyecto de
software. Las respuestas a estas preguntas permiten al planificador del
proyecto esti mar el i mpacto del riesgo. Un f ormato diferente de lista de
comprobacin de el ementos de riesgo contiene si mplemente las
caractersticas relevantes para cada subcategora genrica. Final mente,
se lista un conjunto de "componentes y controladores del ri esgo" junto con
sus probabil idades de aparicin. Los controladores del rendi miento, el
soporte, el coste y l a planificacin temporal del proyecto se estudian como
respuesta a preguntas posteriores.

3.1.- Riesgos del tamao del producto

Pocos gestores experi mentados di scuti ran la siguiente frase: El riesgo del
proyecto es di rectamente proporcional al tamao dcl producto. La
siguiente l ista de comprobacin de elementos de riesgo identifica riesgos
genricos asociados con el tamao del producto (software):

Tamao esti mado del producto en LDC o FP?

Grado de seguridad en la esti macin del tamao?

Tamao esti mado del producto en nmero de programas, archi vos y
transacciones?

Porcentaje de desviacin en el tamao del producto respecto a la
medida de productos anteriores?

Tamao de la base de datos creada o empleada por el producto?

Nmero de usuarios del producto?

Nmero de cambios previstos a los requisitos del producto? Antes de
la entrega? Despus de la entrega?

Cantidad de software reutil i zado?
En cada caso, la informacin del producto a desarrol lar debe compararse
con la experiencia anterior. Si ocurre una gran desviacin del porcentaje o
si las magnitudes son si milares. pero si los resultados anteriores fueron
poco satisfactorios, el riesgo es grande.


3.2.- Riesgos del impacto en el negocio

Un gestor de ingeni era (algo magufo) de una gran compaa de software
coloc una placa con el texto: "dios me concedi el cerebro para ser un
buen jefe de proyectos y el sentido comn para correr como un diablo
cuando marketing establece las fechas lmite del proyecto!". Al
departamento de marketing le guan las consideraciones del negocio, y
stas entran a veces en conflicto directo con las real idades tcnicas. La
siguiente l ista de comprobacin de elementos de riesgo identifica riesgos
genricos asociados con el i mpacto en el negocio:

Efecto de este producto en los ingresos de la compaa?

Viabi lidad de este producto para los gestores expertos?

Es razonable la fecha lmite de entrega?

Nmero de cl i entes que usarn este producto y la consistencia de sus
necesidades relativas al producto?

Nmero de otros productos/sistemas con los que este producto debe
tener interoperatividad?

Sofisticacin del usuario final?

Cantidad y calidad de la documentaci n del producto que debe ser
elaborada y entregada al cliente?

Li mitaciones gubernamentales en la construccin del producto?

Costos asociados por un retraso en l a entrega?

Costos asociados con un producto defectuoso?
Cada respuesta para el producto a desarrol lar debe compararse con la
experiencia anterior. Si se obtiene una gran desviacin del porcentaje o si
las magnitudes son si milares, pero los resultados anteriores fueron poco
satisfactorios, el riesgo es grande.

3.3.- Riesgos relacionados con el cliente

No todos los clientes son iguales. Pressman y Herron tratan este aspecto
cuando dicen: Los clientes tienen diferentes necesidades. Algunos saben
lo que quieren; otros saben lo que no quieren. Algunos estn deseando
saber todos los detalles, mientras que otros se quedan satisfechos con
vagas promesas.

Los clientes tienen diferentes personal i dades. Algunos disfrutan siendo
clientes (la tensin, la negociacin, las recompensas psicolgicas de un
buen producto).

Otros preferi ran no ser cl ientes en absoluto. Algunos aceptaran
feli zmente cualquier cosa que se les entregara y le sacaran el mejor
provecho a un producto pobre. Otros se quejarn amargamente cuando les
falte calidad; algunos darn las gracias cuando la calidad es buena; unos
pocos se quejarn por todo.

Los clientes tambin tienen varios tipos de asociaciones con sus
sumini stradores. Al gunos conocen bien a sus proveedores y sus
productos; otros no se han visto nunca l as caras y se comunican siempre
mediante correspondencia escrita y algunas llamadas telefnicas breves.

Los clientes se contradicen a menudo. Quieren todo para ayer y gratis. A
menudo, el producto se ve cogido entre las propias contraindicaciones del
cliente.

Un "mal" cliente puede tener un profundo i mpacto en la habilidad del
equipo de software para completar el proyecto a tiempo y dentro de
presupuesto. Un mal cl iente representa una amenaza signifi cativa al plan
del proyecto y un sustancial riesgo para el jefe del proyecto. La siguiente
lista de comprobaci n de elementos de riesgo identifica riesgos genricos
asociados con diferentes clientes:

Ha trabajado con el cl iente anteriormente?

Tiene el cl iente una idea formal de lo que se requiere? Se ha
molestado en escribirlo?

Aceptar el cl iente gastar su tiempo en reuniones formal es de
requisitos para identificar el mbito del proyecto?

Est dispuesto el cliente a establecer una comunicacin fluida con el
desarrolador?

Est dispuesto el cliente a participar en las revisiones?

Es sofisti cado tcnicamente el rea del producto?

Est dispuesto el cliente a dejar a su personal hacer el trabajo? Es
decir, resisti r la tentacin de mi rar por enci ma del hombro durante el
trabajo tcnico?

Entiende el cliente el proceso del software?

Si la respuesta a al guna de estas preguntas es "no", se debera hacer una
investigacin ms profunda para valorar el potencial de riesgo.

3.4.- Riesgos del proceso

Si el proceso del software no est bien definido; si el anlisis, diseo y
pruebas se real i zan sobre la marcha; si la calidad es un concepto que
todo el mundo esti ma i mportante, pero por la que nadie acta de manera
tangible para alcanzarla, entonces el proyecto est en peligro. Las
siguientes preguntas se han extrado sobre la evaluacin de la i ngeniera
del software desarrollado por R. S. Pressman & Associates. Inc. Las
preguntas se han adaptado del cuestionario de evaluacin del proceso del
software del Instituto de Ingeniera del Software (IIS).

Aspectos del proceso
Apoyan sus gestores senior unas normas escritas que hagan hincapi
en la i mportancia de un proceso estndar para el desarrol l o del software?

Ha desarrol lado su organi zacin una descripcin escrita del proceso del
software a emplear en este proyecto?

Estn de acuerdo los miembros del personal con el proceso del
software tal y como est documentado y estan dispuestos a usarlo?

Se emplea este proceso del software para otros proyectos?

Ha desarrol lado o adquirido su organi zacin cursos de formacin de
ingeniera del software para jefes de proyecto y personal tcnico?

Se ha proporcionado una copia de los estndares de ingeniera del
software publicados a cada desarrol lador y gestor de software?

Se han desarrol l ado diseos de documentos y ejemplos para todas las
entregas definidas como parte del proceso del software?

Se llevan a cabo regularmente revi si ones tcnicas formales de las
especificaciones de requisitos, diseo y cdigo?

Se llevan a cabo regularmente: revi si ones tcnicas de los
procedi mientos de prueba y de los casos de prueba?

,Se documentan todos los resultados de las revisiones tcnicas,
incluyendo los errores encontrados y recursos empleados?

Exi ste algn mecanismo para asegurarse de que el trabajo real i zado en
un proyecto se ajusta a l os estndares de ingeniera del software?

Se emplea una gestin de configuracin para mantener l a consistencia
entre los requi sitos del sistema/software, diseo, cdigo y casos de
prueba?

Hay algn mecanismo de control de cambios de los requi sitos del
cliente que i mpacten en el software?

Hay alguna declaracin de trabajo documentada, una especificacin de
requisitos software y un plan de desarrollo del software para cada
subcontratacin?

Se sigue algn procedi miento para hacer un segui miento y revi sar el
rendi miento de las subcontraciones?

Aspectos tcnicos

Se emplean tcni cas de especifi cacin de aplicaciones para ayudar en
la comuni cacin entre el cliente y el desarrol lador?

Se emplean mtodos especficos para el anlisis del software?

Emplea un mtodo especfico para el diseo de datos y arquitectnico?

Est escrito su cdigo en ms de un 90 por ciento en lenguaje de alto
nivel?

Se han definido y empleado reglas especficas para la documentacin
del cdigo?

Emplea mtodos especficos para el diseo de casos de prueba?

Se emplean herramientas de software para apoyar la planificacin y el
segui miento de las actividades?

Se emplean herramientas de software de gestin de configuracin para
controlar y segui r los cambios a lo largo de todo el proceso del software?

Se emplean herramientas de software para apoyar los procesos de
anlisi s y diseo del software?

Se emplean herramientas para crear prototipos software?

Se emplean herramientas de software para dar soporte a los procesos
de prueba?

Se emplean herramientas de software para soportar la produccin y
gestin de la documentacin?

Se han estableci do mtri cas de cal idad para todos los proyectos de
software?

Se han estableci do mtri cas de productividad para todos los proyectos
de software?
Si la mayora de las cuestiones anteriores se han respondido
negativamente, el proceso del software es dbil y el riesgo es alto.

3.5.- Riesgos tecnol gicos
Alcanzar los lmites de la tecnologa es un reto excitante. Es el sueo de
casi todos los tcni cos, porque fuerza al profesional a emplear su talento
al mxi mo. Pero tambin es muy arriesgado. La ley de Murphy parece
mantener su i mperi o en esta parte del universo del desarrollo, haciendo
extremadamente difcil predeci r los riesgos, y mucho menos hacer ningn
plan sobre ellos. La siguiente l ista de comprobacin de elementos de
riesgo identifica riesgos genricos asoci ados con la tcnica a construi r.

Es nueva para su organi zacin la tecnologa a construi r?

Demandan los requisitos del cl iente l a creacin de nuevos algoritmos o
tecnologa de entrada o salida?

El software interacta con hardware nuevo o no probado?

Interacta el software a construir con productos software sumini strados
por el vendedor que no se hayan probado?

Interacta el software a construir con un sistema de base de datos cuyo
funcionamiento y rendi miento no se han comprobado en esta rea de
aplicacin?

Demandan los requisitos del producto una interfaz de usuar io especial?

Demandan los requisitos del producto la creacin de componentes de
programacin distintos de; los que su organi zacin haya desarrollado
hasta ahora?

Demandan los requisitos el empleo de nuevos mtodos de anlisis,
diseo o pruebas?

Demandan los requisitos el empleo de mtodos de ' desarrollo del
software no convencionales, tales como los mtodos formales, enfoques
basados .... en IA y redes neuronales? Imponen excesi vas restricciones
de rendi miento los requisitos del producto?

No est seguro el cl iente de que la funcionalidad pedida sea factible?

Si la respuesta a al guna de estas preguntas es afirmativa, se debera
reali zar una investigacin ms profundidad para valorar el ri esgo
potencial.



3.6.- Riesgos del entorno de desarrollo

Si a un carpintero se le pidiera que construyera un mueble de calidad con
una si mple sierra de mano, se dudara de la calidad del producto final. Las
herramientas inapropiadas o ineficaces pueden estropear los esfuerzos de
incluso un experi mentado profesional.

El entorno de ingeni era del software soporta al equipo del proyecto. al
proceso y al producto. Pero si el entomo es malo. puede ser una fuente de
riesgos significativa. La siguiente li sta de comprobacin de elementos de
riesgo identifica riesgos genricos asoci ados com el entomo de
desarrol lo:

Tenemos disponi ble una herramienta de gestin de proyectos de
software?

Tenemos disponi ble una herramienta de gestin del proceso del
software?

Exi sten herramientas de anlisis y di seo disponibles?

Proporcionan las herramientas de anlisis y di seo, mtodos
apropiados para el producto a construi r?

Hay disponible? compiladores o generadores de cdigo apropiados
para el producto a construir?

Hay disponibles herramientas de pruebas apropiadas para el producto a
construi r?

Tenemos disponi bles herramientas de gestin de configuracin
software?

Hace uso el entorno de bases de datos o informacin al macenada?

Estn todas las herramientas de software integradas entre s?

Se ha formado a los miembros del equipo del proyecto en todas las
herramientas,?

Exi sten expertos disponibles para responder todas las preguntas que
surjan sobre las herramientas?

Es adecuada la ayuda en lnea y la documentacin de l as
herramientas?

Si se ha contestado negativamente a la mayora de las preguntas
anteriores, el entomo de desarrollo es dbil y el riesgo es al to.


3.7.- Riesgos asociados con el tamao de la plantilla de personal y su
experiencia:

Bohem sugiere las si guientes cuestiones para valorar los riesgos
asociados con el tamao de la plantil la de personal y su experiencia:


Disponemos de l a mejor gente?

Tiene el personal todos los conoci mi entos adecuados?

Tenemos suficiente personal?

Se ha asignado al personal para toda la duracin del proyecto?

Habr parte del personal del proyecto que trabaje slo durante parte de
l?

Dispone el personal de las expectati vas correctas sobre el trabajo?

Ha recibido el personal la formacin adecuada?

Ser mni mo el movi miento del personal para permiti r la continuidad?
Si la respuesta a al guna de estas preguntas es "no", se debera hacer una
investigacin ms profunda para valorar el potencial de riesgo.


3.8.- Componentes y controladores del riesgo

Las Fuerzas Areas de Estados Unidos han redactado un documento que
contiene excelentes directri ces para identificar riesgos software y
evitarlos. El enfoque de las Fuerzas Areas requiere que el gestor del
proyecto identifique los controladores del ri esgo que afectan a los
componentes de riesgo software (rendi miento, coste, soporte y
planificacin temporal). En el contexto de este estudio, los componentes
de riesgo se definen de la siguiente manera:

Riesgo de rendi mi ento: el grado de incertidumbre con el que el producto
encontrar sus requisitos y se adecue para su empl eo pretendido.

Riesgo de coste: el grado de i ncertidumbre que mantendr el
presupuesto del proyecto.

Riesgo de soporte: el grado de incerti dumbre de la facil idad del software
para corregi rse, adaptarse y ser mejorado.

Riesgo de la planificacin temporal: el grado de incertidumbre con que
se podr mantener la planificacin temporal y de que el producto se
entregue a tiempo.


El i mpacto de cada controlador de riesgo en el componente de riesgo se
divide en cuatro categoras de i mpacto -despreciable. marginal, crtico y
catastrfi co. La figura indica las consecuencias potenci ales de errores
(fi las etiquetadas con 1) o la i mposibil idad de conseguir el producto
deseado (filas etiquetadas con 2) La categora de impacto es elegida
basndose en la caracteri zacin que mejor encaja con la descripcin de la
tabla.

4.- Proyeccin del riesgo


La proyeccin del riesgo, tambin denominada esti macin del riesgo,
intenta medi r cada riesgo de dos maneras -la probabil idad de que el
riesgo sea real y l as consecuencias de los problemas asociados con el
riesgo, si ocurriera. El jefe del proyecto, junto con otros gestores y
personal tcnico, reali za cuatro activi dades de proyeccin del riesgo: (1)
establecer una escala que refleje la probabilidad percibida del riesgo; (2)
definir las consecuencias del riesgo; (3) esti mar el i mpacto del riesgo en
el proyecto y en el producto; y (4) apuntar la exactit ud general de la
proyeccin del riesgo de manera que no haya confusiones.