Instituto Tecnológico de Colima
Cuadro comparativo de metodologías Web WSDM – HDM – W2000 – UWA – NDT - DDDP
Víctor Manuel Galindo Ramírez #10460269, Víctor Manuel Romero Larios #10460739, Luis Manuel Avalos Lara #10460247, Armando Saúl Carranza Sánchez #10460256, Lizeth Reyes Carmen #10460736, Juan Pablo González Ramírez #10460714, David Cuadra Quevedo #10460260 9-11-2013
WSDM
HDM
W2000
Características Dirigido para el desarrollo de sitios web. Propone 4 fases: o Modelado de usuario Clasificación Descripción o Diseño conceptual Modelado de objetos Diseño navegacional o Diseño e implementación o Realización de la implementación Existe un acercamiento con el usuario. Dependiendo del tipo de usuario se define el sistema. Busca satisfacer las necesidades de cada grupo de usuarios Se clasifican los usuarios. Creado por Franca Garzotto en 1991. Es extensión del modelo entidad-relación (ERD) para representar estructuras complejas con enlaces y semántica de navegación interna. Es una técnica de modelado. Los elementos que incorpora son: o La información a capturar (entidad) o La información que espera obtener (perspectiva) o La forma de navegar (Enlaces) o El conjunto de información (Unidades) Estudia y diseña la navegación. Plantea el modelado en las aplicaciones multimedia. Usa la perspectiva hacia el usuario. Base para nuevas propuestas como OOHDM. Trabaja con estructuras de acceso como índices. Trabaja en 2 fases: o Especificación y diseño de los aspectos globales y estructurales o Desarrollo y ubicación del contenido de las unidades (información) Está en desuso.
Ventajas Se estudia a fondo cada tipo de usuario para satisfacer sus necesidades. Se hace un análisis profundo de los tipos de usuarios.
Desventajas No garantiza que la información no sea repetida ni redundante. No evalúa seguridad ni funcionalidad. Se ocupa hacer mucha documentación para identificar los tipos de usuarios.
Costos Es costoso ya que requiere tiempo para analizar a los tipos de usuario a los que se les va a desarrollar el sistema.
Se le muestra lo que el usuario realmente quiere ver. Se obtiene una navegación consistente y rica. Separa lo conceptual, información que se almacena y de la presentación. Se incorpora fácilmente a un modelo entidad-relación Incorpora solo el modelo de clases de UML para ver las relaciones entre elementos.
No es una metodología de desarrollo de aplicaciones multimedia. No contempla procesos, los elementos resultan insuficientes en el desarrollo No define pautas de trabajo, se centra en lo visual. No propone novedades por ser técnica obsoleta La técnica no se documenta ni especifica en aspectos de interfaz. Solo se concentra en la información final: ¿como se muestra? y ¿en qué se muestra? Entre el modelo de clases y entidadrelación solo se aprecia la navegación y comunicación entre los elementos.
Menor costo comparado con otras. Solo se ocupa conocer lo que proporciona y espera el usuario. La interfaz y la navegación dependerá de los enlaces y comunicación de los elementos. Otro aspecto que la hace económica es que solo son una técnica, más no consta de pasos y fases, Considera que la metodología ya fue aplicada. Solo se fija como se muestran los resultados y donde se ubica.
Se centra en la orientación a objetos. Separa el aspecto de la navegación de las demás
Esta metodología sirve para el diseño de aplicaciones web complejas.
Es innecesaria usarla con sistemas web sencillos.
Es más costosa por la personalización al usuario.
fases. Toma de base la HDM y la adecua a la web. Propone un ciclo de vida para el desarrollo de sistemas web. UWA
NDT
DDDP
Proceso iterativo. Clasificación de objetivos. Requerimientos de datos. Requerimientos de interfaz. Requerimientos de navegación. Requerimientos de personalización. Requerimientos de transacción. Se centra en una detallada fase de ingeniería de requisitos guiada por objetivos, que contempla tanto la captura, como la definición y la verificación de requisitos. Ciclo de vida compuesto por dos fases: o Ingeniería de requisitos o Análisis En el tratamiento de requisitos separa la captura, la definición y la validación de requisitos, proponiendo técnicas específicas para cada uno. Ofrece una herramienta NDT-Tool que sirve como soporte en la aplicación de sus técnicas. Su aplicación NDT-Tool genera tres resultados finales: o El documento de requisitos de la aplicación Web, donde se detallan los objetivos y requisitos que debe cumplir la aplicación Web. o El documento de análisis de la aplicación Web, donde se recogen el modelo conceptual y el modelo de navegación del sistema. o Los prototipos del sistema, que muestran la estructura de la interfaz de la aplicación Web. Para la descripción de los modelos de requisitos usa modelos que se basan fundamentalmente en patrones y casos de uso. Los modelos son: o De requisitos de almacenamiento de información. o De actores o De requisitos funcionales o De requisitos de interacción El proceso se basa en prototipos con el fin de
Personaliza el sistema web a cada usuario de acuerdo a sus requisitos. Con el uso de UML esta metodología se vuelve muy sólida y con gran soporte. Tiene una excelente documentación por la ayuda de UML. En comparación con otras metodologías, no requiere que se recaben datos en entrevistas, lluvia de ideas, casos de uso o cuestionarios. El proceso de desarrollo se disminuya en tiempo ya que no se tienen que hacer consultas. Es una metodología que tiene como objetivo el diseño de la página o sitio web a crear.
Por cada usuario se hace un modelo de caso de uso diferente. Es muy tardado el modelado UML. Requiere mucha documentación.
Implica más tiempo y esfuerzo en el modelado UML.
Dado que se inducen los requerimientos de datos, interfaz, navegación, personalización, al usuario o usuarios pueden o no gustarles el diseño. Usuarios renuentes al diseño. Incomodidad de interfaz.
Disminución de tiempo en las actividades de recabar información con los usuarios. Aumento de tiempo en cuanto a renuencia de usuarios a usar el sistema.
NDT-Tool utiliza la herramienta Rational Rose como soporte para la visualización de los modelos gráficos. Consigue los modelos básicos tantos conceptuales como de navegación a partir de los requisitos. En la captura de requisitos asume técnicas propias del mundo de la ingeniería del software (brainstorming, entrevistas, o el estudio de sistemas anteriores). Con el uso de NDT-Tool mejora el tiempo de desarrollo del sistema puesto que se automatizan muchas tareas, los resultados se consiguen simplemente pulsando un botón y se asegura la calidad de lo que se está generando, gracias a los controles internos que tiene NDT-Tool. Con los resultados de NDT se pueda continuar el ciclo de vida con cualquier otra metodología. En muchos momentos se puede realizar la vuelta atrás para corregir errores o salvar incongruencias. Se aplican una serie de revisiones para detectar errores. Normaliza la estructura de los resultados que se deben conseguir durante la ingeniería de requisitos y propone cuál debe ser la estructura completa del documento a conseguir.
NDT no contempla las fases avanzadas del ciclo de vida de desarrollo de una aplicación Web, como podrían ser implementación o mantenimiento. NDT no ofrece nuevos lenguajes de modelado. Se tienen que conocer los modelos antecesores a este ya que es basado en ellos. Intenta utilizar en la medida de lo posible, lenguajes de modelo estándar y ya aceptados por la comunidad investigadora. Con la fase de requisitos y de análisis no es suficiente para un desarrollo software. NDT cubre estas fases pero no dice cómo se continúa el proyecto. Es necesario que el analista después de revisar si encuentra errores vuelva a la ingeniería de requisitos. La fase de requisitos resulta más compleja, puesto que es más detallada.
El costo es relativamente alto en tiempo y esfuerzo ya que es necesario crear muchos prototipos que sirvan para validaciones y correcciones presentadas a los usuarios. Es necesario en muchas ocasiones volver más de una vez a fases anteriores para corregir errores. Hacer una descripción de los requisitos del sistema mediante patrones es más costoso que hacerlo en lenguaje natural o sólo mediante casos de uso.
Es un diseño por prototipos lo cual permite explorar posibles
Al hacer entrevistas a los usuarios
Si bien el proceso de recabar información
explorar posibles soluciones y problemas a resolver. Es un proceso iterativo, que consiste de la reducción de los clientes y las dudas de los clientes. Ciclo con tres fases: o Evaluación o Especificación o Construcción Necesidad de los requisitos tales como: o Clasificación de objetivos. o Requerimientos de datos. o Requerimientos de interfaz. o Requerimientos de navegación. o Requerimientos de personalización. o Requerimientos de transacción. o Requerimientos no funcionales.
soluciones de problemas que se van creando. Los requerimientos son adaptativos, si el cliente cambia a medio proceso la metodología permite redefinir requisitos. Recaba información atreves de entrevistas, por lo tanto el diseño de los requisitos no está muy alejado de lo que realmente quiere el cliente y hace que se tenga una buena relación con los usuarios finales del producto o página. En comparación con la UWA, esta no induce los requisitos tales como de datos, de interfaz, de personalización, navegación, etc. Al tener la página o sitio que el usuario requiere se disminuyen los costos de capacitar dado que tendría una interfaz amigable para el usuario.
finales se consume mucho tiempo. Mayor tiempo en el diseño dado que se pregunta a los usuarios como quieren que este la página. No usa modelado de casos de uso. No se tiene un seguimiento o documentación para la validación de requerimientos. Al tener contacto cercano con el cliente y los usuarios, no adopta un lenguaje formal y por lo tanto no cuenta con un glosario para la documentación.
del cliente para realizar el diseño es mayor que en otras metodologías, no lo es tanto como para volverlo costoso. Es una metodología fácil de seguir su proceso relativamente fácil.
Bibliografía Escalona Cuaresma, M. J. (2004). Modelos y técnicas para la especificacióny el análisis de la navegación ensistemas software. (Tesis de doctorado, Universidad de Sevilla). Recuperado dehttp://www.lsi.us.es/docs/doctorado/tesis/tesis.pdf