Está en la página 1de 21

www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968

B2G1T01 - CONCEPTO DEL CICLO DE VIDA DE LOS SISTEMAS Y FASES.

1. INTRODUCCIN.............................................................................................................................................................. 2
1.1. LA EVOLUCIN DEL SOFTWARE .......................................................................................................................... 2
1.2. CARACTERSTICAS ESPECIALES DEL SOFTWARE ........................................................................................... 2
1.3. LA CRISIS DEL SOFTWARE ................................................................................................................................. 3
1.4. INGENIERA DEL SOFTWARE ................................................................................................................................ 3
2. CONCEPTO DEL CICLO DE VIDA Y FASES ............................................................................................................. 4
2.1 PROCESOS DEL CICLO DE VIDA SOFTWARE...................................................................................................... 4
2.2 PROCESOS PRINCIPALES........................................................................................................................................ 4
2.3 PROCESOS DE SOPORTE ......................................................................................................................................... 5
2.4 PROCESOS DE LA ORGANIZACIN ...................................................................................................................... 6
2.5 PROCESO DE ADAPTACIN ................................................................................................................................... 6
3. MODELO EN CASCADA................................................................................................................................................. 7
3.1. FASES DEL MODELO EN CASCADA...................................................................................................................... 7
3.1.1 PLANIFICACIN................................................................................................................................................. 7
3.1.2 ESPECIFICACIN DE REQUISITOS ANLISIS FUNCIONAL...................................................................... 8
3.1.3 DISEO ANLISIS ORGNICO....................................................................................................................... 8
3.1.4 CODIFICACIN - PROGRAMACIN ................................................................................................................ 9
3.1.5 PRUEBAS E INTEGRACIN............................................................................................................................... 9
3.1.6 IMPLANTACIN Y ACEPTACIN ..................................................................................................................... 9
3.1.7 MANTENIMIENTO ............................................................................................................................................ 10
3.2 LA DOCUMENTACIN........................................................................................................................................... 10
3.3 CRTICA DEL MODELO.......................................................................................................................................... 11
3.4 EXTENSIONES AL MODELO EN CASCADA ....................................................................................................... 11
4. MODELO EN ESPIRAL DEL CICLO DE VIDA ........................................................................................................ 12
4.1 INTRODUCCIN...................................................................................................................................................... 12
4.2 EJEMPLO DE APLICACIN DEL MODELO EN ESPIRAL .................................................................................. 14
CICLO 0: ESTUDIO DE VIABILIDAD................................................................................................................................ 14
4.3 EVALUACIN DEL MODELO................................................................................................................................ 15
4.3.1 VENTAJAS.......................................................................................................................................................... 15
4.3.2 DIFICULTADES ................................................................................................................................................ 16
4.4 EL PLAN DE GESTIN DE RIESGO....................................................................................................................... 17
5. CONCLUSIN ................................................................................................................................................................. 18
6. BIBLIOGRAFA .............................................................................................................................................................. 18
7. ESQUEMA RESUMEN ................................................................................................................................................ 19

TEMARIO-TICB-feb04 B2G1T01
Actualizado en febrero de 2004 Pgina 1 de 21
www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968

1. INTRODUCCIN

En este tema se va a dar una visin de lo que se llama ciclo de vida del software, as como distintos modelos de
representacin del mismo.

Para qu un ciclo de vida? En un departamento de sistemas de informacin de una empresa es necesario


establecer lo que llamamos un marco de referencia comn que pueda ser empleado por todas las personas que
participan en el desarrollo de un proyecto informtico: directivos, consultores externos e internos, jefes de
proyecto, analistas, programadores, usuarios, etc.

En este marco de referencia deben estar claramente definidos los procesos, actividades y tareas a desarrollar.

Veamos primeramente dos definiciones publicadas por dos organismos internacionales:

Norma IEEE 1074: Se entiende por ciclo de vida del software una aproximacin lgica a la
adquisicin, el suministro, el desarrollo, la explotacin y el mantenimiento del software.
Norma ISO 12207-1: Se entiende por modelo de ciclo de vida un marco de referencia que contiene
los procesos, las actividades y las tareas involucradas en el desarrollo, la explotacin y el
mantenimiento de un producto de software, abarcando la vida del sistema desde la definicin de
requisitos hasta la finalizacin de su uso.

1.1. LA EVOLUCIN DEL SOFTWARE

El concepto de ciclo de vida se utiliz para modelar el proceso de ingeniera del software que, a su vez, apareci
como solucin a la llamada crisis del software.

Veamos un poco de historia. El desarrollo del software ha ido en paralelo con la evolucin de los sistemas
informticos, los cuales han ido mejorando notablemente debido al aumento de la potencia del hardware, a la
reduccin de su tamao y la disminucin de su coste econmico.

Siguiendo a Presmann podemos distinguir las siguientes etapas en la evolucin del software:

1 Etapa: Primeros aos de la informtica (1950-1965). El hardware sufri numerosos cambios. Se desarrollaba
software sin planificacin y sin metodologas sistemticas. En casi todos los sistemas se utilizaba programacin
en batch. La mayora del software era desarrollado y utilizado por la misma persona.

2 Etapa: (1965-1980). Aparicin de la multiprogramacin y de los sistemas multiusuario. Como consecuencia de


la interactividad de los sistemas aparecen nuevos tipos de aplicaciones. Surgen, asimismo, los sistemas en
tiempo real. Tambin los primeros gestores de bases de datos.

3 Etapa: (1975-1985). Aparecen los sistemas distribuidos, redes de rea local LAN y de rea global WAN. Hay
una fuerte presin sobre los desarrolladores de software. Los ordenadores personales impulsan el crecimiento de
muchas compaas de software.

4 Etapa: (1985- ). Tecnologas de cuarta generacin. Tecnologas orientadas a objetos.

1.2. CARACTERSTICAS ESPECIALES DEL SOFTWARE

Existen caractersticas propias del software que lo diferencian de otros productos:

El software no se fabrica en un sentido clsico, sino que se desarrolla: Si bien existen similitudes con
la fabricacin del hardware, se trata de actividades fundamentalmente diferentes. Tanto en una como
en otra la buena calidad se adquiere mediante un buen diseo pero la fabricacin del hardware es
muy diferente de la del software y puede introducir problemas de calidad que no existen o son
fcilmente corregibles en el software. Ambas actividades requieren la construccin de un producto

TEMARIO-TICB-feb04 B2G1T01
Actualizado en febrero de 2004 Pgina 2 de 21
www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968

pero con mtodos muy diferentes. Los costes del desarrollo del software estn en la ingeniera por lo
que no se pueden gestionar como si fueran clsicos proyectos de fabricacin.
El software no se estropea: El hardware se deteriora con el paso del tiempo y con el uso. Los
errores no detectados del software provocarn fallos al principio de su vida. Sin embargo, una vez
corregidos deberan desaparecer los fallos y no aparecer nuevos. No obstante la realidad suele ser
diferente. El software sufre a lo largo de su vida modificaciones y al introducir estos cambios suelen
producirse nuevos fallos que, a su vez, tienen que ser corregidos y as sucesivamente.
La mayor parte del software se construye a medida, en lugar de ensamblar componentes como hace
la industria: En la fabricacin del hardware, la reutilizacin de componentes es una parte natural del
proceso de ingeniera. En el mundo del software es algo que slo ha comenzado a lograrse
recientemente.

1.3. LA CRISIS DEL SOFTWARE

Desde que se empez a desarrollar software a gran escala empezaron a ser comunes una serie de problemas:

La planificacin resultaba ser muy imprecisa. Los plazos de entrega eran superados en la mayora de
los casos.
El coste final de los proyectos era frecuentemente mucho mayor que el previsto.
La productividad era muy baja.
La calidad del producto entregado era, asimismo, muy baja.
El cliente sola quedar insatisfecho del producto.
El software era difcil de mantener.

