UNIDAD II:

METODOLOGÍAS DE DESARROLLO

El concepto de metodología, dentro de la Ingeniería del Software es, sin duda, uno de los temas más oscuros y que más confusión produce tanto en estudiantes como en profesionales involucrados en procesos de desarrollo de software.

Tanto es así, que en muchos proyectos de desarrollo, la aplicación de una metodología brilla por su ausencia, siendo éste un concepto casi desconocido.

Además, la constante innovación tecnológica hace que cada vez sea necesaria la aplicación de nuevas metodologías adaptadas a los nuevos tiempos y, sin embargo, siguen figurando en los libros de texto viejas metodologías pensadas para viejos problemas... cosa que no sería necesariamente mala si las nuevas metodologías tuviesen también su lugar... pero a menudo no es así.

Y no es que haya una metodología claramente superior a las demás. Todas las metodologías son, en esencia, bienintencionadas. Obviamente, las más modernas responden a problemas y necesidades más actuales.

Afortunadamente, los tiempos van cambiando. La informática va madurando y tanto algunos profesionales de las tecnologías de la información como algunos de sus clientes se van dando cuenta de que se hace necesario seguir unas ciertas pautas predefinidas en el desarrollo del software de calidad: es decir, llevar un comportamiento metódico: seguir una metodología.

2.1 Metodologías clásicas

Hay una serie de metodologías que solemos llamar tradicionales o clásicas propuestas casi todas ellas con anterioridad a los años 90 que pretendían ayudar a los profesionales indicando pautas para realizar y documentar cada una de las tareas del desarrollo del software. Sin embargo, tienen casi todas ellas un gran problema: asumen que un proyecto informático es casi una extensión de un proyecto burocrático tradicional. Así pues, los pasos que sugieren para llevar a cabo cada tarea, aunque bienintencionados, están cargados de burocracia, reiteraciones, ambigüedades... No suelen tener en cuenta cosas como la calidad, la satisfacción, la competitividad, los beneficios. Fueron metodologías creadas en los años 70-80 pensando en los negocios de los años 50.

El mundo va ahora mucho más rápido: sólo los negocios inteligentes sobreviven, sólo los proyectos de software inteligentemente construidos lo hacen también. Ahora las comunicaciones son instantáneas, mundiales. La información fluye en tiempo real. Las empresas compiten al segundo.

El software ya tiene una cierta historia. Hemos aprendido mucho. Utilizamos conceptos abstractos para construir sistemas que van mucho más allá de los datos y los algoritmos.

La mayor parte de las metodologías tradicionales ya no funcionan. Están obsoletas desde casi todos los puntos de vista. Sólo algunas metodologías tradicionales han sido revisadas y adaptadas, y su funcionalidad suele estar limitada a proyectos no muy innovadores.

Las metodologías surgidas desde los 90 hasta aquí suelen tener otra mentalidad, una cierta agilidad. Siendo conscientes de lo cambiante y amplio que es el mundo del software, una metodología debe ser lo suficientemente precisa como para que todo el mundo la pueda seguir y sea de utilidad como pauta común, pero también debe ser lo suficientemente adaptable como para poder aplicarse en distintos proyectos, y lo suficientemente sencilla como para que no resulte muy complicada su utilización, pero lo suficientemente completa y compleja como para que la utilización por parte del equipo sea provechosa. Debe ser ágil.

Aunque el término de agilidad es muy discutible, es indudable que las metodologías "modernas" responden a otra mentalidad completamente distinta.

Así a la pregunta de "¿Qué metodología utilizar?"... pues depende:

Si formas parte de un equipo de desarrollo en un proyecto grande y te toca decidir qué metodología hay que utilizar significa que tienes un puesto de responsabilidad. Escoge una metodología moderna, bien definida, que dé respuesta a las necesidades del proyecto.
Si formas parte de un equipo de desarrollo en un proyecto grande y no ocupas un puesto de responsabilidad, no deberías decidir qué metodología utilizar: alguien lo decidirá por ti. Si nadie toma esa decisión, el proyecto en el que estás involucrado está destinado al fracaso.
Si formas parte de un equipo pequeño en un proyecto pequeño, lo mejor es conocer la metodología a utilizar. Incluso, combinar buenas ideas de más de una.

2.1.1 Desarrollo en Cascada

En Ingenieria de software el desarrollo en cascada, también llamado modelo en cascada, es el enfoque metodológico que ordena rigurosamente las etapas del proceso del desarrollo del software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior.

Un ejemplo de una metodología de desarrollo en cascada es:

1. Análisis de requisitos.

2. Diseño del Sistema.

3. Diseño del Programa.

4. Codificación.

5. Pruebas.

6. Implantación.

7. Mantenimiento.

De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto.

Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy.

Fases del modelo:

Análisis de requisitos

