Revista de Procesos y Mtricas de las Tecnologas de la Informacin (RPM) VOL.

2, N 1, Marzo 2005, 3-16 Asociacin Espaola de Sistemas de Informticos (AEMES)

ISSN: 1698-2029

OPTIMIZACIN DE MTRICA VERSIN 3 EN ENTORNOS ORIENTADOS A OBJETOS

Jos L. Lpez Cuadrado, ngel Garca Crespo, Beln Ruiz Mezcua, Israel Gonzlez Carrasco
Universidad Carlos III, Departamento de Informtica
Avda. de la Universidad 30, 28913 Legans, Madrid, Spain

E-Mail: jllopez@inf.uc3m.es, acrespo@ia.uc3m.es, bruiz@inf.uc3m.es, igcarras@inf.uc3m.es

Abstract:

Metrica v3 methodology has been created by the Ministry of Public Administrations of Spain, to develop projects of the administration, but also it is being used in projects of the private company. The experience says that the first contact with the methodology can be complicated for managers little experienced. For that reason the methodology has been reviewed including explanations taken from the bibliography on the development of software projects, and including examples that facilitate the understanding. In addition we propose the modification of the order in some activities, as well as the suppression or fusion of others to facilitate the application of the methodology. La metodologa Mtrica v3 ha sido creada por el Ministerio de Administraciones Pblicas de Espaa, para llevar a cabo proyectos de la administracin, pero tambin se est utilizando en proyectos de la empresa privada. La experiencia nos dice que el primer contacto con la metodologa puede resultar complicado para gestores poco experimentados. Por ello se ha revisado la metodologa incluyendo explicaciones tomadas de la bibliografa sobre el desarrollo de proyectos software, y se han incluido ejemplos que faciliten la comprensin. Adems se propone la modificacin del orden en algunas actividades, as como la supresin o fusin de otras para facilitar la aplicacin de la metodologa.

Resumen:

Palabras clave: Metodologa de desarrollo, Ciclo de vida, Ingeniera del software.

1.

INTRODUCCIN

Mtrica Versin 3 establece tres grandes etapas: 1. Planificacin de Sistemas de Informacin. Esta etapa no es objeto de estudio en esta revisin. Consiste en analizar las necesidades de sistemas de informacin que tiene la organizacin. Desarrollo de Sistemas de Informacin. Esta es la etapa en la que se va a centrar la presente revisin. Se subdivide en los siguientes procesos: a. b. c. d. Estudio de Viabilidad Sistema (EVS) Anlisis del Sistema Informacin (ASI) Diseo del Sistema Informacin (DSI) del de de

Las Administraciones Pblicas, conscientes de la importancia de seguir una metodologa para desarrollar software de calidad, han promovido la utilizacin de metodologas para que sean usadas como referencia tanto por los organismos pblicos, como por las empresas privadas. As, la Administracin Pblica francesa cre la metodologa MERISE, y la Administracin Pblica del Reino Unido cre SSADM. Adems, se siguen desarrollando otras metodologas, como el Proceso Unificado de Modelado de Jacobson, Booch y Rumbaugh, dirigido a proyectos Orientados a Objetos. En Espaa, el Ministerio de Administraciones Pblicas desarroll la metodologa Mtrica, que actualmente est en su versin 3.

2.

Construccin del Sistema de

RPM-AEMES, VOL. 1, N 2, Agosto 2004

ISSN: 1698-2029

Informacin (CSI) e. 3. Implantacin y Aceptacin del Sistema (IAS)

Mantenimiento del Sistema de Informacin. El proceso de mantenimiento queda fuera del alcance de esta revisin.

Adems Mtrica Versin 3, establece las interfaces de Gestin de Proyectos, Gestin de Configuracin y Gestin de Calidad que se aplican a lo largo de todos los procesos. Los objetivos que se pretenden con la optimizacin son: Revisar la Metodologa Mtrica Versin 3, centrndose en proyectos Orientados a Objetos. Aclarar los puntos que en la realizacin de un proyecto supusieron dificultades. Reorganizar y unificar y eliminar tareas, para facilitar el desarrollo y la comprensin de la metodologa. La rigidez en la interpretacin y utilizacin de la metodologa puede tener efectos no deseados en el proyecto, por lo que la metodologa debe mirarse desde las necesidades del proyecto. Aportar ejemplos de documentacin

