PFC Elena Sanchez Pescador

ANLISIS E IMPLANTACIN DE UNA HERRAMIENTA DE GESTIN DE REQUISITOS PARA LA GESTIN DE SERVICIOS BASADO EN LA FILOSOFIA DE ITIL V3, CMMI DE SERVICIOS
Y MOF
UNIVERSIDAD CARLOS III DE MADRID ESCUELA POLITECNICA SUPERIOR Ingeniera Tcnica en Informtica de Gestin
Autor: Elena Snchez Pescador Tutor: Prof. Antonio Folgueras Marcos 2009
Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios
Agradecimientos
A mis padres, a mi hermano, tos, primos y abuelos, obviamente, porque soy consciente de que si estoy aqu y soy tal y como soy, es gracias a todos ellos y a todas las lecciones de vida que me han transmitido. Por su ayuda, su compresin, su confianza y su apoyo. A mis compaeros de carrera, porque sin ellos creo que no hubiera estado donde estoy ahora. Adems, estoy segura que la consecuencia de esta meta hubiera sido muchsimo ms difcil y menos gratificante. Por su amistad y todo ese tiempo compartido juntos. A mis tres piezas de puzzle, Carmen, Rosa y Graci, por ser tal y como son, simplemente. Porque nunca pens que, a pesar de que cada una tiene su forma, todo encaja a la perfeccin. Por la complicidad que se ha ido creando con el paso de los aos, por las largas conversaciones sobre la vida, por los viajes de mundo, por todos esos momentos que hemos pasado y, sobre todo, por lo que nos queda por delante. A Luismi, porque s que parte de este proyecto le corresponde a l. Porque a pesar de todo, me gusta desde donde me mira. Por ser esa clase de personas que todo lo comprende y dan lo mejor de s mismos en cada momento. Y por ltimo, pero no por ello menos importante, quisiera agradecerle desde la primera hasta la ltima pgina de este proyecto a Antonio, mi tutor, por la gran confianza volcada en m y en el trabajo realizado da a da. Me ha concedido su tiempo y sus ganas para crear finalmente este proyecto que culmina con una gran poca y marca el comienzo de grandes retos tanto en lo personal como en lo profesional. Gracias, gracias a todos, es lo nico que me queda aadir. Gracias a las personas que se han alegrado cuando he superado un obstculo y gracias por estar siempre prestndome su apoyo cuando el mismo obstculo me ha hecho tropezar. Gracias por sacarme una sonrisa da a da y por concederme el privilegio de saber que pasito a pasito se crea un sendero. Creo que la vida en si no se construye por s misma, es decir, creo que se va creciendo con el apoyo y el cario de los dems. Todo lo que hacemos pone en movimiento una causa y esta trae consigo un efecto, positivo o negativo. S que, indudablemente, ahora o despus se recibe lo que uno desea de verdad. Yo un da dese llegar a este momento y ahora ya est hecho realidad.
Gracias.
Pgina 2 de 219
Tabla De Contenidos
1. Introduccin... Pg. 7
1.1. Marco general... 1.2. Objetivos del proyecto. 1.3. Estructura de la memoria....... 1.4. Definiciones, acrnimos y abreviaturas.. Pg. 7 Pg. 8 Pg. 9 Pg. 11
2. Gestin de Servicios TI... Pg. 14

2.1 Objetivos de la Gestin de Servicios 2.2 ITIL: Conceptos y procesos fundamentales. 2.3 Ciclo de vida del servicio.. 2.4 CMMI para servicios 2.5 Integracin de CMMI para servicios con ITIL. 2.6 MOF (Microsoft Operations Framework). Pg. 14 Pg. 15 Pg. 18 Pg. 19 Pg. 21 Pg. 21
3. Herramientas de gestin de requisitos Pg. 23

3.1 La Gestin de Requisitos.. 3.2 El cliente frente a los requisitos.. 3.3 Por qu utilizar estas Herramientas?................. 3.4 Caractersticas generales de las Herramientas. 3.5 Anlisis detallado de las Herramientas.. 3.5.1 Doors Telelogic 3.5.2 CaliberRM 6.0.. 3.5.3 Software Planner 3.5.4 REM. 3.5.5 OSRMT..... 3.5.6 Gatherspace.. 3.6 Anlisis comparativo y conclusiones 3.6.1 Requisitos de las herramientas de gestin de requisitos.. 3.6.2 Diagrama Tecnologa-Valor-Riesgo.. Pg. 23 Pg. 24 Pg. 25 Pg. 26 Pg. 28 Pg. 28 Pg. 30 Pg. 32 Pg. 33 Pg. 34 Pg. 36 Pg. 38 Pg. 39 Pg. 45
Pgina 3 de 219
4. Principales caractersticas de la herramienta a disear....... Pg. 49

4.1 Descripcin general. Pg. 49 4.2 Principales caractersticas Pg. 49 4.3 Diseo conceptual de los principales requisitos.. Pg. 51
5. Entorno tcnico de trabajo..... Pg. 55

5.1 Firefox Mozilla. 5.2 Microsoft Office Word 2007.. 5.3 Microsoft Visual Estudio.. 5.4 Visual Basic .Net. 5.5 Microsoft SQL Server 2005. 5.6 ASP.NET Pg. 55 Pg. 55 Pg. 55 Pg. 55 Pg. 56 Pg. 56
6. Anlisis Pg. 58
6.1 Objetivo... 6.2 Definicin de alcance del sistema. 6.3 Identificar usuarios.. 6.4 Especificacin de casos de uso 6.4.1 Usuario registrado y No registrado.. 6.4.2 Administrador.. 6.4.3 Jefe de proyecto. 6.4.4 Usuario.. 6.4.5 Gestin de proyectos.. 6.4.6 Gestin de carpetas. 6.4.7 Gestin de requisitos.. 6.4.8 Gestin de usuarios. 6.4.9 Gestin de roles.. 6.4.10 Gestin de Informes de trazabilidad 6.4.11 Gestin de Informes comparativo. 6.4.12 Glosario de trminos.. 6.4.13 Ayuda. 6.5 Definicin de requisitos del sistema 6.5.1 Acceso a la aplicacin. 6.5.2 Gestin de proyectos.. 6.5.3 Gestin de carpetas. 6.5.4 Gestin de requisitos.. 6.5.5 Gestin de usuarios. 6.5.6 Gestin de roles.. 6.5.7 Obtencin de informes..
Pgina 4 de 219
Pg. 58 Pg. 58 Pg. 59 Pg. 60 Pg. 61 Pg. 62 Pg. 65 Pg. 67 Pg. 69 Pg. 74 Pg. 76 Pg. 79 Pg. 82 Pg. 83 Pg. 84 Pg. 85 Pg. 87 Pg. 88 Pg. 89 Pg. 92 Pg. 94 Pg. 95 Pg. 102 Pg. 103 Pg. 104
6.5.8 Glosario de trminos 6.5.9 Ayuda. 6.5.10 Requisitos de funcionamiento.. 6.5.11 Requisitos de interfaz.
Pg. 105 Pg. 106 Pg. 106 Pg. 107
7. Diseo.... Pg. 109

7.1 Definicin de la arquitectura.... 7.1.1 Definicin de la arquitectura del sistema. 7.1.2 Diagrama de secuencia.. 7.2 Diagramas de actividad. 7.2.1 Iniciar sesin en proyecto... 7.2.2 Aadir proyecto.. 7.2.3 Modificar proyecto 7.2.4 Borrar proyecto.. 7.2.5 Asignar/Borrar usuario en proyecto. 7.2.6 Aadir carpeta. 7.2.7 Modificar carpeta.. 7.2.8 Borrar carpeta.. 7.2.9 Incorporar requisitos a carpeta 7.2.10 Realizar bsqueda de requisitos. 7.2.11 Aadir requisito.. 7.2.12 Modificar requisito 7.2.13 Borrar requisito.. 7.2.14 Aadir/Borrar relacin entre requisitos 7.2.15 Modificar datos personales 7.2.16 Aadir usuario. 7.2.17 Modificar usuario.. 7.2.18 Borrar usuarios 7.2.19 Modificar rol. 7.2.20 Visualizar Informe de trazabilidad. 7.2.21 Visualizar Informe comparativo.. 7.2.22 Aadir un trmino en glosario.. 7.2.23 Modificar un trmino en glosario. 7.2.24 Borrar un trmino en glosario.. 7.2.25 Consultar ayuda.. 7.3 Modelo conceptual.. 7.3.1 Diagrama conceptual 1. 7.3.2 Diagrama conceptual 2. 7.3.3 Diagrama conceptual 3.. 7.4 Diseo de la base de datos. 7.5 Diagrama de estados.. Pg. 109 Pg. 109 Pg. 109 Pg. 111 Pg. 112 Pg. 112 Pg. 113 Pg. 114 Pg. 115 Pg. 116 Pg. 117 Pg. 118 Pg. 119 Pg. 120 Pg. 121 Pg. 122 Pg. 123 Pg. 124 Pg. 125 Pg. 126 Pg. 127 Pg. 128 Pg. 129 Pg. 130 Pg. 131 Pg. 132 Pg. 133 Pg. 134 Pg. 135 Pg. 136 Pg. 137 Pg. 137 Pg. 139 Pg. 141 Pg. 142 Pg. 143
Pgina 5 de 219
8. Anlisis econmico.
8.1 Consideraciones inciales. 8.2 Calculo de puntos de funcin de Albretch 8.2.1 ILF. 8.2.2 EIF. 8.2.3 EI 8.2.4 EO. 8.2.5 EQ. 8.2.6 Resultados finales. 8.3 Estimacin COCOMO II.. 8.4 Planificacin del proyecto.. 8.5 PMBOK .
Pg. 144
Pg. 144 Pg. 144 Pg. 144 Pg. 147 Pg. 148 Pg. 154 Pg. 156 Pg. 160 Pg. 165 Pg. 173 Pg. 177
9. Conclusiones.
9.1 Dificultados encontradas. Pg. 179 9.2 Soluciones propuestas Pg. 179 Pg. 180
10. Referencias.. Pg. 181 11. Anexos

11.1 Requisitos de herramientas ITSMF 11.1.1 Requisitos tcnicos..... 11.1.2 Integracin herramientas. 11.1.3 Service Desk.. 11.1.4 Release Management. 11.1.5 Incidentes 11.1.6 Problemas 11.1.7 Niveles de servicio. 11.1.8 Configuracin 11.1.9 Monitorizacin. 11.2 ndice de figuras..
Pg. 185
Pg. 185 Pg. 185 Pg. 188 Pg. 189 Pg. 195 Pg. 200 Pg. 204 Pg. 206 Pg. 212 Pg. 215 Pg. 218
Pgina 6 de 219
1. Introduccin
1.1. Marco general.
Actualmente las Tecnologas de la Informacin (TI) estn afectando prcticamente a todos los sectores de nuestra sociedad. Han producido un cambio fundamental, saltando de una sociedad de tipo industrial hacia una sociedad de la informacin. Se hace imprescindible cubrir tanto las necesidades de los usuarios como de la propia organizacin y para ello las TI soportan y mejoran en lo posible los procesos de la entidad. Se considera que las inversiones en TI son fundamentales para asegurar la competitividad de las organizaciones y mejorar su posicin en el mercado. Se busca conseguir infraestructuras informticas fuertes, que cubran el mayor rango de objetivos de negocio de la organizacin. Adems, se tiene como finalidad la bsqueda de la calidad, innovacin y valor de TI, es decir, se ofrece lo que el cliente necesita tal y como se especifica en los requisitos expuestos. Como se muestra en la siguiente figura, la inversin en las tecnologas de la informacin no representa en s misma una fuente de ventajas competitivas, sino que se requieren ms elementos que permitan que dicha inversin maximicen la eficiencia y productividad de los procesos de negocio.
Figura 1. Elementos clave en la inversin de TI

Pgina 7 de 219
La inversin en las tecnologas de la informacin no son un gasto en s, sino que a medio o largo plazo conllevan a una mejorar en la empresa. Invertir en TI es sinnimo de conseguir beneficios que impactan directamente en el negocio. Una inversin significativa en tecnologa puede evitar incurrir en desventajas. Pero en ocasiones, las inversiones en TI no se ejecutan para ganar ms, sino para evitar prdidas de competitividad con el resto del sector. Esto significa que la rentabilidad de la inversin no se debe contemplar en trminos de una mayor generacin de beneficios, sino a partir de la valoracin de las prdidas observar el nivel de progreso de la tecnologa. Si hablamos de ITIL (IT Infrastructure Library) como base fundamental de este proyecto, diremos que estamos ante una gua para realizar buenas prcticas en la Gestin de Servicios TI. Supone una prestacin y mejora de los servicios de TI en la comunicacin de usuarios. ITIL se intenta adaptar a cualquier tipo de empresa, amoldndose al contexto actual. Esta gua proporciona una serie de procesos para llevar a cabo la infraestructura, el desarrollo y las operaciones de TI y expresa la forma de implementar estos procesos de una forma adecuada. Por tanto, con ITIL se consigue una reduccin en el tiempo y costes, una clara relacin con el cliente, lo que lleva a mantener o enriquecer la satisfaccin del mismo, y una mejora en la produccin y satisfaccin del trabajo. Estas metas se consiguen mediante un enfoque sistemtico del servicio TI centrado en los procesos y procedimientos y estableciendo estrategias para la gestin de la infraestructura TI. Para finalizar esta pequea introduccin, no debemos olvidar hablar de ITSMF (Information Technology Service Management Forum). Es una red mundial para usuarios de las TI que ofrece mejores prcticas y estndares para mejorar la Gestin de Servicios TI. Su objetivo es organizar una red de expertos en Gestin de Servicios Informticos, proporcionar informacin completa y organizar seminarios y conferencias para ayudar a las empresas a resolver los problemas que puedan encontrar. En la actualidad, las empresas dependen cada vez ms en las TI para la promocin y distribucin de sus productos en el mercado, por lo que resulta imprescindible seguir la filosofa de guas y estndares.
1.2. Objetivos del proyecto

El objetivo fundamental del proyecto es el desarrollo de un aplicativo capaz de dar solucin al anlisis de requisitos de una empresa, en principio, de cualquier sector empresarial.
Pgina 8 de 219
Se busca comprobar si efectivamente una empresa funciona a la perfeccin, obteniendo calidad de los servicios, mejor eficacia, reduccin de riesgos asociado a los servicios TI y mejor relacin con los clientes. Todo esto conllevar a una ventaja competitiva importante, ya que se conoce con exactitud las partes del negocio que dan valor a la empresa. Y por tanto, en el caso de que una parte no funcione adecuadamente, habr que plantearse su modificacin o eliminacin. Las Tecnologas de la Informacin cubren un rea bastante grande y su complejidad requiere una filosofa que considere cada punto y asegure su funcionamiento y calidad para todos los usuarios que puedan requerir de los servicios proporcionados por TI. ITIL, como gua integral y de dominio pblico sobre previsin de servicios TI, ayudar a desarrollar un sistema robusto para satisfacer las expectativas del usuario. Se analizar, disear e implementar una herramienta til para la gestin de requisitos, llegando a facilitar una tarea fundamental en cualquier proyecto de software. La utilizacin de herramientas de gestin de requisitos reforzar la planificacin estratgica de la entidad y aportar muchos beneficios en todos los sentidos, ahorrando tiempo, capital y personal. El anlisis de los requisitos es uno de los puntos ms crticos en el desarrollo de un proyecto, por ello es importante realizar una base corpulenta. Se buscar, por tanto, facilitar el trabajo a los usuarios de la aplicacin, los cuales disfrutaran de unos servicios ms eficaces y de mejor calidad.
1.3 Estructura de la memoria.

A continuacin se muestran los diferentes captulos que forman este documento, explicando brevemente cada uno de ellos: En el Apartado 1, Introduccin, tiene lugar la situacin del proyecto. Se define una pequea introduccin con los conceptos fundamentales, especificando el marco bajo el cual se desarrollar el proyecto. A continuacin, se describe el problema a resolver y los objetivos principales a cumplir al finalizar dicho proyecto. Por ltimo, se incorporar la lista de definiciones, acrnimos y abreviaturas que ayudan a entender mejor todos los conceptos que incorpora el documento. En el Apartado 2, Gestin de Servicios TI, se hace un estudio sobre la Gestin de Servicios de las TI, introduciendo, por tanto, conceptos bsicos de ITIL v3 y CMMI. Se vern los procesos fundamentales de ITIL v3, los cambios respecto a la versin anterior de ITIL y el ciclo de vida del servicio, como base fundamental de nuestro
Pgina 9 de 219
proyecto. Adems se expondr brevemente en qu consiste el Modelo de Madurez de la Capacidad Integrado, as como su integracin con ITIL. En el Apartado 3, Herramientas de gestin de requisitos, se incluir un estudio sobre las herramientas ms importantes en el mercado, valorando sus caractersticas principales, as como las ventajas y desventajas ms destacables de cada una de ellas. En el ltimo punto del apartado, a modo de conclusin y con el fin de encontrar una herramienta completa y as empezar a construir nuestra propia herramienta, se realizar un anlisis comparativo de las cinco herramientas elegidas. Se mostrar la situacin de cada herramienta en una grafica ValorTecnologa-Riesgo. En el Apartado 4, Principales caractersticas de la herramienta a disear, se expondrn las funcionalidades ms destacables de nuestra herramienta. Se obtendrn del estudio realizado en el apartado anterior, donde se valoraban todas las funcionalidades de las herramientas de gestin de requisitos elegidas. A modo de introduccin al anlisis se representar un modelo conceptual sencillo de los principales requisitos obtenidos. En el Apartado 5, Entorno tcnico de trabajo, se representar un breve resumen de la tecnologa utilizada para la realizacin del proyecto. En el Apartado 6, Anlisis, se explicarn los conceptos ms importantes sobre los que va a girar el proyecto. El objetivo de este apartado es poder hacerse una idea aproximada de qu es lo que se trata de llevar a cabo con la herramienta. Estar compuesto por diagramas de casos de uso y una especificacin de requisitos completa para comprender perfectamente todos los procesos de desarrollo. En el Apartado 7, Diseo, se entrar ms en detalle y se describir ms en profundidad que modelo es el elegido, la arquitectura utilizada y como se van a manejar los flujos de los procesos. En este apartado se encontraran los diagramas necesarios para la comprensin de todos los procesos del desarrollo, y con ello posteriormente poder desarrollar la aplicacin adecuadamente. En el Apartado 8, Anlisis econmico, se realizar una estimacin de los recursos que se van a necesitar y con ello se har una planificacin detallada de todas las tareas necesarias. En el Apartado 9, Conclusiones, se realizar una pequea valoracin del proyecto final, incluyendo las dificultades y las soluciones propuestas.
Pgina 10 de 219
En el Apartado 10, Referencias, contendr la bibliografa utilizada. En el Apartado 11, Anexos, se incorporar las tablas sobre los requisitos de las herramientas, proporcionado por ITSMF, juntos con otra informacin necesaria para una mejor gestin del proyecto. Este documento se ha desarrollado utilizando Microsoft Office Word. El formato del documento empleado ha sido: Tipo de letra: Calibri. Tamao de letra: 12. Idioma: Espaol. El interlineado es de 1,0. Los mrgenes de los lados son de 2 cm y los superiores e inferiores constan de 2,5 cm. Los dibujos, diagramas y esquemas se han realizado con Microsoft PowerPoint. Para los ttulos de los captulos se utiliza el tipo de letra Calibri tamao 25. Para los ttulos de los sub-captulos se utiliza el tipo de letra Calibri tamao 14. Tamao del documento: DIN-A4.
1.4 Definiciones, acrnimos y abreviaturas.

ASCII (American Standard Code for Information Interchange): es un cdigo de caracteres basado en el alfabeto latino tal como se usa en ingls moderno y en otras lenguas occidentales. CMMI (Capability Maturity Model Integration): El modelo de integracin de madurez de la capacidad es una aproximacin a la mejora de procesos desarrollada por el Software Engineering Institute (SEI) de la Carnegie Melon University. CMMI provee a las organizaciones de los elementos esenciales para la efectividad de los procesos. El modelo puede ser usado para habilitar la mejora de procesos a lo largo de un proyecto, una divisin, o una organizacin completa. CMMI ayuda a integrar funciones de la organizacin tradicionalmente separadas, fijar prioridades y objetivos en la mejora de procesos, guas para la calidad de los procesos, y proporcionar un punto de referencia para la evaluacin de los procesos en curso.
Pgina 11 de 219
CRM (Customer Relationship Management): es parte de una estrategia de negocio centrada en el cliente. Ayuda a recopilar la mayor cantidad de informacin posible sobre los clientes, para poder dar valor a la oferta. La empresa debe trabajar para conocer las necesidades de los mismos y as poder adelantar una oferta y mejorar la calidad en la atencin. HTML (HyperText Markup Language): Lenguaje predominante para la construccin de pginas Web. IIS (Internet Information Server): Servicio para los ordenadores que se encargar de convertir al propio ordenador en un servidor de internet. INCOSE (International Council on Systems Engineering): Organizacin que tiene el objetivo de promover el estado de la tcnica y la prctica de la ingeniera. Busca producir soluciones tecnolgicas adecuadas que satisfagan las necesidades de la sociedad. ITIL (IT Infrastructure Libray): Conjunto de mejores prcticas para la Gestin de Servicios de TI. ITIL es propiedad de la OGC y consiste en una serie de publicaciones que aconsejan sobre la provisin de servicios de TI de calidad, y sobre los procesos y las instalaciones necesarias para soportarlos ITSM (IT Service Management): Implantacin y gestin de servicios de TI de calidad que cumplen con las necesidades del negocio. La Gestin de los Servicios de TI es llevada a cabo por los proveedores de servicios TI a travs de la combinacin apropiada de personas, procesos y tecnologas de la informacin. ITSMF: Es una organizacin independiente dedicada a promover una aproximacin profesional a la Gestin de los Servicios de TI. ITSMF es una organizacin, sin nimo de lucro, con representacin en gran nmero de pases por todo el mundo. ITSMF y sus miembros contribuyen al desarrollo de ITIL y de los estndares de gestin de servicio asociados. .NET frameword: Componente software de Microsoft que provee un extenso conjunto de soluciones predefinidas para necesidades generales de programacin de aplicaciones, y administra la ejecucin de los programas escritos especficamente con la plataforma. PDF (Portable Document documentos. Format): Formato de almacenamiento de
Pgina 12 de 219
PMBOK: Estndar de gestin de proyectos mantenido y publicado por el Project Management Institute. PMBOK son las siglas de Project Management Body of Knowledge (Cuerpo de Conocimiento de Gestin de Proyectos). RTF (Rich Text Format): Lenguaje de descripcin formado por Microsoft para intercambiar informacin entre programas de edicin de texto. T-SQL (Transact-SQL): Es el lenguaje de programacin de SQL-Server. A travs de t-sql se pueden realizar operacin de insercin, modificacin, borrado y consulta, sin tener que volver a pasar por cdigo ASP o VB. TI (Information Technology): Uso de la tecnologa para el almacenamiento, comunicacin o procesado de informacin. La tecnologa incluye tpicamente ordenadores, telecomunicaciones, aplicaciones y otros software. La informacin puede incluir datos de negocio, voz, imgenes, video, etc. UML (Unified Language Model): Lenguaje Unificado de Modelado, lenguaje de sistemas software ms conocido y utilizado en la actualidad. URL (Uniform Resource Locator): Es una secuencia de caracteres, de acuerdo a un formato estndar, que se usa para nombrar recursos, como documentos e imgenes en Internet, por su localizacin.
Pgina 13 de 219
2. Gestin de Servicios TI
2.1 Objetivos de la Gestin de Servicios.
El objetivo fundamental es asegurar que los servicios TI cubran las necesidades del negocio. Es importante aferrar la disponibilidad de los activos de una empresa, as como mantener una adecuada calidad de servicio. Esta gestin ayuda a potenciar el valor de los procesos TI ms importantes, generar negocio e identificar los impactos que un cambio produce, reduciendo los posibles riesgos. La Gestin de Servicios puede convertirse en el punto ms beneficiario en un proceso TI. El entorno operativo ideal supone disponer de unos servicios fiables y adecuados, reducir los costes de la prestacin de los servicios, utilizar los activos, la experiencia y el conocimiento TI, adems de mejorar la calidad y velocidad de cambio y configuracin. ITSM (IT Service Management) surge como solucin y consiste principalmente en un conjunto de habilidades especializadas que fundamentalmente forman tres pilares, los cuales cooperan para asegurar la calidad de los servicios TI:
Personas
Tecnologa
Procesos
Visin
Figura 2. Puntos clave en los servicios TI
Personas. Habilidad de ejecutar la operacin, el soporte y el desarrollo. Es importante asignar tareas, roles y responsabilidades con el fin de conseguir los objetivos de TI propuestos. La comunicacin entre los miembros del equipo, tanto jerrquica como entre diferentes reas del departamento TI tambin es un punto crtico que ofrece una mayor sintona a la gestin del servicio TI.
Pgina 14 de 219
Tecnologa. Productos potentes como servidores, redes, bases de datos y aplicaciones. Es necesario adquirir y mantener la tecnologa adecuada para la prestacin servicios, as como asegurar y aprovechar la capacidad de la misma. Procesos. Progreso, coordinacin y disciplina. Se define la estrategia de soporte y provisin de los servicios TI, segn ITIL, as como la gestin de la configuracin, la gestin de incidencias, la gestin de problemas, la gestin de cambio, la gestin de la disponibilidad, de la capacidad, de la continuidad y de la seguridad, entre otros.
ITSM se encargar de mejorar la calidad de los servicios y adquirir las necesidades que tiene el cliente. Adems define una estrategia defensiva, regula los recursos, hace marketing interno de los servicios TI y controla los costes de operaciones TI.
2.2 ITIL: Conceptos y procesos fundamentales.

ITIL es un marco de referencia para la Gestin de los Servicios TI. Consiste en una filosofa de mejora continua orientada a enriquecer la calidad del servicio. Surgi durante los aos 80 en el Reino Unido, ante la necesidad de gestionar de manera eficaz y eficiente los recursos de las Tecnologas de la Informacin. ITIL expresa la forma de implementar los procesos correctamente con un coste justificado, adems proporciona una visin de cmo se interrelacionan entre ellos, es decir, para que los servicios TI funcionen adecuadamente sus procesos deben hablar con el fin de que exista un flujo de informacin continua. Puesto que es posible que un fallo producido en un determinado proceso se propague a los dems procesos, lo que conllevara a tener una informacin corrupta, es adecuado que exista esta comunicacin entre los diferentes procesos Cuando hablamos de ITIL no hay que confundirlo con una metodologa para implantar los procesos de Gestin de Servicios de TI. ITIL no proporciona instrucciones de trabajo, no asigna tareas a personas ni propone mapas de proceso. Hay que tener en cuenta que ITIL es una gua, y por ello no asegura siempre un mejor sistema informtico o se va a proporcionar mejor servicio, sino que los resultados finales dependern tambin de factores externos como la naturaleza de la empresa, la magnitud, los medios o la posicin en el mercado entre otros. En primer lugar se deber analizar que partes de ITIL convienen a la entidad y luego hay que adaptarlas a las infraestructuras de TI. En definitiva, con ITIL se consigue dar un mejor servicio, una adecuada comunicacin entre entidad y cliente y adems se consiguen unas infraestructuras TI organizadas y controladas, adquiriendo eficacia y eficiencia.
Pgina 15 de 219
La ltima versin, ITIL v3, propone una visin ms estratgica. Introduce un ciclo de vida de servicio de TI compuesto por estrategia de servicio, diseo, transicin y operacin. Los procesos y los servicios son constantemente monitorizados, analizados y mejorados, lo que conlleva a evolucionar lenta pero adecuadamente. De forma general, en relacin con la versin 2 de ITIL, el contenido es mucho ms amplio y complejo. Supone una fiabilidad y disponibilidad de los servicios, una mejor relacin con los usuarios y permite que los cambios sean giles debido a que todo planteamiento es consistente y est normalizado. Los procesos de ITIL proporcionan una gua para la gestin estratgica, tctica y operacional de las infraestructuras de TI. Los procesos ms importantes se detallan a continuacin: Gestin Financiera de Servicios TI: Se encarga de que la provisin de servicios TI sea prudente y rentable. Permite realizar presupuestos, justificar todos los gastos y asignarlos directamente a los servicios. Gestin de la Cartera de Servicios: Tiene como objetivo fundamental maximiza el valor, gestionando riesgos y costes. Trabaja con las necesidades del negocio buscando las mejoras propuestas para satisfacer a los proveedores de servicios. Gestin de la Demanda de Servicios: Tiene como fin predecir y regular la demanda de manera que se encuentre una compatibilidad entre el suministro y la propia demanda existente. Gestin del Catlogo de Servicios: Incorpora informacin de los servicios TI, garantizando al cliente su disponibilidad total. El catlogo de servicios contiene detalles como el estado, interacciones posibles y dependencias. Gestin de Nivel del Servicio: Su objetivo es establecer acuerdos claros con el cliente sobre el tipo y la calidad de los servicios TI prestados. Adems, garantiza que los prximos servicios se ejecutan de acuerdo a los objetivos fijados. Gestin de la Capacidad. Es el proceso encargado de optimizar costes y mejorar el desarrollo de recursos TI para soportar los acuerdos actuales y futuros con los clientes. Gestin de la Disponibilidad. Proporciona un despliegue de recursos para soportar la disponibilidad acordada con el cliente. Gestin de la Continuidad del Servicio TI. La finalidad de este proceso es preparar y planificar las instalaciones tcnicas, de servicios TI, sistemas informticos, redes, aplicaciones, etc., para que, en caso de interrupcin
Pgina 16 de 219
del negocio, los servicios TI se recuperen en un tiempo acordado previamente. Gestin de la Seguridad. Este proceso se asegura de proteger la informacin en todos los servicios y actividades de la Gestin de Servicios, en cuanto a confidencialidad, integridad y disponibilidad. Gestin de Proveedores: Se encarga de gestionar a los proveedores y los servicios que estos proporcionan, con el objetivo de conseguir una calidad excepcional y consistente de los servicios TI. Gestin del Cambio. Se encarga de la aprobacin e implementacin de los cambios de la infraestructura TI. Se ha de garantizar que los cambios son registrados, evaluados, autorizados, priorizados, planificados, probados, implementados, documentados y revisados. Gestin de la Configuracin. Su principal objetivo es proporcionar informacin detallada sobre el entorno de produccin de TI y representa uno de los elementos centrales en las operaciones desempeadas por el departamento. Adems, cubre la identificacin, control, mantenimiento y verificacin de los elemento de configuracin (CIs) Gestin de Incidentes. Su finalidad es la de resolver los incidentes surgidos y restaurar la provisin del servicio lo antes posible, minimizando el impacto sobre los procesos de negocio. Los incidentes pueden ser fallos, preguntas, consultas planteadas por el usuario o fallos en las herramientas de monitorizacin de eventos. Gestin de Problemas. Su principal utilidad es ser proactivo e intentar localizar problemas antes de que ocurran. Se busca prevenir problemas e incidentes y, en caso de que surjan, buscar su causa subyacente para evitarlos y prevenirlos para el futuro.
Existen varios procesos mas como Validacin y Pruebas de Servicio, Gestin de Entregas y Despliegues, Gestin del Conocimiento, Gestin de Eventos, Gestin de Accesos y Centro de Servicios al Usuario que completan el ciclo de vida de ITIL v3, asegurando una gestin adecuada de las infraestructuras de TI ITIL puede y debe aplicarse tanto a pequeas como medianas o grandes empresas. Implantar sus procesos es beneficioso para cualquier organizacin siempre que sea de forma ordenada, progresiva y con un estudio previo. La diferencia est en las partes de ITIL que se adopten y el grado de complejidad de los procesos.
Pgina 17 de 219
En definitiva, la fortaleza de ITIL radica en que se trata simplemente de una gua, un marco de referencia, que solo marca el camino a seguir, pero luego la decisin de cada organizacin, en funcin de sus condiciones y necesidades, es crucial para alcanzar con xito los objetivos buscados. A pesar de todo, hay que tener en cuenta que la implementacin de ITIL en una organizacin puede derivar una serie de problemas: La introduccin puede llevar tiempo y requiere un esfuerzo significativo, lo que implica un cambio de cultura organizacional. Puede no haber mejora si no se comprenden adecuadamente los procesos ms relevantes. Si no se implican todas las personas y departamentos por igual no se puede conseguir una implantacin exitosa, ya que la comunicacin entre todas las partes es fundamental. El servicio no mejorar si no se realiza una importante inversin tanto en formacin como en herramientas de soporte.
2.3 Ciclo de vida del servicio.

La metodologa de ITIL es una de las ms aceptadas mundialmente sobre la Gestin de Servicios TI. Esta gua es desarrollada para reducir costes de previsin y soporte en los servicios TI. Adems garantiza seguridad y aumenta el nivel de fiabilidad y calidad. La versin 3 de ITIL se estructura teniendo como eje central el ciclo de vida del servicio. Este ciclo de vida es un modelo de organizacin y ofrece informacin sobre la estructura de gestin de servicio y los diferentes componentes. Adems describe las relaciones y cambios que se producen entre estos componentes. Se compone de cinco volmenes que buscan facilitar su aplicacin: Estrategia de Servicio Se busca el alineamiento entre el negocio y TI, es decir, la construccin de las fases de diseo, desarrollo e implementacin de la Gestin del Servicio como un activo estratgico. Diseo del Servicio Una vez diseada la estrategia, este volumen suministra una gua para la produccin e implementacin del diseo de arquitecturas, procesos TI innovadores, documentos para el diseo del servicio y polticas de TI.
Pgina 18 de 219
Transicin del Servicio Es el paso a la produccin de servicios. Se centra en la gestin de cambios y en las prcticas de lanzamiento, considerando los riesgos y mecanismos de entrega. Operaciones del Servicio Suministra una gua sobre cmo alcanzar la efectividad y eficiencia en la entrega. Se hace necesario asegurar el valor para el cliente y para el proveedor de servicios. Mejora Continua del Servicio Se enfoca en el mantenimiento de los servicios existentes.
Figura 3. Ciclo de vida ITIL v3
El desarrollo de unos procesos en torno al ciclo de vida de servicio es una idea adecuada que da coherencia en todos los procesos.
2.4 CMMI para servicios:

El Modelo Integrado de Madurez y Capacidad es un modelo de referencia de prcticas maduras usadas para evaluar y mejorar la capacidad de los procesos en el sector TI, y as disear procesos efectivos en productividad, rendimiento, coste y tiempos de respuesta. Es un camino evolutivo, continuo a la vez que por etapas, de implementacin de las mejores prcticas. En la representacin continua, la mejora se mide utilizando niveles de capacidad, mientras que la madurez se mide para un proceso concreto de la organizacin. En la representacin por etapas, la mejora se mide utilizando niveles de madurez para un conjunto de procesos en
Pgina 19 de 219
una organizacin. CMMI se centra en 4 dominios: Ingeniera de Software, Ingeniera de Sistemas, Desarrollo integrado de productos y procesos y Gestin de Proveedores para Proyectos.
CMMI establece seis niveles de madurez, en la representacin continua: Nivel 0 (Incompleto): Representa procesos que no consiguen obtener los objetivos propuestos Nivel 1 (Inicial o ejecutado): El proceso se ejecuta y se logran sus objetivos, aunque sea fuera de presupuesto y de tiempo. En este nivel, el desarrollo del proyecto es turbio, no se sabe lo que pasa en l. Nivel 2 (Gestionado): Se da cuando el xito de los resultados obtenidos se pueden repetir. La principal diferencia entre este nivel y el anterior es que el proyecto es ejecutado, planificado, controlado y evaluado durante su desarrollo, de manera que se comprueba que los requisitos se cumplen. El desarrollo no es opaco y se puede saber el estado del proyecto en todo momento. Nivel 3 (Definido): La forma de desarrollar proyectos est definida, establecida, documentada y existen mtricas para la consecucin de objetivos concretos. Nivel 4 (Cuantitativamente gestionado): Los proyectos usan objetivos cuantificables para alcanzar las necesidades de los clientes y de la organizacin. Se usan estadsticas, mtricas y otras tcnicas cuantitativas para gestionar la organizacin. Nivel 5 (Optimizado): Los procesos de los proyectos y de la organizacin estn orientados a la mejora de las actividades, que mediante mtricas son identificadas, evaluadas y puestas en prctica.
El propsito del modelo CMMI para servicios (CMMI-SVC) es conseguir que los usuarios de CMMI tengan los resultados y beneficios deseados, busca mejorar de manera excepcional los procesos mediante los cuales las organizaciones ofrecen sus servicios, optimizando desde el inicio hasta la entrega al cliente. Es una gua para ayudar a las organizaciones a decidir qu servicios prestar, adems aporta el conocimiento adecuado para asegurar que se tiene todo lo necesario para prestar el servicio, incluyendo personas, procesos y productos. Concede una reduccin de
Pgina 20 de 219
costes, una mejora en la previsibilidad de horarios y en la calidad, retirando cualquier sistema obsoleto o mejorndolo en lo posible, y asegura recuperarse de desastres potenciales volviendo al estado inicial.
2.5 Integracin CMMI para servicios con ITIL:

CMMI e ITIL son dos proyectos claramente diferenciados pero no por ellos excluyentes. La gran diferencia entre ellos dos es que CMMI establece las metas, pero es ITIL quien dice como alcanzarlas. Como ya hemos comentado anteriormente CMMI-SVC busca mejorar los procesos de servicios, encontrar resultados adecuados y beneficiosos para la organizacin, mientras que ITIL se ocupa de las operaciones TI, tales como seguridad, cambio y gestin de la configuracin, entre otras. CMMI-SVC resume las mejores prcticas de ITIL dentro de un pequeo conjunto de prcticas especficas, por tanto no hay ningn inconveniente si se quiere combinar ITIL con CMMI para cubrir todas las reas de TI. Se asocian las mejores prcticas de ITIL a componentes CMMI, de forma que los usuarios pueden consultar ITIL como informacin adicional para su implementacin.
2.6 MOF (Microsoft Operations Framework):

MOF proporciona una gua tcnica completa, estructurada y flexible, sobre las actividades TI, ayudando a los usuarios a establecer y aplicar sistemas fiables y rentables en servicios TI. Busca la disponibilidad y confiabilidad del soporte tcnico y de la administracin del sistema de produccin crtica. Ofrece informacin sobre el modo de plantear, implementar y mantener procesos operativos de TI. En relacin con ITIL, MOF est basado en esta biblioteca de infraestructuras de TI. ITIL va a explicar cmo debera ser la Gestin de Servicios TI, es decir, se va a encargar de describir los procesos necesarios para el obtener soluciones de servicios crticas, mientras que MOF consiste en una serie de adaptaciones de ITIL consideradas mejores prcticas en operaciones TI. A parte de en ITIL, MOF tambin se basa en equipos de consultara y soporte tcnico de Microsoft, en el estndar ISO /IEC 15504, que proporciona una vista normalizada para evaluar la madurez del proceso de software y se integra con Microsoft Solutions Framework (MSF) para completar el ciclo de vida TI. El modelo de proceso de MOF dispone de tres disciplinas: Procesos de operacin: Permite definir estructuras para administras mejor los sistemas de TI. Este mtodo se centra en cuatro pilares fundamentales, que se integran entre s para formar el ciclo de vida TI completo:
Pgina 21 de 219
Cambios: Incorpora nuevas soluciones, tecnologas, sistemas, aplicaciones, hardware y procesos para responder con eficacia a las necesidades y demandas del negocio. Durante esta fase, los cambios se van a presentar y a probar. Operaciones: Facilita los procesos, los procedimientos y las herramientas. Son actividades que se realizan diariamente para mantener un sistema de funcionamiento adecuado y actualizado en todo momento. Soporte tcnico: Es el proceso de mantenimiento del sistema. Con herramientas y procedimientos adecuados, se busca la resolucin de incidentes y problemas. Optimizacin: Se reducirn costes mientras se mantienen o mejoran los niveles de servicio. Es posible que la mejora del sistema requiera un cambio del hardware, el software o los procedimientos.
Despus de cada fase se realiza una revisin de manera que no se arrastren errores innecesarios y se tenga un control adecuado de la administracin, operaciones y seguridad. Equipo de trabajo: Se busca la realizacin de actividades hacia una meta comn de servicios, para ello se debe determinar la organizacin de equipo de trabajo, los roles y los permisos. Gestin de riesgos: Es fundamental para comprender cuales son las riesgos a los que se expone el negocio. Es importante identificarlos, analizarlos, planearlos, rastrearlos y controlarlos para mantener un sistema libre de riesgos. El resultado continuo y consciente de este proceso genera un documento de anlisis de riesgos y planes de mitigacin y contingencia.
Pgina 22 de 219
3.
Herramientas de gestin de requisitos
3.1. La Gestin de Requisitos

La gestin de requisitos es una parte vital en el desarrollo de proyectos software puesto que define el propsito, la direccin y el tamao del proyecto y por tanto, en mayor o menor medida, condicionar el xito global del mismo. Es importante la comunicacin iterativa con el cliente, con el fin de definir y registrar adecuadamente que se espera del proyecto. Se fomenta la calidad a travs de la trazabilidad, es decir, el proyecto finalizar correctamente si trabajamos con el menor nmero de cambios o errores en los objetivo. Con los requisitos almacenados debemos analizarlos y verificarlos de manera que se asegura la satisfaccin del cliente, representando las necesidades fieles del mismo. Pero hay que tener en cuenta que los requisitos son inestables puesto que cambian a lo largo de la vida del proyecto. Cambios de tipo tecnolgico, estratgico o en las leyes, son algunos de los ejemplos ms comunes. En todo momento hay que tratar y controlar las actualizaciones y cambios en los requisitos y actuar en consecuencia para poder seguir teniendo como objetivo principal la satisfaccin del cliente.
Figura 4. Creacin del producto
Pgina 23 de 219
Las principales actividades de la gestin de requisitos son: Recoleccin: Consiste en una comunicacin iterativa entre cliente y participantes para descubrir, definir, refinar y registrar requisitos del producto. Documentacin: Una vez recolectados, los requisitos han de ser analizados al detalle con el fin de tener un convenio con el cliente. Verificacin: Se ha de verificar con el cliente que efectivamente los requisitos expuestos cubren todas sus necesidades. Gestin de cambios: Se encargar de identificar, evaluar y trazar cambios. Un proyecto evoluciona, por tanto, cabe la posibilidad de que los requerimientos vayan modificndose. Se necesita un rastreo completo y preciso de todos estos cambios.
Por ltimo comentar que la gestin de requisitos requiere una fuerte inversin de dinero al principio del proyecto y necesita una constante financiacin a los largo del ciclo de vida del mismo. Puesto que la financiacin del proyecto es limitada al principio del mismo, a menudo se realizan atajos en la gestin de los requisitos. Por tanto, muchos proyectos realizan la gestin de requisitos cuando se presenta el problema derivados inevitablemente de la falta de la misma, momento en el cual suele ser demasiado tarde. A consecuencia de ello, podemos concluir que la gestin de requisitos es una actividad crtica para el desarrollo del sistema, ya que asegura que las necesidades del cliente son tenidas en cuenta.
3.2 El cliente frente a los requisitos.

El cliente necesita cambios en su proyecto y el gestor de proyectos debe responder a estos cambios. A medida que un proyecto software va desarrollndose, el cliente comienza a adquirir mayor conocimiento y experiencia sobre el mismo. El cliente tendr, en cualquier momento del ciclo de vida del proyecto, la necesidad de modificar algunos de los requisitos inciales. Los clientes no involucrados adecuadamente en el proyecto provocarn un riesgo de construir un producto equivocado. El xito de participacin del cliente puede provocar una mejor implementacin y aceptacin del aplicativo final.
Pgina 24 de 219
Se debe buscar que la participacin del cliente apunte a contribuciones que hubiesen sido errneas sino participaba. Un proyecto experimenta alrededor del 25% de cambios en los requisitos a lo largo del desarrollo. El cliente, por tanto, es un factor crtico en la entrega excelente del producto. Se han de realizar reuniones con el cliente, con el fin de valorar si el sistema solicitado rene o no las necesidades, y si no es as tomar las medidas oportunas.
3.3 Por qu utilizar estas herramientas?

El uso de las herramientas de gestin de requisitos mejora la productividad y la calidad en el desarrollo de un proyecto software. La mayora de los proyectos TI fallan por el inadecuado entendimiento de las necesidades de los usuarios. Pero adems, se hace necesario crear un hilo continuo entre requisitos, diseo y programacin, lejos de la inconsistencia. Actividades como la especificacin de requisitos y la gestin de requisitos de usuario son algunos de los puntos ms crticos en el desarrollo y produccin del proyecto. Si un proyecto software terminado cumple sus objetivos propuestos se ahorrar indudablemente en tiempo y recursos y existir una facilidad de reutilizacin.
Figura 5. Grafico sobre el estado de proyectos finales
Pgina 25 de 219
Segn el grafico, perteneciente a un estudio, ms del 50% de los proyectos son terminados pero sin satisfacer al cliente. Los motivos por los que falla un proyecto derivan de requisitos incompletos, cambios en los mismos, falta de recursos, expectativas no realistas o productos finales no necesarios. Hay que tener en cuenta que el coste de correccin de defectos de requisitos es del orden de 100 a 200 veces inferior en las etapas inciales, es decir, un fallo en los requisitos se ha de solucionar lo antes posible. Se debe identificar claramente el problema. El usuario ha de aportar toda la informacin necesaria para que el proyecto sea completo y cubra todas las necesidades. Hay que tener en cuenta que el entorno tiene tendencia a cambiar, por tanto, en tal situacin se debe actuar en consecuencia, sin desviarse del camino para conseguir los objetivos. A pesar de que las herramientas de gestin de requisitos avancen y evolucionen a gran velocidad, hay que tener muy presente que esto es indiferente si se produce software inadecuado. Se debe poner un gran empeo en las primeras fases de desarrollo si se quiere alcanzar grandes resultados y sacar el mximo partido a las herramientas.
3.4 Caractersticas generales de las Herramientas.

La mayora de las herramientas de gestin de requisitos existentes en el mercado, realizan prcticamente los mismos servicios. Fundamentalmente, deben identificar y clasificar requisitos. Estas herramientas permiten entender las necesidades del usuario, lo que supone el punto de partida para el desarrollo de la aplicacin adecuada, y al mismo tiempo, proporcionan el patrn sobre el que medir el xito logrado en la implementacin final. La gestin de requisitos consiste en la captura, almacenamiento y gestin (organizacin, trazabilidad, anlisis y visualizacin) de la informacin. Si hablamos de trazabilidad, diremos que es un concepto clave. Supone la provisin de relaciones entre los requisitos, diseo e implementacin de un sistema, con el fin de gestionar los efectos del cambio y asegurar el xito del sistema desarrollado. Las herramientas de gestin de requisitos definen correctamente la trazabilidad pero no basta con asegurarla dentro de los lmites de estas herramientas sino que se debe asegurar dentro del conjunto de herramientas que se usen en el entorno. Por tanto, las herramientas deben
Pgina 26 de 219
integrarse correctamente con las dems herramientas para completar el ciclo de vida de un proyecto correctamente. En un estudio realizado por INCOSE (Requirements Working Group paper, Jones et al 1995) se identific las siguientes funcionalidades bsicas necesarias para que una herramienta se considere herramienta de gestin de requisitos: Debe identificar requisitos. Debe clasificar requisitos. Debe proveer una interfaz de atributos bsicos. En este estudio se analizaron 15 herramientas comerciales en funcin de si cumplan o no diferentes caractersticas. Casi todas las herramientas elegidas para el estudio cumplan las necesidades bsicas exigibles, entre las que estaban la captura e identificacin de los requisitos, el anlisis de la trazabilidad, la integracin con otras herramientas, adquisicin de documentacin y ficheros de salida. En general, todas las herramientas se centran en sistemas de gestin de bases de datos, con el fin de poder almacenar todo la informacin referente a los requisitos. La definicin de un requisito se hace mediante texto libre con una serie de atributos. Respecto a la clasificacin de los requisitos, suele ser jerrquica, basada en el tipo de requisitos o en los atributos de requisitos. Adems, cada requisito puede estar formado o depender de otros requisitos, por tanto, es importante hablar sobre el anlisis de impacto de cambio. Cuando un requisito cambia, se debe tener en cuenta que probablemente este cambio afecte a otro requisito. La herramienta debe ser capaz de identificar todos los requisitos afectado debido a este cambio. Se podr aadir, modificar o borrar cualquier requisito. Las herramientas pueden estar disponibles en diferentes idiomas y se pueden encontrar herramientas de libre distribucin, comerciales y disponibles en Web, que permiten la distribucin y comparticin de requisitos on-line. Adems, suelen generar diferentes documentos de salida como informes, esquemas o grficos, con el fin de tener una visin ms prctica. Algunas herramientas permiten asociar requisitos a travs de archivos externos guardados en disco, en texto o URLs. En general, estas herramientas buscan crear una base solida para que el proyecto pueda desarrollarse de una forma organizada.
Pgina 27 de 219
3.5 Anlisis detallado de las herramientas.

Como ya dijimos en anteriores apartados, las herramientas de gestin de requisitos mejoran indiscutiblemente la calidad del proyecto software. Definir correctamente lo que busca el cliente es fundamental para partir de una base robusta y consistente. Existen infinidad de herramientas capaces de facilitar en lo posible la gestin de los requisitos. Estas herramientas son, en mayor o menos medida, complejas y sofisticadas pero ahorran en costes y minimizan el impacto de errores. A continuacin se va a presentar un anlisis sobre algunas de las herramientas capaces de llevar una correcta gestin de requisitos. Hay que tener en cuenta que, debido a la gran cantidad de opciones que ofrecen estas herramientas y a que no se les dio un uso muy prolongado, sino solo el necesario para este pequeo estudio, las caractersticas aqu presentadas es probable que no sean del todo completas. El uso de estas herramientas durante un largo periodo de tiempo y sobre un proyecto real dara mucha ms validez a este informe. A continuacin se mostrarn las caractersticas principales de cinco herramientas elegidas: 3.5.1 Doors Telelogic. Esta herramienta, destacable en el mercado, forma parte de una familia de soluciones que mejoran la calidad y optimizan la comunicacin y la colaboracin. Se encarga de gestionar los requisitos, enlazar, trazar, analizar y manejar un amplio rango de informacin para asegurar la adecuacin del proyecto a los requisitos y estndares. Doors Telelogic proporciona las siguientes funcionalidades: Importar/exportar: Nos permite importar y exportar informacin mediante Microsoft Word, Excel, PowerPoint, Outlook, textos planos (ASCII), hojas de clculo y RTF, entre otros. Vistas del documento: Con un simple vistazo del documento pueden ser visualizados todos los requisitos, atributos y relaciones entre ellos. Los objetos pueden contener requisitos, grficos y otro tipo de informacin como hyperlinks u OLEs. Trazabilidad: dispone de una matriz de trazabilidad de requisitos fcil de usar y actualizar. Se encarga de mantener y gestionar las dependencias entre los distintos requisitos estableciendo una trazabilidad entre ellos.
Pgina 28 de 219
Mltiples proyectos concurrentes: Doors soporta trabajo concurrente con mltiples documentos, incluyendo creacin de dependencias. Flexibilidad en el tamao del proyecto, aceptando un nmero ilimitado de usuarios. Firma electrnica: para mantener responsabilidades y comunicacin. Integracin completa del ciclo de vida y trazabilidad: por va de varios programas de integracin, incluyendo herramientas de modelado, pruebas, cambios, gestin de la configuracin y otras reas del ciclo de desarrollo. Es capaz de integrarse con diferentes aplicaciones como Telelogic Change (Gestin de defectos), Doors Analyst (Trazabilidad entre requisito y elementos UML), DOORS Informes Test (gestin de casos de prueba), Telelogic Dashboard, ChangeSynergy (Gestin de incidencias y ordenes de Trabajo) o DOORS planificacin Test.
El usuario puede navegar a travs de los distintos documentos fcilmente. La vista del Explorador proporciona una jerarqua de proyectos y carpetas muy similar a la mostrada por el Explorador de Windows. Los requisitos se definen mediante atributos como prioridad (High, Medium o Low) estado, fuente del requisito o comentarios, lo que ayuda a gestionar mejor y ms eficientemente los requisitos mediante bsquedas, ordenaciones o filtros. Doors dispone de una barra de cambios a la izquierda de cada requisito, representada en un color (green, yellow o red), del cual depende el estado de cambio del requisito. Adems, la relacin entre dos requisitos se establece mediante un link o enlace. Por un lado, es posible unir requisitos dentro de un mismo documento (Drag and drop). Con solo pulsar el enlace se llegar hasta el otro requisito dentro del mismo paquete. Por otro lado, se crea la necesidad de unir requisitos entre diferentes proyecto. Cada requisito relacionado tiene adjudicada una flecha representada a la derecha del requisito, para observar la trazabilidad que presenta con requisitos de paquetes diferentes, solo hemos de pulsar dicha flecha. Estos enlaces tienen direccin, lo que hace ms clara la relacin y la navegacin entre los diferentes requisitos.
Pgina 29 de 219
Figura 6. Representacin de relacion de requisitos en Doors Telelogic
Por ltimo se ha de mencionar que aunque la versin instalable de la herramienta es completa e impecable, la versin Web de la misma deja mucho que desear. Solamente tiene disponible una mnima parte de las funcionalidades totales que presenta la herramienta en s, lo que originar una incompleta satisfaccin de las necesidades que una adecuada gestin de requisitos es capaz de originar. 3.5.2 CaliberRM 6.0. Herramienta creada por Borland para facilitar la definicin, el anlisis y la gestin de los requisitos software, mejorando en su calidad y reduciendo el nivel de fracaso. Esta herramienta es famosa fundamentalmente por su facilidad de uso, puesto que permite una rpida adopcin para personal no tcnico y adems, actualmente est muy bien posicionada en el mercado. Dentro de la herramienta CaliberRM, los requisitos se pueden clasificar en varios paquetes como requisitos de negocio, requisitos usuario, funcionales, de diseo y escenarios de prueba, entre otros. Lo que la hace destacar puesto que otras herramientas no permites esta flexibilidad en cuento a la clasificacin de los requisitos. Adems, de cada requisito se aporta una gran cantidad de informacin. Partiendo de un identificador, fijado automticamente, y una versin, que ir cambiando a raz que modifiquemos las caractersticas, se puede introducir atributos como el nombre del requisito, descripcin, creador, estado, prioridad (esencial, til, deseable, sin asignar,) o un historial de revisiones. Destacar que el historial muestra informacin sobre los cambios que se han realizado dentro del proyecto, guardando el cdigo del atributo modificado, el autor responsable de dicho cambio, la fecha, el valor antiguo y valor nuevo.
Pgina 30 de 219
Figura 7. Representacin del aspecto de CaliberRM
CaliberRM dispone de un repositorio (vista grid de requisitos) centralizado y seguro de manera que todos los requisitos de un proyecto estn localizados. As, los requisitos de un proyecto se gestionan a travs del ciclo de vida de la aplicacin, mejorando la comunicacin entre los diferentes participantes y facilitando la deteccin temprana de posibles errores. Permite el acceso a travs de protocolos de Internet. Con mnimos requisitos de ancho de banda se permite que los miembros del equipo tengan un acceso rpido a los requisitos del proyecto y participen en discusiones online para capturar la informacin. CaliberRM proporciona mltiples mtodos para la visualizacin de la trazabilidad, que ayudan a los usuarios a comprender inmediatamente el alcance del anlisis requerido para calibrar el impacto del cambio de los requisitos. Si un cambio realizado afecta a cualquier otro requisito, prueba, tarea y/o cdigo CaliberRM muestra esta informacin a tiempo real. Por otra parte, CaliberRM puede ser configurado fcilmente, a travs una amigable interfaz grfica, dependiendo del tipo de proyecto que est desarrollndose. Los requisitos se puede enlazar con otras aplicaciones como CaliberRM document factory, CaliberRM DataMart o Microsoft Project que complementan y automatizan el ciclo de vida del desarrollo software e incluye Estime Pro,
Pgina 31 de 219
herramienta que permite la estimacin de proyectos mediante comparaciones. Estas estimaciones ayudan a determinar el alcance del proyecto y por tanto, ayudan indudablemente a mejorar en personal, tiempo y recursos econmicos, adaptando el proyecto a los requerimientos de la empresa. Otra de las funcionalidades a destacar es que permite crear un glosario de trminos especficos. En general, los glosarios ayudan a que todos los miembros del proyecto entiendan los requisitos de la misma forma, definindose en l trminos ambiguos e inestables. Este glosario es global y se puede compartir entre proyectos. Todos los usuarios podrn aadir, modificar, borrar y buscar trminos es este glosario. Adems, desde la descripcin de cada requisito es posible llegar directamente hasta el glosario puesto que cada uno de estos trminos se convierte en un enlace. Por ltimo, hemos de exponer varios inconvenientes sobre la herramienta. Lo primero a destacar es su alto precio de licencia. Por otra parte, esta herramienta adquiere una debilidad importante al tener que ser instalada en cada mquina en la que vaya a ser utilizada. Esto hace ms complicada la gestin de software, dificultando las actualizaciones del mismo. 3.5.3 Software Planner 9.0. Herramienta orientada a la gestin de software. Recoge todas y cada una de las etapas del desarrollo de un programa. Es una herramienta muy completa y est presente en todos los campos tratados en un proyecto software (gestin de requisitos, casos de prueba, errores y fase de integracin). Nos vamos a centrar en las funcionalidades ms importantes que proporciona Software Planner para la realizacin de la gestin de requisitos: Importa/Exporta documentos. Es capaz de realizar bsquedas y filtrar requisitos. Dispone de un men desplegable en la parte izquierda y varias pestaas con las funcionalidades ms importantes en la parte superior. Diagramas: muestra salidas de informacin como estadsticas o grficos. A pesar de que la aplicacin est muy elaborada y, a consecuencia de ello el aprendizaje ser complicado, las posibilidades que ofrece en lo referente a la gestin de requisitos no son todo lo que cabra esperar de una aplicacin semejante. La herramienta est ms orientada a la gestin de proyectos y funcionalidades CRM que a la gestin de requisitos. Es una buena herramienta
Pgina 32 de 219
solo que con el inconveniente que no profundiza todo lo necesario en la gestin de requisitos. 3.5.4 REM (Requirements Management). Herramienta experimental gratuita desarrollada por la Universidad de Sevilla. Dispone de una gran sencillez conceptual, basada en plantillas y patrones lingsticos, lo que hace iniciar a gente inexperta en el proceso de Ingeniera de Requisitos. En REM, un proyecto est compuesto por cuatro documentos: Documento de requisitos del sistema, Documento de anlisis del sistema, Registro de conflictos y defectos y Registro de peticiones de cambio en los requisitos, donde se ir registrando toda la informacin apropiada. Todos los proyectos se almacenan como archivos con extensin .rem. Esta herramienta es capaz de crear objetos a los cuales se le pueden asignar hijos a modo de rbol. Todos estos objetos tiene la opcin de clonarse, editar sus propiedades o eliminarse. Dentro del rbol de objetos es posible arrastrar objetos de un lugar a otro. Todos los objetos tienen propiedades comunes y especificas de cada tipo de objeto, de las que destacamos el identificador que ser fijado automticamente, el nombre del objeto, la versin, la fecha de creacin, el o los autores, una descripcin, la prioridad y un historial. Hay varios tipos de objetos dentro de la herramienta: Generales: Encontramos las secciones o apndices (dividen el documentos en carpetas), trminos de glosario (incluyen enlaces al mismo glosario), fichero grfico (inserta imgenes externas en el documento), organizacin, participantes (personal que participa en el proyecto. Permite asociar autores y fuentes a los dems requisitos) y reuniones. Requisitos: objetivos, casos de uso, requisitos de informacin (informacin que debe almacenar el sistema para cumplir los objetivos), requisitos de restriccin (regla de negocio que debe tenerse en cuenta el crear un nuevo sistema), casos de uso (servicio que el sistema debe prestar a los actores), requisitos funcionales y no funcionales y matriz de rastreabilidad (visualiza las dependencias registradas en el proyecto). Modelado: Tipos de objetos (clases que pueden tener atributos y componentes), tipo de valor, asociacin (relacin entre dos tipo de
Pgina 33 de 219
objetos. Dispone de atributos, componentes y roles) y operacin del sistema. Gestin: conflicto (problema detectado en un requisito), defecto (falta de calidad en uno o varios requisitos) y peticin de cambio.
Figura 8. Representacin de las caractersticas de un requisito en REM
Esta herramienta no permite la creacin de grficos ni diagramas, nicamente, como ya hemos comentado, proporciona la posibilidad de crear documentos. La pantalla principal muestra en todo momento una previsualizacin del documento ordenado. Es posible guardar este documento generado en formato .html. Su principal inconveniente radica en que se trata de un proyecto llevado a cabo de forma individual dentro de una tesis doctoral por lo que se trata de un proyecto que, a largo plazo, no va a tener sostenibilidad. 3.5.5 OSRMT 1.3 (Open Source Requirements Management Tool). Herramienta de software libre que permite una descripcin avanzada de diversos tipos de requisitos y garantiza la trazabilidad entre todos los documentos relacionados con la ingeniera de requisitos (funcionalidades, requisitos, casos de uso y casos de prueba). Los diversos mdulos integrados en la herramienta son: Administracin y Configuracin: Se van a definir los atributos de las diferentes funcionalidades, requisitos y casos de prueba. Adems cada usuarios fijar valores predefinidos (Valores por defecto de prioridades, estados, versiones,..) y personalizar sus vistas.
Pgina 34 de 219
Gestin de documentos de ingeniera de requisitos. Trazabilidad entre documentos de trabajo: la trazabilidad se produce entre requisitos frente a requisitos, funcionalidades o casos de prueba. Es posible visualizar la matriz de trazabilidad entre los diferentes componentes, as como, un rbol de trazabilidad o un grfico de dependencias entre diferentes documentos. Informes y estadsticas: Los informes y estadsticas creados podrn ser bsicos o especficos, con la posibilidad de ser exportados a HTML o PDF. Adems cabe destacar que la creacin de estos informes se hace a travs de la herramienta Ireport.
Dispone de bsquedas avanzadas (filtros y ordenaciones) sobre los documentos de trabajo. Esta aplicacin es capaz de adjuntar imgenes o cualquier otro tipo de archivo, as como crear arboles de trazabilidad o matrices de vnculos. Dispone de un entorno multiusuario, es decir, varios usuarios puede conectar al mismo tiempo a la herramienta sin ningn tipo de problema. Adems, es posible conectarse desde una URL. Ante cualquier problema o duda sobre la funcionalidad de la herramienta se dispone de una ayuda en lnea y un manual de usuario. Adems, dispone de una pgina web principal y telfono de apoyo.
Figura 9. Representacin de las caractersticas de un requisito en OSRMT
Dentro de las herramientas open source que abarca la ingeniera de requisitos, se trata de la herramienta que mejores funcionalidades ofrece. La visualizacin de requisitos es intuitiva y fcil de usar, ofrece, como ya hemos comentado
Pgina 35 de 219
anteriormente, un cliente web para accesos desde internet y est muy bien documentada pero es importante destacar que consiste en una herramienta llevada a cabo por un nico desarrollador por lo que existe un riesgo importante de no poder ser sostenible a largo plazo.
3.5.6 Gatherspace. Herramienta Web capaz de editar, compartir y distribuir requisitos on-line. Puesto que se necesita nicamente de un navegador Web, esta herramienta se hace independiente de la plataforma, descarta la necesidad de instalacin y es portable 100% a cualquier sistema operativo. Es sencilla de utilizar puesto que todas las funcionalidades de la aplicacin estn organizadas en un men de pestaas muy intuitivo. Los requisitos se agrupan es paquetes y caractersticas de manera que estn ordenados y son fcilmente localizables dentro de cada paquete. Dentro del men de pestaas encontramos: Requisitos: Permite gestin paquetes, caractersticas, requisitos de software, iteraciones, actores, casos de uso, crear lneas base o trminos en el glosario. Proyectos: Se encarga de la gestin de proyecto. Informes: Permite crear documentos sobre los requisitos, modelos de casos de uso, trazabilidad entre los diferentes requisitos, etc. Ediciones /Cambios de peticiones. Gestin de la cuenta: Contiene toda la informacin de la cuenta registrada, atributos importantes como el identificador nico de la cuenta, tipo de cuenta, fecha de registro, nombre de la compaa, telfono de contacto, etc. Bsquedas: Permite buscar paquetes, atributos, actores, casos de uso o cualquier otra caracterstica que se necesite encontrar dentro del proyecto.
Pgina 36 de 219
Figura 10. Representacin de las caractersticas de un requisito en Gatherspace
Como inconvenientes importantes de la herramienta destacamos que el manejo de la misma, al ser una herramienta web, puede ser lento puesto que estamos a expensas del servidor. Este se puede encontrar cado o sobrecargado lo que ralentizar o restringir el trabajo en el proyecto. Es una herramienta web sencilla y por ello es muy limitada en cuanto a funcionalidades, que en ocasiones s que son tiles a la hora de realizar un proyecto completo y bien documentado. No dispone de control de versionado, ni historial ni se pueden crear lneas base, lo que hace que la informacin de nuestro proyecto est incompleta respecto a los cambios producidos en el mismo. Esta herramienta no permite la conexin multiusuario ni dispone de ayuda en lnea por lo que si se tiene alguna duda sobre el funcionamiento de la herramienta, ser el usuario el que tenga que ingniaselas para resolver el problema por sus propios medios. La realizacin de los diagramas de casos de uso deja mucho que desear puesto que cada diagrama solo puede tener un actor, por lo tanto se hace necesario la utilizacin de otra herramienta para creer los diagramas necesarios.
Pgina 37 de 219
3.6 Anlisis comparativo y conclusiones:

A continuacin se representa, mediante unas tablas comparativas, que funcionalidades y caractersticas poseen las herramientas elegidas. Este anlisis se ha realizado con el fin de poder desarrollar una sencilla pero completa herramienta de gestin de requisitos que se acerque en la medida de lo posible a las herramientas reales que existen. Al finaliza se realizar una representacin Valor-Tecnologa-Riesgo.
Pgina 38 de 219
HERRAMIENTAS GESTIN DE REQUISITOS Doors 9.1 Requisitos Tcnicos

Idioma disponible Ingls Idioma disponible Espaol Otro idioma disponible Herramienta Comercial Herramienta Libre Herramienta Web Herramienta con disponibilidad de Versin Libre Funciona sobre SSOO Windows Funciona sobre SSOO Linux Funciona sobre otro SSOO Necesidad de una Base de datos Se puede trabajar en mltiples proyectos a la vez Mltiple usuarios concurrentes X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X
CaliberRM 6.0
Software Planner
REM 1.2.2
OSRMT
Gatherspace
X X X X X X X X X X
REQUISITOS
Pgina 39 de 219
HERRAMIENTAS GESTIN DE REQUISITOS Doors 9.1 Captura e identificacin de requisitos

Posibilidad de registrar un requisito (id, fuente, estado, categora, descripcin, comentarios,) Identificacin de requisitos automtica Permite personalizar el orden de los requisitos Gestin de categoras de requisitos Gestin de estado de requisitos X X X X X X
CaliberRM 6.0
Software Planner
REM 1.2.2
OSRMT
Gatherspace
X X
X X X X X
X X X X
REQUISITOS
X X
X X
Anlisis de la trazabilidad
Gestin de la trazabilidad entre requisito y requisito Permite visualizar un grfico de las dependencias Permite creacin de documentos de trazabilidad del proyecto X X X X X X X X X X
Pgina 40 de 219
HERRAMIENTAS GESTIN DE REQUISITOS Doors 9.1 Gestin de la configuracin REQUISITOS

Historial de cambios: quien, que, cuando, donde, porque y como. Gestin de versionado de los requisitos (quien y como se modific) Gestin de lnea base del requisito Consulta sobre la variabilidad de los requisitos X X X X X X X X X X X X X X X X X X
CaliberRM 6.0
Software Planner
REM 1.2.2
OSRMT
Gatherspace
Pgina 41 de 219
HERRAMIENTAS GESTIN DE REQUISITOS Doors 9.1 Requisitos Funcionales

