INGENIERIA DE SOFTWAREUnidad II. Metodologas de desarrollo

El desarrollo de un producto software de cierta complejidad es un desafo intelectual tanto para la organizacin en la que se desarrolla como para cada una de las personas que intervienen. Estos dos factores, humano y organizativo, se relacionan durante el proceso de gestacin del producto.La ingeniera de software se preocupa principalmente del proceso de desarrollo que implica a un equipo numeroso de personas en el desarrollo de sistemas de software complejos. En estos casos, cada ingeniero de software forma parte de un equipo de trabajo y desarrolla su actividad en relacin con los componentes del mismo.En funcin de las actividades y de los conocimientos necesarios para realizarlas, cada integrante del equipo de trabajo posee un perfil tcnico especializado. Los perfiles necesarios, aunque no totalmente disjuntos, permiten establecer una primera divisin del trabajo durante el proceso de desarrollo.Los individuos que forman parte del desarrollo de un sistema deben conocer sus obligaciones a nivel individual, poseer los conocimientos requeridos para ello e incluso deben realizar adecuadamente las actividades encomendadas, pero es necesario establecer una clara dependencia y control de las actividades de desarrollo, conseguir una eficaz gestin de los recursos implicados y, finalmente, asegurar un nivel de calidad adecuado a lo largo de todo el proceso.Un conjunto de actividades, orientadas a un fin concreto, empleando y generando determinada informacin relativa al sistema en desarrollo se denomina proceso. Como ejemplo, un proceso sera la obtencin de una nueva versin de un sistema; otro, la prueba de mdulos ya implementados; otro ms, la animacin de un modelo del sistema de software durante las primeras fases.Para cada uno de los procesos se requiere fijar unas actividades, responsables, entradas y salidas, planificacin temporal y de recursos necesarios, y mecanismos para asegurar que se realiza correctamente.Los modelos prescriptivos de proceso definen un conjunto de actividades, acciones, tareas, fundamentos y productos de trabajo que se requieren para producir software de alta calidad. No son perfectos, pero son una gua para el trabajo de los ingenieros de software.El modelo de proceso de software es importante porque proporciona estabilidad, control y organizacin al desarrollo del software.La aplicacin de estos modelos produce como resultado programas, documentos y datos como consecuencia de las actividades y tareas que definen el proceso.

2.1 Metodologas clsicas A partir de los aos setenta, se haba acumulado suficiente experiencia sobre el desarrollo de productos software para poder identificar un conjunto de actividades comunes a todos los proyectos. Asimismo, la estructura organizativa requerida para controlar su ejecucin y la forma en la que el control de calidad aseguraba la validez de un determinado producto eran suficientemente conocidas como para definir marcos de referencia utilizables en nuevos proyectos de desarrollo. Esta idea desemboc en el concepto de modelo de ciclo de vida de un producto software.Por ciclo de vida de un producto software se entiende la secuencia de fases, actividades en cada una de ellas, controles para pasar de una fase a otra y resultados generados en cada una de ellas que permiten el desarrollo de un producto desde su concepcin, entrega al usuario, y evolucin posterior, hasta su retirada del mercado. Cualquier organizacin debe definir un conjunto nico de actividades dentro del marco de trabajo para el o los procesos de software que adopte. Tambin debe llenar cada actividad del marco de trabajo con un conjunto de tareas que identifique el trabajo y los productos del trabajo que deben completarse para alcanzar las metas de desarrollo. Despus la organizacin debe adaptar el modelo de proceso resultante y ajustarlo a la naturaleza especfica de cada proyecto, a las personas que lo realizarn, y el ambiente en el que se ejecutar el trabajo. Sin importar el modelo del proceso seleccionado, los ingenieros de software han elegido de manera tradicional un marco de trabajo genrico para el proceso, el cual incluye las siguientes actividades dentro del marco: comunicacin, planeacin, modelado, construccin y despliegue.

