UNIDAD ACADMICA N 02:

PROCESO DEL DESARROLLO DEL SOFTWARE

Un sistema informtico est compuesto por hardware y software. En cuanto al hardware, su produccin se realiza sistemticamente y la base de conocimiento para el desarrollo de dicha actividad est claramente definida. La fiabilidad del hardware es, en principio, equiparable a la de cualquier otra mquina construida por el hombre. Un proceso de desarrollo de software tiene como propsito la produccin eficaz y eficiente de un producto software que rena los requisitos del cliente. Pero qu es con exactitud un proceso de software desde un punto de vista tcnico? Dentro de este contexto de este libro, un proceso de software se define como un marco de trabajo para las tareas que se requieren en la construccin de software de alta calidad. El proceso es sinnimo de ingeniera del software? La respuesta es s y no. Un proceso de software define el enfoque que se adopta mientras el software est en desarrollo. Pero la ingeniera del software tambin abarca las tecnologas que requiere el proceso (mtodos tcnicos y herramientas automatizadas).

Al finalizar el estudio de la presente unidad temtica el estudiante: 1. Concepta y diferencia las capas de la ingeniera del software. 2. Identifica el marco de trabajo para el proceso del software. 3. Describe los elementos y fases del ciclo de vida del software. 4. Identifica los procesos del ciclo de vida del software segn la Norma Tcnica Peruana vigente. 5. Diferencia los modelos de ciclos de vida para el desarrollo del software. Ing. Wagner E. Vicente Ramos
22

2.1. CAPAS DE LA INGENIERA DEL SOFTWARE La ingeniera del software es una tecnologa estratificada. Como se muestra en la figura, cualquier enfoque de la ingeniera (incluido el de la ingeniera del software) debe estar sustentado en un compromiso con la calidad- La base que soporta la ingeniera del software es un enfoqie en la calidad.

Figura : Capas de la Ingeniera de Software. Dichas capas se describen a continuacin: Cualquier disciplina de ingeniera (incluida la ingeniera del software) debe descansar sobre un esfuerzo de organizacin de calidad. La gestin total de la calidad y las filosofas similares fomentan una cultura continua de mejoras de procesos que conduce al desarrollo de enfoques cada vez ms robustos para la ingeniera del software. El fundamento de la ingeniera de software es la capa proceso. El proceso define un marco de trabajo para un conjunto de reas clave, las cuales forman la base del control de gestin de proyectos de software y establecen el contexto en el cual: se aplican los mtodos tcnicos, se producen resultados de trabajo, se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente. Los mtodos de la ingeniera de software indican cmo construir tcnicamente el software. Los mtodos abarcan una gran gama de tareas que incluyen anlisis de requisitos, diseo, construccin de programas, pruebas y mantenimiento. Estos mtodos dependen de un conjunto de principios bsicos que gobiernan cada rea de la

Ing. Wagner E. Vicente Ramos

23

tecnologa e incluyen actividades de modelado y otras tcnicas descriptivas. Las herramientas de la ingeniera del software proporcionan un soporte automtico o semi-automtico para el proceso y los mtodos, a estas herramientas se les llama herramientas CASE (Computer-Aided Software Engineering). Dado lo anterior, el objetivo de la ingeniera de software es lograr productos de software de calidad (tanto en su forma final como durante su elaboracin), mediante un proceso apoyado por mtodos y herramientas. 2.2. MARCO DE TRABAJO PARA EL PROCESO Un marco de trabajo establece la base para un proceso de software completo al identificar un nmero pequeo de actividades del marco de

trabajo aplicables a todos los proyectos de software, sin importar su

tamao o complejidad. El proceso de desarrollo de software no es nico. No existe un proceso de software universal que sea efectivo para todos los contextos de proyectos de desarrollo. Debido a esta diversidad, es difcil automatizar todo un proceso de desarrollo de software. A pesar de la variedad de propuestas de proceso de software, existe un conjunto de actividades fundamentales que se encuentran presentes en todos ellos: 1. Especificacin de software: Se debe definir la funcionalidad y restricciones operacionales que debe cumplir el software. 2. Diseo e Implementacin: Se disea y construye el software de acuerdo a la especificacin. 3. Validacin: El software debe validarse, para asegurar que cumpla con lo que quiere el cliente. 4. Evolucin: El software debe evolucionar, para adaptarse a las necesidades del cliente.

