Ciclo Vida Software

Embed Size (px)

Text of Ciclo Vida Software

2

Ciclo de vida del software

Objetivos del captuloComprender el concepto de Ciclo de Vida y su importancia para el Software. Conocer el Modelo en Cascada. Conocer el Modelo Incremental. Conocer el Modelo en Espiral. Conocer las caractersticas de los ciclos de vida de los sistemas orientados a objetos.

ANLISIS Y DISEO DETALLADO DE APLICACIONES...

RA-MA

2.1 INTRODUCCINTradicionalmente el desarrollo de aplicaciones informticas se llevaba a cabo de forma individualizada, a base de codificar (generar lneas de cdigo) y probar lo realizado cuanto antes. La misma persona escriba el cdigo, lo ejecutaba y, si fallaba, lo depuraba. El proceso se realizaba sin ninguna planificacin previa y sin que soliese existir documentacin alguna. Debido a que la movilidad en el trabajo era baja, los ejecutivos estaban seguros de que esa persona estara all cuando se produjese algn fallo. En principio, el hecho de que desde un primer momento se vaya generando cdigo, podra considerarse como un sntoma de enorme progreso, pero puede suponer posteriormente un gran retroceso e incluso la necesidad de desechar una gran parte de lo realizado en el caso de que existan errores y no se puedan llevar a cabo las modificaciones necesarias para subsanarlos (por ejemplo, si al 90% del cdigo se descubre que el diseo de la base de datos es incorrecto, puede suponer desechar el trabajo y tener que comenzar de nuevo). Con este enfoque, cualquier cosa que no sea codificacin pura y dura no se realiza (como, por ejemplo, actividades de planificacin, de documentacin, de aseguramiento de la calidad). Esta forma de desarrollar aplicaciones es muy comn en muchas organizaciones y, generalmente, se utiliza cuando no se elige o sigue un enfoque de desarrollo (ciclo de vida) concreto y/o apenas se realiza la actividad de planificacin. Adems, otro factor que juega a favor de este enfoque de codificar y probar es que requiere poca experiencia y cualquier persona podr fcilmente familiarizarse con l [MCCONNELL, 1997]. Esta forma de desarrollar software puede ser eficaz en programas pequeos. Para otro tipo de proyectos, puede resultar peligrosa su utilizacin, ya que no se puede conocer el progreso del proyecto, ni tampoco su calidad, simplemente se est codificando y probando hasta que finaliza el proyecto. Otras maneras de realizar el desarrollo software, como se vern en los siguientes apartados, permitirn, por ejemplo, conocer el progreso, detectar un error lo antes posible, etc. Por lo tanto, es probable que las aplicaciones realizadas segn este enfoque de codificar y probar: Sean poco flexibles, y ante posibles modificaciones (por cambios en los requerimientos del cliente, cambios en el hardware, etc.) se incremente el coste de los proyectos e, incluso, en ocasiones, resulten virtualmente irrealizables debido a la naturaleza personalizada de los programas y a la falta de documentacin (lo que provocar problemas de mantenimiento). Sean incompletas o no reflejen bien las necesidades del cliente, es decir, que no realicen todas las funciones requeridas y, adems, lo hagan con una escasa fiabilidad. Provoquen el descontento de los clientes, pues se producen retrasos en la entrega (no se conoce el momento exacto en el que se entregarn), aparecen errores

46

RA-MA

2 CICLO DE VIDA DEL SOFTWARE