En esta fase se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (documento de especificación de requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos.

Diseño del Sistema

Descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura relacional global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras.

Diseño del Programa

Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber que herramientas usar en la etapa de Codificación.

Codificación

Es la fase en donde se implementa el codigo fuente , haciendo uso de prototipos así como de pruebas y ensayos para corregir errores.

Pruebas

Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona correctamente y que cumple con los requisitos, antes de ser entregado al usuario final.

Verificación

Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no falle.

En la creación de desarrollo de cascada se implementa los códigos de investigación y pruebas del mismo.

Mantenimiento

Una de las etapas más críticas, ya que se destina un 75% de los recursos, es el mantenimiento del Software ya que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas.

Ventajas:

• Es un modelo sencillo y disciplinado
• Es fácil aprender a utilizarlo y comprender su funcionamiento
• Está dirigido por los tipos de documentos y resultados que deben obtenerse al final de cada etapa
• Ha sido muy usado y, por tanto, está ampliamente contrastado
• Ayuda a detectar errores en las primeras etapas a bajo costo
• Ayuda a minimizar los gastos de planificación, pues se realiza sin problemas

Desventajas:
• Los proyectos raramente siguen el proceso lineal tal como se definía originalmente el ciclo de vida
• Es difícil que el cliente exponga explícitamente todos los requisitos al principio
• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida
• No refleja exactamente cómo se programa realmente el sistema, en el que suele haber un gran componente iterativo
• Puede resultar complicado regresar a etapas anteriores (ya acabadas) para realizar correcciones
• El producto final obtenido puede que no refleje todos los requisitos del usuario

2.1.2 Desarrollo Incremental

El Modelo Incremental combina elementos del MLS con la filosofía interactiva de construcción de prototipos.

En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o “Pipeline”, utilizado en muchas otras formas de programación. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento.

Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo.

De esta forma el tiempo de entrega se reduce considerablemente.

Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional.

El Modelo Incremental 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.

El Modelo Incremental se puede ver de la sig manera :

-Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia.

- El usuario se involucra más.

- Difícil de evaluar el coste total.

- Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.

- Requiere gestores experimentados.

- Los errores en los requisitos se detectan tarde.

- El resultado puede ser muy positivo.

Pipeline

La arquitectura en pipeline (basada en filtros) consiste en ir transformando un flujo de datos en un proceso comprendido por varias fases secuenciales, siendo la entrada de cada una la salida de la anterior.

Esta arquitectura es muy común en el desarrollo de programas para el intérprete de comandos, ya que se pueden concatenar comandos fácilmente con tuberías (pipe).

También es una arquitectura muy natural en el paradigma de programación funcional, ya que equivale a la composición de funciones matemáticas.

Interprete de comandos

Parte fundamental de un sistema operativo que ordena la ejecución de mandatos obtenidos del usuario por medio de una interfaz alfanumérica.

Características

-Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con cierta frecuencia.

- El usuario se involucre más.

- Difícil de evaluar el costo total.

- Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.

- Requiere gestores experimentados.

- Los errores en los requisitos se detectan tarde.

- El resultado puede ser muy positivo.

Ventajas:

-Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial.

-También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software.

-El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas sólo al ámbito de cada incremento.

-Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.

- Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.

- Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como técnico.

Desventajas:

-El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.

- Requiere de mucha planeación, tanto administrativa como técnica.

- Requiere de metas claras para conocer el estado del proyecto.

2.1.3 Desarrollo Evolutivo

Un modelo de desarrollo es una representación abstracta de un proceso de software, cada modelo representa el proceso de desarrollo de software de una manera en particular. A pesar de estar definidos claramente, no representan necesariamente la realidad de cómo se debe desarrollar el software, sino que establece un enfoque común. Un modelo puede ser modificado y adaptado de acuerdo a las necesidades del software en desarrollo.

Desarrollo Evolutivo

El desarrollo evolutivo consta del desarrollo de una versión inicial que luego de exponerse se va refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o del usuario final. Las fases de especificación, desarrollo y validación se entrelazan en vez de separarse.

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 definición mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden del todo.

Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele traer más ventajas en comparación con un enfoque en cascada ya que el sistema se va ajustando a las necesidades del cliente, a la vez que él mismo entiende mejor sus propios requerimientos. Sin embargo el enfoque evolutivo desde una perspectiva de ingeniería y gestión suele tener dos grandes problemas:

1. El proceso no es visible. Los administradores tienen que hacer entregas regulares para medir el progreso. Si los sistemas se desarrollan rápidamente, no es rentable producir documentos que reflejen cada versión 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 más en una tarea difícil y costosa.

Aunque supone grandes ventajas el desarrollo evolutivo solo es recomendado para sistemas pequeños y medianos. En los sistemas grandes, los constantes cambios en el desarrollo solo dificultan la estabilidad y la integración de los avances de los distintos grupos de trabajo que puedan existir. La mayoría de las empresas que desarrollan grandes sistemas usan un modelo mixto que usa las mayores fortalezas de los enfoques evolutivos y de cascada.

2.1.4 Desarrollo en Espiral

El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1986,utilizado generalmente en la ingenieria de software. Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteracion representa un conjunto de actividades. Las actividades no están fijadas a ninguna prioridad, sino que las siguientes se eligen en función del analisis de riesgo, comenzando por el bucle interior.

Boehm, autor de diversos artículos de ingeniería del software; modelos de estimación de esfuerzo y tiempo que se consume en hacer productos software; y Modelos de Ciclo de Vida; ideó y promulgó un modelo desde un enfoque distinto al tradicional en Cascada: El Modelo Evolutivo Espiral. Su Modelo de Ciclo de Vida en Espiral tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgo más asumible y se hace un ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelve a evaluar las distintas nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, así hasta que llegue un momento en el que el producto software desarrollado sea aceptado y no necesite seguir mejorándose con otro nuevo ciclo.

Ciclos o Iteraciones:

En cada vuelta o iteración hay que tener en cuenta:

· Los Objetivos: qué necesidad debe cubrir el producto.

· Alternativas: las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista como pueden ser:

1. Características: experiencia del personal, requisitos a cumplir, etc.

2. Formas de gestión del sistema.

3. Riesgo asumido con cada alternativa.

· Desarrollar y Verificar: Programar y probar el software.

Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades:

· Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones, la radial y la angular:

1. Angular: Indica el avance del proyecto del software dentro de un ciclo.

2. Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteración se pasa más tiempo desarrollando.

Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la creación de un Sistema Operativo.

Al ser un modelo de Ciclo de Vida orientado a la gestión de riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente los riesgos.

Tareas

Para cada ciclo habrá cuatro actividades:

1. Determinar Objetivos.

2. Análisis del riesgo.

3. Planificación.

4. Desarrollar y probar.

Determinar o fijar objetivos

· Fijar también los productos definidos a obtener: requerimientos, especificación, manual de usuario.

· Fijar las restricciones.

· Identificación de riesgos del proyecto y estrategias alternativas para evitarlos.

· Hay una cosa que solo se hace una vez: planificación inicial.

Análisis del riesgo

· Se lleva a cabo el estudio de las causas de las posibles amenazas y probables eventos no deseados y los daños y consecuencias que éstas puedan producir.

Planificar

· Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad.

Desarrollar, verificar y validar (probar)

· Tareas de la actividad propia y de prueba.

· Análisis de alternativas e identificación resolución de riesgos.

· Dependiendo del resultado de la evaluación de los riesgos, se elige un modelo para el desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. Así si por ejemplo si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. Si lo riesgos de protección son la principal consideración, un desarrollo basado en transformaciones formales podría ser el más apropiado.

Mecanismos de control

· La dimensión radial mide el coste.

· La dimensión angular mide el grado de avance del proyecto.

Ventajas

El análisis del riesgo se hace de forma explícita y clara. Une los mejores elementos de los restantes modelos.

· Reduce riesgos del proyecto

· Incorpora objetivos de calidad

· Integra el desarrollo con el mantenimiento, etc.

Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodología, ya que este ciclo de vida no es rígido ni estático.

Desventajas

· Genera mucho tiempo en el desarrollo del sistema

· Modelo costoso

· Requiere experiencia en la identificación de riesgos

Inconvenientes

Planificar un proyecto con esta metodología es a menudo imposible, debido a la incertidumbre en el número de iteraciones que serán necesarias. En este contexto la evaluación de riesgos es de la mayor importancia y, para grandes proyectos, dicha evaluación requiere la intervención de profesionales de gran experiencia.

2.1.5 Desarrollo de Prototipos

El Modelo de prototipos, en Ingenieria de software, pertenece a los modelos de desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar muchos recursos.

El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La interacción ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

Etapas

· Plan rápido

· Modelado, diseño rápido

· Construcción del Prototipo

· Desarrollo, entrega y retroalimentación

· Comunicación

Ventajas

· Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.

· También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.

La construcción de prototipos se puede utilizar como un modelo del proceso independiente, se emplea más comúnmente como una técnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos. Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos. De esta manera, este ciclo de vida en particular, involucra al cliente más profundamente para adquirir el producto.

Inconvenientes

· El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado.

· En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final...

Conclusiones

A pesar de que tal vez surjan problemas, la construcción de prototipos puede ser un paradigma efectivo para la ingeniería del software. La clave es definir las reglas del juego desde el principio; es decir, el cliente y el desarrollador se deben poner de acuerdo en:

· Que el prototipo se construya y sirva como un mecanismo para la definición de requisitos.

· Que el prototipo se descarte, al menos en parte.

Que después se desarrolle el software real con un enfoque hacia la calidad.

2.1.6 Desarrollo basado en componentes

La complejidad de los sistemas computacionales actuales nos ha llevado a buscar la reutilización del software existente. El desarrollo de software basado en componentes permite reutilizar piezas de código pre elaborado que permiten realizar diversas tareas, conllevando a diversos beneficios como las mejoras a la calidad, la reducción del ciclo de desarrollo y el mayor retorno sobre la inversión. Al comparar la evolución del ambiente de IT con el crecimiento de las metrópolis actuales, podemos entender el origen de muchos problemas que se han presentado históricamente en la construcción de software y vislumbrar las posibles y probables soluciones que nos llevarán hacia la industrialización del software moderno.

Este proceso de industrialización ha dado ya sus inicios con implementaciones como la plataforma .net, la cual impulsa la idea de industrializar el software utilizando tecnologías de componentes. Los avances y mejoras presentados en esta plataforma van mucho más allá de las implementaciones iniciales como COM y CORBA, convirtiendo a los componentes .net en verdaderas piezas de ensamblaje, en un estilo muy similar a las líneas de ensamblaje modernas. Asimismo, los nuevos paradigmas como las Fábricas de Software proveen de los medios para hacer la transición desde el 'hacer a mano' hacia la fabricación o manufactura de software.

Si hay algo que ha aprendido el ser humano desde tiempos muy antiguos es a reutilizar el conocimiento existente para sus cada vez más ambiciosas empresas. En efecto, al reutilizar trozos de experiencias, ideas y artefactos, no solo nos aseguramos de no cometer los mismos errores del pasado, sino que logramos construir cosas cada vez más grandes y maravillosas, con bases firmes y calidad incomparable. Este concepto de la reutilización, uno de los primeros que se nos enseñan a quienes entramos al mundo del desarrollo de software, habremos de utilizarlo desde el mismo instante en que escribamos nuestra primera línea de código.

Los sistemas de hoy en día son cada vez más complejos, deben ser construidos en tiempo récord y deben cumplir con los estándares más altos de calidad. Para hacer frente a esto, se concibió y perfeccionó lo que hoy conocemos como Ingeniería de Software Basada en Componentes (ISBC), la cual se centra en el diseño y construcción de sistemas computacionales que utilizan componentes de software reutilizables. Esta ciencia trabaja bajo la filosofía de "comprar, no construir", una idea que ya es común en casi todas las industrias existentes, pero relativamente nueva en lo que a la construcción de software se refiere.

Para este momento, ya muchos conocen las ventajas de este enfoque de desarrollo y, de la misma forma, muchos se preguntan día a día el por qué son tan pocos los que realmente alcanzan el éxito siguiendo esta filosofía. En realidad, hasta ahora solo hemos tanteado un poco con las posibilidades del software basado en componentes, y es justo hora, en la presente década, que la industria del software despegará y se perfeccionará para estar a la par de cualquier otra industria del medio. Las analogías que nos han llevado a estudiar a los sistemas comparándolos con las complejas metrópolis de la actualidad, así como las iniciativas más innovadoras como las Fábricas de Software de Microsoft, son la clara representación de que estamos a punto de presenciar un nuevo gran cambio en la forma como pensamos en software.

2. Beneficios del Desarrollo de Software basado en Componentes

En esencia, un componente es una pieza de código pre elaborado que encapsula alguna funcionalidad expuesta a través de interfaces estándar. Los componentes son los "ingredientes de las aplicaciones", que se juntan y combinan para llevar a cabo una tarea. Es algo muy similar a lo que podemos observar en el equipo de música que tenemos en nuestra sala. Cada componente de aquel aparato ha sido diseñado para acoplarse perfectamente con sus pares, las conexiones son estándar y el protocolo de comunicación está ya preestablecido. Al unirse las partes, obtenemos música para nuestros oídos.

El paradigma de ensamblar componentes y escribir código para hacer que estos componentes funcionen se conoce como Desarrollo de Software Basado en Componentes. El uso de este paradigma posee algunas 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 desarrollador 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.

De la misma manera, el optar por comprar componentes de terceros en lugar de desarrollarlos, posee algunas ventajas:

Ciclos de desarrollo más cortos. La adición de una pieza dada de funcionalidad tomará días en lugar de meses ó años.
Mejor ROI. Usando correctamente esta estrategia, el retorno sobre la inversión puede ser más favorable que desarrollando los componentes uno mismo.
Funcionalidad mejorada. Para usar un componente que contenga una pieza de funcionalidad, solo se necesita entender su naturaleza, más no sus detalles internos. Así, una funcionalidad que sería impráctica de implementar en la empresa, se vuelve ahora completamente asequible.

2.2 OTRAS METODOLOGÍAS

2.2.1Ganar-ganar (Win & Win)

Una variante interesante del Modelo Espiral previamente visto es el «Modelo espiral Win-Win»^. El Modelo Espiral previo (clásico) sugiere la comunicación con el cliente para fijar los requisitos, en que simplemente se pregunta al cliente qué necesita y él proporciona la información para continuar; pero esto es en un contexto ideal que rara vez ocurre. Normalmente cliente y desarrollador entran en una negociación, se negocia coste frente a funcionalidad, rendimiento, calidad, etc.
«Es así que la obtención de requisitos requiere una negociación, que tiene éxito cuando ambas partes ganan».
Las mejores negociaciones se fuerzan en obtener «Victoria & Victoria» (Win & Win), es decir que el cliente gane obteniendo el producto que lo satisfaga, y el desarrollador también gane consiguiendo presupuesto y fecha de entrega realista. Evidentemente, este modelo requiere fuertes habilidades de negociación.
El modelo Win-Win define un conjunto de actividades de negociación al principio de cada paso alrededor de la espiral; se definen las siguientes actividades:

Identificación del sistema o subsistemas clave de los directivos(*) (saber qué quieren).
Determinación de «condiciones de victoria» de los directivos (saber qué necesitan y los satisface)
Negociación de las condiciones «victoria» de los directivos para obtener condiciones «Victoria & Victoria» (negociar para que ambos ganen).

Directivo: Cliente escogido con interés directo en el producto, que puede ser premiado por la organización si tiene éxito o criticado si no.
El modelo Win & Win hace énfasis en la negociación inicial, también introduce 3 hitos en el proceso llamados «puntos de fijación», que ayudan a establecer la completitud de un ciclo de la espiral, y proporcionan hitos de decisión antes de continuar el proyecto de desarrollo del software.

2.2.2 Proceso Unificado (UP)

El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado Rational o simplemente RUP.
El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma forma, el Proceso Unificado de Rational, también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.
El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes. También permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El primer libro sobre el tema se denominó, en su versión española, El Proceso Unificado de Desarrollo de Software y fue publicado en 1999 por Ivar Jacobson,Grady Booch y James Rumbaugh, conocidos también por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no están afiliados a Rational utilizan el término Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational.

Características

Iterativo e Incremental

El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio puede incluir varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que añade o mejora las funcionalidades del sistema en desarrollo.

Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clásico o en cascada: Análisis de requisitos, Diseño, Implementación y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto.

Dirigido por los casos de uso

En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteración tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a través de las distintas disciplinas: diseño, implementación, prueba, etc. el proceso dirigido por casos de uso es el rup.

Centrado en la arquitectura

El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del sistema. Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura de software de un sistema. La analogía con la construcción es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanería, etc.

Enfocado en los riesgos

El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos críticos en una etapa temprana del ciclo de vida. Los resultados de cada iteración, en especial los de la fase de Elaboración deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero.

2.2.3 Ingeniería Web

La ingeniería web es la aplicación de metodologías sistemáticas, disciplinadas y cuantificables al desarrollo eficiente, operación y evolución de aplicaciones de alta calidad en la World Wide Web.
La ingeniería web se debe al crecimiento desenfrenado que está teniendo la Web está ocasionando un impacto en la sociedad y el nuevo manejo que se le está dando a la informacion en las diferentes áreas en que se presenta ha hecho que las personas tiendan a realizar todas sus actividades por esta vía.
Desde que esto empezó a suceder el internet se volvió más que una diversión y empezó a ser tomado más en serio, ya que el aumento de publicaciones y de informaciones hizo que la Web se volviera como un desafío para los (Ingenieria de Software ) ingenieros del software, a raíz de esto se crearon enfoques disciplinados, sistemáticos y metodologías
Para garantizar el buen funcionamiento y mantenimiento de los sitios web, este debe contar con ciertos atributos y características que en conjunto forman un concepto muy importante, para alcanzar el éxito en cualquier organización, herramienta, y todo aquello que se pueda considerar como servicio. Dicho concepto es la calidad, que con atributos como, usabilidad, navegabilidad, seguridad, mantenibilidad, entre otros, hace posible por un lado la eficiencia del artefacto web y por ende la satisfacción del usuario final.
Pero para tener artefactos de calidad, a esa misma se le debe planificar, programar y controlar, es decir la calidad no podrá ser agregada a un artefacto web o a cualquier otro producto, al final del proceso de desarrollo, si no que se deberá implementar durante todo el ciclo de vida del desarrollo. Para finalizar el resultado de un proceso de calidad, podría arrojar recomendaciones para introducir mejoras, y la decisión final podría consistir en lanzar una nueva versión del sitio web o en modificar algunos atributos ausentes o pobremente diseñados. Cabe destacar que la ingeniería de la web hace una diferencia entre un Web Site y una aplicación, ya que la ingeniería de la web no se dedica a la construcción de sitios web si no a la construcción de aplicaciones web la principal característica que los distingue (aplicaciones de sitios web) es que los sitios web son sitios en la web en donde se publica contenido generalmente estático o un muy bajo nivel de interactividad con el Usuario, mientras que las aplicaciones son lugares con alto contenido de interactividad y funcionalidades que bien podrían ser de un software convencional, la aplicación web más sencillo seria uno que contenga formularios y subiendo de nivel encontramos los que realizas conexión con bases de datos remotas, y administradores de contenidos entre otras.
Entonces la ingeniería de la Web es la aplicación de metodologías sistemáticas, disciplinadas y cuantificables al desarrollo eficiente, operación y evolución de aplicaciones de alta calidad en laWorld Wide Web. En este sentido, la ingeniería de la Web hace referencia a las metodologías, técnicas y herramientas que se utilizan en el desarrollo de aplicaciones Web complejas y de gran dimensión en las que se apoya la evaluación, diseño, desarrollo, implementación y evolución de dichas aplicaciones.

Áreas

El desarrollo de aplicaciones Web posee determinadas características que lo hacen diferente del desarrollo de aplicaciones o software tradicional y sistemas de informacion. La ingeniería de la Web es multidisciplinar y aglutina contribuciones de diferentes áreas: arquitectura de la informacion, ingeniería de hipermedia/hipertexto, ingeniería de requisitos, diseño de interface de ususario, usabilidad, diseño grafico y de presentación, diseño y analisis de sistemas, ingenieria de software ingeniería de datos, indexado y recuperación de información, testeo, modelado y simulación, despliegue de aplicaciones, operación de sistemas y gestion de proyectos
La ingeniería de la Web no es un clon o subconjunto de la ingeniería de software aunque ambas incluyen desarrollo de software y programacion, pues a pesar de que la ingeniería de la Web utiliza principios de ingeniería de software, incluye nuevos enfoques, metodologias, herramientas, técnicas, guías y patrones para cubrir los requisitos únicos de las aplicaciones web
Los principales aspectos de la ingeniería de la Web incluyen, entre otros, los siguientes temas:

Diseño de procesos de negocio para aplicaciones web.
Herramientas CASE para aplicaciones web.
Generación de codigo para aplicaciones web.
Desarrollo web colaborativo.
Modelado conceptual de aplicaciones web.
Diseño de modelos de datos para sistemas de información web.
Ingeniería web empírica.
Entornos de desarrollo de aplicaciones web integrados.
Herramientas de autor para contenido multimedia.
Pruebas de rendimiento de aplicaciones basadas en web.
Personalización y adaptación de aplicaciones web.
Herramientas y métodos de prototipado.
Control de calidad y pruebas de sistemas.
Ingeniería de requisitos para aplicaciones web.
Aplicaciones para la web semantica
Factorías de software para la web.
Métodos, herramientas y automatización de pruebas para aplicaciones web.
Aplicaciones web móviles y ubícuas.
Usabilidad de aplicaciones web.
Accesibilidad para la web.
Metodologías de diseño web
Formación en ingeniería de la web.
Diseño de interfaces de ususarios
Métricas para la web, estimación de costes y medición.
Gestión de proyectos web y gestión de riesgos.
Desarrollo y despliegue de servicios web.

Categorías

Los sitios web pueden ser categorizados de la siguiente forma:

Sólo estático que se enfoca en la organización de la estructura y el contenido, en la forma como se va a presentar la información y que sea fácil de manejar para cualquier usuario, pero debe tener en cuenta la eficiencia y la confiabilidad.
Sitio estático con formularios de entrada este sitio tiene las mismas características que el anterior, adicionándole que el le permite a los usuarios la interacción por medio de cuestionarios, comentario y sugerencias.
Sitio con acceso de datos dinámicos aquí, además de las características antes mencionadas, cuenta con bases de datos en las cuales el usuario puede realizar consultas y búsquedas.
Sitio creado dinámicamente en este sitio los requerimientos son parecidos pero deben suplir con las necesidades de cada usuario; creando sitios dinámicos que sean compatibles con el entorno de navegación de cada usuario.
Aplicación de software basada en la Web este sitio puede tener todas las características antes mencionadas, pero logrando un parecido con una implementación cliente/servidor comúnmente conocido que a un sitio web estático.

Todas estas consideraciones nos llevan a la conclusión de que un sitio web bien logrado no es únicamente un espacio en la red para ver el mismo comercial que en television; es en realidad una extensión de las empresas o instituciones, así mismo teniendo en cuenta la importancia y aplicabilidad que tiene la ingeniería Web en nuestro desarrollo cognitivo, social y vivencial es fácil visionar que cada una de las funciones que ella emana estarán siempre ligadas a la vanguardia del desarrollo progresivo de la tecnología y del hombre.

Naturaleza multidisciplinaria

La ingenieria de software, incluye nuevas metodologías de desarrollo esenciales para la administración de proyectos. Actualmente la ingeniería web ha adoptado también metodologías de la ingeniería del software y ha creado muchas nuevas. Debido a que la información es publicada para conocimiento de todo el mundo, hay que tener muy en cuenta aspectos sociales, jurídicos y eticos que pueden influir a la hora de la publicación. De acuerdo con esto, la ingeniería Web puede utilizar una parte de cada una de estas disciplinas y no ser dominada por puntos de vista muy particulares, es una respuesta de carácter multidisciplinario para las aplicaciones Web.
Usualmente, las aplicaciones web son multidisciplinares, ya que son construidas en un medio constantemente cambiante, donde los requerimientos son inestables, los equipos de desarrollo generalmente son pequeños, las comunidades de usuarios son más amplias que antes y la competición ahora es a nivel mundial. En general, las aplicaciones web, necesitan ser funcionales, mantenibles, escalables y seguras. Como podemos ver, la actual demanda de las aplicaciones web es totalmente diferente de las aplicaciones convencionales y por lo tanto hay una gran necesidad de la ingeniería web.

2.2.4 Metodologías Ágiles

Luego de varias opiniones tanto a favor como en contra de las metodologías tradicionales se genera un nuevo enfoque denominado, métodos ágiles, que nace como respuesta a los problemas detallados anteriormente y se basa en dos aspectos puntuales, el retrasar las decisiones y la planificación adaptativa; permitiendo potencia aún más el desarrollo de software a gran escala.

Como resultado de esta nueva teoría se crea un Manifiesto Ágil cuyas principales ideas son:

Los individuos y las interacciones entre ellos son más importantes que las herramientas y los procesos empleados.

Es más importante crear un producto software que funcione que escribir documentación exhaustiva.
La colaboración con el cliente debe prevalecer sobre la negociación de contratos.
La capacidad de respuesta ante un cambio es más importante que el seguimiento estricto de un plan.

Entre los principales métodos ágiles tenemos el XP (eXtreme Programming), Scrum, Iconix, Cristal Methods, AUP entre otras.

Estas metodologías ponen de relevancia que la capacidad de respuesta a un cambio es más importante que el seguimiento estricto de un plan. Nos lo proponen porque para muchos clientes esta flexibilidad será una ventaja competitiva y porque estar preparados para el cambio significar reducir su coste.

Retrasar las decisiones y Planificación Adaptativa

Es el eje en cual gira la metodología ágil, el retrasar las decisiones tan como sea posible de manera responsable será ventajoso tanto para el cliente como para la empresa, lo cual permite siempre mantener una satisfacción en el cliente y por ende el éxito del producto, las principales ventajas de retrasar las decisiones son:

ü Reduce el número de decisiones de alta inversión que se toman.

ü Reduce el número de cambios necesario en el proyecto.

ü Reduce el coste del cambio

La planificación adaptativa permite estar preparados para el cambio ya que lo hemos introducido en nuestro proceso de desarrollo, además hacer una planificación adaptativa consiste en tomar decisiones a lo largo del proyecto, estaremos transformando el proyecto en un conjunto de proyectos pequeños.

Esta planificación a corto plazo nos permitirá tener software disponible para nuestros clientes y además ir aprendiendo del feedback para hacer nuestra planificación más sensible, sea ante inconvenientes que aceleren o retrasen nuestro producto. A continuación se detalla el XP que es el más aceptado dentro del desarrollo de SW.

Extreme Programming (XP)

Es la más destacada de los procesos agiles de desarrollo de software formulada por Kent Beck. La programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad.

Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

Las características fundamentales del método son:

Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.

Pruebas Unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo priebas de regresion. Se aconseja escribir el código de la prueba antes de la codificación.

Programación por 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 interacció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.

Refactorizacion: del código, es decir, reescribir 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 en 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. Mientras más simple es el sistema, menos tendrá que comunicar sobre este, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.

Ventajas

· Apropiado para entornos volátiles

· Estar preparados para el cambio, significa reducir su coste.

· Planificación más transparente para nuestros clientes, conocen las fechas de entrega de funcionalidades. Vital para su negocio

· Permitirá definir en cada iteración cuales son los objetivos de la siguiente

· Permite tener realimentación de los usuarios muy útil.

· La presión esta a lo largo de todo el proyecto y no en una entrega final

Desventajas

· Delimitar el alcance del proyecto con nuestro cliente

Para mitigar esta desventaja se plantea definir un alcance a alto nivel basado en la experiencia.

2.2.5 Metodologías emergentes

ICONIX:
El proceso ICONIX se define como un proceso de desarrollo de software práctico. Está entre la complejidad de RUP y la simplicidad y pragmatismo de XP, sin eliminar las tareas de análisis y diseño que XP no contempla.
Es un proceso simplificado en comparación con otros procesos más tradicionales, que unifica un conjunto de métodos de orientación a objetos con el objetivo de abarcar todo el ciclo de vida de un proyecto. ICONIX presenta claramente las actividades de cada fase y exhibe una secuencia de pasos que deben ser seguidos. Además, está adaptado a patrones y ofrece el soporte UML, dirigido por Casos de Uso y es un proceso iterativo e incremental.
Las tres características fundamentales de ICONIX son:
• Iterativo e incremental: varias interacciones ocurren entre el modelo del dominio y la identificación de los casos de uso. El modelo estático es incrementalmente refinado por los modelos dinámicos.
• Trazabilidad: cada paso está referenciado por algún requisito. Se define la trazabilidad como la capacidad de seguir una relación entre los diferentes artefactos producidos
• Dinámica del UML: la metodología ofrece un uso dinámico del UML como los diagramas del caso de uso, diagramas de secuencia y de colaboración.
Las tareas que se realizan en la metodología ICONIX son:
• Análisis de requisitos
• Análisis y diseño preliminar
• Diseño
• Implementación
CRYSTAL METHODOLOGIES:
Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo y la reducción al máximo del número de artefactos producidos. El desarrollo de software se considera un juego cooperativo de invención y comunicación, 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 políticas de trabajo en equipo definidas. Estas políticas dependerán del tamaño del equipo, estableciéndose una clasificación por colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros).