Ing. Wagner E. Vicente Ramos

24

Adems de estas actividades fundamentales, Pressman menciona un conjunto de actividades protectoras, que se aplican a lo largo de todo el proceso del software. Ellas se sealan a continuacin:

Seguimiento y control de proyecto de software. Revisiones tcnicas formales. Garanta de calidad del software. Gestin de configuracin del software. Preparacin y produccin de documentos. Gestin de reutilizacin. Mediciones. Gestin de riesgos.

Pressman caracteriza un proceso de desarrollo de software como se muestra en la Figura 3. Los elementos involucrados se describen a continuacin:

Un marco comn del proceso, definiendo un pequeo nmero de actividades del marco de trabajo que son aplicables a todos los proyectos de software, con independencia del tamao o complejidad.

Un conjunto de tareas, cada uno es una coleccin de tareas de ingeniera del software, hitos de proyectos, entregas y productos de trabajo del software, y puntos de garanta de calidad, que permiten que las actividades del proyecto. del marco de trabajo se adapten a las caractersticas del proyecto de software y los requisitos del equipo

Las actividades de proteccin, tales como garanta de calidad del software, gestin de configuracin del software y medicin, abarcan el modelo del proceso. Las actividades de proteccin son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.

Ing. Wagner E. Vicente Ramos

25

Figura 1: Elementos del proceso del software

Otra perspectiva utilizada para determinar los elementos del proceso de desarrollo de software es establecer las relaciones entre elementos que permitan responder Quin debe hacer Qu, Cundo y Cmo debe hacerlo.

Figura 2: Relacin entre elementos del proceso del software

En la Figura 4 se muestran los elementos de un proceso de desarrollo de software y sus relaciones. As las interrogantes se responden de la siguiente forma:

Quin: Las Personas participantes en el proyecto de desarrollo desempeando uno o ms Roles especficos.
26

Ing. Wagner E. Vicente Ramos

Qu: Un Artefacto es producido por un Rol en una de sus Actividades. Los Artefactos se especifican utilizando Notaciones especficas. Las Herramientas apoyan la elaboracin de Artefactos soportando ciertas Notaciones.

Cmo y Cundo: Las Actividades son una serie de pasos que lleva a cabo un Rol durante el proceso de desarrollo. El avance del proyecto est controlado mediante hitos que establecen un determinado estado de terminacin de ciertos Artefactos.

2.3. CICLO DE VIDA DEL SOFTWARE Todo proyecto de ingeniera tiene unos fines ligados a la obtencin de un producto, proceso o servicio que es necesario generar a travs de diversas actividades. Algunas de estas actividades pueden agruparse en fases porque globalmente contribuyen a obtener un producto intermedio, necesario para continuar hacia el producto final y facilitar la gestin del proyecto.

El ciclo de vida del software es una sucesin de etapas por las que pasa el software en su desarrollo, desde que se concibe la idea hasta que el software deja de utilizarse (obsolescencia).
Cada etapa lleva asociada una serie de actividades y tareas que se deben realizar, y una serie de documentos que sern la salida de cada una de estas fases y que servirn de entrada a la fase siguiente Segn la norma ISO/IEC Standard 12207:2008: Software life-Cycle processes propuesta por la ISO (International Organization for Standardization). El ciclo de vida del software: Es un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, explotacin y mantenimiento de un producto software, abarcando la vida del sistema desde la definicin de requisitos hasta que se deja de utilizar

Ing. Wagner E. Vicente Ramos

27

