Vous êtes sur la page 1sur 30

REPBLICA BOLIVARIANA DE VENEZUELA MINISTERIO DEL PODER POPULAR PARA LA EDUCACIN SUPERIOR.

INSTITUTO UNIVERSITARIO DE TECNOLOGA DEL ESTADO BOLVAR IV-INF-IM

FUNDAMENTOS DE LA INGENIERIA DEL SOFTWARE .

Profesora: Joel Poyo

Bachiller: Jimnez Cis C.I. 18961206

Ciudad Bolvar, Junio de 2013

EL SOFTWARE El software no es slo cdigo, sino tambin las especificaciones del diseo, los datos tratados y la documentacin que permite el desarrollo, instalacin y mantenimiento. Estrictamente, se puede definir como: 1) Instrucciones que, cuando se ejecutan, proporcionan la funcionalidad deseada. 2) Estructuras de datos que facilitan a las instrucciones manipular adecuadamente la informacin. 3) Documentos que describen el desarrollo, uso, instalacin y mantenimiento de los programas.

Caractersticas del Software 1. Es un elemento lgico, no fsico, en contraposicin con el hardware. 2. Se desarrolla, no se fabrica. 3. No se estropea, se deteriora, con el tiempo, el hardware se va estropeando por la presencia de componentes fsicos el software, al carecer de ellos, se deteriora

CUALIDADES DEL SOFTWARE


Correcto Confiable Robusto Eficiente Amigable Verificable

Reusable Portable Interoperable Productivo A Tiempo Visible Coheso Desacoplado Comprensible Mantenible

FACTORES DE CALIDAD DEL SOFTWARE

La calidad del software La obtencin de un software con calidad implica la utilizacin de metodologas o procedimientos estndares para

el anlisis,diseo, programacin y prueba del software que permitan uniformar la filosofa de trabajo, en aras de lograr una mayor confiabilidad, mantenibilidad y facilidad de prueba, a la vez que eleven la productividad, tanto para la labor de desarrollo como para el control de la calidad del software. Los requisitos del software son la base de las medidas de calidad. La falta de concordancia con los requisitos es una falta de calidad. Los estndares o metodologas definen un conjunto de criterios de desarrollo que guan la forma en que se aplica la ingeniera del software. Si no se sigue ninguna metodologa siempre habr falta de calidad. Existen algunos requisitos implcitos o expectativas que a menudo no se mencionan, o se mencionan de forma incompleta (por ejemplo el deseo de un buen mantenimiento) que tambin pueden implicar una falta de calidad. La poltica establecida debe estar sustentada sobre tres principios bsicos: tecnolgico, administrativo y ergonmico. El principio tecnolgico define las tcnicas a utilizar en el proceso de desarrollo del software.

El principio administrativo contempla las funciones de planificacin y control del desarrollo del software, as como la organizacin del ambiente o centro de ingeniera de software. El principio ergonmico define la interfaz entre el usuario y el ambiente automatizado. La adopcin de una buena poltica contribuye en gran medida a lograr la calidad del software, pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluacin. A partir del siguiente grfico se observa la interrelacin existente entre la Gestin de la Calidad, el Aseguramiento de la Calidad y el Control de la Calidad.

La gestin de la calidad Gestin de la calidad: "Aspectos de la funcin de gestin que determinan y aplican la poltica de la calidad, los objetivos y las responsabilidades y que lo realiza con medios tales como la planificacin de la calidad, el control de la calidad, la garanta de calidad y la mejora de la calidad". Dentro de la gestin de la calidad se observa:

Gestin de la calidad de software (ISO 9000): Conjunto de actividades de la funcin general de la direccin que determina la calidad, los objetivos y las responsabilidades y se implanta por medios tales como la planificacin de la calidad, el control de la calidad, el aseguramiento (garanta) de la calidad y la mejora de la calidad, en el marco del sistema de calidad

Poltica de calidad (ISO 9000): Directrices y objetivos generales de una organizacin, relativos a la calidad, tal como se expresan formalmente por la alta direccin.

La gestin de la calidad se aplica normalmente a nivel de empresa. Tambin puede haber una gestin de calidad dentro de la gestin de cada proyecto.

El aseguramiento de la calidad Ante todo se debe conocer:

Aseguramiento de la calidad: "Conjunto de acciones planificadas y sistemticas necesarias para proporcionar la confianza adecuada de que un producto o servicio satisfar los requerimientos dados sobre calidad".

Aseguramiento de la calidad de software: Conjunto de actividades planificadas y sistemticas necesarias para aportar la confianza en que el producto (software) satisfar los requisitos dados de calidad.

El aseguramiento de calidad del software se disea para cada aplicacin antes de comenzar a desarrollarla. Hay quienes prefieren decir garanta de calidad en vez de aseguramiento. La garanta, puede confundir con garanta de productos, mientras que el aseguramiento pretende dar confianza en que el producto tiene calidad. El aseguramiento de calidad del software est presente en:

Mtodos y herramientas de anlisis, diseo, programacin y prueba. Inspecciones tcnicas formales en todos los pasos del proceso de desarrollo del software.

Estrategias de prueba multiescala. Control de la documentacin del software y de los cambios realizados. Procedimientos para ajustarse a los estndares (y dejar claro cuando se est fuera de ellos).

Mecanismos de medida (mtricas). Registro de auditorias y realizacin de informes.

Las actividades para el aseguramiento de calidad del software se detallan en:


Mtricas de software para el control del proyecto. Verificacin y validacin del software a lo largo del ciclo de vida (Incluye las pruebas y los procesos de revisin e inspeccin).

La gestin de la configuracin del software.

Algunos mtodos del aseguramiento:

Revisiones tcnicas y de gestin (su objetivo es la evaluacin).

Inspeccin (su objetivo es la verificacin). Estamos construyendo el producto correcto?.

Pruebas (su objetivo es la validacin). Estamos construyendo el producto correctamente?.

Auditorias (su objetivo es la confirmacin del cumplimiento).

El control de la calidad Se debe conocer:

Control

de

calidad: "Conjunto

de

tcnicas

actividades

de carcter operativo, utilizadas para verificar los requerimientos relativos a la calidad del producto o servicio".

Control de la calidad del software: Tcnicas y actividades de carcter operativo, utilizadas para verificar los requisitos relativos a la calidad, centradas en mantener bajo control el proceso de desarrollo y eliminar las causas de los defectos en las diferentes fases del ciclo de vida.

El control de la calidad del software est centrado en dos objetivos fundamentales:


Mantener bajo control un proceso. Eliminar las causas de los defectos en las diferentes fases del ciclo de vida.

En general, se puede decir que el control de de la calidad del software son las actividades para evaluar la calidad de los productos desarrollados. Las estrategias de trabajo se representan como sigue:

INGENIERA DEL SOFTWARE La Ingeniera del Software es una disciplina que integra mtodos, tcnicas y herramientas para el desarrollo de software de computadora.

Ingeniera Es la aplicacin sistemtica de conocimiento cientfico para la creacin y construccin de soluciones rentables a problemas prcticos al servicio de la humanidad. Sus elementos son:

Herramientas: Programas que mecanizan los mtodos y las tcnicas. Mtodos: Conjunto de tareas ordenadas para conseguir un fin. Los mtodos se desarrollaron para cada una de las fases del desarrollo (anlisis, diseo, implementacin, etc.).

Tcnicas: Ayudan con las dificultades para llevar a cabo lo que se indica en los mtodos.

Objetivos de la ingeniera de software


mejorar la calidad de los productos de software aumentar la productividad y trabajo de los ingenieros del software. Facilitar el control del proceso de desarrollo de software. Suministrar a los desarrolladores las bases para construir software de alta calidad en una forma eficiente.

Definir una disciplina que garantice la produccin y el mantenimiento de los productos software desarrollados en el plazo fijado y dentro del costo estimado.

VISIN GENERAL DEL PROCESO DE LA INGENIERA DEL SOFTWARE El ciclo de vida del software se divide en varias fases desde que nace hasta que muere: Planificacin: Se identica el proyecto, se le da nombre y se dene el alcance. Desarrollo: Se desarrolla e implanta. Mantenimiento: Desde que se implanta hasta que se abandona.