2.1.1 Cascada Es el paradigma ms antiguo de la ingeniera de software, tambin llamado modelo del ciclo de vida clsico, donde se sugiere un enfoque sistemtico, secuencial hacia el desarrollo de software, que se inicia con la especificacin de los requerimientos del cliente y que contina con la planeacin, el modelado, la construccin y el despliegue para culminar con el soporte del software terminado.Anlisis de los requisitos del software. El proceso de reunin de requisitos se intensifica y se centra especialmente en el software. Para comprender la naturaleza del (los) programa(s) a construirse, el ingeniero (analista) del software debe comprender el dominio de informacin del software, as como la funcin requerida, comportamiento, rendimiento e interconexin.El objetivo de la fase de definicin de requisitos (tambin se le suele denominar de especificacin de requisitos) es obtener una clara comprensin del problema a resolver, extraer las necesidades del usuario y derivar de ellas las funciones que debe realizar el sistema.Esta fase suele subdividirse en dos subfases: anlisis de requisitos de usuario y anlisis de requisitos de sistema.La subfase de anlisis de requisitos de usuario tiene como objetivo conocer las necesidades de los usuarios y cules deben ser los servicios que un sistema de software debe ofrecerles para satisfacerlas. La fase implica la creacin del Documento de Requisitos de Usuario (DRU) que constituye el documento base para que, al final del desarrollo, el sistema sea aceptado por el usuario.La subfase de anlisis de requisitos del sistema consiste en la construccin de un modelo lgico del sistema de software describiendo las funciones que sean necesarias (sin tomar ninguna decisin sobre cmo implementarlas) y las relaciones entre ellas suponiendo que no existen limitaciones de recursos.Por modelo lgico se entiende la identificacin de las funciones de software requeridas para satisfacer los requisitos del usuario. Esta identificacin se suele realizar en varios niveles de detalle hasta llegar a uno en el que las funciones identificadas estn suficientemente claras de tal forma que no exija un refinamiento posterior.El producto generado en esta fase es el Documento de Requisitos de Software (DRS). Tambin se genera en esta sub-fase el plan de gestin del desarrollo con estimaciones de costos y recursos ms ajustados que en la sub-fase anterior.Es importante distinguir en esta subfase entre requisitos funcionales (aquellos ligados a la relacin entre datos de entrada y resultados (datos de salida) que debe presentar el sistema, incluidos los derivados de restricciones temporales cuando stas estn cuantificadas) y requisitos no funcionales (que incluyen todos los aspectos de calidad del sistema: por ejemplo, mantenibilidad (facilidad para que el sistema evolucione y se modifique una vez entregado al usuario), escalabilidad (posibilidad de incrementar sustancialmente el nmero de usuarios u otros parmetros), facilidad de uso, etc., que no pueden ligarse a funciones concretas dentro del sistema.Diseo. El diseo del software es realmente un proceso de muchos pasos que se centra en cuatro atributos distintos de programa: estructura de datos, arquitectura de software, representaciones de interfaz y detalle procedimental (algoritmo). El proceso del diseo traduce requisitos en una representacin del software donde se pueda evaluar su calidad antes de que comience la codificacin.La fase de diseo tiene como objetivo determinar una solucin a los requisitos del sistema definidos en la fase anterior. Obviamente, existen muchas maneras de satisfacer los requisitos y, por tanto, multitud de diseos posibles.Es conveniente distinguir entre diseo de alto nivel o arquitectnico y diseo detallado. El primero de ellos tiene como objetivo definir la estructura de la solucin (una vez que la fase de anlisis ha descrito el problema) identificando grandes mdulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define la arquitectura de la solucin elegida. El segundo define los algoritmos empleados y la organizacin del cdigo para comenzar la implementacin, documento resultante: Documento de Diseo Detallado (DDD).En la subfase de diseo arquitectnico se parte del modelo lgico generado en la fase de definicin de requisitos software y se transforma en una arquitectura agrupando las funciones identificadas en componentes software. Asimismo, se define la activacin y desactivacin de cada uno de los componentes y el intercambio de informacin entre ellos. El resultado de esta fase es el Documento de Diseo Arquitectnico (DDA).El proceso de diseo detallado suele requerir diversos pasos de refinamiento en los que mltiples decisiones de diseo permiten incorporar restricciones de implementacin derivadas del uso de recursos limitados: la ejecucin de las funciones identificadas requiere tiempo y espacio de memoria o bfferes as como recursos de CPU que no son ilimitados.El refinamiento culmina cuando la descomposicin modular ha alcanzado el nivel suficiente como para poder comenzar la implementacin del sistema en un lenguaje ejecutable con las prestaciones adecuadas en mdulos de complejidad abordable por una persona (o un pequeo grupo). En esta subfase podemos conocer los recursos software requeridos para ello y hacer una estimacin (conocida la tecnologa de software a utilizar).

Generacin de cdigo. El diseo se debe traducir en una forma legible por la mquina. El paso de generacin de cdigo lleva a cabo esta tarea. Si se lleva a cabo el diseo de una forma detallada, la generacin de cdigo se realiza mecnicamente.Es interesante mencionar que todas las fases anteriores son conceptualmente independientes del lenguaje de programacin seleccionado. Es en esta fase cundo se selecciona y utiliza un lenguaje de programacin determinado.Pruebas. Una vez que se ha generado el cdigo, comienzan las pruebas del programa. El proceso de pruebas se centra en los procesos lgicos internos del software, asegurando que todas las sentencias se han comprobado, y en los procesos externos funcionales; es decir, realizar las pruebas para la deteccin de errores y asegurar que la entrada definida produce resultados reales de acuerdo con los resultados requeridos.Mantenimiento. El software indudablemente sufrir cambios despus de ser entregado al cliente (una excepcin posible es el software empotrado). Se producirn cambios porque se han encontrado errores, porque el software debe adaptarse para acoplarse a los cambios de su entorno externo (por ejemplo: se requiere un cambio debido a un sistema operativo o dispositivo perifrico nuevo), o porque el cliente requiere mejoras funcionales o de rendimiento. El soporte y mantenimiento del software vuelve a aplicar cada una de las fases precedentes a un programa ya existente y no a uno nuevo.Una vez que el producto de software ha entrado en operacin regular por el usuario no es de ningn modo un sistema inmutable. Todo producto software complejo debe adaptarse a un entorno que va cambiando (nuevas necesidades del cliente, evolucin de la plataforma de ejecucin hardware o software, etc). Un producto software que no evoluciona va hacindose cada vez menos til en ese entorno.

Se suele hablar de tres tipos diferentes de mantenimiento:1) Mantenimiento correctivo. Pretende eliminar problemas surgidos durante la fase de operacin del sistema y que no han sido detectados anteriormente.2) Mantenimiento perfectivo. Pretende mejorar la funcionalidad del sistema ya sea en relacin con la eficiencia en ejecucin del mismo (menor tiempo de respuesta, optimizacin del uso de la memoria, etc.), facilitar su uso, etc.3) Mantenimiento evolutivo. Pretende modificar (ampliar, eliminar o sustituir) la funcionalidad del sistema para adaptarla a las nuevas necesidades del usuario o con el objetivo de adaptarlo a nuevas interfaces hardware o software.Ventajas del modelo en cascada:a) Fases conocidas por todos los desarrolladores y ligadas a los perfiles tcnicos clsicamente establecidos. Existe gran experiencia documentada sobre el uso del modelo que coincide con la formacin tpica del ingeniero de software.b) Es el ms eficiente cuando el sistema es conocido y los requisitos estables ya que se puede avanzar rpidamente hacia la fase de diseo arquitectnico sin que exista el peligro de una contina interaccin entre las primeras fases.c) Permite una gestin del proceso de desarrollo basada en revisiones de los documentos generados en cada fase facilitando la ejecucin de los procedimientos de gestin.Algunos problemas que nos podemos encontrar al aplicar este modelo son:1. Es muy raro que los proyectos reales sigan el flujo secuencial que propone el modelo. A pesar de que el modelo lineal incluye iteraciones, lo hace de manera indirecta. Como resultado, los cambios confunden mientras el equipo de proyecto acta.2. Con frecuencia es difcil para el cliente establecer todos los requisitos de manera explcita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporar la incertidumbre natural presente en el inicio de muchos proyectos.3. El cliente debe tener paciencia. Una versin de funciones de los programas estar disponible cuando el proyecto est muy avanzado. Un grave error ser desastroso si no se detecta antes de la revisin del programa.Este modelo conduce a estados de bloqueo, lo que quiere decir que algunos miembros del equipo deben esperar a otros para terminar tareas dependientes. El estado de bloqueo tiende a ser ms comn al principio y al final del proceso secuencial.En la actualidad el trabajo del software est acelerado y sujeto a una cadena infinita de cambios (caractersticas, funciones y contenido de la informacin). Con frecuencia el modelo en cascada no es apropiado para dicho trabajo. Sin embargo, puede servir como un modelo de proceso til en situaciones donde los requerimientos estn fijos y donde el trabajo que se realiza hasta su conclusin, de una manera lineal.

2.1.2 Incremental En muchas situaciones los requisitos iniciales del software estn bien definidos en forma razonable, pero el enfoque global del esfuerzo de desarrollo excluye un proceso puramente lineal. Adems, quiz haya una necesidad imperiosa de proporcionar de manera rpida un conjunto limitado de funcionalidad para el usuario y despus refinarla y expandirla en las entregas posteriores del software. En estos casos se elige un modelo de proceso diseado para producir el software en forma incremental.El modelo incremental combina elementos del modelo en cascada aplicado en forma iterativa. Como se muestra en la siguiente figura:

El modelo incremental aplica secuencias lineales de manera escalonada conforme avanza el tiempo.Cada secuencia lineal produce incrementos del software. Por ejemplo, el software procesador de texto desarrollado con el paradigma incremental en su primer incremento, podra realizar funciones bsicas de administracin de archivos, edicin y produccin de documentos, en el segundo incremento, ediciones ms sofisticadas, y tendra funciones ms complejas de produccin de documentos; en el tercer incremento, funciones de correccin ortogrfica y gramatical; y en el cuarto capacidades avanzadas de configuracin pgina. Se debe tener en cuenta que el flujo de proceso de cualquier incremento puede incorporar el paradigma de construccin de prototipos.A menudo, al utilizar un modelo incremental el primer incremento es un producto esencial. Es decir, se incorporan los requisitos bsicos pero muchas caractersticas suplementarias (algunas conocidas, otras no) no se incorporan. El producto esencial queda en manos del cliente (o se somete a una evaluacin detallada). Como resultado de la evaluacin se desarroll un plan para el incremento siguiente. El plan afronta la modificacin del producto esencial con el fin de satisfacer de mejor manera las necesidades del cliente y la entrega de caractersticas y funcionalidades adicionales. Este proceso se repite despus de la entrega de cada incremento mientras no se haya elaborado el producto completo.El modelo de proceso incremental, al igual que la construccin de prototipos y otros enfoque evolutivos es iterativo por naturaleza.Pero a diferencia de la construccin de prototipos, se enfoca en la entrega del producto operacional con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que se necesita y una plataforma para su evaluacin.Este modelo es til sobre todo cuando el personal necesario para una implementacin completa no est disponible. Los primeros incrementos se pueden implementar con menos gente. Si el producto esencial es bien recibido se agrega (si se requiere) ms personal para implementar el incremento siguiente. Adems, los incrementos se pueden planear para manejar los riesgos tcnicos. Por ejemplo, un sistema grande podra requerir la disponibilidad de un hardware nuevo que est en desarrollo y cuya fecha de entrega es incierta. Sera posible planear los primeros incrementos de forma que se evite el uso de este hardware, lo que permitira la entrega de funcionalidad parcial a los usuarios finales sin retrasos desordenados.Este proceso de desarrollo incremental tiene varias ventajas:1. Los clientes no tienen que esperar hasta que el sistema completo se entregue para sacar provecho de l. El primer incremento satisface los requerimientos ms crticos de tal forma que pueden utilizar el software inmediatamente.2. Los clientes pueden utilizar los incrementos iniciales como prototipos y obtener experiencia sobre los requerimientos de los incrementos posteriores del sistema.3. Existe un bajo riesgo de un fallo total del proyecto. Aunque se pueden encontrar problemas en algunos incrementos, lo normal es que el sistema se entregue de forma satisfactoria al cliente.4. Puesto que los servicios de ms alta prioridad se entregan primero, y los incrementos posteriores se integran en ellos, es inevitable que los servicios ms importantes del sistema sean a los que se les hagan ms pruebas. Esto significa que es menos probable que los clientes encuentren fallos de funcionamiento del software en las partes ms importantes del sistema.Sin embargo, existen algunos problemas en el desarrollo incremental. Los incrementos deben ser relativamente pequeos (no ms de 20.000 lneas de cdigo) y cada uno debe entregar alguna funcionalidad del sistema. Puede ser difcil adaptar los requerimientos del cliente a incrementos de tamao apropiado. Ms an, muchos de los sistemas requieren un conjunto de recursos que se utilizan en diferentes partes del sistema. Puesto que los requerimientos no se definen en detalle hasta que un incremento se implementa, puede ser difcil identificar los recursos comunes que requieren todos los incrementos.2.1.3 Evolutivo El desarrollo evolutivo se basa en la idea de desarrollar una implementacin inicial, exponindola a los comentarios del usuario y refinndola a travs de las diferentes versiones hasta que se desarrolla un sistema adecuado.

Las actividades de especificacin, desarrollo y validacin se entrelazan en vez de separarse, con una rpida retroalimentacin entre stas.Existen dos tipos de desarrollo evolutivo:1. Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente.2. Prototipos desechables, donde el objetivo del proceso de desarrollo evolutivo es comprender los requerimientos del cliente y entonces desarrollar una definicin mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden del todo.En la produccin de sistemas, un enfoque evolutivo para el desarrollo de software suele ser ms efectivo que el enfoque en cascada, ya que satisface las necesidades inmediatas de los clientes. La ventaja de un proceso del software que se basa en un enfoque evolutivo es que la especificacin se puede desarrollar de forma creciente. Tan pronto como los usuarios desarrollen un mejor entendimiento de su problema, ste se puede reflejar en el sistema software.Sin embargo, desde una perspectiva de ingeniera y de gestin, el enfoque evolutivo tiene dos problemas:1. El proceso no es visible. Los administradores tienen que hacer entregas regulares para medir el progreso. Si los sistemas se desarrollan rpidamente, no es rentable producir documentos que reflejen cada versin del sistema.2. A menudo los sistemas tienen una estructura deficiente. Los cambios continuos tienden a corromper la estructura del software. Incorporar cambios en l se convierte cada vez ms en una tarea difcil y costosa.Para sistemas pequeos y de tamao medio (hasta 500.000 lneas de cdigo), el enfoque evolutivo de desarrollo es el mejor. Los problemas del desarrollo evolutivo se hacen particularmente agudos para sistemas grandes y complejos con un periodo de vida largo, donde diferentes equipos desarrollan distintas partes del sistema. Es difcil establecer una arquitectura del sistema estable usando este enfoque, el cual hace difcil integrar las contribuciones de los equipos.Para sistemas grandes, se recomienda un proceso mixto que incorpore las mejores caractersticas del modelo en cascada y del desarrollo evolutivo. Esto puede implicar desarrollar un prototipo desechable utilizando un enfoque evolutivo para resolver incertidumbres en la especificacin del sistema. Puede entonces re-implementarse utilizando un enfoque ms estructurado.Las partes del sistema bien comprendidas se pueden especificar y desarrollar utilizando un proceso basado en el modelo en cascada. Las otras partes del sistema, como la interfaz de usuario, que son difciles de especificar por adelantado, se deben desarrollar siempre utilizando un enfoque de programacin exploratoria.

2.1.4 Espiral Es un modelo de proceso evolutivo que conjuga la naturaleza iterativa de la construccin de prototipos con aspectos controlados y sistemticos del modelo de cascada. Proporciona el material para el desarrollo rpido de versiones incrementales del software.El modelo de desarrollo en espiral es un generador del modelo de proceso guiado por el riesgo que se emplea para conducir sistemas intensivos de ingeniera de software concurrente con mltiples usuarios. Tiene dos caractersticas distintivas principales. Una de ellas es un enfoque cclico para el crecimiento incremental del grado de definicin e implementacin de un sistema, mientras su grado de riesgos disminuye. La otra es un conjunto de puntos de fijacin para asegurar el compromiso del usuario con soluciones de sistema que sean factibles y mutuamente satisfactorias.Cuando se aplica el modelo en espiral, el software se desarrolla en una serie de entregas evolutivas. Durante las primeras iteraciones, la entrega tal vez sea un documento del modelo o un prototipo. Durante las ltimas iteraciones se producen versiones cada vez ms completas del sistema desarrollado.