una vez que la aplicacin ha sido entregada (lgico al no haberse realizado de forma sistemtica actividades de verificacin y validacin en el proyecto). Por tanto, es necesario que todo esfuerzo en el desarrollo del software conlleve un enfoque lgico para su realizacin. Dicho enfoque debe abarcar toda la vida del sistema, comenzando con su concepcin y finalizando cuando ya no se utiliza o se retira [SIGWART, 1990]. El ciclo de vida software es la descripcin de las distintas formas de desarrollo de un proyecto o aplicacin informtica, es decir, la orientacin que debe seguirse para obtener, a partir de los requerimientos del cliente, sistemas que puedan ser utilizados por dicho cliente. Tambin puede definirse como el conjunto de fases o etapas, procesos y actividades requeridas para ofertar, desarrollar, probar, integrar, explotar y mantener un producto software. Las funciones principales de un ciclo de vida software son: Determinar el orden de las fases y procesos involucrados en el desarrollo del software y su evolucin (teniendo en cuenta el modelo de procesos que se utilice como referencia). Establecer los criterios de transicin para pasar de una fase a la siguiente (productos intermedios). Todo ello, incluye los criterios para la terminacin de la fase actual y los criterios para seleccionar e iniciar la fase siguiente. El ciclo de vida software da respuesta a las siguientes preguntas de la gestin de un proyecto de software: Qu har a continuacin? Cunto tiempo continuar hacindolo? El ciclo de vida que se seleccione en un proyecto [DAVIS, 1988] influir en el xito del proyecto, y puede ayudar a asegurar que cada paso que se d acorte ms la consecucin del objetivo. Dependiendo del ciclo de vida que se seleccione, se puede aumentar la velocidad de desarrollo, mejorar la calidad, el control y el seguimiento del proyecto, minimizar gastos y riesgos, o mejorar las relaciones con los clientes. Una seleccin ineficaz puede ser una fuente constante de ralentizacin del trabajo, trabajo repetitivo, innecesario y frustrante. Algunas de las ventajas que aporta el enfoque de ciclo de vida residen en lo siguiente: En las primeras fases, aunque no haya lneas de cdigo, pensar el diseo es avanzar en la construccin del sistema, pues posteriormente resulta ms fcil la codificacin. Asegura un desarrollo progresivo, con controles sistemticos, que permite detectar precozmente los defectos. Se controla el sobrepasar los plazos de entrega y los costes excesivos, mediante un adecuado seguimiento del progreso.

47

ANLISIS Y DISEO DETALLADO DE APLICACIONES...

RA-MA

La documentacin se realiza de manera formal y estandarizada simultneamente al desarrollo, lo que facilita la comunicacin interna entre el equipo de desarrollo y la de ste con los usuarios. Tambin aumenta la visibilidad y la posibilidad de control para la gestin del proyecto. Supone una gua para el personal de desarrollo, marcando las tareas a realizar en cada momento. Minimiza la necesidad de rehacer trabajo y los problemas de puesta a punto. A continuacin, se presentan algunos de los modelos de ciclo de vida ms comunes.

2.2 MODELO EN CASCADA (WATERFALL)La versin original del modelo de ciclo de vida en cascada fue propuesta por Royce [ROYCE, 1970] y, desde entonces, han aparecido numerosos refinamientos y variaciones de dicho modelo: por ejemplo, [BOEHM, 1981], [SOMMERVILLE, 1985], [SIGWART, 1990]. El nmero de fases o etapas que se proponen en este ciclo suele variar, aunque suelen ser: anlisis de requisitos del sistema, anlisis de requisitos del software, diseo preliminar, diseo detallado, codificacin, pruebas, explotacin y mantenimiento (vase la figura 2.1). Algunas caractersticas de este ciclo son: Cada fase empieza cuando se ha terminado la fase anterior [HAWRYSZKIEWYCZ, 1990]. Para pasar de una fase a otra es necesario conseguir todos los objetivos de la etapa previa [BOEHM, 1981]. Para ello, se realiza una revisin al final de la fase. Ayuda a prevenir que se sobrepasen las fechas de entrega y los costes esperados.

Figura 2.1. Ciclo de Vida en Cascada.

48

RA-MA

2 CICLO DE VIDA DEL SOFTWARE

Al final de cada fase el personal tcnico y los usuarios tienen la oportunidad de revisar el progreso del proyecto. Aunque es el ciclo de vida ms antiguo y el ms ampliamente utilizado, debido a las facilidades que da a los gestores para controlar el progreso de los sistemas, ha recibido numerosas crticas (vase, por ejemplo, [McCRACKEN y JACKSON, 1982]). Algunas de las crticas del modelo en cascada son: No refleja el proceso real de desarrollo de software. Los proyectos reales raramente siguen este flujo secuencial, puesto que siempre hay iteraciones. Aunque en este modelo la iteracin est permitida en etapas contiguas [MACRO, 1990], en la vida real normalmente la iteracin abarca ms de una etapa. Un caso tpico es la redefinicin de los requisitos cuando se est codificando la aplicacin. Se tarda mucho tiempo en pasar por todo el ciclo, dado que hasta que no se finalice una fase no se pasa a la siguiente. As, se podra dar el caso de no salir nunca de la fase de anlisis de requisitos software. Acenta el fracaso de la industria del software con el usuario final. En este caso, el usuario debe tener paciencia [PRESSMAN, 2002], ya que el sistema en funcionamiento no estar disponible hasta las fases finales del proyecto.

