Ingeniería web

La inmediatez, evolución y crecimiento continuos, son características de las aplicaciones Web, esto nos lleva a un proceso incremental y evolutivo, que permite que el usuario se involucre activamente, facilitando el desarrollo de productos que se ajustan a sus requerimientos. Pressman enumera siete actividades que forman parte del proceso de la IWeb y que son aplicables a cualquier WebApp independientemente de su tamaño y complejidad.

Métodos de la Ingeniería Web

Los métodos de la Ingeniería Web definen las etapas y actividades necesarias para efectuar la construcción completa de una aplicación Web. El principio subyacente en todos ellos es que una aplicación Web debe desarrollarse partiendo de una descripción precisa en forma de un Esquema Conceptual que se transforma a una representación software, mediante un conjunto de correspondencias entre las abstracciones conceptuales que constituyen su esquema conceptual y los componentes software. En menor o mayor medida y a veces con diferentes nombres o sub-fases, la mayoría de los métodos coinciden en las siguientes etapas:

• Diseño Conceptual: Trata de la especificación del dominio del problema, a través de la definición de datos y sus relaciones.
• Diseño Navegacional: Establece los caminos de acceso a la información y sus permisos de visibilidad.
• Diseño de la presentación o diseño de Interfaz: Define cómo se muestra la información en la interfaz de usuario.
• Implementación: Es la construcción del software a partir de los artefactos generados en las etapas previas.

 Pressman sugiere un proceso de ingeniería web compuesto por las siguientes fases:

• Planteamiento y formulación. Identificamos los objetivos de nuestra aplicación, y delimitamos el alcance de la primera iteración.
• Planificación. Una vez planteado el problema, podremos estimar costos, riesgos y esfuerzo durante el desarrollo. Recordemos que en la planeación iterativa solamente se detalla la iteración actual, y las iteraciones subsecuentes sólo se plantean de forma general.
• Análisis. Durante esta etapa establecemos los requerimientos técnicos, gráficos, y de contenido, que incorporaremos en la iteración.
• Ingeniería. La actividad de ingeniería incorpora dos grupos de tareas que se realizan en paralelo: el diseño del contenido y la producción, se enfocan en el diseño, producción y adquisición del contenido de texto, gráfico y video que se vayan a integrar en la aplicación. Estas tareas son realizadas por personal no técnico. Por otro lado, están el diseño arquitectónico, de navegación e interfaz, el cual lidia con los aspectos técnicos.
• Generación de páginas y pruebas. Se prueba que el contenido dinámico se genere correctamente, utilizando las plantillas, interfaces y contenidos diseñados en la fase de ingeniería. Posteriormente se realizan las pruebas pertinentes, que dependerán del tipo de aplicación y requerimientos no funcionales (por ejemplo, pruebas de desempeño, etcétera).
• Evaluación del cliente. Al final de cada iteración se debe realizar una evaluación con el cliente, para validar el avance y determinar los cambios o mejoras –en caso de ser necesarios–, que se aplicarán en las siguientes iteraciones.

Particularidades del desarrollo web

Se reconoce que las aplicaciones web tienen sus particularidades, y por ello deben recibir especial atención en algunos puntos, pero esto no significa que deban ignorar por completo la ingeniería. Entre las particularidades más significativas podemos listar:

• Residente en red. Una aplicación web reside en una red, y debe dar servicio a una comunidad diversa de clientes.
• Inmediatez. Se refiere al corto tiempo que normalmente tienen los proyectos web para terminar, o por lo menos, lanzar una versión inicial.
• Evolución continúa. A diferencia del software de aplicaciones convencional, que evoluciona a través de versiones planeadas y cronológicamente espaciadas, las aplicaciones web están en constante evolución, y se actualizan gradualmente.
• Seguridad. Dado que no controlamos con certeza quién puede acceder a nuestra aplicación; la seguridad y confidencialidad de la información requieren un énfasis especial.
• Estética. Es bien sabido que la primera impresión jamás se olvida, por lo que nuestro sitio debe ser atractivo, ergonómico y usable. 
• Medible. Mediante la cuantificación de resultados, podemos conocer la cantidad de usuarios que tenemos, así como sus patrones de comportamiento.

Ventajas