2.3.1. Elementos Del Ciclo De Vida Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas planificables. Segn el modelo de ciclo de vida, la sucesin de fases puede ampliarse con bucles de realimentacin, de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar ms de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecucin aportaciones de los resultados intermedios que se van produciendo (realimentacin).

Figura 2.4: Elementos del ciclo de vida

Para un adecuado control de la progresin de las fases de un proyecto se hace necesario especificar con suficiente precisin los resultados evaluables, o sea, productos intermedios que deben resultar de las tareas incluidas en cada fase. Normalmente estos productos marcan los hitos entre fases. A continuacin presentamos los distintos elementos que integran un ciclo de vida:

Fases.

Una

fase

es

un

conjunto

de

actividades

relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupacin temporal de tareas impone requisitos de temporales recursos correspondientes a la o asignacin materiales). Ing. Wagner E. Vicente Ramos
28

(humanos,

financieros

Cuanto ms grande y complejo sea un proyecto, mayor detalle se necesitar en la definicin de las fases para que el contenido de cada una siga siendo manejable. De esta forma, cada fase de un proyecto puede considerarse un micro-proyecto en s mismo, compuesto por un conjunto de micro-fases. Otro motivo para descomponer una fase en subfases menores puede ser el inters de separar partes temporales del proyecto que se subcontraten a otras organizaciones,
Figura 2.5: Descomposicin de fases

requiriendo

distintos

procesos de gestin.

Cada fase viene definida por un conjunto de elementos observables externamente, como son las actividades con las que se relaciona, los datos de entrada (resultados de la fase anterior, documentos o productos requeridos para la fase, experiencias de proyectos anteriores), los datos de salida (resultados a utilizar por la fase posterior, experiencia acumulada, pruebas o resultados efectuados) y la estructura interna de la fase.

Figura 2.6: Esquema general de operacin de una fase

Entregables ("deliverables"). Son los productos intermedios que generan las fases. o Pueden ser materiales (componentes, equipos) inmateriales (documentos,

Ing. Wagner E. Vicente Ramos

29

software). Los entregables permiten evaluar la marcha del proyecto mediante comprobaciones de su adecuacin o no a los requisitos funcionales y de condiciones de realizacin previamente establecidos. Cada una de estas evaluaciones puede servir, adems, para la toma de decisiones a lo largo del desarrollo del proyecto.

2.3.2. Fases genricas en el ciclo de vida del SW Fase de definicin Qu? Tareas: - Ingeniera de sistemas - Planificacin del proyecto del SW - Anlisis de los requisitos Fase de desarrollo Cmo? Tareas: - Diseo del SW - Generacin de cdigo - Prueba del SW Fase de mantenimiento. Cambios: - Correccin - Adaptacin - Mejora - Prevencin

2.4. PROCESO DEL CICLO DE VIDA DEL SOFTWARE SEGN NTP-ISO/IEC 12207 - 2008 Esta NTP (Norma Tcnica Peruana) agrupa las actividades que se pueden llevar a cabo durante el ciclo de vida del software en cinco Ing. Wagner E. Vicente Ramos
30

procesos principales, ocho procesos de soporte y cuatro procesos generales.

2.4.1. Procesos Principales Adquisicin: Actividades y tareas que el comprador, el cliente o el usuario realizan para adquirir un sistema, un servicio o un producto software: - Preparacin y publicacin de ofertas - Seleccin del suministrador de SW Suministro: Actividades y tareas del suministrador: - Preparar contratos como respuesta a una peticin de un comprador de un producto SW. - Identificar los recursos necesarios para llevar a cabo con xito el desarrollo del producto SW. Desarrollo: Actividades y tareas enfocadas a la obtencin de un producto Software - Anlisis - Diseo - Codificacin Ing. Wagner E. Vicente Ramos
31

- Pruebas - Integracin - Implantacin Explotacin: Explotacin del SW y soporte operativo a los usuarios. Mantenimiento: Actividades que incluyen modificaciones del producto, tanto del cdigo como de la documentacin, debido a errores o a la necesidad de mejora o/y adaptacin. - Migracin hacia un nuevo entorno operativo - Retirada del producto

2.4.2. Procesos de Soporte Dan soporte al resto de procesos y se aplican durante cualquier momento del ciclo de vida del SW. Documentacin: Registrar la informacin producida por un proceso o actividad del ciclo de vida: - Disear, editar, distribuir y mantener los documentos producidos durante el desarrollo del SW. Gestin de la Configuracin: Actividades que controlan las modificaciones y versiones de los elementos. - Registrar las peticiones de cambios e informar de los estados de stos. Aseguramiento de la calidad: Actividades para asegurar que los productos cumplen los requisitos especificados y se ajustan a los planes establecidos Verificacin: Actividades para determinar el buen

funcionamiento de un producto software. Validacin: Actividades para determinar si el producto Ing. Wagner E. Vicente Ramos
32

cumple los requisitos previstos. Revisin conjunta: Actividades que permiten determinar el estado de los productos en una determinada actividad del ciclo de vida o en una cierta fase del proyecto. Puede ser una reunin conjunta con el cliente, el grupo de desarrollo y los clientes potenciales para revisar el trabajo hecho Auditoras: Actividades que permiten determinar en unos momentos determinados si se han conseguido los objetivos propuestos: requisitos, cumplimiento del contrato, etc. Resolucin de problemas: Actividades que permiten analizar y resolver los problemas o disconformidadescon los requisitos o con el contrato, que hayan surgido durante el desarrollo, la explotacin, el mantenimiento, o en cualquier otro momento. - Disponer de un medio documental que permita asegurar que todos los problemas se han tratado

2.4.3. Procesos Generales Se emplean para fortalecer el diseo organizacional: Gestin: Actividades de planificacin, seguimiento,

control, revisin y evaluacin. Infraestructura: Actividades para determinar la

infraestructura necesaria para un proceso. Incluye HW, SW, instalaciones Mejora: Valorar, medir, controlar, evaluar y mejorar todos los procesos del ciclo de vida. Formacin: Plan de formacin para los empleados.

Ing. Wagner E. Vicente Ramos

33

2.5. PROCESO DEL DESARROLLO DE SOFTWARE SEGN NTPISO/IEC 12207 - 2008 El proceso de desarrollo contiene las actividades y tareas del desarrollador. El proceso contiene anlisis software. Lista de actividades: Este proceso consta de las siguientes actividades: a) Implementacin del proceso. b) Anlisis de los requerimientos del sistema. c) Diseo de la arquitectura del sistema. d) Anlisis de los requerimientos software. e) Diseo de la arquitectura del software. f) Diseo detallado del software. de los las actividades para el requerimientos, diseo, codificacin, integracin,