inicialmente la metodologa ubica en el Anlisis del Sistema de Informacin. A travs de la toma detallada de requisitos la decisin que se tome, as la estimacin de esfuerzo y costes para determinar la viabilidad del sistema, tendr muchas posibilidades de ser la mejor, ya sea a travs del desarrollo de un nuevo proyecto, a travs de un sistema comercial existente en el mercado o una combinacin de ambos. La metodologa propone dentro del EVS, la identificacin de los Usuarios que participarn en el Estudio de la Situacin Actual. Dentro de la actividad EVS 1 Establecimiento del Alcance del Sistema, se propone la identificacin de todos los interesados del sistema. El concepto de usuarios puede llevar a equvocos, por lo que se incluye una tarea de identificacin de los stakeholders o interesados en el sistema. Los interesados clave en todos los proyectos incluyen [PMBOK 2000]: Project manager: la persona responsable de la gestin del proyecto. Clientes o usuarios: la persona u organizacin que utilizar el sistema. Existen mltiples niveles de usuarios. Por ejemplo para un producto farmacutico, los clientes sern los doctores que prescriben los medicamentos, los pacientes que los toman y las aseguradoras que pagan por ellos. En algunos sistemas las palabras usuario y clientes son sinnimos, mientras que en otros casos el cliente se refiere a la persona u organizacin que paga el sistema y los usuarios son aquellos que lo utilizarn directamente. Organizacin que va a llevar a cabo el proyecto: la empresa cuyos empleados llevarn a cabo el proyecto para construir el sistema. Evidentemente la empresa tambin tiene inters en el proyecto pues buscar unos objetivos de beneficios. Miembros del equipo de proyecto: el grupo de personas que va a llevar a cabo el proyecto para crear el nuevo sistema. Sponsors: las personas o grupos internos o externos que proveen recursos financieros, bien sea en efectivo o de otro tipo (equipos, software, etc.) para el proyecto. Todos estos interesados deben ser consultados y tomados en consideracin tanto en la toma de requisitos como durante el desarrollo del sistema. Una vez que se ha definido el alcance del sistema, se identifican los interesados en el sistema y se

El alcance de la optimizacin se centra en la etapa de Desarrollo de Sistemas de Informacin y las interfaces de Gestin de Calidad, Gestin de Configuracin y Gestin de Proyectos. En el presente artculo se citan las aportaciones principales que se proponen para la metodologa en sus diversas fases.

2.

ESTUDIO DE VIABILIDAD DEL SISTEMA

El objetivo del proceso de Estudio de Viabilidad del Sistema es analizar un conjunto concreto de necesidades que tiene una organizacin, para proponer una solucin a corto plazo, que tenga en cuenta restricciones econmicas, tcnicas, legales y operativas. En esta fase se deben identificar los requisitos de usuario, a fin de tomar una decisin sobre las medidas que mejor solucionen los problemas que ste plantee. En este sentido se propone adelantar la toma detallada de requisitos de usuario, que

RPM-AEMES, VOL. 1, N 2, Agosto 2004

ISSN: 1698-2029

conoce a travs de ellos la situacin actual se propone la toma detallada de requisitos de usuario. Mtrica v3 propone la identificacin de requisitos generales para el estudio y valoracin de las alternativas de solucin del problema. Se propone detallar ms los requisitos para asegurar que la solucin es la ms adecuada a los problemas plantados. De esta forma se aprovechan las primeras reuniones con los interesados para conocer mejor el problema. Tambin se hace notar que los requisitos normalmente no son inamovibles, y conforme se avanza en el proyecto pueden surgir nuevos requisitos o modificaciones de los ya identificados, por lo que el catlogo de requisitos debe ser retroalimentado cuando se profundiza en el estudio del sistema.

Ms coloquialmente se podra definir la calidad como cumplir las necesidades y expectativas del cliente, en el plazo y los costes acordados, siguiendo los estndares aplicables y manteniendo documentado todo el proceso, de forma que sea posible repetir exactamente el mismo proceso para la generacin de un nuevo sistema. Es importante cumplir las expectativas del cliente, porque si el sistema cumple los requisitos pero no es lo que espera el cliente, ste no quedar totalmente satisfecho. Normalmente las empresas tendrn definido un Plan de Aseguramiento de Calidad que la organizacin impone para todos sus procesos. En este caso se debe adaptar la poltica de la organizacin marcada en ese plan al proyecto concreto que se va a desarrollar, estableciendo las revisiones y pruebas que resulten oportunas. Sin embargo se puede producir el caso de que dicho plan no haya sido definido an, por lo que surge la necesidad de crear el Plan de Aseguramiento de Calidad para el proyecto sin una base previa. Por ello se propone la utilizacin del estndar IEEE 730-2002 para la creacin de un Plan de Calidad, describiendo los puntos principales que debe contener para facilitar su creacin. Uno de los apartados del Plan de Aseguramiento de Calidad segn el estndar IEEE-730-2002, es el Plan de gestin de Riegos. Por ello en base a [CMMI 2002] y [PMBOK 2000], se muestran una serie de pasos que se pueden seguir para planificar la gestin de riesgos que pueden afectar al desarrollo del sistema. Para verificar que las directrices y revisiones marcadas en el Plan de Aseguramiento de Calidad se estn cumpliendo, se propone la utilizacin de matrices de trazabilidad que faciliten las comprobaciones, especialmente en la realizacin de las pruebas, en las que se debe asegurar que todos los requisitos y funcionalidades marcadas han sido recogidas en el sistema final.