Un proceso en espiral se divide en un nmero de actividades del marco de trabajo que define el equipo de ingeniera de software. Para propsitos ilustrativos se aprovechan las actividades genricas del marco de trabajo representa un segmento de la ruta en espiral.Cuando comienza este proceso evolutivo el equipo de software realiza actividades implicadas en un circuito alrededor de la espiral y que se inicia en el centro. El riesgo es un factor considerado en cada revolucin. Los puntos de fijacin una combinacin de productos de trabajo y condiciones incluidas a lo largo de la ruta de la espiral- se consideran para cada paso evolutivo.El primer circuito alrededor de la espiral quiz genere el desarrollo de una especificacin del producto; los pasos subsecuentes alrededor de la espiral se pueden aprovechar para desarrollar un prototipo y despus, en forma progresiva, versiones ms elaboradas de software. Cada paso a travs de la regin de planeacin resulta en ajustes al plan del proyecto. Los costos y el itinerario se ajustan con base en la retroalimentacin derivada de la relacin con el cliente despus de la entrega. Adems, el administrador del proyecto ajusta el nmero de iteraciones planeado que se requiere para completar el software.A diferencia de otros modelos de proceso que terminan cuando se entrega el software, el modelo de espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. Por lo tanto, el primer circuito alrededor de la espiral podra representar un proyecto de desarrollo del concepto, el cual se inicia en el centro de la espiral y contina con mltiples iteraciones hasta que el desarrollo del concepto est completo. Si el concepto se desarrollar en un proyecto de desarrollo de un producto nuevo. El nuevo producto evolucionar a travs de un nmero de iteraciones alrededor de la espiral. Despus, un circuito alrededor de la espiral se podra emplear para representar un proyecto de mejoramiento del producto. En esencia. La espiral, cuando se caracteriza de esta forma, permanece operativa hasta que el software se retira. En ocasiones el proceso est inactivo, pero siempre que se inicie un cambio el proceso comienza en el punto de entrada aprobado (por ejemplo, mejoramiento del producto).El modelo en espiral es un enfoque realista para el desarrollo de software y de sistemas a gran escala. Como el software evoluciona conforme avanza el proceso, el desarrollador y el cliente entienden y reaccionan de mejor manera ante los riesgos en cada etapa evolutiva. El modelo en espiral emplea la construccin de prototipos como un mecanismo encaminado a reducir riesgos pero, en forma ms importante, permite al desarrollador la aplicacin del enfoque de la construccin de prototipos en cualquier etapa evolutiva del producto. Mantiene un enfoque sistemtico de los pasos que sugiere el ciclo de vida clsico, pero lo incorpora al marco de trabajo iterativo que refleja de forma ms verdica el mundo real. El modelo en espiral exige una consideracin directa de los riesgos tcnicos en todas las etapas del proyecto y, si se aplica en forma apropiada, debe reducir los riesgos antes de que se vuelvan problemticos.El desarrollo evolutivo se basa en la idea de desarrollar una implementacin inicial, exponindola a los comentarios del usuario y refinndola a travs de las diferentes versiones hasta que se desarrolla un sistema adecuado.

2.1.5 Prototipos El cliente normalmente define los objetivos generales del software pero no identifica detalladamente todos los requisitos. En otro caso el diseador no puede estar seguro de entender al cliente, de cmo podr ser el software que requiere, de la eficiencia que espera, etc. En estas situaciones puede ser mejor el mtodo de construccin de un prototipo.El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las reas del esquema en donde es obligatoria ms definicin. Entonces aparece un diseo rpido. El diseo rpido se centra en una representacin de esos aspectos del software que sern visibles para el usuario/cliente (por ejemplo: enfoques de entrada y formatos de salida). El diseo rpido lleva a la construccin de un prototipo. El prototipo lo evala el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar. La iteracin ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se necesita hacer.

El prototipo puede ser elaborado en papel o programado para que implemente algunas funciones requeridas de manera rudimentaria, sin todos los detalles y acabados del programa final. Se empieza con la recoleccin de requisitos, se produce un diseo rpido que se enfoca sobre los aspectos visibles al usuario (pantallas, informes, etc.) Se construye el prototipo y se evala por parte del cliente y sus observaciones se usan para refinar los requisitos del software a desarrollar. Se produce un proceso iterativo en el que el prototipo se afina para que satisfaga las necesidades del cliente y al mismo tiempo facilita al desarrollador una mejor comprensin de lo que tiene que hacer.

2.1.6 Desarrollo basado en componentes Las tecnologas de objetos proporcionan el marco de trabajo tcnico para un modelo de proceso basado en componentes para la ingeniera del software. El paradigma orientado a objetos enfatiza la creacin de clases que encapsulan tanto los datos como los algoritmos que se utilizan para manejar los datos. Si se disean y se implementan adecuadamente, las clases orientadas a objetos son reutilizables por las diferentes aplicaciones y arquitecturas de sistemas basados en computadora.

El modelo de desarrollo basado en componentes incorpora muchas de las caractersticas del modelo en espiral. Es evolutivo por naturaleza, y exige un enfoque iterativo para la creacin del software. Sin embargo, el modelo de desarrollo basado en componentes configura aplicaciones desde componentes preparados de software llamados clases.Las clases creadas en los proyectos anteriores de ingeniera de software, se almacenan en una biblioteca de clases o diccionario de datos (repository) Una vez identificadas las clases candidatas, la biblioteca de clases se examina para determinar si estas clases ya existen. En caso de que as fuera, se extraen de la biblioteca. Se compone as la primera iteracin de la aplicacin a construirse, mediante las clases extradas de la biblioteca y las clases nuevas construidas para cumplir las necesidades nicas de la aplicacin. El flujo del proceso vuelve a la espiral y volver a introducir por ltimo la iteracin ensambladora de componentes a travs de la actividad de ingeniera y se vuelven a utilizar.El modelo de desarrollo basado en componentes conduce a la reutilizacin del software, y la reutilizacin proporciona beneficios a los ingenieros de software. Segn estudios de reutilizacin, QSM Associates, Inc. Informa que el ensamblaje de componentes lleva a una reduccin del 70 por 100 de tiempo de ciclo de desarrollo, un 84 por 100 del coste del proyecto.

2.2 Otras Metodologas

2.2.1 Ganar-ganarEn la recoleccin de los requisitos el cliente y el desarrollador entran en un proceso de negociacin, donde el cliente puede ser preguntado para sopesar la funcionalidad, rendimiento, y otros productos o caractersticas del sistema frente al coste y al tiempo de comercializacin.