pruebas e instalacin y aceptacin relacionadas con los productos

g) Codificacin y pruebas del software. h) Integracin del software. i) j) Pruebas de calificacin del software. Integracin del sistema.

k) Pruebas de calificacin del sistema. l) Instalacin del software.

m) Apoyo a la aceptacin del software.

2.6. MODELOS DEL CICLO DE VIDA DEL DESARROLLO DE SOFTWARE Las principales diferencias entre distintos modelos de ciclo de vida estn divididas en tres grandes visiones: El alcance del ciclo de vida, que depende de hasta dnde deseamos llegar con el proyecto: slo saber si es viable el

Ing. Wagner E. Vicente Ramos

34

desarrollo de un producto, el desarrollo completo o el desarrollo completo ms las actualizaciones y el mantenimiento. La cualidad y cantidad de las etapas en que dividiremos el ciclo de vida: segn el ciclo de vida que adoptemos, y el proyecto para el cual lo adoptemos. La estructura y la sucesin de las etapas, si hay realimentacin entre ellas, y si tenemos libertad de repetirlas (iterar). En los distintos modelos de ciclo de vida mencionaremos la efectividad del modelo est ne funcin del riesgo que suponemos aceptar al elegirlo. Cuando hablamos de riesgo, nos referimos a la probabilidad que tendremos de volver a retomar una de las etapas anteriores, perdiendo tiempo, dinero y esfuerzo. 2.6.1. Ciclo de vida lineal Es el ms sencillo de todos los modelos. Consiste en descomponer la actividad global del proyecto en etapas separadas que son realizadas de manera lineal, es decir, cada etapa se realiza una sola vez, a continuacin de la etapa anterior y antes de la etapa siguiente. Con un ciclo de vida lineal es muy fcil dividir las tareas, y prever los tiempos (sumando linealmente los de cada etapa).