Hay que aadir que el conjunto de problemas encontrados en el desarrollo del software no se limitan al software
que no funciona correctamente. La llamada crisis abarca los problemas asociados a cmo desarrollar software,
como mantener el volumen cada vez mayor de software existente y cmo poder mantenernos al corriente de la
demanda creciente de software.

1.4. INGENIERA DEL SOFTWARE

La Ingeniera del Software surge de la necesidad de sistematizar el desarrollo del software afectado por la
llamada crisis del software, aplicando principios de ingeniera para poder obtener software de calidad.

Qu es software de calidad ? Si asumimos que el software cumple con la funcionalidad requerida, para que sea
de calidad deber tener las caractersticas siguientes:

El software debe ser mantenible. Deber estar escrito y documentado de forma tal que las
modificaciones se puedan realizar con el menor coste posible. Esto es fundamental ya que la mayor
parte del coste asociado del software se produce despus de su puesta en funcionamiento.
El software debe ser fiable. Es decir, debe comportarse como esperan los usuarios y no debe fallar
ms de lo permitido por la especificacin.
El software debe ser eficiente.
Debe ofrecer una interfaz de usuario apropiada.

TEMARIO-TICB-feb04 B2G1T01
Actualizado en febrero de 2004 Pgina 3 de 21
www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968

2. CONCEPTO DEL CICLO DE VIDA Y FASES

Podemos definir ciclo de vida de un sistema de informacin como el conjunto de etapas por las que atraviesa el
sistema desde su concepcin, hasta su retirada de servicio pasando por su desarrollo y explotacin.

A veces tambin se habla de ciclo de desarrollo, que es un subconjunto del anterior que empieza en el anlisis y
finaliza con la entrega del sistema al usuario.

Existen diferentes modelos de ciclo de vida o sea distintas pautas a seguir en el desarrollo de los sistemas de
informacin. Ms adelante estudiaremos dos, el llamado modelo clsico o en cascada y el modelo en espiral.

Tres son los objetivos bsicos que cualquier modelo de ciclo de vida debe cubrir:

Definir las actividades a realizar y su orden.


Asegurar la consistencia con el resto de los sistemas de informacin de la organizacin.
Proporcionar puntos de control para la gestin del proyecto (presupuesto y calendario).

2.1 PROCESOS DEL CICLO DE VIDA SOFTWARE

Segn la Norma ISO 12207-1, las actividades a realizar durante el ciclo de vida del software se agrupan en cinco
procesos principales, ocho procesos de soporte y cuatro procesos de la organizacin, as como un proceso
especial que permite adaptar el ciclo de vida a cada proyecto concreto.

A destacar que la norma no recomienda ningn modelo concreto de ciclo de vida, ni de gestin del software, ni
detalla cmo realizar ninguna de las actividades.

2.2 PROCESOS PRINCIPALES

Son aquellos que resultan tiles a las personas que inician o realizan el desarrollo, la explotacin o el
mantenimiento del software a lo largo del ciclo de vida. Estas personas son los compradores, los proveedores, el
personal de desarrollo, los usuarios y el personal encargado del mantenimiento del software.

TEMARIO-TICB-feb04 B2G1T01
Actualizado en febrero de 2004 Pgina 4 de 21
www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968

Proceso de adquisicin: Contiene las actividades y tareas que el comprador, el cliente o el usuario realizan para
adquirir un sistema o un producto software. Aqu estn incluidos la preparacin y publicacin de una solicitud de
ofertas, la seleccin del proveedor del software y la correspondiente gestin de los procesos desde la adquisicin
hasta la aceptacin del producto.

Proceso de suministro: Contiene las actividades y tareas que el suministrador o proveedor realiza. Comienzan
con la preparacin de una propuesta para responder a una peticin de oferta de un comprador o con la firma de
un contrato con el comprador para proporcionarle un producto software. Trata, asimismo, de la identificacin de
los procedimientos y de los recursos necesarios para gestionar y garantizar el xito del proyecto, incluyendo el
desarrollo de los planes del proyecto y la ejecucin de dichos planes hasta la entrega del producto software al
comprador.

Proceso de desarrollo: Contiene las actividades de anlisis de requisitos, diseo, codificacin, integracin,
pruebas e instalacin y aceptacin. Vamos a resumir someramente estas actividades:

Anlisis de requisitos del sistema: Aqu son especificados todos los requisitos del Sistema de
Informacin, funciones y capacidades que debe cumplir, requisitos de seguridad, interfaces, de
mantenimiento, etc.
Diseo de la arquitectura del sistema: Se identifican los principales componentes hardware y
software.
Anlisis de los requisitos de software: Se establecen dichos requisitos, incluyendo el nivel de calidad
que debe cumplir el sistema.
Diseo de la arquitectura del software: El diseador debe transformar el anlisis anterior en una
arquitectura en la que se puedan identificar sus componentes principales.
Diseo detallado del software: Aqu se realiza un diseo detallado de cada componente software, de
las bases de datos y manuales de usuario.
Codificacin y pruebas unitarias: Se desarrollan y se documentan los componentes del punto anterior.
Finalmente se realizan las pruebas unitarias de cada uno de ellos para asegurarse de que cumplen
los requisitos exigidos.
Pruebas de integracin: Se integran los componentes del software realizando las correspondientes
pruebas.
Prueba del software: Las pruebas se planifican y disean de forma sistemtica para poder detectar el
mximo nmero y variedad de defectos con el mnimo consumo de tiempo y esfuerzo.
Integracin del sistema: Aqu se realizan las pruebas conjuntas de los elementos hardware y
software.
Implantacin del software desarrollado en el entorno de explotacin final. Cuando se sustituya a un
software ya existente, puede ser recomendable un perodo de tiempo en el que convivan los dos
sistemas.
Proceso de aceptacin del software.

Proceso de explotacin: Comprende la propia explotacin del software y el soporte operativo a los usuarios del
sistema.

Proceso de mantenimiento: Aparece cuando, tarde o temprano, el software requiere modificaciones, bien por
errores, necesidades de mejora, etc.

2.3 PROCESOS DE SOPORTE

Sirven de apoyo al resto de procesos y pueden aplicarse en cualquier punto del ciclo de vida.

TEMARIO-TICB-feb04 B2G1T01
Actualizado en febrero de 2004 Pgina 5 de 21
www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968

Proceso de documentacin: Comprende todas las actividades que permiten desarrollar, distribuir y mantener la
documentacin necesaria para todas las personas involucradas : consultores, jefes de proyecto, analistas,
programadores, usuarios, etc.

Proceso de gestin de la configuracin: Controla las modificaciones y las versiones de los elementos de
configuracin del software del sistema.

Proceso de aseguramiento de la calidad: Comprueba que los procesos y los productos software del ciclo de
vida cumplen con los requisitos especificados y se ajustan a los planes establecidos.

Proceso de verificacin: El objetivo es demostrar la consistencia, completitud y correccin del software entre las
fases del ciclo de desarrollo de un proyecto (por ejemplo, si el cdigo es coherente con el diseo). Este proceso
puede ser responsabilidad de una empresa de servicios y, en este caso se conoce como proceso de verificacin
independiente.

Proceso de validacin: El objetivo es determinar la correccin del producto final respecto a las necesidades del
usuario. Al igual que el anterior, este proceso puede ser ejecutado por una organizacin de servicios,
denominndose proceso de validacin independiente.

Proceso de revisin conjunta: Para evaluar el estado del software y sus productos en una determinada
actividad del ciclo de vida o una fase de un proyecto. Las revisiones conjuntas se celebran tanto a nivel de gestin
como a nivel tcnico del proyecto a lo largo de todo su ciclo de vida. Un mecanismo habitual de revisin son las
reuniones y la responsabilidad es generalmente compartida entre un grupo de personas pertenecientes a la
organizacin.