CRYSTAL CLEAR:
Alistair Cockburn es el propulsor detrás de la serie de metodologías Crystal. Las mismas presentan un enfoque ágil, con gran énfasis en la comunicación, y con cierta tolerancia que la hace ideal en los casos en que sea inaplicable la disciplina requerida por XP. Crystal “Clear” es la encarnación más ágil de la serie y de la que más documentación se dispone. La misma se define con mucho énfasis en la comunicación, y de forma muy liviana en relación a los entregables. Crystal maneja iteraciones cortas con feedback frecuente por parte de los usuarios/clientes, minimizando de esta forma la necesidad de productos intermedios. Otra de las cuestiones planteadas es la necesidad de disponer de un usuario real aunque sea de forma part time para realizar validaciones sobre la Interfase del Usuario y para participar en la definición de los requerimientos funcionales y no funcionales del software.
Una cuestión interesante que surge del análisis de la serie Crystal es el pragmatismo con que se customiza el proceso. Las personas involucradas escogen aquellos principios que les resultan efectivos y mediante la aplicación de la metodología en diversos proyectos agregan o remueven principios en base al consenso grupal del equipo de desarrollo.
Los siete valores o propiedades de Crystal Clear son:
1. Entrega frecuente. Consiste en entregar software a los clientes con frecuencia, no solamente en compilar el código. La frecuencia dependerá del proyecto, pero puede ser diaria, semanal o mensual.
2. Comunicación osmótica. Todos juntos en el mismo cuarto. Una variante especial es disponer en la sala de un diseñador senior; eso se llama Experto al Alcance de la Oreja. Una reunión separada para que los concurrentes se concentren mejor es descrita como El Cono del Silencio.
3. Mejora reflexiva. Tomarse un pequeño tiempo (unas pocas horas por algunas semanas o una vez al mes) para pensar bien qué se está haciendo, cotejar notas, reflexionar, discutir.
4. Seguridad personal. Hablar cuando algo molesta: decirle amigablemente al manager que la agenda no es realista, o a un colega que su código necesita mejorarse, o que sería conveniente que se bañase más seguido.
5. Foco. Saber lo que se está haciendo y tener la tranquilidad y el tiempo para hacerlo. Lo primero debe venir de la comunicación sobre dirección y prioridades, típicamente con el Patrocinador Ejecutivo. Lo segundo, de un ambiente en que la gente no se vea compelida a hacer otras cosas incompatibles.
6. Fácil acceso a usuarios expertos.
7. Ambiente técnico con prueba automatizada, management de configuración e integración frecuente. Muchos equipos ágiles compilan e integran varias veces al día.
FDD :
FDD es un proceso diseñado por Peter Coad, Erich Lefebvre y Jeff De Luca y se podría considerar a medio camino entre RUP y XP, aunque al seguir siendo un proceso ligero (en mi opinión, si tenemos que distinguir entre pesado/ligero) es más similar a este último. FDD está pensado para proyectos con tiempo de desarrollo relativamente cortos (menos de un año). Se basa en un proceso iterativo con iteraciones cortas (~2 semanas) que producen un software funcional que el cliente y la dirección de la empresa pueden ver y monitorizar.
Las iteraciones se deciden en base a features (de ahí el nombre del proceso) o funcionalidades, que son pequeñas partes del software con significado para el cliente. Así, construir el sistema de ventas es algo que requiere mucho tiempo, y construir el sistema de persistencia no tiene significado para el cliente, pero si lo tiene enviar pedido por e-mail.
Un proyecto que sigue FDD se divide en 5 fases:
1. Desarrollo de un modelo general
2. Construcción de la lista de funcionalidades
3. Plan de relealses en base a las funcionalidades a implementar
4. Diseñar en base a las funcionalidades
5. Implementar en base a las funcionalidades
3. Fases de FDD
4. Vista general de FDD
Las primeras tres fases ocupan gran parte del tiempo en las primeras iteraciones, siendo las dos últimas las que absorben la mayor parte del tiempo según va avanzando el proyecto, limitándose las primeras a un proceso de refinamiento.
El trabajo (tanto de modelado como de desarrollo) se realiza en grupo, aunque siempre habrá un responsable último (arquitecto jefe o jefe de programadores en función de la fase en que se encuentre), con mayor experiencia, que tendrá la última palabra en caso de no llegar a un acuerdo. Al hacerlo en grupo se consigue que todos formen parte del proyecto y que los menos inexpertos aprendan de las discusiones de los más experimentados, y al tener un responsable último, se asignan las responsabilidades que todas las empresas exigen.
Las funcionalidades a implementar en una release se dividen entre los distintos subgrupos del equipo, y se procede a implementarlas. Las clases escritas tienen propietario (es decir, solo quién las crea puede cambiarlas), es por ello que en el equipo que implementa una funcionalidad dada deberán estar todos los dueños de las clases implicadas, pudiendo encontrarse un programador en varios grupos, implementando distintas funcionalidades. Habrá también un programador jefe (normalmente el más experimentado) que hará las funciones de líder del grupo que implementa esa funcionalidad.
En el proceso de implementar la funcionalidad también se contemplan como partes del mismo (en otros métodos se describen como actividades independientes) la preparación y ejecución de pruebas, así como revisiones del código (para distribuir el conocimiento y aumentar la calidad) e integración de las partes que componen el software.
FDD también define métricas para seguir el proceso de desarrollo de la aplicación, útiles para el cliente y la dirección de la empresa, y que pueden ayudar, además de para conocer el estado actual del desarrollo, a realizar mejores estimaciones en proyectos futuros.