3.

INTERFAZ DE GESTIN DE CALIDAD

Actualmente la calidad es un aspecto muy importante en todas las organizaciones. Cada vez son ms las que buscan y obtienen la certificacin ISO 9000, para que sus clientes perciban que la organizacin no solo realiza su trabajo, sino que adems lo realiza satisfaciendo las necesidades del cliente y realiza un trabajo de calidad. Un sistema de calidad basado en ISO tiene grandes ventajas para los clientes ya que: Garantiza la capacidad de la empresa para cumplir las especificaciones. Hay un sistema de registro que contiene la documentacin de todos los procesos que se llevan a cabo para la realizacin de un producto, es decir, la empresa tiene los procesos documentados, con lo cul garantiza que sabe hacer el producto, y que adems lo hace bien. Estn definidas las responsabilidades y la cualificacin del personal que realiza las actividades, es decir, que cada uno sabe lo que tiene que hacer, y si falla algo se conoce quin es el responsable.

4.

INTERFAZ DE GESTIN DE CONFIGURACIN

[PRESSMAN 2002] define la calidad del software como la concordancia con los requisitos funcionales y de rendimiento explcitamente establecidos, con los estndares de desarrollo explcitamente documentados, y con las caractersticas implcitas que se espera de todo software desarrollado profesionalmente.

Segn [CUEVAS 2002] la Gestin de Configuracin de Software es el proceso de identificar y definir los elementos de la configuracin para: 1. Controlar la liberacin y los cambios durante todo el ciclo de vida.

RPM-AEMES, VOL. 1, N 2, Agosto 2004

ISSN: 1698-2029

2. 3.

Registrar e informar de su estado y de las peticiones de cambios. Verificar la correccin y acabado de los elementos.

Adems [CUEVAS 2002] tambin define configuracin software como el conjunto de documentos relacionados, ficheros fuentes y herramientas utilizadas en el diseo e implantacin en un sistema software. El objetivo de la gestin de la configuracin es mantener la integridad de los productos que se obtienen a lo largo del desarrollo de los sistemas de informacin, garantizando que no se realizan cambios incontrolados, y que todos los participantes en el desarrollo del sistema disponen de la versin adecuada de los productos que manejan. Por ello, entre los elementos de la configuracin software no se encuentran solamente los ejecutables y el cdigo fuente, sino tambin todos los modelos y documentos que se generan durante el ciclo de vida. En este apartado, se han propuesto ejemplos de formatos que se pueden utilizar para la creacin de un Plan de Gestin de Configuracin, as como diversos ejemplos del contenido del plan, que facilitan la comprensin de los conceptos y la creacin del mismo, especialmente en para el proceso de cambio.

equipo del proyecto, incluyendo la gestin de incidencias y cambios en los requisitos que puedan presentarse y afectar a la planificacin del proyecto. El Seguimiento y Control del proyecto se realiza durante los procesos Anlisis del Sistema, Diseo del Sistema, Construccin e Implantacin del Sistema y Mantenimiento. Actividades de Finalizacin del Proyecto. Al concluir el proyecto se realizan las tareas propias del Cierre del Proyecto y Registro de la Documentacin de Gestin.

En cada una de los bloques que se enumeran se han propuesto distintas tareas y tcnicas que facilitan y mejoran la gestin del proyecto.

5.1

Inicio de proyecto

En el inicio del proyecto se estimar el esfuerzo y tiempo necesario para llevarlo a cabo y se planificarn las actividades a realizar a lo largo del mismo, estableciendo los hitos que se consideren necesarios, teniendo en cuenta las revisiones y pruebas marcadas en el Plan de Aseguramiento de Calidad. Para la planificacin se propone la utilizacin de tcnicas de diagramacin WBS (Work Breakdown Structure), OBS (Object Breakdown Structure) y RBS (Resource Breakdown Structure) para facilitar la identificacin de tareas y productos resultantes que se deben tener en cuenta en la estimacin y planificacin del proyecto.