Proceso de auditora: Permite determinar, en los hitos preestablecidos, si se han cumplido los requisitos, los
planes y, en suma, el contrato.

Proceso de resolucin de problemas: Permite analizar y solucionar los problemas, sean stos diferencias con
los requisitos o con el contrato. Aporta un medio oportuno y documentado para asegurar que los problemas
detectados son analizados y solucionados.

2.4 PROCESOS DE LA ORGANIZACIN

Son los utilizados por una organizacin para llevar a cabo funciones como la gestin, formacin del personal o
procesos de mejora continua.

Proceso de gestin: Contiene las actividades y las tareas genricas que puede emplear una organizacin que
tenga que gestionar sus procesos. Incluye actividades como la planificacin, el seguimiento y control, la revisin y
evaluacin.

Proceso de infraestructura: Establece la infraestructura necesaria para cualquier otro proceso: hardware,
software, herramientas, tcnicas, etc para el desarrollo, explotacin y mantenimiento.

Proceso de mejora: Para mejorar los procesos del ciclo de vida del software.

Proceso de formacin: Para mantener al personal con la adecuada formacin, lo que conlleva el desarrollo del
material de formacin, as como la implementacin del plan de formacin de la organizacin.

2.5 PROCESO DE ADAPTACIN

Sirve para realizar la adaptacin bsica de la norma ISO 12207-1 respecto a los proyectos software. Como es
sabido, las variaciones en las polticas y procedimientos de la organizacin, los mtodos y estrategias de
adquisicin, el tamao y complejidad de los proyectos, los requisitos del sistema y los mtodos de desarrollo,
entre otros, influencian la forma de adquirir, desarrollar, explotar o mantener un sistema.

TEMARIO-TICB-feb04 B2G1T01
Actualizado en febrero de 2004 Pgina 6 de 21
www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968

Dado que los procesos se aplican durante el ciclo de vida del software , y adems se utilizan de diferentes formas
por las diferentes organizaciones y con distintos puntos de vista y objetivos, es preciso comprender los procesos,
las organizaciones y sus relaciones bajo diferentes puntos de vista:

Contrato: El comprador y el proveedor negocian y firman el contrato, empleando los procesos de


adquisicin y suministro.
Gestin o direccin: El comprador, el proveedor, el desarrollador, el operador y el personal de
mantenimiento gestionan sus respectivos procesos en el proyecto software.
Explotacin: El operador proporciona el servicio de explotacin del software a los usuarios.
Ingeniera: El desarrollador o el personal de mantenimiento llevan a cabo sus respectivas tareas de
ingeniera para producir o modificar los productos de software.
Soporte: Los grupos de soporte (el de gestin de la configuracin, el de aseguramiento de la calidad,
el de auditoria, etc) proporcionan servicios de apoyo a otros grupos en el cumplimiento de tareas
nicas y especficas.

3. MODELO EN CASCADA

Este modelo naci durante los aos setenta y supuso un gran avance con respecto a los modelos que haban
sido utilizados hasta entonces. Este modelo se compone de una serie de fases que se suceden secuencialmente,
generndose en cada una de las fases resultados que constituyen la entrada de la fase siguiente. Estas fases
pueden diferir, pero suelen comprender:

Planificacin.
Especificacin de Requisitos.
Diseo.
Codificacin.
Pruebas e Integracin.
Implantacin y Aceptacin.
Mantenimiento.

La fase de especificacin de requisitos es conocida tambin como anlisis funcional, la fase de diseo se
denomina anlisis orgnico y la fase de codificacin se llama programacin.

El nmero de fases es irrelevante, lo que caracteriza verdaderamente a este modelo es la secuencialidad entre
las fases y la necesidad de completar cada una de ellas para pasar a la siguiente. El sistema est terminado
cuando se han realizado todas las fases.

El modelo en cascada ayud a eliminar muchos de los problemas que se planteaban antes de su utilizacin,
adems ha sido la base para la normalizacin y la adopcin de estndares. A medida que ha sido utilizado se han
detectado en l debilidades e inconsistencias que se han intentado corregir con diversas modificaciones y
extensiones al modelo inicial.

3.1. FASES DEL MODELO EN CASCADA

Vamos a analizar cada una de las posibles fases:

3.1.1 PLANIFICACIN

De esta fase depende en gran medida un desarrollo efectivo en lo referente a costos y plazos de entrega.

TEMARIO-TICB-feb04 B2G1T01
Actualizado en febrero de 2004 Pgina 7 de 21
www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968

Hay que fijar los siguientes puntos:

mbito del trabajo a realizar.


Recursos necesarios.
Tareas a realizar.
Referencias a considerar.
Coste aproximado del desarrollo del proyecto.
Formacin del equipo de desarrollo.
Ordenacin y calendario de las actividades.

La planificacin se llevar a cabo con un nivel de detalle adecuado a la complejidad, tamao y grado de
estructuracin del proyecto. Para proyectos de gran tamao la planificacin es imprescindible y en ocasiones
sirve para determinar el modelo de ciclo de vida a seguir en el proyecto.

La estimacin de recursos, costes y calendario se determina a partir de la experiencia acumulada por parte del
jefe de proyecto y de la informacin histrica de otros proyectos realizados dentro o fuera de la organizacin. Esta
es una de las fases ms difciles de realizar, pero en la actualidad se cuenta con tcnicas y herramientas
automatizadas para el control y la gestin del proceso de produccin de los sistemas de informacin.

3.1.2 ESPECIFICACIN DE REQUISITOS ANLISIS FUNCIONAL

Una vez terminada la planificacin del proyecto, la fase de anlisis de requisitos es la primera del proceso de
desarrollo del sistema. En esta fase es preciso analizar, entender y documentar el problema que el usuario trata
de resolver con el sistema de informacin o aplicacin a desarrollar.

Es necesario especificar en detalle las funciones, objetivos y restricciones del sistema propuesto para que el
usuario y los desarrolladores puedan tomar estas especificaciones como punto de partida para acometer el resto
del sistema.

El proceso de recogida de requisitos es la tarea ms delicada de esta fase en la cual el analista del sistema debe
llegar a comprender el dominio de la informacin y adaptar las necesidades del usuario a unas especificaciones
formales listas para poder ser utilizadas por los desarrolladores.

Se trata de definir qu debe hacer el sistema identificando la informacin a procesar, las funciones a realizar, el
rendimiento deseado del sistema, las interfaces con otros sistemas o las restricciones de diseo entre otros
aspectos. Es fundamental en esta fase la participacin e implicacin del usuario del sistema.

Para el anlisis de las necesidades a cubrir y los requisitos a satisfacer por el sistema, su priorizacin, comprobar
que el sistema se ajusta a las necesidades del usuario y plantear alternativas viables no solo a nivel tcnico sino
desde el punto de vista de costes y riesgos, hay que utilizar todas aquellas tcnicas o elementos a nuestro
alcance como, por ejemplo, realizacin de entrevistas con los usuarios, utilizacin de informacin referente al
sistema actual si es que existe, utilizacin de tcnicas de diagramacin para facilitar la comprensin del sistema,
tcnicas de anlisis coste-beneficio, tcnicas de prototipado rpido o tcnicas de anlisis estructurado.

Las tareas asociadas a esta fase y los resultados que se obtienen sern independientes del entorno tecnolgico
del sistema de informacin.

3.1.3 DISEO ANLISIS ORGNICO

A partir, como siempre, de las especificaciones de la fase anterior y una vez elegida la mejor alternativa, se debe
comenzar a crear la solucin al problema descrito atendiendo a aspectos de interfaz de usuario, estructura del
sistema y de decisiones sobre la implantacin posterior.

