Ingeniería de requerimientos aplicada a la concepción del Portal Web del CICPC
Trabajo de diploma para optar por el título de Ingeniero en Ciencias Informáticas
Autor: Isyed De La Caridad Rodríguez Trujillo Tutor: Ing. Edier García Gutiérrez
Ciudad de La Habana Junio, 2008
“Año 50 de La Revolución”
DE D E CL C L AR A RA A CI C I ÓN Ó N D D E E A A U U TO T O RÍ R ÍA A
Por este medio declaramos que Isyed de la Caridad Rodríguez Trujillo es la única autora de este trabajo y autorizo a la Universidad de las Ciencias Informáticas (UCI) para que hagan el uso que estimen pertinente con este trabajo.
Para que así conste firmo la presente a los __ días del mes de ___ de 2008.
______________ _______________
Firma del Autor Firma del Tutor
"Nunca consideres el estudio como una obligación sino como una oportunidad para penetrar en el bello y maravillosos mundo del saber."
Albert Einstein.
AGRADECIMIENTOS
…A La Revolución Cubana y al Comandante Fidel Castro por hacer realidad el sueño de graduarme.
…A La Universidad de las Ciencias Informáticas por forjarme como profesional.
…A mi queridos padres, a mi mamá Deysi Trujillo Bermúdez y a mi papá Jorge A Rodríguez Díaz, por ayudarme, por enseñarme hacer mejor cada día, y por ser extraordinarios.
…A mi novio Adriel Montero Duarte, por estar siempre junto a mí en todos los momentos y por su apoyo incondicional
…A mis abuelos, Ana Rosa y Osvaldo y Aída y Reynerio por quererme y guiarme por un buen camino.
…A mi tutor, el ingeniero Edier García Gutiérrez, por su dedicación y consejos.
…A mis tíos, Alain, Osmani, Cosme y Vlady, por darme siempre su entera confianza.
...A mis amigas Emilita, Marisol, Mechy, Nereida y Cary, porque siempre están ayudándome en lo que necesite.
…A mis compañeros y amigos de cinco años de estudio y esfuerzo, especialmente a Lisandra, Danay M, Arelys, Dayami, Lissette, Yinet, Danay O, Mayensi y Elvis.
…A los profesores del proyecto CICPC Yunexis, Miguel Angel, Yenisleydi y Sacha, por sus recomendaciones.
De una manera u otra a todas las personas y organizaciones sin la cual este trabajo no hubiese sido posible.
A todos ellos… Gracias.
DEDICATORIA
Dedico este trabajo a mis maravillosos padres,
A mi mamá y a mi papá, por estar siempre a mi lado, por apoyarme continuamente y, por darme su amor incondicional y sobre todo porque hicieron posible que llegara este momento, pues sin ellos no lo hubiera logrado.
Los quiero mucho.
RESUMEN:
La Ingeniería del Software, definida como el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software, lleva marcando las pautas de como se debe trabajar en el desarrollo de sistemas de información dentro de la ingeniería informática. La Ingeniería Web es un área de la Ingeniería del Software que trabaja en el entorno de los sistemas Web. La solución que se brinda en este trabajo es cómo modelar un portal, a través de la ingeniería de requerimientos, basado en la metodología RUP y siguiendo las pautas que brinda UML, con el objetivo de identificar los requerimientos funcionales y no funcionales que debe presentar el portal para facilitar con ello una mejor construcción del mismo y que responda tanto a los intereses de los usuarios como a los de la institución.
ÍNDICE
Introducción _______________________________________________________________ 1 Capítulo 1 Fundamentación del tema __________________________________________ 4
1.1 Introducción ... 4
1.2 ¿Qué es un Portal Web? ... 4
1.3 Análisis de Portales Web existentes ... 4
1.4 Ingeniería de Requerimientos ... 6
1.4.1 Requerimientos ... 7
1.4.2 Técnicas de Recopilación de Información. ... 8
1.4.2.1 Selección de las técnicas de recopilación de la información. ... 11
1.5 Metodologías de Desarrollo ... 11
1.5.1 Metodologías Web ... 12
1.5.2 Metodologías tradicionales y ágiles ... 19
1.5.3 Características de RUP y XP ... 21
1.5.3.1 El Proceso Unificado de Modelado (RUP) ... 21
1.5.3.2 La Programación Extrema (XP) ... 24
1.5.4 RUP y XP en el Flujo de Trabajo de Requerimiento ... 25
1.5.5 Fundamento de la selección de la metodología de desarrollo ... 27
1.6 Leguaje de Modelado ... 28
1.7 Herramientas de Modelado ... 30
1.7.1 Rational Rose ... 31
1.7.2 Visual Paradigm ... 31
1.7.3 Selección de la Herramienta de Modelado. ... 33
1.8 Propuesta de Solución ... 33
1.9 Otras Herramientas a utilizar ... 33
1.10 Conclusiones ... 35
Capítulo 2 Modelo de Dominio ______________________________________________ 36 2.1 Introducción ... 36
2.2 Modelo Conceptual ... 36
2.2.1 Modelo de Negocio ... 36
2.2.2 Modelo de Dominio ... 37
2.2.3 ¿Modelo de Negocio o Modelo de Dominio? ... 37
2.3 Modelo de Dominio ... 38
2.4 Descripción de los conceptos del Modelo de Dominio ... 39
2.5 Conclusión ... 41
Capítulo 3 Requerimientos _________________________________________________ 42 3.1 Introducción ... 42
3.2 Requerimientos ... 42
3.2.1 Requerimientos Funcionales: ... 42
3.2.2 Requerimientos No Funcionales ... 46
3.3 Módulos del sistema ... 49
3.4 Modelo de Casos de Uso del Sistema ... 50
3.4.1 Definición de los Actores del Sistema ... 51
3.4.2 Casos de Uso del Sistema ... 52
3.4.2.1 Gestionar Elementos de la Mediateca ... 52
3.4.2.2 Gestionar Reseñas de Tesis ... 53
3.4.2.3 Gestionar Publicidad Institucional ... 56
3.4.2.4 Gestionar Proyectos Más Importantes del CICPC ... 57
3.4.2.5 Gestionar Preguntas Frecuentes ... 59
3.4.2.6 Gestionar Eventos del CICPC... 60
3.4.2.7 Gestionar Enlaces a Sitios Externos ... 61
3.4.2.8 Gestionar Elementos del Directorio ... 63
3.4.2.9 Gestionar Casos Cangrejos ... 64
3.4.2.10 Gestionar Boletín Informativo ... 66
3.4.2.11 Actualizar Información Institucional ... 67
3.4.2.12 Gestionar Temas de Asesoría Jurídica ... 68
3.4.2.13 Publicar Respuesta de Asesoría Jurídica... 70
3.4.2.14 Suscribirse al Boletín Informativo ... 71
3.4.2.15 Enviar Pregunta a Asesoría Jurídica ... 72
3.4.2.16 Consultar vehículo recuperado ... 73
3.4.2.17 Gestionar Elementos del Organigrama ... 74
3.4.2.18 Actualizar Reseña Histórica del CICPC ... 75
3.4.2.19 Gestionar Preguntas y Respuestas de Asesoría Jurídica ... 76
3.4.2.20 Gestionar Reseñas de Libros ... 77
3.4.4 Diccionario de Datos ... 79
3.5 Conclusión ... 82 Conclusiones _____________________________________________________________ 83
Recomendaciones _________________________________________________________ 84 Referencias Bibliográficas ___________________________________________________ 85 Bibliografía _______________________________________________________________ 87 Glosario de Términos _______________________________________________________ 89 Anexos ___________________________________________________________________ 90
1
INTRODUCCIÓN
La seguridad ciudadana es uno de los temas centrales en las agendas públicas de varios países de América Latina, Venezuela no es la excepción. La inseguridad de la población venezolana constituye una de las principales preocupaciones a nivel nacional. El Cuerpo de Investigaciones Científicas, Penales y Criminalísticas (CICPC) de la República Bolivariana de Venezuela, aún cuando es un organismo destinado a la investigación de los delitos de orden público en sus diferentes manifestaciones, que procede una vez ocurrido el hecho punible; no puede permanecer indiferente ante el auge delictivo en Venezuela, por esta razón considera un deber ineludible alertar y orientar a todos los ciudadanos sobre cómo enfrentar los delitos.
Para mejorar el enfrentamiento al delito, el CICPC lleva a cabo un proyecto de modernización que abarca el mejoramiento de las condiciones de trabajo de los funcionarios y el desarrollo de una nueva estrategia de comunicación que permita elevar el prestigio de la institución ante la población venezolana. Dentro de la actual estrategia de comunicación, el CICPC cuenta con una revista y un portal Web que no cumple con todas las expectativas de la institución pues tiene prestaciones de servicios limitados. Está compuesto de páginas estáticas que no aportan ningún valor añadido, su diseño gráfico es pobre y da una imagen poco profesional. Además que se hace difícil su mantenimiento, al tener que hacer cambios también en el diseño. Toda esta situación provoca que el portal Web no refleje la actualidad de la institución y la población esté desinformada sobre las labores que realiza y de cómo enfrentarse preventivamente al delito, además produce desorientación sobre cómo actuar o a dónde dirigirse ante una situación delictiva.
Se hace necesario entonces abrir una nueva forma de comunicación con la población, para escuchar sus inquietudes, sus sugerencias y poder sondear de esta forma el estado de opinión con respecto al trabajo de la institución. Por lo que una parte importante dentro de la estrategia comunicacional que lleva a cabo el CICPC es precisamente el desarrollo de un nuevo portal Web fácil de mantener y actualizar, que brinde servicios que estén orientados al uso de la población, tanto venezolana como extranjera y mejorar la asesoría en materia de orientación general, para que los ciudadanos conozcan mejor a quién acudir para realizar una denuncia.
2 Este trabajo surge como necesidad de dar solución a las situaciones antes expuestas; por lo que el problema consiste en: ¿Cómo modelar el Portal Web del CICPC de manera que mejore los servicios que brinda a la población?
El objeto de estudio de este trabajo es el Modelado de Portales Web y de ello resulta el campo de acción que es el modelado del Portal Web del CICPC.
El objetivo general del trabajo será: Modelar el Portal Web del CICPC, aplicando la Ingeniería de Requerimientos, para mejorar los servicios que debe brindar.
Por Tanto la idea a defender es Modelar el Portal Web del CICPC aplicando la Ingeniería de Requerimientos, facilitando el desarrollo de un portal que corresponda con los intereses del pueblo y de la institución.
Para darle cumplimiento a dicho objetivo, es necesario realizar una serie de tareas de investigación como son:
Investigar las tendencias actuales para la modelación de un Portal Web.
Estudiar el proyecto técnico definido para el proyecto CICPC.
Analizar la solución existente del Portal actual, para definir los problemas que presenta y los perfeccionamientos que necesita.
Definir los servicios informativos y participativos que brindará el portal.
Investigar el flujo de trabajo de ingeniería de requerimientos del proceso unificado de modelado (RUP).
Investigar las diferentes técnicas de recopilación de información para la captura de requisitos.
Especificar los requisitos funcionales y no funcionales del software.
Agrupar los requerimientos según sus similitudes en casos de usos y modelar una propuesta de módulos a realizar.
3 A continuación se estructura el trabajo investigativo realizado, el cual se dividió en tres capítulos:
Capítulo1 Fundamentación del tema: Se realiza un análisis de las características que presentan algunos portales Web que se identifican con el del CICPC. Se exponen las técnicas clásicas utilizadas en el mundo de la ingeniería de requisitos y se realiza un estudio comparativo de las metodologías y herramientas de modelado más usadas en la actualidad.
Capítulo2 Modelo de Negocio: Se describen los conceptos de Modelo de Negocio y de Modelo de Dominio. Se elabora una descripción de los conceptos que están presentes en el portal.
Capítulo3 Requerimientos: Se especifican los requerimientos funcionales y no funcionales del sistema.
Se identifican y se justifican los actores del mismo y se realiza el diagrama de Casos de Uso y las descripciones de estos.
4
CAPÍTULO 1 FUNDAMENTACIÓN DEL TEMA
1.1 Introducción
En este capítulo se hace un análisis del estado actual de las herramientas, técnicas y las metodologías de desarrollo que pudieran ser adecuadas para la modelación del sistema que se pretende desarrollar.
En algunos casos son necesarias comparaciones que fundamentarán la propuesta final.
1.2 ¿Qué es un Portal Web?
Es un sitio Web cuyo objetivo es ofrecer al usuario, de forma fácil e integrada, el acceso a una serie de recursos y de servicios. Principalmente están dirigidos a resolver necesidades específicas de un grupo de personas o de acceso a la información y servicios de a una institución pública o privada. El término portal tiene como significado puerta grande, y precisamente su nombre hace referencia a su función u objetivo: es el punto de partida de un usuario que desea entrar y realizar búsquedas en la Web. Se puede decir que un portal ofrece servicios para la navegación en Internet, logrando incrementar la intensidad de tráfico en el mismo. (Glosario de Informática e Internet)
1.3 Análisis de Portales Web existentes
Para desarrollar un buen modelado del Portal CICPC es necesario hacer un análisis de sitios publicados por instituciones homólogas al CICPC. Esto permite conocer qué contenidos y servicios son comúnmente publicados en sitios con características similares al que se pretende desarrollar.
Fueron identificados 7 sitios o portales Web que responden a instituciones policiales con características similares al Cuerpo de Investigaciones Científicas, Penales y Criminalísticas (CICPC).
Estos son:
1. Policía Metropolitana de Cali.
2. Policía de Investigaciones de Chile.
3. Policía Nacional del Perú.
4. Policía Nacional de República Dominicana.
5. FBI de EEUU.
5 6. Policía Inglesa.
7. Policía Española.
Para la comparación, se siguieron las pautas propuestas por los autores de Guía para el Desarrollo de Sitios Web Gobierno de Chile. A través de estas pautas se ofrecen los elementos que deben ser revisados en un sitio Web para establecer la calidad de los contenidos. Por cada uno de los puntos descritos, se debe entregar la información que se indica.
Nombre de la institución: Indica la identificación del sitio.
URL del Sitio Web: Dirección Web del sitio.
País de Origen: País de origen de la institución que ha generado el sitio Web.
Breve Descripción del Sitio: Indica de qué se trata el sitio Web que se revisa, con sus principales características; también se debe informar de las características de la institución.
Imagen de Pantalla Principal: Incluye una imagen de la pantalla de inicio del sitio Web.
Estructura de la información: Indica de qué manera está estructurada la información que se entrega en el sitio Web. Se pueden incluir imágenes que apoyen la descripción.
Tipos de Contenidos: Indica de qué se tratan los contenidos y si todos pertenecen a la institución o toma de terceros. Señalar además en qué niveles está estructurado, idealmente apoyándose con la estructura descrita por el Mapa del Sitio.
Calidad de Contenidos: Se emite un juicio sobre la forma de presentar los contenidos y sobre la pertinencia de su descripción para los objetivos que tiene la institución.
Servicios interactivos: Indica qué tipo de elementos interactivos se ofrecen en el sitio Web.
Resultados generales
Luego de un análisis de los contenidos y servicios que brindan los sitios de estas instituciones similares al CICPC, se hace un listado de aquellos que son comunes a todos los sitios y junto a ellos algunos otros que se consideran importantes que tenga el nuevo portal.
Tipos de Contenidos
Información institucional (Misión, Visión y Valores, Objetivos estratégicos, Reseña Histórica, Nuestros símbolos, Directiva).
Información de contacto (de la institución, administrador del sitio, dependencias).
Información sobre direcciones territoriales (información geográfica de las dependencias).
6 Noticias del acontecer de la institución. Novedades.
Enlaces a sitios relacionados con la institución.
Documentos del marco Jurídico.
Boletín Informativo.
Acceso a Revistas relacionadas con el CICPC.
Recomendaciones al ciudadano sobre algunas de sus preocupaciones por la seguridad en todas las esferas.
Preguntas más frecuentes.
Mediateca: contiene archivos de Imágenes: fotografías de actividades Institucionales; Videos:
sobre actividades importantes y operativos destacados; Audio: discursos, entrevistas y mensajes de interés; Texto PDF: Libros y revistas de interés Institucional.
Información de reclutamiento.
Información sobre denuncias, dónde acudir para realizar las mismas.
Información sobre los Eventos que realiza el CICPC.
Servicios Interactivos
Buscador interno del sitio.
Servicio de contacto con la institución.
Consultar vehículos recuperados.
Preguntas sobre algún tema de Asesoría Jurídica.
El análisis de homólogos es una herramienta muy útil ya que su resultado sirve de guía en el seguimiento de aquellos sitios que muestran las mejores prácticas adaptables a las necesidades del producto en cuanto a tipos de contenidos, estructuras, niveles de información, entre otros elementos.
Por lo que permitió establecer los contenidos y los servicios del portal escritos anteriormente. Los mismos se organizaron en un mapa conceptual del sitio, donde inicio es la página principal, para ver su estructura organizativa por niveles y secciones (Ver Anexo 2).
1.4 Ingeniería de Requerimientos
Desde hace varias décadas, se ha introducido en el desarrollo de software, estándares, metodologías, herramientas para condicionar el éxito de todo proyecto. Pero, cuál puede ser la causa de que fallan aún muchos proyectos, o por qué muchos software carecen de la calidad requerida. En gran parte es
7 por la incorrecta gestión de requisitos, que es de gran importancia dentro de dicho proceso de desarrollo.
La Ingeniería de Requerimientos cumple un papel primordial en el proceso de producción de software, ya que enfoca un área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema; de esta manera, se pretende minimizar los problemas relacionados al desarrollo de sistemas.
Algunos conceptos de Ingeniería de Requerimientos son:
"Ingeniería de Requerimientos es la disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el sistema". (Boehm 1979)
"Ingeniería de Requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes , ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones". (Starts Guide 1987)
"Enfoque sistémico para recolectar, organizar y documentar los requerimientos del sistema; es también el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto". (Rational Software)
1.4.1 Requerimientos
La IEEE Standard Glossary of Engineering Terminology, define el término requerimiento como:
Condición o capacidad que necesita un usuario para resolver un problema o lograr un objetivo.
Condición o capacidad que tiene que ser alcanzada o poseída por un sistema o componente de un sistema para satisfacer un contrato, estándar, u otro documento impuesto formalmente.
Es importante no perder de vista que un requerimiento debe ser:
Especificado por escrito: Como todo contrato o acuerdo entre dos partes.
8 Posible de probar o verificar. Si un requerimiento no se puede comprobar, entonces ¿cómo se
sabe si se cumplió con él o no?
Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.
Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.
Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector.
Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales.
Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.
1.4.2 Técnicas de Recopilación de Información.
En la medida que transcurren los años de experiencia en el desarrollo de software, se reconoce el valor de la Ingeniería de Requisitos pues si no se realiza la misma de la forma más correcta y suficiente, puede provocar grandes problemas en la medida que trascurre el proceso de desarrollo. Es por esta razón que se fundan técnicas específicas dedicadas especialmente para mejorar el proceso de de gestión de requisitos del software.
Las técnicas de la recopilación de informaciones más usadas para la captura de requisitos son:
Entrevistas: Técnica de recopilación de información que no constituye un interrogatorio, sino una forma de conversación. Durante la misma no debe limitarse a informar los puntos de interés sino que debe aprovechar la oportunidad para explicar el trabajo a los usuarios y crear un clima de intercambio sociológico favorable. Resultan una técnica muy aceptada dentro de la ingeniería de requisitos y su uso está ampliamente extendido. Las entrevistas le permiten al analista tomar conocimiento del problema y comprender los objetivos de la solución buscada. A través de esta técnica el equipo de
9 trabajo se acerca al problema de una forma natural. Existen muchos tipos de entrevistas y son muchos los autores que han trabajado en definir su estructura y dar guías para su correcta realización. (Durán, Bernádez, Ruiz, & Toro, 1999) y (Pan, Zhu, & Jhonson, 2001).
A pesar de que las entrevistas son esenciales en el proceso de la captura de requisitos y con su aplicación el equipo de desarrollo puede obtener una amplia visión del trabajo y las necesidades del usuario, es necesario destacar que no es una técnica sencilla de aplicar (Pan, Zhu, & Jhonson, 2001).
Requiere que el entrevistador sea experimentado y tenga capacidad para elegir bien a los entrevistados y obtener de ellos toda la información posible en un período de tiempo siempre limitado.
Aquí desempeña un papel fundamental la preparación de la entrevista.
Básicamente, la estructura de la entrevista abarca tres pasos: identificación de los entrevistados, preparación de la entrevista, realización de la entrevista y documentación de los resultados (protocolo de la entrevista).
Existen diferentes tipos de entrevistas, entre las que se puede mencionar:
Entrevistas de Cuestionarios: Este tipo de entrevistas recomienda que se genere un cuestionario de preguntas, el cual será aplicado al cliente para comenzar la captura de requisitos. Se define como un formulario de preguntas abiertas o cerradas en dependencia de los objetivos del mismo.
Entrevistas Abiertas: Este tipo de entrevistas son del tipo que realizan los psicólogos. La idea es que el ingeniero de requisitos permita que el Cliente le vaya platicando su problemática y el ingeniero de Software lo va a ir guiando a través de la platica para ir determinando los requisitos del sistema.
Entrevistas en grupos de desarrollo: Este tipo de entrevistas recomienda formar grupos específicos con el personal del cliente. Estos grupos tendrán en común algún área de trabajo o especialidad. EL objetivo es poder contar con los expertos en cierta área de la empresa para poder llegar en conjunto a la especificación de requisitos.
Discusiones: Este tipo de entrevistas pretende que el Ingeniero de Requisitos sostenga una discusión con el Cliente sobre su problemática para tratar de determinar en conjunto los requisitos del sistema.
10 Análisis de usabilidad: Técnica basada en el análisis de varios elementos de una entidad Web, en vistas a determinar qué tan navegable es o qué aspectos a favor o en contra tiene referente a la accesibilidad y la usabilidad que posee el sitio analizado.
Análisis documental: Técnica basada en la revisión analítica de documentación o bibliografía relevante para un tema en particular. Se centra en el estudio de la información que se produce en el ambiente productivo de la institución. Su objetivo es asimilar la información recopilada hasta el momento y transformarla en conocimiento dejándola plasmada en los formatos establecidos para el análisis, exposición y asimilación de la misma por clientes, desarrolladores, usuarios y terceros. En síntesis es una técnica que recomienda que se realice un estudio exhaustivo de todos los documentos e informes elaborados, en donde se identifican las funcionalidades del sistema a elaborar.
Taller: Técnica de trabajo para grupos multidisciplinarios en la recopilación de información, con el objetivo de construir conocimiento, validar o demostrar un entendimiento común de una determinada información.
Tormenta de ideas: Es también una técnica de reuniones en grupo cuyo objetivo es que los participantes muestren sus ideas de forma libre (Raghavan, Zelesnik, & Ford, 1994). Consiste en la mera acumulación de ideas y/o información sin evaluar las mismas. El grupo de personas que participa en estas reuniones no debe ser muy numeroso (máximo 10 personas), una de ellas debe asumir el rol de moderador de la sesión, pero sin carácter de controlador. Como técnica de captura de requisitos es sencilla de usar y de aplicar, contrariamente al JAD, puesto que no requiere tanto trabajo en grupo como éste.
Además suele ofrecer una visión general de las necesidades del sistema, pero normalmente no sirve para obtener detalles concretos del mismo, por lo que suele aplicarse en los primeros encuentros.
JAD: (Joint Application Development/Desarrollo conjunto de aplicaciones):
Esta técnica resulta una alternativa a las entrevistas. Es una práctica de grupo que se desarrolla durante varios días y en la que participan analistas, usuarios, administradores del sistema y clientes (IBM, 1997). Está basada en cuatro principios fundamentales: dinámica de grupo, el uso de ayudas visuales para mejorar la comunicación, mantener un proceso organizado y racional y una filosofía de documentación WYSIWYG, durante la aplicación de la técnica se trabajará sobre lo que se generará.
Tras una fase de preparación del JAD al caso concreto, el equipo de trabajo se reúne en varias sesiones. En cada una de ellas se establecen los requisitos de alto nivel a trabajar, el ámbito del
11 problema y la documentación. Durante la sesión se discute en grupo sobre estos temas, llegándose a una serie de conclusiones que se documentan. En cada sesión se van concretando más las necesidades del sistema.
Esta técnica presenta una serie de ventajas frente a las entrevistas tradicionales, ya que ahorra tiempo al evitar que las opiniones de los clientes se tengan que contrastar por separado, pero requiere un grupo de participantes bien integrados y organizados.
1.4.2.1 Selección de las técnicas de recopilación de la información.
Ninguna técnica es efectiva por sí misma, requiere ser combinada con otras para lograr un resultado productivo. Por ello se usa la unión de varias de ellas como son el Análisis de usabilidad, que permite determinar la estructura y la organización del contenido del portal, así como examinar cuán usable y accesible es el sitio. Los Talleres que ayudan a organizar el trabajo y a entender el proceso de modelado. Por último las Entrevistas, dentro de las mismas es escogida la del tipo discusiones que posibilita obtener cuales son las necesidades del cliente y conocer las nuevas peticiones y exigencias del mismo.
1.5 Metodologías de Desarrollo
Desarrollar un buen software depende de un sinnúmero de actividades y etapas, donde el impacto de elegir la mejor metodología para un equipo en un determinado proyecto, es trascendental, para el éxito del producto. El papel preponderante de las metodologías es sin duda esencial en un proyecto y el paso inicial, que debe encajar en el equipo, guiar y organizar actividades que conlleven a las metas trazadas en el grupo
La selección de la metodología de desarrollo, es una decisión muy importante ya que todo desarrollo de sistemas se torna dificultoso y riesgoso si no se lleva un control mediante una metodología, para así mantener a los clientes o usuarios satisfechos con los resultados.
Muchas veces realizamos el diseño del software de manera rígida, con los requerimientos que el cliente nos solicitó, de tal manera que cuando el cliente en la etapa final (etapa de prueba), solicita un cambio se nos hace muy difícil realizarlo, pues si se hace, altera muchas cosas que no habíamos previsto, y es justo éste, uno de los factores que ocasiona un atraso en el proyecto y por tanto la incomodidad del desarrollador por no cumplir con el cambio solicitado y el malestar por parte del cliente por no tomar en cuenta su pedido. Obviamente para evitar estos incidentes se debe haber
12 llegado a un acuerdo formal con el cliente, al inicio del proyecto, de tal manera que cada cambio o modificación no perjudique al desarrollo del mismo.
Existen diferentes metodologías para el modelado de aplicaciones, de las cuales se realiza una selección de acuerdo a las características del sistema que se va a modelar. Se puede decir que una metodología es un conjunto de procedimientos, técnicas y ayudas a la documentación para el desarrollo de productos software.
1.5.1 Metodologías Web
Están las metodologías para la construcción de aplicaciones Web, sus esfuerzos se centran mayoritariamente en la etapa de modelado conceptual, tratando con menor profundidad la especificación de requisitos (Escalona & Koch, 2004). Una aplicación Web no deja de ser una aplicación software, y por tanto, debe dar soporte también a requisitos funcionales así como a características no funcionales.
A continuación se describen alguna de estas metodologías y se explica solamente como trabajan en la especificación de requisitos.
SOHDM: Scenario-based Object-Oriented Hypermedia Design Methodology
Esta propuesta presenta la necesidad de disponer de un proceso que permita capturar las necesidades del sistema. Para ello, propone el uso de escenarios (Lee, Lee, & Yoo, 1998). El proceso de definición de requisitos parte de la realización de un diagrama de contexto tal y como se propone en los diagramas de flujos de datos (DFD) (Yourdon, 1989). En este diagrama de contexto se identifican las entidades externas que se comunican con el sistema, así como los eventos que provocan esa comunicación. La lista de eventos es una tabla que indica en qué eventos puede participar cada entidad.
Por cada evento diferente, SOHDM propone elaborar un escenario. Éstos son representados gráficamente mediante los denominados SACs (Scenario Activity Chart). Cada escenario describe el proceso de interacción entre el usuario y el sistema cuando se produce un evento determinado, especificando el flujo de actividades, los objetos involucrados y las transacciones realizadas. SOHDM propone un proceso para conseguir a partir de estos escenarios el modelo conceptual del sistema, que
13 es representado mediante un diagrama de clases. El proceso de SOHDM continúa reagrupando estas clases para conseguir un modelo de clases navegacionales del sistema.
WSDM: Web Site Design Method
WSDM es una propuesta para el desarrollo de sitios Web, en la que el sistema se define en base a los grupos de usuarios. Su proceso de desarrollo se divide en cuatro fases: modelo de usuario, diseño conceptual, diseño de la implementación e implementación (De Troyer & Leune, 1997). La fase que más repercusión tiene para este trabajo es la primera en la que intenta detectar los perfiles de usuarios para los cuales se construye la aplicación. Para ello, se deben realizar dos tareas:
Clasificación de usuarios: en este paso se deben identificar y clasificar a los usuarios que van a hacer uso del sistema. Para ello, WSDM propone el estudio del entorno de la organización donde se vaya a implantar el sistema y los procesos que se vayan a generar, describiendo las relaciones entre usuarios y actividades que realizan estos usuarios. Para la representación gráfica de estas relaciones WSDM propone una especie de mapas de conceptos de roles y actividades.
Descripción de los grupos de usuarios: en esta segunda etapa se describen con más detalles los grupos de usuarios detectados en la etapa anterior. Para ello, se debe elaborar un diccionario de datos, en principio con formato libre, en el que indican los requisitos de almacenamiento de información, requisitos funcionales y de seguridad para cada grupo de usuarios. El resto de las fases del proceso de WSDM se hacen en base a la clasificación de usuarios que se realiza en esta primera etapa.
RNA: Relationship-Navegational Analysis
RNA plantea una secuencia de pasos para el desarrollo de aplicaciones Web, centrándose fundamentalmente en el flujo de trabajo de análisis. El proceso de trabajo que presenta RNA se basa en la realización de las siguientes fases:
Fase 1- Análisis del entorno: el propósito de esta fase es el de estudiar las características de la audiencia. Consiste en determinar y clasificar a los usuarios finales de la aplicación en grupos según sus perfiles.
14 Fase 2- Elementos de interés: en esta fase se listan todos los elementos de interés de la aplicación.
Por elementos de interés se entienden los documentos, las pantallas que se van a requerir, la información, etc.
Fase 3- Análisis del conocimiento: esta fase consiste en desarrollar un esquema que represente a la aplicación. Para ello RNA propone identificar los objetos, los procesos y las operaciones que se van a poder realizar en la aplicación, así como las relaciones que se producen entre estos elementos.
Fase 4- Análisis de la navegación: en esta fase el esquema obtenido en la fase anterior es enriquecido con las posibilidades de navegación dentro de la aplicación.
Fase 5- Implementación del análisis: una vez obtenido el esquema final en el que ya se encuentran incluidos los aspectos de navegación, se pasa el esquema a un lenguaje entendible por la máquina.
(Bieber & Galnares, 1998)
La propuesta de RNA es quizás una de las que más ha resaltado la necesidad de trabajar con la especificación de requisitos, incluyendo tareas como el análisis del entorno y de los elementos de interés. Además, resulta interesante pues plantea la necesidad de analizar los requisitos conceptuales de manera independiente a los navegacionales.
HFPM: Hypermedia Flexible Process Modeling
La propuesta de HFPM describe un proceso detallado que cubre todo el ciclo de vida de un proyecto software. HFPM propone un total de trece fases para las cuales se especifican a su vez una serie de tareas. Para este estudio es principalmente relevante la primera fase, denominada de modelado de requisitos, cuyas tareas son las siguientes:
Descripción breve del problema. No indica ninguna técnica concreta pudiendo realizarse esta descripción mediante el lenguaje natural.
Descripción de los requisitos funcionales mediante casos de uso.
Realizar un modelo de datos para esos casos de uso, proponiendo el uso de un modelo de clases.
Modelar la interfaz de usuario. Para ello, propone el uso de sketches y prototipos que permitan presentar los datos al usuario.
15 Modelar los requisitos no funcionales. En éstos incluyen la navegación, la seguridad, etc.
(Olsina, 1998)
Se puede observar que la propuesta de HFPM ofrece mayor detalle a la hora de realizar el tratamiento de los requisitos. Sin embargo, no ofrece técnicas concretas, especialmente a la hora de trabajar con los requisitos no funcionales.
OOHDM: Object Oriented Hypermedia Design Model
OOHDM es una propuesta metodológica ampliamente aceptada para el desarrollo de aplicaciones de la Web (Schwabe & Rossi, 1998). En sus comienzos no contemplaba la fase de captura y definición de requisitos, pero actualmente propone el uso de User Interaction Diagrams (UIDs) (Vilain, Schwabe, &
Sieckenius, 2000). Esta propuesta parte de los casos de uso, que considera una técnica muy difundida, ampliamente aceptada y fácilmente entendible por los usuarios y clientes no expertos, pero que resulta ambigua para el equipo de desarrollo en fases posteriores del ciclo de vida. Igualmente, resalta la necesidad de empezar el diseño del sistema, especialmente en los entornos Web, teniendo un claro y amplio conocimiento de las necesidades de interacción, o lo que es lo mismo de la forma en la que el usuario va a comunicarse con el sistema.
Partiendo de estas dos premisas, OOHDM propone que la comunicación con el usuario se realice utilizando los casos de uso y a partir de ellos los analistas elaboran los UIDs. Estos UIDs son modelos gráficos que representan la interacción entre el usuario y el sistema, sin considerar aspectos específicos de la interfaz. El proceso de transformación de un caso de uso a un UIDs es descrito detalladamente en la propuesta.
OOHDM centra el desarrollo de un sistema de información Web entorno al modelo conceptual de clases. Este diagrama debe surgir de los requisitos que se definan del sistema, pero los casos de uso resultan demasiado ambiguos para ello. Así, propone refinar el proceso de desarrollo descrito en UML, de forma que de los casos de uso se generen los UIDs que concreten más la definición de los requisitos para, a partir de ellos, obtener el diagrama conceptual. En algunos de los primeros trabajos, OOHDM propone la descripción de escenarios en forma textual y gráfica para cada tipo de usuario, como etapa previa al diseño de la navegación.
16 UWE: UML-Based Web Engineering
Es una propuesta metodológica basada en el Proceso Unificado y UML para el desarrollo de aplicaciones Web (Jacobson, El Proceso Unificado de Desarrollo de Software). UWE cubre todo el ciclo de vida de este tipo de aplicaciones, centrando además su atención en aplicaciones personalizadas (adaptivas) (Hennicker & Koch, 2000). Para este trabajo, nos interesa principalmente analizar la propuesta de captura de requisitos de UWE. Esta metodología distingue entre la tarea de validar requisitos, definir y validar los requisitos. El resultado final de la captura de requisitos en UWE es un modelo de casos de uso acompañado de documentación que describe los usuarios del sistema, las reglas de adaptación, los casos de uso y la interfaz.
UWE clasifica los requisitos en dos grandes grupos: funcionales y no funcionales. Los requisitos funcionales tratados por UWE son:
Requisitos relacionados con el contenido.
Requisitos relacionados con la estructura.
Requisitos relacionados con la presentación.
Requisitos relacionados con la adaptación.
Requisitos relacionados con los usuarios.
Además, UWE propone como técnicas apropiadas para la captura de los requisitos de un sistema Web las entrevistas, los cuestionarios y los checklists y los casos de uso, los escenarios y el glosario para la definición de requisitos. Para la validación propone walk-throughs, auditorias y prototipos.(Entra las ventajas más importantes de UWE es su uso 100% UML.)
W2000
W2000 supone una propuesta que amplía la notación de UML con conceptos para modelar elementos de multimedia heredados de la propuesta HDM (Hypermedia Design Model) (Garzoto, Schwabe, &
Paolini, 1993). El proceso de desarrollo de W2000 se divide en tres etapas: análisis de requisitos, diseño de hipermedia y diseño funcional. El primero de ellos es el que resulta interesante para este trabajo.
17 La especificación de requisitos en W2000 se divide en dos subactividades: análisis de requisitos funcionales y análisis de requisitos navegacionales. La especificación de requisitos comienza haciendo un estudio de los diferentes roles de usuario que van a interactuar con el sistema. Cada actor potencialmente distinto tendrá su modelo de requisitos de navegación y de requisitos funcionales (Baresi, Garzotto, & Paolini, 2000). El modelo de requisitos funcionales es representado como un modelo de casos de uso tal y como se propone en UML. En él se representa la funcionalidad principal asociada a cada rol y las interacciones que se producen entre el sistema y cada rol. El segundo modelo consiste en otro diagrama de casos de uso pero que no representa funcionalidad sino posibilidades de navegación de cada actor. La representación gráfica es realizada con una extensión de UML.
UWA: Ubiquituos Web Applications
UWA ha nacido de la colaboración entre diferentes grupos de trabajo, por lo que resulta realmente una agrupación de propuestas y técnicas. En concreto, la propuesta de W2000 se encuentra incluida en UWA. Sin embargo, W2000 ha sido incluida en UWA sólo en la fase de diseño hipermedia, siendo ambas propuestas diferentes en la fase de definición de requisitos. Por esta razón han sido incluidos en este trabajo de forma separada.
El proceso de captura de requisitos en UWA comienza definiendo los diferentes roles de usuario que pueden interactuar con el sistema, los objetivos globales de éste y la relación entre ellos. El proceso continúa haciendo un refinamiento de esos objetivos globales, concretándolos en subobjetivos (UWA, 2001).
Estos subobjetivos son estudiados y refinados para detectar conflictos entre ellos. De esta forma, se concretizan aún más dividiéndolos en requisitos. Los requisitos son clasificados en varios tipos: de contenido, de estructura de contenido, de acceso, de navegación, de presentación, de operaciones de usuario y de operaciones del sistema.
De esta forma, los requisitos se van refinando hasta que solo pertenezcan a uno de estos grupos. Y finalmente los requerimientos son asignados a artefactos de diseño o a reglas de customización.
Para definir los objetivos, UWA propone una notación propia, basada en una plantilla. La definición de los actores y la relación con los objetivos se hace usando un diagrama basado en casos de uso. Por último, para definir y refinar los subobjetivos y los requisitos, utilizan una notación gráfica propia que denominan grafo de refinamiento de objetivos, el refinamiento de este grafo permite ir representando la
18 relación entre los requisitos y hacer un seguimiento para validar la consecución de los objetivos del sistema. Una vez que los requisitos son detectados, hacen uso de XML para definirlos de una manera formal.
NDT - Navigational Development Techniques
NDT es una técnica para especificar, analizar y diseñar el aspecto de la navegación en aplicaciones Web (Escalona, Torres, & Mejías, 2002). Para este trabajo, solo es relevante la propuesta que ofrece para la definición y captura de requisitos. El flujo de especificación de requisitos de NDT comienza con la fase de captura de requisitos y estudio del entorno. Para ello, plantea el uso de técnicas como las entrevistas o el brainstorming (tormenta de ideas) y JAD. Tras esta fase, se propone la definición de los objetivos del sistema. En base a estos objetivos, el proceso continúa definiendo los requisitos que el sistema debe cumplir para cubrir los objetivos marcados. NDT clasifica los requisitos en:
Requisitos de almacenamiento de información.
Requisitos de actores.
Requisitos funcionales.
Requisitos de interacción, representados mediante:
• Frases, que recogen cómo se va a recuperar la información del sistema utilizando un lenguaje especial denominado BNL (Bounded Natural Language) (Brisaboa, Penabad, Places, & Rodríguez, 2001).
• Prototipos de visualización, que representan la navegación del sistema, la visualización de los datos y la interacción con el usuario.
Requisitos no funcionales.
Todo el proceso de definición y captura de requisitos y objetivos que propone NDT se basa principalmente en plantillas o patrones, pero también hace uso de otras técnicas de definición de requisitos como son los casos de uso y los glosarios. La propuesta ofrece una plantilla para cada tipo de requisito, lo que permite describir los requisitos y objetivos de una forma estructurada y detallada.
Algunos de los campos de los patrones son cerrados, es decir, solo pueden tomar valores predeterminados. Estos campos permiten que en el resto del proceso del ciclo de vida de NDT se
19 puedan conseguir resultados de forma sistemática. El flujo de trabajo de especificación de requisitos termina proponiendo la revisión del catálogo de requisitos y el desarrollo de una matriz de trazabilidad que permite evaluar si todos los objetivos han sido cubiertos en la especificación. La propuesta viene acompañada de una herramienta case, NDT-Tool, que facilita la cumplimentación de los patrones y que permite automatizar el proceso de consecución de resultados.
Design-driven Requirements Elicitation
Es parte del proceso design-driven que proponen para el desarrollo de aplicaciones en el entorno Web.
La propuesta consiste en realizar la captura, definición y validación de requisitos durante el proceso de diseño. Ello hace necesario que las actividades de diseño sean realizadas de modo que los requerimientos pueden ser tratados y administrados. El proceso se basa en el uso de prototipos para ayudar al cliente en la exploración de las posibles soluciones y de los problemas que tienen que ser resueltos. Los usuarios o clientes definen sus requerimientos basándose en la observación o trabajo con estos prototipos. Es un proceso iterativo que consiste en reducir la incertidumbre del cliente (Lowe
& Eklund, 2002).
El ciclo tiene tres fases: evaluación, especificación y construcción. Este proceso fue definido sobre la base de un exhaustivo análisis de buenas prácticas en el desarrollo de aplicaciones comerciales para el entorno Web. Esta metodología trata a todos los requisitos de la misma manera; estos requisitos son: de contenido, de protocolo de interfaces, de estructura navegacional, de representación interna de datos, de versionamiento, de control de cambios, de seguridad, de gestión de contenido, de acceso de control, de eficiencia, de monitoreo del usuario, de soporte de funcionalidad, de adaptación del sistema, de identificación del usuario y sus derechos de acceso, etc.
En la mayoría de estas propuestas el tratamiento de requisitos ha sido tratado con una menor importancia, ya que centran su trabajo principalmente en las etapas de diseño e implementación.
1.5.2 Metodologías tradicionales y ágiles
Por otra parte se encuentran las metodologías ágiles y las metodologías tradicionales.
Las metodologías tradicionales imponen una disciplina de trabajo sobre el proceso de desarrollo del software, con el objetivo de conseguir un software más eficiente y predecible. Para ello, se hace un especial hincapié en la planificación total de todo el trabajo a realizar y una vez que esta todo
20 detallado, comienza el ciclo de desarrollo del producto software. Este planteamiento está basado en el resto de disciplinas de ingeniería.
Con estas metodologías se lleva trabajando desde hace tiempo y no ha habido en ningún caso ninguna experiencia traumática acerca de su uso. Pero aún así, han recibido diversas críticas, y la más común hace referencia a su carácter excesivamente burocrático. (Cáceres & Marcos)
En contraste a las metodologías mencionadas anteriormente, o sea las tradicionales, durante los últimos años han aparecido las llamadas metodologías ágiles. Las cuales aportan nuevas técnicas y métodos de trabajo para el desarrollo de cada etapa de un software. En general esta metodología hace un balance entre los procesos y el esfuerzo, ya que tratan de centrarse en las cuestiones necesarias sin perderse en las burocráticas.
Las primeras recalcan el uso exhaustivo de documentación durante todo el ciclo del proyecto, mientras que las segundas ponen vital importancia en la capacidad de respuesta a los cambios y al mantener una buena relación con el cliente para llevar al éxito el proyecto.
Se puede analizar con más detalles sus diferencias en la siguiente tabla:
Metodologías Ágiles Metodologías tradicionales
Basada en heurísticas provenientes de prácticas de producción de código
Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo
Impuestas internamente(por el equipo) Impuestas externamente Proceso menos controlado, con pocos
principios
Proceso mucho más controlado, con numerosas políticas y normas El cliente es parte del equipo El cliente interactúa con el equipo de
desarrollo mediante reuniones Grupos pequeños( <10 integrantes) y
trabajando en el mismo sitio
Grupos grandes y posiblemente distribuidos
Menos énfasis en la arquitectura del software La arquitectura del software es esencial y se expresa mediante modelos
No existe contrato tradicional o al menos es bastante flexible
Existe un contrato prefijado
Pocos artefactos y pocos roles Más artefactos y más roles
21 Hasta hace poco el proceso de desarrollo llevaba asociada un marcado énfasis en el control del proceso mediante una rigurosa definición de roles, actividades y artefactos, incluyendo modelado y documentación detallada. Este esquema "tradicional" para abordar el desarrollo de software ha demostrado ser efectivo y necesario en proyectos de gran tamaño (respecto a tiempo y recursos), donde por lo general se exige un alto grado de ceremonia en el proceso.
Sin embargo, este enfoque no resulta ser el más adecuado para muchos de los proyectos actuales donde el entorno del sistema es muy cambiante, y en donde se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad.
En este escenario, las metodologías ágiles emergen como una posible respuesta para llenar ese vacío metodológico. Por estar especialmente orientadas para proyectos pequeños, las metodologías ágiles constituyen una solución a medida para ese entorno, aportando una elevada simplificación que a pesar de ello no renuncia a las prácticas esenciales para asegurar la calidad del producto.
La solución a algunos de los problemas presentados por las metodologías tradicionales se logra con una gran evolución del modelo espiral. El proceso unificado (RUP) propone la elaboración de varios ciclos de desarrollo, donde cada uno finaliza con la entrega al cliente de un producto terminado. Este se enmarca entre los conocidos modelos iterativo-incremental.
En el caso de las metodologías ágiles se encuentra a Extreme Programming (XP) la cual es una de las metodologías de desarrollo de software más exitosas utilizadas en la actualidad para proyectos de cortos plazo, pequeños equipos y cuyo plazo de entrega era ayer. La metodología consiste en una programación rápida o extrema, cuya particularidad es tener como parte del equipo al usuario final, pues es uno de los requisitos para llegar al éxito del proyecto. (Sáchez, 2004)
El RUP hace un uso intensivo de artefactos de muy diversos tipos, entre ellos, el uso de artefactos de documentación es quizá una de los factores que lo hacen tedioso para algunos. El uso intensivo de documentación es una buena práctica que no debe abandonarse incluso en la XP. Los ciclos de vida de un proyecto en XP y en RUP no son exactamente iguales, aunque sin duda tienen bastantes similitudes, ambas son metodologías iterativas con probado éxito en el desarrollo de software.
1.5.3 Características de RUP y XP
1.5.3.1 El Proceso Unificado de Modelado (RUP) es el producto final de tres décadas de desarrollo y uso práctico, o sea es el conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software. Sin embargo, el proceso unificado es más que un simple proceso; es
22 un marco de trabajo genérico que puede especializarse para una gran variedad de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organización, diferentes niveles de aptitud y diferentes tamaños de proyecto. (Del Soto Montalvo, 2003)
La metodología plantea la realización del proyecto dividiéndolo en cuatro fases de trabajo dentro de cada fase se llevan a cabo varios flujos de trabajo dentro de los cuales se desarrollan actividades específicas y se genera la documentación mínima indispensable y necesaria para el desarrollo del proyecto.
Las cuatro fases el desarrollo del software de RUP son:
Inicio, El Objetivo en esta etapa es determinar la visión del proyecto.
Elaboración, En esta etapa el objetivo es determinar la arquitectura óptima.
Construcción, En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial.
Transmisión, El objetivo es llegar a obtener el release del proyecto.
Principales características:
Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo).
Pretende implementar las mejores prácticas en Ingeniería de Software.
Guiado/Manejado por casos de uso.
Centrado en la arquitectura.
Desarrollo iterativo e incremental.
Administración de requisitos.
Uso de arquitectura basada en componentes
.
Control de cambios.
Modelado visual del software.
Verificación de la calidad del software.
Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones. Los objetivos de una iteración se establecen en función de la evaluación de las iteraciones precedentes. (Sáchez, 2004)
El ciclo de vida que se desarrolla por cada iteración, es llevada bajo dos disciplinas:
Disciplina de Desarrollo:
Ingeniería de Negocios: Entendiendo las necesidades del negocio.
Requerimientos: Trasladando las necesidades del negocio a un sistema automatizado.
23 Análisis y Diseño: Trasladando los requerimientos dentro de la arquitectura de software.
Implementación: Creando software que se ajuste a la arquitectura y que tenga el comportamiento deseado.
Pruebas: Asegurándose que el comportamiento requerido es el correcto y que todo lo solicitado está presente.
Disciplina de Soporte:
Configuración y administración del cambio: Guardando todas las versiones del proyecto.
Administrando el proyecto: Administrando horarios y recursos.
Ambiente: Administrando el ambiente de desarrollo.
Distribución: Hacer todo lo necesario para la salida del proyecto.
Figura 1: Fases e Iteraciones de la Metodología RUP
Los elementos de RUP son:
Actividades: Son los procesos que se llegan a determinar en cada iteración.
Trabajadores: Vienen a ser las personas o entes involucrados en cada proceso.
Artefactos: Un artefacto puede ser un documento, un modelo, o un elemento de modelo.
Una particularidad de esta metodología es que, en cada ciclo de iteración, se hace exigente el uso de artefactos, siendo por este motivo, una de las metodologías más importantes para alcanzar un grado de certificación en el desarrollo del software. (Sáchez, 2004)
24 1.5.3.2 La Programación Extrema (XP) o Extreme Programming es otra de las metodologías de desarrollo de software que existen en la actualidad. Mientras que RUP intenta reducir la complejidad del software por medio de estructura y la preparación de las tareas pendientes en función de los objetivos de la fase y actividad actual, XP, como toda metodología ágil, lo intenta por medio de un trabajo orientado directamente al objetivo, basado en las relaciones interpersonales y la velocidad de reacción. (Molpeceres, 2002)
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. Se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico.
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. De la misma forma el cliente tiene la obligación de manejar el ámbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteración.
El ciclo de vida ideal de XP consiste de seis fases: Exploración, Planificación de la Entrega (Release), Iteraciones, Producción, Mantenimiento y Muerte del Proyecto.
Principales Características:
La metodología se basa en:
Pruebas Unitarias: se basa en las pruebas realizadas a los principales procesos, de tal manera que adelantándose en algo hacia el futuro, se puedan hacer pruebas de las fallas que pudieran ocurrir. Es como si se adelanta en la obtención de los posibles errores.
25 Re fabricación: se basa en la reutilización de código, para lo cual se crean patrones o modelos
estándares, siendo más flexible al cambio.
Programación en pares: una particularidad de esta metodología es que propone la programación en pares, la cual consiste en que dos desarrolladores participen en un proyecto en una misma estación de trabajo. Cada miembro lleva a cabo la acción que el otro no está haciendo en ese momento. Es como el chofer y el copiloto: mientras uno conduce, el otro consulta el mapa. (Sáchez, 2004)
Lo fundamental en este tipo de metodología es:
La comunicación, entre los usuarios y los desarrolladores La simplicidad, al desarrollar y codificar los módulos del sistema
La retroalimentación, concreta y frecuente del equipo de desarrollo, el cliente y los usuarios finales.(Sáchez, 2004)
1.5.4 RUP y XP en el Flujo de Trabajo de Requerimiento
Los esfuerzos de este trabajo están enfocados en la ingeniería de requerimientos por lo que se compara como trabajan estas metodologías en el flujo de trabajo de requerimientos.
Al analizar cómo trabaja RUP y XP principalmente en el flujo de requerimientos. Se puede decir que para suplir la falta de requisitos, casos de uso, y demás herramientas; XP utiliza historias de usuarios, que no son más que las necesidades, escritas por los usuarios, con la ayuda de los diseñadores, que quieren ser satisfechas con el sistema. La gestión de requisitos es extremadamente simple.
Básicamente consiste en trabajar estrechamente con el cliente, haciendo pequeñas iteraciones (mini- entregas), cada dos semanas, donde no existe más documentación que el código en sí; cada versión contiene las modificaciones necesarias según el cliente vaya retroalimentando el sistema (por eso es necesaria la disponibilidad del cliente durante todo el desarrollo).
XP propone fichas en papel para registrar las historias de usuario y tareas asociadas, sin dar mayores guías respecto a la información que debe ser recolectada ni cómo debe gestionarse dicha información.
No existe documentación del proyecto (el talón de Aquiles de este modelo) lo que más se acerca a la documentación son las historias de usuario, pero al concluir el proyecto se descartan. Además la ausencia de documentación hace que el mantenimiento del sistema (realizado por otro equipo de trabajo) sea muy engorroso y difícil.
26 Por otra parte en RUP el esfuerzo del análisis de requerimientos están en enfocado a:
Reconocimiento del problema como lo ve el usuario:
Evaluación del problema y síntesis de la evaluación: Como evaluación se entiende a la definición de los datos observables, la evaluación del flujo y contenido de la información. La definición de las funciones del software, entender el comportamiento del software ante eventos, el establecimiento de las características de la interfaz y el descubrimiento de restricciones adicionales de diseño. Toda esta evaluación se sintetiza en la definición en detalle de los datos, funciones y el comportamiento del sistema.
Modelado: Creación de modelos que ayuden a entender la entidad a construir.
Construcción de un prototipo de alto nivel del sistema.
Revisión por parte del usuario.
Firma del contrato si las partes están de acuerdo.
Los objetivos de RUP en el flujo de trabajo de requerimientos son:
Identificar, enunciar y clasificar los requerimientos.
Obtener las propiedades o cualidades que el producto debe cumplir.
Obtener un listado de las capacidades o funciones que el sistema debe cumplir.
Proveer a los desarrolladores un mejor entendimiento de los requerimientos del sistema.
Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario.
Determinar actores y casos de uso del sistema.
Establecer y mantener un acuerdo entre clientes y otros involucrados sobre lo que el sistema debería hacer.
Para capturar los requisitos es preciso entrevistar a todos los interesados en el proyecto, no sólo a los usuarios finales, y anotar todas sus peticiones. A partir de ellas hay que descubrir lo que necesitan y expresarlo en forma de requisitos. Estos se dividen en dos grandes grupos los requerimientos funcionales y los no funcionales.
Categorías de los Requerimientos no funcionales:
Requerimientos de Software.
Requerimientos de Hardware.
27 Restricciones en el diseño y la implementación.
Requerimientos de apariencia o interfaz externa.
Requerimientos de Seguridad:
• Confidencialidad.
• Integridad.
• Disponibilidad
Requerimientos de Usabilidad.
Requerimientos de Soporte.
En este flujo de trabajo, y como parte de los requisitos de facilidad de uso, se diseña la interfaz gráfica de usuario. Para ello habitualmente se construyen prototipos de la interfaz gráfica de usuario que se contrastan con el usuario final.
Lograr una comunicación efectiva entre los usuarios y el equipo de proyecto con el objetivo de llegar a un entendimiento de lo que hay que hacer, es la clave del éxito en la producción de un software.
Durante muchos años muchas aplicaciones han fallado (no se culminaron o no se usaron) porque existieron incongruencias entre lo que el usuario quería, lo que realmente necesitaba, lo que interpretaba cada miembro del equipo de proyecto y lo que realmente se obtiene. Se puede definir que RUP brinda una mejor posibilidad de realizar una captura de requisitos que concuerde más con las expectativas del cliente y del producto.
1.5.5 Fundamento de la selección de la metodología de desarrollo
El proyecto CICPC es de gran tamaño y complejo, aunque el grupo de desarrollo del Portal Web es pequeño. En el mismo, se realizó un contrato prefijado, de largo plazo y con una fecha límite, donde el cliente se encuentra en otro país, por lo que no puede estar en constante contacto con el equipo de desarrolladores, sino que solo interactúa y sigue el avance del proyecto a través de reuniones que son planificadas, también por ello es necesario una mayor documentación para que exista un control de todo el proceso de avance. Por tanto la metodología más apropiada según las características que han sido descritas y las particularidades del proyecto, es la tradicional. Dentro de la tradicional se centra la atención en una las más importantes metodologías de desarrollo, el Proceso Unificado del Modelado (RUP), ya que cumple con las condiciones planteadas y muestra una correcta guía para la