2.3 MODELO INCREMENTALEl modelo incremental [LEHMAN, 1984] corrige la necesidad de una secuencia no lineal de pasos de desarrollo. En el modelo incremental (vase la figura 2.2) se va creando el sistema software aadiendo componentes funcionales al sistema (llamados incrementos). En cada paso sucesivo, se actualiza el sistema con nuevas funcionalidades o requisitos, es decir, cada versin o refinamiento parte de una versin previa y le aade nuevas funciones [AMESCUA et al, 1995]. El sistema software ya no se ve como una nica entidad monoltica con una fecha fija de entrega, sino como una integracin de resultados sucesivos obtenidos despus de cada iteracin. El modelo incremental se ajusta a entornos de alta incertidumbre, por no tener la necesidad de poseer un conjunto exhaustivo de requisitos, especificaciones, diseos, etc., al comenzar el sistema, ya que cada refinamiento ampla los requisitos y las especificaciones derivadas de la fase anterior. El modelo incremental constituy un avance sobre el modelo en cascada, pero tambin presenta problemas. Aunque permite el cambio continuo de requisitos,

49

ANLISIS Y DISEO DETALLADO DE APLICACIONES...

RA-MA

Figura 2.2. Modelo en cascada utilizando el desarrollo incremental.

an existe el problema de determinar si los requisitos propuestos son vlidos. Los errores en los requisitos se detectan tarde y su correccin resulta tan costosa como en el modelo en cascada.

2.4 MODELO EN ESPIRALCon el fin de paliar los inconvenientes del modelo en cascada, [BOEHM, 1988] propuso el modelo en espiral (vase la figura 2.3), que consta de una serie de ciclos. Cada uno empieza identificando los objetivos, las alternativas y las restricciones del ciclo. Una vez evaluadas las alternativas respecto a los objetivos y teniendo en cuenta las restricciones, se lleva a cabo el ciclo correspondiente para, una vez finalizado, empezar a plantear el prximo. Para ver de forma ms clara el modelo en espiral, lo explicaremos con un ejemplo. Cada ciclo de la espiral comienza con la identificacin de: Los objetivos de la parte del producto que est siendo elaborada (rendimientos, funcionalidad, adaptacin al cambio, etc.). Por ejemplo, una empresa que desea aumentar su productividad de software. Las alternativas principales de la implementacin de esta porcin del producto (usar el diseo A, usar el diseo B, reutilizar el mdulo X de la aplicacin Z, comprar a un proveedor externo, etc.). Para el ejemplo anterior, existen diferentes alternativas: en el rea de tecnologa se podra reutilizar software o utilizar ciertas herramientas, determinados mtodos que condujeran al desarrollo de mejores productos. Pero tambin existen alternativas no software que marcan la posibilidad de realizar actividades no software, por ejemplo en las reas de gestin (la organizacin de los proyectos, la poltica de la empresa, la planificacin y el control de los proyectos, etc.), de perso-

50

RA-MA

2 CICLO DE VIDA DEL SOFTWARE