Fase de planificacin Se realiza un inventario de todas las actividades que se realizan en una empresa y se agrupan por proyectos estableciendo una correspondencia entre stos y las reas organizativas. Tambin se discute la arquitectura hardware, la topologa de red, el lenguaje de programacin, etc., y se da una prioridad a cada proyecto. Se concluye con un documento denominado Plan de Sistemas de Informacin. Como anotacin, se puede comentar que no se encuentra entre las normas ISO debido a que se realiza una vez cada perodos muy grandes de tiempo (una vez cada dcada o incluso ms).

Fase de desarrollo Se llevan a cabo las tareas hasta tener el proyecto funcionando. Conlleva varias actividades: anlisis, diseo, construccin, pruebas e implantacin.

Fase de mantenimiento Su objetivo es la obtencin de una nueva versin de un sistema debido a peticiones de cambio que los usuarios realizan por un problema detectado, o por la necesidad de una mejora del mismo, para acomodarlo a los cambios de su entorno externo o para conseguir una mayor adecuacin a los requisitos, mayor eciencia, o simplemente recoger nuevas funcionalidades no expresadas en la fase de denicin del sistema. Comprende el mantenimiento:

Correctivo: Cambia el software para corregir los defectos. Evolutivo: Introduce mejoras en el software. Adaptativo: Modica el software para acomodarlo a los cambios de su entorno externo.

Perfectivo: Lleva al software ms all de sus requisitos funcionales originales.

CICLO DE VIDA DEL SOFTWARE Un modelo de ciclo de vida define el estado de las fases a travs de las cuales se mueve un proyecto de desarrollo de software. Fases del ciclo de vida: Fase I - Requerimientos Elaborar una especificacin completa y validada de las funciones requeridas Fase II - Anlisis / Diseo Anlisis: El propsito es conocer exactamente cmo trabaja el sistema actual, determinar y documentar qu debe hacer el sistema y recomendar las posibles soluciones.

Diseo: El propsito de esta fase es desarrollar un diseo (cmo va a quedar) del sistema de informacin que satisfaga todos los requisitos documentados. Se determina qu va a hacer el sistema. Se identifican las entradas (Input), salidas (Output), archivos, programas, procedimientos y controles del sistema. Actividades dentro de la fase de Anlisis/Diseo. Analizar y Disear Proceso: Las operaciones y los requerimientos de funcionamiento definidos en la primera fase, se toman en cuenta con el propsito de determinar la forma en que debe funcionar el sistema. Analizar y Disear Los Datos: Con los requerimientos de informacin definidos en la fase I se debe organizar los distintos modelos de datos que nos ayuden a disear la base de datos que hagan falta para que el sistema funcione de acuerdo al modelo de funcionamiento. Disear y Organizar Los Componentes Fsicos: Todo componente fsico como (pantallas, base de datos) que hagan posible el funcionamiento del sistema de acuerdo al modelo de funcionamiento. Planificar El Desarrollo De Los Componentes Fsicos: actividad en la cual planificamos la forma en que pueden ser construidos e implementados los componentes fsicos de una forma rpida y productiva. En esta fase de anlisis / diseo puede incluirse una sub.-fase de evaluacin de paquetes. Esta se pudiese realizar si en los requerimientos se estableci adquirir un paquete de aplicaciones en lugar de completar un diseo arquitectnico.

Fase III Construccin Dentro de esta fase de construccin existen actividades separadas en cinco sub.fases: Desarrollo de infraestructura Durante esta fase se desarrollar y organizar la infraestructura que permita cumplir las tareas de construccin en la forma ms productiva posible.

Adaptacin de paquete Uno de los objetivos centrales de esta subfase es conocer al mximo detalle posible el funcionamiento del paquete, este asegurar que el paquete ser utilizado con el mximo provecho, tanto desde el punto de vista del negocio, como de la utilizacin de recursos. Cada componente del paquete ser revisado en forma exhaustiva por el equipo Analista Usuario, con el fin de conocer y comprender todos los aspectos del paquete.

Desarrollo de unidades de diseo interactivas Las unidades de diseo interactivas, son procedimientos que se cumple o se ejecutan Las a travs de de esta un subfase dialogo tienen usuario como objetivo sistema. central:

actividades

Especificar en detalle las tareas que debe cumplir la unidad de diseo Desarrollar componentes

Realizar las pruebas unitarias y las pruebas de integra cin a nivel de la unidad de diseo.

Desarrollo de unidades de diseo batch En esta sub.-fase se preparan especificaciones hechas utilizando una