Las actividades de cada una de las etapas mencionadas deben ser independientes entre s, es decir, que es condicin primordial que no haya retroalimentacin entre ellas, aunque s pueden admitirse ciertos supuestos de realimentacin correctiva. Desde el punto de vista de la gestin, requiere tambin que se conozca desde el primer momento, con excesiva rigidez, lo que va a ocurrir en cada una de las distintas etapas antes de comenzarla.

Ing. Wagner E. Vicente Ramos

35

Esto ltimo minimiza, tambin, las posiblidades de errores durante la codificacin y reduce al mnimo la necesidad de requerir informacion del cliente o del usuario. Se destaca como ventaja la sencillez de su gestin y administracin tanto econmica como temporal, ya que se acomoda perfectamente a proyectos internos de una empresa para programas muy pequeos de ABM (sistemas que realizan Altas, Bajas y Modificaciones sobre un conjunto de datos). Tiene como desventaja que no es apto para Desarrollos que superen mnimamente requerimientos de retroalimentacin entre etapas, es decir, es muy costoso retomar una etapa anterior al detectar alguna falla. Es vlido tomar este ciclo de vida cuando algn sector pequeo de una empresa necesita llevar un registro de datos acumulativos, sin necesidad de realizar procesos sobre ellos ms que una consulta simple. Es decir, una aplicacin que se dedique exclusivamente a almacenar datos, sea una base de datos o un archivo plano. Debido a que la realizacin de las etapas es muy simple y el cdigo muy sencillo. 2.6.2. Ciclo de vida en cascada puro Este modelo de ciclo de vida fue propuesto por Winston Royce en el ao 1970. Es un ciclo de vida que admite iteraciones, contrariamente a la creencia de que es un ciclo de vida secuencial como el lineal. Despus de cada etapa se realiza una o varias revisiones para comprobar si se puede pasar a la siguiente. Es un modelo rgido, poco flexible, y con muchas restricciones. Aunque fue uno de los primeros, y sirvi de base para el resto de los modelos de ciclo de vida. Una de sus ventajas, adems de su planificacin sencilla, es la de proveer un producto con un elevado grado de calidad sin necesidad de un personal altamente calificado.

Ing. Wagner E. Vicente Ramos

36

Se pueden considerar como inconvenientes: la necesidad de contar con todos los requerimientos (o la mayora) al comienzo del proyecto, y, si se han cometido errores y no se detectan en la etapa inmediata siguiente, es costoso y difcil volver atrs para realizar la correccion posterior. Adems, los resultados no los veremos hasta que no estemos en las etapas finales del ciclo, por lo que, cualquier error detectado nos trae retraso y aumenta el costo del desarrollo en funcion del tiempo que insume la correccion de stos. Es un ciclo adecuado para los proyectos en los que se dispone de todos los requerimientos al comienzo, para el desarrollo de un producto con funcionalidades conocidas o para proyectos, que aun siendo muy complejos, se entienden perfectamente desde el principio. Fue utilizado en medianos y grandes proyectos hasta principios de la dcada de 1990, y a finales de esta dcada las crticas a

Ing. Wagner E. Vicente Ramos

37

este modelo aumentaron notablemente. Por lo que hoy en da slo se lo cita como mero ejemplo bibliogrfico. 2.6.3. Ciclo de vida en V Este ciclo fue diseado por Alan Davis, y contiene las mismas etapas que el ciclo de vida en cascada puro. A diferencia de aqul, a ste se le agregaron dos subetapas de retroalimentacin entre las etapas de anlisis y mantenimiento, y entre las de diseo y prueba.