TEMARIO-TICB-feb04 B2G1T01
Actualizado en febrero de 2004 Pgina 8 de 21
www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968

Esta fase aborda el cmo, es decir, deber disear las estructuras de datos, la arquitectura del sistema, los
detalles que permitan la codificacin posterior y las pruebas a realizar.

Para el diseo del sistema habr que trasladar la especificacin de requisitos a un conjunto de representaciones
ya sean grficas, tabulares o basadas en lenguajes que constituirn la estructura de datos lgica y fsica, la
arquitectura y los procedimientos.

Otras cuestiones que se abordan en esta fase son los requisitos de comunicaciones, algoritmos, seguridad y
control. Al igual que en las fases anteriores la de diseo conlleva una documentacin en la que se recogen sus
resultados. En esta fase hay que tener en cuenta el entorno del sistema referente a hardware y software de base.

3.1.4 CODIFICACIN - PROGRAMACIN

En esta fase se traducen las especificaciones de diseo a un lenguaje de programacin capaz de ser interpretado
y ejecutado por el ordenador. Existen lenguajes de distintos grados de complejidad o eficacia y la utilizacin de
uno u otro determinar la forma de trabajo de esta fase. En todo caso, el lenguaje vendr determinado por el
entorno tecnolgico del sistema.

El programador deber velar por la claridad de su estilo para facilitar cualquier interpretacin posterior de los
programas. Asimismo se respetarn los estndares de la organizacin en cuanto a nomenclatura y formato. Es
imprescindible que los programas incorporen comentarios escritos que ayuden a su comprensin y que se
acompaen de la documentacin externa necesaria que describa su objeto, los algoritmos que incluye, sus
entradas y salidas y cualquier otro elemento relevante.

Muchas son las tcnicas aplicables a la programacin, como, por ejemplo, las tcnicas estructuradas
ampliamente extendidas desde hace aos. Ms reciente es la generacin automtica de cdigo, que a partir de
especificaciones formales, algunas herramientas CASE (Computer Aided Software Engineering) facilitan con un
mayor o menor grado de optimizacin, segn los casos, cdigo en los lenguajes de programacin ms utilizados.

3.1.5 PRUEBAS E INTEGRACIN

Una vez que los programas han sido desarrollados, es preciso llevar a cabo las pruebas necesarias para asegurar
la correccin de la lgica interna de los mismos y comprobar que cubren las funcionalidades previstas.

La integracin de las distintas partes que componen la aplicacin o el sistema es precisa en proyectos complejos
o de grandes dimensiones que hayan sido descompuestos por razones de facilidad de gestin y control. La
integracin debe solucionar posibles problemas de interaccin y garantizar el buen funcionamiento del conjunto.

En esta fase se debe proporcionar la documentacin que ilustre los procedimientos de usuario en la utilizacin y
funcionamiento del sistema y si fuera preciso se organiza un plan de formacin para usuarios con el material
didctico necesario.

Como en las fases anteriores existen tcnicas y herramientas para la realizacin de las tareas de esta fase.

3.1.6 IMPLANTACIN Y ACEPTACIN

En esta fase se trata de conseguir la aceptacin final del sistema por parte de los usuarios del mismo y llevar a
cabo las actividades necesarias para su puesta en produccin.

Para ello se tomarn como punto de partida los componentes del sistema probados de forma unitaria e integrada
en la fase anterior y se probarn una vez ms esta vez con el fin de verificar que cumplen los requisitos de
usuario y que el sistema es capaz de manipular los volmenes de informacin requeridos en los tiempos y
velocidades deseados, que las interfaces con otros sistemas funcionan, etc.

En estas pruebas participar el usuario que si est conforme deber aceptar formalmente el sistema.

TEMARIO-TICB-feb04 B2G1T01
Actualizado en febrero de 2004 Pgina 9 de 21
www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968

3.1.7 MANTENIMIENTO

Esta fase comienza una vez que el sistema es entregado al usuario y contina mientras permanece activa su vida
til. El mantenimiento puede venir propiciado por:

Errores no detectados previamente.


Modificaciones, mejoras o ampliaciones solicitadas por los usuarios.
Adaptaciones requeridas por la evolucin del entorno tecnolgico o cambios normativos.

En el primer caso se habla de mantenimiento correctivo puesto que debe solventar defectos en el sistema. El
segundo caso se denomina mantenimiento perfectivo puesto que se produce una modificacin de los requisitos
iniciales aumentando las funcionalidades. El ltimo de los casos se conoce por mantenimiento adaptativo, con el
paso del tiempo es muy posible que la situacin inicial respecto de la cual se concibi el sistema cambie.

Para la realizacin del mantenimiento se siguen los mismos pasos que para la realizacin del sistema, pero en el
contexto de un sistema existente. Es fundamental que las variaciones producidas en esta fase queden reflejadas
en todas las fases anteriores y no simplemente en la fase de codificacin. De lo contrario esta prctica conducira
a sistemas intratables al cabo de varias modificaciones sin actualizacin de la documentacin afectada.

La fase de mantenimiento lleva asociada su propia documentacin reflejando los cambios, su objeto, la fecha, el
autor y cualquier dato que pueda ayudar al control de dichos cambios o a procesos de mantenimiento posteriores.

3.2 LA DOCUMENTACIN

El modelo de ciclo de vida en cascada est regido por la documentacin, es decir, la decisin del paso de una
fase a la siguiente se toma en funcin de si la documentacin asociada a esa fase est completa o no.

El concepto de documentacin debe entenderse en sentido amplio como todos los productos resultantes de las
tareas realizadas en cada fase ya sean informes, programas, juegos de pruebas, etc., se podra definir la
documentacin como aquello que se construye y ha de mantenerse durante la vida del sistema.

A pesar de posibles crticas a esta orientacin se recogen a continuacin las caractersticas que deben incluir los
documentos asociados a cada fase. No hay que olvidar que el objetivo final es construir con xito un sistema de
informacin y que la documentacin nos ayudar a conseguirlo pero no es un fin en s misma.

En la fase de planificacin se elaborar documentacin que tendr el carcter de marco bsico de referencia del
proyecto y deber incluir:

Descripcin y alcance de las tareas que se van a llevar a cabo.


Identificacin de los principales mtodos, instrumentos y procedimientos de trabajo que se utilizarn.
Procedimientos de seguimiento y control de los trabajos y mecanismos de revisin y aprobacin de
los mismos.
Calendario de tareas y su ordenacin temporal.
Asignacin de recursos.
Organizacin de las personas que intervienen en el proyecto.

En la fase de especificacin de requisitos ser necesaria la existencia de documentacin en el que se recojan las
necesidades del usuario respecto al sistema: funcionalidades, rendimientos, limitaciones y restricciones, los
interfaces de usuario. La descripcin de los requisitos de los usuarios debe ser descrita de forma que se pueda
verificar su cumplimiento mediante inspecciones o pruebas. Este documento reflejar el punto de vista del
analista del sistema respecto de las especificaciones que el usuario ha realizado, si la comprensin por parte del
analista no es adecuada el usuario debe rechazar el documento. Este documento es crucial porque sobre sus
presupuestos se construir el sistema de informacin, por tanto se detallar la naturaleza de la informacin, su

TEMARIO-TICB-feb04 B2G1T01
Actualizado en febrero de 2004 Pgina 10 de 21
www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968

contenido y su estructura lgica. La representacin funcional de las operaciones y procesos, sus entradas y
salidas y cualquier caracterstica relevante a nivel funcional referente al entorno tecnolgico del sistema.