combinacin de tcnicas como flujo gramas, diagramas de estructuras, tablas de decisiones etc. Cualquiera que se utilice ser til para que la especificacin sea clara y se logre el propsito de que el programador comprenda y pueda programar y probar los programas correspondientes. Desarrollo de unidades de diseo manuales Las actividades de esta subfase tienen como objetivo central desarrollar todos los procedimientos administrativos que rodearn y gobernarn la utilizacin de los componentes computarizados desarrollados en la fase de diseo detallado y construccin. Fase IV Pruebas Esta fase, da inicio luego de que las diferentes unidades de diseo han sido desarrolladas y probadas por separado. Durante su desarrollo, el sistema se emplea de forma experimental para asegurar que el software no falle, es decir que funcione deacuerdo a sus especificaciones y a la manera que los usuarios esperan que lo haga, y de esta forma poder detectar cualquier anomala, antes de que el sistema sea puesto en marcha y se dependa de el. Para evaluar el desenvolvimiento del sistema, en esta fase se llevan a cabo varios niveles de prueba: Funcional: Prueba desde el punto de vista de los requerimientos funcionales. De Sistema: Prueba desde el punto de vista de los niveles de calidad del sistema y de desempeo. De Integracin: Prueba de interfaces. De Aceptacin Tcnica: Prueba de manejo de condiciones extremas.

Si el Sistema cumple de forma satisfactoria con estos niveles mencionados anteriormente, se procede a realizar la carga de los archivos, base de datos y tablas del nuevo sistema, para de esta forma dar inicio al proceso de aceptacin final, durante el cual, el sistema comenzar a funcionar bajo la responsabilidad del departamento de operaciones y del usuario, por un lapso determinado de tiempo llamado Periodo de Aceptacin. Finalizado el Periodo de Aceptacin, se le dar al sistema la aprobacin final, para que pase a ser el sistema oficial.

Fase V - Produccin / Mantenimiento Una vez que un sistema pasa a formar parte de la vida diaria de la empresa o institucion, cada programa, cada procedimiento y cada estructura de datos se convierte en una pieza del negocio que, como tal, deber funcionar en forma constante, exacta y confiable. L a operacin del negocio ahora depender del funcionamiento del sistema, por lo que las tareas de mantenimiento cobran vital importancia. Durante la fase de mantenimiento, se ponen en prctica todas las polticas y los procedimientos destinados a garantizar la operacin contina de los de los sistemas y a asegurar su uso efectivo, con el fin, de que stos se constituyan en una verdadera herramienta de apoyo al logro de los objetivos estratgicos de la empresa FUNDAMENTACION TEORICA

Paradigmas de programacin

Existe una infinidad de definiciones de lo que es un paradigma. Un paradigma es un determinado marco desde el cual miramos el mundo, lo comprendemos, lo interpretamos e intervenimos sobre l. Abarca desde el conjunto de conocimientos

cientficos que imperan en una poca determinada hasta las formas de pensar y de sentir de la gente en un determinado lugar y momento histrico. Adam Smith define paradigma, en su libro Los poderes de la mente, como un conjunto compartido de suposiciones. Es la manera como percibimos el mundo: agua para el pez. El paradigma nos explica el mundo y nos ayuda a predecir su comportamiento". En nuestro contexto, el paradigma debe ser concebido como una forma aceptada de resolver un problema en la ciencia, que ms tarde es utilizada como modelo para la investigacin y la formacin de una teora. Tambin, el paradigma debe ser concebido como un conjunto de mtodos, reglas y generalizaciones utilizadas conjuntamente por aquellos entrenados para realizar el trabajo cientfico de investigacin. En nuestro contexto, los paradigmas de programacin nos indican las diversas formas que, a lo largo de la evolucin de los lenguajes, han sido aceptadas como estilos para programar y para resolver los problemas por medio de una computadora. Se muestran a continuacin un resumen de los paradigmas de uso ms extendido en programacin. Programacin por procedimientos Es el paradigma original de programacin y quiz todava el de uso ms comn. En l, el programador se concentra en el procesamiento, en el algoritmo requerido para llevar a cabo el cmputo deseado. Los lenguajes apoyan este paradigma proporcionando recursos para pasar argumentos a las funciones y devolviendo valores de las funciones. FORTRAN es el lenguaje de procedimientos original, Pascal y C son inventos posteriores que