5.

GESTIN DE PROYECTOS

La Gestin del Proyecto tiene como finalidad principal la planificacin, el seguimiento y el control de las actividades y de los recursos, tanto humanos como materiales, que intervienen en el desarrollo de un Sistema de Informacin, para evitar desviaciones de costes, duracin o funcionalidad del proyecto. Con este control se persigue conocer en todo momento qu problemas se producen y resolverlos o paliarlos a la mayor brevedad para minimizar sus consecuencias. Podemos agrupar las actividades de gestin en tres bloques: Gestin Inicial (GPI): al principio del proyecto, al concluir el Estudio de Viabilidad del Sistema, se realizarn las actividades de Estimacin de Esfuerzo y Planificacin de Proyecto. Gestin de Seguimiento y Control (GPS): comprenden desde la asignacin de las tareas hasta su asignacin interna por parte del

5.2

Seguimiento proyecto

control

del

El objetivo de la Gestin del Proyecto es que el proyecto se entregue en la fecha convenida, con el coste acordado y con la funcionalidad y calidad requerida por el cliente. El seguimiento y control del proyecto tiene como objetivo fundamental la vigilancia de todas las actividades de desarrollo del sistema. Es una de las labores ms importantes en todo desarrollo de sistemas, ya que un adecuado control hace posible evitar desviaciones en costes y plazos, o al menos detectarlas cuanto antes. En esta fase se deben prestar atencin a los indicadores identificados en el plan de gestin de riesgos que indiquen que se ha producido o se va a producir alguno de los riesgos que se han identificado. Cuando se detecta esta situacin, es

RPM-AEMES, VOL. 1, N 2, Agosto 2004

ISSN: 1698-2029

necesario llevar a cabo medidas correctoras destinadas a evitar que el riesgo se produzca, o bien paliar sus consecuencias a partir de los planes de contingencia que se hayan establecido. Dentro del seguimiento del proyecto, se propone, adems del seguimiento de tareas que propone Mtrica Versin 3, el seguimiento de los indicadores definidos en [MONTENEGROb 2004]: Actividad GPS 3: Seguimiento de Tareas. Seguimiento de Recursos. o Recursos Humanos. o Recursos Materiales. Seguimiento de Costes o Costes derivados del personal. o Costes derivados por recursos materiales. o Costes derivados de las actividades. o Costes acumulados. Seguimiento de Clientes. o Satisfaccin Respecto al Equipo de Trabajo. o Satisfaccin del Cliente Respecto a la Tecnologa. o Participacin del Cliente en el Proyecto. o Participacin del Cliente en el Incremento de Requisitos. Seguimiento de Usuarios. o Interfaz de Usuario. o Satisfaccin del Usuario Respecto al Equipo del Proyecto. o Participacin del Usuario.

mismo, el anlisis servir como base para el posterior diseo del sistema. La fase de anlisis es la fase de definicin del problema. En esta fase no se pretende solucionar el problema del que surge la necesidad del sistema. Se trata captar las necesidades que debe resolver, y modelar el problema utilizando distintas tcnicas, en funcin de las caractersticas del proyecto, para posteriormente, en el diseo del sistema, resolverlo. En determinadas tareas del proceso de anlisis deben participar tambin los interesados el sistema. Es necesario definir los interesados que deben participar en este proceso, determinando los perfiles, las responsabilidades que tendrn en el proceso y la dedicacin al proceso necesaria. La participacin de los interesados es especialmente relevante para el establecimiento de requisitos y la especificacin detallada del nuevo sistema. La principal propuesta que se realiza en esta fase es la identificacin de los requisitos software. Al hilo del adelanto de la toma de requisitos de usuario al EVS, se adelanta a la fase de Anlisis la definicin de requisitos software para profundizar en la definicin del problema. Antes de la toma de requisitos software se definirn los Diagramas Casos de Uso derivados de los requisitos de usuario que ya se haban identificado. A partir de ellos se avanza en la identificacin de los requisitos software. El propsito de la definicin de requisitos software es analizar los requisitos de usuario y producir un conjunto de requisitos que debe cumplir el software, tan completo, constante y correcto como sea posible. Los requisitos software son una visin del problema por parte del desarrollador. La documentacin de requisitos debe seguir unas normas de estilo y redaccin que posibiliten y facilite su comprensin. Las caractersticas de dicha documentacin son [CUEVAS 2002]: Los requisitos son entendibles de una sola manera, es decir, no son ambiguos. Completa: la documentacin recoge todos los requisitos que debe cubrir el sistema. Verificable: se puede comprobar que el sistema cumple con los requisitos, es decir, se puede establecer una accin para cada requisito que compruebe que el sistema le incorpora. Coherente: no hay requisitos contradictorios.