En la documentacin asociada a la fase de diseo se profundizar ms, llegando a describir los componentes del
sistema: estructuras de datos, unidades de tratamiento o mdulos de procesamiento e interfaces al mximo nivel
de detalle. Se concretar la descripcin tcnica y cuestiones relacionadas con la implantacin del sistema:
arquitectura general, ficheros y/o bases de datos, pantallas, informes o comunicaciones con otros sistemas.

La fase de codificacin debe proporcionar como documentacin, el cdigo fuente de todos los mdulos incluidas
las funciones auxiliares, el cdigo para la creacin de estructuras de datos e interfaces externas y cualquier tipo
de mdulos o rutinas relacionadas con el sistema. Adems del cdigo de cada mdulo en el soporte fsico y
formato de representacin previamente establecido por el usuario, se acompaar el listado del cdigo con sus
comentarios internos y comentarios externos sobre la definicin de las estructuras de datos, de los algoritmos,
sobre el manejo de excepciones y la gestin de errores.

La fase de pruebas e integracin llevar documentacin que describa el plan de pruebas a nivel unitario e
integrado y los resultados de dichas pruebas. La fase de implantacin y aceptacin vendr documentada con el
plan de pruebas del sistema a nivel global y sus resultados. Por ltimo si se realizan modificaciones en la fase de
mantenimiento debern reflejarse en la documentacin correspondiente que haya podido ser afectada.

La documentacin asociada al sistema no estara completa sin un manual de usuario que contenga la descripcin
funcional de todos los procedimientos para facilitar la operativa del sistema al usuario. Recoger los
procedimientos de instalacin, administracin y gestin de la configuracin, operaciones especiales,
funcionamiento, ayudas incorporadas, tratamiento de errores, comandos y sentencias de control. A veces tambin
puede incluir una gua de referencia rpida con el resumen de todas estas instrucciones.

3.3 CRTICA DEL MODELO

Las principales crticas al modelo se centran en sus caractersticas bsicas, es decir secuencialidad y utilizacin
de los resultados de una fase para acometer la siguiente de modo que el sistema slo se puede validar cuando
est terminado.

Los proyectos reales raramente siguen el flujo secuencial que propone el modelo. Siempre ocurren interacciones
y en las ltimas fases sobre todo se pueden realizar en paralelo algunas reas como por ejemplo codificacin y
pruebas. Una aplicacin del modelo en sentido estricto obligara a la congelacin de los requisitos de los
usuarios, supuesto este completamente alejado de la realidad. El modelo no contempla la posibilidad de
realimentacin entre fases.

El modelo en su formulacin pura no prev revisiones o validaciones intermedias por parte del usuario, as los
resultados de los trabajos slo se ven al final de una serie de tareas y fases de tal forma que si se ha producido
un error en las primeras fases ste slo se detectar al final y su correccin tendr un costo muy elevado, puesto
que ser preciso rehacer todo el trabajo desde el principio. El modelo no dispone de resultados parciales que
permitan validar si el sistema cumple con los requisitos desde las primeras fases, dndose el caso de sistemas
perfectamente formalizados y documentados que no cumplen los requisitos del usuario.

3.4 EXTENSIONES AL MODELO EN CASCADA

Actualmente, despus de la experiencia obtenida con la aplicacin del modelo en cascada y gracias a avances
tecnolgicos como por ejemplo lenguajes de cuarta generacin o herramientas CASE existen modelos de ciclo de
vida alternativos al modelo en cascada. En la prctica se llegan a realizar incluso modelos mixtos. En este punto
no se tratarn estos casos, sino que se citarn algunas innovaciones aplicables al modelo en cascada que
permiten mejorar algunas de las deficiencias del modelo y aumentar su eficacia:

Utilizacin de herramientas CASE y otras facilidades. Al hablar de las fases del ciclo de vida se
mencionaban las tcnicas estructuradas, en principio dichas tcnicas no se utilizaban en el modelo en
cascada, sin embargo, hoy en da no se plantea la realizacin de un sistema artesanalmente.

TEMARIO-TICB-feb04 B2G1T01
Actualizado en febrero de 2004 Pgina 11 de 21
www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968

Introduccin de una fase intermedia entre especificacin de requisitos y el diseo denominado diseo
rpido que sirva para validar las especificaciones por parte del usuario, establecindose un proceso
iterativo de modificacin de la especificacin hasta que el usuario est satisfecho con la misma.
Tcnicas de diseo en grupo. Es deseable que el usuario pueda participar al mximo en la definicin
de los requisitos puesto que se evitarn errores y confusiones ya en las primeras etapas.
Utilizar tcnicas de anlisis de riesgos y de coste-beneficio para pasar a la fase siguiente y abandonar
planteamientos rgidos de paso a la fase siguiente cuando se ha completado la documentacin.
Dotar de autonoma al jefe de proyecto para que de acuerdo con su experiencia y las caractersticas
del proyecto decida comenzar una fase sin haber terminado la anterior al 100%, pero que le permite,
por ejemplo, realizar una maqueta para la validacin por parte del usuario.
Codificacin y pruebas de los mdulos de ms alto nivel en primer lugar, seguida de la de los
mdulos ms detallados o de ms bajo nivel. Esta aproximacin puede propiciar el dilogo entre el
analista y el usuario en fases posteriores a la especificacin de requisitos estableciendo as un
proceso de realimentacin entre las fases de Implantacin y Especificacin de requisitos.
Realizacin de fases en paralelo como codificacin y pruebas. La codificacin se puede as ver
beneficiada por los resultados de las pruebas y deteccin de errores.
Reutilizacin de cdigo ya probado. A veces con pequeas modificaciones se pueden llegar a utilizar
programas existentes.
Revisiones de cdigo. Se trata de inspecciones para localizar lo ms pronto posible dentro del ciclo
todos los errores de diseo y codificacin.

4. MODELO EN ESPIRAL DEL CICLO DE VIDA

4.1 INTRODUCCIN

A partir de la experiencia de la aplicacin del modelo en cascada se desarroll el modelo en espiral del ciclo de
vida del software y se implement en algunos grandes proyectos.

En este modelo subyace el concepto de que cada ciclo implica una progresin que aplica la misma secuencia de
pasos para cada parte del producto y para cada uno de sus niveles de elaboracin, desde la concepcin global de
la operacin hasta la codificacin de cada programa Individual.

El modelo en espiral se ilustra en la Figura siguiente. En ella podemos apreciar :

La dimensin radial: representa el coste acumulativo en el que se ha incurrido en las etapas


realizadas hasta el momento actual.
La dimensin angular: representa el progreso hecho en completar cada ciclo de la espiral.

TEMARIO-TICB-feb04 B2G1T01
Actualizado en febrero de 2004 Pgina 12 de 21
www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968

CUADRANTE 1 CUADRANTE 2

CUADRANTE 3

CUADRANTE 4

Describamos a continuacin como sera un tpico ciclo de espiral. Considerando cada cuadrante de izquierda a
derecha en el sentido de las agujas del reloj.

CUADRANTE 1: Cada ciclo en espiral empieza con la identificacin de:

Los objetivos de la parte del producto que va a ser elaborada (rendimiento, funcionalidad,
disponibilidad para acomodarse a nuevos cambios, etc.)
Las alternativas para implementar esta parte del producto (diseo A, diseo B, compra del software
ya desarrollado, reutilizacin de un software ya existente, etc.).
Las restricciones impuestas: costes, calendario de realizacin, interfaces, etc.

CUADRANTE 2: Aqu se evalan las opciones relativas a los objetivos y las restricciones.

Este proceso, con frecuencia, identificar reas de incertidumbre que son fuentes significativas de riesgo. Esto
llevara implcito la formulacin de una estrategia econmicamente efectiva para resolver las fuentes de riesgo:
prototipado, simulacin, benchmark, modelos analticos o combinaciones de stas y otras tcnicas de resolucin
de riesgos.