nal (la incorporacin de plantilla, la promocin de incentivos, la formacin, etc.) y de soporte (comunicaciones entre el personal, lugares de trabajo, etc.). Las restricciones impuestas para cada alternativa (costes, planificaciones, interfaces, etc.). Para el ejemplo, las restricciones podran ser que el aumento de productividad fuera a un coste razonable, que no se cambiase la cultura de la empresa, etc. El segundo paso es evaluar las diferentes alternativas que se plantean teniendo en cuenta los objetivos a conseguir y las restricciones impuestas. Frecuentemente, este paso identifica las reas de incertidumbre del proyecto con sus correspondientes riesgos. Para el ejemplo anterior, los riesgos encontrados podran ser que las ganancias en productividad no fueran significativas y que adems dichas mejoras no fueran compatibles con la cultura de la empresa. Si existen riesgos, el siguiente paso conlleva la formulacin de una estrategia efectiva en coste (utilizando prototipos, simulacin, bancos de prueba, cuestionarios para los usuarios, modelizacin analtica o combinaciones de stas y otras tcnicas de resolucin de riesgos) para resolver dichos riesgos. Para el ejemplo, podra recurrirse a la realizacin de informes y anlisis. El tercer paso consiste en revisar los resultados del anlisis de riesgos. As, para el ejemplo que estamos tratando, los resultados podran indicar la posibilidad de conseguir ganancias significativas de productividad a un coste razonable persiguiendo un conjunto integrado de iniciativas en las reas de tecnologa, gestin, personal y soporte.

Figura 2.3. Modelo en espiral de Boehm.

51

ANLISIS Y DISEO DETALLADO DE APLICACIONES...

RA-MA

El cuarto paso consiste en planificar la fase posterior. En el ejemplo prctico, se incluira la necesidad de realizar informes y anlisis ms profundos y, por lo tanto, de contar con ms personal. Una vez realizado el primer ciclo se volvera a empezar. As, por ejemplo, los objetivos de este segundo ciclo podran ser doblar la productividad en tres aos, con la restriccin de que el coste de investigacin fuese de 6000 euros por persona y que la cultura de la compaa no cambiase. El modelo en espiral puede aplicarse en la mayora de las ocasiones. Sin embargo, en algunos casos hay que resolver ciertas dificultades [BOEHM, 1988]: Trabajo con software contratado. El modelo en espiral trabaja bien en los desarrollos internos, pero necesita un ajuste posterior para adaptarlo a la subcontratacin de software. En el desarrollo interno existe una gran flexibilidad y libertad para ajustarse a los acuerdos etapa por etapa, para aplazar acuerdos de opciones especficas, para establecer miniespirales con objeto de resolver caminos crticos, para ajustar niveles de esfuerzo, o para acomodar prcticas como prototipado, desarrollo evolutivo, o uso de mtodos de diseo ajustado al coste. En el desarrollo de software bajo contrato no existe esta flexibilidad y libertad, por lo que es necesario mucho tiempo para definir los contratos, ya que los entregables no estarn previamente definidos de forma clara. Necesidad de expertos en evaluacin de riesgos para identificar y manejar las fuentes de riesgos de un proyecto. Normalmente, un equipo sin experiencia puede producir una especificacin con una gran elaboracin de los elementos de bajo riesgo bien comprendidos, y una pequea y pobre elaboracin de los elementos de alto riesgo. A no ser que se realice una inspeccin por expertos, en este tipo de proyecto se tendr la ilusin de progresar durante un perodo, y, sin embargo, se encuentra dirigido directamente hacia el desastre. Otro aspecto a tener en cuenta es que una especificacin dirigida por riesgos es tambin dependiente del personal. Por ejemplo, un diseo producido por un experto puede ser implantado por inexpertos. Sin embargo, lo contrario es muy difcil llevarlo a cabo.

2.5 MODELO GENRICO PARA DESARROLLO DE SISTEMAS ORIENTADOS A OBJETOSSin entrar en detalles, podemos decir, [PARETS et al., 1991], que los modelos orientados a objetos caracterizan el desarrollo orientado al objeto por: La eliminacin de fronteras entre fases, ya que debido a la naturaleza iterativa del desarrollo orientado al objeto, estas fronteras se difuminan cada vez ms.

52

RA-MA

2 CICLO DE VIDA DEL SOFTWARE