Permite creacin de documentos Permite creacin de Informes Microsoft Permite creacin Informes PDF. Permite creacin Informes HTML Permite creacin diagramas UML Alertas por email Permite creacin de grficos Permite visualizar todos los requisitos, atributos y relaciones en un nico documento. Dispone de un repositos central donde se almacenan los requisitos Agrupamiento de requisitos por paquetes Ofrece soporte de pruebas Filtrar requisitos Permite realizar bsquedas Dispone de un glosario Dispone de un men de pestaas Dispone de un men contextual Listar la relacin entre requisitos X X X X X X X X X X X X X X X X X X X X X X X X X X X X X
CaliberRM 6.0
Software Planner
REM 1.2.2
OSRMT
Gatherspace
X X X X X X X X
X X
X X
X X X X X X X X X X X X
X X X X X X
Pgina 42 de 219
HERRAMIENTAS GESTIN DE REQUISITOS Doors 9.1 Interfaces con otras herramientas

Comunicaciones inter (externas) de herramientas Dispone de interfaces con otras herramientas Soporta sistemas abiertos de bases de datos Importa datos desde diferentes formatos de fichero Integracin con otros productos Exporta documentos generados X X X X X X X X X X X X X X X X X
CaliberRM 6.0
Software Planner
REM 1.2.2
OSRMT
Gatherspace
REQUISITOS
Pgina 43 de 219
HERRAMIENTAS GESTIN DE REQUISITOS Doors 9.1 Mantenimiento y soporte

Garanta Poltica de licencia de red Poltica de modernizacin y mantenimiento Ayuda en lnea Acceso a Internet/pgina principal de Internet Telfono de soporte Grupo de usuarios de soporte X X X X X X X X X X X X X X X X X X X X X X X X
CaliberRM 6.0
Software Planner
REM 1.2.2
OSRMT
Gatherspace
REQUISITOS
HERRAMIENTAS GESTIN DE REQUISITOS Doors 9.1 Formacin REQUISITOS

Clases especificas de formacin de la herramienta Formacin disponible en el sitio Web X X X X
CaliberRM 6.0
Software Planner
REM 1.2.2
OSRMT
Gatherspace
Pgina 44 de 219
Pgina 45 de 219
Para complementar, y que no exista ninguna ambigedad en el diagrama expuesto anteriormente, se realizar una breve explicacin sobre los conceptos que se han tenido en cuenta a la hora de representar cada una de las herramientas en el diagrama: Doors Telelogic: Consiste en una herramienta con un gran nmero de funcionalidades lo que la hace destacable entre las dems y la posiciona correctamente en el mercado. Trabaja bajo cualquier sistema operativo ampliando as el nmero de clientes que harn uso de dicha herramienta; Se integra con otros muchos productos para crear planes de prueba o mediciones de rendimiento, entre otros; Doors Telelogic permite la creacin de diagramas UML como casos de uso, diagramas de clase, diagramas de actividad, de componentes, de integracin, de secuencia y organigramas. Respecto al valor que proporciona Doors Telelogic se ha de destacar la optimizacin del alineamiento de negocio en requisitos, el gran alcance de los proyectos realizados y las buenas relaciones con el cliente. Adems, esta herramienta se adapta perfectamente a la situacin independientemente del tamao o la madurez de las empresas donde ha sido implantada o se implantar en un futuro. Doors Telelogic es una herramienta muy completa y por ello algunas de las funcionalidades que presenta pueden resultar complicadas de entender y ambiguas, Doors Telelogic requiere conocimientos tcnicos previos para su uso lo que a veces puede resultar un riesgo en la eleccin de la herramienta. Caliber RM: A pesar de que Caliber RM es una herramienta bastante bien estructurada y completa no cuenta con algunas de las funcionalidades importantes en una herramienta de este calibre: Caliber RM no es soportable bajo todos los sistemas operativos, no contiene opciones de bsquedas ni de filtros y no genera informes de salida con formatos PDF o HTML, entre otros. El lado positivo de esta herramienta es que dispone de un repositorio centralizado donde se almacenan todos los requisitos disponibles, creando una gran estructura ordenada. Adems, se integra con varias herramientas, del tipo Microsoft Office Project, Modeling, test o EDI Tools, que permiten completar el ciclo de vida de un proyecto.
Pgina 46 de 219
Caliber RM permite definir trazas de estado de desarrollo de un producto (impacto de cambio). Es una herramienta con un gran nivel de adaptabilidad puesto que dispone de una gran agilidad en procesos de especificacin de requisitos. Caliber RM dispone de un acceso Web que la mayora de las veces resulta ms cmodo puesto que se agilizan las operaciones y mejora las discusiones online, pero hay que tener en cuenta que puede resultar de gran riesgo si no se cuentan con unas estructuras firmes y adecuadas y existen a menudo fallos. Comentar tambin, que el precio de la licencia es elevado en comparacin con otras herramientas de gestin de requisitos lo que descarta como posibles clientes a pequeas y medias empresas que no dispongan de capital suficiente para la compra. Software Planner: Estamos ante una herramienta completa, bien posicionada en el mercado y con un gran nmero de funcionalidades. Recoge todas las etapas de un proyecto software adquiriendo as madurez y responsabilidad ante cualquier proyecto. Dispone de un gran valor TI pero los aspectos tecnolgicos se quedan alejados de muchas otras herramientas dedicadas exclusivamente a la gestin de requisitos, lo que generar un riesgo a la hora de capturar clientes que busquen desarrollar de forma amplia y completa esta etapa. REM: REM consiste en una herramienta creada para fines educativos. Es una herramienta gratuita, muy simple y sencilla de utilizar, por tanto, las funcionalidades y caractersticas de las que dispone son muy bsicas. REM permite crear nicamente documentos normalizados, donde se incluyen los requisitos necesarios para el desarrollo de un sistema de informacin. No admite diagramas UML, ni graficas, ni grafos. REM dispone de una estructura muy rgida y unos servicios ofrecidos muy limitados que no permiten adaptarse a cambios, ni necesidades. Si hablamos del riesgo que genera esta herramienta diremos que, puesto que es una herramienta experimental creada de forma individual, ser un proyecto sin sostenibilidad ni apoyo.
Pgina 47 de 219
OSRMT: A pesar de que consiste en una de las herramientas de tipo open source ms destacable, puesto que posee las caractersticas y funcionalidades ms bsicas dentro de las herramientas que abarcan la ingeniera de requisitos, se queda an lejos de ocupar los primeros puestos. Las funcionalidades son escasas, es una herramienta poco madura y puesto que ha sido llevada a cabo por un nico desarrollador, existe un riesgo importante de no poder ser sostenible a largo plazo. Gatherspace: Consiste en una herramienta Web, lo que implica que funciona a travs de un navegador y, por tanto, bajo cualquier sistema operativo, pero hay que tener en cuenta que se pueden producir interrupciones o no estar disponible en todo momento, adems de tener un funcionamiento lento si se trabaja con conexiones de red pequeas. Respecto a las funcionalidades se ha decir que esta herramienta responde bien a las caractersticas bsicas de una herramienta de este calibre: permite edicin, comparacin y distribucin de requisitos on-line, exportacin e importacin de documentos, creacin de documentos de trazabilidad entre casos de uso, requisitos y carpetas, entre otras funcionalidades no menos importantes, aunque no dispone de versionado e historial de cambios, que sin ellos la informacin de los requisitos queda incompleta.
Pgina 48 de 219
4. Principales caractersticas de las herramientas a disear

4.1 Descripcin general.
El sistema a desarrollar ser una herramienta para la gestin de requisitos de un proyecto software. Se pretende que sea una herramienta sencilla pero til, que permita crear, clasificar y mantener un catlogo de requisitos. Adems, debe tratar las relaciones entre los requisitos, control de versionado, trabajar con el glosario de trminos y obtener informes que muestras una relacin de los requisitos, entre otras funcionalidades. El desarrollo de esta herramienta pretende mejorar, facilitar o ampliar las posibilidades que ofrecen otras herramientas del mismo tipo. Si regresamos al apartado 3 se puede visualizar el estudio realizado sobre las diferentes herramientas existentes en el mercado actual. La herramienta est destinada a todas aquellas personas o empresas que quieran disponer de un modo eficaz de una herramienta capaz de administrar sus requisitos. Se pretende que la herramienta sea amigable y su aprendizaje sencillo, pero, obviamente, el usuario ha de tener unos conocimientos acerca de la ingeniera de requisitos, as como de la gestin de los mismos.
4.2 Principales caractersticas.

Las funcionalidades ms destacables de la herramienta son: Gestin de proyectos: La aplicacin permitir la gestin de mltiples proyectos. Gestin de carpetas: Se podrn crear una o varias carpetas dentro de cada proyecto, de manera que se pueda tener la informacin ordenada y agrupada jerrquicamente. Gestin de requisitos: Se dar soporte a todas las tareas relacionadas con la gestin de requisitos de un proyecto. Atributos como el estado de un requisito, quien los solicita, quien los soporta, fecha de creacin, fecha de cambios, valor que aporta en eficiencia, valor que aporta en
Pgina 49 de 219
innovacin estratgica, proceso ITIL al que pertenece, tipo de requisito, etc. sern utilizados en la aplicacin. Incluir un atributo referido a la versin del requisito, as como de un historial de requisitos donde se detallar la vida de todos los requisitos, fechas de creacin y cambios. Gestin de usuarios: La herramienta dar soporte a la creacin, modificacin y eliminacin de usuarios que han accedido a la herramienta. Cada usuario deber validarse antes de entrar en la aplicacin. Gestin de roles: Cada uno de los usuarios tendr un rol asignado previamente. El rol del que dispone cada usuario le va a permitir o no acceder a determinados sitios. Informes: Por un lado, la aplicacin permite salidas de informacin sobre la trazabilidad que tienen los diferentes requisitos de un proyecto, y por otro, se permitir obtener informes comparativos entre carpetas.
Pgina 50 de 219
4.3 Diseo conceptual de los principales requisitos.

A continuacin se van a exponer y explicar los conceptos ms importantes sobre los que se va a basar el diseo del sistema. En primer lugar hay que indicar que habr dos partes bien diferenciadas referente a los requisitos de la aplicacin: 1. Informacin sobre las mejores prcticas de servicios TI. 2. Informacin de cada organizacin que dispondr, por un lado de los requisito que proporciona ITIL y por otro los requisitos aportados por la propia empresa. De esta forma, cuando se aada una organizacin se cargarn los requisitos que da la herramienta ITIL y despus los requisitos pertenecientes nicamente a la organizacin, que ser la propia organizacin la encargada de gestionarlos.
Figura 11. Representacin de requisitos en WebITSM
Pgina 51 de 219
Para mantener una estructura ordenada y sencilla, los requisitos de la aplicacin se agruparan en diferentes jerarquas. As se podr hacer un seguimiento de los requisitos rpido y eficaz, ahorrando quebraderos de cabeza y bsquedas de requisitos sin xito.
Figura 12. Jerarqua de requisitos en WebITSM
Pgina 52 de 219
El usuario que entra en la aplicacin, previa validacin, va a tener un rol, Administrador, Jefe de proyecto o Usuario, del que depender para acceder a las diferentes funcionalidades que proporciona la aplicacin.
Figura 13. Accesos a WebITSM
Pgina 53 de 219
A partir de los requisitos de la organizacin se pueden obtener informes comparativos para facilitar la gestin de servicios en el proyecto. As, estos informes proporcionaran informacin sobre las relaciones que presentan los diferentes requisitos y adems la organizacin podr conocer que requisitos de la herramienta ITIL cumple o cuales no, y por tanto cuales necesita implementar para mejorar la eficacia de su proyecto.
Figura 14. Informes de salida en WebITSM

Pgina 54 de 219
5. Entorno tcnico de trabajo

5.1 Firefox Mozilla.
Navegador de internet libre. Gracias a l se ha podido navegar por la Web con el fin de ayudar a completar parte de la informacin representada. Se han obtenido las descargas de las herramientas de gestin de requisitos tiles para su estudio as como documentos, estudios, manuales, noticias, graficas, estadsticas y toda la informacin necesaria e interesante para un desarrollo completo del proyecto.
5.2 Microsoft Office Word 2007.

Este procesador de texto se ha utilizado para poder realizar la memoria de este proyecto. Se ha seguido una plantilla estructurada con la finalidad de crear un documento elegante y fcil de leer.
5.3 Microsoft Visual Studio.

Consiste en un en entorno de desarrollo integrado (IDE) para sistemas Windows. A pesar de que soporta varios lenguajes de programacin, en nuestro caso se destacar Visual Basic .Net y ASP.NET, a travs del cual se crear una aplicacin web, utilizando como servidor de aplicaciones Internet Information Services (IIS). Una de las caractersticas fundamentales del lenguaje Visual Basic .Net es que utiliza el Framework .Net, lo que permite que sea independiente de la maquina donde se est ejecutando la herramienta. En nuestro caso utilizaremos: Visual Basic Edition SQL Server Edition
Visual Web Developer Edition
5.4 Visual Basic .Net

Consiste en un lenguaje de programacin de fcil y rpido aprendizaje. Est guiado por eventos e integra el diseo y la implementacin de formulario Windows, lo que conlleva a un desarrollo de aplicaciones grficas. Hay tres conceptos fundamentales:
Pgina 55 de 219
Propiedades: Para todos los objetos y controles de Visual hay definidas una serie de propiedades. Eventos: Cada objeto lleva definidos una serie de eventos determinados que le pueden ocurrir. Mtodos: Son procedimientos asociados a un objeto.
Entre las caractersticas ms destacadas: Lenguaje basado en objetos (Programacin orientada a eventos): los formularios que se construyen, los controles integrados en cada uno de los formularios y las bases de datos, entre otros elementos, son objetos. Permite el polimorfismo. Consta de varias bibliotecas: A travs de ADO.NET se realizan conexiones a diferentes bases de datos con el fin de poder manejar informacin contenida en tablas o consultas.
5.5 Microsoft SQL Server 2005

Microsoft SQL Server es un sistema de gestin de bases de datos relacional (SGBD), basado en el lenguaje T-SQL. Las caractersticas ms importantes son: Soporte de transacciones. Escalabilidad y estabilidad. Procedimientos almacenados: Gracias a SQL Server se puede crear estos elementos de la base de datos capaces de realizar operaciones tales como insercin, actualizacin o eliminacin de registros de la propia base de datos. Permite trabajar en modo cliente-servidor.
5.6 ASP.NET
Gracias al entorno de desarrollo Microsoft Visual Web Developer se pueden crear sitios Web y aplicaciones Web con ASP.NET ms seguras y estables. El modelo ASP.NET permite a los desarrolladores escribir cdigo ms limpio y ms fcil de reutilizar, incrementando el rendimiento. Entre las caractersticas ms importantes se ha de destacar: Manejabilidad: ASP.NET utiliza un sistema de configuracin jerrquico de texto. Se evitan herramientas de administracin local, puesto que la informacin de configuracin se almacena como texto sin formato. Seguridad: Se dispone de esquemas de autenticacin y autorizacin predeterminados para las aplicaciones web.
Pgina 56 de 219
Internacionalizacin: ASP.NET utiliza Unicode internamente para representar datos. Alto rendimiento: Se puede optar por tener un servidor precompilado o dejar que el servidor lo compile la primera vez que se ejecute. Integracin con .NET Framework. Compatibilidad con aplicaciones ASP existentes.
Marco de trabajo de pginas
Configuracin (.config)
Servicios Web XML (.ASMX)
ASP.NET
Pagina de Web Forms (.aspx)
Pagina de Web Forms (.aspx)
Administracin de estado Seguridad de la Web Almacenamiento en cach

Estado de vista Estado de sesin Estado de aplicacin
ADO.NET
Proveedores de datos Comandos de datos Conjuntos de datos
Servidores en tiempo de ejecucin de .NET

Lenguaje y compilacin. Depuracin. Servicios del sistema operativo.
Figura 15. Encaje de componentes de las aplicaciones Web ASP.Net
Pgina 57 de 219
6. Anlisis
6.1 Objetivo.
El objetivo del Anlisis del Sistema de Informacin es la obtencin de una especificacin detallada de dicho sistema donde se representen la caracterstica que satisfacen las necesidades del propio usuario y, posteriormente, se pueda disponer de una gua de ayuda para la realizacin del diseo. En esta fase se realizar una definicin del sistema y de los usuarios que hacen uso del mismo. Se incluirn nicamente diagramas de casos de uso con el fin de crear un acercamiento al funcionamiento de la aplicacin.
6.2 Definicin del alcance del sistema.

El sistema consiste en una aplicacin capaz de gestionar los requisitos de una empresa, en principio cualquier tipo de empresa, y ser accesible mediante una interfaz Web. Las funcionalidades principales de las que dispone nuestra herramienta son: Validacin de usuarios: Los usuarios debern introducir su identificador y contrasea vlida para acceder a la aplicacin. Gestin de proyectos: La aplicacin permitir la gestin de mltiples proyectos. En la aplicacin se podr aadir, modificar, borrar y listar cualquier proyecto. Gestin de carpetas: La aplicacin permitir la gestin de mltiples carpetas dentro de un proyecto. En la aplicacin se podr aadir, modificar, borrar y listar cualquier carpeta. Gestin de requisitos: La aplicacin permitir la gestin de mltiples requisitos. El usuario podr aadir, modificar, borrar y listar requisitos de una carpeta, incluida en un proyecto.
Pgina 58 de 219
Gestin de usuarios: Se podr aadir, modificar, borrar y listar los datos de los usuarios dentro de la aplicacin. Existen tres tipos de usuarios: - Administrador - Jefe de proyecto - Usuario los cuales desempean funciones y tienen diferentes permisos, dentro de la aplicacin.
Gestin de informes: La herramienta permitir crear informes de texto a partir de la informacin introducida sobre los requisitos. Ser til para comparar, dentro de la misma organizacin, los requisitos de los que dispone y no da la herramienta ITIL y los requisitos que da la herramienta ITIL y no dispone la organizacin. Adems, la aplicacin permitir crear una jerarquizacin de los requisitos, es decir, representar las relaciones padre-hijo o hermanos-hermanos que tienen los diferentes requisitos. Gestin de actividades complementarias: La aplicacin dispondr de opciones de filtrado, bsquedas y ayuda online, as como de un glosario para evitar que algn concepto quede ambiguo.
6.3 Identificar usuarios

El usuario-tipo de la aplicacin es cualquier miembro del grupo de desarrollo cuyo proyecto est siendo gestionado por la herramienta. Para la utilizacin de la aplicacin el usuario deber tener unos conocimientos mnimos de la plataforma Windows y de manejo de exploradores Web. En la aplicacin existen tres tipos de roles: Administrador Persona encargada de realizar la configuracin general de la aplicacin. El Administrador tiene acceso a todas las pginas de la aplicacin y por tanto hacer uso de todas las funcionalidades. La aplicacin dispondr de un nico Administrador. Jefe de proyecto: Persona clave para la planificacin, ejecucin y control de los proyectos. Puede acceder a todas las funcionalidades de la aplicacin excepto a aquellas que son propias nicamente del Administrador. El nmero de Jefes de proyecto deber ser uno por cada proyecto creado.
Pgina 59 de 219
Usuario: Persona que solicita el desarrollo de un determinado proyecto, es decir, persona que proporciona las especificaciones y caractersticas que debe contener un producto. Es interesante, por tanto, que el Usuario pueda accede a la aplicacin con el fin de aadir, modificar y consultar requisitos. El usuario registrado con el rol Usuario tiene varias limitaciones a la hora de visualizar, modificar o eliminar informacin. El nmero de usuarios es ilimitado.
Antes de empezar a utilizar la aplicacin se ha de diferenciar entre Usuarios No Registrados y Usuarios Registrados. Para poder tener acceso a la aplicacin el Usuario No Registrado ha de validarse para obtener un nombre de usuario, una contrasea y un tipo de rol. Una vez validado correctamente pasar a ser Usuario Registrado y podr, por tanto, acceder a la aplicacin.
6.4 Especificacin de casos de uso

Los casos de uso expuestos darn una idea de la funcionalidad total de la aplicacin. En cada uno de los casos se especificar las operaciones que se pueden realizar y se detallar la interaccin de agentes externos. Para mayor legibilidad se presentar el modelo dividido en varios diagramas. Adems, a continuacin de cada caso de uso se aadir una descripcin textual que expondr la informacin necesaria para que el mismo quede suficientemente explicado.
Pgina 60 de 219
6.4.1 Usuario registrado y No registrado:
Figura 16. Diagrama caso de uso Usuario Registrado y No Registrado
Nombre: Actores: Objetivo:
Escenario bsico:
Validarse. Usuario No Registrado. Un Usuario No Registrado no podr acceder a la aplicacin. Para hacer uso de ella es necesario validarse como usuario de la misma. 1. Pulsar link Soy un nuevo usuario. 2. Introducir los datos personales oportunos, teniendo en cuenta que el usuario introducido debe ser nico dentro de la aplicacin. 3. Pulsar el botn Aceptar para iniciar sesin en la aplicacin. Iniciar sesin en proyecto. Usuario Registrado. Acceder a un proyecto (Acceder a la aplicacin). 1. Introducir Nombre de usuario, Contrasea y tipo de rol validos. 2. Pulsar el botn Aceptar. 3. Eleccin de un proyecto : 3.1 Elija un proyecto de la lista desplegable de proyectos disponibles para el usuario actual. 3.2 Pulse el link Quiero un nuevo proyecto si desea crear un nuevo proyecto (Solo visible para Administrador y Jefe de proyecto). 4. Pulsar el botn Iniciar para activar el proyecto.
Pgina 61 de 219
Nombre: Actores: Objetivo: Escenario bsico:
6.4.2 Administrador:
Figura 17. Diagrama caso de uso Administrador
Escenario bsico:
Gestionar proyectos. Administrador. Trabajar con todos los proyectos, es decir, aadir, modificar, borrar y listar proyectos segn convenga. Adems, tambin se podr asignar usuarios a proyectos determinados. 1. Dentro de un proyecto, pulsar el link Gestin de Proyectos. Gestionar carpetas. Administrador. Trabajar con todas las carpetas de cualquier proyecto, es decir, aadir, modificar, borrar y listar carpetas segn convenga. 1. Dentro de un proyecto, pulsar el link Gestin de Carpetas.
Escenario bsico:
Pgina 62 de 219
Escenario bsico:
Gestionar requisitos. Administrador. Trabajar con los requisitos de un proyecto determinado, es decir, aadir, modificar, borrar, listar, buscar requisitos y relacionarlos segn convenga. 1. Dentro de un proyecto pulsar el link Gestin de Requisitos. Gestionar usuarios. Administrador. Trabajar con los usuarios dados de alta en la aplicacin, es decir, aadir, borrar y modificar las caractersticas de los usuarios. 1. Dentro de un proyecto, pulsar el link Gestin de Usuarios. Gestionar roles. Administrador. El Administrador podr asignar, modificar y eliminar funcionalidades asociadas a los roles creados en la aplicacin. 1. Dentro de un proyecto pulsar el link Gestin de Usuarios. Gestionar Informe de trazabilidad. Administrador. Permite visualizar un informe, construido previamente dentro de la aplicacin, sobre las relaciones entre los diferentes requisitos de un proyecto. 1. Dentro de un proyecto, pulsar el link Informe de trazabilidad. Gestionar Informe comparativo. Administrador. Permite visualizar un informe comparativo entre requisitos de diferentes carpetas a elegir. 1. Dentro de un proyecto, pulsar el link Informe comparativo.
Escenario bsico:
Escenario bsico:
Escenario bsico:
Pgina 63 de 219
Escenario bsico:
Glosario. Administrador. Se ha creado con el fin de que en el caso de que un trmino resultara ambiguo dentro de la aplicacin, el usuario pueda consultar su definicin en todo momento. 1. Dentro de un proyecto, pulsar el link Glosario de trminos. Ayuda. Administrador. Es un gua fcil de utilizacin de la aplicacin, que el usuario puede consultar desde cualquier pgina, con el objetivo de resolverle cualquier duda acerca del funcionamiento de la aplicacin. 1. Dentro de un proyecto, pulsar el link Ayuda
Escenario bsico:
Pgina 64 de 219
6.4.3 Jefe de proyecto:
Figura 18. Diagrama caso de uso Jefe de proyecto
Escenario bsico:
Gestionar proyectos. Jefe de proyecto. Trabajar con los proyectos creados, es decir, aadir, modificar, borrar y listar proyectos segn convenga. Adems tambin se podr asignar usuarios a proyectos creados por el propio Jefe de proyectos. 1. Dentro de un proyecto, pulsar el link Gestin de Proyectos. Gestionar carpetas. Jefe de proyecto. Trabajar con las carpetas de los proyectos a los que pertenezca, es decir, aadir, modificar y listar segn convenga. 1. Dentro de un proyecto, pulsar el link Gestin de Carpetas.
Escenario bsico:
Pgina 65 de 219
Escenario bsico:
Gestionar requisitos. Jefe de proyecto. Trabajar con los requisitos de un proyecto determinado, es decir, aadir, modificar y listar requisitos y relacionarlos segn convenga. 1. Dentro de un proyecto pulsar el link Gestin de Requisitos. Gestionar usuarios. Jefe de proyecto. Visualizar o modificar la informacin personal. 1. Dentro de un proyecto, pulsar el link Gestin de Usuarios. Gestionar Informe de trazabilidad. Jefe de proyecto. Permite visualizar un informe sobre las relaciones entre los diferentes requisitos de un proyecto. 1. Dentro de un proyecto, pulsar el link Informe de trazabilidad. Gestionar Informe comparativo. Jefe de proyecto. Permite visualizar un informe comparativo entre requisitos de diferentes carpetas a elegir y requisitos que proporciona ITIL. 1. Dentro de un proyecto, pulsar el link Informe comparativo. Glosario. Jefe de proyecto. Se ha creado con el fin de que en el caso de que un trmino resultara ambiguo dentro de la aplicacin, el usuario pueda consultar su definicin en todo momento. 1. Dentro de un proyecto, pulsar el link Glosario de trminos. Ayuda. Jefe de proyecto. Es un gua fcil de utilizacin de la aplicacin que el usuario puede consultar desde cualquier pgina, con el objetivo de resolverle cualquier duda acerca del funcionamiento de la aplicacin. 1. Dentro de un proyecto, pulsar el link Ayuda
Escenario bsico:
Escenario bsico:
Escenario bsico:
Pgina 66 de 219
6.4.4 Usuario:
Figura 19. Diagrama caso de uso Usuario
Gestionar proyectos. Usuario. Visualizar una relacin de los proyectos a los cuales tal usuario est asignado. 1. Dentro de un proyecto, pulsar en link Gestin de Proyectos. Gestionar carpetas. Usuario. Trabajar con las carpetas del proyecto al que pertenece, es decir, visualizar, aadir y modificar segn convenga. 1. Dentro de un proyecto, pulsar en link Gestin de Carpetas.
Pgina 67 de 219
Escenario bsico:
Gestionar requisitos. Usuario. Trabajar con los requisitos del proyecto al que pertenece, es decir, aadir, modificar, buscar y relacionar requisitos segn convenga. 1. Dentro de un proyecto, pulsar en link Gestin de Requisitos. Gestin de usuarios Usuario. Permite visualizar y modificar los datos personales del propio usuario que ha iniciado sesin en la aplicacin. 1. Dentro de un proyecto, pulsar el link Gestin de Usuarios. Gestionar Informe de trazabilidad Usuario. Permite visualizar un informe de las relaciones entre los diferentes requisitos de un proyecto. 1. Dentro de un proyecto, pulsar el link Informe de trazabilidad. Gestionar Informe comparativo Usuario. Permite visualizar un informe comparativo entre requisitos de diferentes carpetas a elegir y requisitos que proporciona ITIL. 1. Dentro de un proyecto, pulsar el link Informe comparativo. Glosario. Usuario. Se ha creado con el fin de que en el caso de que un trmino resultara ambiguo dentro de la aplicacin, el usuario pueda consultar su definicin en todo momento. 1. Dentro de un proyecto, pulsar el link Glosario de trminos. Ayuda. Usuario. Es un gua fcil de utilizacin de la aplicacin que el usuario puede consultar desde cualquier pgina, con el objetivo de resolverle cualquier duda acerca del funcionamiento de la aplicacin. 1. Dentro de un proyecto, pulsar el link Ayuda
Pgina 68 de 219
Escenario bsico:
Escenario bsico:
Escenario bsico:
6.4.5 Gestin de proyectos:
Figura 20. Diagrama caso de uso Gestionar proyecto (Administrador)
Listar proyectos. Administrador. Visualizar una lista con las caractersticas de todos y cada uno de los proyectos creados en la aplicacin. 1. Dentro de Gestin de Proyectos, hacer clic en el link Listar proyectos. Se obtendr una lista de todos los proyectos de la aplicacin. Aadir proyecto. Administrador. Crear un nuevo proyecto en la aplicacin. 1. Dentro de Gestin de Proyectos, hacer clic en el link Listar proyectos. Se obtendr una lista de todos los proyectos de la aplicacin. 2. Pulse el enlace Quiero un nuevo proyecto. 3. Rellene los datos correspondientes a ese nuevo proyecto, comprobando previamente la disponibilidad del nombre del nuevo proyecto. 4. Pulsar Aceptar para finalizar la operacin.
Pgina 69 de 219
Modificar proyecto. Administrador. Modificar los datos de un proyecto. 1. Dentro de Gestin de Proyectos, hacer clic en el link Listar proyectos. Se obtendr una lista de los proyectos a los que tiene acceso. 2. Sobre el proyecto a modificar, pulse el botn Editar. 3. Modifique las caractersticas oportunas de la proyecto. 4. Confirmar la accin pulsando Ok. Borrar proyecto. Administrador. Eliminar un proyecto. 1. Dentro de Gestin de Proyectos, hacer clic en el link Listar proyectos. Se obtendr una lista de los proyectos a los que tiene acceso. 2. Sobre el proyecto a borrar, pulse el botn Borrar. Asignar Usuario a Proyecto. Administrador. Asignar/Borrar usuarios a proyectos determinados. 1. Dentro de Gestin de Proyectos, hacer clic en el link Aadir/ Borrar usuario en proyecto. 2. Hacer las elecciones oportunas, eligiendo el usuario y el proyecto a asignarle. 3. Confirmar la accin pulsando Aadir usuario a proyecto o en su defecto Borrar usuario en proyecto, si lo que desea es eliminar la relacin asignada entre usuario y proyecto.
Pgina 70 de 219
Figura 21. Diagrama caso de uso Gestionar Proyectos (Jefe de proyecto)
Listar proyectos. Jefe de proyecto Visualizar una lista con las caractersticas de los proyectos creados por Jefe de proyecto. 1. Dentro de Gestin de Proyectos, hacer clic en el link Listar proyectos. Se obtendr una lista de los proyectos de la aplicacin. Listar proyectos adjuntos. Jefe de proyecto Visualizar una lista con las caractersticas de los proyectos a los que ha sido asignado tal Jefe de proyecto. 1. Dentro de Gestin de Proyectos, hacer clic en el link Listar proyectos. Se obtendr una lista de los proyectos de la aplicacin.
Pgina 71 de 219
Aadir proyecto. Jefe de proyecto Crear un nuevo proyecto en la aplicacin. El usuario registrado ser el Jefe de proyecto de dicho proyecto. 1. Dentro de Gestin de Proyectos, hacer clic en el link Listar proyectos. 2. Pulse el enlace Quiero un nuevo proyecto. 3. Rellene los datos correspondientes a ese nuevo proyecto, comprobando previamente la disponibilidad del nombre del nuevo proyecto. 4. Pulsar Aceptar para finalizar la operacin. Modificar proyecto. Jefe de proyecto Modificar los datos de un proyecto. 1. Dentro de Gestin de Proyectos, hacer clic en el link Listar proyectos. 2. Sobre el proyecto a modificar, pulse el botn Editar. Recuerde que solo se podr editar los proyectos creados por dicho Jefe de proyecto. 3. Modifique las caractersticas oportunas del proyecto. 4. Confirmar la accin pulsando Ok. Borrar proyecto. Jefe de proyecto Eliminar un proyecto. 1. Dentro de Gestin de Proyectos, hacer clic en el link Listar proyectos. 2. Sobre el proyecto a borrar, pulse el botn Borrar. Recuerde que solo se podr borrar los proyectos creados por dicho Jefe de proyecto.
Pgina 72 de 219
Asignar Usuario a Proyecto. Jefe de proyecto Asignar/Borrar usuarios a proyectos determinados. 1. Dentro de Gestin de Proyectos, hacer clic en el link Aadir/ Borrar usuario en proyecto. 2. Hacer las elecciones oportunas, eligiendo el usuario y el proyecto a asignarle. Recuerde que solo se pueden asignar/borrar usuarios a proyectos creados por el propio Jefe de proyecto actual. 3. Confirmar la accin pulsando Aadir usuario a proyecto o en su defecto Borrar usuario en proyecto, si lo que desea es eliminar la relacin asignada entre usuario y proyecto.
Figura 22. Diagrama caso de uso Gestionar Proyectos (Usuario)
Listar proyectos adjuntos. Usuario Visualizar una lista con las caractersticas de los proyectos a los que ha sido asignado tal Usuario. 1. Dentro de Gestin de Proyectos, hacer clic en el link Listar proyectos. Se obtendr una lista de los proyectos de la aplicacin.
Pgina 73 de 219
6.4.6 Gestin de carpetas:
Figura 23. Diagrama caso de uso Gestionar Carpeta
Listar carpeta. Usuario Registrado. Permite a un Usuario Registrado visualizar la informacin de las carpetas creadas en la aplicacin. 1. Dentro de Gestin de Carpetas, visualizar la lista de carpetas creadas en el proyecto activo actual. Aadir carpeta. Usuario Registrado. Permite a un Usuario Registrado crear una nueva carpeta de requisitos dentro de su proyecto. 1. Dentro de Gestin de Carpetas, hacer clic en el icono Quiero una nueva carpeta. 2. Rellenar las caractersticas de la nueva carpeta. 3. Pulsar Aceptar.
Pgina 74 de 219
Modificar carpeta. Usuario Registrado. Permite a un Usuario Registrado modificar los datos de una carpeta de requisitos de su proyecto. 1. Dentro de Gestin de Carpetas, se pueden visualizar la relacin de carpetas disponibles. 2. Sobre la carpeta a modificar, pulse el botn Editar. 3. Modifique las caractersticas oportunas de la carpeta. 4. Confirmar la accin pulsando Ok Borrar carpeta. Administrador Permite al Administrador eliminar una carpeta de requisitos de su proyecto. 1. Dentro de Gestin de Carpetas, se pueden visualizar la relacin de carpetas disponibles. 2. Pulsar en el icono Borrar. 3. Confirmar la accin pulsando Aceptar.
Pgina 75 de 219
6.4.7 Gestin de requisitos:
Figura 24. Diagrama caso de uso Gestionar Requisitos
Listar requisitos. Usuario Registrado. Acceder a la lista de requisitos para visualizar toda su informacin. 1. Dentro de Gestin de Requisitos, pulsar el link Listar requisitos. Se obtendr una lista de todos los requisitos de proyecto activo.
Pgina 76 de 219
Realizar bsqueda de requisito. Usuario Registrado. Permite encontrar requisitos especficos en la lista de requisitos. 1. Dentro de Gestin de Requisitos, pulsar el link Listar requisitos. Se obtendr una lista de todos los requisitos de proyecto activo. 2. Elegir el campo de bsqueda en la lista desplegable. 3. Indicar el valor de la bsqueda. 4. Pulsar Filtrar requisitos. Aadir requisito. Usuario Registrado. Crear un nuevo requisito en el catalogo de requisitos de un proyecto determinado. 1. Dentro de Gestin de Requisitos, pulsar el link Listar requisitos. 2. Pulsar el link Quiero un nuevo requisito. 3. En la pantalla que aparece, rellenar como mnimo los campos obligatorios. 4. Rellenar el resto de campos que se desee. 5. Pulsar el botn Aceptar. Modificar requisito. Usuario Registrado. Modificar los datos de un requisitos del catalogo de requisitos. 1. Dentro de Gestin de Requisitos, pulsar el link Listar requisitos. 2. Sobre el requisito a modificar, pulse el botn Editar. 3. Modifique las caractersticas oportunas del requisito. 4. Confirmar la accin pulsando Ok. Borrar requisito. Administrador Eliminar un requisitos del catalogo de requisitos. 1. Dentro de Gestin de Requisitos, pulsar el link Listar requisitos. 2. Sobre el requisito a borrar, pulse el botn Borrar. 3. Confirmar la accin pulsando Aceptar.
Pgina 77 de 219
Aadir/Borrar relacin entre requisitos. Usuario Registrado. Definir una nueva relacin entre dos requisitos del mismo proyecto. 1. Dentro de Gestin de Requisitos, pulse el link Editar relacin entre requisitos. 2. Elija los dos requisitos a relacionar, recuerda que un mismo requisito no se puede relacionar entre s. 3. Marque el tipo de relacin. 4. Pulse el botn Aadir relacin requisitos/Borrar relacin requisitos
Pgina 78 de 219
6.4.8 Gestin de usuarios:
Figura 25. Diagrama caso de uso Gestionar usuarios (Administrador)
Listar usuarios Administrador Acceder a la lista de todos los usuarios dados de alta en la aplicacin. 1. Dentro de Gestin de Usuarios, pulse Ver informacin detallada de usuarios. Se podr visualizar la relacin de usuarios disponibles. Aadir usuario Administrador Crear un nuevo usuario en la aplicacin. 1. Dentro de Gestin de Usuarios, pulse Ver informacin detallada de usuarios. 2. Pulsar el link Quiero un nuevo usuario. 3. En la pantalla que aparece, rellene los datos personales del usuario a dar de alta. Recuerde que el usuario introducido debe ser un usuario vlido para la aplicacin. 4. Pulse el botn Aceptar
Pgina 79 de 219
Modificar usuario Administrador Modificar los datos de un usuario determinado de la aplicacin. 1. Dentro de Gestin de Usuarios, pulse Ver informacin detallado de usuarios. Se podr visualizar la relacin de usuarios disponibles. 2. Seleccione el usuario a modificar y pulse Editar. 3. Modifique los datos personales oportunos. 4. Pulse el botn Aceptar. Borrar usuario Administrador Eliminar un usuario de la aplicacin. 1. Dentro de Gestin de Usuarios, pulse Ver informacin detallado de usuarios. Se podr visualizar la relacin de usuarios disponibles. 2. Seleccione el usuario a eliminar y pulse Borrar. 3. Pulse el botn Aceptar.
Figura 26. Diagrama caso de uso Gestionar usuarios
Listar datos personales Usuario Registrado Listar datos personales del usuario actual. 1. Dentro de Gestin de Usuarios, podr visualizar sus datos personales.
Pgina 80 de 219
Modificar datos personales Usuario Registrado Modificar datos personales del usuario actual. 1. Dentro de Gestin de Usuarios, podr visualizar sus datos personales. 2. Pulsar sobre el link Cambiar datos personales. 3. Modificar los datos oportunos. 4. Pulsar Aceptar, para finalizar la operacin.
Pgina 81 de 219
6.4.9 Gestin de roles:
Figura 27. Diagrama caso de uso Gestionar rol (Administrador)
Listar roles. Administrador. Permite al Administrador de la aplicacin listar los datos de un rol. 1. Dentro de Gestin de Usuarios, pulse Ver informacin detallada de roles. Se visualizar una lista con los usuarios disponibles en la aplicacin junto al tipo de rol asignado. Modificar rol. Administrador. Permite al Administrador de la aplicacin modificar el tipo de rol de un usuario, lo que modificar a su vez sus permisos dentro de la aplicacin. 1. Dentro de Gestin de Usuarios, pulse Ver informacin detallada de roles. 2. Sobre el usuario a modificar, pulse el botn Editar. 3. Modifique el tipo de rol oportuno. 4. Confirmar la accin pulsando Ok.
Escenario bsico:
Pgina 82 de 219
6.4.10 Gestin de Informes de trazabilidad:
Figura 28. Diagrama caso de uso Gestionar Informe de trazabilidad
Visualizar Informe de trazabilidad. Usuario Registrado. Visualizar el informe de trazabilidad creado en el proyecto activo. 1. Dentro de Informe de trazabilidad, lea detenidamente la informacin presente y pulse sobre el link aqu. 2. Si desea ocultar el informe pulse sobre el link Ocultar Informe de Trazabilidad. Imprimir Informe de trazabilidad. Usuario Registrado. Obtener el Informe de trazabilidad en formato papel. Se debe disponer de una impresora conectada y cualquier otro recurso necesario para que esta accin se lleve a cabo. 1. Dentro de Informe de trazabilidad, lea detenidamente la informacin presente y pulse sobre el link aqu. 2. Se visualiza el informe y un link Imprimir, plselo. 3. Siga las instrucciones especficas para imprimir el documento.
Escenario bsico:
Pgina 83 de 219
6.4.11 Gestin de Informes comparativo:
Figura 29. Diagrama caso de uso Gestionar Informe comparativo
Visualizar Informe comparativo. Usuario Registrado. Obtener un listado de los requisitos comunes y no comunes entre dos carpetas a elegir. 1. Dentro de Informe comparativo, elegir dos carpetas, diferentes, de las disponibles en las listas desplegables. Las carpetas pertenecen al proyecto activo actual. 2. Pulse el link aqu para visualizar el informe. 3. Si desea ocultar el informe pulse sobre el link 4. Ocultar Informe Comparativo. Imprimir Informe comparativo. Usuario Registrado. Imprimir el informe comparativo. 1. Dentro de Informe comparativo, elegir dos carpetas, diferentes, de las disponibles en las listas desplegables. Las carpetas pertenecen al proyecto activo actual. 2. Pulse el link aqu para visualizar el informe. 3. Se visualiza el informe y un link Imprimir, plselo. 4. Siga las instrucciones especficas para imprimir el documento.
Pgina 84 de 219
6.4.12 Glosario de trminos:
Figura 30. Diagrama caso de uso Glosario de trminos
Listar trminos. Usuario Registrado. Acceder al glosario de trminos de la aplicacin. 1. Dentro de Glosario de trminos se podr visualizar una lista de los trminos presentes en la aplicacin.
Pgina 85 de 219
Aadir trmino. Usuario Registrado. Aadir un nuevo trmino a la aplicacin. 1. Dentro de Glosario de trminos se podr visualizar una lista de los trminos presentes en la aplicacin. 2. Pulsar el link Quiero un nuevo trmino. 3. Rellenar los datos disponibles, comprobando la disponibilidad del trmino introducido. 4. Pulsar el botn Aceptar para completar la operacin. Modificar trmino. Usuario Registrado. Modificar la definicin de un trmino. 1. Dentro de Glosario de trminos se podr visualizar una lista de los trminos presentes en la aplicacin. 2. Pulsar el icono Editar. 3. Modifique los datos oportunos y pulse Ok. Borrar trmino. Administrador Borrar un trmino de la aplicacin. 1. Dentro de Glosario de trminos se podr visualizar una lista de los trminos presentes en la aplicacin. 2. Pulsar el icono Borrar sobre el trmino a eliminar. 3. Confirme la operacin, pulsando Aceptar.
Pgina 86 de 219
6.4.13 Ayuda
Figura 31. Diagrama caso de uso Ayuda
Consultar ayuda. Usuario Registrado. Acceder a la ayuda de la aplicacin. 1. Dentro de Ayuda se podr visualizar una gua rpida de utilizacin de la aplicacin.
Pgina 87 de 219
6.5 Definicin de requisitos del sistema.