Las ventajas y desventajas de este modelo son las mismas del ciclo anterior, con el agregado de los controles cruzados entre etapas para lograr una mayor correccin. Podemos utilizar este modelo de ciclo de vida en aplicaciones, que si bien son simples (pequeas transacciones sobre bases de datos por ejemplo), necesitan una confiabilidad muy alta. Un ejemplo claro en el que no nos podemos permitir el lujo de cometer errores es una aplicacin de facturacin, en la que si bien los procedimientos vistos individualmente son de codificacin e interpretacin sencilla, la aplicacin en su conjunto puede tener matices complicados. 2.6.4. Ciclo de vida iterativo Tambin derivado del ciclo de vida en cascada puro, este modelo busca reducir el riesgo que surge entre las necesidades

Ing. Wagner E. Vicente Ramos

38

del usuario y el producto final por malos entendidos durante la etapa de solicitud de requerimientos. Es la iteracin de varios ciclos de vida en cascada. Al final de cada iteracin se le entrega al cliente una versin mejorada o con mayores funcionalidades del producto. El cliente es quien luego de cada iteracin, evala el producto y lo corrige o propone mejoras. Estas iteraciones se repetirn hasta obtener un producto que satisfaga al cliente.

Se suele utilizar en proyectos en los que los requerimientos no estn claros de parte del usuario, por lo que se hace necesaria la creacin de distintos prototipos para presentarlos y conseguir la conformidad del cliente. Podemos adoptar el modelo mencionado en aplicaciones medianas a grandes, en las que el usuario o cliente final no necesita todas las funcionalidades desde el principio del proyecto. Quizs una empresa que debe migrar sus aplicaciones hacia otra arquitectura, y desea hacerlo paulatinamente, es un candidato ideal para este tipo de modelo de ciclo de vida. 2.6.5. Ciclo de vida por prototipos El uso de programas prototipo no es exclusivo del ciclo de vida iterativo.

Ing. Wagner E. Vicente Ramos

39

En la prctica los prototipos se utilizan para validar los requerimientos de los usuarios en cualquier ciclo de vida. Si no se conoce exactamente cmo desarrollar un determinado producto o cules son las especificaciones de forma precisa, suele recurrirse a definir especificaciones iniciales para hacer un prototipo, o sea, un producto parcial y provisional. En este modelo, el objetivo es lograr un producto intermedio, antes de realizar el producto final, para conocer mediante el prototipo cmo respondern las funcionalidades previstas para el producto final. Antes de adoptar este modelo de ciclo debemos evaluar si el esfuerzo por crear un prototipo vale realmente la pena adoptarlo.

Se utiliza mayoritariamente en desarrollos de productos con innovaciones importantes, o en el uso de tecnologas nuevas o poco probadas, en las que la incertidumbre sobre los resultados a obtener, o la ignorancia sobre el comportamiento, impiden iniciar un proyecto secuencial. La ventaja de este ciclo se basa en que es el nico apto para desarrollos en los que no se conoce a priori sus especificaciones o la tecnologa a utilizar. Como contrapartida, por este

Ing. Wagner E. Vicente Ramos

40

desconocimiento, tiene la desventaja de ser altamente costoso y difcil para la administracin temporal. Si deseamos migrar aplicaciones de tecnologa para adoptar sus nuevas funcionalidades o simplemente para estar en la cresta de la ola, este modelo es ideal. Un claro ejemplo son las llegadas de Java y la tecnologa .NET que si bien contaban con respaldo y material de ayuda, implantaron nuevas tendencias. 2.6.6. Ciclo de vida evolutivo Este modelo acepta que los requerimientos del usuario pueden cambiar en cualquier momento. La prctica nos demuestra que obtener todos los requerimientos al comienzo del proyecto es extremadamente difcil, no slo por la dificultad del usuario de transmitir su idea, sino porque estos requerimientos evolucionan durante el desarrollo y de esta manera, surgen nuevos requerimientos a cumplir. El modelo de ciclo de vida evolutivo afronta este problema mediante una iteracin de ciclos requerimientos desarrolloevaluacin.