Las mejores negociaciones se esfuerzan en obtener ganar-ganar. Esto es, el cliente gana obteniendo el producto o sistema que satisface la mayor parte de sus necesidades y el desarrollador gana trabajando para conseguir presupuestos y lograr una fecha de entrega realista. El modelo en espiral WINWIN de Boehm define un conjunto de actividades de negociacin al principio de cada paso alrededor de la espiral. Ms que una simple actividad de comunicacin con el cliente, se definen las siguientes actividades:1. Identificacin del sistema o subsistemas clave de los directivos.2. Determinacin de las condiciones de ganar de los directivos.3. Negociacin de las condiciones de ganar de los directivos para reunirlas en un conjunto de condiciones ganar-ganar para todos los afectados (incluyendo el equipo del proyecto de software).Conseguidos completamente estos pasos iniciales se logra un resultado ganar-ganar, que ser el criterio clave para continuar con la definicin del sistema y del software.En esencia, los puntos de fijacin representan tres visiones diferentes del progreso mientras que el proyecto recorre la espiral. El primer punto de fijacin, llamado objetivos del ciclo de vida (OCV), define un conjunto de objetivos para cada actividad principal de ingeniera del software. Como ejemplo, de una parte de OCV, un conjunto de objetivos asociados a la definicin de los requisitos del producto/sistema del nivel ms alto. El segundo punto de fijacin, llamado arquitectura del ciclo de vida (ACV), establece los objetivos que se deben conocer mientras que se define la arquitectura del software y el sistema. Como ejemplo, de una parte de la ACV, el equipo del proyecto de software debe demostrar que ha evaluado la funcionalidad de los componentes del software reutilizables y que ha considerado su impacto en las decisiones de arquitectura. La capacidad operativa inicial (COI) es el tercer punto de fijacin y representa un conjunto de objetivos asociados a la preparacin del software para la instalacin/distribucin, preparacin del lugar previamente a la instalacin, y la asistencia precisada de todas las partes que utilizar o mantendr el software.

2.2.2 Proceso Unificado (UP) El Proceso de desarrollo unificado fue creado reuniendo los mejores rasgos y caractersticas de modelos de procesos de software. Reconoce la importancia de la comunicacin con el cliente enfatiza el importante papel de la arquitectura de software, y ayuda al arquitecto a enfocarse en las metas correctas. Sugiere un flujo de proceso iterativo e incremental y que proporciona el sentido evolutivo esencial en el desarrollo del software moderno.Es un marco de trabajo para la ingeniera de software orientado a objetos, mediante la utilizacin de UML (lenguaje de modelado unificado).

ElaboracinInicioTransicinIncremento del softwareLanzamiento

Produccin

Se compone de las siguientes fases:a. Inicio: Abarca la comunicacin con el cliente y las actividades de planeacin. Al colaborar con los clientes y usuarios finales se identifican los requisitos de negocios para el software, se propone una arquitectura aproximada para el sistema y se desarrolla un plan para la naturaleza iterativa e incremental del sistema subsiguiente. El propsito de esta fase es establecer una visin general para el proyecto, identificar los requisitos de negocios, formar un caso de negocios para el software y definir los riesgos del proyecto y del negocio que pudieran representar un obstculo para el xito. En esta etapa se obtiene el modelo de caso de uso que es una coleccin de casos de uso que describen la forma en que actores externos (usuarios humanos y no humanos del software) interactan con el sistema y obtienen valor a partir de ste. En esencia, el modelo de casos de uso es una coleccin de escenarios de uso con plantillas estandarizadas que implican caractersticas y funciones del software mediante la descripcin de una serie de condiciones previa, un flujo de eventos o un escenario, y un conjunto de condiciones exteriores para la interaccin representada. En un inicio, los casos de uso describen requisitos al nivel del dominio de negocios (por ejemplo, el grado de abstraccin es alto). Sin embargo, el modelo de casos de uso se refina y elabora conforme cada fase del Proceso Unificado se ejecuta y sirve como una entrada importante para la creacin de productos de trabajo subsecuentes. Durante la fase de inicio slo se completa entre el 10 y el 20 por ciento de los casos de uso. Despus de la elaboracin, se ha creado entre un 80 y 90 por ciento del modelo.b. Elaboracin: Abarca la comunicacin con el cliente y las actividades de modelado del modelo genrico. La elaboracin refina y expande los casos de uso preliminares que se desarrollaron como parte de la fase de inicio; adems, expande la representacin arquitectnica para incluir cinco visiones diferentes del software: el modelo de caso de uso, el modelo de anlisis, el modelo de diseo, el modelo de implementacin y el modelo de despliegue. En algunos casos, la elaboracin crea una lnea de base arquitectnica ejecutable que representa un sistema ejecutable en su primer corte. La lnea de base arquitectnica demuestra la viabilidad de la arquitectura, pero no proporciona todas las caractersticas y funciones necesarias para utilizar el sistema. Esta fase produce un conjunto de productos de trabajo que elabora requisitos (incluso requisitos no funcionales), as como una descripcin arquitectnica y un diseo preliminar. Cuando el ingeniero de software inicia con el anlisis orientado a objetos, el objetivo es definir un conjunto de clases de anlisis que describan en forma adecuada el comportamiento del sistema. El modelo de anlisis del Proceso Unificado es un producto de trabajo que se desarrolla como consecuencia de esta actividad. Los paquetes de clases y anlisis (colecciones de clases) definidos como una parte del modelo de anlisis se refinan despus en un modelo de diseo, el cual identifica clases de diseo, subsistemas y las interfaces entre los subsistemas. Adems en esta fase se revisan los riesgos y el plan del proyecto para asegurar que cada uno de ellos conserve su validez.c. Construccin: Est fase es idntica a la actividad de construccin definida para el proceso genrico del software. Si se utiliza el modelo arquitectnico como entrada, la fase de construccin desarrolla o adquiere los componentes del software que harn que cada caso de uso sea operativo para los usuarios finales. Lograr esto requiere que los modelos de anlisis y diseo iniciados durante la fase de elaboracin se completen para reflejar la versin final del incremento del software. Todas las caractersticas y funciones necesarias y requeridas del incremento del software (por ejemplo la entrega) se implementan en cdigo fuente. Conforme los componentes estn en proceso de implementacin, se disean y ejecutan pruebas de unidad para cada uno de ellos. Adems, se realizan las actividades de integracin (ensamblaje de componentes y pruebas de integracin). Los casos de uso se utilizan para derivar un conjunto de pruebas de aceptacin que se ejecutan antes del inicio de la siguiente fase. La fase de construccin produce un modelo de implementacin que traduce las clases de diseo en componentes de software que se constituirn para ejecutar el sistema, y un modelo de despliegue convierte los componentes en el ambiente fsico de computacin. Por ltimo, un modelo de prueba describe las pruebas empleadas para asegurar que los casos de uso se reflejen de manera apropiada en el software que se ha construido.d. Transicin: abarca las ltimas etapas de la actividad genrica de construccin y la primera parte de la actividad genrica de despliegue. El software se entrega a los usuarios finales para realizar pruebas beta, y la retroalimentacin del usuario reporta tanto defectos como cambios necesarios. Adems, el equipo de software crea la informacin de soporte necesaria (por ejemplo, manuales del usuario, guas de resolucin de problemas, procedimientos de instalacin) para el lanzamiento. Al final de la fase de transicin, el incremento de software se convierte en un lanzamiento de software utilizable. La fase transicin entrega el incremento del software y evala los productos de trabajo elaborados durante la etapa en que los usuarios finales trabajan con el software. En esta etapa se produce la retroalimentacin proveniente de las pruebas beta y los requerimientos cualitativos de cambio.e. Produccin: Esta fase coincide con la actividad de despliegue del proceso genrico. Durante esta fase se monitorea el uso subsiguiente del software, se proporciona soporte para el ambiente operativo (infraestructura), y se reciben y evalan los informes de defectos y los requerimientos de los cambios.En este modelo es posible que mientras se estn ejecutando las fases de construccin, transicin y produccin ya se hayan iniciado trabajos para el siguiente incremento del software.La perspectiva prctica de este proceso describe buenas prcticas de la ingeniera del software que son aconsejables en el desarrollo de sistemas. Se recomiendan seis buenas prcticas fundamentales:1. Desarrolle el software de forma iterativa. Planifique incrementos del sistema basado en las prioridades del usuario y desarrollo y entregue las caractersticas del sistema de ms alta prioridad al inicio del proceso de desarrollo.2. Gestione los requerimientos. Documente explcitamente los requerimientos del cliente y mantngase al tanto de los cambios de estos requerimientos. Analice el impacto de los cambios en el sistema antes de aceptarlos.3. Utilice arquitecturas basadas en componentes. Estructure la arquitectura del sistema en componentes.4. Modele el software visualmente. Utilice modelos grficos UML para presentar vistas estticas y dinmicas del software.5. Verifique la calidad del software. Asegure que el software cumple los estndares de calidad organizacionales.6. Controle los cambios del software. Gestione los cambios del software usando un sistema de gestin de cambios y procedimientos y herramientas de gestin de configuraciones.