5.3

Gestin de finalizacin de tareas y finalizacin del proyecto.

En la gestin de finalizacin se identifican las tareas que se deben realizar cuando se finaliza una tarea o cuando se cierre el proyecto. Principalmente se refiere a la documentacin y revisiones que se realizan en la conclusin de cada tarea y del proyecto en general. En este sentido se ha definido el Documento Histrico de Proyecto, que se detallar ms adelante.

6.

ANLISIS DEL SISTEMA DE INFORMACIN

El objetivo del Anlisis del Sistema de Informacin es obtener una especificacin detallada del sistema que se va a construir. As

RPM-AEMES, VOL. 1, N 2, Agosto 2004

ISSN: 1698-2029

Fcil de modificar. El procedimiento de cambio se especifica en el Plan de Gestin de Configuracin. Fcil de identificar el origen y las consecuencias de los requisitos. Fcil de utilizar en el resto de fases.

Finalmente se completa el proceso de anlisis con ejemplos de las revisiones de consistencia entre las especificaciones del sistema y los requisitos, utilizando matrices de trazabilidad, as como de la definicin del plan de pruebas del sistema.

7.
En la optimizacin se han incluido formatos para la representacin de requisitos. Seguidamente la metodologa propone el anlisis de los casos de uso, la creacin del modelo de clases y su anlisis. Pese a que para desarrollos orientados a objetos la metodologa no aplica la creacin de un modelo de datos, en la optimizacin se ha tomado en cuenta, pues puede facilitar la identificacin de necesidades de migracin y carga inicial. La definicin de la interfaz de usuario en el anlisis, segn algunos autores, es cuestin de gustos, pudiendo dejar esta actividad para el Diseo pues forma parte de l. Sin embargo, en la optimizacin se ha considerado que puede ser til la definicin en el Anlisis, pues facilita la visin del sistema a los interesados que no son informticos. Para la definicin de las interfaces se parte de la descripcin de cada escenario en los casos de uso. [BRAUDE, 2001] define los siguientes pasos que se pueden seguir para definir la interfaz de usuario: Paso 1: Conocer al usuario. Paso 2: Entender la funcin de negocio en cuestin. Paso 3: Aplicar principios de diseo de dilogos. Paso 4: Seleccionar el tipo adecuado de ventanas. Paso 5: Definir los mens del sistema. Paso 6: Seleccionar los controles adecuados al tipo de interfaz. Paso 7: Elegir los controles apropiados a la pantalla. Paso 8: Organizar y presentar las ventanas. Paso 9: Elegir los colores apropiados. Paso 10: Crear iconos significativos. Paso 11: Proporcionar mensajes y retroalimentacin al resto de procesos.

DISEO DEL SISTEMA DE INFORMACIN

El objetivo del Diseo del Sistema de Informacin es resolver el problema que se ha descrito y modelado en el Anlisis del Sistema de Informacin. En este proceso se va a definir cmo se soluciona el problema planteado, detallando los algoritmos y tcnicas concretas a utilizar. Tambin se realiza una especificacin detallada de los componentes del sistema. Adems, en este proceso se define completa y detalladamente la arquitectura del sistema y el entorno tecnolgico en el que va a funcionar. Por arquitectura del sistema no solo nos vamos a referir a arquitectura fsica, sino tambin a la arquitectura de componentes software que van a formar parte del sistema. Es por ello que proponemos como nombre Diseo de Arquitectura Software. Segn [RUMBAUGH 1996], en todas las aplicaciones, salvo en las ms pequeas, el primer paso para disear un sistema consiste en dividir el sistema en un pequeo nmero de componentes. Cada uno de los componentes principales de un sistema se llama subsistema. Cada subsistema abarca aspectos del sistema que comparten alguna propiedad comn, como puede ser una funcionalidad similar, la misma ubicacin fsica, o la ejecucin en el mismo tipo de hardware. Como los requisitos software ya han sido definidos en el proceso de anlisis, en la fase de Diseo solo se van a definir los procedimientos de operacin y seguridad derivados de los requisitos ya identificados, completando aquellos que sea necesario a partir de la arquitectura software propuesta. La siguiente actividad propuesta en la metodologa es el Diseo de Subsistemas de Soporte. Se propone en este punto identificar tambin los mecanismos genricos de diseo, como la identificacin de patrones, resultando una nica actividad que se debera denominar Diseo de Arquitectura Software. Citando a [JACOBSON 2000], se trata de realizar un diseo de alto nivel del sistema que se va a desarrollar: es el primer

