Metrica 3.0

Embed Size (px)

Citation preview

  • Ministerio de Administraciones Pblicas

    Introduccin

    NDICE

    INTRODUCCIN ...............................................................................................................................1

    APORTACIONES DE MTRICA VERSIN 3 ......................................................................................2

    PROCESOS PRINCIPALES DE MTRICA VERSIN 3.......................................................................3

    PLANIFICACIN DE S ISTEMAS DE INFORMACIN (PSI) .............................................................................4 DESARROLLO DE SISTEMAS DE INFORMACIN........................................................................................5 ESTUDIO DE V IABILIDAD DEL S ISTEMA (EVS)..............................................................................6 ANLISIS DEL SISTEMA DE INFORMACIN (ASI) ...........................................................................7 DISEO DEL SISTEMA DE INFORMACIN (DSI).............................................................................9 CONSTRUCCIN DEL S ISTEMA DE INFORMACIN (CSI) ............................................................... 11 IMPLANTACIN Y ACEPTACIN DEL S ISTEMA (IAS)..................................................................... 11 MANTENIMIENTO DE SISTEMAS DE INFORMACIN (MSI) ......................................................................... 12

    INTERFACES DE MTRICA VERSIN 3.......................................................................................... 14

    GESTIN DE PROYECTOS ................................................................................................................. 14 SEGURIDAD.................................................................................................................................... 15 GESTIN DE LA CONFIGURACIN ....................................................................................................... 15 ASEGURAMIENTO DE CALIDAD........................................................................................................... 16

  • Ministerio de Administraciones Pblicas

    Participantes

    NDICE

    INTRODUCCIN.................................................................................................................................... 1

    PERFIL DIRECTIVO .............................................................................................................................. 2

    PERFIL JEFE DE PROYECTO .............................................................................................................. 3

    PERFIL CONSULTOR ........................................................................................................................... 4

    PERFIL ANALISTA................................................................................................................................ 5

    PERFIL PROGRAMADOR ..................................................................................................................... 7

  • Participantes 1

    Ministerio de Administraciones Pblicas Metodologa MTRICA Versin 3

    INTRODUCCINMTRICA Versin 3 ha sido concebida para abarcar el desarrollo completo de Sistemas

    de Informacin sea cual sea su complejidad y magnitud, por lo cual su estructura y los perfilesde los participantes que intervienen debern adaptarse y dimensionarse en cada momento deacuerdo a las caractersticas particulares de cada proyecto.

    Para poder exponer una estructura de los participantes que se han identificado a lo largode los procesos de la Metodologa MTRICA Versin 3, se ha optado por establecer una seriede perfiles en los que se encuadran la totalidad de los participantes. Estos perfiles coincidencon los elegidos para el Plan de Formacin y la herramienta de autoformacin en MTRICAVersin 3, obtenindose de este modo una visin homognea de la metodologa. Se haconsiderado que esta es una clasificacin en la que se pueden resumir las funciones yresponsabilidades de los participantes, ya que en la mayora de los casos intervienen en losmismos procesos principales definidos en MTRICA Versin 3 y el conocimiento que han detener sobre la metodologa coincide.

    Los perfiles establecidos son:

    - Directivo

    - Jefe de Proyecto

    - Consultor

    - Analista

    - Programador

    Para cada uno de estos perfiles se analizan una serie de caractersticas importantes a lahora de delimitar su participacin en el proyecto:

    - Correspondencia con Participantes de MTRICA Versin 3.

    - Responsabilidades o funciones a desempear en cada uno de los procesos.

    - Perfil o caractersticas propias de cada uno de los participantes.

  • 2 Participantes

    Metodologa MTRICA Versin 3 Ministerio de Administraciones Pblicas

    PERFIL DIRECTIVODentro de esta categora se agrupan los siguientes participantes:

    - Comit de Direccin

    - Comit de Seguimiento

    - Directores de usuarios

    - Usuarios expertos

    Intervienen en todos los procesos principales de MTRICA Versin 3, siendo susprincipales responsabilidades y funciones similares, si bien dependiendo del proceso estaspueden experimentar pequeas variaciones.

    El perfil requerido para este grupo de participantes incluye a personas con un nivel altoen la direccin de la organizacin, conocimiento de los objetivos estratgicos y de negocioque se persiguen y autoridad para validar y aprobar cada uno de los procesos realizadosdurante el desarrollo del Sistema de Informacin. Adems deben tener un conocimiento delentorno y de la organizacin suficiente para proporcionar, a lo largo de todo el proyecto, unosrequisitos del Sistema adecuados, completos y suficientemente importantes como paraconsiderarse en el catlogo definitivo de requisitos.

    Es responsabilidad del Comit de Direccin proveer los recursos necesarios para elcumplimiento de los objetivos propuestos, revisar y aprobar formalmente cada uno de losprocesos. Este Comit supone la implicacin directa de la alta direccin de la organizacin enel proyecto, si bien su constitucin variar en funcin de las caractersticas del mismo.

    Los Directores de las reas organizativas y de usuarios afectadas por el proyectoaportan informacin sobre las necesidades planteadas y validan los resultados con el fin degarantizar la identificacin, comprensin e incorporacin de todos los requisitos con lasprioridades adecuadas. Esta misma funcin la desempean con mayor nivel de detalle losusuarios expertos de nivel directivo.

    El seguimiento y control del desarrollo del proyecto es responsabilidad del Comit deSeguimiento, que se ocupar de resolver cualquier contingencia que pueda presentarsedurante la ejecucin del mismo y asegurar la disponibilidad de recursos humanos con losperfiles adecuados y su participacin en las actividades donde es necesaria su colaboracin.

  • Participantes 3

    Ministerio de Administraciones Pblicas Metodologa MTRICA Versin 3

    PERFIL JEFE DE PROYECTOLos participantes que se engloban dentro de este perfil son los que se detallan a

    continuacin:

    - Jefe de Proyecto

    - Responsable de Implantacin

    - Responsable de Mantenimiento

    - Responsable de Operacin

    - Responsable de Sistemas

    - Responsable de Seguridad

    - Responsable de Calidad

    Todos ellos ejercen labores de coordinacin y direccin de equipos humanosespecializados en la realizacin de actividades propias de un proceso o interfaz de MTRICAVersin 3. La figura principal es el Jefe de Proyecto, el cual recibe el apoyo de los distintosresponsables durante la realizacin de procesos o determinadas actividades a lo largo delproyecto.

    El Jefe de Proyecto realiza la estimacin del esfuerzo necesario para llevar a cabo elproyecto, selecciona la estrategia de desarrollo, determina la estructura del mismoseleccionando los procesos principales de MTRICA Versin 3 que lo integran, fija elcalendario de hitos y entregas y establece la planificacin del proyecto. Es el encargado dedirigir el proyecto, realizando las labores de seguimiento y control del mismo, revisin yevaluacin de resultados y coordinacin del equipo de proyecto. Se ocupa tambin de lagestin y resolucin de incidencias que puedan surgir durante el desarrollo del proyecto ascomo de la actualizacin de la planificacin inicial. Entre sus funciones se encuentran laelaboracin de los informes de seguimiento y el archivo de la documentacin de gestin delproyecto una vez que este ha finalizado.

    Los Responsables de Implantacin, Operacin, Sistemas y Mantenimiento intervienenen procesos principales de MTRICA Versin 3, ofreciendo apoyo al Jefe de Proyecto durantela realizacin de sus actividades. Poseen mayor conocimiento de los aspectos organizativos yde procedimiento habituales en la organizacin en sus reas de responsabilidad concretas,facilitando el desarrollo de los procesos que afectan a esas reas. Aseguran la disponibilidadde los recursos necesarios y la participacin activa del equipo humano que coordinan.

    Los Responsables de Seguridad y Calidad aportan informacin relativa a las normas yprocedimientos habituales en la organizacin, completndolos en su caso de acuerdo con losrequerimientos particulares del sistema en colaboracin con el Jefe de Proyecto. Ofrecenasesoramiento sobre todos los aspectos de seguridad y calidad relativos tanto al productocomo al proceso seguido para su obtencin, analizando los riesgos y determinando lasmedidas de control oportunas. Coordinan a los integrantes del Equipo de Seguridad y elGrupo de Aseguramiento de la Calidad.

  • 4 Participantes

    Metodologa MTRICA Versin 3 Ministerio de Administraciones Pblicas

    PERFIL CONSULTOREn este perfil se incluyen los siguientes participantes:

    - Consultor

    - Consultor Informtico

    - Consultor de las Tecnologas de la Informacin

    - Consultor de Sistemas de Informacin

    - Especialista en Comunicaciones

    - Tcnico de Sistemas

    - Tcnicos de Comunicaciones

    La principal funcin de los Consultores es asesorar en las cuestiones sobre las quetienen un conocimiento especializado. Se diferencia as entre Consultor, que asesora en losaspectos relativos al negocio y Consultor Informtico, con un nivel de especializacin mayoren los aspectos relacionados con la informtica, su aplicacin e integracin en laorganizacin.

    En el mbito de la Consultora Informtica se distingue entre Tecnologas de laInformacin y Sistemas de Informacin. El Consultor en Tecnologas de la Informacin aportaun mayor conocimiento de las ltimas tecnologas, colabora en la evaluacin de distintasalternativas tecnolgicas y participa en la validacin y seleccin de la solucin ms adecuadapara el sistema a desarrollar, mientras que el Consultor de Sistemas de Informacin ofreceuna opinin experta, pericia o conocimientos relativos a los requisitos del negocio, tcnicos yde usuario que han de tenerse en cuenta en el desarrollo de un sistema de informacin.

    Los Tcnicos y Especialistas en Sistemas y Comunicaciones cuentan con una visinms precisa de la tecnologa existente en la actualidad en la organizacin o que se valoraincorporar, en cuanto a sus requerimientos tcnicos, entorno e infraestructura que precisan,implantacin, integracin con otros sistemas existentes, configuracin y pruebas. Aportan suconocimiento y experiencia prctica a la hora de valorar alternativas tecnolgicas para elsistema de informacin, participando activamente durante su implantacin y puesta enproduccin.

  • Participantes 5

    Ministerio de Administraciones Pblicas Metodologa MTRICA Versin 3

    PERFIL ANALISTAEn el perfil de Analista se agrupan los siguientes participantes de MTRICA Versin 3:

    - Analista

    - Administrador de Bases de Datos

    - Equipo de Arquitectura

    - Equipo de Formacin

    - Equipo de Implantacin

    - Equipo de Operacin

    - Equipo de Seguridad

    - Equipo de Soporte Tcnico

    - Equipo de Proyecto

    - Grupo de Aseguramiento de la Calidad

    La responsabilidad de los Analistas es elaborar un catlogo detallado de requisitos quepermita describir con precisin el sistema de informacin, para lo cual mantendrn entrevistasy sesiones de trabajo con los responsables de la organziacin y usuarios, actuando de elinterlocutor entre stos y el equipo de proyecto en lo que a requerimientos se refiere. Estosrequisitos permiten a los analistas eleborar los distintos modelos que sirven de base para eldiseo, obteniendo los modelos de datos y de procesos en el caso del anlisis estructurado ylos modelos de clases e interaccin de objetos en anlisis orientado a objeto. Asi mismorealizan la especificacin de las interfaces entre el sistema y el usuario.

    El Administrador de Bases de Datos participa en la obtencin del diseo fsico de datos,definiendo la estructura fsica de datos que utilizar el sistema a partir del modelo lgico dedatos normalizado o del modelo de clases, teniendo presentes las caractersticas especficasdel sistema de gestin de base de datos concreto a utilizar, los requisitos establecidos para elsistema de informacin, y las particularidades del entorno tecnolgico, se consiga una mayoreficiencia en el tratamiento de los datos. Si se va a realizar una migracin de datos colaboracon el equipo de proyecto estimando los volmenes de las estructuras de datos implicadas,definiendo los mecanismos de migracin y carga inicial de datos y participando activamenteen su realizacin. Una vez que el sistema est en produccin se ocupa de la gestin yoperativa asociada a las bases de datos y al software en el que estn implementadas.

    Los integrantes del Equipo de Proyecto participan a lo largo de todo el proceso dedesarrollo y mantenimiento del sistema de informacin, si bien su composicin puede irvariando en funcin de las caractersticas del proyecto y del proceso que se est realizando,diferenciando as los Equipos de Implantacin, Operacin, Mantenimiento, Arquitectura,Soporte Tcnico y Seguridad, coordinados por un Resposable de Equipo, cuyas funciones yperfiles estn ms especializadas para la realizacin de un proceso o interfaz concreto.

  • 6 Participantes

    Metodologa MTRICA Versin 3 Ministerio de Administraciones Pblicas

    El Equipo de Formacin es el encargado de preparar e impartir la formacin al equiporesponsable de la implantacin y operacin del sistema, para lo cual se encarga de elaborarun plan de formacin que incluye los cursos de formacin y sus contenidos, as como losrecursos humanos y de infraestructura para llevarlo a cabo. Igualmente define el contenido dela formacin que deber recibir el usuario final del sistema, realizando su seguimiento.

    El Grupo de Aseguramiento de la Calidad, dirigido por el Responsable de Calidad,desarrolla el plan de aseguramiento de calidad especfico para el proyecto, reflejando endicho plan entre otros aspectos las actividades de calidad a realizar (normales oextraordinarias). Participa en la revisin de los productos seleccionados para determinar si sonconformes o no a los procedimientos, normas o criterios especificados, comprobando que sehan llevado a cabo las medidas preventivas o correctoras necesarias. Este grupo escompletamente independiente del equipo de proyecto.

  • Participantes 7

    Ministerio de Administraciones Pblicas Metodologa MTRICA Versin 3

    PERFIL PROGRAMADORDado que la participacin y funciones de los programadores son concretas y limitadas

    a los procesos de Construccin y Mantenimiento de Sistemas de Informacin, el perfil deProgramador hace referencia nicamente al participante Programador descrito en MTRICAVersin 3.

    La funcin del programador, miembro del equipo de proyecto, es construir el cdigoque dar lugar al producto resultante en base al diseo tcnico realizado por el analista oanalista programador, generando tambin el cdigo asociado a los procedimientos demigracin y carga inicial de datos. Igualmente se encarga de la realizacin de las pruebasunitarias y participa en las pruebas de conjunto de la aplicacin.

  • Ministerio de Administraciones Pblicas

    Tcnicas y Prcticas

    NDICE

    INTRODUCCIN............................................................................................................................................... 2

    TCNICAS DE DESARROLLO ........................................................................................................................ 3

    ANLISIS COSTE/BENEFICIO ............................................................................................................................. 3

    CASOS DE USO ................................................................................................................................................ 7

    DIAGRAMA DE CLASES.................................................................................................................................... 12

    DIAGRAMA DE COMPONENTES......................................................................................................................... 18

    DIAGRAMA DE DESCOMPOSICIN .................................................................................................................... 20

    DIAGRAMA DE DESPLIEGUE............................................................................................................................. 21

    DIAGRAMA DE ESTRUCTURA ........................................................................................................................... 23

    DIAGRAMA DE FLUJO DE DATOS (DFD) ........................................................................................................... 33

    DIAGRAMA DE INTERACCIN............................................................................................................................ 47

    Diagrama de secuencia............................................................................................................................ 48

    Diagrama de colaboracin ....................................................................................................................... 51

    DIAGRAMA DE PAQUETES ............................................................................................................................... 53

    DIAGRAMA DE TRANSICIN DE ESTADOS ......................................................................................................... 55

    MODELADO DE PROCESOS DE LA ORGANIZACIN............................................................................................. 57

    SADT (Structured Analysis and Design Technique) ................................................................................ 58

    MODELO ENTIDAD/RELACIN EXTENDIDO........................................................................................................ 61

    NORMALIZACIN............................................................................................................................................. 68

    OPTIMIZACIN................................................................................................................................................ 74

    REGLAS DE OBTENCIN DEL MODELO FSICO A PARTIR DEL LGICO. ................................................................ 75

    REGLAS DE TRANSFORMACIN ....................................................................................................................... 79

    TCNICAS MATRICIALES.................................................................................................................................. 81

    TCNICAS DE GESTIN DE PROYECTOS ................................................................................................. 83

    TCNICAS DE ESTIMACIN .............................................................................................................................. 83

    Mtodo Albrecht para el Anlisis de los Puntos Funcin......................................................................... 84

    Mtodo MARKII para el Anlisis de los Puntos Funcin.......................................................................... 94

    STAFFING SIZE (ORIENTACIN A OBJETOS)............................................................................................... 106

    PLANIFICACIN............................................................................................................................................. 111

  • Tcnicas y Prcticas 1

    Metodologa MTRICA Versin 3 Ministerio de Administraciones Pblicas

    Program Evaluation & Review Technique - PERT................................................................................. 111

    Diagrama de Gantt ................................................................................................................................. 118

    Estructura de Descomposicin de Trabajo (WBS - Work Breakdown Structure) .................................. 123

    Diagrama de Extrapolacin .................................................................................................................... 124

    PRCTICAS.................................................................................................................................................. 126

    ANLISIS DE IMPACTO................................................................................................................................... 126

    CATALOGACIN............................................................................................................................................ 128

    CLCULO DE ACCESOS................................................................................................................................. 129

    CAMINOS DE ACCESO................................................................................................................................... 130

    DIAGRAMA DE REPRESENTACIN .................................................................................................................. 131

    FACTORES CRTICOS DE XITO ..................................................................................................................... 132

    IMPACTO EN LA ORGANIZACIN ..................................................................................................................... 138

    PRESENTACIONES ........................................................................................................................................ 140

    PROTOTIPADO.............................................................................................................................................. 142

    PRUEBAS ..................................................................................................................................................... 144

    Pruebas Unitarias ................................................................................................................................... 144

    Pruebas de Integracin .......................................................................................................................... 145

    Pruebas del Sistema .............................................................................................................................. 146

    Pruebas de Implantacin........................................................................................................................ 147

    Pruebas de Aceptacin .......................................................................................................................... 148

    Pruebas de Regresin............................................................................................................................ 149

    REVISIN FORMAL........................................................................................................................................ 150

    REVISIN TCNICA ....................................................................................................................................... 151

    SESIONES DE TRABAJO................................................................................................................................. 152

    Entrevistas.............................................................................................................................................. 152

    Reuniones .............................................................................................................................................. 153

    JAD (Joint Application Design)............................................................................................................... 154

    JRP (Joint Requirements Planning) ....................................................................................................... 155

    SOPORTE POR HERRAMIENTAS .............................................................................................................. 157

    BIBLIOGRAFA............................................................................................................................................. 159

  • 2 Tcnicas y Prcticas

    Ministerio de Administraciones Pblicas Metodologa MTRICA Versin 3

    INTRODUCCIN El objetivo de este documento es describir las tcnicas utilizadas en los procesos principales

    y en el proceso de Gestin de Proyectos.

    En el proceso de Desarrollo de Sistemas de Informacin se incluyen tanto las tcnicas propias de un desarrollo orientado a objetos como estructurado, ya que las actividades de ambas aproximaciones estn integradas en una estructura comn.

    La metodologa MTRICA Versin 3 proporciona un conjunto de mtodos y tcnicas que gua a los distintos profesionales de Sistemas y Tecnologas de la Informacin y Comunicaciones (STIC) en la obtencin de los diversos productos de los procesos del ciclo de vida de un proyecto informtico. Con el fin de mejorar la productividad de los distintos participantes y asegurar la calidad de los productos resultantes, la mayora de las tcnicas propuestas estn soportadas por herramientas disponibles en el mercado que automatizan en mayor o menor grado su utilizacin. En cualquier caso, no todos los productos resultantes de cada tarea son susceptibles de obtenerse de forma automatizada.

    Se hace una distincin entre tcnicas y prcticas en funcin del propsito al que respondan. Se considera tcnica al conjunto de heursticas y procedimientos que se apoyan en estndares, es decir, que utilizan una o varias notaciones especficas en trminos de sintaxis y semntica y cumplen unos criterios de calidad en cuanto a la forma de obtencin del producto asociado. Las prcticas representan un medio para la consecucin de unos objetivos especficos de manera rpida, segura y precisa, sin necesidad de cumplir unos criterios o reglas preestablecidas.

    Para cada una de las tcnicas y prcticas referenciadas en el documento se explica brevemente el objetivo que se persigue al utilizarlas. Se describen: los elementos bsicos asociados y los principios fundamentales de elaboracin; la notacin utilizada, en el caso de tcnicas grficas, para la representacin de cada uno de los elementos implicados. En los captulos finales se incluye el soporte que ofrecen las herramientas del mercado actualmente para las tcnicas y las referencias bibliogrficas que permitan, a aquellos profesionales que lo deseen, profundizar en un mayor nivel de detalle.

    Por continuidad con MTRICA Versin 2.1 la notacin empleada es la misma para aquellas tcnicas que son comunes en ambas versiones. En el caso de desarrollos orientados a objetos se ha seguido la notacin de UML.

    Es importante resaltar que la notacin que se propone en la aplicacin de la tcnica en ningn caso se considerar obligatoria. Cada organizacin podr utilizar la notacin que desee, la que suele utilizar o la que ofrecen sus herramientas de desarrollo, respetando las reglas y restricciones especficas de las distintas tcnicas.

  • Tcnicas y Prcticas 3

    Metodologa MTRICA Versin 3 Ministerio de Administraciones Pblicas

    TCNICAS DE DESARROLLO Las tcnicas de desarrollo son un conjunto de procedimientos que se basan en reglas y

    notaciones especficas en trminos de sintaxis, semntica y grficos, orientadas a la obtencin de productos en el desarrollo de un sistema de informacin. En desarrollos del tipo estructurado o de orientacin a objetos merecen especial atencin las tcnicas grficas, que proponen smbolos y notaciones estndares para una mejor comprensin de los sistemas o sus componentes. De todos modos, y debido a la diversidad existente, las notaciones aqu propuestas no se consideran obligatorias en la metodologa MTRICA Versin 3, pero s que se deben aplicar rigurosamente sus reglas y validaciones para conseguir el objetivo propuesto con la mayor eficacia.

    Anlisis Coste/Beneficio La tcnica de anlisis coste/beneficio tiene como objetivo fundamental proporcionar una

    medida de los costes en que se incurre en la realizacin de un proyecto y comparar dichos costes previstos con los beneficios esperados de la realizacin de dicho proyecto. Esta medida o estimacin servir para:

    Valorar la necesidad y oportunidad de acometer la realizacin del proyecto. Seleccionar la alternativa ms beneficiosa para la realizacin del proyecto. Estimar adecuadamente los recursos econmicos necesarios en el plazo de realizacin del

    proyecto. Es de destacar la necesidad cada vez mayor de guiarse por criterios econmicos y no slo

    tcnicos para la planificacin de trabajos y proyectos. Por ello se hace una primera introduccin sobre las tcnicas y mtodos de evaluacin de conceptos econmicos, con el fin de proporcionar a los profesionales criterios que les ayuden en la planificacin de proyectos y evaluacin de alternativas.

    Conceptos

    Punto de amortizacin (Break-Even Point)

    Es el momento en el tiempo en que el conjunto de beneficios obtenidos por la explotacin del nuevo sistema iguala al conjunto de costes de todo tipo que ha ocasionado. A partir del punto de amortizacin (Break-Even Point), el sistema entra en fase de aportar beneficios netos a la organizacin.

    Periodo de amortizacin (PayBack)

    Es el periodo de tiempo que transcurre desde que los costes son mximos hasta que se alcanza el punto de amortizacin (Break-Even Point), es decir, en cuanto el sistema empieza a aportar beneficios. Cuanto menor sea el periodo de amortizacin (Payback) de un Sistema, ms atractivo ser para la organizacin acometer su implantacin.

    Retorno de la Inversin - ROI (Return of Investment)

    Es el rendimiento de la inversin expresada en trminos de porcentaje. Se calcula mediante la frmula siguiente:

  • 4 Tcnicas y Prcticas

    Ministerio de Administraciones Pblicas Metodologa MTRICA Versin 3

    ROI = 100 x (Beneficio Neto Anual - Coste Desarrollo Anualizado) / Inversin Promedio

    Siendo:

    Beneficio Neto Anual: Es la ganancia que aporta el sistema como consecuencia de su uso, es decir los beneficios obtenidos ms los gastos no incurridos. Deben restrsele los gastos operacionales anuales y los de mantenimiento del sistema.

    Coste Desarrollo Anualizado: Total del gasto inicial de desarrollo del sistema, dividido por los aos que se supone que va a ser operativo.

    Inversin Promedio: Total de la inversin realizada (costes de desarrollo, hardware, software, etc.) dividido por el total de conceptos en los que se invierte.

    Descripcin

    Para la realizacin del anlisis coste/beneficio se seguirn los siguientes pasos:

    1.- Producir estimaciones de costes/beneficios.

    2.- Determinar la viabilidad del proyecto y su aceptacin.

    1.- PRODUCIR ESTIMACIONES DE COSTES-BENEFICIOS

    Se realizar una lista de todo lo que es necesario para implementar el sistema y una lista de los beneficios esperados del nuevo sistema.

    En general, los costes suelen ser medibles y estimables en unidades econmicas, no as los beneficios, los cuales pueden ser tangibles o no tangibles. En un anlisis de costes y beneficios se deben considerar aquellos aspectos tangibles, es decir, medibles en valores como dinero, tiempo, etc., y no tangibles, es decir, no ponderables de una forma objetiva.

    Entre los beneficios no tangibles pueden estar:

    El aumento de cuentas debido a un mejor servicio a los clientes. La mejora en la toma de decisiones debido a una mejora en el soporte informtico.

    La valoracin de los beneficios no tangibles se debe estimar de una forma subjetiva y ser realizada por las reas correspondientes.

    A menudo es conveniente desglosar los costes estimados a lo largo del proyecto, para ofrecer una informacin ms detallada de la distribucin de los recursos de cara a la direccin.

    En la estimacin de costes se considerarn, entre otros, los siguientes aspectos:

    Adquisicin de hardware y software: El que sea preciso para el desarrollo, implantacin y normal funcionamiento del sistema. Se debe considerar la saturacin de mquinas o sistemas actuales como consecuencia de la entrada en vigor del nuevo sistema.

    Gastos de mantenimiento de hardware y software anteriores. Gastos de comunicaciones: Lneas, telfono, correo, etc. Gastos de instalacin: Cableado, acondicionamiento de sala, recursos humanos y

    materiales, gastos de viaje, etc. Coste de desarrollo del sistema.

  • Tcnicas y Prcticas 5

    Metodologa MTRICA Versin 3 Ministerio de Administraciones Pblicas

    Gastos del mantenimiento del sistema: Coste anual. Gastos de consultora: En caso de requerirse algn consultor externo en cualquier etapa

    del proyecto. Gastos de formacin: De todo tipo (Desarrolladores, Operadores, Implantadores, Usuario

    Final, etc.). Gastos de material: Papel, toner, etc. Costes derivados de la curva de aprendizaje: De todo el personal involucrado:

    Desarrolladores, Tcnicos de Sistemas, Operadores, y desde luego, Usuarios. Costes financieros, de publicidad, etc.

    En la estimacin de beneficios se pueden considerar cuestiones como las siguientes:

    Incremento de la productividad: Ahorro o mejor utilizacin de recursos humanos. Ahorro de gastos de mantenimiento del sistema actual. Ahorros de adquisicin y mantenimiento de hardware y software, o reutilizacin de

    plataformas sustituidas. Incremento de ventas o resultados, disminucin de costes: Producidos por una mejora

    de la gestin (rotacin de stock, "just in time", analtica de clientes, etc.). Ahorro de material de todo tipo: Sustituido por datos electrnicos que proporciona el

    sistema, como por ejemplo: papel, correo, etc. Beneficios financieros. Otros beneficios tangibles: Ahorro de recursos externos, consultora, formacin, etc. Beneficios intangibles: Incremento de la calidad del producto o servicio, mejora de la

    imagen de la compaa, mejora en la atencin al cliente, mejora en la explotacin, etc.

    2.- DETERMINAR LA VIABILIDAD DEL PROYECTO

    Se basar en uno de los mtodos siguientes:

    Retorno de la Inversin:

    Este mtodo consiste en calcular el coste y el beneficio anual, conociendo el coste total al inicio del proyecto "C0, para determinar en qu ao se recupera el coste total inicialmente estimado.

    AO COSTE BENEFICIO BENEFICIO NETO

    0 C0 0

    1 C1 B1 B1 - C1

    2 C2 B2 B2 - C2

    ...

    n Cn Bn Bn - Cn

    El ao de recuperacin de la inversin se produce cuando Beneficio Neto = C0.

    Valor Actual

    Este mtodo permite tener en cuenta que un gasto invertido durante un cierto tiempo produce un beneficio.

  • 6 Tcnicas y Prcticas

    Ministerio de Administraciones Pblicas Metodologa MTRICA Versin 3

    El mtodo consiste en determinar el dinero que es viable invertir inicialmente para que se recupere la inversin en un periodo de tiempo definido previamente.

    El resultado depende del tipo de inters (r) utilizado en la evaluacin.

    Se debe calcular, en primer lugar, el beneficio neto que se obtendr cada ao. Dicho beneficio no es real, ya que se debe estimar el valor real de dicha cantidad en el ao n.

    Para ello se aplica la frmula:

    Valor Actual = Beneficio neto / (1 + r/100)n n = ao 1,..,i

    Se debe estudiar en cuntos aos se recupera la inversin realizada inicialmente, o bien, si en un periodo de aos fijado previamente se retorna la inversin y, por tanto, es viable el proyecto.

    Si la inversin es el C0, se determinar la viabilidad del proyecto consultando la siguiente tabla:

    AO COSTE BENEFICIO VALOR ACTUAL

    0 C0

    1 C1 B1 V.A1 =(B1-C1)/(1+r/100)

    2 C2 B2 V.A2 =(B2-C2)/(1+r/100) 2

    ...

    n Cn Bn V.An =(Bn-Cn)/(1+r/100) n

    El proyecto ser viable si VAi > C0 a lo largo del periodo fijado.

  • Tcnicas y Prcticas 7

    Metodologa MTRICA Versin 3 Ministerio de Administraciones Pblicas

    Casos de Uso Los objetivos de los casos de uso son los siguientes:

    Capturar los requisitos funcionales del sistema y expresarlos desde el punto de vista del usuario.

    Guiar todo el proceso de desarrollo del sistema de informacin. Los casos de uso proporcionan, por tanto, un modo claro y preciso de comunicacin entre

    cliente y desarrollador. Desde el punto de vista del cliente proporcionan una visin de caja negra del sistema, esto es, cmo aparece el sistema desde el exterior sin necesidad de entrar en los detalles de su construccin. Para los desarrolladores, suponen el punto de partida y el eje sobre el que se apoya todo el desarrollo del sistema en sus procesos de anlisis y diseo.

    Descripcin Un caso de uso es una secuencia de acciones realizadas por el sistema, que producen un

    resultado observable y valioso para un usuario en particular, es decir, representa el comportamiento del sistema con el fin de dar respuestas a los usuarios.

    Aquellos casos de uso que resulten demasiado complejos se pueden descomponer en un segundo nivel, en el que los nuevos casos de uso que intervengan resulten ms sencillos y manejables.

    Para especificar este comportamiento existen una serie de recomendaciones o tcnicas que se aplican dependiendo del momento del desarrollo que se est y de la complejidad del caso de uso. Puede ser desde una simple descripcin textual que recoja un requisito funcional a una especificacin del caso de uso, e incluso un conjunto de diagramas:

    Especificacin de un caso de uso

    Un caso de uso recoge, en un primer momento, una descripcin general. Esta descripcin reflejar posiblemente uno o varios requisitos funcionales del sistema o formar parte de algn requisito.

    Se puede completar la descripcin definiendo cules son las precondiciones y postcondiciones del sistema, es decir, qu condiciones deben cumplirse para que se realice un caso de uso y cules son aquellas condiciones que se cumplen posteriormente al caso de uso.

    Tambin se pueden enumerar los diferentes escenarios del caso de uso si los tuviese y dar una breve descripcin de ellos. Los escenarios son los distintos caminos por los que puede evolucionar un caso de uso, dependiendo de las condiciones que se van dando en su realizacin.

    Diagrama de casos de uso

    Estos diagramas presentan dos tipos de elementos fundamentales:

    Actores. Un actor es algo o alguien que se encuentra fuera del sistema y que interacta con l. En general, los actores sern los usuarios del sistema y los sistemas externos al que se est desarrollando. Si se habla de usuarios, un actor es el papel que puede llevar a cabo en cuanto a su forma de interactuar con el sistema, es decir, un nico actor puede representar

  • 8 Tcnicas y Prcticas

    Ministerio de Administraciones Pblicas Metodologa MTRICA Versin 3

    a muchos usuarios diferentes y de la misma forma, un usuario puede actuar como actores diferentes.

    Casos de uso. Un caso de uso representa el comportamiento que ofrece el sistema de informacin desde el punto de vista del usuario. Tpicamente ser un conjunto de transacciones ejecutadas entre el sistema y los actores. Para facilitar la comprensin de los casos de uso del sistema de informacin en el anlisis, es posible agruparlos en paquetes segn funcionalidades semejantes o relacionadas. Adems de estos elementos, un diagrama de casos de uso presenta relaciones. Las

    relaciones pueden tener lugar entre actores y casos de uso o entre casos de uso.

    La relacin entre un actor y un caso de uso es una relacin de comunicacin, que indica que un actor interviene en el caso de uso. Normalmente, el actor aporta informacin para la realizacin de un caso de uso o recibe informacin como resultado de la realizacin del mismo, por ello, esta relacin puede ser unidireccional o bidireccional, aunque generalmente se muestra como bidireccional, ya que no es necesario especificar en detalle estas relaciones.

    La relacin entre casos de uso es una relacin unidireccional. Esta relacin puede presentar uno de los dos siguientes tipos: usa y extiende.

    La relacin usa se utiliza cuando se quiere reflejar un comportamiento comn en varios casos de uso. Es decir, si los casos de uso A y B presentan una parte comn, sta se puede sacar a un tercer caso de uso C. Entonces, habr una relacin usa del caso de uso A al C y otra del B al C.

    La relacin extiende se utiliza cuando se quiere reflejar un comportamiento opcional de un

    caso de uso. Por ejemplo, se tiene el caso de uso A que representa un comportamiento habitual del sistema. Sin embargo, dependiendo de algn factor, este caso de uso puede presentar un comportamiento adicional o ligeramente diferente, que se podra reflejar en un caso de uso B. En este caso, habr una relacin extiende del caso de uso B al A.

    A

    C

    B

    A

    C

    B

    A B

    >

    A B

    >

  • Tcnicas y Prcticas 9

    Metodologa MTRICA Versin 3 Ministerio de Administraciones Pblicas

    Notacin El diagrama de casos de uso es un grafo de actores, casos de uso y las relaciones entre

    estos elementos.

    Opcionalmente, los casos de uso se pueden enmarcar en un cuadrado que representa los lmites del sistema.

    Caso de Uso

    Un caso de uso se representa mediante una elipse con el nombre del caso de uso dentro o debajo.

    Actor

    Un actor se representa con una figura de hombre de palo con el nombre del actor debajo de la figura.

    Relacin

    Dependiendo del tipo de relacin, la representacin en los diagramas ser distinta. As pues, las relaciones entre un actor y un caso de uso se representan mediante una lnea continua entre ellos. Las relaciones entre casos de uso se representan con una flecha discontinua con el nombre del tipo de relacin como etiqueta. En las relaciones extensin la flecha parte del caso de uso con el comportamiento adicional hacia aquel que recoge el comportamiento bsico y en las relaciones usa desde el caso de uso bsico hacia el que representa el comportamiento comn.

    Paquete

    Casode uso

    Nombre Actor

    >

    Nombre Actor

    Caso 1 Caso 2

  • 10 Tcnicas y Prcticas

    Ministerio de Administraciones Pblicas Metodologa MTRICA Versin 3

    Un paquete se representa con un icono con forma de carpeta y con el nombre colocado en la pestaa. Los paquetes tambin pueden formar diagramas que complementen al diagrama de casos de uso (ver Diagrama de paquetes).

    (Nota.- Esta notacin es la ms habitual, pero MTRICA Versin 3 no exige su utilizacin).

    Paquete

  • Tcnicas y Prcticas 11

    Metodologa MTRICA Versin 3 Ministerio de Administraciones Pblicas

    Ejemplo

    Estudio de una aplicacin que se encarga de la gestin de los prstamos y reservas de libros y revistas en una biblioteca.

    Bibliotecario

    Bibliotecario

    Borrar o Actualizar Ttulo

    Aadir Ttulo

    Aadir Ejemplar

    Mantenimiento

    Borrar Ejemplar

    Prestatario

    Devolucin de Ejemplar

    Hacer Reserva

    Borrar Reserva

    Prestar Ejemplar

    BD

    Informacinprestatario

  • 12 Tcnicas y Prcticas

    Ministerio de Administraciones Pblicas Metodologa MTRICA Versin 3

    Diagrama de Clases El objetivo principal de este modelo es la representacin de los aspectos estticos del

    sistema, utilizando diversos mecanismos de abstraccin (clasificacin, generalizacin, agregacin).

    Descripcin El diagrama de clases recoge las clases de objetos y sus asociaciones. En este diagrama se

    representa la estructura y el comportamiento de cada uno de los objetos del sistema y sus relaciones con los dems objetos, pero no muestra informacin temporal.

    Con el fin de facilitar la comprensin del diagrama, se pueden incluir paquetes como elementos del mismo, donde cada uno de ellos agrupa un conjunto de clases.

    Este diagrama no refleja los comportamientos temporales de las clases, aunque para mostrarlos se puede utilizar un diagrama de transicin de estados, otra de las tcnicas propuestas en MTRICA Versin 3.

    Los elementos bsicos del diagrama son:

    Clases

    Una clase describe un conjunto de objetos con propiedades (atributos) similares y un comportamiento comn. Los objetos son instancias de las clases.

    No existe un procedimiento inmediato que permita localizar las clases del diagrama de clases. stas suelen corresponderse con sustantivos que hacen referencia al mbito del sistema de informacin y que se encuentran en los documentos de las especificaciones de requisitos y los casos de uso.

    Dentro de la estructura de una clase se definen los atributos y las operaciones o mtodos:

    Los atributos de una clase representan los datos asociados a los objetos instanciados por esa clase.

    Las operaciones o mtodos representan las funciones o procesos propios de los objetos de una clase, caracterizando a dichos objetos. El diagrama de clases permite representar clases abstractas. Una Clase abstracta es una

    clase que no puede existir en la realidad, pero que es til conceptualmente para el diseo del modelo orientado a objetos. Las clases abstractas no son instanciables directamente sino en sus descendientes. Una clase abstracta suele ser situada en la jerarqua de clases en una posicin que le permita ser un depsito de mtodos y atributos para ser compartidos o heredados por las subclases de nivel inferior.

    Las clases y en general todos los elementos de los diagramas, pueden estar clasificados de acuerdo a varios criterios, como por ejemplo su objetivo dentro de un programa. Esta clasificacin adicional se expresa mediante un Estereotipo. Algunos de los autores de mtodos OO, establecen una clasificacin de todos los objetos que pueden aparecer en un modelo. Los tipos son:

    Objetos Entidad.

  • Tcnicas y Prcticas 13

    Metodologa MTRICA Versin 3 Ministerio de Administraciones Pblicas

    Objetos lmite o interfaz. Objetos de control.

    stos son estereotipos de clases. Un estereotipo representa una la meta-clasificacin de un elemento.

    Dependiendo de la herramienta utilizada, tambin se puede aadir informacin adicional a las clases para mostrar otras propiedades de las mismas, como son las reglas de negocio, responsabilidades, manejo de eventos, excepciones, etc.

    Relaciones

    Los tipos ms importantes de relaciones estticas entre clases son los siguientes:

    Asociacin. Las relaciones de asociacin representan un conjunto de enlaces entre objetos o instancias de clases. Es el tipo de relacin ms general, y denota bsicamente una dependencia semntica. Por ejemplo, una Persona trabaja para una Empresa. Cada asociacin puede presentar elementos adicionales que doten de mayor detalle al tipo de relacin: Rol, o nombre de la asociacin, que describe la semntica de la relacin en el sentido

    indicado. Por ejemplo, la asociacin entre Persona y Empresa recibe el nombre de trabaja para, como rol en ese sentido.

    Multiplicidad, que describe la cardinalidad de la relacin, es decir, especifica cuntas instancias de una clase estn asociadas a una instancia de la otra clase. Los tipos de multiplicidad son: Uno a uno, uno a muchos y muchos a muchos.

    Herencia. Las jerarquas de generalizacin/especializacin se conocen como herencia. Herencia es el mecanismo que permite a una clase de objetos incorporar atributos y mtodos de otra clase, aadindolos a los que ya posee. Con la herencia se refleja una relacin es_un entre clases. La clase de la cual se hereda se denomina superclase, y la que hereda subclase. La generalizacin define una superclase a partir de otras. Por ejemplo, de las clases profesor y estudiante se obtiene la superclase persona. La especializacin o especificacin es la operacin inversa, y en ella una clase se descompone en una o varias subclases. Por ejemplo, de la clase empleado se pueden obtener las subclases secretaria, tcnico e ingeniero.

    Agregacin. La agregacin es un tipo de relacin jerrquica entre un objeto que representa la totalidad de ese objeto y las partes que lo componen. Permite el agrupamiento fsico de estructuras relacionadas lgicamente. Los objetos son-parte-de otro objeto completo. Por ejemplo, motor, ruedas, carrocera son parte de automvil.

    Composicin. La composicin es una forma de agregacin donde la relacin de propiedad es ms fuerte, e incluso coinciden los tiempos de vida del objeto completo y las partes que lo componen. Por ejemplo, en un sistema de Mquina de caf, las relaciones entre la clase mquina y producto, o entre mquina y depsito de monedas, son de composicin.

    Dependencia. Una relacin de dependencia se utiliza entre dos clases o entre una clase y una interfaz, e indica que una clase requiere de otra para proporcionar alguno de sus servicios.

    Interfaces

    Una interfaz es una especificacin de la semntica de un conjunto de operaciones de una clase o paquete que son visibles desde otras clases o paquetes. Normalmente, se corresponde con una parte del comportamiento del elemento que la proporciona.

  • 14 Tcnicas y Prcticas

    Ministerio de Administraciones Pblicas Metodologa MTRICA Versin 3

    Paquetes

    Los paquetes se usan para dividir el modelo de clases del sistema de informacin, agrupando clases u otros paquetes segn los criterios que sean oportunos. Las dependencias entre ellos se definen a partir de las relaciones establecidas entre los distintos elementos que se agrupan en estos paquetes (ver Diagrama de paquetes).

    Notacin

    Clases

    Una clase se representa como una caja, separada en tres zonas por lneas horizontales.

    En la zona superior se muestra el nombre de la clase y propiedades generales como el estereotipo. El nombre de la clase aparece centrado y si la clase es abstracta se representa en cursiva. El estereotipo, si se muestra, se sita sobre el nombre y entre el smbolo: >.

    La zona central contiene una lista de atributos, uno en cada lnea. La notacin utilizada para representarlos incluye, dependiendo del detalle, el nombre del atributo, su tipo y su valor por defecto, con el formato:

    visibilidad nombre : tipo = valor-inicial { propiedades }

    La visibilidad ser en general publica (+), privada (-) o protegida (#), aunque puede haber otros tipos de visibilidad dependiendo del lenguaje de programacin empleado.

    En la zona inferior se incluye una lista con las operaciones que proporciona la clase. Cada operacin aparece en una lnea con formato:

    visibilidad nombre (lista-de-parmetros): tipo-devuelto { propiedad }

    La visibilidad ser en general publica (+), privada (-) o protegida (#), aunque como con los atributos, puede haber otros tipos de visibilidad dependiendo del lenguaje de programacin. La lista de parmetros es una lista con los parmetros recibidos en la operacin separados por comas. El formato de un parmetro es:

    nombre : tipo = valor-por-defecto

    La notacin especificada se puede simplificar segn el nivel de detalle con el que se quiera trabajar en un momento dado.

    + botonBuscarTtulo_Pulsado ( )+ botonBuscarPrestatario_Pulsado( )+ botonOk_Pulsado ()+ botonCancelar_Pulsado ()+ ttuloResultado ()+ prestatarioResultado ()- comprobarEstado ()+ FormularioDeReservas ( )# botonEliminarTtulo ( )

    >Formulario de Reservas

    + ttulo : Titulo+ prestatario: Informacion_prestatario

  • Tcnicas y Prcticas 15

    Metodologa MTRICA Versin 3 Ministerio de Administraciones Pblicas

    Relaciones

    Una relacin de asociacin se representa como una lnea continua entre las clases asociadas. En una relacin de asociacin, ambos extremos de la lnea pueden conectar con la misma clase, indicando que una instancia de una clase, est asociada a otras instancias de la misma clase, lo que se conoce como asociacin reflexiva.

    La relacin puede tener un nombre y un estereotipo, que se colocan junto a la lnea. El nombre suele corresponderse con expresiones verbales presentes en las especificaciones, y define la semntica de la asociacin. Los estereotipos permiten clasificar las relaciones en familias y se escribirn entre el smbolo: >.

    Las diferentes propiedades de la relacin se pueden representar con la siguiente notacin:

    Multiplicidad: La multiplicidad puede ser un nmero concreto, un rango o una coleccin de nmeros. La letra n y el smbolo * representan cualquier nmero.

    Orden: Se puede especificar si las instancias guardan un orden con la palabra clave {ordered}. Si el modelo es suficientemente detallado, se puede incluir una restriccin que indique el criterio de ordenacin.

    Navegabilidad: La navegacin desde una clase a la otra se representa poniendo una flecha sin relleno en el extremo de la lnea, indicando el sentido de la navegacin.

    Rol o nombre de la asociacin: Este nombre se coloca junto al extremo de la lnea que esta unida a una clase, para expresar cmo esa clase hace uso de la otra clase con la que mantiene la asociacin.

    Adems, existen notaciones especficas para los otros tipos de relacin, como son:

    Agregacin: Se representa con un rombo hueco en la clase cuya instancia es una agregacin de las instancias de la otra.

    Composicin: Se representa con un rombo lleno en la clase cuya instancia contiene las instancias de la otra clase.

    Dependencia: Una lnea discontinua con una flecha apuntando a la clase cliente. La relacin puede tener un estereotipo que se coloca junto a la lnea, y entre el smbolo: >.

    Herencia: Esta relacin se representa como una lnea continua con una flecha hueca en el extremo que apunta a la superclase.

    - atributo1 : Tipo- atributo2 : Tipo

    + mtodo1( )+ mtodo2( )

    Clase

    - atributo1 : Tipo- atributo2 : Tipo

    + mtodo1( )+ mtodo2( )

    Clase

    Nombre de asociacin (Rol)

    1 1.. *- atributo1 : Tipo- atributo2 : Tipo

    + mtodo1( )+ mtodo2( )

    Clase

    - atributo1 : Tipo- atributo2 : Tipo

    + mtodo1( )+ mtodo2( )

    Clase

    - atributo1 : Tipo- atributo2 : Tipo

    + mtodo1( )+ mtodo2( )

    Clase

    - atributo1 : Tipo- atributo2 : Tipo

    + mtodo1( )+ mtodo2( )

    Clase

    Nombre de asociacin (Rol)

    1 1.. *

    AGREGACIN COMPOSICIN HERENCIA DEPENDENCIA

  • 16 Tcnicas y Prcticas

    Ministerio de Administraciones Pblicas Metodologa MTRICA Versin 3

    Interfaces

    Una interfaz se representa como una caja con compartimentos, igual que las clases. En la zona superior se incluye el nombre y el estereotipo . La lista de operaciones se coloca en la zona inferior, igual que en las representaciones de clases. La zona en la que se listan los atributos estar vaca o puede omitirse.

    Existe una representacin ms simple para la interfaz: un crculo pequeo asociado a una clase con el nombre de la interfaz debajo. Las operaciones de la interfaz no aparecen en esta representacin; si se quiere que aparezcan, debe usarse la primera notacin.

    Entre una clase que implementa las operaciones que una interfaz ofrece y esa interfaz se establece una relacin de realizacin que, dependiendo de la notacin elegida, se representar con una lnea continua entre ellas cuando la interfaz se representa como un crculo y con una flecha hueca discontinua apuntando a la interfaz cuando se represente como una clase.

    Paquetes

    Los paquetes se representan mediante un icono con forma de carpeta y las dependencias con flechas discontinuas entre los paquetes dependientes (ver Diagrama de paquetes).

    Datos

    >Datos

    obtenerTtulo ()asignarTtulo()obtenerAutor()asignarAutor ()....

    Ttulo Ejemplar

    Datos

    >Datos

    obtenerTtulo ()asignarTtulo()obtenerAutor()asignarAutor ()....

    Ttulo Ejemplar

  • Tcnicas y Prcticas 17

    Metodologa MTRICA Versin 3 Ministerio de Administraciones Pblicas

    Ejemplo

    Estudio del sistema encargado de la gestin de prstamos y reservas de libros y revistas de una biblioteca. Dependiendo del momento del desarrollo el diagrama estar ms o menos detallado. As, el diagrama tendra la siguiente estructura en el proceso de anlisis:

    (Nota.- Esta notacin es la ms habitual, pero MTRICA Versin 3 no exige su utilizacin).

    0..*

    >Informacin del

    prestatarionombre : String

    tiene / tienen

    hace referencia a /es prestado en

    tiene

    hace referercia a / es reservado en

    - id : Integer- nombre : String

    Prstamo

    - direcc : String

    - estado : String- cdigo : String

    EjemplarTtulo

    - tiempo pendiente : Dias = 30- tiempo pendiente: Dias = 10

    fecha : Fecha = fecha_actual

    + encontrar sobre ttulo( )+ crear( )+ destruir( )+ encontrar( )

    + crear( )

    - autor : String- isbn : String- nmero de reserva

    + encontrar( )+ crear( )+ destruir( )

    - fecha : Fecha = fecha_Actual

    Ttulo del libro

    Reserva

    + crear( )+ destruir( )+ encontrar( )

    + encontrar( )

    + destruir( )

    + crear( )+ destruir( )+ encontrar( )

    Ttulo de revista

    0..1

    0..*

    0..1

    0..*

    0..* copia de

    0..*

    0..*

    0..*

    { ordered }

    0..*

    0..*

    >Informacin del

    prestatarionombre : String

    tiene / tienen

    hace referencia a /es prestado en

    tiene

    hace referercia a / es reservado en

    - id : Integer- nombre : String

    Prstamo

    - direcc : String

    - estado : String- cdigo : String

    EjemplarTtulo

    - tiempo pendiente : Dias = 30- tiempo pendiente: Dias = 10

    fecha : Fecha = fecha_actual

    + encontrar sobre ttulo( )+ crear( )+ destruir( )+ encontrar( )

    + crear( )

    - autor : String- isbn : String- nmero de reserva

    + encontrar( )+ crear( )+ destruir( )

    - fecha : Fecha = fecha_Actual

    Ttulo del libro

    Reserva

    + crear( )+ destruir( )+ encontrar( )

    + encontrar( )

    + destruir( )

    + crear( )+ destruir( )+ encontrar( )

    Ttulo de revista

    0..1

    0..*

    0..1

    0..*

    0..* copia de

    0..*

    0..*

    0..*

    { ordered }

    0..*

  • 18 Tcnicas y Prcticas

    Ministerio de Administraciones Pblicas Metodologa MTRICA Versin 3

    Diagrama de Componentes El diagrama de componentes proporciona una visin fsica de la construccin del sistema de

    informacin. Muestra la organizacin de los componentes software, sus interfaces y las dependencias entre ellos.

    Descripcin Como ya se ha indicado, los elementos de estos diagramas son los componentes software y

    las dependencias entre ellos.

    Un componente es un mdulo de software que puede ser cdigo fuente, cdigo binario, un ejecutable, o una librera con una interfaz definida. Una interfaz establece las operaciones externas de un componente, las cuales determinan una parte del comportamiento del mismo. Adems se representan las dependencias entre componentes o entre un componente y la interfaz de otro, es decir uno de ellos usa los servicios o facilidades del otro.

    Estos diagramas pueden incluir paquetes que permiten organizar la construccin del sistema de informacin en subsistemas y que recogen aspectos prcticos relacionados con la secuencia de compilacin entre componentes, la agrupacin de elementos en libreras, etc.

    Notacin

    Componente

    Un componente se representa como un rectngulo, con dos pequeos rectngulos superpuestos perpendicularmente en el lado izquierdo.

    Para distinguir distintos tipos de componentes se les puede asignar un estereotipo, cuyo nombre estar dentro del smbolo: >

    Interfaz

    Se representa como un pequeo crculo situado junto al componente que lo implementa y unido a l por una lnea continua. La interfaz puede tener un nombre que se escribe junto al crculo. Un componente puede proporcionar ms de una interfaz.

    Paquete

    Un paquete se representa con un icono de carpeta (ver Diagrama de Paquetes).

  • Tcnicas y Prcticas 19

    Metodologa MTRICA Versin 3 Ministerio de Administraciones Pblicas

    Relacin de dependencia

    Una relacin de dependencia se representa mediante una lnea discontinua con una flecha que apunta al componente o interfaz que provee del servicio o facilidad al otro. La relacin puede tener un estereotipo que se coloca junto a la lnea, entre el smbolo: .

    Ejemplo.

    Sistema encargado de la gestin de los prstamos y reservas de libros y revistas en una biblioteca. El lenguaje de desarrollo ser Java, y los accesos a la informacin del prestatario sern mediante un paquete de Base de Datos.

    (Nota.- Esta notacin es la ms habitual, pero MTRICA Versin 3 no exige su utilizacin).

    Ejemplar.java Prstamo.java

    Ttulo.java Reserva.java

    BD

    Informacinprestatario

  • 20 Tcnicas y Prcticas

    Ministerio de Administraciones Pblicas Metodologa MTRICA Versin 3

    Diagrama de Descomposicin El objetivo del diagrama de descomposicin es representar la estructura jerrquica de un

    dominio concreto.

    Descripcin La tcnica es una estructura por niveles que se lee de arriba abajo y de izquierda a derecha,

    donde cada elemento se puede descomponer en otros de nivel inferior y puede ser descrito con el fin de aclarar su contenido.

    El diagrama de descomposicin, tambin conocido como diagrama jerrquico, tomar distintos nombres en funcin del dominio al que se aplique. En el caso de MTRICA Versin 3, se utilizan los diagramas de descomposicin funcional, de descomposicin organizativo y de descomposicin en dilogos.

    Notacin Los elementos del dominio que se est tratando se representan mediante un rectngulo,

    que contiene un nombre que lo identifica. Las relaciones de unos elementos con otros se representan mediante lneas que los conectan.

    Ejemplo.

    Diagrama de Descomposicin Organizativo:

    (Nota.- Esta notacin es la ms habitual, pero MTRICA Versin 3 no exige su utilizacin).

    Direccin General

    rea 1

    Subdireccin 1

    rea 2

    Subdireccin 3Subdireccin 2

    Direccin General

    rea 1

    Subdireccin 1

    rea 2

    Subdireccin 3Subdireccin 2

  • Tcnicas y Prcticas 21

    Metodologa MTRICA Versin 3 Ministerio de Administraciones Pblicas

    Diagrama de Despliegue El objetivo de estos diagramas es mostrar la disposicin de las particiones fsicas del

    sistema de informacin y la asignacin de los componentes software a estas particiones. Es decir, las relaciones fsicas entre los componentes software y hardware en el sistema a entregar.

    Descripcin En estos diagramas se representan dos tipos de elementos, nodos y conexiones, as como

    la distribucin de componentes del sistema de informacin con respecto a la particin fsica del sistema.

    En MTRICA Versin 3 se propone una definicin concreta de nodo, prescindiendo de determinados detalles, pero permitiendo una continuidad tanto en el diseo como en la construccin del sistema de informacin. Con este fin, se utiliza el nodo como particin fsica o funcional real, pero sin descender a detalles de infraestructura o dimensionamiento; por ejemplo, interesa si el nodo procesador es arquitectura Intel, pero no tanto si tiene dos o cuatro procesadores.

    Las conexiones representan las formas de comunicacin entre nodos.

    Adems, a cada nodo se le asocia un subsistema de construccin que agrupa componentes software, permitiendo de este modo, determinar la distribucin de estos componentes. Por lo tanto, un diagrama de despliegue puede incluir, dependiendo del nivel de detalle, todos los elementos descritos en la tcnica de diagrama de componentes, adems los nodos y las conexiones propios de esta tcnica.

    Notacin

    Nodo

    Se representa con la figura de un cubo. El nodo se etiqueta con un nombre representativo de la particin fsica que simboliza. Se pueden asociar a los nodos subsistemas de construccin.

    Conexin

    Las conexiones se representan con una lnea continua que une ambos nodos y pueden tener una etiqueta que indique el tipo de conexin. (ejemplo: canal, red, protocolo, etc.)

  • 22 Tcnicas y Prcticas

    Ministerio de Administraciones Pblicas Metodologa MTRICA Versin 3

    Ejemplo.

    El diagrama representa una arquitectura compuesta por un servidor central de lgica de negocio y acceso a datos, en un monitor de teleproceso de tipo XXX, al cual hay conectados 10 servidores departamentales, con clientes (100) e impresora conectados a cada uno de ellos. No interesa tanto recoger en el diagrama la infraestructura real (la exactitud de la configuracin, nmero de procesadores que pueden cambiar con el tiempo y en principio no afecta ni al diseo ni a la construccin), como el tipo genrico de los servidores, los volmenes en el caso de que sean significativos (por ejemplo: 100 puestos por departamento).

    (Nota.- Esta notacin es la ms habitual, pero MTRICA Versin 3 no exige su utilizacin).

    10

    IPX

    CLIENTE

    B.D.RELACIONAL

    XXX

    100

    IMPRESORALASER

    SERVIDOR DPTO.SERVIDOR LGICA DE NEGOCIO IP (WAN)

    IP

    GUIUtilidades

    Gestin datos

    Obj. negocio

    MONITOR DETELEPROCESO

    XXXMONITOR DE

    TELEPROCESOYYY

    10

    10

    IPX

    CLIENTE

    B.D.RELACIONAL

    XXX

    100

    IMPRESORALASER

    SERVIDOR DPTO.SERVIDOR LGICA DE NEGOCIO IP (WAN)

    IP

    GUIUtilidades

    Gestin datos

    Obj. negocio

    MONITOR DETELEPROCESO

    XXXMONITOR DE

    TELEPROCESOYYY

    10

  • Tcnicas y Prcticas 23

    Metodologa MTRICA Versin 3 Ministerio de Administraciones Pblicas

    Diagrama de Estructura El objetivo de este diagrama es representar la estructura modular del sistema o de un

    componente del mismo y definir los parmetros de entrada y salida de cada uno de los mdulos.

    Para su realizacin se partir del modelo de procesos obtenido como resultado de la aplicacin de la tcnica de diagrama de flujo de datos (DFD).

    Descripcin Un diagrama de estructura se representa en forma de rbol con los siguientes elementos:

    Mdulo: divisin del software clara y manejable con interfaces modulares perfectamente definidas. Un mdulo puede representar un programa, subprograma o rutina dependiendo del lenguaje a utilizar. Admite parmetros de llamada y retorno. En el diseo de alto nivel hay que ver un mdulo como una caja negra, donde se contemplan exclusivamente sus entradas y sus salidas y no los detalles de la lgica interna del mdulo. Para que se reduzca la complejidad del cambio ante una determinada modificacin, es necesario que los mdulos cumplan las siguientes condiciones: Que sean de pequeo tamao. Que sean independientes entre s. Que realicen una funcin clara y sencilla.

    Conexin: representa una llamada de un mdulo a otro. Parmetro: informacin que se intercambia entre los mdulos. Pueden ser de dos tipos en

    funcin de la clase de informacin a procesar: Control: son valores de condicin que afectan a la lgica de los mdulos llamados.

    Sincronizan la operativa de los mdulos. Datos: informacin compartida entre mdulos y que es procesada en los mdulos

    llamados. Otros componentes que se pueden representar en el diagrama de estructura son:

    Mdulo predefinido: es aquel mdulo que est disponible en la biblioteca del sistema o de la propia aplicacin, y por tanto no es necesario codificarlo.

    Almacn de datos: es la representacin fsica del lugar donde estn almacenados los datos del sistema.

    Dispositivo fsico: es cualquier dispositivo por el cual se puede recibir o enviar informacin que necesite el sistema.

  • 24 Tcnicas y Prcticas

    Ministerio de Administraciones Pblicas Metodologa MTRICA Versin 3

    Estructuras del diagrama

    Existen ciertas representaciones grficas que permiten mostrar la secuencia de las llamadas entre mdulos. Las posibles estructuras son:

    Secuencial: un mdulo llama a otros mdulos una sola vez y, se ejecutan de izquierda a derecha y de arriba abajo.

    Repetitiva: cada uno de los mdulos inferiores se ejecuta varias veces mientras se cumpla

    una condicin.

    Alternativa: cuando el mdulo superior, en funcin de una decisin, llama a un mdulo u

    otro de los de nivel inferior.

    Principios del diseo estructurado

    El diagrama de estructura se basa en tres principios fundamentales:

    La descomposicin de los mdulos, de manera que los mdulos que realizan mltiples funciones se descompongan en otros que slo realicen una. Los objetivos que se persiguen con la descomposicin son: Reducir el tamao del mdulo. Hacer el sistema ms fcil de entender y modificar y por lo tanto facilitar el

    mantenimiento del mismo. Minimizar la duplicidad de cdigo.

  • Tcnicas y Prcticas 25

    Metodologa MTRICA Versin 3 Ministerio de Administraciones Pblicas

    Crear mdulos tiles. La jerarqua entre los mdulos, de forma que los mdulos de niveles superiores coordinen a

    los de niveles inferiores. Al dividir los mdulos jerrquicamente, es posible controlar el nmero de mdulos que interactan con cualquiera de los otros.

    La independencia de los mdulos, de manera que cada mdulo se ve como una caja negra, y nicamente es importante su funcin y su apariencia externa, y no los detalles de su construccin.

    Estrategias de diseo

    Dependiendo de la estructura inicial del diagrama de flujo de datos sobre el que se va a realizar el diseo, existen dos estrategias para obtener el diagrama de estructura. El uso de una de las dos estrategias no implica que la otra no se utilice, eso depender de las caractersticas de los procesos representados en el DFD. Estas estrategias son:

    Anlisis de transformacin. Anlisis de transaccin.

    1.- Anlisis de Transformacin

    El anlisis de transformacin es un conjunto de pasos que permiten obtener, a partir de un DFD con caractersticas de transformacin, la estructura del diseo de alto nivel del sistema. Un DFD con caractersticas de transformacin es aqul en el que se pueden distinguir:

    Flujo de llegada o entrada. Flujo de transformacin o centro de transformacin que contiene los procesos esenciales del

    sistema y es independiente de las caractersticas particulares de la entrada y la salida. Flujo de salida.

    Los datos que necesita el sistema se recogen por los mdulos que se encuentren en las ramas de la izquierda, de modo que los datos que se intercambian en esa rama sern ascendentes. En las ramas centrales habr movimiento de informacin compartida, tanto ascendente como descendente. En las ramas de la derecha, la informacin ser de salida y, por lo tanto, descendente.

    Los pasos a realizar en el anlisis de transformacin son:

    1. Identificar el centro de transformacin. Para ello ser necesario delimitar los flujos de llegada y salida de la parte del DFD que contiene las funciones esenciales del sistema.

    2. Realizar el primer nivel de factorizacin o descomposicin del diagrama de estructura. Habr que identificar tres mdulos subordinados a un mdulo de control del sistema:

    Mdulo controlador del proceso de informacin de entrada. Mdulo controlador del centro de transformacin. Mdulo controlador del proceso de la informacin de salida.

    3. Elaborar el segundo nivel de factorizacin. Se transforma cada proceso del DFD en un mdulo del diagrama de estructura.

    4. Revisar la estructura del sistema utilizando medidas y guas de diseo.

  • 26 Tcnicas y Prcticas

    Ministerio de Administraciones Pblicas Metodologa MTRICA Versin 3

    A continuacin se muestra un grfico explicativo de dicha estrategia de diseo:

    B

    E

    CF H

    I

    SISTEMA

    OBTENERDATOS

    C

    OBTENERDATOS

    E

    CENTRO DETRANSFORMACIN

    PRODUCIRDATOS

    J

    OBTENERDATOS

    B

    MODULOF

    MODULOH

    MODULOI

    LEER LEER ESCRIBIR

    Estrategia de Anlisis de Transformacin

    Informacin de Entrada

    Informacin de Salida

    Centro de Transformacin

    J

    B

    E

    CF H

    I

    SISTEMA

    OBTENERDATOS

    C

    OBTENERDATOS

    E

    CENTRO DETRANSFORMACIN

    PRODUCIRDATOS

    J

    OBTENERDATOS

    B

    MODULOF

    MODULOH

    MODULOI

    LEERLEER LEERLEER ESCRIBIRESCRIBIR

    Estrategia de Anlisis de Transformacin

    Informacin de Entrada

    Informacin de Salida

    Centro de Transformacin

    J

  • Tcnicas y Prcticas 27

    Metodologa MTRICA Versin 3 Ministerio de Administraciones Pblicas

    2.- Anlisis de Transaccin

    El anlisis de transaccin se aplica cuando en un DFD existe un proceso que en funcin del flujo de llegada, determina la eleccin de uno o ms flujos de informacin.

    Se denomina centro de transaccin al proceso desde el que parten los posibles caminos de informacin. Los pasos a realizar en el anlisis de transaccin son:

    1. Identificar el centro de transaccin. Se delimita la parte del DFD en la que a partir de un camino de llegada se establecen varios caminos de accin.

    2. Transformar el DFD en la estructura adecuada al proceso de transacciones. El flujo de transacciones se convierte en una estructura de programa con una bifurcacin de entrada y una de salida.

    3. Factorizar la estructura de cada camino de accin. Cada camino se convierte en una estructura que se corresponde con las caractersticas especficas del flujo (de transaccin o de transformacin).

    4. Refinar la estructura del sistema utilizando medidas y guas de diseo.

  • 28 Tcnicas y Prcticas

    Ministerio de Administraciones Pblicas Metodologa MTRICA Versin 3

    A continuacin se muestra un grfico explicativo de dicha estrategia de diseo:

    Validar transaccin

    Validar transaccin

    Validar transaccin

    Actualizar transaccin

    Actualizar transaccin

    Actualizar transaccin

    ANLISISTRANSAC.

    C

    ANLISISTRANSAC.

    A

    ANLISISTRANSAC.

    B

    SISTEMA

    ANALIZARTRANSACCION

    PROCESAMIENTOTRANSACCION

    PROCESARTRANSAC.

    A

    PROCESARTRANSAC.

    B

    PROCESARTRANSAC.

    C

    Estrategia de Anlisis de Transaccin

    Imprimir

    A

    B

    C

    Centro de Transaccin

    Determinar tipo

    transaccin

    IMPRIMIR

    Validar transaccin

    Validar transaccin

    Validar transaccin

    Validar transaccin

    Actualizar transaccin

    Actualizar transaccin

    Actualizar transaccin

    ANLISISTRANSAC.

    C

    ANLISISTRANSAC.

    A

    ANLISISTRANSAC.

    B

    SISTEMA

    ANALIZARTRANSACCION

    PROCESAMIENTOTRANSACCION

    PROCESARTRANSAC.

    A

    PROCESARTRANSAC.

    B

    PROCESARTRANSAC.

    C

    Estrategia de Anlisis de Transaccin

    ImprimirImprimir

    A

    B

    C

    Centro de Transaccin

    Determinar tipo

    transaccin

    IMPRIMIR

  • Tcnicas y Prcticas 29

    Metodologa MTRICA Versin 3 Ministerio de Administraciones Pblicas

    Evaluacin del diseo

    Una vez que hayan sido elaborados los diagramas de estructura, habr que evaluar el diseo estudiando distintos criterios y medidas. Se utilizan dos mtricas que miden la calidad estructural de un diseo:

    Acoplamiento. Cohesin.

    El acoplamiento se puede definir como el grado de interdependencia existente entre los mdulos, por tanto, depende del nmero de parmetros que se intercambian. El objetivo es que el acoplamiento sea el mnimo posible, es decir, conseguir que los mdulos sean lo ms independientes entre s.

    Es deseable un bajo acoplamiento, debido a que cuantas menos conexiones existan entre dos mdulos, menor ser la posibilidad de que aparezcan efectos colaterales al modificar uno de ellos. Adems, se mejora el mantenimiento, porque al cambiar un mdulo por otro, hay menos riesgo de actualizar la lgica interna de los mdulos asociados. Los diferentes grados de acoplamiento son:

    De datos: los mdulos se comunican mediante parmetros que constituyen elementos de datos simples.

    De marca: es un caso particular del acoplamiento de datos, dnde la comunicacin entre mdulos es travs de estructuras de datos.

    De control: aparece cuando uno o varios de los parmetros de comunicacin son de control, es decir variables que controlan las decisiones de los mdulos subordinados o superiores.

    Externo: los mdulos estn ligados a componentes externos (dispositivos E/S, protocolos de comunicaciones, etc.).

    Comn: varios mdulos hacen referencia a un rea comn de datos. Los mdulos asociados al rea comn de datos pueden modificar los valores de los elementos de datos o estructuras de datos que se incluyen en dicha rea.

    De contenido: ocurre cuando un mdulo cualquiera accede o hace uso de los datos de una parte de otro mdulo. La cohesin es una medida de la relacin funcional de los elementos de un mdulo, es

    decir, la sentencia o grupo de sentencias que lo componen, las llamadas a otros mdulos o las definiciones de los datos. Un mdulo con alta cohesin realiza una tarea concreta y sencilla.

    El objetivo es intentar obtener mdulos con una cohesin alta o media. Los distintos niveles de cohesin, de mayor a menor, son:

    Funcional: todos los elementos que componen el mdulo estn relacionados en el desarrollo de una nica funcin.

    Secuencial: un mdulo empaqueta en secuencia varios mdulos con cohesin funcional. De comunicacin: todos los elementos de procesamiento utilizan los mismos datos de

    entrada y de salida. Procedimental: todos los elementos de procesamiento de un mdulo estn relacionados y

    deben ejecutarse en un orden determinado. En este tipo existe paso de controles. Temporal: un mdulo contiene tareas relacionadas por el hecho de que todas deben

    realizarse en el mismo intervalo de tiempo. Lgica: un mdulo realiza tareas relacionadas de forma lgica (por ejemplo un mdulo que

    produce todas las salidas independientemente del tipo). Casual: un mdulo realiza un conjunto de tareas que tienen poca o ninguna relacin entre s.

  • 30 Tcnicas y Prcticas

    Ministerio de Administraciones Pblicas Metodologa MTRICA Versin 3

    Un buen diseo debe ir orientado a conseguir que los mdulos realicen una funcin sencilla e independiente de las dems (mxima cohesin), y que la dependencia con otros mdulos sea mnima (acoplamiento mnimo), lo cual facilita el mantenimiento del diseo.

    Notacin

    Mdulo

    Se representa mediante un rectngulo con su nombre en el interior.

    Un mdulo predefinido se representa aadiendo dos lneas verticales y paralelas en el interior del rectngulo

    Conexin

    Se representa mediante una lnea terminada en punta de flecha cuya direccin indica el mdulo llamado. Para llamadas a mdulos estticos se utiliza trazo continuo y para llamadas a mdulos dinmicos trazo discontinuo.

    Parmetros

    La representacin vara segn su tipo: control (flags) o datos.

    REALIZAR PRESTAMO

    IMPRIMIRCHEQUE

    DEPAGO

    IMPRIMIRCHEQUE

    DEPAGO

    B

    A Mdulo quellama

    Conexin

    Mdulollamado

    Conexin esttica

    Conexin dinmica

  • Tcnicas y Prcticas 31

    Metodologa MTRICA Versin 3 Ministerio de Administraciones Pblicas

    Almacn de datos

    Dispositivo fsico

    (Nota.- Esta notacin es la ms habitual, pero MTRICA Versin 3 no exige su utilizacin).

    OBTENER CONTRATO

    ENCONTRAR EMPLEADO

    Control

    Datos

    Nombre del clienteNmero de

    contratoNmero de contrato correcto

    OBTENER CONTRATO

    ENCONTRAR EMPLEADO

    Control

    Datos

    Control

    Datos

    Nombre del clienteNmero de

    contratoNmero de contrato correcto

    NOMBRE

    NOMBRE

  • 32 Tcnicas y Prcticas

    Ministerio de Administraciones Pblicas Metodologa MTRICA Versin 3

    Ejemplo.

    El siguiente ejemplo muestra un proceso de emisin de cheques para el pago de nminas de los empleados de una empresa. En l se diferencian los clculos relativos a los trabajadores empleados por horas y los que poseen contrato. La lectura del fichero de empleados y la impresin de los cheques son mdulos ya disponibles en las libreras del sistema, es decir, mdulos predefinidos.

    LEER REGISTRODE PAGO

    EMITIR CHEQUES

    EMPLEADOS

    IMPRIMIRCHEQUEDE PAGO

    OBTENERNETO

    POR HORAS

    CALCULARNETO PORCONTRATO

    CALCULAR BRUTO

    POR HORAS

    CALCULARDEDUCCIONES

    NORMALES

    CALCULAROTRAS

    DEDUCCIONES

    Nmeroempleado

    Nombreempleado

    CALCULARNETO

    EMPLEADO

    Pagosueldoneto

    Registropagosalario

    Registropagohoras

    Pagonetohoras

    Fin defichero

    Registroempleado

    Tarifanormal

    Pagas

    Tarifaporhoras

    Horastrabajadas Pago

    brutocontrato

    Pagobrutohoras

    Pagobrutohoras

    Pagobrutocontrato

    Descuentosimpuestos

    Deduccionesnormales

    Retencinimpuestos

    Deduccionesnormales

    Pagoneto

    Registropago Pago

    empleado

  • Tcnicas y Prcticas 33

    Metodologa MTRICA Versin 3 Ministerio de Administraciones Pblicas

    Diagrama de Flujo de Datos (DFD) El objetivo del diagrama de flujo de datos es la obtencin de un modelo lgico de procesos

    que represente el sistema, con independencia de las restricciones fsicas del entorno. As se facilita su comprensin por los usuarios y los miembros del equipo de desarrollo.

    El sistema se divide en distintos niveles de detalle, con el objetivo de:

    Simplificar la complejidad del sistema, representando los diferentes procesos de que consta. Facilitar el mantenimiento del sistema.

    Descripcin Un diagrama de flujo de datos es una tcnica muy apropiada para reflejar de una forma clara

    y precisa los procesos que conforman el sistema de informacin. Permite representar grficamente los lmites del sistema y la lgica de los procesos, estableciendo qu funciones hay que desarrollar. Adems, muestra el flujo o movimiento de los datos a travs del sistema y sus transformaciones como resultado de la ejecucin de los procesos.

    Esta tcnica consiste en la descomposicin sucesiva de los procesos, desde un nivel general, hasta llegar al nivel de detalle necesario para reflejar toda la semntica que debe soportar el sistema en estudio.

    El diagrama de flujo de datos se compone de los siguientes elementos:

    Entidad externa: representa un ente ajeno al sistema que proporciona o recibe informacin del mismo. Puede hacer referencia a departamentos, personas, mquinas, recursos u otros sistemas. El estudio de las relaciones entre entidades externas no forma parte del modelo. Puede aparecer varias veces en un mismo diagrama, as como en los distintos niveles del DFD para mejorar la claridad del diagrama.

    Proceso: representa una funcionalidad que tiene que llevar a cabo el sistema para transformar o manipular datos. El proceso debe ser capaz de generar los flujos de datos de salida a partir de los de entrada, ms una informacin constante o variable al proceso. El proceso nunca es el origen ni el final de los datos, puede transformar un flujo de datos de entrada en varios de salida y siempre es necesario como intermediario entre una entidad externa y un almacn de datos.

    Almacn de datos: representa la informacin en reposo utilizada por el sistema independientemente del sistema de gestin de datos (por ejemplo un. fichero, base de datos, archivador, etc.). Contiene la informacin necesaria para la ejecucin del proceso. El almacn no puede crear, transformar o destruir datos, no puede estar comunicado con otro almacn o entidad externa y aparecer por primera vez en aquel nivel en que dos o ms procesos accedan a l.

    Flujo de datos: representa el movimiento de los datos, y establece la comunicacin entre los procesos y los almacenes de datos o las entidades externas. Un flujo de datos entre dos procesos slo es posible cuando la informacin es sncrona, es decir, el proceso destino comienza cuando el proceso origen finaliza su funcin. Los flujos de datos que comunican procesos con almacenes pueden ser de los siguientes tipos:

  • 34 Tcnicas y Prcticas

    Ministerio de Administraciones Pblicas Metodologa MTRICA Versin 3

    De consulta: representan la utilizacin de los valores de uno o ms campos de un almacn o la comprobacin de que los valores de los campos seleccionados cumplen unos criterios determinados.

    De actualizacin: representan la alteracin de los datos de un almacn como consecuencia de la creacin de un nuevo elemento, por eliminacin o modificacin de otros ya existentes.

    De dilogo: es un flujo entre un proceso y un almacn que representa una consulta y una actualizacin.

    Existen sistemas que precisan de informacin orientada al control de datos y requieren flujos y procesos de control, as como los mecanismos que desencadenan su ejecucin. Para que resulte adecuado el anlisis de estos sistemas, se ha ampliado la notacin de los diagramas de flujo de datos incorporando los siguientes elementos:

    Proceso de control: representa procesos que coordinan y sincronizan las actividades de otros procesos del diagrama de flujo de datos.

    Flujo de control: representa el flujo entre un proceso de control y otro proceso. El flujo de control que sale de un proceso de control activa al proceso que lo recibe y el que entra le informa de la situacin de un proceso. A diferencia de los flujos tradicionales, que pueden considerarse como procesadores de datos porque reflejan el movimiento y transformacin de los mismos, los flujos de control no representan datos con valores, sino que en cierto modo, se trata de eventos que activan los procesos (seales o interrupciones).

    Descomposicin o explosin por niveles

    Los diagramas de flujo de datos han de representar el sistema de la forma ms clara posible, por ello su construccin se basa en el principio de descomposicin o explosin en distintos niveles de detalle.

    La descomposicin por niveles se realiza de arriba abajo (top-down), es decir, se comienza en el nivel ms general y se termina en el ms detallado, pasando por los niveles intermedios necesarios. De este modo se dispondr de un conjunto de particiones del sistema que facilitarn su estudio y su desarrollo.

    La explosin de cada proceso de un DFD origina otro DFD y es necesario comprobar que se mantiene la consistencia de informacin entre ellos, es decir, que la informacin de entrada y de salida de un proceso cualquiera se corresponde con la informacin de entrada y de salida del diagrama de flujo de datos en el que se descompone.

    En cualquiera de las explosiones puede aparecer un proceso que no necesite descomposicin. A ste se le denomina Proceso primitivo y slo se detalla en l su entrada y su salida, adems de una descripcin de lo que realiza. En la construccin hay que evitar en lo posible la descomposicin desigual, es decir, que un nivel contenga un proceso primitivo, y otro que necesite ser particionado en uno o varios niveles ms.

    El modelo de procesos deber contener:

    Un diagrama de contexto (Nivel 0). Un diagrama 0 (Nivel 1). Tantos diagramas 1, 2, 3, ... n como funciones haya en el diagrama 0 (Nivel 2). Tantos niveles intermedios como sea necesario. Varios DFD en el ltimo nivel de detalle.

    El diagrama de contexto tiene como objetivo delimitar el mbito del sistema con el mundo exterior definiendo sus interfaces. En este diagrama se representa un nico proceso que

  • Tcnicas y Prcticas 35

    Metodolo