2.2.3 Ingeniera Web El proceso de ingeniera Web comienza con una formulacin del problema que pasa a resolverse con las WebApps. Se planifica el proyecto y se analizan los requisitos de la WebApp, entonces se lleva a cabo el diseo de interfaces arquitectnico y del navegador. El sistema se implementa utilizando lenguajes y herramientas especializados asociados con la Web, y entonces comienzan las pruebas. Dado que las WebApps estn en constante evolucin, deben de establecerse los mecanismos para el control de configuraciones, garanta de calidad y soporte continuo.La Ingeniera Web (IWeb) est relacionada con el establecimiento y utilizacin de principios cientficos, de ingeniera y de gestin, y con enfoques sistemticos y disciplinados del xito del desarrollo, empleo y mantenimiento de sistemas y aplicaciones basados en Web de alta calidad.Los sistemas basados en Web implican una mezcla de publicacin impresa y desarrollo de software, de marketing e informtica, de comunicaciones internas y relaciones externas, y de arte y tecnologa.Atributos de las aplicaciones WEB:Intensivas de Red. Por su propia naturaleza, una WebApp es intensiva de red. Reside en una red y debe dar servicio a las necesidades de una comunidad diversa de clientes. Una WebApp puede residir en Internet (haciendo posible as una comunicacin abierta para todo el mundo). De forma alternativa, una aplicacin se puede ubicar en una Intranet (implementando la comunicacin a travs de redes de una organizacin) o una Extranet (comunicacin entre redes).Controlada por el contenido. En muchos casos, la funcin primaria de una WebApp es utilizar hipermedia para presentar al usuario el contenido de textos, grficos, sonido y vdeo.Evolucin continua. A diferencia del software de aplicaciones convencional, que evoluciona con una serie de versiones planificadas y cronolgicamente espaciadas, las aplicaciones Web estn en constante evolucin. No es inusual que algunas WebApps (especficamente, su contenido) se actualicen cada hora.Inmediatez. Las aplicaciones basadas en Web tienen una inmediatez que no se encuentra en otros tipos de software. Es decir, el tiempo que se tarda en comercializar un sitio Web completo puede ser cuestin de das o semanas. Los desarrolladores debern utilizar los mtodos de planificacin, anlisis, diseo, implementacin y comprobacin que se hayan adaptado a planificaciones apretadas en tiempo para el desarrollo de WebApps.Seguridad. Dado que las WebApps estn disponibles a travs del acceso por red, es difcil, si no imposible, limitar la poblacin de usuarios finales que pueden acceder a la aplicacin. Con objeto de proteger el contenido confidencial y de proporcionar formas seguras de transmisin de datos, debern implementarse fuertes medidas de seguridad en toda la infraestructura que apoya una WebApp y dentro de la misma aplicacin.Esttica. Una parte innegable del atractivo de una WebApp es su apariencia e interaccin. Cuando se ha diseado una aplicacin con el fin de comercializarse o vender productos o ideas, la esttica puede tener mucho que ver con el xito del diseo tcnico.

Categoras de las pginas Web1. Informativa: se proporciona un contenido solo de lectura con navegacin y enlaces simples.2. Descarga: un usuario descarga la informacin desde el servidor apropiado.3. Personalizable: el usuario personaliza el contenido a sus necesidades especficas.4. Interaccin: la comunicacin entre una comunidad de usuarios ocurre mediante un espacio chat (charla), tablones de anuncios o mensajera instantnea.5. Entrada del usuario: la entrada basada en formularios es el mecanismo primario de la necesidad de comunicacin.6. Orientada a transacciones: el usuario hace una solicitud (por ejemplo, la realizacin un pedido) que es cumplimentado por la WebApp.7. Orientado a servicios: la aplicacin proporciona un servicio al usuario, por ejemplo, ayuda al usuario a determinar un pago de hipoteca.8. Portal: la aplicacin canaliza al usuario llevndolo a otros contenidos o servicios Web fuera del dominio de la aplicacin del portal.9. Acceso a bases de datos: el usuario consulta en una base de datos grande y extrae informacin.10. Almacenes de datos: el usuario hace una consulta en una coleccin de bases de datos grande y extrae informacin.