• Es de Fácil uso
• Permite la comunicación rápida y directa con una o varias personas que se encuentre en cualquier parte del mundo, ayudando de esta manera en las Tics.
• Desarrollo de diferentes proyectos y propuestas para dar a conocer dichos proyectos a través de la red
• Ayuda en el proceso de globalización de las empresas, ya que permite contactar diferentes entidades y personas en el mundo sin altos costos
• Crear publicidad para que los clientes puedan acceder a productos y servicios y tengan información actualizada de ellos.
• Creación de ventaja competitiva, ya que la empresa o entidad se encontraría a la vanguardia de la tecnología.

Desventajas

• No posee muchas funcionalidades para la empresa. Solo suple necesidades de comunicación.
• No ofrece diversidad de opciones

Características 

• Inmediatez y evolución.
• Crecimiento continuo.
• Se publica contenido generalmente estático o un muy bajo nivel de interactividad con el usuario.

Basados en componentes

Un componente es una unidad de composición de aplicaciones software, que posee un conjunto de interfaces y un conjunto de requisitos, y que ha de poder ser desarrollado, adquirido, incorporado al sistema y compuesto con otros componentes de forma independiente, en tiempo y espacio.

El desarrollo basado en componentes (CBD) es un área nueva y poco explorada. Se lo suele asociar e incluso confundir con el desarrollo orientado a objetos (OOD); a pesar de que ambos enfoques están relacionados, los mismos son aplicables a sistemas de distinto porte. Generalmente OOD es asociado con Programming-in-the-Small, mientras que CBD es más aplicable a Programming-in-the-Large.

El desarrollo basado en componentes es una aplicación de la técnica de divide & conquer para manejar la complejidad. La diferencia principal con los métodos estructurados es principalmente que el análisis y diseño es realizado dentro del mismo paradigma que la implementación. Esta implementación queda relegada a un segundo plano, siendo importante dar una solución lógica al problema, previo a su codificación. Este principio fue utilizado en el paradigma de orientación a objetos, el hecho de combinar operaciones e información en una misma unidad, y de contar con técnicas de modelado dentro del mismo paradigma, hizo que la orientación a objetos tuviera un éxito importante.

El principal objetivo que se persiguió con la introducción de este paradigma fue el reuso.

La necesidad de reusar una clase implica llevar consigo otros artefactos que en un principio pueden no ser necesarios para el nuevo escenario donde se quiere reaprovechar la clase.

Por esta razón, el paradigma de componentes no se focaliza en el principio de reuso sino que ataca principalmente la mantenibilidad. El reuso es un objetivo admirable pero no es sencillo de obtener. Bajo el enfoque de componentes se busca construir para el cambio. Los sistemas actuales cambian sus requerimientos incluso cuando el sistema ya está en producción. El principal objetivo de un componente no es el reuso sino que sea fácilmente reemplazable.

El enfoque de componentes enfatiza en la arquitectura del sistema y en la capacidad de manejar al sistema completo, de forma tal que es en base a esa arquitectura que se evalúa el impacto del cambio y no en base a información local. Las decisiones internas a los componentes son un objetivo secundario, siendo lo primordial su interacción con el resto de los componentes del sistema. El enfoque propone concentrarse en el todo y no en las partes.

La metodología propuesta está basada en casos de uso y está centrada en la arquitectura. Estos lineamientos generales, propuestos por el Rational Unified Proccess, encajan fuertemente con los objetivos de nuestro paradigma.

El modelo de desarrollo basado en componentes incorpora muchas de las características del modelo espiral. Es evolutivo por naturaleza y exige un enfoque interactivo para la creación del software. Sin embargo, el modelo de desarrollo basado en componentes configura aplicaciones desde componentes preparados de software (clases).

Actividades Particulares al Enfoque

Identificación de Componentes

Esta etapa identifica a partir de los artefactos generados en las actividades anteriores el conjunto de interfaces y especificaciones de componentes que poblaran la arquitectura.

Esta actividad tiene como objetivos:

• Crear un conjunto inicial de interfaces y especificaciones de componentes, tanto a nivel de componentes de sistema como de componentes de negocio.
• Producir el modelo de tipos del negocio inicial, partiendo del modelo conceptual preliminar.
• Presentar las interfaces y especificaciones de componentes en una arquitectura de componentes inicial, decidiendo de que forma se agrupan las interfaces en especificaciones de componentes. 

Interacción de Componentes

En esta etapa se decide cómo trabajarán juntos los componentes detectados en la etapa anterior de forma de satisfacer las funcionalidades deseadas.

