Buscar este blog

miércoles, agosto 18

metodologias

Descripción de las metodologías existentes para el desarrollo de software
Tener metodologías diferentes para aplicar de acuerdo con el proyecto que se desarrolle resulta imprescindible teniendo en cuenta las necesidades cambiantes que tiene el entorno de desarrollo actual y el acelerado progreso de la informática a nivel mundial resulta una idea interesante. Estas metodologías pueden involucrar prácticas tanto de metodologías ágiles como de metodologías tradicionales
Metodología RUP
El proceso de desarrollo RUP aplica varias de las mejores practicas en el desarrollo moderno de software, en una forma que se adapta a un amplio rango de proyectos y organizaciones. Provee a cada miembro del equipo, un fácil acceso a una base de conocimiento con guías., plantillas y herramientas para todas las actividades criticas del desarrollo de software. Esta metodología permite que todos los integrantes de un equipo de trabajo, conozcan y compartan el proceso de desarrollo, una base de conocimientos y los distintos modelos de cómo desarrollar el software utilizando un lenguaje modelado común

El RUP es un proceso de desarrollo de software:

Su principal objetivo es asegurar la producción de software de alta calidad, que cumpla las necesidades de sus usuarios finales, que sea realizado en las fechas acordadas y con el presupuesto disponible.

El RUP es un producto:
IBM comercializa un producto que permite instancia al RUP según las características del proyecto, siendo una referencia en la metodología que sirve como repositorio único de información.

El RUP es un marco de trabajo
Este marco de trabajo puede ser adoptado y extendido para satisfacer las necesidades de la organización que lo utilice seleccionando las fases y interacciones, los flujos de trabajo y disciplinas que se van a recorrer y los entregables o productos que se van a construir. Es importante conocer como esta organizado y estructurado el proceso para poder seleccionar el frame work, los elementos del proceso que mas valor darán al proyecto.

El RUP incorpora muchas de las conocidas como “buenas practicas” en el desarrollo de software moderno, las cuáles se deben tener presentes en el desarrollo de aplicaciones empresariales para garantizar el éxito del proyecto, tales como: Desarrollo iterativo, Gestión de Requerimientos, Arquitectura basada en componentes, Modelo Visual, Verificación de la calidad en forma continua y control de cambios.

El RUP presenta 3 características:

1. Dirigido por los casos de uso.
2. Centrado en la arquitectura.
3. Ciclo de vida iterativo.

Otras características

• Reconoce que las necesidades del usuario y sus requerimientos no se pueden definir completamente al principio•
Permite evaluar tempranamente los riesgos en lugar de descubrir problemas en la integración final del sistema
• Reduce el costo del riesgo a los costos de un solo incremento
• Acelera el ritmo del esfuerzo de desarrollo en su totalidad debido a que los desarrolladores trabajan para obtener resultados claros a corto plazo
• Distribuye la carga de trabajo a lo largo del tiempo del proyecto ya que todas las disciplinas colaboran en cada iteración.
• Facilita la reutilización del código teniendo en cuenta que se realizan revisiones en las primeras iteraciones lo cual además permite que se aprecien oportunidades de mejoras en el diseño
El proceso de desarrollo está dividido en Fases a lo largo del tiempo cada una de las cuales tiene objetivos específicos:

Las fases son las siguientes:

1) Inicio
2) Elaboración
3) Construcción
4) transición

Metodología UML