En esta fase se refinar el conjunto de requisitos obtenido en los apartados anteriores, de manera que se definir de una forma ms formal, clara y detallada que debe hacer el producto, es decir, que funcionalidades y restricciones tiene el sistema final. Cada uno de los requisitos descritos dispondr de los siguientes atributos: Identificador: nico para cada requisito. A travs de este identificador se diferenciar a cada requisito de forma univoca y su localizacin dentro de la definicin de requisitos se hace ms sencilla y rpida. Prioridad: Nivel de prioridad de realizacin del requisito respecto a los dems requisitos que existen en el sistema. Los valores definidos en este atributo, en orden de prioridad ascendente, sern: baja, media o alta. Necesidad: Nivel de importante de un requisito en la realizacin de la aplicacin. Los valores definidos en este atributo, en orden de necesidad ascendente, sern: baja, media o alta Existirn, por tanto, requisitos imprescindibles en la aplicacin, que ante ningn evento pueden ser eliminados de la misma y, por otro lado, requisitos opcionales que podran llegar a eliminarse, se as fuera preciso. Estado: Estado actual del requisito. Autor: Origen de cada requisito. Indica la persona que ha propuesto la necesidad de ese requisito. Las valores definidos en este atributo sern: Tutor del proyecto (A.F.M.) Desarrollador del proyecto, es este caso, el alumno (E.S.P.) Requisitos relacionados: Lista de requisitos que tienen algn tipo de relacin con el propio requisito descrito. Descripcin: Texto explicativo que describe el objetivo del requisito de forma clara y adecuada, con el fin de tener una idea ms extendida de la funcionalidad del requisito propuesto.
Pgina 88 de 219
6.5.1 Acceso a la aplicacin: R-001: Acceso a la aplicacin

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: R-002,R-003 Descripcin: Para acceder a la aplicacin es necesario disponer de un identificador de usuario junto con una contrasea. Una vez introducidos en los textbox correspondientes, el sistema proceder a su validacin: o Si los datos son incorrectos, se mostrar un mensaje de error. o Si los datos son correctos, se acceder a la ventana de seleccin de proyectos de la aplicacin. Si es la primera vez que se accede a la aplicacin y, por tanto, no se dispone de ningn dato de acceso, se ha de pulsar el link Soy un nuevo usuario y seguir los pasos que indica el sistema.
R-002: Identificador de usuario registrados

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: Descripcin: Debe ser nico en el sistema, para ello se deber comprobar su disponibilidad en la base de datos. El identificador de usuario ser una palabra compuesta por letras o nmeros nicamente o letras y nmeros. No se mantienen maysculas ni minsculas.
R-003: Contrasea de usuario registrados

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: Descripcin: Las contraseas de los Usuarios Registrados se almacenan de forma segura en la base de datos. La contrasea del usuario ser una palabra compuesta por letras o nmeros nicamente o letras y nmeros. No se mantienen maysculas ni minsculas.
Pgina 89 de 219
R-004: Inicio sesin en proyecto.

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: R-001 Descripcin: Una vez que el Usuario Registrado est validado, se presentar una pantalla donde ha de elegir el proyecto sobre el cual se va a trabajar.
R-005: Ventana de inicio, Proyecto activo (opciones Administrador)

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: R-004 Descripcin: Iniciar sesin en un proyecto. En la parte superior-lateral izquierdo de la pantalla se encuentran varias pestaas que cubren las funcionalidades ms importantes de la aplicacin: Gestin de proyectos, Gestin de carpetas, Gestin de requisitos y Gestin de usuario. Algunas de estas opciones son pestaas desplegables donde se podr encontrar una lista con ms funcionalidades para usuarios con el rol de Administrador. En la parte superior-central se encuentra, adems, varias pestaas sobre la Gestin de los Informes, Glosario de trminos y Ayuda. Desde cualquier pgina se podr visualizar el usuario conectado, los permisos que tiene, la fecha actual y el proyecto activo, adems de cambiar dicho proyecto activo o cerrar sesin.
Pgina 90 de 219
R-006: Ventana de inicio, Proyecto activo (opciones Jefe de proyecto)

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: R-004 Descripcin: Iniciar sesin en un proyecto. En la parte superior-lateral izquierdo de la pantalla se encuentran varias pestaas que cubren las funcionalidades ms importantes de la aplicacin: Gestin de proyectos, Gestin de carpetas, Gestin de requisitos y Gestin de usuario. Algunas de estas opciones son pestaas desplegables donde se podr encontrar una lista con ms funcionalidades para usuarios con el rol de Jefe de proyecto. En la parte superior-central se encuentra, adems, varias pestaas sobre la Gestin de los Informes y Glosario de trminos y Ayuda. Desde cualquier pgina se podr visualizar el usuario conectado, los permisos que tiene, la fecha actual y el proyecto activo, adems de cambiar dicho proyecto activo o cerrar sesin.
R-007: Ventana de inicio, Proyecto activo (opciones Usuario)

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: R-004 Descripcin: Iniciar sesin en un proyecto. En la parte superior-lateral izquierdo de la pantalla se encuentran varias pestaas que cubren las funcionalidades ms importantes de la aplicacin: Gestin de proyectos, Gestin de carpetas, Gestin de requisitos y Gestin de usuario. Algunas de estas opciones son pestaas desplegables donde se podr encontrar una lista con ms funcionalidades para usuarios con permisos de Usuario. En la parte superior-central se encuentra, adems, varias pestaas sobre la Gestin de los Informes, Glosario de trminos y Ayuda. Desde cualquier pgina se podr visualizar el usuario conectado, los permisos que tiene, la fecha actual y el proyecto activo, adems de cambiar dicho proyecto activo o cerrar sesin.
Pgina 91 de 219
6.5.2 Gestin de proyectos: R-008: Listar detalles de un proyecto

Prioridad: Media Estado: Finalizado Necesidad: Media Autor: ESP Requisitos relacionados: Descripcin: Un Usuario Registrado puede consultar los detalles de los proyectos en los que est asignado. Podr consultar detalles como el nombre, el autor, la descripcin y la fecha de creacin.
R-009: Aadir un nuevo proyecto

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: Descripcin: Un Administrador o un Jefe de proyecto tienen la posibilidad de crear un nuevo proyecto en la aplicacin. Un proyecto tiene un nico creador y ste ser el nico Usuario Registrado con permisos para hacer modificaciones o borrar un proyecto, a excepcin del Administrador que tiene permiso para modificar o borrar cualquier proyecto. Desde la pestaa Gestin de Proyectos se puede asignar/borrar los usuarios que trabajan en cada uno de los proyectos.
R-010: Nuevo proyecto. Base de datos

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: R-009 Descripcin: El nuevo proyecto ser almacenado en una base de datos, para poder estar disponible siempre que se quiera trabajar sobre l. Los datos que se guardan de cada proyecto son: Nombre Autor Descripcin Fecha de creacin
R-011: Modificar configuracin de un proyecto

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: Descripcin: Tanto el Jefe de proyecto que crea su proyecto, como el Administrador, tienen la posibilidad de modificar la configuracin de sus proyectos.
Pgina 92 de 219
R-012: Eliminar un proyecto

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: Descripcin: Tanto el Jefe de proyecto que crea su proyecto, como el Administrador, tienen la posibilidad de eliminar sus proyectos.
Pgina 93 de 219
6.5.3 Gestin de carpetas: R-013: Listar carpetas

Prioridad: Media Estado: Finalizado Necesidad: Media Autor: AFM Requisitos relacionados: Descripcin: Un Usuario Registrado puede consultar los detalles de las carpetas pertenecientes a los proyectos donde est asignado. Podr consultar detalles como el nombre, el autor, la descripcin y la fecha de creacin.
R-014: Aadir una nueva carpeta

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: AFM Requisitos relacionados: Descripcin: Cualquier Usuario Registrado tiene la posibilidad de crear una nueva carpeta dentro del proyecto activo actual. Los datos que se guardan de cada carpeta son: Id Nombre Autor Descripcin Fecha de creacin Proyecto al que pertenece El objetivo fundamental de la utilizacin de carpetas es agrupar requisitos con caractersticas similares en un mismo paquete, manteniendo un orden y una jerarqua dentro de la aplicacin.
R-015: Modificar carpeta

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: AFM Requisitos relacionados: Descripcin: Cualquier Usuario Registrado, con permisos para acceder a un proyecto determinado, tiene la posibilidad de modificar los datos de las carpetas contenidas en dicho proyecto.
R-016: Borrar carpeta

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: AFM Requisitos relacionados: Descripcin: nicamente el Administrador tiene la posibilidad de borrar las carpetas pertenecientes al proyecto activo actual.
Pgina 94 de 219
6.5.4 Gestin de requisitos: R-017: Realizar bsquedas de requisito

Prioridad: Media Estado: Finalizado Necesidad: Media Autor: ESP Requisitos relacionados: R-018 Descripcin: La aplicacin permite buscar un determinado requisito. El usuario registrado debe elegir el criterio de bsqueda, de entre los siguientes campos: Carpeta Proceso Nombre Estado y darle valor al atributo elegido.
R-018: Listado de requisitos

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: Descripcin: El Usuario Registrado puede acceder a la informacin de los requisitos de todos los proyectos donde tal usuario est asignado.
R-019: Aadir nuevo requisito

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: Descripcin: Cualquier Usuario Registrado tiene la posibilidad de crear un nuevo requisito dentro de una carpeta determinada.
R-020: Modificado de un requisito

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: SR-018 Descripcin: Dentro de un proyecto, la aplicacin permite modificar el estado de un requisito perteneciente a dicho proyecto.
R-021: Borrado de un requisito

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: SR-018 Descripcin: Dentro de un proyecto, la aplicacin permite eliminar, nicamente al Administrador, cualquier requisito.
Pgina 95 de 219
R-022: Informacin de requisitos

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: R-019 Descripcin: La aplicacin es capaz de aadir un nuevo requisito. De cada requisito se puede almacenar: IdReq TipoReq* IdCarpeta* IdReqXCarpeta* Proceso* rea* Tipo Nombre* Descripcin Nivel de madurez Efectividad Eficacia Calidad Inf Alcance Autor* Fecha de creacin* Estado* Versin* Los campos marcados con * son obligatorios.
R-023: Atributos automticos y no modificables

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: R-022 Descripcin: Hay una serie de atributos que son asignados automticamente por la aplicacin al crear el requisito y por tanto, no son modificables durante la vida de un requisito. Los atributos son: IdReq TipoReq IdReqXCarpeta Autor Fecha de creacin
Pgina 96 de 219
R-024: Identificador de un requisito

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: R-022 Descripcin: La aplicacin asignar de forma automtica el identificador a cada nuevo requisito creado. El identificador de un requisito es un entero y sigue un formato autonumrico.
R-025: Tipo de un requisito

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: R-022 Descripcin: La aplicacin asignar de forma automtica el tipo de requisito que es segn provenga de la lista de requisitos ITIL (tipoReq: ITIL) o sea un requisito especfico creado por la propia organizacin (tipoReq: ORG).
R-026: Identificador de un requisito por carpeta

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: R-022 Descripcin: La aplicacin asignar de forma automtica este identificador a cada nuevo requisito creado. El formato de este requisitos ser: XXXX00-Carpeta XXXX representa el tipo de requisito. Si el requisito proviene de la lista de requisitos ITIL, el tipo ser ITIL. Si por el contario proviene de la lista de requisitos creados por la propia organizacin, el tipo ser ORG. 00 representa el identificador propio del requisito, tomado de las tablas de requisitos ITIL o de requisitos ORG, segn el tipo de requisitos que sea. Carpeta representa la carpeta donde se ha asignado dicho requisitos.
R-027: Autor de un requisito

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: R-022 Descripcin: La aplicacin asignar de forma automtica el autor de cada nuevo requisito propuesto. Este autor ser tomado de la variable sessin (usuario).
Pgina 97 de 219
R-028: Fecha de creacin de un requisito

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: R-022 Descripcin: La aplicacin asignar de forma automtica la fecha de creacin a cada nuevo requisito propuesto. La fecha de creacin de un requisito sigue el siguiente formato: dd/mm/yyyy.
R-029: Estado de un requisito

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: R-022 Descripcin: Los estados posibles de un requisito son: Aprobado Modificado Rechazado Implementado Cancelado Propuesto Por defecto, el estado de un requisito de herramientas ITIL ser Mejor prctica, y cuando se aada a la aplicacin tomar al valor de Propuesto. Por el contrario, los requisitos aadidos por Usuarios Registrados tomaran por defecto el valor de estado Propuesto por usuario registrado.
R-030: rea de un requisito

Prioridad: Alta Estado: Finalizado Necesidad: Media Autor: AFM Requisitos relacionados: R-022 Descripcin: Las reas posibles de un requisito son: Requisitos funcionales Requisitos de integracin Requisitos tcnicos
Pgina 98 de 219
R-031: Tipo de un requisito

Prioridad: Alta Estado: Finalizado Necesidad: Media Autor: AFM Requisitos relacionados: R-022 Descripcin: Los tipos posibles de un requisito son: Infraestructura Accesibilidad/ Administracin Conectores Otras integraciones Generales Procesos Integracin
R-032: Nivel de madurez de un requisito

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: AFM Requisitos relacionados: R-022 Descripcin: Los niveles de madurez posibles de un requisito son: 1 (Inicial) 2 (Repetible) 3 (Definido) 4 (Gestionado) 5 (Optimizado)
R-033: Efectividad de un requisito

Prioridad: Alta Estado: Finalizado Necesidad: Media Autor: AFM Requisitos relacionados: R-022 Descripcin: La efectividad posible de un requisito es:
S P
R-034: Eficacia de un requisito

Prioridad: Alta Estado: Finalizado Necesidad: Media Autor: AFM Requisitos relacionados: R-022 Descripcin: La eficacia posible de un requisito es: S P
Pgina 99 de 219
R-035: Calidad Informacin de un requisito

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: AFM Requisitos relacionados: R-022 Descripcin: La calidad de informacin posible de un requisito es: S P
R-036: Alcance de un requisito

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: AFM Requisitos relacionados: R-022 Descripcin: La alcance posible de un requisito es: Alto Medio Bajo
R-037: Historial de un requisito

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: AFM Requisitos relacionados: R-019, R-020, R-021 Descripcin: Se guardaran todas las acciones que se hacen sobre un requisito. Los valores que se almacenaran cada vez que se produzca una entrada en el historial sern: Id Nombre Fecha de la accin Autor de la accin Descripcin {Creacin de un requisito, modificacin de un requisito, etc. }
R-038: Valor de un atributo

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: R-022 Descripcin: El valor de un atributo de un requisito vara segn el atributo. Puede ser un texto libre como ocurre con el Nombre o la Descripcin, un formato especfico como la Fecha de creacin o una lista desplegable como ocurre con el Estado o el Nivel de Madurez, entre otros.
Pgina 100 de 219
R-039: Relacin de requisitos

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: AFM Requisitos relacionados: Descripcin: La aplicacin permite crear una relacin entre los requisitos. Para ello se han de buscar los requisitos a relacionar, teniendo en cuenta que un requisito no se puede relacionar consigo mismo. Adems, es imprescindible elegir el tipo de relacin de entre las siguientes opciones: Depende de Hace referencia a Es padre de
Pgina 101 de 219
6.5.5 Gestin de usuarios: R-040: Informacin asociada a un nuevo usuario registrado

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: Descripcin: Cada Usuario Registrado del sistema tendr un informacin personal asociada a los siguientes campos: Nombre Apellido1 Apellido2 Email Usuario Contrasea Rol/es asignados. Si desea formar parte de la aplicacin como Usuario solo tiene que acceder al formulario realizado para dicho fin. Si, por el contrario, quiere formar parte del aplicativo pero como Jefe de proyecto tiene que ponerse en contacto con el Administrador de la aplicacin.
R-041: Listado de usuarios registrados

Prioridad: Media Estado: Finalizado Necesidad: Media Autor: ESP Requisitos relacionados: R-040 Descripcin: El Administrador puede acceder a la informacin de todos los Usuarios Registrados de la aplicacin.
R-042: Modificacin de datos de usuario registrado

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: Descripcin: El Usuario Registrado tiene permitido modificar sus propios datos personales. Adems, si el Usuario Registrado tiene rol de Administrador podr modificar los datos personales de cualquier usuario.
R-043: Borrado de usuario registrado

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: Descripcin: El Administrador puede borrar usuarios de la aplicacin.
Pgina 102 de 219
6.5.6 Gestin de roles: R-044: Roles

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: Descripcin: Existen tres tipos de roles con los que trabajar en la aplicacin: Administrador Jefe de proyecto Usuario Segn el rol con el que se acceda a la aplicacin, se podrn desempean unas funciones u otras. El Administrador de la aplicacin ser el Usuario Registrado que pueda acceder al total de las funcionalidades de la aplicacin.
R-045: Rol de Administrador

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: R-044 Descripcin: Es el nico que puede modificar cualquier rol de Usuario Registrado. Tiene acceso sin lmite a todas las funcionalidades de la aplicacin.
R-046: Rol de Jefe de proyecto

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: R-044 Descripcin: Tiene acceso restringido a algunas funcionalidades de la aplicacin. Ser jefe de varios proyectos y por tanto tiene abierto el acceso a la informacin sobre sus propios proyectos.
R-047: Rol de Usuario

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: R-044 Descripcin: Es rol que menos privilegios tiene. Un Usuario Registrado con rol de Usuario podr acceder solamente a la informacin de los proyectos a los que ha sido asignado.
Pgina 103 de 219
6.5.7 Obtencin de informes: R-048: Informe de trazabilidad

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: AFM Requisitos relacionados: Descripcin: La aplicacin ofrece la posibilidad de crear informes de trazabilidad con el fin de visualizar en texto plano la relacin que guardan los diferentes requisitos de un proyecto determinado. La informacin de los requisitos se encuentra ordenada y es fcil de leer.
R-049: Informe comparativo

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: AFM Requisitos relacionados: Descripcin: La aplicacin ofrece la posibilidad de crear informes comparativos. Este tipo de informes tiene como objetivo fundamental comparar los requisitos incorporados a dos carpetas diferentes, de manera que, el texto plano represente una relacin de los requisitos comunes y no comunes de ambas carpetas. La informacin de los requisitos se encuentra ordenada y es fcil de leer.
R-050: Impresin de informes

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: AFM Requisitos relacionados: R-048,R-049 Descripcin: Tanto el Informe de trazabilidad como el Informe comparativo tienen la funcionalidad de ser impresos.
Pgina 104 de 219
6.5.8 Glosario de trminos: R-051: Aadir un nuevo trmino al glosario

Prioridad: Baja Estado: Finalizado Necesidad: Baja Autor: ESP Requisitos relacionados: Descripcin: Es posible que se tenga la necesidad de aadir un trmino al glosario para aclarar el significado del mismo y no quede ambiguo dentro de la aplicacin. Los valores a rellenar por cada trmino introducido son: Trmino Definicin Autor Aparte cada trmino tendr un identificar nico, creado automticamente.
R-052: Modificar un trmino del glosario

Prioridad: Baja Estado: Finalizado Necesidad: Baja Autor: ESP Requisitos relacionados: Descripcin: Se puede modificar cualquier trmino del glosario.
R-053: Eliminar un trmino del glosario

Prioridad: Baja Estado: Finalizado Necesidad: Baja Autor: ESP Requisitos relacionados: Descripcin: El Administracin de la aplicacin ser el nico Usuario Registrado con permisos para eliminar cualquier trmino del glosario.
Pgina 105 de 219
6.5.9 Ayuda: R-054: Consultar ayuda

Prioridad: Media Estado: Finalizado Necesidad: Media Autor: ESP Requisitos relacionados: Descripcin: Existe una gua rpida de usuario donde se pueden encontrar todas las funcionalidades que cubre la aplicacin. Esta gua est accesible desde cualquier pgina del aplicativo.
6.5.10 Requisitos de funcionamiento: R-055: Mensajes de error

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: Descripcin: Se mostrar un mensaje de error en el caso de que algn atributo obligatorio no sea rellenado.
R-056: Mensajes de error

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: Descripcin: Se mostrar un mensaje de error en el caso de que algn atributo sea rellenado incorrectamente.
R-057: Mensajes de error

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: Descripcin: Se mostrar un mensaje de error en el caso de que el nombre de usuario, proyecto, carpeta, requisito o termino a aadir en el glosario ya exista en la base de datos. Se quiere evitar las ambigedades.
Pgina 106 de 219
6.5.11 Requisitos de Interfaz: R-058: Hora del sistema

Prioridad: Baja Estado: Finalizado Necesidad: Baja Autor: ESP Requisitos relacionados: Descripcin: La aplicacin mostrar en todo momento la fecha del sistema.
R-059: Idioma de la aplicacin

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: Descripcin: El idioma de la aplicacin ser el castellano.
R-060: Lenguaje de programacin

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: Descripcin: La aplicacin ser desarrollado utilizando una tecnologa Microsoft .Net, lenguaje ASP.NET
R-061: Software de la aplicacin

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: Descripcin: Se utilizar la herramienta Visual Web Devoloper.
R-062: Base de datos de la aplicacin

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: Descripcin: La aplicacin trabaja con una base de datos SQL. La estructura que tiene la base de datos estar compuesta de tablas y columnas, introducidas mediante un script. Para acceder a la base de datos se utiliza el lenguaje T-SQL. Como base de datos se utilizar SQL Server Express.
Pgina 107 de 219
R-063: Manejo de la interfaz

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: Descripcin: La interfaz de usuario ser amigable, fcil de usar, agradable a la vista e intuitiva. El usuario interacta con la aplicacin mediante el teclado y el ratn.
R-064: Resolucin de pantalla

Prioridad: Media Estado: Finalizado Necesidad: Media Autor: ESP Requisitos relacionados: Descripcin: La pantalla tendr una resolucin de 1024 x 768.
R-065: Tipo de fuente

Prioridad: Baja Estado: Finalizado Necesidad: Baja Autor: ESP Requisitos relacionados: Descripcin: El tipo de fuente principal utilizado en la aplicacin ser Arial, estilo normal y tamao 12. Habr excepciones donde se tomar otro tipo de fuente por hacer la aplicacin ms atractiva.
R-066: Lenguaje formal

Prioridad: Alta Estado: Finalizado Necesidad: Alta Autor: ESP Requisitos relacionados: Descripcin: Se utilizar un lenguaje serio y formal, dando una buena imagen a la aplicacin.
Pgina 108 de 219
7. Diseo
7.1 Diseo arquitectnico
7.1.1 Definicin de la arquitectura del sistema Este apartado referencia al diseo arquitectnico del sistema, y en l se va a explicar detalladamente el modelo de diseo seguido, los componentes que interviene en l y las razones de dicha eleccin, de manera clara y sencilla. El modelo elegido para la realizacin del diseo arquitectnico de la aplicacin ha sido el Modelo-Vista-Controlador (MVC) o tambin llamado Modelo de arquitectura de tres capas. Como su propio nombre indica, se divide en tres partes claramente diferenciadas: un modelo (los datos de la aplicacin), una vista (la interfaz de usuario) y un controlador (la lgica de control). La capa Modelo Contiene el componente encargado de todos los accesos a las bases de datos. Este componente tiene como objetivo primordial realizar las consultas, inserciones, borrados o modificados que sean precisas. Para realizar estas operaciones se har uso de ADO .NET que proporcionar una flexibilidad en el intercambio de los datos, asegurando su integridad de forma sencilla, modular y gil. Nuestra aplicacin dispondr de una base de datos para almacenar toda la informacin referente a cada proyecto, junto con todos los usuarios que hacen uso de la aplicacin, por tanto, es primordial el uso de esta capa Modelo. El gestor de la base de datos elegido es Microsoft SQL Server. La capa Vista Es la encargada de exponer la informacin, es decir, muestra la parte del diseo al usuario. Adems, queda responsable de recoger todas las acciones provenientes del usuario, desde recopilar toda la informacin plasmada en los formularios hasta recogida de todos y cada uno de los eventos. En todo momento conoce el estado actual del sistema, representado por el modelo.
Pgina 109 de 219
Mediante ASP.NET se va a implementar la capa Vista de este modelo, de manera que esta capa contiene todas las pginas .aspx adjuntas a cada pgina. La capa Controlador: Se encarga de recibir las peticiones de usuario en forma de eventos, transformar estos datos en caso de ser necesario, determinar qu elemento va a ser el encargado de procesar dicho evento y enviar estos datos a la vista correspondiente. Adems, como bien sabemos, es importante llevar a cabo un buen el manejo de errores, por tanto el controlador se encargar tambin de la gestin de la seguridad. ASP.NET ofrece un Code-Behind, mecanismo que permite separar la interfaz de usuario de la lgica de la aplicacin. De esta forma el cdigo fuente puede residir en un fichero separado.
Figura 32. Integracin entre los componentes del Modelo de arquitectura de tres capas
Pgina 110 de 219
La ventaja que ofrece este modelo se centra fundamentalmente en la facilidad de realizar cambios en la aplicacin. Cuando se realiza un cambio en la base de datos, en la parte de programacin o en la interfaz de usuario, solo accedemos a la capa correspondiente, trabajando nicamente sobre el componente a modificar y dejando, por tanto, intactos a los dems. Adems, esta separacin hace que no sea necesario conocer cmo funciona cada parte, es decir, modificar la capa Modelo requiere una persona con conocimientos de bases de datos pero, puesto que la parte de interfaz de usuario no le incumbe, no se requiere que conozca cmo se trabaja con asp.net o cualquier otro lenguaje para construir aplicaciones Web. 7.1.2 Diagrama de secuencia Para que quede complemente claro cmo funciona el Modelo de arquitectura de tres capas explicado anteriormente, a continuacin se va a mostrar un diagrama de secuencia muy simple que resume la interaccin entre las tres capas de dicho modelo:
Figura 33. Diagrama de secuencia del Modelo de arquitectura de tres capas
Pgina 111 de 219
7.2 Diagramas de actividad