2.2.4 Metodologas giles Hasta hace poco el proceso de desarrollo de software tena un marcado nfasis en el control del proceso mediante una rigurosa definicin de roles, actividades y artefactos, incluyendo modelado y documentacin detallada. Este esquema "tradicional" para abordar el desarrollo de software ha demostrado ser efectivo y necesario en proyectos de gran tamao (respecto a tiempo y recursos), donde por lo general se exige un alto grado de ceremonia en el proceso. Sin embargo, este enfoque no resulta ser el ms adecuado para muchos de los proyectos actuales donde el entorno del sistema es muy cambiante, y en donde se exige reducir drsticamente los tiempos de desarrollo pero manteniendo una alta calidad. Ante las dificultades para utilizar metodologas tradicionales con estas restricciones de tiempo y flexibilidad, muchos equipos de desarrollo se resignan a prescindir del buen hacer de la ingeniera del software, asumiendo el riesgo que ello conlleva.En este escenario, las metodologas giles emergen como una posible respuesta para llenar ese vaco metodolgico. Por estar especialmente orientadas para proyectos pequeos, las metodologas giles constituyen una solucin a medida para ese entorno, aportando una elevada simplificacin que a pesar de ello no renuncia a las prcticas esenciales para asegurar la calidad del producto.Las caractersticas de los proyectos para los cuales las metodologas giles han sido especialmente pensadas se ajustan a un amplio rango de proyectos industriales de desarrollo de software; aquellos en los cuales los equipos de desarrollo son pequeos, con plazos reducidos, requisitos voltiles, y/o basados en nuevas tecnologas.En febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace el trmino gil aplicado al desarrollo de software. En esta reunin participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologas de software. Su objetivo fue esbozar los valores y principios que deberan permitir a los equipos desarrollar software rpidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretenda ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rgidos y dirigidos por la documentacin que se genera en cada una de las actividades desarrolladas.Tras esta reunin se cre The Agile Alliance, una organizacin, sin nimo de lucro, dedicada a promover los conceptos relacionados con el desarrollo gil de software y ayudar a las organizaciones para que adopten dichos conceptos. El punto de partida fue el Manifiesto gil, un documento que resume la filosofa gil.El Manifiesto gil.Segn el Manifiesto se valora: Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente es el principal factor de xito de un proyecto software. Es ms importante construir un buen equipo que construir el entorno. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte automticamente. Es mejor crear el equipo y que ste configure su propio entorno de desarrollo en base a sus necesidades. Desarrollar software que funciona ms que conseguir una buena documentacin. La regla a seguir es no producir documentos a menos que sean necesarios de forma inmediata para tomar un decisin importante- Estos documentos deben ser cortos y centrarse en lo fundamental. La colaboracin con el cliente ms que la negociacin de un contrato. Se propone que exista una interaccin constante entre el cliente y el equipo de desarrollo. Esta colaboracin entre ambos ser la que marque la marcha del proyecto y asegure su xito. Responder a los cambios ms que seguir estrictamente un plan. La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnologa, en el equipo, etc.) determina tambin el xito o fracaso del mismo. Por lo tanto, la planificacin no debe ser estricta sino flexible y abierta.Los valores anteriores inspiran los doce principios del manifiesto. Son caractersticas que diferencian un proceso gil de uno tradicional. Los dos primeros principios son generales y resumen gran parte del espritu gil. El resto tienen que ver con el proceso a seguir y con el equipo de desarrollo, en cuanto metas a seguir y organizacin del mismo. Los principios son:I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor.II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva.III. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas.IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.VI. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin dentro de un equipo de desarrollo.VII. El software que funciona es la medida principal de progreso.VIII. Los procesos giles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberan ser capaces de mantener una paz constante.IX. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad.X. La simplicidad es esencial.XI. Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados por s mismos.XII. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms efectivo, y segn esto ajusta su comportamiento.

Metodologas gilesMetodologas tradicionales

Basadas en heursticas provenientes de prcticas de produccin de cdigo.Basadas en normas provenientes de estndares seguidos por el entorno de desarrollo

Especialmente preparados para cambios durante el proyecto.Cierta resistencia a los cambios.

Impuestas internamente (por el equipo)Impuestas externamente

Proceso menos controlado, con pocos principiosProceso mucho ms controlados, con numerosas polticas/normas

No existe contrato tradicional o al menos es bastante flexibleExiste un contrato prefijado

El cliente es parte del equipo de desarrollo El cliente interacta con el equipo de desarrollo mediante reuniones

Grupos pequeos ( menos de 10 integrantes) y trabajando en el mismo sitioGrupos grandes y posiblemente distribuidos

Pocos artefactosMs artefactos

Pocos rolesMs roles

Menos nfasis en la arquitectura de softwareLa arquitectura del software es esencial y se expresa mediante modelos.

PROGRAMACIN EXTREMA (EXTREME PROGRAMMING, XP)XP es una metodologa gil centrada en potenciar las relaciones interpersonales como clave para el xito en desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo tcnico. Los principios y prcticas son de sentido comn pero llevadas al extremo, de ah proviene su nombre. Kent Beck, el padre de XP, describe la filosofa de XP en sin cubrir los detalles tcnicos y de implantacin de las prcticas. Las caractersticas esenciales de XP: historias de usuario, roles, proceso y prcticas.a) Las Historias de UsuarioSon la tcnica utilizada para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las caractersticas que el sistema debe poseer, sean requisitos funcionales o no funcionales. El tratamiento de las historias de usuario es muy dinmico y flexible. Cada historia de usuario es lo suficientemente comprensible y delimitada para que los programadores puedan implementarla en unas semanas.Debe tener los siguientes contenidos segn Beck: fecha, tipo de actividad (nueva, correccin, mejora), prueba funcional, nmero de historia, prioridad tcnica y del cliente, referencia a otra historia previa, riesgo, estimacin tcnica, descripcin, notas y una lista de seguimiento con la fecha, estado cosas por terminar y comentarios. A efectos de planificacin, las historias pueden ser de una a tres semanas de tiempo de programacin (para no superar el tamao de una iteracin). Las historias de usuario son descompuestas en tareas de programacin (task card) y asignadas a los programadores para ser implementadas durante una iteracin.b) Roles XPLos roles de acuerdo con la propuesta original de Beck son: Programador. El programador escribe las pruebas unitarias y produce el cdigo del sistema. Cliente. Escribe las historias de usuario y las pruebas funcionales para validar su implementacin. Adems, asigna la prioridad a las historias de usuario y decide cules se implementan en cada iteracin centrndose en aportar mayor valor al negocio. Encargado de pruebas (Tester). Ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas. Encargado de seguimiento (Tracker). Proporciona realimentacin al equipo. Verifica el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, para mejorar futuras estimaciones. Realiza el seguimiento del progreso de cada iteracin. Entrenador (Coach). Es responsable del proceso global. Debe proveer guas al equipo de forma que se apliquen las prcticas XP y se siga el proceso correctamente. Consultor. Es un miembro externo del equipo con un conocimiento especfico en algn tema necesario para el proyecto, en el que puedan surgir problemas. Gestor (Big boss). Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinacin.

c) Proceso XPEl ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos:1. El cliente define el valor de negocio a implementar.2. El programador estima el esfuerzo necesario para su implementacin.3. El cliente selecciona qu construir, de acuerdo con sus prioridades y las restricciones de tiempo.4. El programador construye ese valor de negocio.5. Vuelve al paso 1.En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe presionar al programador a realizar ms trabajo que el estimado, ya que se perder calidad en el software o no se cumplirn los plazos. De la misma forma el cliente tiene la obligacin de manejar el mbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteracin.El ciclo de vida ideal de XP consiste de seis fases: Exploracin, Planificacin de la Entrega (Release), Iteraciones, Produccin, Mantenimiento y Muerte del Proyecto.