Una nueva forma de concebir los lenguajes de programacin y su uso, ya que se incorporan bibliotecas de clases y otros componentes reutilizables. Un alto grado de iteracin y solapamiento, lo que lleva a una forma de trabajo muy dinmica. En general, todos los expertos en tecnologa de objetos proponen seguir un desarrollo iterativo e incremental. Es iterativo porque las tareas de cada fase se llevan a cabo de forma iterativa, a la vez que existe un ciclo de desarrollo anlisisdiseo-implementacin-anlisis que permite hacer evolucionar al sistema. Por lo que respecta al desarrollo incremental, el sistema se divide en un conjunto de particiones, cada una de las cuales se desarrolla de manera completa, hasta que se finaliza el sistema. Esta idea est aumentando su importancia a medida que existe ms experiencia sobre el desarrollo orientado al objeto. Goldberg afirma que la idea de la integracin incremental es la diferencia clave de cmo debe ser gestionado un proyecto que utiliza tecnologa orientada al objeto [GOLDBERG, 1993]. De esta forma las actividades de validacin, verificacin y aseguramiento de la calidad se pueden realizar, para cada iteracin de cada fase de cada incremento en el desarrollo del sistema, es decir, de forma continuada. Por otro lado cabe destacar, como seala Booch, que en realidad se pueden combinar los modelos tradicionales de ciclo de vida con los ms modernos, reconciliando as la necesidad de creatividad e innovacin con el requisito de prcticas de gestin ms controladas [BOOCH, 1994]. Booch propone distinguir el microproceso del macroproceso. El microproceso puede seguir cualquiera de los ciclos de vida ms modernos, ya que sirve de marco para el desarrollo inte-

RESUMEN DEL CAPTULOEl ciclo de vida software describe las diferentes fases o etapas, procesos y actividades requeridas para ofertar, desarrollar, probar, integrar, explotar y mantener una aplicacin informtica. Existen diferentes modelos de ciclo de vida como son: el modelo en cascada (el ms antiguo, y en el que cada fase empieza cuando se ha terminado la fase anterior), el modelo incremental (en el que se va creando el sistema software aadiendo componentes funcionales al sistema), el modelo en espiral (que consta de una serie de ciclos) y modelos especficos para sistemas orientados a objetos en los que se difuminan las fronteras entre fases y se utiliza un enfoque iterativo e incremental, y se diferencia el macroproceso del microproceso.

53

ANLISIS Y DISEO DETALLADO DE APLICACIONES...

RA-MA

EJERCICIOS PROPUESTOSractivo y es ms informal. Mientras que el macroproceso est ms cercano a un modelo en cascada con el fin de controlar el microproceso de una manera formal. La ventaja principal de estos modelos es que permiten fijar hitos ms frecuentemente, realizando entregas de sistemas que son operativos cada dos o tres meses, para recibir retroalimentacin del cliente lo antes posible e ir adaptando la aplicacin segn cambian las necesidades y se refinan los requisitos. El inconveniente que presentan es la dificultad de gestionar de manera formal los proyectos que siguen estos ciclos de vida aunque, como se ha sealado, este problema se puede paliar diferenciando el micro del macroproceso.

TEST DE CONOCIMIENTOS

1. Qu factores influyen a la hora de elegir un ciclo de vida para resolver un problema dado? Qu ciclo de vida elegira para resolver un problema que se comprende bien desde el principio y est muy estructurado? Una vez elegido el ciclo de vida, qu procesos escogera para dicho ciclo de vida, teniendo en cuenta que el desarrollo informtico para resolver el problema anterior lo realiza una nica persona? 2. Se supone que se va desarrollar una aplicacin relativa a la gestin de pedidos de una empresa. En este caso el cliente no tiene todava muy claro qu es lo que quiere. Adems el personal informtico va a utilizar una tecnologa que le es completamente nueva. Disctase qu tipo de ciclo de vida es ms apropiado y qu procesos se

deberan utilizar para desarrollar esta aplicacin.

1

Sealar la respuesta incorrecta. Entre las funciones principales de un ciclo de vida software se encuentran: a) Determinar el orden de las fases involucradas en el desarrollo del software. b) No realizar documentacin simultneamente al desarrollo. c) Establecer los criterios para iniciar una fase. d) Establecer los criterios para finalizar una fase. Sealar la respuesta correcta. El enfoque de codificar y probar: a) Consiste en realizar actividades de anlisis, diseo, codificacin y pruebas.

2

54

RA-MA

2 CICLO DE VIDA DEL SOFTWARE