siguen la misma idea. La programacin estructurada se considera como el componente principal de la programacin por procedimientos. Programacin modular Con los aos, en el diseo de programas se dio mayor nfasis al diseo de procedimientos que a la organizacin de la informacin. Entre otras cosas esto refleja un aumento en el tamao de los programas. La programacin modular surge como un remedio a esta situacin. A menudo se aplica el trmino mdulo a un conjunto de procedimientos afines junto con los datos que manipulan. As, el paradigma de la programacin modular consiste en: a) Establecer los mdulos que se requieren para la resolucin de un problema. b) Dividir el programa de modo que los procedimientos y los datos queden ocultos en mdulos. Este paradigma tambin se conoce como principio de ocultacin de

procedimientos y datos. Aunque C++ no se diseo especficamente para desarrollar la programacin modular, su concepto de clase proporciona apoyo para el concepto de mdulo. Abstraccin de datos Los lenguajes como ADA y C++ permiten que un usuario defina tipos que se comporten casi de la misma manera que los tipos definidos por el lenguaje. Tales tipos de datos reciben a menudo el nombre de tipos abstractos o tipos definidos por el usuario. El paradigma de programacin sobre este tipo de datos consiste en: a) Establecer las caractersticas de los tipos de datos abstractos se desean definir.

b) Proporcionar un conjunto completo de operaciones vlidas y tiles para cada tipo de dato. Metodologas para desarrollo de software

Un proceso de software detallado y completo suele denominarse Metodologa. Las metodologas se basan en una combinacin de los modelos de proceso genricos (cascada, evolutivo, incremental, etc.). Adicionalmente una metodologa debera definir con precisin los artefactos, roles y actividades involucrados, junto con prcticas y tcnicas recomendadas, guas de adaptacin de la metodologa al proyecto, guas para uso de herramientas de apoyo, etc. Habitualmente se utiliza el trmino mtodo para referirse a tcnicas, notaciones y guas asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de mtodos de anlisis y/o diseo. La comparacin y/o clasificacin de metodologas no es una tarea sencilla debido a la diversidad de propuestas y diferencias en el grado de detalle, informacin disponible y alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notaciones utilizadas para especificar artefactos producidos en actividades de anlisis y diseo, podemos clasificar las metodologas en dos grupos: Metodologas Estructuradas y Metodologas Orientadas a Objetos. Por otra parte, considerando su filosofa de desarrollo, aquellas metodologas con mayor nfasis en la planificacin y control del proyecto, en especificacin precisa de requisitos y modelado, reciben el apelativo de Metodologas Tradicionales (o peyorativamente denominada Metodologas Pesadas, o Peso Pesado). Otras metodologas, denominadas Metodologas giles, estn ms orientadas a la generacin de cdigo con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeos, hacen especial hincapi en aspectos humanos asociados al trabajo en equipo e involucran activamente al cliente en el proceso. A continuacin se revisan brevemente cada una de estas categoras de metodologas.

Metodologas estructuradas Los mtodos estructurados comenzaron a desarrollarse a fines de los 70s con la Programacin Estructurada, luego a mediados de los 70s aparecieron tcnicas para el Diseo (por ejemplo: el diagrama de Estructura) primero y posteriormente para el Anlisis (por ejemplo: Diagramas de Flujo de Datos). Estas metodologas son particularmente apropiadas en proyectos que utilizan para la implementacin lenguajes de 3ra y 4ta generacin. Ejemplos de metodologas estructuradas de mbito gubernamental: MERISE (Francia), MTRICA (Espaa), SSADM (Reino Unido). Ejemplos de propuestas

de mtodos estructurados en el mbito acadmico: Gane & Sarson , Ward & Mellor , Yourdon & DeMarco e Information Engineering . Metodologas orientadas a objetos Su historia va unida a la evolucin de los lenguajes de programacin orientada a objeto, los ms representativos: a fines de los 60s SIMULA, a fines de los 70s Smalltalk-80, la primera versin de C++ por Bjarne Stroustrup en 1981 y actualmente Java o C# de Microsoft. A fines de los 80s comenzaron a