Ing. Wagner E. Vicente Ramos

41

Resulta ser un modelo muy til cuando desconocemos la mayora de los requerimientos iniciales, o estos requerimientos no estn completos. Tomemos como ejemplo un sistema centralizado de stock ventasfacturacin, en el cual hay muchas reas que utilizarn la aplicacin. Tenemos dos complicaciones: la primera, los usuarios no conocen de informtica, la segunda, no es uno, sino varios los sectores que nos pueden pedir modificaciones o hacer nuevas solicitudes. Adems, el pedido de un sector puede influir en los requerimientos del otro. Se hace necesario, entonces, lograr que la aplicacin evolucione hasta lograr las satisfacciones de los todos los sectores involucrados. 2.6.7. Ciclo de vida incremental Este modelo de ciclo de vida se basa en la filosofa de construir incrementando las funcionalidades del programa.

Se realiza construyendo por modulos que cumplen las diferentes funciones del sistema. Esto permite ir aumentando gradualmente las capacidades del software. Este ciclo de vida facilita la tarea del desarrollo permitiendo a cada miembro del equipo desarrollar
42

Ing. Wagner E. Vicente Ramos

un modulo particular en el caso de que el proyecto sea realizado por un equipo de programadores. Es una repeticin del ciclo de vida en cascada, aplicndose este ciclo en cada funcionalidad del programa a construir. Al final de cada ciclo le entregamos una versin al cliente que contiene una nueva funcionalidad. Este ciclo de vida nos permite realizar una entrega al cliente antes de terminar el proyecto. El modelo de ciclo de vida incremental nos genera algunos beneficios tales como los que se describen a continuacion: Construir un sistema pequeo siempre es menos riesgoso que construir un sistema grande. Como desarrollamos independientemente las funcionalidades, es ms fcil relevar los requerimientos del usuario. Si se detecta un error grave, slo desechamos la ltima iteracin. No es necesario disponer de los requerimientos de todas las funcionalidades en el comienzo del proyecto y adems facilita la labor del desarrollo con la conocida filosofa de divide y vencers. Este modelo de ciclo de vida no est pensado para cierto tipo de aplicaciones, sino que est orientado a cierto tipo de usuario o cliente. Podremos utilizar este modelo de ciclo de vida para casi cualquier proyecto, pero ser verdaderamente til cuando el usuario necesite entregas rpidas, aunque sean parciales. 2.6.8. Ciclo de vida en espiral Este ciclo puede considerarse una variacin del modelo con prototipado, fue diseado por Boehm en el ao 1988. El modelo se basa en una serie de ciclos repetitivos para ir ganando madurez en el producto final. Toma los beneficios de los ciclos de vida incremental y por prototipos, pero se tiene ms en cuenta el concepto de riesgo que aparece debido a las

Ing. Wagner E. Vicente Ramos

43

incertidumbres

ignorancias

de

los

requerimientos

proporcionados al principio del proyecto o que surgirn durante el desarrollo. A medida que el ciclo se cumple (el avance del espiral), se van obteniendo prototipos sucesivos que van ganando la satisfaccin del cliente o usuario. A menudo, la fuente de incertidumbres es el propio cliente o usuario, que en la mayora de las oportunidades no sabe con perfeccin todas las funcionalidades que debe tener el producto.

En este modelo hay cuatro actividades que envuelven a las etapas. Planificacin: Relevamiento de requerimientos iniciales o luego de una iteracin. Anlisis de riesgo: De acuerdo con el relevamiento de requerimientos decidimos si continuamos con el desarrollo.

Ing. Wagner E. Vicente Ramos