Los objetivos particulares de esta actividad son:

• Refinar las definiciones de las interfaces de sistema.
• Definir las interacciones entre los componentes identificando operaciones en las interfaces de los componentes de negocio y determinando las dependencias entre componentes.
• Definir políticas de manejo de integridad referencial.

Especificación de Componentes

Esta actividad es realizada una vez que la arquitectura e interfaces de los componentes estén estables. La especificación de los componentes es una actividad fundamental la cual favorece fuertemente a la reemplazabilidad así como posibilita el reuso de componentes en futuros proyectos.

Los objetivos de esta actividad son:

• Definir el modelo de información de cada interfaz; este modelo representa una vista abstracta de la información manejada por el componente.
• Especificar formalmente las operaciones de las interfaces; esta especificación se realiza con contratos de software.
• Capturar y documentar las restricciones entre los componentes.

Ventajas

• Reutilización del software. Nos lleva a alcanzar un mayor nivel de reutilización de software.
• Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de los componentes antes de probar el conjunto completo de componentes ensamblados.
• Simplifica el mantenimiento del sistema. Cuando existe un débil acoplamiento entre componentes, el desabollador es libre de actualizar y/o agregar componentes según sea necesario, sin afectar otras partes del sistema.
• Mayor calidad. Dado que un componente puede ser construido y luego mejorado continuamente por un experto u organización, la calidad de una aplicación basada en componentes mejorará con el paso del tiempo.
• Reduce los costes y tiempos.

Desventajas

• Genera mucho tiempo en el desarrollo del sistema.
• Modelo costoso.
• Requiere experiencia en la identificación de riesgos.
• Inconvenientes.
• Genera mucho trabajo adicional. Cuando un sistema falla se pierde tiempo y coste dentro de la empresa. Exige una cierta habilidad en los analistas (es bastante difícil).

Características de un Componente

• Identificable: Debe tener una identificación que permita acceder fácilmente a sus servicios que permita su clasificación.
• Auto contenido: Un componente no debe requerir de la utilización de otros para finiquitar la función para la cual fue diseñado.
• Puede ser remplazado por otro componente: Se puede remplazar por nuevas versiones u otro componente que lo remplace y mejore.
• Con acceso solamente a través de su interfaz: Debe asegurar que estas no cambiaran a lo largo de su implementación.
• Sus servicios no varían: Las funcionalidades ofrecidas en su interfaz no deben variar, pero su implementación sí.
• Bien Documentado: Un componente debe estar correctamente documentado para facilitar su búsqueda si se quiere actualizar, integrar con otros, adaptarlo, etc.
• Es genérico: Sus servicios deben servir para varias aplicaciones.
• Reutilizado dinámicamente: Puede ser cargado en tiempo de ejecución en una aplicación.
• Independiente de la plataforma: Hardware, Software, S.O.

SCRUM

Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.

En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales.

Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la moral de los equipos es baja y la rotación alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de producto.

En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de un mes natural y hasta de dos semanas, si así se necesita). Cada iteración tiene que proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite.

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a su coste y quedan repartidos en iteraciones y entregas.  

Fases de ejecución

• Planteamiento: un proyecto gestionado bajo el modelo SCRUM parte de los objetivos que han trazado con anterioridad el cliente y la empresa. Lo primero es fraccionarlo en entregas parciales, de manera que el cliente pueda replantear aspectos a los que en principio no prestó la importancia debida o que simplemente desconocía. Esos aspectos pueden ser sobre costes, estrategias, producción, etc.
• Lista de tareas: el equipo de trabajo elabora la lista de tareas que debe tener en cuenta para cada entrega de resultados. Es muy importante hacer una estimación del esfuerzo requerido para, de esta manera, fijas plazos proporcionados.
• Reuniones: lo ideal es que cada día el equipo dedique 15 minutos para reunirse y ponerse al tanto de la evolución del plan. En estas sesiones, el líder del proyecto (Scrum Master) debe encargarse de que cada miembro cumpla con las labores que le han sido asignadas y de motivarles para que su productividad no descienda. En caso de que detecte alguna incidencia dentro del grupo, es necesario que tome las opciones más adecuadas, que pueden ir desde un relevo de la función hasta el nombramiento de miembros de apoyo.
• Demostración: una vez ejecutadas las labores de cada fase, el equipo se reúne con el cliente para mostrar los avances correspondientes. El cliente decide si replantea los elementos del proyecto. Si es necesario, el equipo asume nuevos compromisos.
• Retrospectiva: los miembros del equipo se reúnen para valorar el proceso de entrega de resultados y analizan los factores que podrían mejorar de cara al final del proceso. La función del Scrum Master será eliminar dichos obstáculos.