Si los riesgos de rendimiento o los riesgos del interfase de usuario tienen mucha ms importancia que los riesgos
de desarrollo de programas o los riesgos de interfase de control interno, entonces el paso siguiente podra ser un
paso de desarrollo evolutivo: un esfuerzo mnimo para especificar la naturaleza global del producto, un plan para
el siguiente nivel de prototipado y el desarrollo de un prototipo ms detallado para continuar la resolucin de las
mayores fuentes de riesgo.

Si este prototipo es operacionalmente til y suficientemente robusto para servir como una base de bajo riesgo
para la evolucin del producto, entonces, los subsiguientes pasos dirigidos por el riesgo (risk-driven) podran ser
una serie de prototipos cada vez ms evolucionados, movindonos hacia la derecha en la figura. As,
consideraciones de riesgo, pueden llevar a la realizacin del proyecto utilizando slo un subconjunto de todos los
pasos potenciales en el modelo.

TEMARIO-TICB-feb04 B2G1T01
Actualizado en febrero de 2004 Pgina 13 de 21
www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968

CUADRANTES 3 y 4: Si los esfuerzos previos de prototipado han resuelto ya todos los riesgos de rendimiento o
los riesgos de interface de usuario y dominan los riesgos de desarrollo de programas o los riesgos de control de
interface, el paso siguiente sera el desarrollo segn el modelo en cascada. Cada nivel de especificacin del
software en la figura, entonces, seguido por un paso de validacin y planificacin del siguiente ciclo.

Esta implementacin, dirigida por el riesgo, de un subconjunto del modelo en espiral, permite al modelo
acomodarse a cualquier mezcla de estrategias de desarrollo de software: orientado por las especificaciones,
orientado por la simulacin, orientado por transformaciones automticas o cualquier otro enfoque de desarrollo.

En tales casos, la estrategia mixta apropiada se escoge, considerando, la relacin relativa de magnitudes de los
riegos y la efectividad relativa de las distintas alternativas en la resolucin de estos riesgos. De forma similar,
consideraciones de gestin de riesgo, permiten determinar la cantidad de tiempo y esfuerzo que debe dedicarse a
otras actividades del proyecto tales como: planificacin, gestin de la configuracin, garanta de la calidad,
verificacin formal, y prueba.
Un aspecto importante del modelo espiral, como en otros muchos modelos, es que cada ciclo se completa por
una revisin que involucra a las personas u organizaciones principales relacionadas con el proyecto. Esta revisin
cubre todas las actividades desarrolladas durante el ciclo previo, incluyendo los planes para el prximo ciclo y los
recursos que se requieren para llevarlos a cabo.
El principal objetivo de la revisin es asegurar que todas las partes implicadas estn de acuerdo con el camino a
seguir en la siguiente fase.
Los planes para las fases sucesivas pueden incluir tambin el desarrollo del producto por medio de incrementos
sucesivos o la divisin en componentes que pueden ser desarrollados por distintas personas u organizaciones.
En este ultimo caso, aparecen unos ciclos espirales paralelos (uno para cada componente) aadiendo una tercera
dimensin al concepto presentado en la figura.
Adems, la etapa de revisin y compromiso puede extenderse, desde una simple revisin informal del diseo de
un programa a una revisin de los requerimientos principales implicando, en este caso, a clientes, usuarios,
desarrolladores y organizaciones de mantenimiento.

4.2 EJEMPLO DE APLICACIN DEL MODELO EN ESPIRAL

El modelo en espiral se aplic en un proyecto muy complejo: la definicin y desarrollo del Sistema de
Productividad de Software (TRW-SPS) un entorno integrado de ingeniera de software de la empresa TRW. El
objetivo era mejorar la productividad de las tareas de desarrollo de software realizadas por la empresa.

En primer lugar se realiz un ciclo 0 de la espiral para determinar la viabilidad de conseguir un incremento
significativo de productividad en el desarrollo de software.

Ciclo 0: Estudio de viabilidad

Participaron cinco personas, a tiempo parcial, durante un perodo de dos a tres meses. Durante este ciclo los
objetivos y las restricciones se consideraron a un nivel muy alto, expresndoles en trminos cualitativos (mejora
significativa, coste razonable, etc).

Se consideraron alternativas en cuatro reas: gestin de los proyectos, gestin del personal, tecnologa e
instalaciones.
Como reas de riesgo, se consider la posibilidad de que la compaa realizase una inversin importante para
encontrarse con:

- Mejoras de productividad escasamente significativas.


- Mejoras potenciales incompatibles con aspectos de la cultura de la empresa.

El anlisis de riesgos condujo a la conclusin de que se podran obtener significativas mejoras en la


productividad, a un coste razonable, por medio de un conjunto integrado de iniciativas.

TEMARIO-TICB-feb04 B2G1T01
Actualizado en febrero de 2004 Pgina 14 de 21
www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968

Ciclo 1: Concepcin de la operacin

En este ciclo se invirtieron ms recursos (12 meses hombre en lugar de los 2 meses hombre del Ciclo 0); se
consideraron objetivos ms especficos (conseguir el doble de productividad en la produccin de software en 5
aos a un coste mximo de 10.000 $ por persona); surgieron nuevas restricciones como la preferencia por la
utilizacin de productos desarrollados por la propia empresa, en especial la red local de TRW.

Para las reas de riesgo tambin se fue ms especfico que en el Ciclo 0 (comprobacin que la red TRW LAN
ofreca una relacin precio / rendimiento dentro de la restriccin 10.000 $ por persona ). Para la resolucin de
riesgos se realizaron tareas ms extensivas, tales como la realizacin de benchmarks y anlisis de un prototipo
de la TRW LAN.

La fase de compromisos no se limit a la aceptacin del plan. Se acord la aplicacin del entorno de desarrollo de
software producido a un proyecto piloto que implicaba a ms de 100 personas. Se decidi la formacin de un
comit de seguimiento para garantizar la coordinacin de las distintas actividades y para evitar que el prototipo de
entorno de desarrollo no se optimizase, excesivamente, en funcin de las caractersticas del proyecto en el que
se iba a probar. Se recomend que no solamente se desarrollase el prototipo, sino que tambin se elaborase una
especificacin de requerimientos y un diseo siguiendo una orientacin orientada al riesgo.

Ciclo 2: Especificacin de los requerimientos de alto nivel

Se tomaron las decisiones al comienzo del ciclo al observarse que muchos de los requisitos del sistema
dependan de la decisin sobre el sistema operativo a utilizar y de si el sistema a elaborar iba a ser un sistema
orientado al host o totalmente portable. Se decidi escoger UNIX y un sistema orientado a un host UNIX.

Otros ciclos posteriores

Las etapas posteriores se realizaron segn las caractersticas generales de la implantacin del modelo en este
caso:

Desarrollo de especificaciones, postergando la elaboracin de los elementos de software de bajo


riesgo hasta que no se hubieran estabilizado los elementos de software de alto riesgo.
Incorpora la construccin de prototipos como tcnica de reduccin de riesgos en cualquiera de las
etapas del proyecto.
Permite la vuelta atrs a etapas anteriores cuando se encuentran alternativas ms atractivas o se
identifican nuevas fuentes de riesgo que requieren solucin.

4.3 EVALUACIN DEL MODELO

4.3.1 VENTAJAS

La ventaja principal del modelo en espiral es que su rango de opciones acomoda las buenas caractersticas de los
otros modelos de desarrollo de software, y su procedimiento dirigido por el riesgo, evita muchas de sus
dificultades.

En situaciones apropiadas, el modelo en espiral es equivalente a uno de los modelos de proceso existentes.

