BIBLIOTECA VIRTUAL de Derecho, Economía y Ciencias Sociales


SELECCIÓN DE METODOLOGÍAS DE DESARROLLO PARA APLICACIONES WEB EN LA FACULTAD DE INFORMÁTICA DE LA UNIVERSIDAD DE CIENFUEGOS

Karenny Brito Acuña


Esta página muestra parte del texto pero sin formato.

Puede bajarse el libro completo en PDF comprimido ZIP (148 páginas, 1.89 Mb) pulsando aquí

 

 

I.3. 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. A continuación se describen las características de algunas de ellas.

Proceso Unificado de Desarrollo (RUP)

El Proceso Unificado de Desarrollo [20] fue creado por el mismo grupo de expertos que crearon UML, Ivar Jacobson, Grady Booch y James Rumbaugh en el año 1998. El objetivo que se perseguía con esta metodología era producir software de alta calidad, es decir, que cumpla con los requerimientos de los usuarios dentro de una planificación y presupuesto establecidos. Como se expresaba anteriormente, esta metodología concibió desde sus inicios el uso de UML como lenguaje de modelado.

Es un proceso dirigido por casos de uso, este avanza a través de una serie de flujos de trabajo (requisitos, análisis, diseño, implementación, prueba) que parten de los casos de uso; está centrado en la arquitectura y es iterativo e incremental. Además cubre el ciclo de vida de desarrollo de un proyecto y toma en cuenta las mejores prácticas a utilizar en el modelo de desarrollo de software.

A continuación se muestran estas prácticas.

• Desarrollo de software en forma iterativa.

• Manejo de requerimientos.

• Utiliza arquitectura basada en componentes.

• Modela el software visualmente.

• Verifica la calidad del software.

• Controla los cambios.

Para apoyar el trabajo con esta metodología ha sido desarrollada por la Compañía norteamericana Rational Corporation la herramienta CASE (Computer Assisted Software Engineering) Rational Rose en el año 2000. Esta herramienta integra todos los elementos que propone la metodología para cubrir el ciclo de vida de un proyecto.

Microsoft Solution Framework (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 tiene las siguientes características [21]:

• 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, Modelo de

Diseño de Proceso y finalmente el modelo de Aplicación.

Aplicando esta metodología todo proyecto es separado en cinco principales fases [22]:

• 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. Planificación: 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. La infraestructura también es desarrollada durante esta fase.

Scrum

Scrum [23] 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. [11]

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 (Extreme Programming, XP)

XP [24] 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 en [10] sin cubrir los detalles técnicos y de implantación de las prácticas.

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: [24]

• 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: [14]

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.

El ciclo de vida ideal de XP consiste de seis fases [10]: Exploración, Planificación de la Entrega (Release), Iteraciones, Producción, Mantenimiento y Muerte del Proyecto.

ICONIX

El proceso ICONIX [25] 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). [24]

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: [26]

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 [27] 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 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.

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. [28]

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.

Agile Unified Process (AUP)

Agile Unified Process [29] 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.

Dynamic Systems Development Method (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 de la proyecto." [30]

Sus principales características son: es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos.

El ciclo de desarrollo de DSDM está compuesto 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

XBreed [31] 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 [32] 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

Win-Win Spiral Model [33] 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

MIDAS [34] 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

RMM [35] 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. [36]

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.

OOHDM (The Object-Oriented Hypermedia Design Model)

El Modelo de Diseño de Hipermedia Orientado a Objeto [37], 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.

I.4 Conclusiones del capítulo

En este capítulo se realizó una introducción a la ingeniería de software y su historia. Además se llevó a cabo un estudio de las investigaciones que se han realizado en el campo de las metodologías de desarrollo no solo en Cuba sino también en el mundo. Se llevó a cabo igualmente un análisis de estas metodologías de desarrollo de software que son utilizadas en la actualidad por los desarrolladores de sistemas para lograr productos de alta calidad.


Grupo EUMEDNET de la Universidad de Málaga
Enciclopedia Virtual
Biblioteca Virtual
Servicios
 
Todo en eumed.net:

Congresos Internacionales


¿Qué son?
 ¿Cómo funcionan?

 

10 al 27 de
abril
VIII Congreso EUMEDNET sobre
Ética, Gobernanza y Desarrollo




Aún está a tiempo de inscribirse en el congreso como participante-espectador.


Próximos congresos

7 al 26 de
mayo
VII Congreso EUMEDNET sobre
Historia y Ciencias Sociales

6 al 25 de
junio
XI Congreso EUMEDNET sobre
Desarrollo Sostenible y Población

8 al 25 de
julio
VIII Congreso EUMEDNET sobre
Turismo y Desarrollo

7 al 24 de
octubre
XII Congreso EUMEDNET sobre
Globalización y Crisis Financiera

 

 

 

 

 

Encuentros de economia internacionales a traves de internet


Este sitio web está mantenido por el grupo de investigación eumednet con el apoyo de Servicios Académicos Internacionales S.C.

Volver a la página principal de eumednet