Roles

Product Owner

• Las responsabilidades del Product Owner (que puede ser interno o externo a la organización) son:
• Ser el representante de todas las personas interesadas en los resultados del proyecto (internas o externas a la organización, promotores del proyecto y usuarios finales [idealmente también debería ser un usuario clave] o consumidores finales del producto) y actuar como interlocutor único ante el equipo, con autoridad para tomar decisiones.
• Definir los objetivos del producto o proyecto.
• Dirigir los resultados del proyecto y maximizar su ROI (Return Of Investment).
• Es el propietario de la planificación del proyecto: crea y mantiene la lista priorizada con los requisitos necesarios para cubrir los objetivos del producto o proyecto, conoce el valor que aportará cada requisito y calcula el ROI a partir del coste de cada requisito que le proporciona el equipo.
• Reparte los objetivos/requisitos en iteraciones y establece un calendario de entregas.
• Antes de iniciar cada iteración replanifica el proyecto en función de los requisitos que aportan más valor en ese momento, de los requisitos completados en la iteración anterior y del contexto del proyecto en ese momento (demandas del mercado, movimientos de la competencia, etc.).
• Colaborar con el equipo para planificar, revisar y dar detalle a los objetivos de cada iteración:
• Participar en la reunión de planificación de iteración, proponiendo los requisitos más prioritarios a desarrollar, respondiendo a las dudas del equipo y detallando los requisitos que el equipo se comprometer a hacer.
• Estar disponible durante el curso de la iteración para responder a las preguntas que puedan aparecer.
• No cambiar los requisitos que se están desarrollando en una iteración, una vez está iniciada.
• Participar en la reunión de demostración de la iteración, revisando los requisitos completados.

Scrum Master (facilitador)

Lidera al equipo llevando a cabo las siguientes responsabilidades:

• Velar por que todos los participantes del proyecto sigan las reglas y proceso de Scrum, encajándolas en la cultura de la organización, y guiar la colaboración intraequipo y con el cliente de manera que las sinergias sean máximas. Esto implica:
• Asegurar que la lista de requisitos priorizada esté preparada antes de la siguiente iteración.
• Facilitar las reuniones de Scrum (planificación de la iteración, reuniones diarias de sincronización del equipo, demostración, retrospectiva), de manera que sean productivas y consigan sus objetivos.
• Enseñar al equipo a autogestionarse. No da respuestas, si no que guía al equipo con preguntas para que descubra por sí mismo una solución.
• Quitar los impedimentos que el equipo tiene en su camino para conseguir el objetivo de cada iteración (proporcionar un resultado útil al cliente de la manera más efectiva) y poder finalizar el proyecto con éxito. Estos obstáculos se identifican de manera sistemática en las reuniones y en las reuniones de retrospectiva.
• Proteger y aislar al equipo de interrupciones externas durante la ejecución de la iteración(introducción de nuevos requisitos, "secuestro" no previsto de un miembro del equipo, etc.). De esta manera, el equipo puede mantener su productividad y el compromiso que adquirió sobre los requisitos que completaría en la iteración.

Team (equipo)

Grupo de personas que de manera conjunta desarrollan el producto del proyecto. Tienen un objetivo común, comparten la responsabilidad del trabajo que realizan (así como de sucalidad) en cada iteración y en el proyecto.

El tamaño del equipo está entre 5 y 9 personas. Por debajo de 5 personas cualquier imprevisto o interrupción sobre un miembro del equipo compromete seriamente el compromiso que han adquirido y, por tanto, el resultado que se va a entregar al cliente al finalizar la iteración. Por encima de 9 personas, la comunicación y colaboración entre todos los miembros se hace más difícil y se forma subgrupos (ver los requisitos de Scrum).

De cualquier manera, se puede hacer Scrum con 3 personas y se ha utilizado en proyectos con 250 personas en varios equipos. Cuando es necesario que más de un equipo trabaje de manera ágil en un mismo proyecto, existen diferentes técnicas que permiten esta colaboración, desde el Scrum de Scrums hasta equipos de integración que dedican parte de su tiempo a trabajar con los equipos de desarrollo, siempre completando incrementos de producto de manera regular.