La metodología que se propone, denominada UML-MAST, concilia las diferencias entre la visión del diseñador de sistemas de tiempo real y la del de sistemas orientados a objetos. A tal fin define un nivel de abstracción adecuado para los elementos de modelado del comportamiento de tiempo real, que permite formularlos con una estructura paralela a la arquitectura lógica del sistema, y vincularlos a esta. La semántica de modelado sigue el perfil UML para planificabilidad, rendimiento y tiempo (SPT) estandarizado por el OMG, del que UML-MAST puede considerase una implementación. La propuesta se integra con las herramientas de análisis y diseño de sistemas de tiempo real MAST que analiza los modelos y retorna los resultados al modelo inicial para su interpretación por el diseñador. Asimismo, se han definido criterios para la extensión de esta metodología a otros niveles de abstracción tales como sistemas basados en componentes y sistemas implementados utilizando Ada 95. Parte de los resultados de este trabajo han sido incorporados por el OMG a su perfil SPT.

Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.
Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.

Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.
MSF
MSF es una metodología desarrollada por Microsoft Consulting Services en conjunto con varios grupos de negocios de Microsoft y otras fuentes de la industria. MSF provee los principios, modelos y disciplinas para un correcto desarrollo de proyectos en cualquier plataforma (Linux, Citrix, Microsoft, Unix).
Esta es una metodología flexible e interrelacionada con una serie de conceptos, modelos y prácticas de uso, que controlan la planificación, el desarrollo y la gestión de proyectos tecnológicos. MSF se centra en los modelos de proceso y de equipo dejando en un segundo plano las elecciones tecnológicas.
MSF características:
• Adaptable: es parecido a un compás, usado en cualquier parte como un mapa, del cual su uso es limitado a un específico lugar.
• Escalable: puede organizar equipos tan pequeños entre 3 o 4 personas, así como también, proyectos que requieren 50 personas a más.
• Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente.
• Tecnología Agnóstica: porque puede ser usada para desarrollar soluciones basadas sobre cualquier tecnología.
MSF se compone de varios modelos encargados de planificar las diferentes partes implicadas en el desarrollo de un proyecto: Modelo de Arquitectura del Proyecto, Modelo de Equipo, Modelo de Proceso, Modelo de Gestión del Riesgo.
metodología: en cinco principales fases
• Visión y Alcances.
• Planificación.
• Desarrollo.
• Estabilización.
• Implantación.
Visión y Alcances: trata uno de los requisitos fundamentales para el éxito del proyecto, la unificación del equipo detrás de una visión común.
El equipo debe tener una visión clara de lo que quisiera lograr para el cliente y ser capaz de indicarlo en términos que motivarán a todo el equipo y al cliente. Se definen los líderes y responsables del proyecto, adicionalmente se identifican las metas y objetivos a alcanzar; estas últimas se deben respetar durante la ejecución del proyecto en su totalidad, y se realiza la evaluación inicial de riesgos del proyecto.
Es en esta fase es cuando la mayor parte de la planeación para el proyecto es terminada. El equipo prepara las especificaciones funcionales, realiza el proceso de diseño de la solución, y prepara los planes de trabajo, estimaciones de costos y cronogramas de los diferentes entregables del proyecto.
Desarrollo: Durante esta fase el equipo realiza la mayor parte de la construcción de los componentes (tanto documentación como código), sin embargo, se puede realizar algún trabajo de desarrollo durante la etapa de estabilización en respuesta a los resultados de las pruebas
Scrum
Scrum es una metodología de desarrollo muy simple, que requiere trabajo duro, porque no se basa en el seguimiento de un plan, sino en la adaptación continua a las circunstancias de la evolución del proyecto.
Toma forma de las prácticas de trabajo que a partir de los 80 comienzan a adoptar algunas empresas tecnológicas y que Nonaka y Takeuchi acuñaron como "Campos de Scrum". El modelo Scrum, aplicado al desarrollo de software, emplea el principio de desarrollo ágil: "desarrollo iterativo e incremental", denominando sprint a cada iteración de desarrollo. Las prácticas empleadas por Scrum para mantener un control ágil en el proyecto son:
• Revisión de las iteraciones
• Desarrollo incremental
• Desarrollo evolutivo
• Auto-organización del equipo
• Colaboración
Define un marco para la gestión de proyecto. Está especialmente indicado a proyectos con un rápido cambio de requisitos. En Scrum inicialmente planean el contexto y un estimado amplio de la entrega. Luego desarrollan el estimado de la entrega basado en el desarrollo del ambiente del proyecto.
El proceso del ciclo de vida de Scrum reconoce que el proceso de desarrollo fundamental está completamente indefinido y usa mecanismos de control para perfeccionar la flexibilidad, manipular lo imprescindible y el control del riesgo.
Los valores que hacen posible a las prácticas de Scrum crear "campos de Scrum" son:
• Autonomía del equipo
• Respeto en el equipo • Responsabilidad y auto-disciplina
• Foco en la tarea
• Información transparencia y visibilidad
Programación Extrema XP
XP es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo.
XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico.
Los principios y prácticas son de sentido común pero llevadas al extremo, de ahí proviene su nombre. Kent Beck, el padre de XP, describe la filosofía de XP.
XP utiliza un técnica denominada Historias de Usuario es utilizada para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las características que el sistema debe poseer, sean requisitos funcionales o no funcionales.
Roles XP
Los roles de acuerdo con la propuesta original de Beck son:
• Programador.
• Cliente.
• Encargado de pruebas (Tester).
• Encargado de seguimiento (Tracker).
• Entrenador (Coach).
• Consultor.
• Gestor (Big boss).
Proceso XP
El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos:
1. El cliente define el valor de negocio a implementar.
2. El programador estima el esfuerzo necesario para su implementación.
3. El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de tiempo.
4. El programador construye ese valor de negocio.
5. Vuelve al paso 1.
En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe presionar al programador a realizar más trabajo que el estimado, ya que se perderá calidad en el software o no se cumplirán los plazos.
XP consiste de seis fases
Exploración, Planificación de la Entrega (Release), Iteraciones, Producción, Mantenimiento y Muerte del Proyecto.
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.
características de ICONIX
• 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
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 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.
FDD se divide en 5 fases:
1. Desarrollo de un modelo general
2. Construcción de la lista de funcionalidades
3. Plan de releases 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.
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.
ASD propone tres fases esenciales:
especulación
colaboración
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.
AUPAgile Unified Process es una versión simplificada de Rational Unified Process, desarrollada por Scott Amber.
Divide el ciclo de desarrollo en 4 fases:
Incepción: identificación del alcance y dimensión del proyecto, propuesta de la arquitectura y de presupuesto del cliente.
Elaboración: Confirmación de la idoneidad de la arquitectura.
Construcción: Desarrollo incremental del sistema, siguiendo las prioridades funcionales de los implicados.
Transición: Validación e implantación del sistema.
DSDM
DSDM es otra metodología diseñada para responder a los plazos de entrega cortos y una cantidad limitada de recursos. Nace en 1994 con el objetivo de crear una metodología RAD (Desarrollo Rápido de Aplicaciones, en inglés, Rapid Application Development) unificada. Al igual que Cristal, DSDM se esfuerza por acortar las líneas de comunicación entre el cliente, promotor, y las empresas interesadas, a fin de prestar un servicio más eficiente en el proceso de producción de software. Al fijar el plazo de entrega (generalmente 6 meses) y el establecimiento de límites de los recursos, es más fácil establecer un proceso de desarrollo que responda a los usuarios "reales requerimientos del negocio." Según el sitio web del Consorcio DSDM, DSDM en un marco de desarrollo que "se centra en las prioridades del negocio y ofrece los entregados dentro de los plazos y costos del proyecto, en orden de prioridad determinado por las necesidades y los objetivos del proyecto.
Sus principales características son: es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos.
DSDM de 5 fases.
1. . Estudio de viabilidad
2. Estudio de negocio
3. Iteración de modelado funcional
4. Iteración de diseño y desarrollo
5. Implementación
Las tres últimas son iterativas, además de existir realimentación a todas las fases.
Xbreed
es una mezcla de XP y Scrum ideas desarrolladas por Mike Beedle. SCRUM XBreed utiliza como marco de gestión, mientras que la adaptación de una versión reducida de Extreme Programming para su proceso de desarrollo
Fue diseñado con la intención de desarrollar "software reutilizables en un tiempo récord." Mediante el empleo de patrones de diseño para crear los objetos reutilizables, XBreed crea una biblioteca de componentes que, idealmente, son fácilmente reinsertados en nuevos proyectos de software. El proceso de desarrollo depende en gran medida de la capacidad y los conocimientos de los miembros de su equipo, que requieren fuertes y poca transferencia de conocimientos generales de comunicación para mantener el proyecto funcionando bien y eficientemente, los requisitos son ayudados por el uso de SCRUM.
En la actualidad está evolucionando y cambiando de nombre. Mantiene los principios de gestión de Scrum, y ahora se denomina AE (Agile Enterprise).
Lean Development Lean
fue descrito por Mary Poppendieck, es una de las últimas contribuciones a la comunidad Ágil de Desarrollo de Software. Basado en los principios de producción ajustada japoneses, Lean es otro paradigma de desarrollo de naturaleza similar a la de Cristal y TEA en la medida en que fomenta un cambio en la cultura, así como un cambio en el proceso. Estos principios están diseñados para aumentar la velocidad de entrega, los productos de software de alta calidad y menor coste de producción.
Win-Win Spiral
propuesto por Barry Boehm es un nuevo logro en un proceso tradicional de software. Manteniendo al mismo tiempo muchos de los elementos tradicionales la versión Win-Win Spiral Model se esfuerza por comprender a todos los interesados en el proceso de desarrollo. Se trata de un motor de colaboración que establece que "ganar" las condiciones establecidas por los usuarios, clientes, desarrolladores, ingenieros de sistemas y con el fin de evolucionar y priorizar los requisitos durante todo el proceso. Las prácticas tradicionales, como los requisitos de ingeniería, diseño, código, y probar, aún están presentes en cada iteración de la espiral, pero el paso de colaboración durante el proceso de desarrollo hace que sea claramente de adaptación. Esta colaboración ofrece el software más rápido, con mayor calidad, menos costosa y, debido a la inicial de satisfacción de las necesidades de los usuarios y la cantidad reducida de mantenimiento
Estabilización: En esta fase se conducen pruebas sobre la solución, las pruebas de esta etapa enfatizan el uso y operación bajo condiciones realistas. El equipo se enfoca en priorizar y resolver errores y preparar la solución para el lanzamiento.
Implantación: Durante esta fase el equipo implanta la tecnología base y los componentes relacionados, estabiliza la instalación, traspasa el proyecto al personal soporte y operaciones, y obtiene la aprobación final del cliente.
MIDAS
es una metodología genérica y fácilmente adaptable a cualquier tipo de SIW. Es un framework metodológico para el desarrollo de Sistemas de Información para Windows (SIW por sus siglas en inglés), en el que se propone un proceso de desarrollo ágil integrado en una arquitectura dirigida por modelos, alineándose así con la propuesta MDA del OMG.
MIDAS propone modelar un SIW atendiendo a dos dimensiones ortogonales. Por un lado, y debido a que la metodología se basa en una propuesta MDA, es necesario tener en cuenta el grado de dependencia de la plataforma de los modelos construidos. En primer lugar, será necesario modelar el sistema construyendo modelos independientes de la computación (CIM), modelos independientes de la plataforma (PIM) y modelos específicos de la plataforma (PSM) y, en segundo lugar, será necesario especificar las reglas que permitan realizar transformaciones entre estos modelos. Por otro lado, la segunda dimensión a considerar está relacionada con tres aspectos básicos: el contenido (es decir, la información presente en el SIW), el hipertexto (relacionado con el modelado de las posibles rutas de navegación que podría seguir un usuario del SIW durante su interacción con el mismo) y el comportamiento propiamente dicho del sistema.
Además, MIDAS sugiere la utilización del Lenguaje de Modelado Unificado (UML) como única notación para modelar tanto los PIMs como los PSMs.
RMM
está basada en los conceptos implantados en el Modelo de diseño de hipertexto, es decir, en las entidades y en los tipos de entidades. Su objetivo es mejorar la navegación a través de un análisis de las entidades del sistema. En teoría, se obtiene una navegación más estructurada y logra que esta sea más intuitiva para el usuario. Los conceptos de slices y m-slices, que consisten en la agrupación de datos de una entidad en diferentes pantallas, es una de las aportaciones más importantes de esta metodología. Fue la primera metodología completa que se publica para software multimedia. Su problema principal es que no permite realizar consultas a partir de dos entidades y como está muy atado al modelo entidad relación cuando se define una relación se obliga a descomponerlas en dos relaciones copiando el modelo E-R. Además no considera las consultas a la base de datos para la creación de páginas Web dinámicas.
UWE
La propuesta de Ingeniería Web basada en UML es una metodología detallada para el proceso de autoría de aplicaciones con una definición exhaustiva del proceso de diseño que debe ser utilizado. Este proceso, iterativo e incremental, incluye flujos de trabajo y puntos de control, y sus fases coinciden con las propuestas en el Proceso Unificado de Modelado.
UWE está especializada en la especificación de aplicaciones adaptativas, y por tanto hace especial hincapié en características de personalización, como es la definición de un modelo de usuario o una etapa de definición de características adaptativas de la navegación en función de las preferencias, conocimiento o tareas de usuario.
Otras características relevantes del proceso y método de autoría de UWE son el uso del paradigma orientado a objetos, su orientación al usuario, la definición de un meta-modelo (modelo de referencia) que da soporte al método y el grado de formalismo que alcanza debido al soporte que proporciona para la definición de restricciones sobre los modelos.
OOHDME
Modelo de Diseño de Hipermedia Orientado a Objeto el sucesor del modelo de diseño hipertexto HDM, se trata de una metodología que se fundamenta en la orientación a objeto. Propone las siguientes fases: Diseño conceptual o análisis de dominio que utiliza el método de diseño orientado a objeto para obtener esquemas conceptuales de las clases y las relaciones entre las mismas. Utiliza las “técnicas de modelo de objeto” llamada notación OMT para el diseño de la navegación, donde se define la estructura de navegación por medio de modelos, es decir, a través de diferentes vistas del esquema conceptual; la fase de diseño de interfaz abstracta, se apoya en un modelo orientado a objeto para especificar la estructura y el comportamiento de la interfaz del sistema, este modelo se crea a través de tres tipos de diagramas: diagramas abstractos para cada clase, diagramas de configuración para reflejar los eventos externos y diagrama de estado para señalar el comportamiento dinámico; y por último, la fase de implementación, es decir, la construcción de los programas en programación orientada a objeto.

No hay comentarios.:

Publicar un comentario