7.2.1 Iniciar sesin en proyecto:
Figura 34. Diagrama de actividad Iniciar sesin en proyecto
Pgina 112 de 219
7.2.2 Aadir proyecto:
Figura 35. Diagrama de actividad Aadir proyecto
Pgina 113 de 219
7.2.3 Modificar proyecto:
Figura 36. Diagrama de actividad Modificar proyecto
Pgina 114 de 219
7.2.4 Borrar proyecto:
Figura 37. Diagrama de actividad Borrar proyecto
Pgina 115 de 219
7.2.5 Asignar/Borrar usuario en proyecto:
Figura 38. Diagrama de actividad Asignar/Borrar usuario en proyecto
Pgina 116 de 219
7.2.6 Aadir carpeta:
Figura 39. Diagrama de actividad Aadir carpeta
Pgina 117 de 219
7.2.7 Modificar carpeta:
Figura 40. Diagrama de actividad Modificar carpeta
Pgina 118 de 219
7.2.8 Borrar carpeta:
Figura 41. Diagrama de actividad Borrar carpeta
Pgina 119 de 219
7.2.9 Incorporar requisitos a carpeta:
Figura 42. Diagrama de actividad Incorporar requisitos a carpeta
Pgina 120 de 219
7.2.10 Realizar bsqueda de requisito:
Figura 43. Diagrama de actividad Realizar bsqueda de requisito
Pgina 121 de 219
7.2.11 Aadir requisito:
Figura 44. Diagrama de actividad Aadir requisito
Pgina 122 de 219
7.2.12 Modificar requisito:
Figura 45. Diagrama de actividad Modificar requisito
Pgina 123 de 219
7.2.13 Borrar requisito:
Figura 46. Diagrama de actividad Borrar requisito
Pgina 124 de 219
7.2.14 Aadir/Borrar relacin entre requisitos:
Figura 47. Diagrama de actividad Aadir/Borrar relacin entre requisitos
Pgina 125 de 219
7.2.15 Modificar datos personales:
Figura 48. Diagrama de actividad Modificar datos personales
Pgina 126 de 219
7.2.16 Aadir usuario:
Figura 49. Diagrama de actividad Modificar usuario
Pgina 127 de 219
7.2.17 Modificar usuario:
Figura 50. Diagrama de actividad Modificar usuario
Pgina 128 de 219
7.2.18 Borrar usuario:
Figura 51. Diagrama de actividad Borrar usuario
Pgina 129 de 219
7.2.19 Modificar rol
Figura 52. Diagrama de actividad Modificar rol
Pgina 130 de 219
7.2.20 Visualizar Informe de trazabilidad
Figura 53. Diagrama de actividad Visualizar informe de trazabilidad
Pgina 131 de 219
7.2.21 Visualizar Informe comparativo
Figura 54. Diagrama de actividad Visualizar informe comparativo
Pgina 132 de 219
7.2.22 Aadir un trmino en glosario:
Figura 55. Diagrama de actividad Aadir un trmino en glosario
Pgina 133 de 219
7.2.23 Modificar un trmino en glosario:
Figura 56. Diagrama de actividad Modificar un trmino en glosario
Pgina 134 de 219
7.2.24 Borrar un trmino en glosario:
Figura 57. Diagrama de actividad Borrar un trmino en glosario
Pgina 135 de 219
7.2.25 Consultar ayuda:
Figura 58. Diagrama de actividad Consultar ayuda
Pgina 136 de 219
7.3 Modelo conceptual

A continuacin se presenta el modelo conceptual dividido en varios diagramas, con el fin de mejorar su legibilidad. Se adjunta adems una pequea descripcin de cada uno de las clases para que la lectura de los diagramas sea clara y precisa. 7.3.1 Diagrama conceptual 1
Figura 59. Diagrama conceptual 1
Pgina 137 de 219
Diagrama conceptual 1
Clase PROYECTO Descripcin Representa un proyecto definido en la aplicacin. Se encarga de almacenar toda la informacin acerca del mismo. Representa una sesin iniciada en la aplicacin sobre un proyecto en concreto. Almacena la fechas de entrada y salida, el usuario registrado que realizada la accin y el proyecto activo para dicha sesin. Representa un usuario definido en la aplicacin. Almacena los datos personales del propio usuario registrado, junto con el nombre de usuario y contrasea del mismo. Representa un rol definido en la aplicacin. El rol que tendr un usuario dentro de un proyecto puede ser de varios tipos: ADMINISTRADOR, JEFE DE PROYECTO O USUARIO, y de ello depender los permisos dentro de la aplicacin.
SESIN
USUARIO
ROL
Pgina 138 de 219
7.3.2 Diagrama conceptual 2
Pgina 139 de 219
Clase PROYECTO Descripcin Representa un proyecto definido en la aplicacin. Se encarga de almacenar toda la informacin acerca del mismo. Representa una carpeta definida dentro de un proyecto. Se encarga de almacenar toda la informacin acerca de la misma. Una carpeta pertenece a un nico proyecto. Representa un requisito definido en la aplicacin. Se encarga de almacenar toda la informacin acerca del requisito. Existen requisitos ITIL que sern los requisitos de las herramientas ITIL, que ya vienen incorporados en la base de datos. Adems, cabe la posibilidad de crear requisitos aparte de los proporcionados por ITIL, estos sern los requisitos de la propia organizacin. Representa el historial de un requisito, es decir, va a formar el almacn donde se guarde toda la informacin referente a los cambios producidos en cada requisito.
CARPETA
REQUISITO
HISTORIAL
Pgina 140 de 219
7.3.3 Diagrama conceptual 3
Clase INFORME Descripcin Representa un informe creado en la aplicacin. Un informe se crea a partir de los datos de los requisitos. Los informes consistirn en documentos de texto que reflejaran la informacin deseada. Pueden ser INFORMES DE TRAZABILIDAD o INFORMES COMPARATIVOS. Representa los trminos definidos en la aplicacin. Se encarga de almacenar toda la informacin acerca del mismo.
GLOSARIO
Pgina 141 de 219
7.4 Diseo de la base de datos
Pgina 142 de 219
7.5 . Diagrama de estados:

A continuacin vamos a representar el estado de los requisitos dentro de la aplicacin.
Figura 63. Diagrama de estados (Estados de requisitos)
Pgina 143 de 219
8. Anlisis econmico
8.1 Consideraciones inciales:
Se deben establecer los lmites de la aplicacin para poder llevar a cabo una correcta estimacin. Adems, se debe conocer cules son los datos que se obtienen de otros sistemas y cuales tienen que ser mantenidos por la propia aplicacin. Almacenes pertenecientes a la aplicacin: Los datos correspondientes a los proyectos, carpetas y requisitos incorporados en cada carpeta, las relaciones que mantienen los mismos y los usuarios que hacen uso de la aplicacin. Tambin pertenecern a esta clasificacin los almacenes que soportan las funcionalidades extras de la aplicacin como el glosario. Almacenes no pertenecientes a la aplicacin: Toda la informacin perteneciente a las organizaciones ser gestionada por cada entidad y tampoco tiene una importancia fundamental en el sistema. Por lo tanto, de estos almacenes simplemente se utilizar su informacin para determinados procesos sin tener que preocuparse de su mantenimiento. Cada empresa se encargar de controlar sus datos.
8.2 Clculo de puntos de funcin de Albretch:

A continuacin se van a hacer las operaciones necesarias para estimar el tamao de la aplicacin. Se justificarn todas las decisiones en la obtencin de los puntos de funcin sin ajustar y posteriormente en los puntos de funcin ajustados. Se va a tener en cuenta tanto las consideraciones mencionadas anteriormente como el diseo tcnico realizado. De esta forma se van a clasificar todos los almacenes y flujos del sistema segn los criterios que define el mtodo Albretch y se va a calcular la complejidad de cada almacn y flujo. 8.2.1 ILF (FICHEROS LOGICOS INTERNOS) Los almacenes correspondientes a este apartado se han seleccionado porque el usuario de la aplicacin los mantiene, y son gestionados dentro de los lmites de la aplicacin. Adems, es un grupo de datos lgico e identificable por el usuario y que ste lo mantiene o modifica mediante procesos elementales del sistema. Con respecto a los RET, se ha elegido este tipo de clasificacin en base a agrupar los campos del almacn que tuviesen una semntica comn. A continuacin se enumeran los DET, RET y la complejidad de cada almacn:
Pgina 144 de 219
DET IdProy NombreProy AutorProy DescripcinProy FechaDeCreacin Total DET: 5
tProyectos RET
Tipo
Complejidad
RetDefectoP
ILF
Baja
Total RET: 1 tCarpetas RET
DET IdCarpeta NombreCarpeta AutorCarpeta DescripcinCarpeta FechaDeCreacin IdProyecto Total DET: 6
Tipo
Complejidad
RetDefectoC ILF DatosProyecto Total RET: 2 tRequisitos RET RetDefectoR Datos clasificacin del requisito Baja
DET IdReq IdReqXCarpeta tipoReq NombreCarpeta Proceso Area Tipo Nombre Descripcin NivelMadurez Efectividad Eficacia CalidadInf Alcance Autor Estado Versin Total DET: 17
Tipo
Complejidad
ILF
Baja
RetDefectoR
Total RET: 2
Pgina 145 de 219
DET IdReq TipoReq NombreCarpeta Proceso Area Tipo Nombre Descripcin NivelMadurez Efectividad Eficacia CalidadInf Alcance Autor Estado Versin Total DET: 16
tRequisitosORG RET Tipo RetDefectoRORG Datos clasificacin del requisito
Complejidad
ILF RetDefectoRORG
Baja
Total RET: 2 tHistorial RET
DET IdHistorial IdRequisito Nombre FechaDeAccin AutorDeAccin Descripcin Total DET: 6
Tipo
Complejidad
RetDefectoH
ILF
Baja
Total RET: 1 TRequisitosRelacionados RET Tipo
DET IdRelacin IdRequisito1 IdRequisito2 TipoDeRelacin FechaDeRelacin Total DET: 5
Complejidad
RetDefectoRR
ILF
Baja
Total RET: 1
Pgina 146 de 219
DET Usuario Contrasea TipoDeRol Nombre Apellido1 Apellido2 Email Total DET: 7
TUsuario RET Datos validacin RetDefectoU
Tipo
Complejidad
ILF
Baja
Total RET: 2 TUsuarioEnProyecto RET Tipo RetDefectoUP Total RET: 1 tGlosario RET RetDefectoG Total RET: 1
DET
IdUsuarioEnProyecto
Complejidad
IdUsuario IdProyecto FechaDeAsignacin Total DET: 4
ILF
Baja
DET IdTrmino Trmino Definicin AutorTermino Total DET: 4
Tipo
Complejidad
ILF
Baja
8.2.2 EIF (FICHEROS DE INTERFAZ EXTERNA) Los almacenes pertenecientes a este apartado son mantenidos fuera de los lmites de la aplicacin y son ficheros a los cuales se referencian desde nuestro sistema, es decir, slo se toman datos de ellos, no los mantiene la aplicacin. Estos almacenes estn formados por un grupo de datos lgico identificables por el usuario. Tambin se considera que el grupo de datos que lo componen se cuenta como un Fichero Lgico Interno por, al menos, otra aplicacin, en este caso, por el sistema del que cuente cada entidad. Los RET se han elegido en base a agrupar los campos del almacn que tuviesen una semntica comn. A continuacin se detalla el nico almacn que cumplen con estas caractersticas:
Pgina 147 de 219
DET IdReq TipoReq NombreCarpeta Proceso Area Tipo Nombre Descripcin NivelMadurez Efectividad Eficacia CalidadInf Alcance Autor Estado Versin Total DET: 16
TRequisitosITIL RET Tipo RetDefectoRITIL Datos de clasificacin del requisito
Complejidad
EIF RetDefectoRITIL
Baja
Total RET: 2
8.2.3 EI (ENTRADAS EXTERNAS) Todos los flujos enumerados como entradas externas es porque mantienen un fichero lgico interno a travs de un proceso elemental de la aplicacin. Los datos se reciben desde fuera de los lmites de la aplicacin, ya que los va a insertar el usuario. Adems se observa que el proceso es autocontenido y deja la aplicacin en un estado consistente. El nmero de FTR viene dado por el nmero de almacenes sobre los que incide este flujo. A continuacin se detallan todas las entradas externas: Aadir proyecto Entrada Salida IdProy NombreProy AutorProy DescripcinProy FechaDeCreacin Ok/CodigoError Total:6 Total: 0 TProyectos Total: 1 Total: 0 On-line Funcin/es Complejidad/es
DET
EI
Baja
FTR
Pgina 148 de 219
DET
FTR
Modificar proyecto Entrada Salida IdProy NombreProy DescripcinProy Ok/CodigoError Total:4 Total: 0 tProyectos Total: 1 Total: 0 Borrar proyecto Entrada Salida IdProy Ok/CodigoError Total:2 Total: 0 tProyectos Total: 1 Total: 0 Asignar usuario a proyecto Entrada Salida IdUsuario IdProyecto Ok/CodigoError Total:3 Total: 0
tUsuarioEnProyecto
Funcin/es
On-line Complejidad/es
EI
Baja
On-line Funcin/es Complejidad/es
DET
EI
Baja
FTR
Funcin/es
DET
EI
Baja
FTR
Total: 1
Total: 0 On-line Complejidad/es
DET
FTR
Aadir carpeta Entrada Salida IdCarpeta NombreCarpeta AutorCarpeta DescripcinCarpeta FechaDeCreacin IdProyecto Ok/CodigoError Total:7 Total: 0 tCarpetas Total: 1 Total: 0
Funcin/es
EI
Baja
Pgina 149 de 219
DET
FTR
Modificar carpeta Entrada Salida IdCarpeta NombreCarpeta DescripcinCarpeta Ok/CodigoError Total:4 Total: 0 tCarpetas Total: 1 Total: 0 Borrar carpeta Entrada Salida IdCarpeta Ok/CodigoError Total:2 Total: 0 tCarpetas Total: 1 Total: 0 Aadir requisito Entrada Salida IdReq TipoReq IdReqXCarpeta NombreCarpeta Proceso rea Tipo Nombre Descripcin NivelMadurez Efectividad Eficacia CalidadInf Alcance Autor Estado Versin Ok/CodigoError Total:18 Total: 0 tRequisitos Total: 1 Total: 0
Funcin/es
EI
Baja
DET
EI
Baja
FTR
DET
EI
Media
FTR
Pgina 150 de 219
DET
FTR
Modificar requisito Entrada Salida IdReq Nombre Estado Versin Ok/CodigoError Total: 5 Total: 0 TRequisitos Total: 1 Total: 0 Borrar requisito Entrada Salida IdReq Ok/CodigoError Total: 2 Total: 0 TRequisitos Total: 1 Total: 0 Incorporar requisito a carpeta Entrada Salida IdReq TipoReq NombreCarpeta IdReqXCarpeta Ok/CodigoError Total: 5 Total: 0
tRequisitos
Funcin/es
EI
Baja
DET
EI
Baja
FTR
Funcin/es
DET
EI
Baja
FTR
Total: 1
Total: 0 On-line Complejidad/es
DET
Aadir relacin entre requisitos Entrada Salida IdRelacin IdRequisito1 IdRequisito2 TipoDeRelacin FechaDeRelacion Ok/CodigoError Total: 6 Total: 0
tRequisitosRelacionados
Funcin/es
EI
Baja
FTR
Total: 1
Total: 0
Pgina 151 de 219
DET
Borrar relacin entre requisitos Entrada Salida IdRelacin Ok/CodigoError Total: 2 Total: 0
tRequisitosRelacionados
Funcin/es
EI
Baja
FTR
Total: 1
Total: 0 On-line Funcin/es Complejidad/es
DET
FTR
Aadir Usuario Entrada Salida Usuario Contrasea TipoDeRol Nombre Apellido1 Apellido2 Email Ok/CodigoError Total: 8 Total: 0 tUsuarios Total: 1 Total: 0 Modificar Usuario Entrada Salida Usuario Contrasea Nombre Apellido1 Apellido2 Email Ok/CodigoError Total: 7 Total: 0 tUsuarios Total: 1 Total: 0
EI
Baja
Funcin/es
DET
EI
Baja
FTR
Pgina 152 de 219
DET
FTR
Borrar Usuario Entrada Salida Usuario Ok/CodigoError Total: 2 Total: 0 tUsuarios Total: 1 Total: 0 Modificar datos personales Entrada Salida Contrasea Nombre Apellido1 Apellido2 Email Ok/CodigoError Total: 6 Total: 0 tUsuarios Total: 1 Total: 0 Modificar rol Entrada Salida Usuario TipoDeRol Ok/CodigoError Total:3 Total: 0 tRoles Total: 1 Total: 0 Aadir trmino en glosario Entrada Salida IdTrmino Trmino Definicin AutorTrmino Ok/CodigoError Total: 5 Total: 0
tGlosario
Funcin/es
EI
Baja
DET
EI
Baja
FTR
Funcin/es
DET
EI
Baja
FTR
DET
EI
Baja
FTR
Total: 1
Total: 0
Pgina 153 de 219
DET
FTR
Modificar trmino en glosario Entrada Salida IdTrmino Trmino Definicin Ok/CodigoError Total: 4 Total: 0 TGlosario Total: 1 Total: 0 Borrar trmino en glosario Entrada Salida IdTrmino Ok/CodigoError Total: 2 Total: 0 TGlosario Total: 1 Total: 0
Funcin/es
EI
Baja
DET
EI
Baja
FTR
8.2.4 EO (SALIDAS EXTERNAS) Se han considerado estos flujos como salidas externas ya que no mantienen ningn fichero lgico interno a travs de un proceso elemental, sino que a travs de dicho proceso se envan datos o informacin de control. Adems, el proceso es autocontenido y deja la aplicacin en un estado consistente. Este flujo no se ha considerado consulta porque se realizan clculos con la informacin obtenida de los almacenes, de forma que aparecen datos derivados. El nmero de FTR viene dado por el nmero de almacenes sobre los que incide este flujo. A continuacin se detallan todas las salidas externas:
Pgina 154 de 219
DET
FTR
Listar de requisitos ITIL Entrada Salida IdReq TipoReq NombreCarpeta Proceso Area Tipo Nombre Descripcin NivelMadurez Efectividad Eficacia CalidadInf Alcance Autor Estado Versin Total: 0 Total: 16 TRequisitos Total: 1 Total: 0 Listar usuarios Entrada Salida Usuario Contrasea Nombre Apellido1 Apellido2 Email Total: 0 Total: 6 tUsuarios Total: 1 Total: 0 Listar trminos Entrada Salida Trmino Definicin AutorDelTrmino Total: 0 Total: 3 TGlosario Total: 1 Total: 0
Funcin/es
EO
Baja
DET
EO
Baja
FTR
DET
EO
Baja
FTR
Pgina 155 de 219
8.2.5 EQ (CONSULTAS EXTERNAS) Los siguientes flujos son consultas externas ya que no modifican ningn fichero lgico interno, no contiene datos derivados y son bsqueda de datos: Iniciar sesin usuario Registrado Entrada Salida Usuario Usuario Contrasea Contrasea TipoDeRol TipoDeRol Ok/CodigoError Total: 3 Total: 4 tUsuarios Total: 1 Total: 0 On-line Funcin/es Complejidad/es EQ(Entrada) Baja
DET
EQ(Salida)
Baja
FTR
DET
FTR
Iniciar sesin usuario No Registrado On-line Entrada Salida Funcin/es Complejidad/es Usuario Usuario Contrasea Contrasea EQ(Entrada) Baja TipoDeRol TipoDeRol Nombre Ok/CodigoError Apellido1 Apellido2 Email EQ(Salida) Baja Total: 7 Total: 4 tUsuarios Total: 1 Total: 0 Listar proyectos Entrada Salida Usuario NombreProy TipoDeRol AutorProy DescripcionProy FechaDeCreacin Total: 2 Total: 4
tProyectos
Funcin/es EQ(Entrada)
On-line Complejidad/es Baja
DET
FTR
EQ(Salida) Total: 0
Baja
Total: 1
Pgina 156 de 219
DET
Listar proyectos adjuntos Entrada Salida Usuario NombreProy TipoDeRol AutorProy DescripcionProy FechaDeCreacin Total: 2 Total: 4
TProyectos
EQ(Salida)
Baja
FTR
Total: 1
Total: 0 On-line Funcin/es Complejidad/es EQ(Entrada) Baja
DET
Listar usuarios en proyectos Entrada Salida Usuario IdUsuario TipoDeRol IdProyecto FechaDeAsignacin Total: 2 Total: 3
TRequisitos
FTR
EQ(Salida) Total: 0
Baja
Total: 1
DET
FTR
Listar carpetas Entrada Salida IdProyecto NombreCarpeta AutorCarpeta DescripcinCarpeta FechaDeCreacin IdProyecto Total: 1 Total: 5 TCarpetas Total: 1 Total: 0
On-line Funcin/es Complejidad/es EQ(Entrada) Baja
EQ(Salida)
Baja
Pgina 157 de 219
DET
FTR
Realizar bsqueda de requisitos Entrada Salida CampoDeBusqueda IdReqXCarpeta ValorDeBusqueda NombreCarpeta Proceso rea Tipo Nombre Descripcin NivelMadurez Efectividad Eficacia CalidadInf Alcance Autor Estado Versin Total: 2 Total: 15 tRequisitos Total: 1 Total: 0 Listar requisitos Entrada Salida IdProyecto IdReqXCarpeta Proceso Nombre Descripcin Estado Total: 1 Total: 5 tRequisitos Total: 1 Total: 0 Listar datos personales Entrada Salida Usuario Usuario Contrasea Nombre Apellido1 Apellido2 Email Total: 1 Total: 6 tUsuarios Total: 1 Total: 0
Pgina 158 de 219
Funcin/es
EQ(Entrada)
Baja
EQ(Salida)
Baja
DET
EQ(Entrada)
Baja
FTR
EQ(Salida)
Baja
DET
EQ(Salida)
Baja
FTR
Visualizar informe trazabilidad On-line Entrada Salida Funcin/es Complejidad/es IdProyecto IdRelacion IdRequisito1 EQ(Entrada) Baja DET IdRequisito2 TipDeRelacin EQ(Salida) Baja Total: 1 Total: 4 tRequisitosRelacionados FTR Total: 1 Total: 0 Visualiza informe comparativo Entrada Salida NombreCarpeta1 IdReqXCarpeta NombreCarpeta2 NombreCarpeta Proceso rea Tipo Nombre Descripcin NivelMadurez Efectividad Eficacia CalidadInf Alcance Autor Estado Versin Total: 2 Total: 16 tRequisitos Total: 1 Total: 0 On-line Funcin/es Complejidad/es
EQ(Entrada)
Baja
EQ(Salida)
Baja
FTR
Pgina 159 de 219
8.2.6 RESULTADOS FINALES Almacn TProyectos TCarpetas TRequisitos TRequisitoORG tHistorial tRequisitosRelacionados TUsuarios tUsuarioEnProyecto TGlosario TRequisitoITIL TOTAL FUNCIONES TOTAL PFSA (Datos) ILF M EIF M
B X X X X X X X X X 9
x7
0 9
x10
0
x15
X 1 x5 68
63
0 1 x7 5
0 x10
Pgina 160 de 219
Proceso Aadir proyecto Modificar proyecto Borrar proyecto Asignar usuario a proyecto Aadir carpeta Modificar carpeta Borrar carpeta Aadir requisito Modificar requisito Borrar requisito Incorporar requisitos a carpeta Aadir relacin entre requisito Borrar relacin entre requisito Aadir usuario Modificar usuario Borrar usuario Modificar datos personales Modificar rol Aadir trmino en glosario Modificar trmino en glosario Borrar trmino en glosario Listar requisitos ITIL Listar usuarios Listar trminos Iniciar sesin usuario Registrado Iniciar sesin usuario No Registrado Listar proyectos Listar proyectos adjuntos Listar usuarios en proyectos Listar carpetas Realizar bsqueda de requisitos Listar requisitos Listar datos personales Visualizar informe trazabilidad Visualizar informe comparativo Total funciones Total funciones
EI B X X X X X X X X X X X X X X X X X X X X X X X X M A B
EO M A B
EQ M A
X X X X X X X X X X X 11 3 x5 12 109 x7 x3 11 x4 33 x6
20 x3
1 21 x4 64 x6
3 x4
PFSA= PFSADatos + PFSAProcesos = 68 + 109 = 177 puntos de funcin sin ajustar
Pgina 161 de 219
A continuacin es necesario hacer un anlisis de las caractersticas generales del sistema para ajustar dichos puntos de funcin. Se debe calcular el grado de influencia on-line y el grado de influencia batch que tiene la aplicacin, justificando todas las decisiones: GDI on-line: Los procesos On-line se realizan manualmente, es decir, se necesita de una persona que active dichos procesos. C1 Comunicacin de datos: Se ha considerado de nivel 5 puesto que existen usuarios que interactan con la aplicacin a travs de ms de una ordenador, para llevar a cabo la gestin de requisitos de la empresa. La aplicacin consiste en una pgina web y, por lo tanto, dispone de varios tipos de protocolos de comunicacin. C2 Funciones distribuidas: Se ha considerado de nivel 4 puesto que las peticiones de informes por parte del usuario se generan dinmicamente dentro de los lmites del sistema, adems de que la transferencia de datos es on-line y en ambas direcciones, es decir, hay una interaccin entre usuario y servidor. C3 Rendimiento: Se ha considerado de nivel 1 puesto que los requisitos y el rendimiento del sistema fueron diseados y revisados antes de poner en prctica la aplicacin. Los tiempos de respuesta no presentan ninguna accin especial. C4 Configuracin fuertemente utilizadas: Se ha considerado un nivel 2 ya que las restricciones de seguridad en la aplicacin web, donde se atiende a clientes y usuarios, deben ser altas al tratar informacin sensible de las entidades. Contamos con una base de datos con informacin suficientemente importante para perderla. Se trabaja sobre una aplicacin segura y con acceso validado. C5 Frecuencia de transacciones: Se ha considerado un nivel 4 debido a que existe una frecuencia de transacciones alta diariamente, y sta influir sobre el soporte de la aplicacin. C6 Entrada de datos on-line: Se ha considerado un nivel 5 porque ms del 30% de las transacciones son interactivas, ya que tanto el usuario como el cliente tienen acceso al sistema a travs de una aplicacin web. Por lo general se dispone de acciones de tipo alta, baja, modificacin y consulta, por tanto, el nivel de transacciones relacionadas entre s es alto. Para que se produzca la accin de baja de un proyecto, por ejemplo, debe haber tenido la accin previa donde se ha dado de alta ese proyecto en la aplicacin.
Pgina 162 de 219
C7 Eficiencia del usuario final: Se ha considerado un nivel 3 ya que el sistema tiene funciones como ayudas a la navegacin, scrolling, documentacin on-line, teclas de funcin preasignadas, mens y ventanas, entre otras, por lo que necesitar ms de 6 funciones. No se especifican requisitos del usuario respecto a la eficiencia. C8 Actualizacin on-line: Se ha considerado un nivel 4 debido a que en la interaccin con el sistema se actualizan la mayora de los ficheros lgicos internos, y es esencial la proteccin contra la perdida de datos. Esta proteccin ha sido diseada y programa en el sistema. C9 Procesos complejos: Se ha considerado un nivel 0 puesto que bsicamente los procesos on-line consisten en altas, bajas, modificaciones y obtencin de listados. Nunca estn presentes procesos complejos ni matemticos. C10 Reutilizacin: Se ha considerado un nivel 3 porque al menos el 10% de la aplicacin tendr en cuenta las necesidades de ms de un usuario. C11 Facilidad de instalacin: Se ha considerado un nivel 1 puesto que por parte del usuario no existen requisitos especiales en cuanto a la instalacin, pero al ser instalado en un servidor web se requerir de un desarrollo especial de instalacin. C12 Facilidad de operacin: Se ha considerado un nivel 5 debido a que la aplicacin slo debe arrancarse y parar por el operador y se debe intentar que se lleve a cabo una recuperacin automtica de errores. C13 Instalacin en distintos lugares: Se ha considerado un nivel 3 porque el sistema desarrollado ha de ser lo ms independiente posible tanto del hardware como del software del que disponga el usuario final. Por otra parte, habr que facilitar documentacin y un plan de soporte de la aplicacin al cliente. C14 Facilidad de cambio: Se ha considerado un nivel 2 ya que se realizan consultas de complejidad media y se mantienen datos de control mediante procesos on-line de forma inmediata. La mayora de las operaciones son alta, baja, modificacin y consultas sin grandes problemas para ser cambiadas.
Pgina 163 de 219
Grados de influencia de Albretch Caracterstica C1 Comunicacin de datos C2 Funciones distribuidas C3 Rendimiento C4 Configuracin fuertemente utilizadas C5 Frecuencia de transacciones C6 Entrada de datos on-line C7 Eficiencia del usuario final C8 Actualizacin on-line C9 Procesos complejos C10 Reutilizacin C11 Facilidad de instalac0069n C12 Facilidad de operacin C13 Instalacin en distintos lugares C14 Facilidad de cambio Total
DI 5 4 1 2 4 5 3 4 0 3 1 5 3 2 42
GDI batch: Los procesos Batch sern activados automticamente en un cierto intervalo de tiempo, teniendo en cuenta que el usuario tendr constancia de que se produce. En este proyecto no se va a llevar a cabo ningn proceso batch por lo tanto el grado de influencia es nulo.
GDItotal= GDIOn-line + GDIBatch = 42 + 0 = 42 Una vez calculado el grado de influencia total de la aplicacin, se va a conseguir el factor de ajuste que corresponde y se va a aplicar sobre los puntos de funcin sin ajustar obtenidos con anterioridad. Por ltimo, se conseguirn las lneas de cdigo Basic que tendr la aplicacin, teniendo en cuenta que la equivalencia con COCOMO II en cuanto a lneas de cdigo por punto de funcin sera de 32 lneas/PF. FA = 0,65 + (0,01 * GDI TOTAL) = 0,65 + (0,01 * 42) = 1,07 PF = PFSA * FA = 177 * 1,07 = 189,39 puntos de funcin LOC = PF * 32 = 189,39 * 32 = 6060, 48 LOC = 6,06048 KLOC
Pgina 164 de 219
8.3 Estimacin COCOMO II:

Mediante un modelo Post-Arquitectura se van a establecer los factores de escala y los drivers de coste, con sus respectivas justificaciones, para realizar la estimacin mediante COCOMO II. Procedencia de Desarrollo (PREC): Se considera que este factor de escala tiene un valor muy bajo, puesto que se trata de un proyecto completamente sin precedentes, no existe experiencia en software de este tipo. Flexibilidad de Desarrollo (FLEX): Teniendo en cuenta que, como otras empresas de la competencia, estn desarrollando programas parecidos, se tendr que reducir el tiempo de desarrollo al 80% aproximadamente del tiempo previsto. Por tanto, se le ha asignado un nivel bajo en lo que conlleva a la flexibilidad de desarrollo. Arquitectura/Resolucin de Riesgos (RESL): No se tiene mucha informacin acerca de este factor de escala, por tanto y analizando subjetivamente las caractersticas del entorno se le va a asignar el valor nominal. Cohesin de Equipo (TEAM): Se tiene en cuenta que todos los miembros del equipo de desarrollo tienen una edad similar y que se encuentran en la misma posicin laboral, llegan con ganas de trabajar y aprender pero por contra tiene poca experiencia en aplicaciones similares. Se ha considerado asignarle un valor nominal. Madurez del Proceso (PMAT): Para calcular este factor de escala, no se conocen datos de las 18 caractersticas necesarias para ello. Analizando las caractersticas que se exponen en el enunciado relativas a la madurez del proceso, se determina que el PMAT, tendr un valor nominal.
Driver PREC FLEX RESL TEAM PMAT
Factores de escala Valor Muy bajo Bajo Nominal Nominal Nominal
Puntuacin 6.20 4.05 4.24 3.29 4.68
Pgina 165 de 219
Fiabilidad Requerida de Software (RELY): Se ha elegido un valor alto para el RELY puesto que el sistema ser un servidor y una cualidad bsica que se le exigira a nuestra aplicacin es que sea consistente y se produzcan las mnimas excepciones posibles. La informacin es suficientemente importante y las perdidas a veces no sern recuperables. Medida del volumen de Datos (DATA): Para este driver se ha considerado que tenga un valor nominal ya que el nmero de registros en la BBDD y el volumen de datos de dichos registros sern usuales. Complejidad del producto (CLPX): Analizando el proyecto se llega a la conclusin de que el valor de este driver ser nominal puesto que incluye acciones simples como anidamientos, llamadas y operaciones bsicas. Reutilizacin Requerida (RUSE): Se ha considerado que este driver de coste tendr un valor alto porque a lo largo de todo el proyecto se genera una serie de documentacin muy detallada que podr ser utilizada como referencia en otras aplicaciones, adems se crear una metodologa propia y existir la posibilidad de reutilizar gran parte del cdigo. Documentacin Asociada a las necesidades del ciclo de Vida (DOCU): Se ha elegido un valor alto para este driver de coste ya que se consideran unas necesidades correctas al ciclo de vida. Se crea un ciclo de vida en cascada y cada una de sus fases llevar su debida documentacin que ser estudiada como base para la toma de decisiones. Restriccin del tiempo de ejecucin (TIME): Se ha elegido un valor nominal puesto que las operaciones realizadas no requieren de un uso de la maquina elevado. No se espera que alguna de las aplicaciones consuma un tiempo de ejecucin excesivo puesto que los procesos no son especialmente complicados. Restriccin de almacenamiento principal (STOR): La estimacin de este driver es complicada puesto que no sabemos el volumen de datos que se manejan ni la capacidad de almacenamiento de cada empresa, por lo que hemos fijado un valor nominal, con el fin de mantener un valor equidistante. Volatilidad de la plataforma (PVOL): El software que vamos a desarrollar no precisa de requerimientos hardware y software muy elevados. Se prev que no ser necesario hacer demasiados cambios importantes a lo largo del tiempo puesto que el sistema es fcilmente adaptable a las necesidades. Se desarrollar una plataforma hardware, el
Pgina 166 de 219
Gestor de Bases de Datos y un sistema operativo, por tanto, el mayor cambio se realizar cada 12 meses. Este driver tendr un valor bajo. Habilidad del Analista (ACAP): En analista tiene ganas de trabajar y motivacin. En algunos casos es inexpertos en su trabajo por ser personal joven. Se considera que el valor de habilidad del analista ser bajo. Habilidad del Programador (PCAP): Como ocurra con los analistas, consideramos que nuestros programadores tambin son jvenes e inexpertos, pero tienen ganas de adquirir conocimiento y ponerlo en prctica. Se considera que el valor ser bajo. Experiencia en las Aplicaciones (AEXP): El equipo de analistas y programadores tiene poca experiencia en este trabajo. Por tanto, al ser la mayor parte del equipo de desarrollo recin licenciado, su experiencia tanto en las aplicaciones como en los dems mbitos del proyecto ser baja. Este driver de coste tendr un valor bajo. Experiencia en la Plataforma (PEXP): La experiencia en la plataforma, al igual que en las aplicaciones tendr un valor bajo. Experiencia en la Herramienta y en el Lenguaje (LTEX): La experiencia en Visual Basic .Net y en el lenguaje ASP se considerar de valor nominal puesto que, a pesar de que tanto los analistas como los programadores sean inexpertos, consideramos que tanto la herramienta como el lenguaje est extendido y el personal dispone de conocimiento mnimos para desenvolverse con soltura. Continuidad del Personal (PCON): No se especifica nada sobre la poltica de la empresa a este respecto, pero al contar con personal inexperto, se pretende formarles correctamente para contar con ellos en proyectos futuros, aunque es preciso dar un margen de movimiento en la plantilla puesto que son empleados nuevos y pueden no estar a la altura de las especificaciones necesarias. El valor de este driver ser nominal. Uso de herramientas Software (TOOL): Como se ha especificado anteriormente se realizar la documentacin necesaria para cada fase del ciclo de vida, por tanto, se utilizarn las herramientas del ciclo de vida bsicas para facilitar esta tarea. Es por ello que se le ha asignado a este driver de coste un valor nominal.
Pgina 167 de 219
Desarrollo Multilugar (SITE): La localizacin de la empresa ser alta puesto que se trabajar en la misma ciudad o rea metropolitana, dentro de la sede de la empresa. La comunicacin entre empleados y personal ser mediante comunicacin electrnica de banda ancha, suponiendo esto ya que es algo que actualmente es prcticamente bsico en cualquier lugar. Se va a atribuir, por tanto, al desarrollo multilugar un valor alto. Calendario de Desarrollo Requerido (SCED): Debido a que no hay exigencias de tiempo y el personal ser bastante inexperto, el proyecto puede retrasarse, por lo que el valor ser alto. Factores de escala Valor Alto Nominal Nominal Alto Alto Nominal Nominal Bajo Bajo Bajo Bajo Bajo Nominal Nominal Nominal Alto Alto
Driver RELY DATA CLPX RUSE DOCU TIME STOR PVOL ACAP PCAP AEXP PEXP LTEX PCON TOOL SITE SCED
Puntuacin 1.10 1.00 1.00 1.07 1.11 1.00 1.00 0.87 1.19 1.15 1.10 1.09 1.00 1.00 1.00 0.93 1.00
Pgina 168 de 219
A continuacin se adjuntan los datos obtenidos de la herramienta COCOMO II al aplicar los factores de escala y los drivers de coste estimados anteriormente:
Figura 64. Datos de estimacin COCOMO II
Tras evaluar los 17 drivers de coste en este ejercicio (modelo postarquitectura), se obtiene un valor de 1,94 para el multiplicador de esfuerzo, que se obtiene multiplicando todos los drivers de coste entre s. En los datos anteriores se puede observar informacin de inters sobre el proyecto, como son el riesgo, estimacin optimista, moderada y pesimista, y la productividad. La duracin total del proyecto es de 15,9 meses. Segn esta estimacin, el coste final del proyecto sera de 61.279 euros.
Pgina 169 de 219
Para completar el estudio de la planificacin, vamos a incluir los datos obtenidos de la herramienta COCOMO II, distribuidos en cada una de las fases: Proyecto total:
Figura 65. Datos de estimacin
Podemos apreciar que la fase de programacin del proyecto en la que ms tiempo y esfuerzo va a invertir. El esfuerzo ser de 25,398 personas/mes sobre el esfuerzo total que es 40,853 personas/mes. Las lneas de cdigo estimadas para la realizacin de la aplicacin son 5664. Requisitos y planes del proyecto:
Figura 66. Datos de estimacin fase planificacin y requisitos
Se observa que el tiempo de desarrollo tiene un valor contante a lo largo de todas las fases. El tiempo sern 2,743 meses y el esfuerzo requerido para llevarlas a cabo ser de 2,860 personas/mes.
Pgina 170 de 219
Diseo del proyecto:
Figura 67. Datos de estimacin fase diseo
Se observa que el tiempo de desarrollo tiene un valor contante para todas las fases de diseo. El tiempo sern 3,920 meses y el esfuerzo requerido para llevarlas a cabo ser de 6,945 personas/mes.
Programacin del proyecto:
Figura 68. Datos de estimacin fase programacin
Se observa que el tiempo de desarrollo tiene un valor contante para todas las fases de programacin del proyecto. El tiempo sern 8,530 meses y el esfuerzo requerido para llevarlas a cabo ser de 25,398 personas/mes.
Pgina 171 de 219
Integracin y pruebas del proyecto:
Figura 69. Datos de estimacin fase integracin y pruebas
Se observa que el tiempo de desarrollo tiene un valor contante para todas las fases de integracin y pruebas. El tiempo sern 3,477 meses y el esfuerzo requerido para llevarlas a cabo ser de 8,511 personas/mes.
Mediante el RBS representaremos la estructura tanto de los recursos humanos como materias y tecnolgicos. Los recursos humanos estarn compuestos por 3 personas. Consideramos necesario un analista, encargado de desarrollar las tareas, disear el proyecto y dar apoyo al Jefe de proyectos, y un programador, capaz de realizar la implementacin de la aplicacin y las pruebas unitarias correspondientes. Estos dos componentes estarn vigilados por un Jefe de proyecto, que ser el responsable del proyecto, toma decisiones y se muestra autoritario.
Figura 70. Recursos humanos
Pgina 172 de 219
A pesar de que el proyecto real ha sido analizado, diseado y desarrollado por
una nica persona, consideramos oportuno diferenciar estos tres roles para hacer ms real el proyecto. En el caso del proyecto presente, la nica persona implicada desarrollar funciones de Jefe de proyecto, de analista y de programador, trabajando al 50% de sus posibilidades en caso de existir, por ejemplo, dos tareas paralelas. Los recursos materiales estarn compuestos por las herramientas, plataformas y dems recursos necesarios para la realizacin del proyecto.
Figura 71. Recursos materiales
8.4 Planificacin del proyecto:

Las actividades que se van a realizar para llevar a cabo en este proyecto se han descrito de acuerdo al estndar IEEE 1074-2006. A continuacin se muestra el grfico del resultado del diagrama Gantt que se obtiene tras la realizacin de dicho diagrama en Microsoft Project 2007.
Pgina 173 de 219
Pgina 174 de 219
Si observamos el diagrama Gantt anterior, podemos comprobar que la duracin de las fases del ciclo de vida concuerda con las estimaciones obtenidas en COCOMO II. Dicha herramienta, tras evaluar las caractersticas oportunas, obtena un valor de 15,9 meses de duracin total de proyecto y 61.279 como estimacin de coste final. El estudio realizado con COCOMO II ha sido muy completo y cubre todas las fases del ciclo de vida. Comentar que nos hemos visto en la obligacin de recortar tanto en gastos como en tiempo de realizacin del proyecto puesto que exceda de esfuerzo, y a consecuencia de ello, nuestro proyecto final ha pasado por alto algunos requisitos y tareas irrelevantes. Adems, las tareas realizadas tienen menos alcance. A continuacin se muestra el grfico del resultado del diagrama Gantt que se obtiene tras la realizacin de dicho diagrama en Microsoft Project 2007.
Pgina 175 de 219
Pgina 176 de 219
La duracin total del proyecto real, segn el diagrama Gantt obtenido, es de 263 das laborales. El proyecto empez el 1 Julio de 2008 y terminar el 2 de Julio del 2009. Aadir que, por regla general cada da laboral se ha trabajo 8 horas pero algunos das nos hemos visto forzados a trabajar un mayor nmero de horas para terminar el proyecto a tiempo.
8.5 PMBOK
El Project Management Body Of Knowledge es una gua estndar para la gestin de proyectos. PMBOK contiene prcticas y teoras que han sido compiladas y mejoradas durante los ltimos aos y es uno de los ms importantes documentos creado por el Project Management Institute (PMI). El PMI se encarga de administrar, documentar e identificar un gran conjunto de informacin en reas de conocimiento y adems describir prcticas que son aplicables en esta gestin de proyectos.
8.5.1 Integracin de PMBOK con ITIL

El modelo PMBOK tiene un punto de unin con la biblioteca ITIL. Tanto PMBOK como ITIL son estndares complementarios pero superpuesto a la vez, por tanto se puedes utilizar paralelamente de manera que ITIL se encarga de gestionar los servicios y PMBOK de gestionar los cambios provenientes de dichos servicios. ITIL est orientado a garantizar la disponibilidad y el buen funcionamiento del servicio y por otro lado PMBOK busca una correcta gestin de cambios para garantizar la calidad de los servicios en tiempo, coste y riesgos.
8.5.2 Representacin de los datos de estimacin

Mediante la tcnica del valor ganado se va a medir la cantidad de trabajo real realizado en el proyecto y pronosticar el coste final y fecha de fin del proyecto. Los tres valores sobre los datos se procesan cada mes y son los siguientes: PV: Coste presupuestado del trabajo programado. EV: Coste presupuestado del trabajo realizado. AC: Coste real del trabajo realizado. La lnea base o valor PV se obtiene de los datos planificados definidos en el primer diagrama Gantt. Para construirlo se debe evaluar cada tarea realizada, el alcance del proyecto, los costes unitarios y las responsabilidades que tiene cada rol.
Pgina 177 de 219
Figura 74. Datos de estimacin.
Se observa que el proyecto final se ha realizado en menos tiempo, exactamente 4 meses de diferencia respecto al planificado. Adems, el coste invertido es menor puesto que se han realizado menos tareas o requisitos.
Pgina 178 de 219
9. Conclusiones
Si se vuelve al punto 1.2 de este documento, donde reflejamos los objetivos a conseguir con la realizacin de este proyecto, veremos que efectivamente el resultado del mismo cumple con los requisitos fijados antes de comenzar. Se buscaba la realizacin de un estudio y un posterior aplicativo capaz de dar solucin al anlisis de requisitos de una empresa, lo cual lo hemos superado con creces. Se ha construido una herramienta completa, amigable y sencilla, adems de adquirir una calidad, precisin y claridad de la documentacin y del cdigo generado. Como tambin hemos comentado al comienzo de este documento, la fase de adquisicin de requisitos es una de las ms importantes para conseguir la satisfaccin del cliente y desarrollar lo que realmente buscaba. Con esta herramienta se fortalece la relacin entre cliente e ingeniero de software y se crea una base robusta, facilitando la realizacin de las dems fases de un proyecto software. Destacar, tambin, que el acercamiento a ITIL como gua sobre la provisin de servicios TI, a CMMI y a MOF ha sido satisfactorio. El anlisis, el diseo y la implementacin de la aplicacin se han realizado y documentado adecuadamente con el fin de poder ser reutilizado y/o ampliada en procesos futuros. A continuacin haremos hincapi en los problemas encontrados durante el desarrollo del proyecto, junto con resoluciones propuestas.
9.1 Dificultades encontradas:

El hecho de que el estudio elaborado junto con la herramienta construida forme parte de un proyecto fin de carrera realizado por una nica persona implica una serie de dificultades importantes que hay que tener en cuenta. Cualquier proyecto real existente no es una nica persona la que realiza todas las fases, sino que cada fase se realiza por una o varias personas que se apoyan, comparten y discuten ideas y, por tanto, hacen del trabajo varios puntos de vista. Adems en realidad, a parte de todos los conocimientos nuevos que se puedan adquirir con la realizacin de este proyecto, que han sido muchos, un proyecto fin de carrara es condicin para obtener finalmente la titulacin, y se
Pgina 179 de 219
nota una cierta presin sobre el tiempo de entrega con el fin de que ste no sea eterno. Por otra parte, puesto que la desarrolladora del proyecto era inexperta en la tecnologa ASP .Net se han encontrado graves obstculos a la hora de implementar la aplicacin Web requerida en este proyecto. Se desconoca las caractersticas, el funcionamiento de la plataforma y los patrones de diseo, adems se encontraron problemas a la hora de pensar en la distribucin de las clases y los objetos que la aplicacin debera tener. Se han cometido errores, sobre todo en las primeras fases de desarrollo, lo que era complicado de subsanar ya avanzado el proyecto.
9.2 Soluciones propuestas:

El proyecto se ha realizado de forma ordenada y estructura, teniendo claro desde un principio los objetivos a conseguir y las tecnologas a utilizar. Se ha hecho uso de documentacin sobre herramientas de gestin de requisitos, manuales, tutoriales y toda la informacin necesaria para realizar un estudio completo, e incluso se ha tomado un tiempo de trabajo con las propias herramientas de gestin de requisitos actuales en el mercado para conocer las funcionalidades y caractersticas ms importantes para luego implementarlas en nuestra propia herramienta. Para resolver el problema del desconocimiento de la tecnologa ASP .Net se ha hecho un estudio exhaustivo de la misma, adquiriendo conocimientos bsicos para poder implementar la aplicacin web. No ha sido fcil, todo hay que decirlo, pero la constancia en el trabajo y las ganas de aprender han sido un apoyo fuerte para seguir adelante.
Pgina 180 de 219
10. Referencias
Para la realizacin de este proyecto se han utilizado, por un lado, informacin recogida en diferentes pginas Web, en las que se han de destacar: http://es.wikipedia.org/wiki/Information_Technology_Infrastructure_Library (ITIL) http://en.wikipedia.org/wiki/ITIL_v3 (ITIL v3) http://www.best-managementpractice.com/gempdf/itSMF_An_Introductory_Overview_of_ITIL_V3.pdf http://www.channelplanet.com/?idcategoria=19212 (Ciclo de vida del servicio) http://es.wikipedia.org/wiki/Gesti%C3%B3n_de_Servicio_TI (Gestin de Servicios) http://itil.osiatis.es/Curso_ITIL/Gestion_Servicios_TI/service_desk/vision_ge neral_service_desk/vision_general_service_desk.ph http://es.wikipedia.org/wiki/CMMI http://www.sei.cmu.edu/cmmi/ http://www.sei.cmu.edu/cmmi/models/CMMI-Services-status.html http://ciencias.unizar.es/web/relacionesEmpresas/salidas/presentacion_Cap gemini08.pdf http://www.dtic.mil/ndia/2006cmmi/wednesday/3D5_Hollenbach.pdf http://www.mkm-pi.com/mkmpi.php?article1817 (Cmmi vs ITIL) http://technet.microsoft.com/en-us/library/cc506049.aspx (MOF)
Pgina 181 de 219
http://technet.microsoft.com/es-es/library/bb232042.aspx http://en.wikipedia.org/wiki/Microsoft_Operations_Framework http://books.google.es/books?id=PI2HokV7HtIC&pg=PA146&lpg=PA146&dq =gestion+de+requisitos&source=web&ots=yQBaHEvdhE&sig=b7NA4WNQKa 5OZyataeYveZTqxh8&hl=es&sa=X&oi=book_result&resnum=8&ct=result#PP A141,M1 http://is.ls.fi.upm.es/doctorado/Trabajos20042005/Mcdonald.pdf (Herramientas de gestin de requisitos) http://www.paper-review.com/tools/rms/read.php (INCOSE) http://www.als-es.com/home.php?location=herramientas/entornodesarrollo/doors ( Doors Telelogic) http://www.telelogic.com/products/doors/doors/index.cfm (Doors Telelogic) http://www.dssltd.com/a3_doors.pdf (Manual de Telelogics Doors Software) http://www.borland.com/us/products/caliber/rm.html (Borland CaliberRM) http://www.samsistemas.com.ar/partners/caliber.html (Borland CaliberRM) http://www.softwareplanner.com/ (SoftwarePlanner) http://ipcorp.com.ar/blog/?p=15 (OSRMT) http://www.gatherspace.com/ (Gartherspace)
Pgina 182 de 219
Para la realizacin de un estudio ms completo de las herramientas se han descargados e instalado las versiones libres de las mismas, con el fin de probar sus funcionalidades de una forma ms directa: CaliberRM: http://www.borland.com/downloads/download_caliber.html REM: http://www.lsi.us.es/descargas/descarga_programas.php?id=3 OSRMT: http://sourceforge.net/projects/osrmt Gatherspace: http://www.gatherspace.com/ http://www.clikear.com/manuales/uml/ (Manual UML) http://es.wikipedia.org/wiki/Modelo_Vista_Controlador http://www.proactiva-calidad.com/java/patrones/mvc.html http://thinkingindotnet.wordpress.com/2007/10/16/aspnet-mvcframework/ http://trevinca.ei.uvigo.es/~cfajardo/Nueva_carpeta/presentaciones/cocom o2k.pdf (COCOMO II) http://www.scribd.com/doc/2906082/Tutorial-Microsoft-Project-2007 (Tutorial Microsoft Project 2007) http://www.inf.utfsm.cl/~lhevia/asignaturas/proy_ti/topicos.php?sigla=INF364&area=4 (Descargas varias del PMBOK) http://www.best-managementpractice.com/gempdf/ITILV3_Glossary_Spanish_v3.1.24.pdf (Glosario de trminos ITIL) http://www.desarrolloweb.com/manuales/48/ http://www.webestilo.com/aspnet/ http://www.elguille.info/NET/ASPNET/Default.aspx
Pgina 183 de 219
Los libros utilizados para completar la informacin de este proyecto han sido muy diversos, entre los ms destacados estn: Fundamentos de la Gestin de Servicios de TI Basado en ITIL v3, de ITSMF Internacional. Manual de Visual Basic .net Manual de Sql-Server Manual de Ado.net Manual de ASP.net
Pgina 184 de 219
11. Anexos
11.1 Requisitos de herramientas ITSMF 11.1.1 Requisitos Tcnicos:
AREA TIPO BLOQUE REQUISITOS
ARQUITECTURA Servidor: S.O soportado: HPUX Servidor: S.O soportado: Solaris Servidor: S.O soportado: Windows ARQUITECTURA Servidor: S.O soportado: Linux Arquitectura distribuida : Web, Middleware y Datos. Alta disponibilidad REQUISITOS TECNICOS INFRAESTRUCTURA Protocolo comunicaciones Rendimiento Comunicaciones Solucin multi-cliente ESCALABILIDAD El sistema flexible distribuida. para soportar una solucin centralizada o una NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA
DESCRIPCIN REQUISITO
NIVEL DE MADUREZ
EFECTIVIDAD
TIPO DE IMPACTO EFICACIA CALIDAD INF
ALCANCE
El sistema deber soportar esquemas de balanceo de carga entre servidores Encriptacin de Datos ALMACENAMIENTO Almacenamiento Integracin con otras BBDD SEGURIDAD Definicin de Roles de usuario en funcin de grupos tcnicos Definicin de roles de usuario en funcin de la responsabilidad.
Pgina 185 de 219
Gestin de Roles de usuario centralizada de gestin de seguridad desde la que se permitir: -Posibilidad Posibilidad de crear, borrar o actualiza actualizar un nuevo perfil autorizado. -Asignacin Asignacin de permisos. Configuracin dinmica de estos y de su metodologa de asignacin. El sistema tema de Gestin de Seguridad debe ofrecer adicionalmente la mayor flexibilidad posible para que el administrador pueda parametrizar por ej: nmero mximo de intentos de acceso fallidos, tiempo de inactividad mximo, complejidad de passwords, etc El sistema debe garantizar la integridad de la informacin, impidiendo que dos usuarios modifiquen mismos campos de informacin simultneamente El sistema debe garantizar la integridad de la informacin almacenada, por ejemplo encriptando informacin en la base de datos Las aplicaciones de acceso Web debern garantizar la integridad y confidencialidad de la informacin a travs de protocolos de encriptacin, tales como SSL (Secure Socket Layer) El sistema debe poder integrarse con sistemas de directorio para autenticacin de usuarios y/o autorizacin de usuarios, tales como sistemas LDAP, Active Directory, etc. Almace Almacenamiento de Accesos. ACCESIBILIDAD/ADMINISTRACIN Definicin de Roles de Usuario Interfaces de Usuario: Web y Consola Interfaces de Administracin:Web Parametrizacin consolas de usuario en funcin de los roles de usuario ACCESIBILIDAD ACCESIBILIDAD/ADMINISTRACIN Interfaces de usuario multi multi-idioma. Mnimo Ingles y Castellano. El sistema debera proveer un kit de customizacin de interfaces (pantallas) El sistema istema debe permitir realizar consultas directas a las Bases de Datos en SQL. L. Tiempo de instalacin Tiempo de Configuracin. Wizard de instalacin. Soporte Escenarios de WorkFlow Integracin con Directorio Activo INSTALACIN Integracin con Notes Integracin con SMS Consultas parametrizables Facilidad parametrizacin Facilidad de uso. Interface intuitivo Tiempo de aprendizaje de un operador bajo
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA
Pgina 186 de 219
Dependencia del proveedor baja Precisa cliente puestos Help Desk Tiempo Parametrizacin. Configuracin basada en mantenimientos. ADMINISTRACIN/CONFIGURACION Configuracin basada en reglas de negocio. Mantenimiento en Caliente (7x24) Tiempo de arranque del sistema. Facilidad para la creacin de informes Herramienta integrada para la generacin de informes GENERACIN DE INFORMES Asistentes para formularios e informes Automatizacin de la generacin de informes Envo de informes automticos por mail
NA NA NA NA NA NA NA NA NA NA NA NA
Pgina 187 de 219
11.1.2 Integracin Herramientas:

TIPO DE IMPACTO EFECTIVIDAD EFICACIA CALIDAD INF
AREA
TIPO
BLOQUE REQUISITOS CONECTORES
DESCRIPCIN REQUISITO
NIVEL DE MADUREZ
ALCANCE
Pluggins conexin productos gestin de disponibilidad Pluggins conexin productos gestin de capacidad CONECTORES Pluggins conexin productos gestin de incidencias&problemas Pluggins conexin productos gestin de cambios PLUGGINS Pluggins conexin productos gestin de versiones Pluggins conexin productos gestin de continuidad Pluggins conexin productos gestin de seguridad Pluggins conexin productos gestin de configuracin Pluggins conexin productos gestin financiera INTEGRACIN HERRAMIENTAS BBDD OTRAS INTEGRACIONES ARQUITECTURA SOA Arquitectura SOA El sistema debe tener la capacidad de integrarse con sistemas como: - Sistemas de gestin de infraestructura. - Plataformas de Mail - Plataformas de PDA - Soluciones de paging - Soluciones de CRM, SFA y ERP - Soluciones de distribucin de software e inventario - Herramientas de reporting - Sistemas de cdigo de barra OPCIONES INTERACIN El sistema debe permitir la importacin y exportacin de datos a sistemas estndar como, por ejemplo, bases de datos SQL, MS Excel y MS Project El producto debe soportar APIs, que permitan la construccin de interfaces, en lenguajes estndar como, por ejemplo, C, JAVA, MAPI, XML XML. El producto a nivel de servidor, debe ser multiplataforma e independiente de los sistemas operativos que las soporten El producto a nivel de servidor, debe ser compatible con diferentes RDBMSs Conectores con BBDD otros productos
NA NA NA NA NA NA NA NA NA NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA
NA NA NA
NA NA NA
NA NA NA
NA NA NA
NA NA NA
Pgina 188 de 219
11.1.3 Service Desk:

AREA TIPO BLOQUE REQUISITOS REQUISITOS GENERALES Iniciar una peticin de servicio: El portal ofrecer para todos aquellos usuarios que tengan el rol para ello, una entrada para arrancar peticiones de servicio en Service Desk. Esta entrada dar paso a un formulario que permitir registrar la peticin de servicio. Listar las peticiones de servicio pendientes: El portal ofrecer a los usuarios que tengan peticiones de servicio pendientes de resolver, una lista de las mismas. El listado deber presentar suficiente informacin para que pueda reconocer la prioridad de la peticin, el cdigo de la peticin, el tipo de peticin de servicio, el estado en el que se encuentra, la fecha de apertura, el usuario asociado, el grupo que la tiene asignado y referencia al SLA a cumplir. Tambin es recomendable que si la peticin esta vinculada con otra entidad (ej. Incidencia o Cambio) aparezca su cdigo. Este listado deber de ofrecer mecanismos de filtrado para seleccionar. Listar las peticiones de servicio solicitadas "Mis Solicitudes": El portal ofrecer a los usuarios que hayan abierto peticiones, una opcin para ver el listado de solicitudes que han realizado y estn en curso. El listado deber presentar suficiente informacin para que pueda reconocer el cdigo de la peticin, la fecha de apertura y el estado. Este listado deber ofrecer mecanismos de filtrado. Multi-Idioma : El portal ofrecer un mnimo de dos idiomas entre los cuales se podr conmutar. Adems, se valorar el que el sistema pueda ser configurado con idiomas alternativos. Generacin informes : El portal deber ofrecer informes por defecto que resuman el total de peticiones de servicios solicitadas en una escala temporal semanal. Se valorar el que se ofrezcan otras escalas , como por ejemplo: mensuales y anuales. Repositorio de Contenidos : Se ofrecer un modelo de datos relacionado con las Gestin de Peticiones de Servicio documentado y explotable que permita generar informes a medida u otro tipo de anlisis. Auditoria de accesos: El producto ofrecer log estndar para la gestin de la auditora de accesos del usuario al sistema. KPI's (Key Process Indicators:internos del proceso) - Valores y Grficas en distintas escalas temporales. El sistema ofrecer grficas de evolucin de este tipo de indicadores sobre la funcin de Service Desk. Se valorar el nmero de escalas temporales y la posibilidad de extraer los datos para su anlisis. DESCRIPCIN REQUISITO NIVEL DE MADUREZ TIPO DE IMPACTO EFECTIVIDAD EFICACIA CALIDAD INF ALCANCE
MEDIO
MEDIO
PORTAL NICO DE PROCESOS. REQUISITOS FUNCIONALES
REQUISITOS GENERALES
MEDIO
ALTO
ALTO
GENERACIN DE INFORMES
ALTO
MEDIO
MTRICAS
ALTO
Pgina 189 de 219
KGI's (Key Goal Indicators: Objetivos del proceso) - Valores y Grficas en distintas escalas temporales. El sistema ofrecer grficas de evolucin de este tipo de indicadores sobre la funcin del Service Desk. Se valorar el nmero de escalas temporales y la posibilidad de extraer los datos para su anlisis. Mail: El sistema deber ofrecer una comunicacin de entrada y salida con el usuario a travs de correo electrnico. SMS: El sistema deber ofrecer una comunicacin de salida con el usuario a travs de mensajes cortos a movil. CANALES DE COMUNICACIN Mixto - Mail y SMS: El sistema deber de ofrecer la posibilidad de una comunicacin de salida por mltiples canales simultneamente. Gestin de alertas multicanal: El sistema ofrecer mecanismos de alarmas para llamar la atencin al operador o la usuario. Estos mecanismos se pueden traducir,por ejemplo, en unos indicadores luminosos para alertar de un incumplimiento o prximo incumplimiento de SLA o paneles de alertas u otros mecanismos similares. Mdulo de Usuarios: El proceso ofrecer un formulario para que el usuario pueda realizar un registro autnomo de una peticin de servicio. MODULOS DISPONIBLES Mdulo de Agentes: El proceso ofrecer un formulario apra que los agentes realicen todo el ciclo de vida sobre una peticin de servicio. Establecimiento de destinatarios : El sistema ofrecer un mecanismo basado en reglas de negocio para que se pueda establecer reglas de destinatarios. Establecimiento de la categorizacin : El sistema ofrecer un mecanismo basado en reglas de negocio para que se pueda establecer reglas que precategoricen la peticin de servicio. Establecimiento de SLA : El sistema ofrecer un mecanismo basado en reglas de negocio para que se pueda establecer reglas de calculo del acuerdo de resolucin de la peticin en base a las distintas variables requeridas para su generacin. Establecimiento de calculo de prioridad: El sistema ofrecer un mecanismo basado en reglas de negocio para que se pueda establecer reglas de calculo de prioridad, combinando las distintas variables que deban intervenir para su generacion. Disponibilidad de un paquete de reglas de configuracin: Se valorar que el sistema aporte un paquete de reglas que permita realizar a travs de reglas de negocio, otras configuraciones para personalizar el funcionamiento del proceso. Codificacin de la peticin de servicio: El sistema deber de generar un cdigo nico para la peticin de servicio creada. Este cdigo tendr que ser accesible al usuario y ser comunicado y presentado para su conocimiento de una forma gil. Ej. Envio a su correo, Presentacin en listados, etc. Listas de valores con filtros: El sistema deber ofrecer mecanismos de seleccin basada en listas de valores que permita al usuario agilizar una seleccin tanto nica como mltiple. Se valorar la existencia de filtros para localizar dentro de la lista de valores la informacin.
ALTO
4 4 4
S S S
P P P
S S S
MEDIO MEDIO MEDIO
MEDIO
3 3
S P
P P
S P
MEDIO ALTO
ALTO
ALTO
ALTO
REGLAS DE NEGOCIO
ALTO
ALTO
BAJO
USABILIDAD
BAJO
Pgina 190 de 219
Listados con filtros y ordenacin: El sistema ofrecer listados que permita a los usuarios del proceso localizar los registros abiertos de peticiones de servicio. Organizacin de informacin: El sistema deber ofrecer mecanismos de agrupacin de la informacin para facilitar su presentacin al usuario. Ej. Columnas, tarjetas, etc. Relleno automtico/preautomtico de campos sensibles: El sistema ofrecer mecanismos que permitan dada una informacin recolectar informacin de detalle que se presenta en el formulario. Ej. Dado el ID de usuario, recoger su ubicacin, sus telefonos, su email, etc. Indicador de SLA: El sistema ofrecer mecanismos de presentacin y de alerta de cumplimiento de SLA. Ej. Un indicador que cambie de color al 50% de cumplimineto del tiempo de resolucin y que cambie nuevamente de color cuando se haya superado. Se valorar otros mecanismos de comunicacin como pueda ser las notificaciones via email de estas alertas. Indicador de No Conformidad: El sistema ofrecer mecanismos de presentacin y alerta sobre la no conformidad en la resolucin de una peticin de servicio, quedando claramente indicadas aquellas que han sido marcadas como no conformes durante la encuesta al cliente. Facilidad de Implantacin: El sistema tendr que ofrecer unos mecanismos estandar , intuitivos y usables para su puesta en marcha. Deber de ofrecer una documentacin de calidad para tal propsito. Se valorar el que el sistema sea instalable y configurable a travs de asistentes (siempre que sea posible por estar en su mbito de accin). Multi-Catalogo de Servicios : El sistema ofrecer mecanismos que permita configurar la salida de mltiples ctalogos de servicio en base a variables de decisin. Ej. Empresa, Carctersticas del usuario, etc. GESTIN MULTIPLE Multi-Empresa : El sistema ofrecer mecanismos que permintan configurar distintas empresas y que los datos que proporcione la funcin este filtrado por dicha empresa. Multi-Entidad: El sistema ofrecer mecanismos que permitan conectar con mltiples instancias de repositorio de usuarios. Ej. Varios Active-Directory. Este caso es aplicable a organizaciones donde estos repositorios estn distribuidos Ej. Por geogrfia
BAJO
ALTO
BAJO
MEDIO
BAJO
ALTO
MEDIO
MEDIO
MEDIO
PROCESO REQUISITOS DEL PROCESO Registro: La funcin permitir realizar el registro de la peticin de servicio. Los campos mnimo que tendr esta ficha son : Nombre y Apellido de usuario, telefono/s,ubicacin, tipo de llamada [incidencia,peticin,consulta,reclamacin] , sintoma o tipo de peticin y GESTIN DE PETICIONES DE SERVICIO descripcin de la peticin de servicio. Se valorar que el sistema tenga la (Peticiones, Incidencias, Reclamaciones y posibilidad de anexar documentos para completar o detallar la informacin Consultas) de la descripcin. Ej. Envio de ficheros de log. Envio de Pantallas de error. Completar y priorizar: La funcin permitir completar y priorizar a la peticin de servicio, con el objetivo de aadir la suficiente informacin para que pueda ser procesada y se haga en el orden adecuado.
MEDIO
MEDIO
Pgina 191 de 219
Resolver : La funcin permitir establecer la informacin necesaria para dar por resuelta la peticin. Se valorar la existencia de un diario de acciones que permita ir incluyendo registros de actividades realizadas durante la resolucin. Asociar a instancia de proceso nueva: La funcin debe permtir establecer un vinculo con una instancia de otro proceso con el que se relaciona en su ciclo de vida. Ej. Crear y enlanzar una instancia de incidente que resuelva una peticin de servicio de tipo incidencia. Asociar a instancia de proceso en vuelo: La funcin debe permitir establecer un vinculo con una instancia existente de otro proceso con el que se relaciona en su ciclo de vida. Ej. Enlanzar con una instancia de RFC que resuelva una peticin de servicio de tipo cambio. Revisin de la resolucin: La funcin permitir revisar y cerrar la peticin, bien de forma automtica o bien de forma manual. Lanzamiento manual de encuesta: El sistema deber de permitir lanzar la encuesta de conformidad y satisfaccin de forma manual. Esta situacin es recomendable cuando se desea certificar la correcta resolucin de la peticin de servicio antes de enviar al cliente. Lanzamiento automtica de escuesta: El sistema deber de permitir automticamente la encuesta en los casos en los que no se requiera una certificacin por parte del grupo de agentes del service desk. Resolucin de encuesta: El sistema deber de ofrecer una bandeja de encuestas pendientes al usuario y un formulario para poder establecer la conformidad de la peticin de servicio y la valoracin del servicio recibido. Los campos necesarios son un campo Conforme SI/NO y una serie de preguntas sobre las que se les pueda establecer una puntuacin de 0 a 5. Reapertura de peticiones de servicio en caso de no conformidad: El sistema reactiviar la peticin de servicio para que el agente del service desk vuelva a tratar la peticin en caso de que el usuario hay respondido con "no conformidad" a la encuesta. Cierre de peticiones de servicio en caso de conformidad: El sistema debe permitir cerrar la peticin de servicio de forma automtica tras la conformidad por parte del usuaria de la resolucin. Cierre automtico de peticiones de servicio por Time Out: El sistema debe permitir cerrar peticiones de servicio de forma automtica transcurrido un tiempo de espera de respuesta a la encuesta de conformidad al usuario. Apertura de reclamaciones: El sistema debe permitir abrir peticiones de servicio que corresponda a tipo reclamacin sobre otra peticin en curso. Estas reclamaciones suelen lanzarse en caso de un tiempo excesivo en la obtencin de respuesta por parte del service desk. Resolucin de reclamaciones: El sistema ofrecer los campos necesarios para poder establecer la tipologa de la peticin como reclamacin y los mecanismos para poder relacionar dicha peticin con la peticin origen.
MEDIO
MEDIO
MEDIO
BAJO
MEDIO
ALTO
MEDIO
GESTIN DE ENCUESTAS.
ALTO
MEDIO
MEDIO
MEDIO
GESTION DE RECLAMACIONES
BAJO
Pgina 192 de 219
Generacin automtica de reclamaciones: El sistema debera ofrecer mecanismos basados en reglas de negocio para la apertura automtica de reclamaciones. Ej. Para un tipo concreto de peticin y para un servicio concreto , abrir una reclamacin automtica en caso de no conformidad por parte del usuario. Este mecanismo es un mecanismo proactivo para lanzar una tarea a los agentes del Service Desk para que analicen el porque ha ocurrido esa no conformidad. Diario de Acciones: El sistema deber de ofrecer un diario de acciones para poder visualizar anotaciones automticas que registra el sistema , as como, permitir introducir nuevas acciones por parte de los agentes del service desk y que permiten registrar una traza histrica de la resolucin aplicada. Consulta a la CMDB: El sistema ofrecer una consulta a la CMDB para poder que los agentes del service desk analicen actuaciones pasadas. Ej. dado un elemento de configuracin qu peticiones de servicio se han realizado y poder editar dichas peticiones para analizar su resolucin y su diario de acciones o modo en como se acto. Consulta de notificaciones: EL sistema ofrecer una consulta para poder recodar las notificaciones que han sido enviadas al usuario. UTILIDADES Envio de notificaciones: El sistema ofrecer mecanismos automticos de notificacin y mecanismos manuales a travs de un formulario que permita enviar una notificacin a travs de un canal de comunicacin directa con el usuario de mensajes. Este servicio aporta mayor satisfaccin al usuario. Base de datos de conocimiento de soluciones: El sistema ofrecer un mecanismo a travs de un formulario que permita consultar soluciones disponibles para aplicar durante la resolucin de una peticin de servicio. Plantillas de tareas y subtareas predefinidas: El sistema dispone de una opcin que permite abrir en base a determinadas variables como pueda ser el sintoma o el tipo de cambio, una serie de tareas y subtareas de resolucin para dicho caso. Histrico de peticiones de servicio: El sistema da acceso a las peticiones de servicio creadas en el pasado por un usuario. Esta herramienta cubre la necesidad de disponer de informacin de entrada para un anlisis de un caso en base a casos pasados.
ALTO
BAJO
ALTO
BAJO
MEDIO
ALTO
ALTO
ALTO
REQUISITOS DE INTEGRACION
INTEGRACIN RESTO DE PROCESOS INTEGRACIN RESTO DE PROCESOS Creacin de incidencias: El sistema deber ser capaz de abrir incidencias sobre el proceso de Gestin de Incidencias para vincular a una peticin de servicio de tipo incidencia que no pueda ser resuelta desde la primera linea del service desk. GESTIN DE INCIDENCIAS Vinculacin a incidencias en curso: El sistema deber ser capaz de vincular peticiones de servicio de tipo incidencia a incidentes en vuelo que ya estn abierto dentro del Proceso de Gestin de Incidencias. Reapertura de incidencias: El sistema deber ser capaz de reabrir incidencias en base a encuesta de conformidad no conformes.
MEDIO
3 3
P P
P P
P P
MEDIO MEDIO
Pgina 193 de 219
GESTION DE CAMBIOS.
GESTION DE CONFIGURACIN.
GESTIN DE SERVICIOS
Creacin de cambios: El sistema deber ser capaz de abrir cambios para vincularlo a una peticin de servicio de tipo cambio que no se puede resolver desde la primera linea del service desk. Vinculacin a cambios en curso: El sistema deber ser capaz de vincular peticiones de servicio de tipo cambio a RFC en vuelo que ya estn abiertos dentro del Proceso de Gestin de Cambios. Relacin a elementos de configuracin: El sistema deber de vincularse a los elementos de configuracin definidos en la CMDB en todo momento que se haga referencia a CI's. Apertura de inconsistencias: El sistema dispondr de una utilidad capaz de abrir una notificacin al Gestor de Configuracin en caso de localizar inconsistencias en la CMDB. Esta utilidad puede tener distintos alcances, desde notificar de que falta informacin o es incorrecta a que el CI buscado no se encuentra dentro de la CMDB. Configuracion del SLAs en la resolucion de peticiones de servicio: El sistema ofrecer mecanismos que permitan establecer el tipo de calculo que se hace para generar el SLA asociado a la peticin de servicio. Ej. Ofrecer una matriz configurable de URGENCIAS e IMPACTOS. Notificacin Proactiva y Reactiva del Cumplimiento de SLAs: El sistema ofrecer mecanismos en los que el agente del service desk ser notificado en caso de avance del SLA o de su rotura. Estos mecanismos pondrn ser desde "luminosos" a travs de indicadores dentro del interfaz, como de mensajera a travs de los canales directos de comunicacin.
MEDIO
MEDIO
MEDIO
MEDIO
MEDIO
MEDIO
Pgina 194 de 219
11.1.4 Release Management