Es un equipo autoorganizado, que comparte información y cuyos miembros confían entre ellos. Realiza de manera conjunta las siguientes actividades:

• Seleccionar los requisitos que se compromete a completar en una iteración, de forma que estén preparados para ser entregados al cliente.
• Estimar la complejidad de cada requisito en la lista de requisitos priorizada del producto o proyecto.
• En la reunión de planificación de la iteración decide cómo va a realizar su trabajo:
• Seleccionar los requisitos que pueden completar en cada iteración, realizando al cliente las preguntas necesarias.
• Identificar todas las tareas necesarias para completar cada requisito.
• Estimar el esfuerzo necesario para realizar cada tarea.
• Cada miembro del equipo se autoasigna a las tareas.
• Durante la iteración, trabajar de manera conjunta para conseguir los objetivos de la iteración. Cada especialista lidera el trabajo en su área y el resto colaboran si es necesario para poder completar un requisito.
• Al finalizar la iteración:
• Demostrar al cliente los requisitos completados en cada iteración.
• Hacer una retrospectiva la final de cada iteración para mejorar de forma continua su manera de trabajar.

Componentes

Pila del producto (Product Backlog)

• Responsable: Product Owner
• Relación de requisitos del producto, no detallados excesivamente
• Priorizados
• Todo el mundo puede añadir elementos pero solo el Product Owner añade prioridades.

Pila del sprint (Sprint Backlog)

• Requisitos comprometidos por el equipo para el sprint.
• Suficientemente detallado para su ejecución

Incremento

• Parte del producto desarrollada en 1 sprint
• En condiciones de ser usada (pruebas, codificación limpia y documentada)

Ventajas 

• Entrega mensual (o quincenal) de resultados (los requisitos más prioritarios en ese momento, ya completados).
• Gestión regular de las expectativas del cliente y basada en resultados tangibles.
• Resultados anticipados (time to market).
• Flexibilidad y adaptación respecto a las necesidades del cliente, cambios en el mercado, etc.
• Gestión sistemática del Retorno de Inversión (ROI).
• Mitigación sistemática de los riesgos del proyecto.
• Productividad y calidad.
• Alineamiento entre el cliente y el equipo de desarrollo.
• Equipo motivado.

Desventajas

• Si no se define una fecha de fin, los stakeholders siempre pedirán nuevas funcionalidades.
• Si una tarea no está bien definida puede incrementar costes y tiempos.
• Si el equipo no se compromete hay mucha probabilidad de fracasar.
• Solo funciona bien en equipos pequeños y ágiles.
• Se requieren miembros del equipo experimentados.
• Solo funciona cuando el Scrum Manager confía en su equipo.
• Que un miembro abandone el equipo durante el desarrollo puede conllevar grandes problemas.

Características

• Enfatiza valores y prácticas de gestión, sin pronunciarse sobre requerimientos, prácticas de desarrollo, implementación y demás cuestiones técnicas
• Hace uso de Equipos auto-dirigidos y auto-organizados
• Puede ser aplicado teóricamente a cualquier contexto en donde un grupo de gente necesita trabajar junta para lograr una meta común.
• Desarrollo de software iterativo incremental basado en prácticas agiles
• Iteraciones de treinta días; aunque se pueden realizar con más frecuencia, estas iteraciones, conocidas como Sprint
• Dentro de cada Sprint se denomina el Scrum Master al Líder de Proyecto quien llevará a cabo la gestión de la iteración
• Se convocan diariamente un “Scrum Daily Meeting” el cual representa una reunión de avance diaria de no más de 15 minutos con el propósito de tener realimentación sobre las tareas de los recursos y los obstáculos que se presentan. En la cual se responden preguntas como: ¿Qué has hecho desde el último encunetro? ¿Qué obstaculos hay para cumplir la meta? ¿Qué haras antes del proximo encuentro?

eXtreme programming

La metodología XP define cuatro variables para cualquier proyecto de software: costo, tiempo, calidad y alcance. Además, se especifica que, de estas cuatro variables, sólo tres de ellas podrán ser fijadas arbitrariamente por actores externos al grupo de desarrolladores (clientes y jefes de proyecto). El valor de la variable restante podrá ser establecido por el equipo de desarrollo, en función de los valores de las otras tres. Este mecanismo indica que, por ejemplo, si el cliente establece el alcance y la calidad, y el jefe de proyecto el precio, el grupo de desarrollo tendrá libertad para determinar el tiempo que durará el proyecto. Este modelo es analizado por Kent Beck, donde propone las ventajas de un contrato con alcances opcionales.