d) Prcticas XPLa principal suposicin que se realiza en XP es la posibilidad de disminuir la mtica curva exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseo evolutivo funcione. Esto se consigue gracias a las tecnologas disponibles para ayudar en el desarrollo de software y a la aplicacin disciplinada de las siguientes prcticas. El juego de la planificacin. Hay una comunicacin frecuente el cliente y los programadores. El equipo tcnico realiza una estimacin del esfuerzo requerido para la implementacin de las historias de usuario y los clientes deciden sobre el mbito y tiempo de las entregas y de cada iteracin. Entregas pequeas. Producir rpidamente versiones del sistema que sean operativas, aunque no cuenten con toda la funcionalidad del sistema. Esta versin ya constituye un resultado de valor para el negocio. Una entrega no debera tardar ms 3 meses. Metfora. El sistema es definido mediante una metfora o un conjunto de metforas compartidas por el cliente y el equipo de desarrollo. Una metfora es una historia compartida que describe cmo debera funcionar el sistema (conjunto de nombres que acten como vocabulario para hablar sobre el dominio del problema, ayudando a la nomenclatura de clases y mtodos del sistema). Diseo simple. Se debe disear la solucin ms simple que pueda funcionar y ser implementada en un momento determinado del proyecto. Pruebas. La produccin de cdigo est dirigida por las pruebas unitarias. stas son establecidas por el cliente antes de escribirse el cdigo y son ejecutadas constantemente ante cada modificacin del sistema. Refactorizacin (Refactoring). Es una actividad constante de reestructuracin del cdigo con el objetivo de remover duplicacin de cdigo, mejorar su legibilidad, simplificarlo y hacerlo ms flexible para facilitar los posteriores cambios. Se mejora la estructura interna del cdigo sin alterar su comportamiento externo [8]. Programacin en parejas. Toda la produccin de cdigo debe realizarse con trabajo en parejas de programadores. Esto conlleva ventajas implcitas (menor tasa de errores, mejor diseo, mayor satisfaccin de los programadores, ). Propiedad colectiva del cdigo. Cualquier programador puede cambiar cualquier parte del cdigo en cualquier momento. Integracin continua. Cada pieza de cdigo es integrada en el sistema una vez que est lista. As, el sistema puede llegar a ser integrado y construido varias veces en un mismo da. 40 horas por semana. Se debe trabajar un mximo de 40 horas por semana. No se trabajan horas extras en dos semanas seguidas. Si esto ocurre, probablemente est ocurriendo un problema que debe corregirse. El trabajo extra desmotiva al equipo. Cliente in-situ. El cliente tiene que estar presente y disponible todo el tiempo para el equipo. ste es uno de los principales factores de xito del proyecto XP. El cliente conduce constantemente el trabajo hacia lo que aportar mayor valor de negocio y los programadores pueden resolver de manera inmediata cualquier duda asociada. La comunicacin oral es ms efectiva que la escrita. Estndares de programacin. XP enfatiza que la comunicacin de los programadores es a travs del cdigo, con lo cual es indispensable que se sigan ciertos estndares de programacin para mantener el cdigo legible.

El mayor beneficio de las prcticas se consigue con su aplicacin conjunta y equilibrada puesto que se apoyan unas en otras. Esto se ilustra en la figura anterior, donde una lnea entre dos prcticas significa que las dos prcticas se refuerzan entre s. La mayora de las prcticas propuestas por XP no son novedosas sino que en alguna forma ya haban sido propuestas en ingeniera del software e incluso demostrado su valor en la prctica. El mrito de XP es integrarlas de una forma efectiva y complementarlas con otras ideas desde la perspectiva del negocio, los valores humanos y el trabajo en equipo.

2.2.5 Metodologas emergentesAunque los creadores e impulsores de las metodologas giles ms populares han suscrito el manifiesto gil y coinciden con los principios enunciados anteriormente, cada metodologa tiene caractersticas propias y hace hincapi en algunos aspectos ms especficos. A continuacin se resumen otras metodologas giles. La mayora de ellas ya estaban siendo utilizadas con xito en proyectos reales pero les faltaba una mayor difusin y reconocimiento. SCRUM5. Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un marco para la gestin de proyectos, que se ha utilizado con xito durante los ltimos 10 aos. Est especialmente indicada para proyectos con un rpido cambio de requisitos. Sus principales caractersticas se pueden resumir en dos. El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duracin de 30 das. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente. La segunda caracterstica importante son las reuniones a lo largo proyecto, entre ellas destaca la reunin diaria de 15 minutos del equipo de desarrollo para coordinacin e integracin. Crystal Methodologies. Se trata de un conjunto de metodologas para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo y la reduccin al mximo del nmero de artefactos producidos. Han sido desarrolladas por Alistair Cockburn. El desarrollo de software se considera un juego cooperativo de invencin y comunicacin, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, as como tener polticas de trabajo en equipo definidas. Estas polticas dependern del tamao del equipo, establecindose una clasificacin por colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros). Dynamic Systems Development Method(DSDM)]. Define el marco para desarrollar un proceso de produccin de software. Nace en 1994 con el objetivo de crear una metodologa RAD unificada. Sus principales caractersticas son: es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad, estudio del negocio, modelado funcional, diseo y construccin, y finalmente implementacin. Las tres ltimas son iterativas, adems de existir realimentacin a todas las fases. Adaptive Software Development (ASD). Su impulsor es Jim Highsmith. Sus principales caractersticas son: iterativo, orientado a los componentes software ms que a las tareas y tolerante a los cambios. El ciclo de vida que propone tiene tres fases esenciales: especulacin, colaboracin y aprendizaje. En la primera de ellas se inicia el proyecto y se planifican las caractersticas del software; en la segunda desarrollan las caractersticas y finalmente en la tercera se revisa su calidad, y se entrega al cliente. La revisin de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo. Feature -Driven Development (FDD). Define un proceso iterativo que consta de 5 pasos. Las iteraciones son cortas (hasta 2 semanas). Se centra en las fases de diseo e implementacin del sistema partiendo de una lista de caractersticas que debe reunir el software. Sus impulsores son Jeff De Luca y Peter Coad. Lean Development10 (LD). Definida por Bob Charette.s a partir de su experiencia en proyectos con la industria japonesa del automvil en los aos 80 y utilizada en numerosos proyectos de telecomunicaciones en Europa. En LD, los cambios se consideran riesgos, pero si se manejan adecuadamente se pueden convertir en oportunidades que mejoren la productividad del cliente. Su principal caracterstica es introducir un mecanismo para implementar dichos cambios.

2.3 Reingeniera Cuando un software es obsoleto se necesitar reconstruirlo. Se crear un producto con una funcionalidad nueva, un mejor rendimiento y fiabilidad, y un mantenimiento mejorado. Eso es lo que llamamos reingeniera.La reingeniera es realizada por ingenieros del software.El proceso de reingeniera del software acompaa el anlisis de inventarios, la estructuracin de documentos, la ingeniera inversa, la reestructuracin de datos y la ingeniera avanzada. El objetivo de estas actividades es crear versiones nuevas de los programas existentes que exhiben una mantenibilidad de mayor calidad.Son varios los productos que se elaboran (por ejemplo, modelos anlisis, modelos de diseo, procedimientos de pruebas).El resultado final es el software de reingeniera que lo soporta.En la actualidad, existen compaas importantes que poseen decenas de miles de programas de computadora que prestan apoyo a las viejas reglas del negocio. Cuando los administradores trabajan para modificar estas reglas y lograr as una mayor efectividad y competitividad, el software seguir el mismo ritmo. En algunos casos, esto implica la creacin de sistemas nuevos e importantes basados en computadora. Pero en muchos otros, esto implica la modificacin y/o reconstruccin de las aplicaciones existentes.