consolidarse algunos mtodos Orientadas a Objeto. En 1995 Booch y Rumbaugh proponen el Mtodo Unificado con la ambiciosa idea de conseguir una unificacin de sus mtodos y notaciones, que posteriormente se reorienta a un objetivo ms modesto, para dar lugar al Unified Modeling Language (UML) , la notacin OO ms popular en la actualidad. Algunos mtodos OO con notaciones predecesoras de UML son: OOAD (Booch), OOSE (Jacobson), Coad & Yourdon, Shaler & Mellor y OMT (Rumbaugh). Algunas metodologas orientadas a objetos que utilizan la notacin UML son: Rational Unified Process (RUP) , OPEN , MTRICA (que tambin soporta la notacin estructurada).

Metodologas tradicionales (no giles) Las metodologas no giles son aquellas que estn guiadas por una fuerte planificacin durante todo el proceso de desarrollo; llamadas tambin

metodologas tradicionales o clsicas, donde se realiza una intensa etapa de anlisis y diseo antes de la construccin del sistema. Todas las propuestas metodolgicas antes indicadas pueden considerarse como metodologas tradicionales. Aunque en el caso particular de RUP, por el especial nfasis que presenta en cuanto a su adaptacin a las condiciones del proyecto (mediante su configuracin previa a aplicarse), realizando una configuracin adecuada, podra considerarse gil. Metodologas giles Un proceso es gil cuando el desarrollo de software es incremental (entregas pequeas de software, con ciclos rpidos), cooperativo (cliente y desarrolladores trabajan juntos constantemente con una cercana comunicacin), sencillo (el mtodo en s mismo es fcil de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de ltimo momento) Entre las metodologas giles identificadas en : Extreme Programming Scrum Familia de Metodologas Crystal Feature Driven Development Proceso Unificado Rational, una configuracin gil Dynamic Systems Development Method

Modelos de proceso software

Sommerville define modelo de proceso de software como Una representacin simplificada de un proceso de software, representada desde una perspectiva especfica. Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstraccin de un proceso real. Los modelos genricos no son descripciones definitivas de procesos de software; sin embargo, son abstracciones tiles que pueden ser utilizadas para explicar diferentes enfoques del desarrollo de software. Modelos que se van a discutir a continuacin:

Codificar y corregir Modelo en cascada Desarrollo evolutivo Desarrollo formal de sistemas Desarrollo basado en reutilizacin Desarrollo incremental Desarrollo en espiral

Codificar y corregir (Code-and-Fix) Este es el modelo bsico utilizado en los inicios del desarrollo de software. Contiene dos pasos:

Escribir cdigo. Corregir problemas en el cdigo.

Se trata de primero implementar algo de cdigo y luego pensar acerca de requisitos, diseo, validacin, y mantenimiento. Este modelo tiene tres problemas principales:

Despus de un nmero de correcciones, el cdigo puede tener una muy mala estructura, hace que los arreglos sean muy costosos.

Frecuentemente, an el software bien diseado, no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstruccin es muy cara.

El cdigo es difcil de reparar por su pobre preparacin para probar y modificar.

Modelo en cascada El primer modelo de desarrollo de software que se public se deriv de otros procesos de ingeniera [8]. ste toma las actividades fundamentales del proceso de especificacin, desarrollo, validacin y evolucin y las representa como fases separadas del proceso. El modelo en cascada consta de las siguientes fases: 1. Definicin de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios del sistema. Se busca hacer esta definicin en detalle. 2. Diseo de software: Se particiona el sistema en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los componentes del sistema. 3. Implementacin y pruebas unitarias: Construccin de los mdulos y unidades de software. Se realizan pruebas de cada unidad.

4. Integracin y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente. 5. Operacin y mantenimiento: Generalmente es la fase ms larga. El sistema es puesto en marcha y se realiza la correccin de errores descubiertos. Se realizan mejoras de implementacin. Se identifican nuevos requisitos. La interaccin entre fases puede observarse en la Figura 5. Cada fase tiene como resultado documentos que deben ser aprobados por el usuario. Una fase no comienza hasta que termine la fase anterior y generalmente se

incluye la correccin de los problemas encontrados en fases previas.

En la prctica, este modelo no es lineal, e involucra varias iteraciones e interaccin entre las distintas fases de desarrollo. Algunos problemas que se observan en el modelo de cascada son:

Las iteraciones son costosas e implican rehacer trabajo debido a la produccin y aprobacin de documentos.

Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con las siguientes fases.

Los problemas se dejan para su posterior resolucin, lo que lleva a que estos sean ignorados o corregidos de una forma poco elegante.

Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario por el largo tiempo de entrega del producto.

Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difcil responder a cambios en los requisitos.

Este modelo slo debe usarse si se entienden a plenitud los requisitos. An se utiliza como parte de proyectos grandes. Desarrollo evolutivo La idea detrs de este modelo es el desarrollo de una implantacin del sistema inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado. En la Figura 6 se observa cmo las actividades concurrentes: especificacin, desarrollo y validacin, se realizan durante el desarrollo de las versiones hasta llegar al producto final. Una ventaja de este modelo es que se obtiene una rpida realimentacin del usuario, ya que las actividades de especificacin, desarrollo y pruebas se ejecutan en cada iteracin.

Existen dos tipos de desarrollo evolutivo:

Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene ms claras. El sistema evoluciona conforme se aaden nuevas caractersticas propuestas por el usuario.

Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos que no estn claros para el usuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a terminar de definir estos requisitos.

Entre los puntos favorables de este modelo estn:

La especificacin puede desarrollarse de forma creciente. Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad del software.

Es ms efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.

Desde una perspectiva de ingeniera y administracin se identifican los siguientes problemas:

Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita desarrollar rpido, no es efectivo producir documentos que reflejen cada versin del sistema.

Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento.

Se requieren tcnicas y herramientas: Para el rpido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.

Este modelo es efectivo en proyectos pequeos (menos de 100.000 lneas de cdigo) o medianos (hasta 500.000 lneas de cdigo) con poco tiempo para su desarrollo y sin generar documentacin para cada versin. Para proyectos largos es mejor combinar lo mejor del modelo de cascada y evolutivo: se puede hacer un prototipo global del sistema y posteriormente reimplementarlo con un acercamiento ms estructurado. Los subsistemas con requisitos bien definidos y estables se pueden programar utilizando cascada y la interfaz de usuario se puede especificar utilizando un enfoque exploratorio. Desarrollo formal de sistemas Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un programa ejecutable.
Desiciones Especificacin Informal Especificacin Especificacin de alto nivel (prototipo) Tranformacin Interactiva Especificacin de bajo nivel Transformacin Automtica Desarrollo Formal

Cdigo Fuente

Optimizacin Validacin de Especificacin

Mantenimiento

La Figura 7 (obtenida desde [20]) ilustra un paradigma ideal de programacin automtica. Se distinguen dos fases globales: especificacin (incluyendo validacin) y transformacin. Las caractersticas principales de este paradigma son: la especificacin es formal y ejecutable constituye el primer prototipo del sistema), la especificacin es validada mediante prototipacin. Posteriormente, a travs de transformaciones formales la especificacin se convierte en la implementacin del sistema, en el ltimo paso de transformacin se obtiene una implementacin en un lenguaje de programacin determinado. , el mantenimiento

se realiza sobre la especificacin (no sobre el cdigo fuente), la documentacin es generada automticamente y el mantenimiento es realizado por repeticin del proceso (no mediante parches sobre la implementacin). Observaciones sobre el desarrollo formal de sistemas:

Permite demostrar la correccin del sistema durante el proceso de transformacin. As, las pruebas que verifican la correspondencia con la especificacin no son necesarias.

Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad importantes.

Requiere desarrolladores especializados y experimentados en este proceso para llevarse a cabo.

Desarrollo basado en reutilizacin Como su nombre lo indica, es un modelo fuertemente orientado a la reutilizacin. Este modelo consta de 4 fases ilustradas en la Figura 9. A continuacin se describe cada fase: 1. Anlisis de componentes: Se determina qu componentes pueden ser utilizados para el sistema en cuestin. Casi siempre hay que hacer ajustes para adecuarlos. 2. Modificacin de requisitos: Se adaptan (en lo posible) los requisitos para concordar con los componentes de la etapa anterior. Si no se puede realizar modificaciones en los requisitos, hay que seguir buscando componentes ms adecuados (fase 1). 3. Diseo del sistema con reutilizacin: Se disea o reutiliza el marco de trabajo para el sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para disear o determinar este marco.