Si un proyecto tiene un riesgo bajo en reas tales como el establecimiento de una interfaz de usuario no
adecuada o en el cumplimiento de requerimientos rigurosos de ejecucin y si, por el contrario, tiene un alto riesgo
en la prediccin y control del presupuesto y del calendario de elaboracin, entonces estas consideraciones
conducen el modelo en espiral a uno equivalente al modelo en cascada.

El modelo en espiral tiene otras ventajas adicionales:

TEMARIO-TICB-feb04 B2G1T01
Actualizado en febrero de 2004 Pgina 15 de 21
www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968

Concentra su atencin en opciones que consideran la reutilizacin de software existente. Los pasos
implicados en la identificacin y evaluacin de alternativas potencian estas opciones.
Permite preparar la evolucin del ciclo de vida, crecimiento y cambios del producto software.
Proporciona un mecanismo de incorporacin de objetivos de calidad en el desarrollo de producto
software. Este mecanismo se deriva del nfasis puesto en la identificacin de todos los objetivos y
restricciones durante cada una de las vueltas de la espiral.
Es especialmente adecuado para la temprana eliminacin de errores y alternativas poco atractivas.
No implica procedimientos separados para el desarrollo y la mejora del software.
Proporciona un marco viable para integrar los desarrollos de sistemas software-hardware. El centrar
la atencin en la gestin del riesgo y en la eliminacin de alternativas no atractivas lo antes posible y
con el menor coste es, igualmente, aplicable al software y al hardware.
Se adapta al diseo y programacin orientada a objetos y posiblemente con estos mtodos es cuando
permite obtener mejores resultados: el modelo en espiral potencia la utilizacin de desarrollos
incrementales, y cuando sea necesario, la reelaboracin de partes ya desarrolladas. La abstraccin,
encapsulacin, modularidad y jerarquizacin, elementos fundamentales de los mtodos orientados a
objeto, facilitan los desarrollos incrementales y hacer menos traumticas las reelaboraciones.

4.3.2 DIFICULTADES

Adaptar su aplicabilidad al software contratado.

El modelo en espiral actualmente trabaja bien en desarrollos de software internos pero necesita un trabajo
adicional para adaptarlo al mundo de los contratos de adquisicin del software.

Los desarrollos internos de software tienen bastante flexibilidad y libertad para acomodarse a confirmaciones
etapa por etapa; para diferir confirmaciones a determinadas opciones; para establecer miniespirales con las que
resolver caminos crticos; para ajustar niveles de esfuerzo, o para acomodar prcticas tales como el prototipado, o
el desarrollo evolutivo.

En el mundo de la adquisicin de software es muy difcil conseguir estos grados de flexibilidad y libertad sin
perder responsabilidad y control y es muy difcil definir contratos que no especifiquen por adelantado los
productos a obtener.

Recientemente, se ha progresado en el establecimiento de mecanismos de contratacin ms flexibles pero


todava se necesitan mejoras para conseguir que los compradores se sientan completamente cmodos
utilizndolos.

Dependencia de la experiencia en la evaluacin de riesgos

El modelo en espiral da un papel relevante a la habilidad de los desarrolladores de software para identificar y
gestionar las fuentes de riesgo del proyecto. Un buen ejemplo de esto es la especificacin dirigida por el riesgo en
el modelo en espiral. En ella se debe llegar a un alto nivel de detalle en los elementos de alto riesgo dejando, los
de bajo riesgo, para una elaboracin en etapas posteriores.

Otro problema es que la especificacin ser, en exceso, dependiente de las personas. Por ejemplo, un diseo
producido por un experto puede ser implantado por no expertos; en este caso, el experto que no necesita mucha
documentacin, debe producir suficiente documentacin adicional para que los no expertos no se extraven.

Con una aproximacin convencional, dirigida por la documentacin, el requerimiento de llevar todos los aspectos
de la especificacin a un nivel uniforme de detalle elimina algunos problemas potenciales y permite una adecuada
revisin de algunos aspectos por revisores inexpertos. No obstante, esto produce prdidas de tiempo a los
expertos que deben buscar los aspectos crticos en medio de un gran volumen de detalles no crticos.

TEMARIO-TICB-feb04 B2G1T01
Actualizado en febrero de 2004 Pgina 16 de 21
www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968

4.4 EL PLAN DE GESTIN DE RIESGO

Incluso si una organizacin no est lista para adoptar el procedimiento completo de espiral, una caracterstica
tcnica del mismo que puede ser fcilmente adaptada a cualquier modelo de ciclo de vida proporciona muchos de
los beneficios de dicho procedimiento. Se trata del Plan de Gestin del Riesgo, resumido en las tablas 1 y 2 de la
pgina siguiente.

Este plan, bsicamente, asegura que en cada proyecto se haga una identificacin temprana de sus factores de
riesgo ms altos (el nmero de 10 que figura en la tabla 4 no es un requerimiento absoluto); desarrolla una
estrategia para resolver los factores de riesgo; identifica y establece una agenda para resolver nuevos factores de
riesgo a medida que afloran y, por ltimo, muestra los progresos respecto al plan en revisiones mensuales.

El plan de gestin de riesgo y las tcnicas para gestin de riesgo de Software facilitan adaptar conceptos del
modelo en espiral a los procedimientos de adquisicin y desarrollo de software ms asentados. Se pueden sacar
las siguientes cuatro conclusiones:

El modelo en espiral, por su naturaleza de estar dirigido por el riesgo, es ms adaptable a un amplio
rango de situaciones que los procedimientos dirigidos por la documentacin, tales como el modelo en
cascada o los procedimientos dirigidos por el cdigo, tales como el modelo de desarrollo evolutivo. Es
particularmente aplicable a sistemas de software muy grandes y complejos.
El modelo en espiral ha tenido xito en su mayor aplicacin realizada hasta ahora: el desarrollo del
TRW- SPS. Proporciona la flexibilidad necesaria para acomodar un rango de alternativas tcnicas y
objetivos de usuario muy dinmico.
El modelo en espiral no est, todava, tan elaborado como los modelos ms establecidos. Por esta
razn, el modelo en espiral puede ser aplicado por personal experto, pero necesita elaboracin
posterior en reas como contratacin, especificaciones, puntos de control, revisiones, calendarios e
identificacin de reas de riesgo para ser completamente aplicable en todas las situaciones.
Algunas implementaciones parciales del modelo en espiral como el Plan de Gestin del Riesgo, son
compatibles con la mayora de los modelos de proceso actuales y son muy tiles para superar las
mayores fuentes de riesgo de proyectos.

Factor de riesgo Tcnicas de gestin del riesgo


1. Escasez de personal Formar una plantilla con personal de gran talento, integrado en el
trabajo, integrado en equipo, con alta moral y formado, incluyendo la
gente clave
2. Presupuestos y calendarios no Estimacin, de costes y plazos detallada, usando diversas fuentes;
realistas desarrollo incremental, reutilizacin de software, depuracin de
requisitos
3. Desarrollo de funciones de software Anlisis de la organizacin, anlisis del problema, entrevistas con
no adecuadas usuarios, prototipos, desarrollo temprano de manuales de usuario
4. Desarrollo de una interfaz de Anlisis de tareas, prototipos, guiones, caracterizacin de los usuarios
usuario no adecuada (funcionalidad, estilo, carga de trabajo)
5. Recubrimiento dorado Depuracin de requerimientos, prototipos, anlisis coste-beneficio,
diseo ajustado al coste
6. Continuos cambios de Alto umbral de cambio, desarrollo incremental (dejar los cambios para
requerimientos posteriores incrementos)
7. Componentes adquiridos en el Pruebas, inspecciones, verificacin de referencias, anlisis de
exterior sin la calidad necesaria compatibilidad
8. Tareas realizadas externamente Verificacin de referencias, auditoras previas a la aceptacin, contratos
que no tienen el nivel adecuado con penalizacin
9. Problemas de rendimiento en Simulacin, pruebas, modelado, prototipado, instrumentacin,
tiempo real afinamiento
10. Ir mas all del estado actual de las Anlisis tcnico, anlisis coste-beneficio, prototipos, verificacin de
posibilidades de la informtica referencias.