Estos pasos se desarrollan en las tareas que componen la actividad de Definicin de Interfaces de Usuario y se completarn en el proceso de diseo.

RPM-AEMES, VOL. 1, N 2, Agosto 2004

ISSN: 1698-2029

nivel de descomposicin, previo al diseo detallado. La arquitectura software se centra tanto en los elementos estructurales significativos (subsistemas especficos y subsistemas de soporte identificados en la Actividad DSI 1: Definicin de la Arquitectura del Sistema), como en las colaboraciones que tienen lugar entre estos elementos a travs de las interfaces. En paralelo al Diseo de la Arquitectura Software se van a definir los Casos de Uso Reales y se va a realizar el Diseo de las Clases, a partir de los resultados que provienen del Anlisis del Sistema. Tras las actividades anteriores se realiza el Diseo Fsico de Datos, a partir de las clases que se han identificado, especificando las formas de acceder a los datos y la ubicacin de los mismos. El siguiente paso que propone la metodologa, previo a la definicin detallada de los componentes del sistema, es verificar que se han cumplido con los estndares y criterios de diseo que se han marcado para el diseo, as como comprobar que el diseo que se ha realizado hasta ese momento es coherente con el anlisis previo. Tras la verificacin y aceptacin de la arquitectura del sistema se realiza el diseo detallado de los componentes. Esta actividad constituye el diseo detallado del sistema de informacin. Tambin se generan las especificaciones para la construccin del sistema de informacin, a partir del diseo de la arquitectura, los casos de uso y las clases identificadas durante el proceso de diseo. Se debe especificar hasta el pseudocdigo que define la funcionalidad de cada uno de ellos. En la optimizacin se propone un formato que se puede seguir en la definicin de cada componente. Seguidamente se disea la migracin y carga inicial de datos, generando los componentes que resulten necesarios. En la especificacin tcnica del plan de pruebas se describen los distintos niveles de prueba que se pueden llevar a cabo y se ilustra con ejemplos cada uno de ellos. Finalmente, se establecen los requisitos que deber cumplir la documentacin de usuario y as como el entorno en el que el sistema deber ser implantado.

8.

CONSTRUCCIN SISTEMA INFORMACIN

DEL DE

En este proceso se genera el cdigo de los componentes del sistema de informacin, se desarrollan todos los procedimientos de operacin y seguridad y se elaboran todos los manuales de usuario final y de explotacin, con el objetivo de asegurar el correcto funcionamiento del Sistema para su posterior implantacin. En la construccin se parte del resultado del diseo y se implementa el sistema en trminos de componentes, es decir, ficheros de cdigo fuente, scripts, ficheros de cdigo binario, ejecutables y similares [JACOBSON 2000]. La metodologa propone en primer lugar preparar el entorno de construccin, cargando las bases de datos o ficheros necesarios, e instalando los equipos y el software necesario para llevar a cabo la construccin, de acuerdo con los requisitos especificados. Tras la preparacin del entorno de construccin, se lleva a cabo la codificacin de todos los componentes que se han diseado en la fase anterior. Para la documentacin de las pruebas se propone un formato de control para la realizacin de las pruebas en el que se debe incluir la firma de cada uno de los responsables de la realizacin de las pruebas. Durante la construccin de los componentes se llevan a cabo las pruebas de integracin e integracin, y una vez finalizada la construccin se llevan a cabo las pruebas del sistema (las que verifican que todos los subsistemas funcionan conjuntamente), incluyendo las pruebas de volumen que se hayan establecido. La siguiente actividad propuesta por la metodologa es la generacin de los componentes necesarios para la migracin y carga inicial de datos, si son necesarias. La generacin de la documentacin de usuario, que la metodologa ubica en esta fase, en la presente optimizacin se ha decidido trasladar al proceso de Implantacin y Aceptacin del sistema, pues es cuando se forma a los usuarios. Finalmente, una vez realizadas todas las pruebas descritas para esta fase, el equipo del proyecto da su aprobacin al sistema.

RPM-AEMES, VOL. 1, N 2, Agosto 2004

ISSN: 1698-2029

En el proceso de construccin no se han propuesto cambios significativos respecto a las actividades propuestas en la metodologa. Simplemente se han aadido algunos ejemplos y formatos para el control de las pruebas que se realizan.