El ciclo de vida de un proyecto XP incluye, al igual que las otras metodologías, entender lo que el cliente necesita, estimar el esfuerzo, crear la solución y entregar el producto final al cliente. Sin embargo, XP propone un ciclo de vida dinámico, donde se admite expresamente que, en muchos casos, los clientes no son capaces de especificar sus requerimientos al comienzo de un proyecto. 

Fase de exploración

Es la fase en la que se define el alcance general del proyecto. En esta fase, el cliente define lo que necesita mediante la redacción de sencillas “historias de usuarios”. Los programadores estiman los tiempos de desarrollo en base a esta información. Debe quedar claro que las estimaciones realizadas en esta fase son primarias (ya que estarán basadas en datos de muy alto nivel), y podrían variar cuando se analicen más en detalle en cada iteración. Esta fase dura típicamente un par de semanas, y el resultado es una visión general del sistema, y un plazo total estimado.

Fase de planificación

La planificación es una fase corta, en la que el cliente, los gerentes y el grupo de desarrolladores acuerdan el orden en que deberán implementarse las historias de usuario, y, asociadas a éstas, las entregas. Típicamente esta fase consiste en una o varias reuniones grupales de planificación. El resultado de esta fase es un Plan de Entregas, o “Release Plan”, como se detallará en la sección “Reglas y Practicas”.

Fase de iteraciones

Esta es la fase principal en el ciclo de desarrollo de XP. Las funcionalidades son desarrolladas en esta fase, generando al final de cada una un entregable funcional que implementa las historias de usuario asignadas a la iteración. Como las historias de usuario no tienen suficiente detalle como para permitir su análisis y desarrollo, al principio de cada iteración se realizan las tareas necesarias de análisis, recabando con el cliente todos los datos que sean necesarios. El cliente, por lo tanto, también debe participar activamente durante esta fase del ciclo. Las iteraciones son también utilizadas para medir el progreso del proyecto. Una iteración terminada sin errores es una medida clara de avance. 

Fase de puesta en producción

Si bien al final de cada iteración se entregan módulos funcionales y sin errores, puede ser deseable por parte del cliente no poner el sistema en producción hasta tanto no se tenga la funcionalidad completa. En esta fase no se realizan más desarrollos funcionales, pero pueden ser necesarias tareas de ajuste (“fine tuning”).  

Roles 

Programador

• Pieza básica en desarrollos XP
• Más responsabilidad que en otros modos de desarrollo
• Responsable sobre el código
• Responsable sobre el diseño (refactorización, simplicidad)
• Responsable sobre la integridad del sistema (pruebas)
• Capacidad de comunicación
• Acepta críticas (código colectivo)

Cliente

• Pieza básica en desarrollos XP
• Define especificaciones
• Influye sin controlar
• Confía en el grupo de desarrollo
• Define pruebas funcionales

Encargado de Pruebas

• Apoya al cliente en la preparación/realización de las pruebas funcionales
• Ejecuta las pruebas funcionales y publica los resultados

   

Encargado de Seguimiento (Tracker)

• Recoge, analiza y publica información sobre la marcha del proyecto sin afectar demasiado el proceso
• Supervisa el cumplimiento de las estimaciones en cada iteración
• Informa sobre la marcha de la iteración en curso
• Controla la marcha de las pruebas funcionales, de los errores reportados, de las responsabilidades aceptadas y de las pruebas añadidas por los errores encontrados

Entrenador (Coach)

• Experto en XP
• Responsable del proceso en su conjunto
• Identifica las desviaciones y reclama atención sobre las mismas
• Guía al grupo de forma indirecta (sin dañar su seguridad ni confianza)
• Interviene directamente si es necesario
• Atajar rápidamente el problema

Consultor

• Apoya al equipo XP en cuestiones puntuales

Jefe del Proyecto

• Favorece la relación entre usuarios y desarrolladores
• Confía en el equipo XP
• Cubre las necesidades del equipo XP
• Asegura que alcanza sus objetivos

Objetivos

• Establecer las mejores prácticas de Ingeniería de Software en los desarrollo de proyectos.
• Mejorar la productividad de los proyectos.
• Garantizar la Calidad del Software desarrollando, haciendo que este supere las expectativas del cliente.