44

 Implementacin: desarrollamos un prototipo basado en los requerimientos. Evaluacin: El cliente evala el prototipo, si da su conformidad, termina el proyecto. En caso contrario, incluimos los nuevos requerimientos solicitados por el cliente en la siguiente iteracin. La ventaja ms notoria de este modelo de desarrollo de software es que puede comenzarse el proyecto con un alto grado de incertidumbre, se entiende tambin como ventaja el bajo riesgo de retraso en caso de deteccin de errores, ya que se puede solucionar en la prxima rama del espiral. Algunas de las las desventajas son: el costo temporal que suma cada vuelta del espiral, la dificultad para evaluar los riesgos y la necesidad de la presencia o la comunicacion continua con el cliente o usuario. Se observa que es un modelo adecuado para grandes proyectos internos de una empresa, en donde no es posible contar con todos los requerimientos desde el comienzo y el usuario est en nuestro mismo ambiente laboral. Podemos citar una aplicacin que administre reclamos, pedidos e incidentes, como ejemplo para utilizar este modelo de ciclo de vida, en el que los sectores que utilizarn el sistema son demasiados y con intereses muy diversos como para lograr un relevamiento exhaustivo y completo de los requerimientos. 2.6.9. Ciclo de vida orientado a objetos Esta tcnica fue presentada en la dcada del 90, tal vez como una de las mejores metodologas a seguir para la creacin de productos software. Puede considerarse como un modelo pleno a seguir, como as tambin una alternativa dentro de los modelos anteriores. Al igual que la filosofa del paradigma de la programacin orientada a objetos, en esta metodologa cada funcionalidad, o

Ing. Wagner E. Vicente Ramos

45

requerimiento solicitado por el usuario, es considerado un objeto. Los objetos estn representados por un conjunto de propiedades, a los cuales denominamos atributos, por otra parte, al comportamiento que tendrn estos objetos los denominamos mtodos. Vemos que tanto la filosofa de esta metodologa, los trminos utilizados en ella y sus fines, coinciden con la idea de obtener un concepto de objeto sobre casos de la vida real.

En este modelo se utilizan las llamadas fichas CRC (clase responsabilidadescolaboracin) como herramienta para obtener las abstracciones y mecanismos clave de un sistema analizando los requerimientos del usuario. En la ficha CRC se escribe el nombre de la clase u objeto, sus responsabilidades (los mtodos) y sus colaboradores (otras clases u objetos de los cuales necesita). Estas fichas, adems, nos ayudan a confeccionar los denominados casos de uso. No es correcto suponer que este modelo slo es til cuando se escoge para la implementacin un lenguaje con orientacin a objetos. Se puede utilizar independientemente del lenguaje elegido. Como mencionamos, es un modelo muy verstil, y por ser uno de los ltimos en aparecer, aprendi mucho de los anteriores. Las aplicaciones que podemos incluir como ejemplo para su uso
46

Ing. Wagner E. Vicente Ramos

van desde programas de monitoreo de procesos, grandes sistemas de transacciones sobre base de datos, hasta procesamiento por lotes. Luego de ver algunos de los modelos de ciclo de vida ms utilizados surge la pregunta con la respuesta ms codiciada: qu modelo de ciclo de vida elegir? Sabemos que ninguno predomina sobre los otros. Por ello, debemos elegir el modelo que mejor se adapte al proyecto que desarrollaremos. Podemos analizar, para guiarnos en nuestra eleccin, la complejidad del problema, el tiempo que disponemos para hacer la entrega final, o si el usuario o cliente desea entregas parciales, la comunicacin que existe entre el equipo de desarrollo y el usuario y, por ltimo, qu certeza (o incertidumbre) tenemos de que los requerimientos dados por el usuario son correctos y completos.

ACTIVIDAD 2
A modo de encuesta, pregunte a sus colegas programadores, quin y por qu ha utilizado un ciclo de vida. Indague sobre los resultados obtenidos.

En este capitulo se explica de una manera sencilla los aspectos conceptuales relacionados al proceso del desarrollo del software, considerando la Norma Tcnica Peruana ISO/IEC 12207 2008 como gua estandarizada y aceptada en nuestro pas.

Ing. Wagner E. Vicente Ramos

47