entorno de operacin. Una vez se ha llevado a cabo la instalacin en el entrono de operacin se realizan las pruebas de implantacin y de aceptacin del sistema. Tras las pruebas se prepara el plan de mantenimiento del sistema, se acuerdan los servicios que en adelante se debern prestar por parte del equipo de desarrollo y finalmente se presenta el sistema para su aprobacin. Finalmente, una vez se ha aprobado y aceptado el sistema por parte del cliente, se pasa produccin, comenzando la explotacin del sistema de informacin.

9.

IMPLANTACIN Y ACEPTACIN DEL SISTEMA

En este proceso se realiza la entrega al cliente del Sistema de Informacin ya construido. En primer lugar se lleva a cabo la definicin del plan de implantacin y se forma a los encargados de llevar a cabo dicha implantacin. Se ha trasladado a esta fase la redaccin de la documentacin de usuario, pues es en esta fase en la que se lleva a cabo la formacin de los usuarios finales. Se complementa la documentacin de usuario propuesta por la metodologa con la redaccin de dos documentos distintos: Manual de usuario: Expone los procesos que el usuario puede realizar con el sistema implantado. Para lograr esto, es necesario que se detallen todas y cada una de las caractersticas que tienen los programas y la forma de acceder e introducir informacin. El manual de usuario permite a los usuarios conocer el detalle de qu actividades debern desarrollar para la consecucin de los objetivos del sistema. Rene la informacin, normas y documentacin necesaria para que el usuario conozca y utilice adecuadamente la aplicacin desarrollada. Manual de Referencia: en el manual de referencia se especifican todas las funcionalidades que se pueden hacer con el sistema. No todo lo que aparezca en el manual de usuario es lo que se puede hacer con el sistema. En el manual de usuario se especifican las funcionalidades que va a necesitar el usuario, y cmo puede utilizarlas. El manual de referencia recoge la funcionalidad completa del sistema, incluyendo llamadas a funciones que puedan realizar los programadores de otro sistema, detalles de administracin, modos de depuracin, etc.

10. DOCUMENTO HISTRICO DE PROYECTO

En la optimizacin se aporta la idea de crear al final del proyecto el documento Histrico de Proyecto. El objetivo del Documento Histrico de Proyecto es recoger en un solo documento toda la informacin relevante que se ha ido recogiendo en diversos documentos a lo largo del ciclo de vida del proyecto. Al incluir dicha informacin en un nico documento, se facilita su consulta para aprovechar la experiencia adquirida en proyectos posteriores. Se propone el siguiente contenido para el documento: Descripcin del proyecto. Ejemplos de funcionamiento. Gestin del Proyecto. o Organizacin del Proyecto. Estructura Organizativa. Lmites Organizativos y Relacin Entre los Participantes o Mtodos Empleados. Tecnologas, equipos y herramientas empleados. Planificacin. o Produccin Software. Estimacin Inicial. Estimacin Final. Datos Reales. Conclusiones. o Documentacin. Listado de todos los documentos que se han generado. o Esfuerzo Estimado vs Esfuerzo Real. o Recursos Computacionales.

Tras la generacin de la documentacin de usuario se lleva a cabo la formacin de los usuarios finales y se lleva a cabo la instalacin del sistema en el

10

RPM-AEMES, VOL. 1, N 2, Agosto 2004

ISSN: 1698-2029

Anlisis de Productividad.

los

Factores

de

que permitan centrar el esfuerzo en aplicar la metodologa, en lugar de pensar en el formato adecuado.

Revisin del Aseguramiento de la Calidad. En este punto se resumen de las revisiones que se han realizado y los resultados que se han obtenido.

12. CONCLUSIONES
En este trabajo se han revisado las actividades y tareas de la metodologa Mtrica Versin 3 del Ministerio de Administraciones Pblicas de Espaa. Se han completado y aclarado las definiciones de las tareas, facilitando su comprensin, aadiendo ejemplos para ayudar en la documentacin de cada una de las fases. Con los cambios de las tareas con respecto a la organizacin propuesta en la metodologa, se pretende mostrar que la metodologa no es una secuencia inamovible de tareas que deben ser ejecutadas en su totalidad y en el orden propuesto: las caractersticas concretas de los proyectos pueden hacer que determinadas tareas no se apliquen, y que otras puedan ser ejecutadas en un orden distinto. Esta es una aportacin que pretende facilitar la aplicacin y comprensin de la metodologa, pero como siempre se puede mejorar. Cada experiencia de aplicacin que se comparta ayudar a mejorar el proceso de desarrollo de software y esto repercutir en la construccin de un software de mayor calidad.