Adaptive Software Development (ASD):
Este proceso consiste en un cambio de filosofía en las organizaciones pasando de la transición del modelo Comando-Control al modelo liderazgo-Colaboración. Lleva los conceptos de los Sistemas Adaptativos Complejos al campo de la Ingeniería de Software en particular. Dada la complejidad inherente al software concluye que la aplicación de esta teoría es esencial para el nuevo escenario que plantea la economía global.
El ciclo de vida de ASD propone tres fases esenciales: especulación, colaboración y aprendizaje. El proyecto comienza con una fase de especulación en que se lleva a cabo la planificación tentativa del proyecto en función de las entregas que se irán realizando. En esta etapa se fija un rumbo determinado a ser seguido en el desarrollo, sabiendo a partir de ese momento que no será el lugar en que finalizará el proyecto. En cada iteración, se aprenderán nuevas funcionalidades, se entenderán viejas cuestiones, y cambiarán los requerimientos.
La siguiente fase del ciclo de vida, Colaborar, es aquella en la que se construye la funcionalidad definida durante la especulación. ASD define un Componente como un grupo de funcionalidades o entregables a ser desarrollados durante un ciclo iterativo. Durante cada iteración el equipo colabora intensamente para liberar la funcionalidad planificada. También existe la posibilidad de explorar nuevas alternativas, realizar pruebas de concepto, pudiendo eventualmente alterar el rumbo del proyecto profundamente. ASD no propone técnicas ni prescribe tareas al momento de llevar a cabo la construcción simplemente mencionando que todas las prácticas que sirvan para reforzar la colaboración serán preferidas, siguiendo de esta forma la línea de las metodologías ágiles respecto a la orientación a componentes.
La fase final de ASD, Aprender, consiste en la revisión de calidad que se realiza al final de cada ciclo.
Para evaluar la calidad desde el punto de vista del cliente se sugieren utilizar grupos de enfoque en el cliente, mediante los cuales se explora un modelo de la aplicación y se anotan los requerimientos de cambio del cliente.
Las revisiones al diseño, al código o a las pruebas permitirán aprender sobre la calidad de los mismos. En este caso, el énfasis estará puesto en aprender cuales han sido los errores o desvíos y poder resolverlos, y no en encontrar culpables. Asimismo, esta es la etapa en que se evaluarán las exploraciones que se hayan realizado dando la capacidad de poder modificar la arquitectura del sistema si se ha encontrado algún camino que se ajusta mejor a lo que necesita el usuario o si han cambiado los requerimientos.
Finalmente se puede afirmar que ASD es un marco filosófico basado en la teoría de Sistemas Adaptativos Complejos que permite encarar la construcción de software en forma ágil utilizando las prácticas que resulten convenientes en cada caso. En este sentido resulta similar a Scrum.

Unidad II-Metodologias de desarrollo

viernes, 15 de marzo de 2013

Metodologias De Desarrollo