Ventajas

• Programación organizada.
• Menor taza de errores.
• Satisfacción del programador.

Desventajas

• Es recomendable emplearlo solo en proyectos a corto plazo.
• Altas comisiones en caso de fallar.

Características

• Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.
• Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación.
• Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe es más importante que la posible pérdida de productividad inmediata.
• Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
• Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
• Refactorización del código, es decir, rescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
• Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
• Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.
• La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.

Cascada

El modelo de la cascada es uno de los primeros modelos empleados en el desarrollo de software, se popularizo en 1970 por Winston Royce y aún está vigente en algunos desarrollos. Éste modelo se define como una secuencia de actividades a ser seguidas en orden, donde la estrategia principal es definir y seguir el progreso del desarrollo de software hacia puntos de revisión bien definidos, es decir, se codifica y reparan los errores; es un proceso continuo de codificación y reparación.

Sus características principales son:

• Es lineal
• Las actividades están relacionadas secuencialmente.
• Cada etapa tiene una entrada y una salida.
• Es rígido y sistemático: La entrada de una actividad es la salida de la etapa anterior, por lo cual no se puede dar inicio a la siguiente fase.
• Es monolítico: Existe una única fecha de entrega.
• La implementación se pospone hasta que no se comprendan los objetivos.
• Los documentos a entregar rigen el proceso de software.
• Las fases que contempla el modelo de la cascada son al Análisis y especificación de requerimientos, diseño, codificación, integración y pruebas, liberación y mantenimiento.

Su ciclo de vida abarca las siguientes actividades:

• Análisis de requisitos.
• Diseño del Sistema.
• Codificación.
• Pruebas.
• Verificación.
• Mantenimiento.

Ingeniería y Análisis del Sistema

Debido a que el software es siempre parte de un sistema mayor el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software.

Análisis de los requisitos del software

El proceso de recopilación de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software debe comprender el ámbito de la información del software así como la función, el rendimiento y las interfaces requeridas.

Diseño

Si diseño del software se enfoca en cuatro atributos distintos del programa; la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz. El proceso de diseño traduce los requisitos en una representación del software con la calidad requerida antes de que comience la codificación.

Codificación

El diseño debe traducirse en una forma legible para la maquina. Si el diseño se realiza de una manera detallada, la codificación puede realizarse mecánicamente.

Prueba

Una vez que se ha generado el código comienza la prueba del programa. La prueba se centra en la lógica interna del software y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren.

Mantenimiento

El software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debidos a que se haya encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos) o a que el cliente requiera ampliaciones funcionales o del rendimiento.

Ventajas

• Sencillez.
• Se tiene todo bien organizado y no se mezclan las fases.
• Ayuda a localizar errores en las primeras etapas del proyecto a un bajo costo.
• Ayuda a minimizar los gastos de la planificación porque permite realizarla sin planificación porque permite realizarla sin problemas.
• La calidad del producto resultante es alta.

Desventajas

• Gran dependencia en los requerimientos iníciales.
• Difícilmente un cliente va a establecer al principio todos los requerimientos necesarios, por lo que provoca un gran atraso trabajando en este modelo, ya que este es muy restrictivo y no permite movilizarse entre fases.
• El modelo genera pocos signos visibles de progreso hasta el final. Esto puede dar la impresión de un desarrollo lento, existe la incertidumbre de los clientes si sus proyectos serán entregados a tiempo.
• Inicio de la codificación muy tarde en el ciclo de vida del proyecto.
• Es difícil incorporar nuevas cosas si se quiere actualizar

Características

• Es el más utilizado.
• Es una visión del proceso de desarrollo de software como una sucesión de etapas que produce productos intermedios.
• Si se cambia el orden de las fases, el producto final será de inferior calidad.
• Las actividades están relacionadas secuencialmente.

El modelo en cascada puede ser apropiado, en general, para proyectos estables (especialmente los proyectos con requisitos no cambiantes) y donde es posible y probable que los diseñadores predigan totalmente áreas de problema del sistema y produzcan un diseño correcto antes de que empiece la implementación.

Funciona bien para proyectos pequeños donde los requisitos están bien entendidos.

Es un modelo en el que todo está bien organizado y no se mezclan las fases. Es simple y fácil de usar.

Debido a la rigidez del modelo es fácil de gestionar ya que cada fase tiene entregables