11. MEJORAS PROPUESTAS

Tras la revisin del proceso propuesto por Mtrica V3, hemos identificado la necesidad de adelantar la identificacin de requisitos de usuario a la fase de estudio de viabilidad, y la identificacin de requisitos software a la fase de anlisis. Por otro lado la identificacin de casos de uso y subsistemas queda separada de los requisitos, creando dos caminos que se recorren en paralelo. Por un lado el sistema se define a travs de los requisitos y por otro a travs de casos de uso, diagramas de secuencia, para al final, converger en una nica solucin que no pase nada por alto. El proceso, comenzara en la definicin de requisitos de usuario en el estudio de viabilidad. A partir de los requisitos de usuario se definen los requisitos de software en el anlisis, y a partir de estos se identifican componentes de arquitectura y componentes de bajo nivel en el diseo. En paralelo se realiza un anlisis de casos de uso, identificando clases de anlisis, modelo de datos, y un diseo de clases detallado. Al final, ambos procesos concluyen en una definicin de componentes de bajo nivel, que en la fase de construccin sern implementados. Los interfaces de gestin de proyectos y gestin de configuracin constituyen ejes bsicos para que el proceso reorganizado funcione correctamente. En la gestin del proyecto se deben tener en cuenta los indicadores que muestran que el proyecto evoluciona correctamente, en especial aquellos relacionados con la satisfaccin del cliente y su grado de participacin en el proyecto. Una mtrica adecuada para estos parmetros proporcionar un ndice de modificacin de requisitos ms bajo. En cuanto a la gestin de configuracin, al utilizar dos caminos en paralelo, es fundamental el control de los elementos resultado de cada fase de refinamiento. La trazabilidad entre los elementos de las dos vas se torna crtica, y la utilizacin de herramientas de gestin de configuracin y de gestin de requisitos facilita la labor. Las metodologas no siempre proponen una tcnica o una gua de documentacin concreta a utilizar. Por ello hemos propuesto formatos de documentos

REFERENCIAS
A guide to the project management body of knowledge : PMBOK guide. Project Management Institute, 2000 [PMBOK 2000] Capability Maturity Model (CMMISM), Version 1.1 Software Institute, 2002 [CMMI 2002] Metrica. Versin 3. Ministerio Administraciones Pblicas. [MAP] Integration Engineering de

BRAUDE, Eric J. SOFTWARE ENGENEERING An Object-Oriented Pespective. John Wiley & Sons, INC. [BRAUDE 2001] BURGESS, T.F.; McKee D., Kidd C. Configuration Management in the Aerospace Industry: a review of industry practice. International Journal of Operations & Production Management Volume 25, No 3, 2005. [BURGESS 2005]. CUEVAS AGUSTN, Gonzalo. Gestin del

11

RPM-AEMES, VOL. 1, N 2, Agosto 2004

ISSN: 1698-2029

Proceso Software. Editorial Centro de Estudios Ramn Areces, S.A. [CUEVAS 2002]. JACOBSON, BOOCH, RUMBAUGH. El Proceso Unificado de Desarrollo de Software. Addison Wesley. [JACOBSON 2000]. MONTENEGRO, Maril y GARCA, ngel. Representacin visual de la Gestin de Requisitos en la Gestin de Proyectos Informticos. 30ma Conferencia Latinoamericana de Informtica (CLEI2004) pp.402413. [MONTENEGROa 2004]. MONTENEGRO, Maril; GARCA, ngel; URQUIZA, Alfonso. Information Technology Graphics in the Software Engineering. WSEAS Trans. on INFORMATION SCIENCE and APPLICATIONS, December 2004. [MONTENEGROb 2004]. PRESSMAN, Roger S. Ingeniera del Software. Un Enfoque prctico. Adaptado por Darle Ince. Mc Graw Hill. Quinta Edicin. 2002 [PRESSMAN 2002] RUMBAUGH, James. Modelado y Diseo Orientado a Objetos. Blaha Michael, William Premerlani, Eddy Frederick, Lorensen William. Prentice Hall, 1996. [RUMBAUGH 1996] RUMBAUGH, James. El Lenguaje Unificado de Modelado. Addison Wesley, 2000. [RUMBAUGH 2000] SOMMERVILE, Ian. Integrated Requirements Engineering: A Tutorial. Software, IEEE Volume 22, Issue 1, Jan.-Feb. 2005 Page(s):16 - 23 [SOMERVILLE 2005].

12