Tabla 1. Los 10 factores de riesgo del software ms importantes.

TEMARIO-TICB-feb04 B2G1T01
Actualizado en febrero de 2004 Pgina 17 de 21
www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968

1. Identificar los 10 factores del proyecto de mayor riesgo.


2. Presentar un plan para resolver cada factor de riesgo.
3. Actualizar mensualmente la lista de factores de mayor riesgo, planes y resultados.
4. Resaltar el estado de los factores de riesgo en las revisiones mensuales del proyecto.
Comparar con el estado de situacin de los meses anteriores.
5. Iniciar las acciones correctoras apropiadas.

Tabla 2. Plan de Gestin del Riesgo del Software

5. CONCLUSIN

Hemos visto, pues, como de la llamada crisis del software surge la necesidad de utilizar mtodos ms prximos
a la Ingeniera para afrontar los desarrollos de software.

Revisamos dos modelos de ciclo de vida:

El modelo en cascada cuyas limitaciones son sobradamente conocidas:

Los proyectos reales no se ajustan al modelo secuencial sino que se producen iteraciones que hacen
difcil la aplicacin del paradigma.
La mayora de los problemas provienen de la dificultad de definir al principio todos los requisitos del
sistema.
Los resultados no se ven hasta muy avanzado el proyecto por lo que la realizacin de un cambio
debido a un error puede suponer unas implicaciones muy importantes en el plazo de entrega y coste
del desarrollo.
y que parece ya un modelo agotado.

El modelo en espiral con claras ventajas:

Utiliza un enfoque evolutivo que permite al desarrollador y al cliente entender y reaccionar frente a
los riesgos en cada nivel evolutivo.
Utiliza la creacin de prototipos como un mecanismo de reduccin de riesgo.
Mantiene el enfoque sistemtico de fases del ciclo de vida clsico pero incorporndolo dentro de un
marco de trabajo interactivo que refleja mejor el mundo real.
y, tambin, dificultades:

Puede ser difcil convencer a grandes clientes de que el enfoque evolutivo es confortable.
Requiere una considerable habilidad y experiencia para la valoracin del riesgo. Si no se descubre un
riesgo importante surgirn problemas.
El modelo no ha sido tan probado como el modelo en cascada.

Cualquier modelo que resulte predominante en el futuro deber, en nuestra opinin, contemplar un concepto
fundamental: el de reusabilidad.

6. BIBLIOGRAFA

INGENIERA DEL SOFTWARE. Un enfoque prctico. Roger S. Pressman. Editorial McGraw Hill.
5 Edicin. Ao 2002.
Anlisis y diseo detallado de Aplicaciones Informticas de Gestin. Mario G. Piattini y otros. Editorial
RA-MA. Ao 1996.

TEMARIO-TICB-feb04 B2G1T01
Actualizado en febrero de 2004 Pgina 18 de 21
www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968

7. ESQUEMA RESUMEN

EVOLUCIN DEL SOFTWARE

1 Etapa: 1950-1965. Primeros aos de la informtica.


2 Etapa: 1965-1980. Multiprogramacin y sistemas multiusuario.
3 Etapa: 1975-1985. Sistemas distribuidos. LAN y WAN.
4 Etapa: Desde 1985. Tecnologas de 4 generacin. Orientacin a objetos.

CARACTERSTICAS ESPECIALES DEL SOFTWARE

El software no de fabrica en un sentido clsico, sino que se desarrolla.


El software no se estropea.
La mayor parte del software se construye a medida, en lugar de ensamblar componentes como hace
la industria.

LA CRISIS DEL SOFTWARE

La planificacin resultaba ser muy imprecisa. Plazos de entrega superados.


El coste final de los proyectos era superior al previsto.
Productividad baja.
Clientes insatisfechos.
Software difcil de mantener.

SOLUCIN: INGENIERA DEL SOFTWARE Aplicar principios de ingeniera para obtener software de calidad:

El software debe ser mantenible.


El software debe ser fiable.
El software debe ser eficiente.
Debe ofrecer una interfaz de usuario apropiada.

CONCEPTO DE CICLO DE VIDA Y FASES

Definicin Ciclo de Vida: Conjunto de etapas por las que atraviesa el sistema desde su concepcin, hasta su
retirada de servicio pasando por su desarrollo y explotacin.

Definir las actividades a realizar y su orden.


Asegurar la consistencia con el resto de los sistemas de informacin de la organizacin.
Proporcionar puntos de control para la gestin del proyecto (presupuesto y calendario).

PROCESOS DEL CICLO DE VIDA SOFTWARE (Norma ISO 12207-1)

Procesos Principales Procesos de Soporte Procesos de la Organizacin

Adquisicin. Documentacin. Gestin.


Suministro. Gestin de la Configuracin. Infraestructura.
Desarrollo. Aseguramiento de la Calidad. Mejora.
Explotacin. Verificacin. Formacin.
Mantenimiento. Validacin.
Revisin Conjunta.

TEMARIO-TICB-feb04 B2G1T01
Actualizado en febrero de 2004 Pgina 19 de 21
www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968

Auditora.
Resolucin de Problemas.

MODELO EN CASCADA

Serie de fases que se suceden secuencialmente, generndose en cada una de las fases resultados que
constituyen la entrada de la fase siguiente.

Planificacin.
Especificacin de Requisitos.
Diseo.
Codificacin.
Pruebas e integracin.
Implantacin y Aceptacin.
Mantenimiento.

Documentacin: Este modelo est regido por la documentacin, es decir, la decisin del paso de una fase a la
siguiente se toma en funcin de si la documentacin asociada a esa fase est completa o no.

CRTICA DEL MODELO

Los proyectos reales raramente siguen el flujo secuencial que propone el modelo.

El mtodo no prev revisiones o validaciones intermedias por parte del usuario. Los resultados de los trabajos
slo se ven al final de una serie de tareas y fases de tal forma que si se ha producido un error en las primeras
fases ste slo se detectar al final y su correccin tendr un costo muy elevado.

EXTENSIONES AL MODELO EN CASCADA

MODELO EN ESPIRAL DEL CICLO DE VIDA

Dimensin radial: Coste acumulativo en el que se ha incurrido en las etapas realizadas hasta el momento actual.
Dimensin angular: Representa el progreso hecho en completar cada ciclo de la espiral.

Cada ciclo implica una progresin que aplica la misma secuencia de pasos para cada parte del producto y para
cada uno de sus niveles de elaboracin, desde la concepcin global de la operacin hasta la codificacin de cada
programa individual.

Ejemplo de aplicacin: Empresa TRW.

VENTAJAS

a) Resume las buenas caractersticas de los dems modelos de desarrollo de software, mientras que su
procedimiento dirigido por el riesgo, evita muchas de sus dificultades.
b) Proporciona un mecanismo de incorporacin de objetivos de calidad en el desarrollo del producto
software.
c) Se potencia la reutilizacin.
d) Se adapta al diseo y programacin orientada a objetos.

DIFICULTADES

a) Adaptar su aplicabilidad al software contratado fuera de la organizacin.

TEMARIO-TICB-feb04 B2G1T01
Actualizado en febrero de 2004 Pgina 20 de 21
www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968

b) Dependencia de la experiencia en la evaluacin de riesgos.

TEMARIO-TICB-feb04 B2G1T01
Actualizado en febrero de 2004 Pgina 21 de 21

También podría gustarte