Incremental

El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el enfoque incremental de desarrollo como una forma de reducir la repetición 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.

Este modelo se conoce también bajo las siguientes denominaciones:

• Método de las comparaciones limitadas sucesivas.
• Ciencia de salir del paso.
• Método de atacar el problema por ramas.

El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofía interactiva de Construcción de Prototipos. El modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. El primer incremento generalmente es un producto esencial denominado núcleo.

En una visión genérica, el proceso se divide en 4 partes:

• Análisis
• Diseño
• Código
• Prueba

El Modelo Incremental es de naturaleza interactiva brindando al final de cada incremento la entrega de un producto completamente operacional. 

Este modelo es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añadirá personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.

Durante el proceso se trata de llevar a cabo al proyecto en diferentes partes que al final terminará siendo la solución completa requerida por el cliente, pero éstas partes no se pueden realizar en cualquier orden, sino que dependen de lo que el cliente este necesitando con más urgencia, de los puntos más importantes del proyecto, los requerimientos más básicos, difíciles y con mayor grado de riesgo, ya que estos se deben hacer al comienzo, de manera que se disminuya la dificultad y el riesgo en cada versión.

De este modo podemos terminar una aplicación ejecutable (primera versión) que podrá ser entregada al cliente para que éste pueda trabajar en ella y el programador pueda considerar las recomendaciones que el cliente efectúe para hacer mejoras en el producto. Estas nuevas mejoras deberán esperar a ser integradas en la siguiente versión junto con los demás requerimientos que no fueron tomados en cuenta en la versión anterior.

El modelo incremental consiste en un desarrollo inicial de la arquitectura completa del sistema, seguido de sucesivos incrementos funcionales. Cada incremento tiene su propio ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad ni sus interfaces. Una vez entregado un incremento, no se realizan cambios sobre el mismo, sino únicamente corrección de errores. Dado que la arquitectura completa se desarrolla en la etapa inicial, es necesario conocer los requerimientos completos al comienzo del desarrollo.

Al iniciar del desarrollo, los clientes o los usuarios, identifican a grandes rasgos, las funcionalidades que proporcionará el sistema. Se confecciona un bosquejo de requisitos funcionales y será el cliente quien se encarga de priorizar que funcionalidades son más importantes. Con las funcionalidades priorizadas, se puede confeccionar un plan de incrementos, donde en cada incremento se indica un subconjunto de funcionalidades que el sistema entregará. La asignación de funcionalidades a los incrementos depende de la prioridad dada a los requisitos. Finalizado el plan de incrementos, se puede comenzar con el primer incremento.

Ventajas

• Los clientes no tienen que esperar hasta que el sistema se entregue completamente para comenzar a hacer uso de él.
• Los clientes pueden usar los incrementos iniciales como prototipo para precisarlos requerimientos posteriores del sistema.
• Minimización del riesgo de falla en el proyecto porque los errores se van corrigiendo progresivamente.
• El resultado puede ser muy positivo.

Desventajas

• Difícil de aplicar a sistemas transaccionales que tienden a ser integrados y a operar como un todo.
• Riesgos largos y complejos.
• Pueden aumentar el coste debido a las pruebas.
• Los errores en los requisitos se detectan tarde. 

Características

• Cada incremento agrega funcionalidad adicional o mejorada sobre el sistema.
• Cada etapa debe cumplir con los requisitos de las desarrolladas.
• La propuesta del modelo es diseñar sistemas que puedan entregarse por piezas.
• A partir de la evaluación se planea el siguiente incremento y así sucesivamente.
• Es interactivo por naturaleza.
• Es útil cuando el personal no es suficiente para la implementación completa.
• En lugar de entrega del sistema en una sola entrega, el desarrollo y la entrega están fracturados bajo incrementos, con cada incremento que entrega parte dela funcionalidad requerida.
• Los requerimientos del usuario se priorizan y los requerimientos de prioridad más altos son incluidos en los incrementos tempranos.
• Hechos de incrementos tempranos como un prototipo, ayudan a obtener requisitos para los incrementos más tardíos.
• Los usuarios no tiene que esperar.
• El desarrollo incremental es el proceso de construcción siempre incrementando subconjuntos de requerimientos del sistema.
• Se evitan proyectos largos y se entrega “Algo de valor” a los usuarios con cierta frecuencia.
• El usuario se involucra más.
• Requiere gestores experimentados.