4. Desarrollo e integracin: El software que no puede comprarse, se desarrolla. Se integran los componentes y subsistemas. La integracin es parte del desarrollo en lugar de una actividad separada. Las ventajas de este modelo son:

Disminuye el costo y esfuerzo de desarrollo. Reduce el tiempo de entrega. Disminuye los riesgos durante el desarrollo.

Desventajas de este modelo:

Los compromisos en los requisitos son inevitables, por lo cual puede que el software no cumpla las expectativas del cliente.

Las actualizaciones de los componentes adquiridos no estn en manos de los desarrolladores del sistema.

Procesos iterativos A continuacin se expondrn dos enfoques hbridos, especialmente diseados para el soporte de las iteraciones:

Desarrollo Incremental. Desarrollo en Espiral.

Desarrollo incremental Mills [9] sugiri el enfoque incremental de desarrollo como una forma de reducir la repeticin del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema (ver Figura 10). Es una combinacin del Modelo de Cascada y Modelo Evolutivo. Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones hasta tener experiencia en el sistema. Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo.

Entre las ventajas del modelo incremental se encuentran:

Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo desde el primer incremento.

Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas del sistema.

Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento.

Las partes ms importantes del sistema son entregadas primero, por lo cual se realizan ms pruebas en estos mdulos y se disminuye el riesgo de fallos.

Algunas de las desventajas identificadas para este modelo son:

Cada incremento debe ser pequeo para limitar el riesgo (menos de 20.000 lneas).

Cada incremento debe aumentar la funcionalidad. Es difcil establecer las correspondencias de incrementos. los requisitos contra los

Es difcil detectar las unidades o servicios genricos para todo el sistema.

Desarrollo en espiral El modelo de desarrollo en espiral (ver Figura 11) es actualmente uno de los ms conocidos y fue propuesto por Boehm [7]. El ciclo de desarrollo se representa como una espiral, en lugar de una serie de actividades sucesivas con retrospectiva de una actividad a otra. Cada ciclo de desarrollo se divide en cuatro fases: 1. Definicin de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y del producto. Se realiza un diseo detallado del plan administrativo. Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de estos. 2. Evaluacin y reduccin de riesgos: Se realiza un anlisis detallado de cada riesgo identificado. Pueden desarrollarse prototipos para disminuir el riesgo de requisitos dudosos. Se llevan a cabo los pasos para reducir los riesgos.

3. Desarrollo y validacin: Se escoge el modelo de desarrollo despus de la evaluacin del riesgo. El modelo que se utilizar (cascada, sistemas formales, evolutivo, etc.) depende del riesgo identificado para esa fase. 4. Planificacin: Se determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto. Este modelo a diferencia de los otros toma en consideracin explcitamente el riesgo, esta es una actividad importante en la administracin del proyecto. El ciclo de vida inicia con la definicin de los objetivos. De acuerdo a las restricciones se determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra las alternativas. Se evalan los riesgos con actividades como anlisis detallado, simulacin, prototipos, etc. Se desarrolla un poco el sistema. Se planifica la siguiente fase.

REFERENCIAS Pressman, R, Ingeniera del Software: Un enfoque prctico, McGraw Hill 1997. Naur P., Randell B., Software Engineering: A Report on a Conference Sponsored by the NATO Scienc, 1969. Jacaboson, I., Booch, G., Rumbaugh J., El Proceso Unificado de Desarrollo de Software, Addison Wesley 2000. Sommerville, I., Ingeniera de Software, Pearson Educacin, 2002. Letelier, P., Proyecto Docente e Investigador, DSIC, 2003. Beck, K., Una explicacin de la Programacin Extrema. Aceptar el cambio, Pearson Educacin, 2000. Boehm, B. W., A Spiral Model of Software Develpment and Enhancement, IEEE Computer ,1988. Royce, W., Managing the developmento of large software systems: concepts and technique, IEEE Westcon, 1970. Mills, H., ONeill, D., The Management of Software Engineering, IBM Systems, 1980. Laboratorio Ing. Soft., Ingeniera de software 2, Departamento de Informtica, 2002. Abrahamsson, P., Salo, O., Ronkainen, J., Agile Software Development Methods. Review and Analysis, VTT, 2002. Schwaber, K., Scrum Development Process. Workshop on Business Object Design and Implementation, OOPSLA95, 1995.