AREA TIPO BLOQUE REQUISITOS REQUISITOS GENERALES Iniciar una instancia de lanzamiento (release) dentro del proceso: El portal ofrecer para todos aquellos usuarios que tengan el rol para ello, una entrada para arrancar una entidad nueva de release sobre el proceso de Gestin de Releases. Esta opcin presentar una formulario que permitir seleccionar uno o ms cambios de una o ms RFC's que estn dentro de la FSC. Listar los lanzamientos (releases): El portal ofrecer a los usuarios que tengan tareas pendientes sobre instancias de lanzamientos, un listado de las mismas. El listado deber presentar suficiente informacin para que se pueda reconocer el cdigo del lanzamiento, los cambios asociados, las RFC's vinculadas, los elementos de configuracin que estn involucrados y la tarea solicitada sobre ellos, el estado de la misma y los grupos de resolucin que lo tiene asignado. Tambin se valorar que el listado informe sobre las categoras de CMDB afectadas y que se pueda desde el propio formulario gestionar el agregar ms cambios al lanzamientos. A nivel de usabilidad se valorar que se pueda ver de una forma estructura toda esta informacin. Ej. Un arbol que presente el lanzamiento, las RFC's vinculadas y los cambios seleccionados sobre cada una de esas RFC's. Listar las peticiones de lanzamientos (releases) "Mis Solicitudes": El portal ofrecer a los usuarios que hayan abierto lanzamientos, una opcin para ver el listado de los mismos que han realizado y estn en curso. El listado deber presentar suficiente informacin para que pueda reconocer el cdigo de la peticin, la fecha de apertura y el estado. Este listado deber ofrecer mecanismos de filtrado. Multi-Idioma : El portal ofrecer un mnimo de dos idiomas entre los cuales se podr conmutar. Adems, se valorar el que el sistema pueda ser configurado con idiomas alternativos. Generacin informes : El portal deber ofrecer informes por defecto que resuman el total de peticiones de servicios solicitadas en una escala temporal semanal. Se valorar el que se ofrezcan otras escalas , como por ejemplo: mensuales y anuales. GENERACIN DE INFORMES Repositorio de Contenidos : Se ofrecer un modelo de datos relacionado con las Gestin de Peticiones de Servicio documentado y explotable que permita generar informes a medida u otro tipo de anlisis. Auditoria de accesos: El producto ofrecer log estndar para la gestin de la auditora de accesos del usuario al sistema. DESCRIPCIN REQUISITO NIVEL DE MADUREZ TIPO DE IMPACTO EFECTIVIDAD EFICACIA CALIDAD INF ALCANCE
MEDIO
MEDIO
REQUISITOS FUNCIONALES
PORTAL NICO DE PROCESOS. REQUISITOS GENERALES
MEDIO
ALTO
ALTO
ALTO
MEDIO
Pgina 195 de 219
MTRICAS
KPI's (Key Process Indicators:internos del proceso) - Valores y Grficas en distintas escalas temporales. El sistema ofrecer grficas de evolucin de este tipo de indicadores para el proceso de Release Management. Se valorar el nmero de escalas temporales y la posibilidad de extraer los datos para su anlisis. KGI's (Key Goal Indicators: Objetivos del proceso) - Valores y Grficas en distintas escalas temporales. El sistema ofrecer grficas de evolucin de este tipo de indicadores para el proceso de Release Management. Se valorar el nmero de escalas temporales y la posibilidad de extraer los datos para su anlisis. Mail: El sistema deber ofrecer una comunicacin de entrada y salida con el usuario a travs de correo electrnico. SMS: El sistema deber ofrecer una comunicacin de salida con el usuario a travs de mensajes cortos a movil.
ALTO
ALTO
4 4 4
S S S
P P P
S S S
MEDIO MEDIO MEDIO
CANALES DE COMUNICACIN
Mixto - Mail y SMS: El sistema deber de ofrecer la posibilidad de una comunicacin de salida por mltiples canales simultneamente. Gestin de alertas multicanal: El sistema ofrecer mecanismos de alarmas para llamar la atencin al operador o la usuario. Estos mecanismos se pueden traducir , por ejemplo, en unos indicadores luminosos para alertar de un incumplimiento o prximo incumplimiento de SLA o paneles de alertas u otros mecanismos similares. Mdulo de Lanzamientos (Releases): El proceso ofrecer un formulario para que el rol de release management pueda realizar un registro de un nuevo lanzamiento.
MEDIO
MEDIO
MODULOS DISPONIBLES
Mdulo de Ordenes de Trabajo: El proceso ofrecer un mdulo que permita tratar las distintas tareas a realizar para el lanzamiento en forma de ordenes de trabajo hacia unos destinatarios internos o externos a la organizacin. Se valorar que este mdulo este conectado o facilite la conexin con herramientas de despliegue automtico sobre la infraestructura. Establecimiento de destinatarios : El sistema ofrecer un mecanismo basado en reglas de negocio para que se pueda establecer reglas de destinatarios. Establecimiento de la categorizacin : El sistema ofrecer un mecanismo basado en reglas de negocio para que se pueda establecer reglas que precategoricen del lanzamiento. Disponibilidad de un paquete de reglas de configuracin: Se valorar que el sistema aporte un paquete de reglas que permita realizar a travs de reglas de negocio, otras configuraciones para personalizar el funcionamiento del proceso. Codificacin del lanzamiento (release): El sistema deber de generar un cdigo nico para el lanzamiento creado.
ALTO
ALTO
REGLAS DE NEGOCIO
ALTO
ALTO
BAJO
USABILIDAD
Listas de valores con filtros: El sistema deber ofrecer mecanismos de seleccin basada en listas de valores que permita al usuario agilizar una seleccin tanto nica como mltiple. Se valorar la existencia de filtros para localizar dentro de la lista de valores la informacin.
BAJO
Pgina 196 de 219
Listados con filtros y ordenacin: El sistema ofrecer listados que permita a los usuarios del proceso localizar los registros abiertos de lanzamientos de una forma gil y selectiva. Organizacin de informacin: El sistema deber ofrecer mecanismos de agrupacin de la informacin para facilitar su presentacin al usuario. Ej. Columnas, tarjetas, etc. Relleno automtico/preautomtico de campos sensibles: El sistema ofrecer mecanismos que permitan dada una informacin recolectar informacin de detalle que se presenta en el formulario. Ej. Dada un EC recuperar automticamente su categora en la CMDB, etc. Enlaces a otras entidades: El sistema ofrecer enlaces o links hacia las entidades con las que se relaciona. Estos enlaces ofrecern formularios de solo consulta de la entidad vinculada, presentando toda la informacin de detalle. Facilidad de Implantacin: El sistema tendr que ofrecer unos mecanismos estandar , intuitivos y usables para su puesta en marcha. Deber de ofrecer una documentacin de calidad para tal propsito. Se valorar el que el sistema sea instalable y configurable a travs de asistentes (siempre que sea posible por estar en su mbito de accin). Multi-Catalogo de Servicios : El sistema ofrecer mecanismos que permita configurar la salida de mltiples ctalogos de servicio en base a variables de decisin. Ej. Empresa, Carctersticas del usuario, etc. GESTIN MULTIPLE Multi-Empresa : El sistema ofrecer mecanismos que permintan configurar distintas empresas y que los datos que proporcione sean sensibles a la empresa asociada. Multi-Entidad: El sistema ofrecer mecanismos que permitan conectar con mltiples instancias de repositorio de usuarios. Ej. Varios ActiveDirectory. Este caso es aplicable a organizaciones donde estos repositorios estn distribuidos Ej. Por geogrfia
BAJO
ALTO
BAJO
BAJO
ALTO
MEDIO
MEDIO
MEDIO
PROCESO Crear lanzamientos a partir de cambios en RFC's: El sistema debe de permitir crear lanzamientos a partir de las RFC que estn en la FSC, ofreciendo un formulario que permita seleccionar uno o ms cambios de una o ms RFC's. Completar informacin para su paso a produccin: El sistema ofrecer en su formulario los atributos necesarios para detallar las acciones a realizar para cada una de las tareas solicitadas para los EC involucrados en el lanzamiento. Ejecutar lanzamientos: El sistema permitir la apertura de las tareas necesarias para la correcta implementacin de los cambios incluidos en el lanzamiento Revisin de lanzamiento: El sistema debe permitir la revisin y registro de las conclusiones del PIR, una vez finalizadas todas las tareas asociadas a dicho lanzamiento Marcha atrs parcial o toral: El sistema deber permitir realizar la marcha atrs parcial o total de las tareas (Ordenes de Trabajo) ejecutadas en el lanzamiento, si el resultado del PIR no es satisfactorio
MEDIO
MEDIO
PROCESO
GESTIN DE LANZAMIENTOS (RELEASES)
MEDIO
MEDIO
MEDIO
Pgina 197 de 219
Cierre de lanzamiento: el sistema deber permitir cerrar el lanzamiento, una vez verificado su correcta implantacin, para que los cambios asociados puedan continuar su ciclo de vida. Adems el cierre implicar en su caso la actualizacin de la DSL/DHS correspondiente. Creacin de ordenes de trabajo: Apertura de Ordenes de trabajo a partir del Lanzamiento para asignacin de tareas a cada uno de los grupos de resolucin involucrados Rechazar rdenes de trabajo: Las rdenes de trabajo pueden ser devueltas sin implementar al proceso de Gestin de Lanzamientos. Resolver ordenes de trabajo: Las rdenes de trabajo tienen su propio ciclo de vida con el registro de informacin adecuada en la resolucin, momento en que el Gestor de Lanzamientos revisa el resultado y contina con su proceso. Dar marcha atrs a ordenes de trabajo. Si el resultado de la evaluacin (PIR) es negativo, se puede dar marcha atrs a la Orden de Trabajo. Cerrar ordenes de trabajo: Si el resultado de la evaluacin es negativo, la Orden de trabajo debe quedar cerrada y continuar con el flujo del proceso. Diario de Acciones: El sistema deber de ofrecer un diario de acciones para poder visualizar anotaciones automticas que registra el sistema , as como, permitir introducir nuevas acciones a los roles que tratan el lanzamiento y las ordenes de trabajo asociadas al mismo. Consulta a la CMDB: El sistema ofrecer una consulta a la CMDB para poder que los gestores de lanzamientos analicen actuaciones pasadas. Ej. dado un elemento de configuracin qu RFCs, lanzamientos se han realizado y poder editar dichas peticiones para analizar su resolucin y su diario de acciones o modo en como se acto. Envio de notificaciones: El sistema ofrecer mecanismos automticos de notificacin y mecanismos manuales a travs de un formulario que permita enviar una notificacin a travs de un canal de comunicacin directa con el usuario de mensajes. Plantillas de tareas y subtareas predefinidas: El sistema dispone de una opcin que habilita plantillas para la apertura de Ots, segn determinadas variables: elementos de configuracin afectados, tareas, etc Histrico de lanzamientos: El sistema cuenta con mecanismos de consulta al histrico de lanzamientos y RFCs. Esta herramienta cubre la necesidad de disponer de informacin de entrada para un anlisis de un caso en base a casos pasados.
MEDIO
MEDIO
MEDIO
GESTIN DE ORDENES DE TRABAJO
MEDIO
MEDIO
MEDIO
BAJO
ALTO
UTILIDADES
BAJO
ALTO
ALTO
REQUISITOS DE INTEGRACIN
INTEGRACIN RESTO DE PROCESOS INTEGRACI N RESTO DE PROCESOS GESTIN DE INCIDENCIAS GESTION DE CAMBIOS NA Creacin de lanzamientos: El sistema debe permitir identificar todas las RFCs en curso, susceptibles de ser empaquetadas e implementadas en un mismo lanzamiento. 3 P P P MEDIO
Pgina 198 de 219
Gestin del ciclo de vida: El sistema debe garantizar la coherencia de estados entre el ciclo de vida de las RFCs y los lanzamientos, de forma que no se puedan agrupar RFCs hasta no estar autorizadas y que no se pueda cerrar la RFC, hasta la correcta ejecucin y verificacin del Lanzamiento. Relacin a elementos de configuracin: El sistema deber de vincularse a los elementos de configuracin definidos en la CMDB en todo momento que se haga referencia a CI's. Apertura de inconsistencias: El sistema dispondr de una utilidad capaz de abrir una notificacin al Gestor de Configuracin en caso de localizar inconsistencias en la CMDB. Esta utilidad puede tener distintos alcances, desde notificar de que falta informacin o es incorrecta a que el CI buscado no se encuentra dentro de la CMDB. NA El sistema debe permitir la integracin con herramientas de despliegue de software para automatizar la distribucin e implantacin de cambios.
MEDIO
MEDIO
GESTION DE CONFIGURACIN.
MEDIO
GESTIN DE SERVICIOS DESPLIEGUE DE SOFTWARE
ALTO
Pgina 199 de 219
11.1.5 Incidencias:
AREA TIPO BLOQUE REQUISITOS REQUISITOS GENERALES Presentacin de incidencias segn su criticidad Presentacin de incidencias por el orden de incumplimiento del SLA PORTAL NICO DE PROCESOS Filtrado de las incidencias por grupo asignado Facilitar la creacin, modificacin y cierre de las incidencias Mostrar creador y modificador de cada incidencia Poder realizar un SEGUIMIENTO de las incidencias desde su creacin hasta su cierre el momento actual Consultas o Visiones rpidas sobre la situacin actual de las incidencias abiertas Consultas diversas y visiones puntuales en tiempo real de las incidencias para facilitar el anlisis, la clasificacin, la monitorizacin y el seguimiento por: - Tipo de Incidencia - Fechas - Prioridad y/o Criticidad - Tcnico asignado - CI,s o items - Servicios - Estados El sistema debe permitir la creacin de informes de las incidencias en cada momento customizados segn las necesidades. Disponer de un sistema que permita customizar la extraccin de cualquier campo de detalle de cualquier incidencia de forma que cada usuario pueda obtener la informacin que necesite en cada caso Disponer de un sistema que ofrezca datos totalizados sobre cualquier criterio posible (tipo OLAP o similar) Manual (Telfonico) Web (Intranet/Internet) CANALES DE COMUNICACIN Email Dispositivos moviles MODULOS DISPONIBLES REGLAS DE NEGOCIO El sistema debe tener un boletn online donde se pueda incluir informacin respecto a eventos y incidencias comunes (FAQ) Asignacin a un grupo u otro de las incidencias dependiendo la categora de las mismas. 1 3 2 1 2 3 3 P P S S S P P P S P P P P P P S P S S P S ALTO MEDIO MEDIO MEDIO MEDIO ALTO MEDIO DESCRIPCIN REQUISITO NIVEL DE MADUREZ TIPO DE IMPACTO EFECTIVIDAD EFICACIA CALIDAD INF ALCANCE
GENERACIN DE INFORMES REQUISITOS FUNCIONALES REQUISITOS GENERALES
MEDIO
ALTO
ALTO
MTRICAS
3 2 2 2 2 3 3
P P P P P P P
P P P P P P P
S S S S S S S
ALTO ALTO ALTO ALTO ALTO ALTO ALTO
Pgina 200 de 219
Poder crear NUEVOS TIPOS o Categoras de Incidencias de forma gil y sencilla Poder automatizar la Clasificacin y Categorizacin de Incidencias Restringir la APERTURA de incidencias a las personas autorizadas Restringir la MODIFICACION de incidencias a las personas autorizadas Restringir el CIERRE de incidencias a las personas autorizadas Disponer de PERFILES de ACCESO o mtodo similar para configurar qu acciones sobre incidencias puede realizar cada PERFIL USABILIDAD GESTION MULTIPLE REQUISITOS DEL PROCESO Sistemas de recepcin y creacin de incidencias: - Manual (Telfono). - Web (Intranet/internet). - Email. - Servicios Web. - Interfaces automticas. - Conexin a un sistema CTI. - Eventos de Tiempo, Triggers Registro de incidencias contra diferentes tipos de CIs o Items: - Usuario o Peticionarios (Personas). - Infraestructura (Equipos fsicos). - Servicios. - Software. REGISTRO DE LA INCIDENCIA Informacin mnima por cada incidencia: - Nmero nico incidencia - Fecha y Hora de registro - Detalle del CI o Servicio afectado - Persona de contacto que origina la incidencia, telfono, email - Ubicacin (Direccin) donde se produce la incidencia - Usuario que registra la incidencia en el sistema - Prioridad - Criticidad o Urgencia - Clasificacin (Tipo de Incidencia): varios niveles - Estado de la incidencia - Tcnico o Grupo de Trabajo asignado - Campo de Texto grande - Descripcin del Sntoma - Mtodo de registro en el sistema (manual, email, web, ) - SLA Tiempo de Respuesta asignado - SLA Tiempo de Resolucion asignado Pantalla inicial con las incidencias asignadas a cada grupo ordenadas por diferentes criterios Mostrar las incidencias de cada cliente contrato filtrado.
2 2 2 2 2 2 2 3
P P P P P P P P
P P P P P P P P
S S S S S S S S
ALTO ALTO ALTO ALTO ALTO ALTO ALTO ALTO
ALTO
REQUISITOS DEL PROCESO
ALTO
ALTO
Pgina 201 de 219
Bsquedas para localizar el CI o Servicio para crear la incidencia - Por CI o Servicio - Por n de serie - Por n de inventario - Por n de equipo - Por Cliente, Contrato, Direccion - Por Producto (si procede) Posibilidad de asignacin de una PRIORIDAD Posiblidad de asignacin de un PROPIETARIO Poder asignar por defecto la Prioridad desde el CI o Servicio CATEGORIZACIN IDENTIFICACIN DE LA INCIDENCIA Poder asignar por defecto Prioridad segn el Tipo de la Incidencia (DEFINIR EL CRITERIO PARA PONER LOS VALORES POR DEFECTO, POSIBLIDAD DE MEZCLARLO) Poder asociar una o varias INCIDENCIA a un PROBLEMA o Error Conocido El sistema tiene que poder brindar informacin relacionada al incidente, por ejemplo: - Incidentes abiertos por ese usuario / cliente - Incidentes abiertos por el CI relacionado con el reclamo Poder asignar una incidencia a un Tcnico, Grupo de Trabajo o Empresa externa Poder avisar las asignacin de incidencias a los Tcnicas mediante los siguientes medios: - Email - POPUP - SMS Envio de mensajes de forma automtica (Email, Gsm, Fax, ) a los Tcnicos, Proveedores asignados u otros Destinatarios durante la vida de la incidencia Poder cambiar el estado de la incidencia de forma automtica dependiendo del Tcnico que se le asigne ASIGNACIN DE LA INCIDENCIA Poder pre-asignar Tcnicos a nivel de CI o Servicio contra el que se registra la Incidencia Poder pre-asignar Tcnicos segn el TIPO o Categora de la Incidencia Poder pre-asignar Tcnicos por Clientes o Contratos o Servicios (si es un sistema donde tenemos varios clientes) Poder pre-asignar Tcnicos por Ubicaciones de CI,s o de Servicios Poder ver cuntas veces la incidencia ha sido reasignada o escalada Marcar una incidencia como mal asignada y reasignar la incidencia a su dueo anterior La herramienta debe poder determinar la Prioridad basada en el impacto al servicio, tomando como principal fuente de informacin la CMDB (identificacin de CI) ANLISIS Y RESOLUCIN DE LA INCIDENCIA Poder realizar un anlisis de tendencias basado en incidencias anteriores que ayuden a disgnosticar la solucin
ALTO
2 2 3 3 3
P P P P P
P P P P P
P P P P P
ALTO ALTO ALTO ALTO ALTO
ALTO
ALTO
ALTO
3 3 3 3 3 3 3 3 3
P P P P P P P P P
P P P P P P P P P
P P P P P P P P P
ALTO ALTO ALTO ALTO ALTO ALTO ALTO ALTO ALTO
ALTO
Pgina 202 de 219
Cada incidencia debe tener un AUDIT de todos los detalles de la vida de la incidencia: cundo se ha creado, asignado, cambiado de estado, cerrado, .. Cualquier evento o accin que suceda sobre ella Poder consultar a una Base de Datos de Conocimientos o de Errores Conocidos Poder disponer de un sistema de FAQ,s (incluso para los usuarios que crean incidencias particulares) Self Service Poder devolver la incidencia al originante de la misma, para que pueda dar su conformidad Poder avisar al originante de la misma que la incidencia ha sido resuelta CIERRE DE LA INCIDENCIA El cierre de la incidencia se debe realizar en base a unos cdigos de cierre customizados por el usuario. El sistema debe permitir la bsqueda de incidencias cerradas y consultar el histrico. Debe poder cerrar identificar automticamente todas las incidencias relacionadas con un Problema ESCALADO Y ASIGNACIN DE INCIDENCIAS Poder crear Escalados (Avisos o Notificaciones Automticas) en base a la evaluacin automtica de la informacin de la incidencia: prioridad, criticidad, antigedad, tipo CI o servicio, demoras,
ALTO
3 3 2 2 3 2 3
P P P P P P P
P P P P P P P
P P P P P P P
ALTO ALTO ALTO ALTO ALTO ALTO ALTO
ALTO
INTEGRACIN PROCESOS Creacin de incidencias CENTRO DE SERVICIO. Informes ofrecidos al SERVICE DESK Creacin de incidencias GESTIN DE LA DISPONIBILIDAD REQUISITOS INTEGRACIN Informes de tendencias INTEGRACIN PROCESOS Creacin de incidencias GESTIN DE LA CAPACIDAD Informes de tendencias Se debe poder generar un problema desde la pantalla donde se visualiza el incidente a resolver, pudiendo relacionar con el problema tantas incidencias como se necesite Poder adjuntar documentos a una Incidencia (word, excel, fotos, pruebas, grabaciones, .) Visualizar los cambios asignados a un CI al crear una incidencia Creacin de incidencias GESTIN DE CONTINUIDAD Informes de tendencias Creacin de incidencias GESTIN DE LA SEGURIDAD Informes de tendencias 3 3 4 4 2 4 3 4 3 4 P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P ALTO ALTO ALTO ALTO ALTO ALTO ALTO ALTO ALTO ALTO 3 3 3 P P P P P P P P P ALTO ALTO ALTO
GESTIN DE INCIDENCIAS & PROBLEMAS
GESTIN DE CAMBIOS
Pgina 203 de 219
11.1.6 Problemas:
AREA TIPO BLOQUE REQUISITOS REQUISITOS GENERALES REQUISITOS GENERALES Permitir la creacin, modificacin y cierre de problemas de una manera sencilla. Poder distinguir entre Problemas y Errores Conocidos GENERALES Poder relacionar varias incidencias a un Problema Permitir la creacin de informes customizados para el anlisis de tendencias. Debe permitir la gestin de los problemas y errores conocidos asocindolos unos a otros. REQUISITOS DEL PROCESO La identicacin del problema debe permitir como mnimo el registro de los siguientes campos: o Cdigo nico a cada problema / error conocido / workaround. o Fecha y hora o Estado del problema. o Todos los CIs y servicios afectados o que puedan ser afectados. o Identidad de la fuente y propietario de los CIs afectados o Prioridad y Urgencia del Problema o Campo de Observaciones El el registro del problema el sistema deber permitir acceder a informacin de utilidad, como por ejemplo, todos los problemas relacionados con el CI o servicio indicado afectado Al registrar un problema con su CI asociado, de debe actualizar el estado del CI en la CMDB Al registrarse un problema tiene que permitir establecer un link con sus incidentes origen, y viceversa Al registrarse el problema se tiene que poder distinguir entre distintos tipos (hardware, aplicaciones, etc.) Al crear un Problema se debe poder asociar este a una o varias incidencias. El problema debe poder asignarse por lo menos a una persona, grupo de trabajo o a una empresa tercera ASIGNACIN DEL PROBLEMA Y RESOLUCIN El sistema debera asignar (o sugerir la asignacin) los problemas basndose en informacin como: o Tipo de problema o Servicio Afectado o CI afectado o Prioridad y Urgencia 1 4 3 2 3 P P S S S P S P P P P S P S S ALTO MEDIO MEDIO MEDIO MEDIO DESCRIPCIN REQUISITO NIVEL DE MADUREZ TIPO DE IMPACTO EFECTIVIDAD EFICACIA CALIDAD INF ALCANCE
REQUISISTOS FUNCIONALES
MEDIO
IDENTIFICACIN DEL PROBLEMA
2 2 3 2 4 2
S P P P S P
P P P P S P
S P P S P S
MEDIO MEDIO ALTO ALTO MEDIO ALTO
ALTO
Pgina 204 de 219
El sistema debe contener informacin sobre cuantas veces el problema fue escalado o reasignado. Mostrando tambin el historial de responsables por los que pas. El sistema debe soportar la creacin de una Peticin de Cambio (RFC) y establecer el link desde el registro del problema El sistema debe permitir establecer links del problema con workarounds y problemas conocidos El sistema debe tener facilidades de monotirizacin y seguimiento en tiempo real, que aporte informacin del estado y progreso del problema a lo largo de su ciclo de vida. (esta funcionalidad puede ser especifica de este proceso o comn a varios procesos). El sistema debe proporcionar una estructura de base de conocimiento, donde se almacene la informacin de utilidad para la resolucin de problemas El sistema debe permitir la gestin de permisos para el acceso a esta informacin. Esta informacin debera poder accederse va Web, El sistema debe proveer mecanismos de analisis de tendencias que ayuden a la gestin proacticva de problemas (ej. Tendencia de fallo de un CI especfico) El sistema debe permitir el cerrado automtico de incidentes dependientes de un problema raz que ha sido cerrado El problema no puede ser cerrado antes que sus RFCs relacionados sean cerrados
ALTO
3 3
P P
P P
S S
ALTO ALTO
ALTO
3 3 3 3
P P P P
P P P P
S S S S
ALTO ALTO ALTO ALTO
GESTIN DEL CONOCIMIENTO
3 3
P P
P P
S S
ALTO ALTO
CIERRE DE PROBLEMAS
REQUISITOS INTEGRACIN
INTEGRACIN PROCESOS INTEGRACION PROCESOS Consulta de los problemas de un CI desde el SERVICE DESK CENTRO DE SERVICIO. Consulta del estado de los problemas abiertos 2 2 P P P P P P ALTO ALTO
GESTIN DE CAMBIOS
Creacin de cambios desde un problema para solventarlo
BAJO
Pgina 205 de 219
11.1.7 Niveles de servicio:

AREA TIPO BLOQUE REQUISITOS REQUISITOS GENERALES Informes prediseados: La herramienta debe disponer de informes prediseados cumplimiento de SLA's, alertas generadas y rendimiento de los sistemas semanales, mensuales y anuales. Estos informes deben ser accesibles a los usuarios en funcin de roles o perfiles. Informes a medida: La herramienta debe facilitar unas facilidades de parametrizacin y un modelo de datos relacional y documentado para permitir la generacin de informes a medida. GENERACIN DE INFORMES Auditoria de accesos: La herramienta debe facilitar la obtencin de informacin de accesos al sistemas con informacin completa de usuarios y fechas y horas. Informes de Nivel de Servicio: de disponibilidad, de tiempos de respuesta, de errores, de utilizacin, de cambios, de coste servicio, etc. REQUISITOS DEL PROCESO Informes de Gestin: SLA concluidos, satisfaccin, estadsticas, etc. Mail: La herramienta debe permitir el envo de alertas va mail de forma parametrizable. SMS: La herramienta debe permitir el envo de alertas va SMS de forma parametrizable. Metricas: La herramienta debe permitir obtener mtricas de rendimiento y disponibilidad de los servicios gestionados. Las mtricas sern tanto sobre cumplimiento de objetivos como sobre rendimiento. Accesos: Acceso a consola de usuario va web, consola Ayuda: La herramienta debe proporcionar manuales de ayuda y ayuda on-line al usuario. Multi-idioma: La herramienta debe soportar diferentes idiomas (por lo menos idioma ingles y castellano). Perfiles de usuario: La herramienta debe permitir la definicin de perfiles de usuario. Organizacin de la informacin: La herramienta debe permitir la ejecucin de filtros y ordenacin de la informacin. Dispondr de herramientas de anlisis tipo OLAP. Multi cliente: La herramienta debe permitir una gestin de eventos multicliente. DESCRIPCIN REQUISITO NIVEL DE MADUREZ TIPO DE IMPACTO EFECTIVIDAD EFICACIA CALIDAD INF ALCANCE
ALTO
MEDIO
MEDIO
3 3 3 3 2 3 3 4 1 3
P P S S S S S S S S
S S P P S P P P P P
ALTO ALTO MEDIO MEDIO ALTO MEDIO MEDIO MEDIO ALTO ALTO
METODOS COMUNICACIN
METRICAS
USABILIDAD
GESTIN MULTIPLE.
MEDIO
Pgina 206 de 219
REGLAS DE NEGOCIO
Definicin de reglas de escalado: La herramienta debe soportar la definicin de reglas de escalado que deben poder ser modificables en caliente sin afectar al resto de procesos. El escalado se har mediante workflow con niveles de seguridad y emisin de alertas.
ALTO
REQUISITOS DEL PROCESO Elaboracin de los requisitos de nivel de servicio (SLR): El sistema mantiene el documento de Requisitos de Nivel de Servicio para reflejar las necesidades del cliente y sus expectativas. Entre la informacin soportada se encuentra: la funcionalidad y caractersticas del servicio, la disponibilidad del servicio, la interaccin del servicio con su infraestructura, la continuidad del servicio, los niveles de calidad del servicio, expectativas de rendimiento, tiempo y procedimientos de implantacin del servicio, la escalabilidad del servicio ofrecido, etc. Hojas de especificacin de servicio: El sistema mantiene documentacin interna de carcter tcnico sobre la funcionalidad del servicio as de quin son los responsables del servicio. El sistema permite mantener detalles tcnicos (especificaciones detalladas) de cmo se prestar el servicio, como se implantar el servicio, cuales son los indicadores internos de rendimiento y calidad del servicio, etc. REQUISITOS DEL PROCESO Relaciones entre SLAs, UCs y OLAs: Las hojas de especificaciones describen las diferentes uniones entre SLAs, UCs y OLAs y adems permiten monitorear y realizar la trazabilidad entre las especificaciones internas y externas. El sistema permite un adecuado soporte de los objetivos en cada UCs y OLAs para cada elemento de la cadena de soporte correspondiente a los objetivos marcados en los SLAs. Plan de calidad del servicio: El sistema mantiene un plan de calidad del servicio con informacin detallada de todos los procesos y de cmo hay que realizar la gestin de servicios para que estos se encuentren alineados con los negocios y mantengan unos niveles de calidad adecuados. Acuerdos de nivel de operacin: El sistema soporta OLAs con informacin de los procesos y procedimientos necesarios para ofrecer los niveles de servicio. Contratos de soporte: El sistema soporta UCs con informacin de los procesos y procedimientos necesarios para ofrecer los niveles de servicio. Contratos: El sistema permite la apertura de contratos y del rbol de SLAs que lo constituyen. El sistema soporta informacin como: nombre de la compaa, cliente, lugar, direccin, tipo de contrato, etc. El sistema permite la apertura de contratos con mltiples suministradores de servicio.
ALTO
ALTO
Planificacin de los acuerdos de nivel de servicio
MEDIO
ALTO
ALTO
ALTO
ALTO
Pgina 207 de 219
Elaboracin de un catlogo de servicios: El sistema mantiene un catlogo de servicios con informacin de: servicios ofrecidos, a quien pertenece el servicio, niveles de servicio asociados (usabilidad, disponibilidad, etc), etc. El sistema permite la apertura de un catlogo en un formato de fcil usabilidad y fcilmente entendible por el cliente proporcionando por ejemplo los niveles de servicio asociados que se pueden proporcionar a los clientes. El sistema permite alguna ayuda para elaborar el catlogo de servicios a partir de las especificaciones externas de las hojas espec. Jerarquas catlogo de servicios: El sistema mantiene jerarquas de servicios por diferentes tipologas de servicios. Informacin de detalle relacionada de otros procesos: Dicho catalogo es fcilmente accesible y consultable desde todos los procesos que lo requieren. El sistema permite enlazar los diferentes eventos (incidencias, problemas, RFC, etc) con el catlogo de servicios con el propsito de enriquecer el anlisis y la operatividad del sistema. Gestin de expectativas: El sistema mantendr la funcionalidad necesaria para la gestin de expectativas de los clientes y para mantener al cliente informado de los cambios. Soporte de SLAs: El sistema soporta una descripcin del servicio amplia en los SLAs. Entre la informacin soportada se encuentra: la funcionalidad y caractersticas del servicio, la disponibilidad del servicio, la interaccin del servicio con su infraestructura, la continuidad del servicio, los niveles de calidad del servicio, expectativas de rendimiento, tiempo y procedimientos de implantacin del servicio, la escalabilidad del servicio ofrecido, etc. Tambin se contemplan aspectos no tecnolgicos del servicio como pueden ser: la naturaleza del negocio, aspectos organizativos del cliente y proveedor, datos sobre la organizacin, aspectos culturales del entorno, etc. Soporte de estructura de SLAs: El sistema soporta varios tipos de SLAs tanto los basados en clientes como los basados en servicios como los multi-niveles (nivel de corporacin, nivel de cliente, nivel de servicio, etc). Ayuda apertura y mantenimiento de SLAs: El sistema permite SLAs proforma como ayuda a las negociaciones. El sistema permite la apertura de SLAs en diferentes idiomas para entornos internacionales. El sistema dispone de ayudas para la apertura de SLAs y OLAs a partir de la informacin de los SLRs. El sistema permitir informar sobre los diferentes estados de la vida de un SLA (piloto, inicial, revisado, aprobado, etc). El sistema dispone de seguridad de acceso de acuerdo al nivel de la organizacin al que van destinados. Utilizacin de plantillas de SLAs: El sistema mantiene facilidades para el desarrollo de SLAs tales como plantillas para diferentes tipos de clientes y de servicios. Cada plantilla soporta informacin como descripciones generales, plazos de provisin del servicio, tiempos de respuesta, mtodos de facturacin, planes de contingencia, etc.
ALTO
MEDIO
ALTO
MEDIO
Implantacin de los acuerdos de nivel de servicio
ALTO
MEDIO
MEDIO
MEDIO
Pgina 208 de 219
Soporte de los Acuerdos de Nivel de Seguridad: Soporte de la gestin de seguridad permitiendo el soporte de un nivel de seguridad general bsico y de requisitos adicionales de acuerdo a un anlisis del riesgo. El sistema soporta informacin de anlisis del riesgo. El sistema mantiene listados de personal autorizado, la poltica general de seguridad de informacin, procedimientos de proteccin activos, informacin sobre restricciones sobre copiados de datos, etc. Mantenimiento de objetivos de servicio: Para cada uno de los servicios el sistema mantiene informacin detallada de estos: Trminos, condiciones, tipologa de objetivos de servicio, peso del objetivo de servicio y tratamiento de consolidacin, factores crticos de xito, mtricas y tipos de mtricas, objetivos, umbrales, coste, hitos, herencia de atributos entre servicios. Revisin de los objetivos de servicio: El sistema permite llevar un seguimiento de que los objetivos siguen siendo relevantes (se hace un seguimiento de obsolescencia de objetivos). Mantenimiento de SLAs, UC y OLAs: El sistema permite mantener SLA, UC y OLA pudiendo planificarse revisiones y manteniendo versiones antiguas para analizar su evolucin. Fijacin de hitos: El sistema permite la apertura de hitos para acuerdos as como para objetivos de servicio, que una vez cumplidos disparen diferentes acciones. Se permite disparar las acciones bajo diferentes situaciones: porcentajes de cumplimientos, nmero de veces que sucede un evento, etc. Monitoreo y reporte: El sistema puede almacenar o acceder a mdulos donde se guarde la informacin a monitorizar y reportar (tiempos de respuesta, seguimiento de procedimientos, nmero de incidencias, etc). Con dicha informacin el sistema puede elaborar informes de rendimiento y de alcance de objetivos. Asimismo se dispondr de informacin de costes y de calidad del servicio. La informacin a monitorizar ser tanto la informacin interna como la externa relativa a satisfaccin de los clientes y usuarios. Alertas: El sistema identifica de forma automtica desviaciones frente a los parmetros contractuales y procede al lanzamiento de acciones las cuales pueden ser escaladas en la organizacin de acuerdo a un workflow. Informes de excepcin: El sistema cuenta con informes de excepcin cuando hay rupturas de SLA e informes de operacin con posibilidad de definir la frecuencia de emisin. Seguridad informes: Los informes pueden ser enviados a los usuarios y se permite definir niveles de seguridad de acuerdo a perfiles. Interface grfica: El sistema permite monitorear la informacin con una interface grfica avanzada: cdigos semafricos, diferentes tipos de jerarquas, grficos bidimensionales, etc.
ALTO
ALTO
MEDIO
MEDIO
MEDIO
ALTO
Ejecucin y revisin de los acuerdos de nivel de servicio
MEDIO
ALTO
ALTO
MEDIO
Pgina 209 de 219
Parametrizacin de informes: El sistema tiene herramientas de parametrizacin giles para la emisin de nuevos informes. Estas herramientas permiten definir filas, columnas y rupturas segn diferentes variables y con informacin numrica de SLA y detalles existentes en otros procesos. Indicadores especficos de rendimiento y de objetivos: El sistema proporciona indicadores especficos de rendimiento e indicadores especficos de objetivos: porcentaje de servicios, porcentaje de incumplimiento, costes del servicio, utilizacin de la capacidad, encuestas de satisfaccin del cliente, etc. El sistema permite definir diferentes tipos de indicadores: de valor numrico, de estado, etc. As como diferentes expresiones aritmticas y Booleanas para operar con los indicadores. Reuniones de control: El sistema tiene ayudas para avisar y gestionar las reuniones de revisin de los niveles de servicio. El sistema soporta un seguimiento de los objetivos no cumplidos y de las rupturas de niveles de servicio. El sistema dispone de ayudas para facilitar el seguimiento del cumplimiento de las acciones acordadas en las reuniones precedentes. Para aquellas prdidas de servicio atribuidas a fuentes externas el sistema proporciona ayudas para efectuar un control de los proveedores externos. Elaboracin de programas de mejora del servicio (SIP): El sistema permite soportar programa de mejora de servicio y considera: problemas relacionados con el servicio, nuevas necesidades del cliente, avances tecnolgicos, cumplimiento de los niveles de servicio, implicaciones de una degradacin de la calidad del servicio, evaluacin del rendimiento y capacitacin del personal involucrado, reasignacin de recursos, cumplimientos de OLAs y UCs, percepcin del cliente y usuarios sobre la calidad del servicio, necesidades de formacin adicional, evolucin del catlogo de servicios, etc. El sistema permite la utilizacin de fases e hitos en el SIP. Seguimiento de los programas de mejora del servicio: El sistema permite la definicin de intervalos de revisin de las mejoras. El sistema ayuda a la identificacin de tendencias. El sistema ayuda a la implementacin de acciones ante desviaciones. Penalizaciones y premios por acuerdo: El sistema permite definir penalizaciones y premios ante el cumplimiento o no de un objetivo. Se permiten definir diferentes periodos de revisin as como diferentes tipos de penalizaciones y acuerdos (porcentajes y cantidades). Costes incurridos: El sistema permite llevar un seguimiento de los costes incurridos cuando un objetivo de servicio falla o se incumple. La funcionalidad de costes incurridos permite cambiar el impacto del coste dependiendo del calendario y de otras variables.
ALTO
ALTO
MEDIO
ALTO
ALTO
BAJO
MEDIO
INTEGRACIN PROCESOS
Pgina 210 de 219
CENTRO DE SERVICIO.
Integracin con el centro de servicios: Se intercambia la informacin que maneja el centro de servicio que facilita el trato diario con los clientes. Entre esta informacin estar datos relativos a la percepcin de la calidad, tiempos de solucin, etc Integracin con la gestin de la disponibilidad: Se intercambia la informacin relativa a la gestin de la disponibilidad. Entre esta informacin estar informacin de la disponibilidad acordada y la disponibilidad real. Integracin con la gestin de la capacidad: Se intercambia la informacin relativa a la gestin de la capacidad. Entre esta informacin estar informacin sobre el impacto de un nuevo servicio o la extensin de uno ya existente y si se utilizan los servicios dentro de los lmites acordados. Integracin con la gestin de incidentes y problemas: Se intercambia la informacin relativa a la gestin de incidentes y problemas. Entre esta informacin estar informacin de la calidad de las versiones. Integracin con la gestin de cambios: Se intercambia la informacin relativa a la gestin de cambios. Entre esta informacin estar informacin de los cambios asociados a los servicios y los cambios asociados a los acuerdos. Integracin con la gestin de versiones: Se intercambia la informacin relativa a la gestin de versiones software y hardware. Entre esta informacin estar informacin de la calidad de las versiones. Integracin con la gestin de continuidad del servicio: Se intercambia la informacin relativa a la gestin de continuidad del servicio. Integracin con la gestin de la seguridad: Se intercambia la informacin relativa a la gestin de seguridad recogida en el Acuerdo de Nivel de Seguridad. Integracin con la gestin de configuraciones: El sistema permite integrar el catlogo de servicios con la CMDB pudiendo definir cada servicio como un CI. Se intercambia informacin de lo acordado con la CMDB de: impacto de errores, tiempos de respuesta, nivel de calidad, tiempos de resolucin, etc (el nivel de servicio se permite que se registre contra un servicio CI o contra una componente CI de hardware o software).
MEDIO
GESTIN DE LA DISPONIBILIDAD
MEDIO
GESTIN DE LA CAPACIDAD
MEDIO
INTEGRACIN PROCESOS
GESTIN DE INCIDENCIAS & PROBLEMAS
MEDIO
GESTIN DE CAMBIOS
MEDIO
GESTIN DE VERSIONES
MEDIO
GESTIN DE CONTINUIDAD
MEDIO
GESTIN DE LA SEGURIDAD
MEDIO
GESTIN DE CONFIGURACIONES
MEDIO
Pgina 211 de 219
11.1.8 Configuracin:
AREA TIPO BLOQUE REQUISITOS REQUISITOS GENERALES La herramienta debe cumplir con la certificacin Pink Verify de la compaa Pink Elephant. La CMDB debe soportar la definicin de reglas mediante un "Motor de Reglas" que permita definir y modificar las reglas de forma independiente a la ejecucin el Flujo de Trabajo. El motor de Reglas debe permitir modificar y aplicar las reglas en "caliente". La CMDB debe permitir obtener mtricas de gestin La CMDB deber facilitar la posibilidad de contar con entornos personalizados de consulta segn el perfil que este accediendo y que la informacin pueda consultarse en forma de FAQ (preguntas frecuentes), por ejemplo al consultar soluciones, errores conocidos, workarounds, etc, asociados a un CI La CMDB debe notificar de forma automtica a los afectados de modificaciones de los CIs La CMDB debe disponer de informes pre pre-definidos La CMDB debe contar con manuales de usuario y capacidad de ayuda on on-line, as como la posibilidad de Personalizar los mensajes de ayuda. Usabilidad La CMDB debe tener funcionalidades para la programacin de tareas peridicas. Por ejemplo, la ejecucin de tareas de mantenimiento de los sistemas durante la noche. La herramienta debe soportar idiomas Espaol, Ingls Gestin Mltiple PROCESO GESTION DE CONFIGURACION La CMDB tiene que estar implementada siguiendo un modelo de datos orientado a objetos, donde exista una distribucin jerrquicas de clases. Cada clase hereda los atributos de su clase superior PROCESO GESTION DE CONFIGUR ACIIN La CMDB debe soportar de forma integrada la gestin bajo el concepto "Multi Cliente/Multi Empresa" 2 P P P ALTO DESCRIPCIN REQUISITO NIVEL DE MADUREZ TIPO DE IMPACTO EFECTIVIDAD EFICACIA CALIDAD INF ALCANCE
Reglas de Negocio
ALTO
Mtricas
ALTO
REQUISITOS GENERALES
ALTO
Generacin de informes
4 4 3
P S S
S S S
P P P
ALTO MEDIO MEDIO
3 2 4
P S P
P S P
S S P
MEDIO MEDIO ALTO
Identificacin de CI
ALTO
Pgina 212 de 219
La CMDB debe soportar al menos las siguientes categoras: o Hardware o Software y aplicaciones o Documentacin o Unidades lgicas o Servicios Las personas se pueden considerar CIs incluyndolas en la CMDB, o contemplar una gestin de personal como funcin independiente. Al cambiar atributos de una categora de CI debe replicarse automticamente en todos los CIs que pertenecen a ella El sistema debe proveer facilidades para gestionar los atributos aplicados a los CIs, categoras y subcategoras El sistema debe realizar una distincin clara entre relaciones lgicas y fsicas El sistema debe permitir realizar actualizaciones masivas de atributos El sistema debe proveer una visualizacin grfica de la estructura de CIs, y permitir navegar por sus relaciones (fsicas y lgicas), as como realizar modificaciones a los CIs mediante navegacin Los CIs deben contener referencias al histrico de incidencias, problemas y cambios que les afecten, as como errores conocidos y workarounds asociados Debe ser posible adjuntar referencias a documentacin especfica de los CIs Cuando un CI es afectado por un cambio, problema o incidencia, se debe notificar automticamente a los CIs dependientes del mismo La CMDB debe soportar procedimientos batch de carga de datos de inventario, para aqullos CIs que no estn conectados permanente en red o funcionan en localizacin remota La CMDB debe soportar un proceso de conciliacin que permita incorporar inventarios de distintas fuentes, basandose en reglas definidas por el administrador El Sistema de Configuracin debe soportar funcionalidad de descubrimiento La CMDB debera aportar mecanismos de relacin y enlace con la DSL y otras librerias de SW Auditoria El sistema debe permitir distinguir entre atributos obligatorios versus opcionales de cada CI
ALTO
2 3 2 3
P P P P
P S S P
S S S S
ALTO MEDIO MEDIO MEDIO
ALTO
ALTO
ALTO
ALTO
Control y Estado de CIs
MEDIO
ALTO
4 4 2
P P P
P P P
P P S
ALTO ALTO ALTO
Pgina 213 de 219
El sistema debe conservar el histrico de cada CI, mostrando informacin de utilidad como todos los estados por los que pas, volmen de incidencias, problemas y cambios realizados que le afectaron, etc El sistema debe permitir gestionar derechos de accesos por categora de CI, subcategora, servicio, etc.
ALTO
MEDIO
INTEGRACIN RESTO DE PROCESOS Relacin con Incidencias y SLAs asociados al CI Poder adjuntar documentos a incidencias sobre un CI (word, excel, fotos, pruebas, grabaciones, .) Adjuntar informacin sobre comunicaciones con clientes asociadas a un CI Vinculacin a incidencias en curso. INTEGRACIN RESTO DE PROCESOS REQUISITOS DE INTEGRACION GESTION DE PROBLEMAS GESTIN DEL NIVEL DE SERVICIO Deteccin de CI's causa Raz de problemas Notificacin Proactiva del Cumplimiento de SLAs Notificacin incumplimiento de SLAs Vinculacin a cambios en curso Visualizar los cambios asignados a un CI al crear una incidencia GESTIN DE CAMBIOS Visualizar horarios de mantenimiento, horario de servicios, etc asociados a un CI Facilitar el anlisis de impacto en la disponibilidad de servicio asociado a un CI SERVICE DESK GESTIN DE LA DISPONIBILIDAD GESTIN DE LA CAPACIDAD GESTIN DE VERSIONES GESTIN DE CONTINUIDAD Informes ofrecidos al SERVICE DESK Facilitar informes de tendencias Facilitar informes de tendencias Actualizacin de CIs Facilitar informacin de acuerdos de continuidad de servicio. 3 3 4 3 4 4 3 3 3 3 4 3 4 4 3 4 P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P P ALTO ALTO ALTO ALTO ALTO ALTO ALTO ALTO ALTO ALTO ALTO ALTO ALTO ALTO ALTO ALTO
GESTIN DE INCIDENCIAS
Pgina 214 de 219
11.1.9 Monitorizacin:
AREA TIPO BLOQUE REQUISITOS REQUISITOS GENERALES Informes prediseados: La herramienta debe disponer de informes prediseados cumplimiento de SLA's, alertas generadas y rendimiento de los sistemas semanales, mensuales y anuales. Estos informes deben ser accesibles a los usuarios en funcin de roles o perfiles. Informes a medida: La herrmienta debe facilitar un modelo de datos relacional y documentado para permitir la generacin de informes a medida. Auditoria de accesos: La herramienta debe facilitar la obtencin de informacin de accesos al sistemas. Mail: La herramienta debe permitir el envo de alertas va mail de forma parametrizable. METODOS COMUNICACIN REQUISITOS GENERALES SMS: La herramienta debe permitir el envo de alertas va SMS de forma parametrizable. METRICAS Metricas: La herramienta debe permitir obtener mtricas de rendimiento y disponibilidad de los servicios gestionados. Accesos: Acceso a consola de usuario va web, consola Ayuda: La herramienta debe proporcionar manuales de ayuda y ayuda on-line al usuario. Multi-idioma: La herramienta debe soportar por lo menos idioma ingles y castellano. Perfiles de usuario: La herramienta debe permitir la definicin de perfiles de usuario. Organizacin de la informacin: La herramienta debe permitir la ejecucin de filtros y ordenacin de la informacin. GESTIN MULTIPLE. Multi cliente: La herramienta debe permitir una gestin de eventos multicliente. Definicin de reglas de escalado: La herramienta debe soportar la definicin de reglas de escalado que deben poder ser modificables en caliente sin afectar al resto de procesos. Monitorizacin end-to-end. Percepcin servicio vs usuario GENERACIN DE EVENTOS Monitorizacin de RED Monitorizacin Infraestructura 4 3 1 2 1 2 S P P S P P P P P P P P S P S S P P MEDIO ALTO MEDIO MEDIO MEDIO ALTO DESCRIPCIN REQUISITO NIVEL DE MADUREZ TIPO DE IMPACTO EFECTIVIDAD EFICACIA CALIDAD INF ALCANCE
ALTO
GENERACIN DE INFORMES
MEDIO
3 2
S S
P P
P S
MEDIO MEDIO
USABILIDAD
ALTO
MEDIO
REGLAS DE NEGOCIO ACTIVIDADES DEL PROCESO ACTIVIDAD ES DEL PROCESO
ALTO
3 2 2
P P P
P P P
P P P
ALTO ALTO ALTO
Pgina 215 de 219
Monitorizacin Aplicaciones Monitorizacin Servicios: La herramienta debe facilitar una agrupacin jerrquica de eventos basados servicios. Captura de eventos de diversas fuentes: La herramienta debe poder capturar eventos generados por diversas fuentes, ficheros de log, snmp, comandos Visualizacin de Eventos: La herramienta debe permitir la consolidacin y normalizacin de los eventos. Escalado de Eventos: La herramienta debe permitir la definicin de reglas de escalado de eventos basadas en jerarqua de servicios. Acceso a eventos histricos: La herramienta debe almacenar y facilitar el acceso a eventos cerrados. Correlacin de Eventos: La herramienta debe ser capaz de relacionar eventos de causas comunes. GESTIN DE EVENTOS Grados de criticidad: La herramienta debe diferenciar por lo menos 3 grados de criticidad en los eventos. Roles de Usuario: La herramienta debe permitir la visualizacin de eventos en funcin de Roles de usuario. Horarios de mantenimiento, horario de servicios:La herramienta debe permitir la definicin de horarios de servicio o mantenimiento a nivel de eventos, servicios, aplicaciones o sistemas. Modificacin de umbrales: La herramienta debe permitir la modificacin de umbrales en caliente. Instrucciones de actuacin: La herramienta debe poder relacionar eventos con Instrucciones de actuacin. Acciones de recuperacin automticas o incio manual: La herramienta debe poder ejecutar acciones, tanto automticas como de ejecucin controlada, relacionadas con eventos Insercin de Anotaciones: La herramienta debe permitir la insercin de anotaciones por parte de los usuarios en los eventos. Identificacin de los eventos crticos en los servicios: Escalado jerrquico de eventos. Informacin al usuario: La herramienta debe permitir sistemas de comunicacin al usuarios por evento, servicio o criticidad. Escalado jerrquico: La herramienta debe permitir el escalado jerrquico de los eventos basados en servicios ESCALADO Escalado SLA's: La herramienta debe permitir escalado de eventos basados en cumplimientos de SLA.
2 3
P P
P P
P P
ALTO ALTO
ALTO
MEDIO
ALTO
3 2 3 2
S S P P
P P P P
S P P P
ALTO ALTO ALTO ALTO
ALTO
3 3
S P
P P
S P
BAJO ALTO
MEDIO
ANALISIS-IMPACTO
MEDIO
ALTO
MEDIO
3 4
P P
P P
P S
ALTO ALTO
Pgina 216 de 219
Notificacin de Escalado: La herramienta debe facilitar mtodos de informacin sobre el estado del evento, responsable del evento, evento en tratamiento Cumplimiento SLA: La herramienta debe permitir la generacin de informes basados en SLA. Generacin de Informes de Disponibilidad: La herramienta debe facilitar la generacin de informes de disponibilidad de servicios. INFORMES Generacin de Informes de Rendimiento: La herramienta debe facilitar la generacin de informes de rendimiento Comunicacin de informes: La herramienta debe facilitar el acceso a los informes. Informes de Administracin: La herramienta debe facilitar informes de elementos monitorizados, nodos gestionados, roles definidos. INTEGRACIN DE PROCESOS Insercin de incidencias: La herramienta debe poder interactuar con la herramienta de gestin de incidencias. GESTIN DE INCIDENCIAS REQUISITOS DE INTEGRACIN INTEGRACIN PROCESOS Relaciones entre incidencias y eventos: La herramienta debe poder obtener informacin de la herramienta de gestin de incidencias. Relacin entre Incidencias y la gestin del servicio: La herramienta debe poder interactuar con la gestin de incidencias. Deteccin de CI's causa Raz de problemas. Relacin Eventos y Problemas Horarios de mantenimiento, horario de servicios: La herramienta debe permitir la definicin de horarios de mantenimiento y servicios. Facilita el anlisis de impacto en la disponibilidad de servicio. GESTIN DE CONFIGURACIN Monitorizacin de CI Agrupacin de CI Escalado jerrquico del evento en los servicios. Notificacin Cumplimiento de SLAs
MEDIO
ALTO
ALTO
3 4
S P
P S
P P
ALTO MEDIO
MEDIO
ALTO
ALTO
4 3 4 2 4 2 2 3 3
S P S P P S S P P
P P P P P P P P S
P S S P P P S P P
ALTO MEDIO ALTO ALTO MEDIO ALTO ALTO ALTO ALTO
GESTION DE PROBLEMAS
GESTIN DE CAMBIOS
GESTIN DE SERVICIOS
Pgina 217 de 219
13.2.3 ndice de figuras:

Figura 1. Elementos clave en la inversin TI.. Figura 2. Puntos clave en los servicios TI.... Figura 3. Ciclo de vida ITIL v3 Figura 4. Creacin del producto. Figura 5. Grafico sobre el estado de proyectos finales.......... Figura 6. Representacin de relacin de requisitos en Doors Telelogic Figura 7. Representacin del aspecto de CaliberRM Figura 8. Representacin de las caractersticas de un requisito en REM.. Figura 9. Representacin de las caractersticas de un requisito en OSRMT.. Figura 10. Representacin de las caractersticas de un requisito en Gatherspace. Figura 11. Representacin de requisitos en WebITSM.. Figura 12. Jerarqua de requisitos en WebITSM.. Figura 13. Accesos a WebITSM Figura 14. Informes de salida en WebITSM Figura 15. Encaje de componentes de las aplicaciones Web ASP.Net. Figura 16. Diagrama caso de uso Usuario Registrado y No Registrado. Figura 17. Diagrama caso de uso Administrador Figura 18. Diagrama caso de uso Jefe de proyecto Figura 19. Diagrama caso de uso Usuario Figura 20. Diagrama caso de uso Gestionar proyecto (Administrador).. Figura 21. Diagrama caso de uso Gestionar Proyectos (Jefe de proyecto). Figura 22. Diagrama caso de uso Gestionar Proyectos (Usuario) Figura 23. Diagrama caso de uso Gestionar Carpeta Figura 24. Diagrama caso de uso Gestionar Requisitos. Figura 25. Diagrama caso de uso Gestionar usuarios (Administrador) Figura 26. Diagrama caso de uso Gestionar usuarios.. Figura 27. Diagrama caso de uso Gestionar rol (Administrador). Figura 28. Diagrama caso de uso Gestionar Informe de trazabilidad.. Figura 29. Diagrama caso de uso Gestionar Informe comparativo Figura 30. Diagrama caso de uso Glosario de trminos.... Figura 31. Diagrama caso de uso Ayuda Figura 32. Integracin entre los componentes del Modelo de arquitectura de tres capas.. Figura 33. Diagrama de secuencia del Modelo de arquitectura de tres capas.. Figura 34. Diagrama de actividad Iniciar sesin en proyecto. Figura 35. Diagrama de actividad Aadir proyecto Figura 36. Diagrama de actividad Modificar proyecto Figura 37. Diagrama de actividad Borrar proyecto... Figura 38. Diagrama de actividad Asignar/Borrar usuario en proyecto..
Pgina 218 de 219
Pg. 7 Pg. 14 Pg. 19 Pg. 23 Pg. 25 Pg. 30 Pg. 31 Pg. 34 Pg. 35 Pg. 37 Pg. 51 Pg. 52 Pg. 53 Pg. 54 Pg. 57 Pg. 61 Pg. 62 Pg. 65 Pg. 67 Pg. 69 Pg. 71 Pg. 73 Pg. 74 Pg. 76 Pg. 79 Pg. 80 Pg. 82 Pg. 83 Pg. 84 Pg. 85 Pg. 87 Pg. 110 Pg. 111 Pg. 112 Pg. 113 Pg. 114 Pg. 115 Pg. 116
Figura 39. Diagrama de actividad Aadir carpeta.. Figura 40. Diagrama de actividad Modificar carpeta Figura 41. Diagrama de actividad Borrar carpeta.. Figura 42. Diagrama de actividad Incorporar requisitos a carpeta. Figura 43. Diagrama de actividad Realizar bsqueda de requisito. Figura 44. Diagrama de actividad Aadir requisito Figura 45. Diagrama de actividad Modificar requisito Figura 46. Diagrama de actividad Borrara requisito. Figura 47. Diagrama de actividad Aadir/Borrar relacin entre requisitos Figura 48. Diagrama de actividad Modificar datos personales.... Figura 49. Diagrama de actividad Borrar usuario..... Figura 50. Diagrama de actividad Modificar usuario... Figura 51. Diagrama de actividad Borrar usuario Figura 52. Diagrama de actividad Modificar rol.. Figura 53. Diagrama de actividad Visualizar informe de trazabilidad.. Figura 54. Diagrama de actividad Visualizar informe comparativo Figura 55. Diagrama de actividad Aadir un trmino en glosario.. Figura 56. Diagrama de actividad Modificar un trmino en glosario Figura 57. Diagrama de actividad Borrar un trmino en glosario Figura 58. Diagrama de actividad Consultar ayuda Figura 59. Diagrama conceptual 1. Figura 60. Diagrama conceptual 2. Figura 61. Diagrama conceptual 3. Figura 62. Diagrama base de datos.. Figura 63. Diagrama de estados (Estados de requisitos).. Figura 64. Datos de estimacin COCOMO II.. Figura 65. Datos de estimacin..... Figura 66. Datos de estimacin fase planificacin y requisitos. Figura 67. Datos de estimacin fase diseo Figura 68. Datos de estimacin fase programacin. Figura 69. Datos de estimacin fase integracin y pruebas Figura 70. Recursos humanos.. Figura 71. Recursos materiales... Figura 72. Diagrama Project planificado.... Figura 73. Diagrama Project real.. Figura 74. Datos de estimacin..
Pg. 117 Pg. 118 Pg. 119 Pg. 120 Pg. 121 Pg. 122 Pg. 123 Pg. 124 Pg. 125 Pg. 126 Pg. 127 Pg. 128 Pg. 129 Pg. 130 Pg. 131 Pg. 132 Pg. 133 Pg. 134 Pg. 135 Pg. 136 Pg. 137 Pg. 139 Pg. 141 Pg. 142 Pg. 143 Pg. 169 Pg. 170 Pg. 170 Pg. 171 Pg. 171 Pg. 172 Pg. 172 Pg. 173 Pg. 174 Pg. 176 Pg. 178
Pgina 219 de 219

PFC Elena Sanchez Pescador

Cargado por

Copyright:

Formatos disponibles

PFC Elena Sanchez Pescador

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

PFC Elena Sanchez Pescador

Cargado por

Copyright:

Formatos disponibles

ANLISIS E IMPLANTACIN DE UNA HERRAMIENTA DE GESTIN DE REQUISITOS PARA LA GESTIN DE SERVICIOS BASADO EN LA FILOSOFIA DE ITIL V3, CMMI DE SERVICIOS

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

2. Gestin de Servicios TI... Pg. 14

3. Herramientas de gestin de requisitos Pg. 23

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

4. Principales caractersticas de la herramienta a disear....... Pg. 49

5. Entorno tcnico de trabajo..... Pg. 55

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

Pg. 105 Pg. 106 Pg. 106 Pg. 107

7. Diseo.... Pg. 109

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

10. Referencias.. Pg. 181 11. Anexos

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

Figura 1. Elementos clave en la inversin de TI

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

1.2. Objetivos del proyecto

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

1.3 Estructura de la memoria.

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

1.4 Definiciones, acrnimos y abreviaturas.

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

Figura 2. Puntos clave en los servicios TI

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

2.2 ITIL: Conceptos y procesos fundamentales.

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

2.3 Ciclo de vida del servicio.

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

Figura 3. Ciclo de vida ITIL v3

2.4 CMMI para servicios:

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

2.5 Integracin CMMI para servicios con ITIL:

2.6 MOF (Microsoft Operations Framework):

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

Herramientas de gestin de requisitos

3.1. La Gestin de Requisitos

Figura 4. Creacin del producto

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

3.2 El cliente frente a los requisitos.

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

3.3 Por qu utilizar estas herramientas?

Figura 5. Grafico sobre el estado de proyectos finales

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

3.4 Caractersticas generales de las Herramientas.

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

3.5 Anlisis detallado de las herramientas.

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

Figura 6. Representacin de relacion de requisitos en Doors Telelogic

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios

Figura 7. Representacin del aspecto de CaliberRM

Anlisis e implantacin de una herramienta de gestin de requisitos para la gestin de servicios