I
Facultad 8.
Título: “ Análisis del Módulo de Gestión de Alcance del Sistema Integral de Portafolios de Proyectos”.
Trabajo de Diploma para optar por el título de Ingeniero en Ciencias Informáticas
Autor: Yanitza Rodríguez Serrano.
Tutores: Ing. Adisleydis Rodríguez Pino.
Ing. Jenny Infante Frometa.
Ciudad de La Habana, Cuba
Junio 2010.
”...el futuro de nuestra Patria, tiene que ser, necesariamente, un futuro de hombres de ciencia... ”
Fidel
III
A mis abuelos maternos y mi mamá que son mi razón de ser, sin ellos hubiera sido imposible llegar donde estoy hoy.
Los quiero con la vida, son lo más importante que tengo y a ustedes va dedicado este momento tan importante.
Yany.
III
Muchas han sido las personas que a lo largo de estos años han contribuido a que hoy se esté realizando uno de mis grandes sueños.
Primeramente agradecer a mis abuelos Maira y José Ángel y a mi mamá, a ellos muchísimas gracias por quererme tanto y haber hecho hasta lo imposible porque yo sea hoy la mujer que soy.
A mis tíos
A Susana que la quiero como una madre y siempre he podido contar con su apoyo.
A mis amigos con los que he compartido alegrías y tristezas especialmente Kenia, Dania, Bety.
A Carlos Manuel por su gran ayuda durante los primeros 4 años de la carrera.
A mis tutoras que siempre estuvieron al tanto del trabajo, muchísimas gracias.
Agradecer a la revolución por darme la oportunidad de estudiar en esta universidad que no solo me ha formado como profesional, sino como persona.
Por último agradecer a los que de una forma u otra han contribuido a lo largo de todo este tiempo, a mis compañeros de aula, profesores y a todos los que se han cruzado en mi vida y de una forma u otra han puesto su granito de arena. De todo corazón muchísimas gracias.
Los quiero mucho Yany.
IV Declaro ser autora del presente trabajo de Diploma y reconozco a la Universidad de las Ciencias
Informáticas los derechos patrimoniales de la misma.
Para que así conste firmo la presente a los __días del mes de del año 2010.
Yanitza Rodríguez Serrano Ing. Adisleydis Rodríguez Pino Ing. Jenny Infante Frometa --- --- --- Firma del autor Firma del tutor Firma del tutor
V Título: “Análisis del Módulo de Gestión de Alcance para el desarrollo de un Sistema Integral para la Gestión de Portafolios de Proyectos”.
Autor: Yanitza Rodríguez Serrano.
Los tutores del presente Trabajo de Diploma consideran que durante su ejecución el estudiante mostró las cualidades que a continuación se detallan.
Por todo lo anteriormente expresado consideramos que el estudiante está apto para ejercer como Ingeniero en Ciencias Informáticas; y propongo que se le otorgue al Trabajo de Diploma la calificación de ___puntos.
__ días del mes de _ del año 2010. _________________________
Yanitza Rodríguez Serrano
VI La Gestión de Portafolios de Proyectos es una función de administración de gran importancia en las empresas, para lograr resultados eficientes y concretar las estrategias trazadas, también para poder tener claridad de las prioridades de los proyectos y que éstos no sufran retrasos en su ejecución. El presente trabajo de diploma propone el Análisis del Módulo de Gestión de Alcance del Sistema Integral de Portafolios de Proyectos, debido a que actualmente no se cuenta en la universidad con una herramienta de este tipo que facilite a los usuarios ayuda a la hora de la toma de decisiones. A raíz de esta propuesta y con su seguimiento, se pretende lograr un sistema que al ser implementado asegure gestionar de forma íntegra los portafolios de proyectos garantizando la entrega a tiempo de los productos con la calidad requerida.
Palabras Claves: Gestión de Portafolios, Gestión de Alcance.
VII
Introducción Parcial ... 5
1.1. Gestión de Portafolios de Proyectos ... 5
1.2. Gestión de Alcance ... 6
1.2.1. Principales exponentes de la Gestión de Alcance ... 6
1.2.2.1. MSF ... 6
1.2.2.2. IPMA ... 8
1.2.2.3. PMBOK ... 8
1.3. Gestión de Alcance en la UCI ...13
1.4. Sistemas informáticos relacionados con la Gestión de Portafolios de Proyectos...13
1.5. Metodología y herramientas para la modelación de software ...17
1.5.1. Metodología ...17
1.5.2. Lenguaje de Modelado ...18
1.5.3. Herramienta CASE ...18
1.6.1. Características de los requerimientos ...20
1.6.2. Requerimientos funcionales y no funcionales...20
1.6.2.1. Categoría de los requerimientos no funcionales ...21
1.6.3. Captura de requerimientos ...23
1.7. Patrones de Caso de Uso ...24
1.7. Conclusiones ...25
Introducción ...27
2.1 Propuesta del sistema ...27
2.1 Modelo de dominio ...27
2.1.1. Diagrama conceptual del modelo de dominio. ...29
2.2. Especificación de los requerimientos de software. ...29
2.2.1 Técnicas utilizadas para la elicitación de requerimientos ...30
VIII
2.2.3. Requerimientos no funcionales. ...38
2.3. Definición de los Casos de Uso. ...40
2.3.2. Diagrama de Casos de Uso del Sistema. ...42
2.3.3. Descripción de los Casos de Uso del sistema. ...46
Conclusiones ...50
Introducción ...51
3.1. Técnicas de validación de requerimientos ...51
3.2. Estrategias de validación ...52
3.3. Pruebas. ...62
3.3.1. Pruebas de sistemas. ...63
3.4. Conclusiones...78
Conclusiones ...79
Recomendaciones ...80
Referencias Bibliográficas ...81
Bibliografía ...83
Anexos ...85
Glosario de términos ...86
IX
Anexo 1: Entrevista realizada a especialistas de la Oficina de Gestión de Proyectos UCI... 85
Anexo 2: Diagrama de paquetes ... 85
Índice de Tablas Tabla 1: Comparación de precios de herramientas de GPP. ... 16
Tabla 2: Comparación entre Project.net, Redmine. Fuente Servicio de Gestión de Proyectos... 17
Tabla 3: Descripción de los actores del sistema ... 41
Tabla 4: Descripción del Caso de Uso Gestionar Portafolio ... 50
Tabla 5: Resultados de la revisión a las ERS... 54
Tabla 6: Resultado de la lista de chequeo ... 58
Tabla 7: Aplicación de métricas ... 60
Tabla 10: Resultado de la matriz de trazabilidad ... 62
Tabla 11: Diseño del Caso de Prueba Gestionar portafolio ... 68
Tabla 12: Sección Adicionar Portafolio ... 73
Tabla 13: Sección Modificar Portafolio ... 77
Tabla 14: Sección Eliminar Portafolio... 78
X
Figura 1 Descripción General de la Gestión del Proyectos. Fuente PMBOK ... 12
Figura 2: Modelo de dominio ... 29
Figura 3: Diagrama del Paquete de Planificación ... 42
Figura 4: Diagrama de Casos de Uso del paquete Planeación Estratégica ... 42
Figura 5: Diagrama del Paquete de Reporte ... 43
Figura 6: Diagrama de Casos de uso del Paquete de Reportes ... 43
Figura 7: Diagrama del Paquete de Reportes ... 43
Figura 8: Diagrama de Casos de Uso del Paquete de Funciones Básicas ... 44
Figura 9: Diagrama del Paquete de Funcionalidades Generales ... 44
Figura 10: Diagrama de Casos de Uso del Paquete de Funcionalidades Generales... 45
Figura 11: Diagrama del Paquete de Configuración ... 45
Figura 12: Diagrama de Casos de Uso del Paquete de Configuración ... 45
Figura 13: Resultado de las revisiones ... 53
Figura 14: Representación de los valores aportados por cada factor de calidad aplicado ... 61
1 Introducción
El desarrollo tecnológico está produciendo cambios significativos en la estructura económica y social a nivel mundial, debido a que cada vez se hace más necesaria la creación de nuevos softwares y sistemas informáticos, por lo que las empresas asumen el gran reto de trabajar en un sinnúmero de proyectos con un gran volumen de información. Para garantizar una correcta organización en el desarrollo del proyecto se lleva a cabo la Gestión de Proyectos, ésta ofrece una serie de ventajas una vez que está implantada como cultura corporativa en las empresas. Un ejemplo de esto es que posibilita respuestas rápidas a demandas cambiantes y proporciona la capacidad para adaptarse al cambio. Sin dudas el uso de la Gestión de Proyectos ha mejorado sustancialmente los resultados de los proyectos. A pesar de tener esta relevancia, a la hora de gestionar un conjunto de proyectos activos esta tarea se hace engorrosa y hasta puede llegar a ser abrumador el trabajo. Para resolver estas dificultades en los últimos años se está llevando a cabo la Gestión de Portafolios de Proyectos conocido como PPM (Project Portfolio Management).
La Gestión de Portafolios de Proyectos es el manejo centralizado de uno o más portafolios y envuelve la identificación, priorización, autorización, gestión y control de proyectos, programas y otros trabajos relacionados, para alcanzar las metas estratégicas de negocio (PMI, 2004).Se puedeconsiderar la Gestión de Portafolio como un proceso de decisión dinámico donde un conjunto de proyectos se evalúan, seleccionan, priorizan y revisan de acuerdo con una estrategia trazada. Para obtener una buena Gestión de Portafolios es de vital importancia realizar una correcta Gestión de Alcance, que es donde se delimitan los límites de los proyectos y se decide el trabajo que es necesario realizar, ésta incluye todo el negocio, además, los cambios que se realizan son asociados a las estrategias de las empresas. También comprende las actividades orientadas a garantizar el cumplimiento de las tareas necesarias para lograr los objetivos del proyecto.
Para la Gestión de Portafolios de Proyectos existen diferentes herramientas tales como: Microsoft Office Enterprise Project Management (EPM), Primavera Enterprise Project Portfolio Management, Rational Focal Point, VeraxSistems entre otras.
En el Centro de Tecnología de Gestión de Datos (DATEC) se desarrollan un número de proyectos productivos de gran importancia no solo para la Universidad de las Ciencias Informáticas (UCI) sino también para el país. El centro está estructurado por líneas de producción, en las cuales se necesita gestionar de forma integral todos los proyectos que se desarrollan puesto que el tiempo, recursos y costos están estrechamente asociados. También en la empresa ALBET (Empresa de Ingeniería y Sistemas) donde se
2 gestionan un gran número de proyectos se hace necesario contar con una herramienta que facilite el trabajo.
Así como en la oficina de Gestión de Proyectos de la UCI que tiene como propósito dar soporte a los procesos de Planificación, Monitoreo y Control de las Unidades Productivas de la Universidad, para llevar el seguimiento y control del estado de los proyectos.
Actualmente esta tarea se ve afectada debido a que las herramientas antes mencionadas no pueden ser utilizadas, una de las razones es el elevado costo del producto y sus licencias, un ejemplo de esto se evidencia en la herramienta Enterprise Project Management cuyo precio es 999.95 (USD), además del costo de la licencia cuyo saldo asciende a 59.95 (USD) (Microsoft, 2010), otra de las razones por lo que se hace complicada la adquisición de productos de este tipo es el bloqueo económico al que el país está sometido.
Por todo lo expresado se hace necesario contar con una herramienta propia que permitan un mejor control de las unidades productivas, mayor organización y disciplina del trabajo de modo general.
La inexistencia de un sistema automatizado que soporte el proceso de Gestión de Alcance de Portafolios de Proyectos en la Universidad está provocando que los proyectos se planifiquen de forma independiente, debido a la falta de integración de la información de los mismos, esto impide la capacidad de analizar eficientemente la totalidad del portafolio puesto que resulta más amplio el alcance y los cambios que se realizan son asociados a las estrategias de las empresas. Debido a lo antes mencionado se hace necesario contar con una plataforma que permita monitorear de forma continua los proyectos y portafolios para asegurar que se adopten diversas acciones claves para la toma de decisiones, garantizando la culminación exitosa de los proyectos, y que el producto suministrado sea adecuado a las necesidades y especificaciones.
Problema a resolver
¿Cómo definir de manera eficiente los límites de los proyectos y el trabajo que es necesari o realizar para un Portafolio de Proyectos?
Objeto de estudio
Gestión de Portafolios de Proyectos.
Objetivo general
Desarrollar el análisis del Módulo de Gestión de Alcance del Sistema Integral para la Gestión de Portafolios de Proyectos posibilitando su posterior diseño e implementación.
3 Objetivos Específicos
Construir el Modelo de Dominio.
Identificar los requerimientos funcionales y no funcionales del Módulo de Gestión de Alcance.
Obtener el Modelo de Casos de Uso del Sistema.
Validar los resultados obtenidos.
Campo de acción
Gestión de Alcance de Portafolios de Proyectos.
Idea a defender
Si se realiza un correcto análisis del Módulo de Gestión de Alcance, del Sistema Integral para la Gestión de Portafolios de Proyectos, éste podrá ser diseñado he implementado, contribuyendo así a la mejora en los procesos de definición de los límites en un conjunto de proyectos asegurando el cumplimiento de los compromisos contraídos con los clientes.
Tareas de la investigación
1. Selección y revisión bibliográfica de la Gestión de Portafolios de Proyectos, específicamente la Gestión de Alcance.
2. Procesamiento y evaluación de la información obtenida.
3. Estudio e identificación de las herramientas utilizadas actualmente para la Gestión de Portafolios de Proyectos.
4. Realización de las actividades del flujo de análisis.
5. Validación de los requisitos del sistema mediante técnicas y métricas.
Métodos científicos de la investigación
En el presente trabajo se utilizaron diferentes métodos y técnicas tales como:
- Histórico – Lógico: Este método permitió hacer un estudio de la Gestión de Portafolios de Proyectos, y centrarse específicamente en la Gestión de Alcance.
4 - Analítico – Sintético: Con la utilización de este método resultó menos complejo el análisis de la Gestión de Alcance, sintetizando las características fundamentales posibilitando el resultado del trabajo.
- Hipotético – Deductivo: Este método fue de gran ayuda porque hizo posible elaborar y plantear una idea a defender del trabajo.
- Análisis Bibliográfico: Esta técnica facilitó el trabajo porque permitió recopilar la bibliografía necesaria para el posterior desarrollo del trabajo.
- Observación: Ayudó a tener una visión del problema existente con relación a la Gestión de Portafolios de Proyectos.
Novedad, actualidad e importancia del trabajo
La presente investigación representa un aporte no solo para la Universidad sino para el país porque una vez desarrollada su implementación se contará con una herramienta propia, que representará un gran ahorro económico para el país, también, facilitará el cumplimiento de los compromisos contraídos con el cliente en un tiempo establecido y con la calidad requerida. Además, un sistema de este tipo en un ambiente de negocios competitivo logrará la habilidad de organizar efectivamente los recursos y actividades y así establecer un alineamiento estratégico. Las organizaciones administrarán sus actividades y procesos como proyectos, en esencia proyectarán su negocio, para monitorear el desempeño desde más cerca y tomar mejores decisiones de negocio sobre el trabajo total de su portafolio, planeando y siguiendo los proyectos con claridad y precisión. Por lo que se podrá dar seguimiento a los proyectos con precisión y las organizaciones responderán con mayor agilidad a las demandas de un entorno de negocios que cambia constantemente. Contar con una herramienta de este tipo marcará la diferencia entre tener éxito o apenas sobrevivir.
Estructura de la Tesis
El presente trabajo consta de 3 capítulos estructurados de la siguiente forma: el capítulo 1 contiene conceptos importantes acerca de Gestión de Portafolios de Proyectos y Gestión de Alcance para el mejor entendimiento del tema; también se hace un estudio de los principales exponentes de la Gestión de Alcance, herramientas existentes que soportan la Gestión de Portafolios, ingeniería de requerimientos y patrones de diseño de Casos de Uso. En el capítulo 2 se define la propuesta de solución para el sistema. En el capítulo 3 se expone el análisis de los resultados obtenidos.
5 Introducción
En el presente capítulo se realiza un estudio de la Gestión de Portafolios de Proyectos específicamente la Gestión de Alcance, además se hace mención de diferentes conceptos clave para el mejor entendimiento del tema, así como máximos exponentes en la materia y los sistemas informáticos relacionados. También se hace un análisis de la metodología, el lenguaje y la herramienta a usar. Finalmente, se pretende abordar aspectos relacionados con la Ingeniería de Requerimientos y los patrones de Caso de Uso a utilizar.
1.1. Gestión de Portafolios de Proyectos
Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único (PMI, 2004).
Un programa es un grupo de proyectos relacionados, que se administran de manera coordinada para obtener beneficios (Duncan, 1996).
Un portafolio es una colección de proyectos, programas y otros trabajos que se agrupan para facilitar la gestión eficaz de los que trabajan para alcanzar los objetivos estratégicos del negocio. Los componentes del portafolio son cuantificables, es decir, que pueden ser medidos, clasificados, y priorizados (Duncan, 1996).
La Gestión de Portafolios se centraliza en gestiones de uno o más portafolios, que incluyen la identificación, priorización, autorización, administración, y control de los proyectos, programas y otros trabajos conexos, para archivos específicos de los objetivos empresariales estratégicos. Hay muchos tipos y variedades de la Gestión de Portafolios. Esta norma no trata de abordar todos los tipos de la Gestión de Portafolios, en cambio, se centra en la Gestión de Portafolios de Proyectos (Duncan, 1996).
La Gestión de Portafolios de Proyectos es una función de administración de gran importancia en las empresas para lograr resultados eficientes y concretar las estrat egias trazadas, también para poder tener claridad de las prioridades de los proyectos y que éstos no sufran retrasos en su ejecución. Esta tarea requiere un esfuerzo disciplinado para asegurar el éxito.
Resulta de gran importancia tener en cuenta la Gestión de Alcance para garantizar la realización de proyectos exitosos, es por ello que se hace necesario realizar un estudio de la evolución y principales exponentes de la Gestión de Alcance.
6 1.2. Gestión de Alcance
La Gestión del Alcance del Proyecto es el área que incluye los procesos necesarios para asegurar que el proyecto contenga todo el trabajo requerido, y solo el trabajo requerido, para completar el proyecto satisfactoriamente. La Gestión del Alcance del Proyecto se relaciona principalmente con la definición y el control de lo que está y no está incluido en el proyecto (PMI, 2004).
La Gestión de Alcance es la encargada de definir la totalidad del trabajo necesario para concluir el proyecto, el conjunto de requerimientos a alcanzar por el producto, y la suma de tareas para un fin común. Una detallada definición del alcance o área de competencia garantiza destinar solo la justa cantidad de esfuerzos y recursos para obtener lo que se quiere. Constituye entonces un proceso crítico para el desarrollo de cualquier proyecto. Para la Gestión de Alcance existen diferentes exponentes a nivel mundial que proponen guías y modelos para realizar dicha Gestión de Alcance.
1.2.1. Principales exponentes de la Gestión de Alcance
A la hora de hablar de Alcance debe tenerse en cuenta los principales exponentes que existen para este fin, tal es el caso de MSF (Microsoft Solutions Framework), el IPMA (International Project Managenet Association) y Project Management Institute (PMI).
1.2.2.1. MSF
El marco de desarrollo de soluciones de Microsoft (MSF) es una serie de conceptos, modelos y prácticas de uso que controlan la planificación, el desarrollo y la gestión de proyectos tecnológicos. Se centra en los modelos de procesos y equipos. MSF propone 5 fases de desarrollo: Visión y alcance, planificación, desarrollo, estabilización y despliegue. Presenta además distintos modelos y disciplinas sobre los que basa su aplicación. Entre estas últimas se encuentra la Disciplina de Gestión de Proyectos que es el área de conocimientos que MSF define para la aplicación de habilidades, técnicas y herramientas en pos de gestionar la vida del proyecto. La Gestión de Alcance es uno de los procesos incluidos dentro de la Disciplina de Gestión de Proyectos. La aprobación del alcance es el hito de la primera fase definida por MSF. Este proceso tiene como propósito asegurar que el proyecto identifique todo el trabajo necesario para completar una solución y que no se extravíe fuera de las actividades del alcance sin una previa revisión y aprobación (Microsoft, 2002).
A continuación se xponen los diferentes sub-procesos que propone MSF:
7 Alcance en la fase inicial
Durante la fase de Visión y alcance el equipo de desarrollo debe generar una perspectiva del proyecto independiente de la solución a la que se deba llegar, mediante la definición de los objetivos generales así como sus principales restricciones y asunciones. El establecimiento de una primera versión del alcance debe escribirse a partir de este documento de Visión y alcance el cual deberá ser aprobado tanto por el equipo de desarrollo como por los clientes e interesados, esto es un requerimiento indispensable para la continuación del proyecto. Durante esta fase el alcance es definido en términos generales como un primer acercamiento a este ya que en fases posteriores se definirá con mayor detalle según la información que se vaya obteniendo (Microsoft, 2002).
Definición del alcance
Este sub-proceso debe desarrollarse en la fase de Planificación. Como trabajo principal debe subdividirse el proyecto en partes más pequeñas y manejables. En MSF, la creación de la Estructura de Desglose de Trabajo (EDT) es un ejercicio de colaboración con participación de todos los equipos. Cada uno es el principal responsable de la definición de los detalles del trabajo en sus respectivas áreas. En proyectos más grandes, sub-equipos (por funciones y/o características) pueden necesitar la técnica de lluvia de ideas por separado para definir el trabajo necesario. Cada equipo documenta los resultados de la sesión de lluvia de ideas y en conjunto todo contribuye a los resultados del equipo general. Esto se sincroniza entonces en una EDT (Microsoft, 2002).
Control de cambios del alcance
Otro proceso es el Control de cambios del alcance el cual, una vez definido y estructurado el alcance, se encarga de gestionar los cambios que puedan generarse o ser necesarios durante el desarrollo del proyecto;
siempre con la previa aprobación entre el equipo de desarrollo y el cliente. Este proceso de control tiene como base un plan que especifica los requerimientos a analizar para tomar la decisión del cambio, previa revisión del corrimiento del alcance según la influencia de los cambios propuestos (Microsoft, 2002).
Otro gran exponente es el IPMA, que es la asociación líder en los temas de Gestión de Proyectos, quien potencia la certificación de competencias relacionadas con la Gestión de Alcance.
8 1.2.2.2. IPMA
El modelo de IPMA se construye sobre la metodología propuesta por PMI, dentro de las capacidades técnicas está incluido el elemento de competencia Alcance y entregables en el cual IPMA apunta su criterio en estos aspectos.
Alcance
Plantea el IPMA que el alcance del proyecto define los límites de un proyecto. Estos deben ser bien definidos y los cambios documentados para evitar que todo se vaya de control. Desde el punto de vista de los interesados el alcance engloba los entregables incluidos en el proyecto y estos productos representan además todas las características funcionales, técnicas y de interfaz de usuario. La distribución gradual del alcance va desde los conceptos iniciales del proyecto hasta los productos entregables, documentando estos tan detallados como se vayan desarrollando. El proyecto debería entregar todo lo que haya sido incluido dentro de su alcance. Es importante también definir qué está fuera de este (IPMA, 2006).
La línea base de competencias de IPMA está circunscrita a la evaluación de directivos pero precisamente en esto radica la importancia de su análisis para la creación del modelo de Gestión de Alcance, ya que las buenas prácticas exigidas a los directivos de proyectos son puntos ineludibles en los procesos del alcance.
Otro importante exponente en el tema es el PMI el cual cuenta con la Guía de los Fundamentos de la Dirección de Proyectos (Guía del PMBOK), estándar de gran importancia para la Gestión de Proyectos que estudia diferentes áreas del conocimientos entre ellas la de Gestión de Alcance.
1.2.2.3. PMBOK
PMBOK es un estándar en la Gestión de Proyectos desarrollado por el PMI. Es una colección de procesos y áreas de conocimiento generalmente aceptadas como las mejores prácticas dentro de la Gestión de Proyectos, es un estándar reconocido internacionalmente que provee los fundamentos de la Gestión de Proyectos que son aplicables a un amplio rango de proyectos, incluyendo construcción, software e ingeniería. Esta guía está orientada a procesos e indica el conocimiento necesario para manejar el ciclo vital de cualquier proyecto, programa y portafolio a través de sus procesos. Define el cuerpo de conocimiento en el cual cualquier industria pude construir las mejores prácticas específicas para su área de aplicación. Por todo lo antes mencionado se seleccionó PMBOK como guía para la presente investigación.
9 Esta guía propone un conjunto de procesos para desarrollar una correcta Gestión de Alcance para los cuales se hace necesario seguir una secuencia lógica, estos procesos son:
Planificación del Alcance: Se crea un plan de Gestión del Alcance del proyecto que refleja cómo se definirá, verificará y controlará el alcance del proyecto, y cómo se creará y definirá la Estructura de Desglose del Trabajo (EDT). La planificación y la Gestión del Alcance del proyecto influyen sobre el éxito general del proyecto. Cada proyecto exige un delicado equilibrio entre las herramientas, las fuentes de datos, las metodologías, los procesos y los procedimientos, y otros factores, con el fin de asegurar que el esfuerzo dedicado a actividades para determinar el alcance sea acorde al tamaño, la complejidad y la importancia del proyecto. Durante la planificación, el alcance del proyecto se define y describe con mayor especificidad porque se conoce más información acerca del proyecto. Las necesidades, deseos y expectativas de los interesados se analizan y convierten en requerimientos. Las restricciones se analizan para verificar si están completas y de ser necesario, se agregan restricciones adicionales (PMI, 2004).
Definición del Alcance: Se desarrolla un enunciado del alcance del proyecto detallado como base para futuras decisiones del proyecto. La preparación de un enunciado del alcance del proyecto es crítica para el éxito del proyecto y se construye sobre la base de los principales productos entregables, asunciones y restricciones que se documentan durante la iniciación del proyecto en el enunciado del alcance del proyecto preliminar. Para la definición del alcance existen algunas técnicas y herramientas como:
- Análisis del Producto: El análisis del producto incluye técnicas tales como desglose del producto, análisis de sistemas, ingeniería de sistemas, ingeniería del valor, análisis del valor y análisis funcional.
- Identificación de Alternativas: Es una técnica usada para generar diferentes enfoques, ejecutar y realizar el trabajo del proyecto. A menudo, se usa una gran variedad de técnicas generales de gestión, de las cuales las más comunes son la tormenta de ideas y el pensamiento lateral.
- Juicio de Expertos: Cada área de aplicación tiene expertos que pueden usarse para desarrollar partes del enunciado del alcance del proyecto detallado.
- Análisis de los Interesados: Identifica la influencia y los intereses de los diversos interesados y documenta sus necesidades, deseos y expectativas. El análisis selecciona, prioriza y cuantifica las necesidades, deseos y expectativas para definir requerimientos. Las expectativas no cuantificables, tales como la satisfacción del cliente, son subjetivas e implican un alto riesgo de no ser logradas con éxito. Los intereses de los interesados pueden verse afectados positiva o negativamente por la
10 ejecución o la conclusión del proyecto, y también pueden ejercer una influencia sobre el proyecto y sus productos entregables (PMI, 2004).
Crear EDT: Subdivide los principales productos entregables del proyecto y el trabajo del proyecto en componentes más pequeños y más fáciles de manejar. La EDT organiza y define el alcance total del proyecto. El trabajo planificado comprendido dentro de los componentes de la EDT del nivel más bajo, denominados paquetes de trabajo, puede programarse, supervisarse, controlarse y estimarse sus costos.
Algunas herramientas y técnicas usadas son:
- Plantillas de Estructura de Desglose del Trabajo: Si bien cada proyecto es único, a menudo una EDT de un proyecto anterior puede usarse como plantilla para un nuevo proyecto, ya que algunos proyectos se asemejan a otro proyecto anterior en alguna medida.
- Descomposición: Distintos productos entregables pueden tener diferentes niveles de descomposición. Para llegar a un esfuerzo de trabajo fácil de manejar (es decir, un paquete de trabajo), para algunos productos entregables el trabajo sólo debe descomponerse hasta el nivel siguiente, mientras que otros requieren niveles mayores de descomposición. A medida que el trabajo se descompone hasta niveles inferiores de detalle, mejora la capacidad de planificar, dirigir y controlar el trabajo (PMI, 2004).
Verificación del Alcance: Formaliza la aceptación de los productos entregables completados del proyecto.
Verificar el alcance del proyecto incluye revisar los productos entregables para asegurarse de que cada uno se complete satisfactoriamente. Si el proyecto se termina antes de lo previsto, el proceso de verificación del alcance del proyecto debería establecer y documentar el nivel y alcance de lo completado. La verificación del alcance se diferencia del control de calidad en que la verificación del alcance se relaciona principalmente con la aceptación de los productos entregables, mientras que el control de calidad se relaciona principalmente con cumplir los requisitos de calidad especificados para los productos entregables (PMI, 2004).
Control del Alcance: Controla los cambios en el alcance del proyecto, se encarga de influir sobre los factores que crean cambios en el alcance del proyecto y de controlar el impacto de dichos cambios. Asegura que todos los cambios solicitados y las acciones correctivas recomendadas se procesen a través del proceso Control Integrado de Cambios del proyecto. También se usa para gestionar los cambios reales
11 cuando se producen, y está integrado con los demás procesos de control. Las herramientas y técnicas utilizadas son:
- Sistema de Control de Cambios: Un sistema de control de cambios en el alcance del proyecto, documentado en el plan de gestión del alcance del proyecto, define los procedimientos por los cuales pueden modificarse el alcance del proyecto y el alcance del producto.
- Análisis de Variación: Las mediciones del rendimiento del proyecto se usan para evaluar la magnitud de la variación. Entre los aspectos importantes del control del alcance del proyecto se incluyen determinar la causa de variación relativa a la línea base del alcance y decidir si son necesarias acciones correctivas.
- Replanificación: Las solicitudes de cambio aprobadas que afecten al alcance del proyecto pueden exigir que se hagan modificaciones en la EDT y en el diccionario de la EDT, en el enunciado del alcance del proyecto y en el plan de gestión del alcance del proyecto. Estas solicitudes de cambio aprobadas pueden hacer que se realicen actualizaciones a los componentes del plan de gestión del proyecto.
- Sistema de Gestión de la Configuración: Un sistema de gestión de la configuración formal proporciona procedimientos para el estado de situación de los productos entregables, y asegura que se tengan en cuenta y se documenten los cambios solicitados en el alcance del proyecto y en el alcance del producto antes de procesarse a través del proceso Control Integrado de Cambios (PMI, 2004).
Estos procesos interaccionan entre sí y también con los procesos de las demás áreas del conocimiento.
Cada proceso puede involucrar el esfuerzo de una o más personas o grupos de personas, sobre la base de las necesidades del proyecto.
Cuando se habla de alcance se refiere a lo siguiente: Alcance del producto que son las características y funciones que caracterizan a un producto, servicio o resultado.
Alcance del proyecto es el trabajo que debe realizarse para entregar un producto, servicio o resultado con las funciones y características especificadas. Ver (Figura 1)
12 Figura 1: Descripción General de la Gestión del Proyectos. Fuente PMBOK
13 La Gestión de Alcance a la hora de Gestionar un Portafolio de Proyectos es muy importante porque una vez que se gestione correctamente se podrá decidir cuál o cuáles proyectos son los más rentables para la empresa u organización y contribuirá a la toma de decisiones.
1.3. Gestión de Alcance en la UCI
La Universidad de las Ciencias Informáticas (UCI), funciona como uno de los centros productores de software más grandes con los que país cuenta, el mismo ha asumido retos al trabajar en la creación productos grandes, complejos y comprometidos en tiempo, costo y calidad, los cuales deben concluirse satisfactoriamente. Estos proyectos sustentan su gestión a través de una serie de plantillas y documentos con los que se conforma el Expediente del Proyecto, implícitamente se realiza la Gestión de Alcance aunque no verdaderamente bien implementada, debido a que no se cubren todos los procesos del área de conocimiento de Gestión de Alcance propuesta por uno de los máximos exponentes como PMBOK. Es por ello que se identifican diferentes problemas como: no se define estrategia alguna para la gestión de los cambios que aparecen durante la vida del proyecto en el alcance del mismo, sobre el cual se basan medulares planificaciones tales como las del tiempo, costo o recursos humanos. Tampoco se requiere de la confección o definición de una trazabilidad entre requerimientos y entregables a generar, la cual refleja la verdadera vinculación entre producto y proyecto como un objetivo del otro y verifica si la concentración del esfuerzo que se va realizando está encaminada a alcanzar las metas propuestas.
Esto no significa la inexistencia de la Gestión de Alcance en los proyectos realizados en la Universidad, sino que solo se evalúan algunos de sus puntos por la importancia de estos para el posterior desarrollo de los proyectos.
1.4. Sistemas informáticos relacionados con la Gestión de Portafolios de Proyectos
Existen múltiples herramientas que facilitan el trabajo de la Gestión de Portafolios de Proyectos, y ésta sin lugar a dudas depende de más de una elección adecuada, es por ello que el proceso de selección de la herramienta a utilizar se hace un poco complicado. Por lo que es necesario analizar si la herramienta que se seleccionará cubrirá todas las necesidades existentes en la empresa. A continuación se hace un estudio de los sistemas informáticos existentes para la GPP:
Rational Focal Point: Ayuda a las organizaciones de desarrollo de productos a aumentar el éxito de sus líneas de productos, ésta permite a los planificadores de productos a tomar las decisiones correctas. Cuenta con una serie de características como:
14 - Utiliza la visualización, establecimiento de prioridades, hoja de ruta única y las capacidades de
planificación para crear planes que son valiosos y alcanzables.
- Cierra la brecha entre la empresa y la ingeniería mediante la centralización de la información clave para la toma de decisiones, presentación de informes de estado y la Gestión de Portafolios.
- Prioriza y visualiza las necesidades del cliente para reducir el riesgo de minimización o eliminación durante la ejecución de proyectos de las capacidades más valiosas.
- Centraliza la información para escapar del caos de la gestión de correos electrónicos, documentos y hojas de cálculos, acelerando la capacidad de responder a las cambiantes condiciones del mercado y de negocio (IBM, 2010).
Primavera Enterprise Project Portfolio Management: Se centra exclusivamente en ayudar a las empresas en la Gestión de Proyectos en todo el ciclo de vida del Portafolio de Proyectos, e incluye todos los proyectos sin importar su tamaño. Esta solución ayuda a las empresas a tomar mejores decisiones en cuanto a la Gestión de Portafolios, evalúa los riesgos y beneficios asociados con los proyectos, y determina si existen recursos suficientes con los conocimientos adecuados para realizar el trabajo. También, proporciona la ejecución de proyectos y capacidades de control, necesarias para la entrega exitosa de los proyectos a tiempo, dentro del presupuesto y con la calidad deseada.
Primavera le da a la empresa soluciones de Gestión de Portafolios que permiten a las organizaciones hacer lo siguiente:
- Gestionar eficazmente el tiempo, costo, recursos, contratos, y los cambios en una única solución.
- Mejorar la eficiencia operativa
- Proporcionar proyecto de empresa y la visibilidad de la Gestión de Portafolios de Proyectos.
- Reducir el riesgo de incumplimientos (Oracle, 2010).
Microsoft Enterprise Project Management (EPM): Es muy potente, cumple con las 9 áreas del conocimiento propuestas por el PMBOK y el sistema informático más apto para grandes proyectos o equipos de trabajo inclusive colaborando geográficamente distantes. Uno de los aspectos más importante a destacar de este sistema es que se integra con las herramientas de desarrollo de Microsoft (.net team system), (office sharepoint server's). Esto permite que empresas que produzcan con esta tecnología puedan cerrar todo el ciclo de vida con herramientas integradas totalmente, no solo en la gestión del proyecto sino también en la gestión de toda la documentación del mismo.
15 Ventajas:
- Administra proyectos como portafolios colectivos para tomar mejores decisiones. Administra más efectivamente el portafolio de proyectos de la compañía identificando constantemente, priorizando e invirtiendo en proyectos que estén alineados a la estrategia de la corporación.
- Optimiza recursos a través de su organización para una competencia sostenida. Las personas son el recurso más valioso y generalmente costoso de una organización. Para maximizar la productividad a bajo costo, asigna las personas indicadas a las tareas correctas.
- Agiliza el desempeño de la administración de proyecto para ventajas competitivas. Ya sea proporcionando productos o servicios, todas las organizaciones necesitan alcanzar sus fechas de entrega, presupuestos y expectativas de sus accionistas. Para mantener la satisfacción y expectativas de los clientes alta, no hay espacio para errores o retrasos en los proyectos (Microsoft, 2010).
Las herramientas antes mencionadas, creadas con el fin de gestionar los Portafolios de Proyectos son ideales para proyectos de gran magnitud, estas presentan algunas desventajas tales como:
- Para un usuario ocasional, hay un número de características avanzadas que pueden causar problemas, y para un usuario normal, tienen que gastar una cantidad razonable de tiempo en volver a recuperar la configuración predeterminada.
- No se puede medir la productividad de las máquinas y las personas, tampoco el rendimiento.
- Interfaz de gran alcance lo que permite cometer errores en los archivos de proyectos grandes que pueden ser difícil de ver por un período significativo de tiempo. Es decir, que pueden estropear la mayoría de todas las dependencias de un proyecto en 1 minuto sin intención.
Además de las desventajas que presentan estas herramientas son softwares propietarios con un elevado costo no solo el producto también las licencias y actualizaciones (IBM, 2010), (Microsoft, 2010), (Oracle, 2010). Un ejemplo concreto se puede observar en la siguiente tabla donde aparecen los costos de estos productos y sus licencias ver
Tabla 1).
16 Rational Focal Point Primavera Enterprise
Project Portfolio Management
Microsoft Project Management
Precio del producto 2,690.00 (USD) 1794.00 (Euros) 999.95 (USD)
Precio de la licencia 686.00 (USD) 1973.00 (Euros) 599.95 (USD)
Tabla 1: Comparación de precios de herramientas de GPP.
También existen un número de herramientas para la Gestión de Proyectos que soportan la Gestión de Portafolios de Proyectos tal es el caso de: Redmine, Project.Net, entre otras.
En un estudio realizado recientemente en la universidad por un grupo de la Dirección Técnica de la Infraestructura Productiva (Kindelán, 2009) se analizaron estas herramientas. Las mismas son las que mayores posibilidades tienen de ser usadas, e incluso se quedan por debajo de lo que se necesita, porque no soportan todos los procesos del área de Gestión de Alcance definidos por el PMBOK. En la (Tabla 2) se puede observar una comparación entre Project.net, Redmine. Se puede apreciar que el Redmine no cuenta con una vista gráfica de la Estructura de Desglose de Trabajo (EDT) por lo que no puede descomponer niveles superiores de EDT en componentes detallados de nivel inferior; no verifica el alcance lo que dificulta la garantía de los compromisos contraídos con el cliente. Project.Net cuenta con las limitaciones antes mencionadas; además no posibilita realizar una buena planificación del alcance. Por todo lo antes mencionado estas herramientas no pueden ser usadas por las deficiencias antes mencionadas.
17 Característica
Nivel de cumplimiento de las Herramientas
ProjectNet
(9.0.0) Redmine (0.8)
Gestionar alcance Insuficiente No
Gestionar objetivos No Suficiente
Objetivos terminados No Suficiente
Trazabilidad o dependencias No Insuficiente
Planificación del alcance No No
Definición del alcance No No
Modelar ciclo completo de desarrollo Suficiente Insuficiente
Fases Suficiente Insuficiente
Hitos Suficiente Suficiente
Iteraciones Suficiente No
EDT o WBS No No
Identificar productos entregables y el trabajo
relacionado Suficiente No
Estructurar y Organizar EDT No No
Descomponer niveles superiores de EDT en
componentes detallados de nivel inferior No No
Desarrollar y asignar códigos de identificación
a los componentes de la EDT No No
Verificar que el grado de descomposición del
trabajo es necesario y suficiente No No
Verificación del alcance (garantizar compromisos con el
alcance) No No
Control de alcance (gestión de problemas/desviaciones
y gestión de acciones correctivas) No No
Tabla 2: Comparación entre Project.net, Redmine. Fuente Servicio de Gestión de Proyectos.
1.5. Metodología y herramientas para la modelación de software
1.5.1. Metodología
Las metodologías de desarrollo de softwares van indicando paso a paso todas las actividades a realizar para lograr el producto informático deseado, indicando qué personas deben participar en el desarrollo de las
18 actividades y qué papel deben de tener. Detallan la información que se debe producir como resultado de una actividad y la información necesaria para comenzarla (Onglasses, 2010).
En la presente investigación se utilizó la metodología que fue definida en DATEC. La misma es aplicada para el desarrollo de productos de software, basada en un modelo de líneas de productos que define las fases, actividades y artefactos que se deben generar durant e el ciclo de vida del software. Además, está basada en la adaptación de metodologías para el desarrollo de software en equipos de trabajo, como SCRUM y OpenUP. Actualmente se aplica en las líneas existentes en DATEC.
1.5.2. Lenguaje de Modelado
Un lenguaje de modelado proporciona los elementos básicos con los que escribir un modelo.
UML es el lenguaje de modelado de sistemas de software más conocido en la actualidad; es el estándar internacional aprobado por la Object Managment Group (OMG). UML son un grupo de especificaciones de notación orientadas a Objeto, las cuales están compuesta por distintos diagramas, que representan las diferentes etapas del desarrollo de un proyecto de software. Permite la especificación, visualización, construcción y documentación de elementos de la Ingeniería del Software. UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de lo que se quiere representar. Ejemplos de estos diagramas son: diagramas de Estructura, diagrama de estructura compuesta (UML 2.0), diagramas de Comportamiento, diagramas de Interacción (Jacobson, 2000).
1.5.3. Herramienta CASE
Estas herramientas CASE modelan la información de negocios cuando ésta se transfiere entre distintas entidades organizativas en el seno de una compañía. El objetivo primordial de las herramientas de esta categoría consiste en representar objetos de datos de negocios, sus relaciones, y ayuda a comprender mejor la forma en que fluyen estos objetos de datos entre distintas zonas de negocio en el seno de la compañía.
Estas herramientas proporcionan una ayuda importante cuando se diseñan nuevas estrategias para los sistemas de información y cuando los métodos y sistemas no satisfacen las necesidades de la organización (Murcia, 2010).
En el Centro de Tecnologías de Almacenamiento y Análisis de Datos se utiliza Visual Paradigm como herramienta de modelado para el desarrollo de los proyectos productivos, esta herramienta tiene las siguientes características.
19 Visual Paradigm para UML es una herramienta UML profesional que soporta el ciclo de vida completo del desarrollo de software: análisis y diseño orientados a objetos, construcción, pruebas y despliegue. El software de modelado UML ayuda a una más rápida construcción de aplicaciones de calidad, mejores y a un menor costo. Permite dibujar todos los tipos de diagramas de clases, código inverso, generar código desde diagramas y generar documentación. La herramienta UML CASE también proporciona abundantes tutoriales de UML, demostraciones interactivas de UML y proyectos UML.
Lista de características:
- Soporte de UML versión 2.1.
- Diagramas de Procesos de Negocio - Proceso, Decisión, Actor de negocio, Documento.
- Interoperabilidad con modelos UML2 (metamodelos UML 2.x para plataforma Eclipse) a través de XMI.
- Ingeniería inversa - Código a modelo, código a diagrama.
- Soporta Plataformas Java (Windows/Linux/Mac OS X): SDE para Eclipse (Paradigm, 2010).
1.6. Ingeniería de Requerimientos
Uno de los párrafos más citados en la bibliografía de la ingeniería de software señala: "La parte más difícil de construir un sistema es precisamente saber qué construir. Ninguna otra parte del trabajo conceptual es tan difícil como establecer los requerimientos técnicos detallados, incluyendo todas las interfaces con personas, máquinas y otros sistemas. Ninguna otra parte del trabajo afecta tanto el sistema si no se realiza correctamente. Ninguna es tan difícil de corregir más adelante. Entonces, la tarea más importante que el ingeniero de software hace para el cliente es la extracción iterativa y el refinamiento de los requerimientos del producto" (Presman, 2005).
La etapa de definición de requerimientos es de gran importancia para el proceso de desarrollo de un software debido a que es la actividad donde el equipo de desarrollo de un sistema de software identifica las necesidades que debe cubrir este sistema, este proceso puede resultar complejo, principalmente si el entorno de trabajo es desconocido para el equipo de analistas. No prestar atención especial a los requerimientos conlleva a innumerables problemas en el proyecto, es por ello que se elab ora el documento de requerimientos, dicho documento es considerado como la joya mas preciada de la ingeniería de requerimientos.
El Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) en el glosario estándar de términos de la ingeniería de software define un requerimiento como (IEEE, 2010):
20 I. Condición o capacidad que necesita un usuario para resolver un problema o lograr un objetivo.
II. Condición o capacidad que tiene que ser alcanzada o poseída por un sistema o componente de un sistema para satisfacer un contrato, estándar u otro documento impuesto formalmente.
III. Una representación documentada de una condición o capacidad como en I o II.
En esta definición no se tratan los requerimientos en función de la satisfacción de clientes y usuarios.
Craig Larman define los requerimientos como una descripción de las necesidades o deseos de un producto y delimita la meta primaria de la fase de requerimientos en identificar y documentar lo que en realidad se necesita, en una forma que claramente se lo comunique al cliente y a los miembros del equipo de desarrollo (Larman, 2003).
En esta definición sí se tiene en cuenta los requerimientos como forma de entendimiento entre los desarrolladores y los clientes.
SWEBOK representa la “Guía del Conocimiento de la Ingeniería de Software” y en su versión del 2004 se emite también su propia definición de requerimiento. “En lo más básico, un requerimiento de software es una propiedad que tiene que ser expuesta para resolver un problema determinado del mundo real. Por lo tanto, es una propiedad que tiene que ser exhibida por un software desarrollado o adaptado para resolver algún problema en particular” (IEEE, 2004).
Después de analizar las diferentes definiciones de requerimientos citadas anteriormente, se puede definir un requerimiento como las características o cualidades, condiciones y capacidades de un sistema, descritas claramente tanto para el equipo de desarrollo como para clientes y usuarios en función de satisfacer sus necesidades.
1.6.1. Características de los requerimientos
Los requerimientos poseen una serie de características tales como:
- Especificados por escrito. Como todo contrato o acuerdo entre dos partes.
- Posibles de probar o verificar. Si un requerimiento no se puede comprobar, entonces ¿Cómo sabemos si cumplimos con él o no?
- Descritos como una característica del sistema a entregar. Esto es: que es lo que el sistema debe de hacer (y no cómo debe de hacerlo).
- Lo más abstracto y conciso posible. Para evitar malas interpretaciones (Jacobson, 2000).
21 1.6.2. Requerimientos funcionales y no funcionales
Los requerimientos se clasifican en requerimientos funcionales y no funcionales:
Requerimientos funcionales: son capacidades o condiciones que el sistema debe cumplir.
Requerimientos no funcionales son propiedades o cualidades que el producto debe tener. Debe pensarse en estas propiedades como las características que hacen al producto atractivo, usable, rápido o confiable.
Los requerimientos no funcionales forman una parte significativa de la especificación. Son importantes para que clientes y usuarios puedan valorar las características no funcionales del producto, pues si se conoce que el mismo cumple con la funcionalidad requerida, las propiedades no funcionales, como cuán usable, seguro, conveniente y agradable, pueden marcar la diferencia entre un producto bien aceptado y uno con poca aceptación (Jacobson, 2000).
1.6.2.1. Categoría de los requerimientos no funcionales Existen múltiples categorías para clasificar los requisitos no funcionales.
Requerimientos de interfaz externa
- El acceso a las funcionalidades debe utilizar tipos de datos estándar de Internet.
- Las funcionalidades deben estar accesibles a través del protocolo SOAP.
Requerimientos de Usabilidad
- La plataforma no puede ser accedida directamente, sino a través de una interfaz diseñada para estos propósitos.
- Los mensajes de error deben ser reportados por la propia aplicación en la medida de las posibilidades y no por el Sistema Operativo. Los mensajes del sistema deben estar en el idioma apropiado.
Requerimientos de Rendimientos
- El sistema deberá responder en el mínimo de tiempo posible ante las solicitudes de información por parte de otros sistemas y en el procesamiento de la información. La eficiencia de la aplicación estará
22 determinada en gran medida por el aprovechamiento de los recursos que se disponen en el modelo de n capas, y la velocidad de las consultas a la base de datos.
Requerimientos de Soporte
- Se documentará la aplicación con un manual de ayuda con el objetivo de explicar el uso de la plataforma para garantizar el soporte de la herramienta. Se debe realizar el proyecto de forma versionable que permita darle mantenimientos al sistema a fin de aumentar las funcionalidades y/o corregir los errores del mismo a través de versiones posteriores. Los servicios de instalación y mantenimiento del sistema será responsabilidad del administrador en la entidad que sea utilizado.
Requerimientos de Seguridad
- La información estará protegida contra accesos no autorizados utilizando mecanismos de validación que puedan garantizar el cumplimiento de esto: cuenta, contraseña y nivel de acceso, de manera que cada uno pueda tener disponible solamente las opciones relacionadas con su actividad y tenga datos de acceso propios, garantizando así la confidencialidad.
- Se usarán mecanismos de encriptación de los datos que por cuestiones de seguridad no deben viajar al servidor en texto plano, como es el caso de las contraseñas. Se guardará encriptada esta información en la base de datos utilizando para ello MD5 como algoritmo de encriptación.
Requerimientos de Confiabilidad
- El sistema debe ser tolerante ante los fallos y las operaciones a realizar deben ser transaccionales.
- Ayuda y documentación en línea.
- El sistema tendrá un manual de ayuda disponible que permitirá aclarar dudas respecto al funcionamiento del mismo.
Requerimientos de Software
- La aplicación debe poderse ejecutar en diferentes entornos, como Windows, Linux, (Multiplataforma).
Al mismo tiempo, debe ser capaz de usar para “guardar los datos” diferentes motores de bases de datos.
23 Requerimientos de Hardware
Los requerimientos de hardware estarán dados por la plataforma específica que se utilice para la instalación del sistema, en cuanto a sistema operativo, servidor de aplicaciones y gestor de bases de datos (Eumed, 2010).
1.6.3. Captura de requerimientos
El éxito en la obtención de requerimientos depende del entendimiento a partir de la comunicación entre clientes y desarrolladores. Debido a lo complejidad que esto puede implicar, la ingeniería de requerimientos ha trabajado desde hace años en desarrollar técnicas que permitan hacer este proceso de una forma más eficiente y precisa. A continuación se exponen algunas técnicas que serán utilizadas.
Tormenta de ideas: Tormenta de ideas es también una técnica de reuniones en grupo cuyo objetivo es que
los participantes muestren sus ideas de forma libre. Consiste en la mera acumulación de ideas y/o información sin evaluar las mismas. Las sesiones de tormentas de ideas deben estar integradas por un número de cuatro a diez personas, uno de los cuales debe asumir el rol de moderador de la sesión, pero sin carácter de controlador.
Como técnica de captura de requerimientos es sencilla de aplicar. Además, suele ofrecer una visión general de las necesidades del sistema, pero normalmente no se obtienen resultados con el mismo nivel de detalle que en otras técnicas. Sus fases son: preparación, generación, consolidación y documentación (Escalona, 2002).
Mapas conceptuales: Los mapas conceptuales son grafos en los que los vértices representan conceptos y
las aristas representan posibles relaciones entre dichos conceptos. Estos grafos de relaciones se desarrollan con el usuario y sirven para aclarar los conceptos relacionados con el sistema a desarrollar. Son muy usados dentro de la ingeniería de requisitos, pues son fáciles de entender por el usuario, más aún si el equipo de desarrollo hace el esfuerzo de elaborarlo en un lenguaje común. Sin embargo, deben ser usados con cautela porque pueden llegar a ser ambiguos en casos complejos, si no se acompaña de una descripción textual (Escalona, 2002).
Entrevistas: Las entrevistas resultan una técnica muy aceptada dentro de la ingeniería de requisitos y su
uso está ampliamente extendido. A través de esta técnica el equipo de trabajo se acerca al problema de una forma natural. Existen muchos tipos de entrevistas y son varios los autores que han trabajado en definir su estructura y aportar guías para su correcta realización. Básicamente la estructura de la entrevista abarca
24 cuatro pasos: identificación de los entrevistados, preparación de la entrevista, realización de la entrevista y análisis de los resultados.
La entrevista no es una técnica sencilla de aplicar, pues requiere que el entrevistador sea experimentado y tenga capacidad para elegir bien a los entrevistados para obtener de ellos toda la información posible en un período de tiempo siempre limitado (Escalona, 2002).
1.7. Patrones de Caso de Uso
Los patrones de diseño son soluciones simples y elegantes a problemas específicos y comunes del diseño orientado a objetos. Son soluciones basadas en la experiencia, y que se ha demostrado que funcionan (Gunnar Overgaard, 2004).
Los patrones de diseño no son fáciles de entender, pero una vez entendido su funcionamiento, los diseños serán mucho más flexibles, modulares y reutilizables. Han revolucionado el diseño orientado a objetos y todo buen arquitecto de software debería conocerlos. Algunos patrones de casos de uso son los siguientes:
- Reglas de negocio
- Concordancia (Commonality)
- Componente jerárquico (Component hierarchy) - Extensión concreta o Inclusión
- CRUD (Creating, Reading, Updating, Deleting) - Caso de uso grande (Large Use case)
- Sistema de Capas - Múltiples actores
A continuación se abordarán los patrones de casos de uso que serán utilizados.
Inclusión Concreta: Es un patrón de estructura, consiste en dos casos de uso y una relación de inclusión entre el caso de uso base y el caso de uso incluido. Este último puede ser instanciado por sí solo. El caso de uso base puede ser concreto o abstracto. Este patrón se utiliza cuando un flujo de datos puede ser incluido en el flujo de otro caso de uso y también puede ejecutarse por sí solo (Gunnar Overgaard, 2004).
Extensión Concreta: Es un patrón de estructura, consiste en dos casos de uso y una relación de extensión entre ellos. El caso de uso extendido es concreto, lo que quiere decir que este puede ser instanciado por sí solo, ser una extensión del caso de uso base. El caso de uso base puede ser concreto o abstracto. Es
25 aplicable cuando un flujo de un caso de uso puede extender el flujo de otro caso de uso, así como ser ejecutado por sí solo (Gunnar Overgaard, 2004).
CRUD: Este patrón se basa en la fusión de casos de uso simples para formar una unidad conceptual. CRUD cuyas siglas significan Creating, Reading, Updating and Deleting, es un patrón de estructura. Propone identificar un Caso de Uso, llamado “Información CRUD” o “Gestionar Información”, que modela todas las diferentes operaciones que se pueden realizar sobre una parte de información de cierto tipo (o sea en una misma entidad), tal como crearla, leerla, actualizarla y eliminarla. Debe ser usado cuando todos los flujos contribuyen al mismo valor de negocio y estos a su vez son cortos y simples (Gunnar Overgaard, 2004).
Múltiples Actores: Roles diferentes Captura la concordancia entre actores manteniendo roles separados.
Consiste de un caso de uso y por lo menos dos actores. Es utilizado cuando dos actores juegan diferentes roles en un caso de uso, o sea, interactúan de forma diferente con el caso de uso (Gunnar Overgaard, 2004).
Concordancia: Extrae una subsecuencia de acciones que aparecen en diferentes lugares del flujo de casos de uso y es expresado por separado. Reusabilidad es un patrón de estructura que consta de 3 casos de uso.
El primero llamado subsecuencia común, modela una secuencia de acciones que aparecerán en múltiples casos de uso en el modelo. Los otros casos de uso modelan el uso del sistema que comparte la subsecuencia común de acciones (deben existir al menos dos de ellos) Adición. En el caso de este patrón alternativo, la subsecuencia común de casos de uso, extiende los casos de uso compart iendo la subsecuencia de acciones. Los otros casos de uso modelan el flujo que será expandido con la subsecuencia. Este patrón es preferible usarlo cuando otros Casos de Uso se encuentran propiamente completos, o sea, que no requieren de una subsecuencia común de acciones para modelar los usos completos del sistema. Especialización: Contiene casos de uso del mismo tipo. En este caso, estos son modelados como una especialización de casos de uso de tipo de uso común. Todas las acciones en estos casos de uso son heredadas por los casos de uso hijos, donde otras acciones serán adicionadas o acciones heredadas que serán especializadas. Este patrón es aplicable cuando la utilización de los casos de uso que han sido modelados son del mismo tipo, y este tipo debe hacerse visible en el modelo (Gunnar Overgaard, 2004).
Cada patrón describe un problema que ocurre una y otra vez en el ambiente, y luego describe el núcleo de la solución a ese problema, de tal manera que se pueda usar esa solución un millón de veces más, sin hacer jamás la misma cosa dos veces.
26 1.7. Conclusiones
En este capítulo se analizaron los principales conceptos necesarios para entender la importancia de este trabajo de investigación, se realizó una reseña del estado del arte del tema a tratar. Se hizo un estudio de algunos sistemas informáticos existentes para la Gestión de Portafolios de Proyectos, detectando las deficiencias por las cuales no pueden ser utilizados. Se dejaron sentadas las bases teóricas para un correcto análisis, seleccionando como metodología a utilizar la definida en el centro (CENTALUP) y como herramienta el Visual Paradigm, para así dar solución a la problemática propuesta.
27 Introducción
En este capítulo se realiza una propuesta del sistema a desarrollar, se elabora el modelo de dominio para representar conceptos significativos que utilizan los usuarios. Además, se realiza la gestión de requerimientos a través de diferentes técnicas como entrevistas, tormentas de ideas, entre otras seleccionadas para la captura y definición. Se define el modelo de Casos de Uso del sistema y se realiza una descripción detallada de cada uno de los Casos de Uso del mismo, los cuales guiarán el proceso de desarrollo del software.
2.1. Propuesta del sistema
En el presente trabajo se realiza la propuesta del análisis del Módulo de Gestión de Alcance, para el desarrollo de una plataforma web para el Teletrabajo y la Gestión de Portafolios de Proyectos. Con la misma se pretende gestionar de forma íntegra los portafolios de proyectos. Resulta de suma im portancia contar con el Módulo de Gestión de Alcance para facilitar la toma de decisiones y determinar con exactitud el trabajo que se necesita realizar, además para que los proyectos de los portafolios sean gestionados y ejecutados de forma eficiente garantizando la entrega a tiempo de los productos con la calidad requerida. Este módulo dará la posibilidad de gestionar portafolios, programas y proyectos.
2.1.1. Modelo de dominio
El modelo de dominio es un artefacto muy importante de la disciplina de análisis, debido a que en él se representan los conceptos significativos para el dominio del problema, éste incluye clases de objetos, asociaciones entre clases y atributos de las clases de objeto (Pressman, 1998). El modelo de dominio puede utilizarse para capturar y expresar el entendimiento ganado en un área bajo análisis, como paso previo para el diseño. Este modelo resulta de gran importancia debido a que ayuda a comprender los conceptos que utilizan los usuarios y así lograr un mejor entendimiento con los desarrolladores, puesto que se emplea un vocabulario común para poder entender el contexto en el que se desarrolla el sistema y proporcionar una vista general.
El modelo de dominio se describe mediante un diagrama de UML para poder especificar las principales clases conceptuales que intervienen en el sistema, estos representarán los objetos que existen o eventos que suceden en el entorno en el que trabajará el sistema.
28 Para el mejor entendimiento del diagrama conceptual del modelo de dominio es de gran im portancia conocer el significado de los siguientes términos:
Empresa
Una empresa es el organismo social integrado por elementos humanos, técnicos y materiales cuyo objetivo natural y principal es la obtención de utilidades (Microsoft, 2009).
PPM
PPM (Gestión de Portafolios de proyectos): es la identificación, priorización, autorización, administración y control de los proyectos, programas y otros trabajos conexos, para lograr los objetivos estratégicos empresariales (PMI, 2004).
Programas
Un programa es un grupo de proyectos relacionados, que se administran de manera coordinada para obtener beneficios (Duncan, 1996).
Objetivos estratégicos
Los objetivos estratégicos son logros que la organización quiere alcanzar en un plazo determinado para ser consiente con la orientación y propósitos estratégicos definidos en la misión (Presupuesto, 2005).
Proyecto
Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único (PMI, 2004).
Actividad
Una actividad es una tarea simple asociada a un proyecto.
Categoría
Tipo de clasificación de las actividades que determinan su comportamiento, algunas clasificaciones son: hito, etapa, otras.
Campo
Definiciones que pertenecen a una categoría de actividad, estos tienen un nombre y un valor.