b) Realiza actividades dedicadas a la planificacin. c) Avanza muchas veces en sentido equivocado. d) Obtiene aplicaciones muy flexibles, ya que la introduccin de modificaciones no supone un gran problema.

d) El sistema estar disponible en las fases finales del proyecto.

6

3

Sealar la respuesta incorrecta. En el ciclo de vida: a) Se comienza con la idea o necesidad del cliente y finaliza con la entrega de la aplicacin. b) Se comienza con la idea o necesidad del cliente y finaliza cuando se retira la aplicacin. c) Existe un seguimiento del progreso del proyecto. d) Se produce documentacin simultneamente al desarrollo.

Sealar la respuesta incorrecta. En el modelo en cascada: a) Se tarda mucho tiempo en pasar por todo el ciclo. b) El coste de subir la cascada (retroceder en las fases) es muy grande, sobre todo cuando son ms de dos las fases a retroceder. c) Para pasar de una fase a la siguiente es necesario realizar una revisin final. d) Se permite que el cliente vaya viendo prototipos segn se avanza en el desarrollo.

7

4

Sealar la respuesta incorrecta. En el ciclo de desarrollo: a) Se comienza con la idea o necesidad del cliente y finaliza con la entrega de la aplicacin. b) Se comienza con la idea o necesidad del cliente y finaliza cuando se retira la aplicacin. c) Existe un seguimiento del progreso del proyecto. d) Se produce documentacin simultneamente al desarrollo. Sealar la respuesta correcta. En el modelo en cascada: a) Se crean los sistemas software aadiendo componentes funcionales mediante incrementos. b) Se pueden realizar dos fases en paralelo. c) Se hace un hincapi especial en la gestin de los riesgos.

Sealar la respuesta incorrecta. En el modelo incremental: a) Se crean los sistemas software aadiendo componentes funcionales mediante incrementos. b) No se pueden realizar dos incrementos en paralelo. c) Es necesario definir todos los requisitos al principio del proyecto. d) Existe un sistema en funcionamiento al finalizar el primer incremento. Sealar la respuesta incorrecta. El modelo en espiral: a) Necesita de expertos en gestin de riesgos. b) Se basa en el desarrollo de aplicaciones mediante ciclos, donde en cada ciclo se definen requisitos, diseo, cdigo y pruebas. c) Se basa en el desarrollo de aplicaciones mediante ciclos, donde un ciclo corresponde a los requisitos, otro al diseo, otro al cdigo y a las pruebas.

8

5

55

ANLISIS Y DISEO DETALLADO DE APLICACIONES...

RA-MA

BIBLIOGRAFAd) La segunda fase consiste en la evaluacin de alternativas e identificacin y resolucin de riesgos.

9

Sealar cul no es un modelo de ciclo de vida:

a) Cascada. b) Codificar y probar. c) Incremental. d) Espiral. Sealar la respuesta correcta. En el modelo genrico para OO:

10

a) Se recomienda seguir un enfoque en cascada. b) Se recomienza seguir un enfoque en espiral. c) Se recomienda seguir un enfoque incremental. d) Se recomienda seguir un enfoque iterativo e incremental.

BIBLIOGRAFA Amescua Seco, A., Garca Snchez, L., Martnez Fernndez, P. y Daz Prez, P., Ingeniera del Software de Gestin: anlisis y diseo de aplicaciones, Paraninfo, Madrid, 1995. Boehm, B. W., A Spiral Model of Software Development and Enhancement, Computer, pp. 61-72, mayo 1988. Davis, A., Bersoff, E. y Comer, E., A Strategy for Comparing Alternative software development Life Cycle Models, IEEE Transactions on Software Engineering, vol. 14, n 10, pp. 1453-1461, octubre 1988. International Standards Organization / Internacional Electrotechnical Commission, ISO/IEC 12207-1 - Information Technology Software Parte 1: Software life-cycle process (ISO/IEC 12207-1 - Tecnologa de la Informacin Software Parte 1: Proceso del ciclo de vida software), 1994.

56

RA-MA

2 CICLO DE VIDA DEL SOFTWARE

TEST DE CONOCIMIENTOS

57