TRABAJO INVESTIGATIVO 02

PRESENTADO POR:

Steven Acosta Cdigo: 20041078002 Camilo Gaviria Cdigo: 20041078 Yesid Tibaquira Cdigo: 20041078111

Profesor: JUAN GUEVARA

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS FACULTAD TECNOLOGICA TECNOLOGIA EN SISTEMAS GRUPO 2 ANALISIS DE SISTEMAS BOGOTA D.C 2006

TABLA DE CONTENIDO 1 2 2.1 2.2 3 3.1 3.2 3.3 3.4 4 INTRODUCCION CICLO DE VIDA DEL SOFTWARE Descripcin del ISO/IEC 12207-1 Descripcin del ISO/IEC 15504-2 CONCEPTOS Ciclo de vida del software Proceso de desarrollo de software Metodologa de desarrollo de software Proyecto de software METODOLOGIA DE DESARROLLO DE SOFTWARE 01 3 4 4 8 10 10 12 12 17 18 18 18 18 21 23 27 27 27 28 40

4.1 Nombre : OMT (Object Modeling Technique Tcnica de Modelado de Objetos). 4.2 4.3 4.4 4.5 5 5.1 5.2 5.3 5.4 Caractersticas Etapas Diagramas utilizados en cada etapa Ejemplo Explicativo METODOLOGA DE DESARROLLO DE SOFTWARE 02. Nombre: Mtrica 3 Caractersticas. Etapas Diagramas utilizados en cada etapa.

5.5 6 7

Ejemplo explicativo CONCLUSIONES BIBLIOGRAFIA

56 62 64

INTRODUCCION

El presente trabajo explica dos normas sobre los procesos del ciclo de vida de un proyecto de software, y la valoracin del proyecto en cada proceso, tomando en cuenta que en el presente la forma de desarrollar software, ha cambiado, ya no, se implementa la forma de sentar a programar, y en donde el nico objetivo era el de conseguir un producto que solo funcione, sin tener en cuenta la calidad con la que fue hecho, la metodologa que se utiliz, buena o mala, pero lo importante era el producto y que funcionara bien. Pero, ahora, esta forma ha cambiado. Hay metodologas, bien elaboradas, con mucho tiempo de trabajo, que se encargan de producir software de calidad, software eficiente y eficaz, porque de esta manera la sociedad est creando productos. La era del mucho tiempo de programacin pas, a la era de mucho tiempo de modelamiento, de definir la estructura lgica, de un software, para luego darle el pequeo toque de la programacin. Con el desarrollo de estas metodologas, aparecen nuevos lenguajes de programacin, los cuales hacen fcil el trabajo en conjunto con estas herramientas. Sin embargo, tomamos como referencia dos metodologas: OMT(Tcnica de modelado de objetos), que enfatiza ms en la parte estructural del sistema, y Mtrica 3, que se puede implementar en cualquier etapa de desarrollo en un software, basndose en las prioridades, de cada subproceso. Con el fin de presentar dos metodologas, para desarrollar software, y dos estndares, que se establecieron, los cuales representan las formas generales de realizar un sistema de informacin, se elabora este trabajo.

2 2.1

CICLO DE VIDA DEL SOFTWARE

DESCRIPCIN DEL ISO/IEC 12207-1

La norma NBR ISO/IEC 12207 Procesos del ciclo de vida del software tiene como principal objetivo ofrecer una estructura comn para que todos aquellos que se encuentren relacionados directamente con el software utilicen un lenguaje comn. La estructura de la norma fue concebida de manera que fuera flexible, modular y adaptable a las necesidades de quien la utiliza. Para esto esta fundamentada en dos principios bsicos: Modularidad y responsabilidad. Modularidad en el sentido de procesos con mnimo acoplamiento y mximo de cohesin. Responsabilidad en el sentido de establecer una responsabilidad nica a cada proceso, facilitando la aplicacin de la norma en proyectos donde varias personas pueden estar vinculadas. Conforme a lo mencionado anteriormente la norma est compuesta por una serie de procesos, actividades y tareas que pueden ser adaptadas de acuerdo con los proyectos de software. Estos procesos son clasificados en tres tipos: Fundamentales, de apoyo y organizacionales. Los procesos de apoyo y organizacionales deben existir independientemente de la organizacin y del proyecto que se este ejecutando. Los procesos fundamentales son definidos de acuerdo con la situacin.

Procesos Fundamentales Son los responsables de la generacin de los productos de software, constituyendo el ciclo de vida propiamente dicho. Son representados por los siguientes procesos: Proceso de adquisicin: Define las actividades del propietario, u organizacin que adquiere un sistema de producto de software. Se inicia con la definicin de la necesidad de adquirir un sistema, producto o servicio de software. El proceso continua con la preparacin y emisin del pedido de propuesta, seleccionando el proveedor o gerencia del proceso de adquisicin a travs de la aceptacin del sistema, producto o servicio de software. Proceso de suministro: Define las actividades del proveedor, u organizacin que provee un producto de software al propietario. El proceso puede ser iniciado tanto por una decisin de preparar una propuesta para responder a un pedido propuesto por un cliente, cuando se asignatura un contrato para el desarrollo de un sistema, producto o servicio de software. El proceso continua con la determinacin de los procedimientos y recursos para gestionar y garantizar el proyecto. Incluido en desarrollo y la ejecucin de los planos del proyecto incluso en la entrega del sistema, producto o servicio de software para el cliente. Proceso de desarrollo: Define las actividades del desarrollador, o la entidad que define el desarrollo del producto de software. El proceso contiene las actividades

para el anlisis de los requisitos, proyecto, codificacin, integracin pruebas, instalacin y aceptacin relacionadas con los productos de software. Proceso de explotacin: Define las actividades del operario, u organizacin que provee el servicio de operacin de un sistema de computacin en un ambiente de operacin para sus usuarios. El proceso sobre la operacin de un producto de software y el soporte operacional a los usuarios. Proceso de mantenimiento: Define las actividades del personal u organizacin que provee el servicio de mantenimiento del software, esto es gestin de modificaciones en el software para mantenerlo actualizado y en perfecta operacin. Este proceso es realizado cuando el producto de software es sometido a modificaciones en el cdigo o en la documentacin asociada debido a un problema o a necesidades de mejora y adaptacin. El objetivo es modificar un producto de software existente preservando su integridad.

Proceso de apoyo Tiene como objetivo ayudar otros procesos, verificando principalmente la calidad en el suceso del proyecto. Estn representados por los: Proceso de documentacin: Define las actividades para el registro de informacin producida por un proceso o actividad del ciclo de vida. El proceso contiene un conjunto de actividades que planea, proyecta, desenvuelve produce, edita, distribuye y mantiene los documentos necesarios a todos los interesados tal como gerentes, ingenieros, y usuarios del sistema o producto de software. Gestin de configuracin: Define las actividades para la aplicacin de procedimientos administrativos y tcnicos para todo un ciclo de vida de software, destinado a identificar y definir los tems de software un sistema y establecer sus lneas bsicas (baseline); controlar las modificaciones y liberacin de tems. Registrar y presentar la situacin de los tems y los pedidos de modificacin. Garantizar la finalizacin y consistencia en la correccin de los tems, y controlar el almacenamiento y manipulacin de la distribucin de los tems. Aseguramiento de la calidad: Define las actividades para el suministro de una garanta adecuada en los procesos y productos de software, no en el ciclo de vida del proyecto. Estarn en conformidad con los requisitos especificados y adherentes a los planos establecidos.

Proceso de verificacin: Define las actividades para la verificacin de los productos de software. En un propsito para determinar si los productos de software de una actividad atienden completamente los requisitos o las condiciones impuestas. Proceso de validacin: Define las actividades para a validacin de los productos producidos por el proyecto de software. Es un proceso para determinar si los requisitos o el producto final (sistema de software) atienden el uso especfico propuesto. Proceso de revisin conjunta: Define las actividades para avalar la situacin de productos de una actividad de un proyecto son apropiadas. Las revisiones conjuntas son hechas tanto en los niveles de gestin del proyecto, con en los niveles tcnicos y son ejecutadas durante la vigencia del contrato. Proceso de Auditoria: Define las actividades para determinar adecuacin en los requisitos, planos y contrato, cuando es apropiado. Proceso de resolucin de problemas: Define un proceso para analizar y resolver los problemas (incluyendo inconformidades), de cualquier naturaleza o fuente, que sean descubiertos durante la ejecucin del desarrollo, operacin y mantenimiento o en otros procesos. El objetivo es proveer los medios en el tiempo adecuado y de forma responsable y documentada para garantizar que todos los problemas encontrados se han analizado y resuelto. Procesos de la organizacin Tiene como objetivo garantizar y mejorar los procesos dentro de la organizacin. Son representados por los: Procesos de gestin: Define las actividades genricas que pueden ser entregada por cualquiera de las partes que tienen que gestionar su(s) respectivo(s) proceso(s). El gerente es el responsable de la gestin del producto, gestin del proyecto y gestin de tareas de los procesos aplicables tales como adquisicin, suministro, desarrollo, operacin, mantenimiento y los procesos de apoyo. Procesos de infraestructura: Define las actividades para establecer y mantener la infraestructura necesaria para cualquier otro proceso. La infraestructura puede incluir hardware, software, herramientas, tcnicas, patrones y recursos para el desarrollo, operacin y mantenimiento.

Proceso de mejora: define las actividades bsicas que una organizacin ejecuta para establecer, avalar, medir, controlar y mejorar un proceso del ciclo de vida del software. Proceso de formacin: Define las actividades para proveer y mantener el personal capacitado. La adquisicin, suministro, o desarrollo, y operacin o mantenimiento de productos de software son extremamente dependientes del personal con conocimiento y calificacin. Por tanto, es esencial que el entrenamiento sea planeado e implementado con anterioridad para que el personal entrenado este disponible cuando el producto de software fuera adquirido, suministrado, desarrollado, operado, o mantenido. 2.2 DESCRIPCIN DEL ISO/IEC 15504-2

ISO/IEC 15504-2:2003 define los requisitos por realizar la valoracin del proceso como una base para el uso en la mejora del proceso y determinacin de capacidad. La valoracin del proceso esta basada en dos modelos dimensionales que contienen una dimensin del proceso y una dimensin de capacidad. La dimensin del proceso se proporciona por un modelo de referencia de proceso externo que define un conjunto de procesos caracterizado por las declaraciones de propsito del proceso y los resultados del proceso. La dimensin de capacidad consiste en un marco a la medida que comprende seis niveles de proceso y nivela los atributos asociados al proceso. La valoracin del rendimiento consiste en un conjunto de rangos para cada atributo de proceso para cada proceso evaluado, tambin puede incluir el nivel de capacidad logrado por ese proceso. ISO/IEC 15504-2:2003 identifica las dimensiones del marco para la capacidad del proceso y los requisitos para: Realizar una valoracin Modelos de referencia de proceso Modelos de valoracin de proceso Verificar la conformidad de evaluacin del proceso

Los requisitos para la valoracin de procesos definida en ISO/IEC 15504-2:2003 forma una estructura que: Posibilita la autovaloracin Provee una base para la mejora del proceso y determinacin de capacidad Toma en la cuenta el contexto en que el proceso evaluado se lleva a cabo Produce una valoracin del proceso Direcciona la capacidad del proceso para lograr su propsito; Es aplicable en todos los dominios de la aplicacin y tamaos de organizacin y puede proporcionar una referencia objetiva entre las organizaciones. El conjunto mnimo de requisitos definido en ISO/IEC 15504-2:2003 asegura que los resultados de la valoracin sean objetivos, imparciales, consistentes, y representativos de los procesos evaluados. Pueden compararse los resultados de las valoraciones de los procesos cuando se considera que los alcances de las valoraciones son similares.

CONCEPTOS

3.1

CICLO DE VIDA DEL SOFTWARE

Conjunto de procesos que se siguen para construir, entregar y hacer evolucionar el software, desde la concepcin desde una idea hasta la entrega y el retiro del sistema. Su objetivo principal es determinar el orden de las etapas involucradas en el desarrollo del software. Establecer un criterio de transicin para progresar de una etapa a la siguiente: Criterio para determinar la finalizacin. Criterio para comenzar y elegir la siguiente. De acuerdo con la IEEE el ciclo de vida del software es: Una aproximacin lgica a la adquisicin, el suministro, el desarrollo, la exploracin y el mantenimiento del software. IEEE 1074 El ciclo de vida del software se divide en varios procesos principales: Proceso de adquisicin. Proceso de suministro. Proceso de desarrollo. Proceso de exploracin. Proceso de mantenimiento. Y en subprocesos de soporte: Proceso de documentacin Proceso de gestin de la configuracin Proceso de aseguramiento de la calidad Proceso de verificacin Proceso de validacin Proceso de revisin conjunta Proceso de auditoria Proceso de resolucin de problemas

10

Conformando as los procesos generales: Proceso de gestin Proceso de infraestructura Proceso de mejora Proceso de formacin. El ciclo de vida de software se desarrolla mediante modelos de desarrollo software, entre los que tenemos: El modelo en cascada El modelo incremental El modelo de prototipo El modelo en espiral El modelo remolino Entre otros.

11

3.2

PROCESO DE DESARROLLO DE SOFTWARE

El proceso de desarrollo de software puede definirse como un conjunto de herramientas, mtodos y prcticas que se emplean para producir software. Como cualquier otra organizacin, las dedicadas al desarrollo de software mantienen entre sus principales fines, la produccin de software de acuerdo con la planificacin inicial realizada, adems de una constante mejora con el fin de lograr los tres objetivos ltimos de cualquier proceso de produccin: alta calidad y bajo coste, en el mnimo tiempo. La gestin de un proceso de desarrollo de software engloba, por tanto, todas las funciones que mantengan a un proyecto dentro de unos objetivos de coste, calidad y duracin previamente estimados. La mayora de estas funciones y tcnicas de gestin y control empleadas, se han importado de otras industrias de produccin que desarrollaron estos mtodos a principios de siglo. 3.3 METODOLOGA DE DESARROLLO DE SOFTWARE

Las metodologas de desarrollo de software son un conjunto de procedimientos, tcnicas y ayudas a la documentacin para el desarrollo de productos software. Mtrica Metodologa de desarrollo, de sistemas de informacin diseada por Ministerio de Administraciones Publicas (MAP), con la colaboracin de asesores de COOPERS & LYBRAND y promovidas por el consejo superior de informtica (CSI). Para su uso en proyectos informtico de las Administraciones Publicas, por su carcter pblico se permite el uso de mtrica en empresas pblicas y privadas, sin necesitar una autorizacin de los organismos que han intervenido en su desarrollo. Mtrica es una metodologa que permite su utilizacin en las fases de planificacin, anlisis, diseo, construccin e implantacin de sistemas de informacin. La metodologa mtrica permite crear un desarrollo de sistemas que: Soluciona las necesidades y objetivos considerados prioritarios por la definicin de requisitos por el cliente. Necesidades de los usuarios, as como los presupuestos y duracin estimados.

12

Utiliza mtodos procesos y herramientas en los que prima la calidad del desarrollo. La generacin de documentacin para minimizar costes de mantenimiento. Se adaptan a la evolucin del sistema a lo largo del tiempo. La mtrica no encaja dentro del Ciclo de Vida Clsico, ni prototipos ni espiral, sino que selecciona e integra elementos de los modelos anteriormente estudiados. Permite empleo de herramientas CASE y lenguaje de cuarta generacin, que facilitan el desarrollo. Limitaciones de la mtrica: Soporte necesario para actividades y gestin de proyectos, gestin de calidad y gestin de configuracin. Metodologa OMT (Rumbaugh) La metodologa OMT (Object Modeling Technique) fue creada por James Rumbaugh y Michael Blaha en 1991, mientras James diriga un equipo de investigacin de los laboratorios General Electric. OMT es una de las metodologas de anlisis y diseo orientadas a objetos ms maduras y eficientes que existen en la actualidad. La gran virtud que aporta esta metodologa es su carcter de abierta (no propietaria), que le permite ser de dominio pblico y, en consecuencia, sobrevivir con enorme vitalidad. Esto facilita su evolucin para acoplarse a todas las necesidades actuales y futuras de la ingeniera de software. Las fases que conforman a la metodologa OMT son: Anlisis. El analista construye un modelo del dominio del problema, mostrando sus propiedades ms importantes. El modelo de anlisis es una abstraccin resumida y precisa de lo que debe de hacer el sistema deseado y no de la forma en que se har. Los elementos del modelo deben ser conceptos del dominio de aplicacin y no conceptos informticos tales como estructuras de datos. Un buen modelo debe poder ser entendido y criticado por expertos en el dominio del problema que no tengan conocimientos informticos. Diseo del sistema. El diseador del sistema toma decisiones de alto nivel sobre la arquitectura del mismo. Durante esta fase el sistema se organiza en

13

subsistemas basndose tanto en la estructura del anlisis como en la arquitectura propuesta. Se selecciona una estrategia para afrontar el problema. Diseo de objetos. El diseador de objetos construye un modelo de diseo basndose en el modelo de anlisis, pero incorporando detalles de implementacin. El diseo de objetos se centra en las estructuras de datos y algoritmos que son necesarios para implementar cada clase. OMT describe la forma en que el diseo puede ser implementado en distintos lenguajes (orientados y no orientados a objetos, bases de datos, etc.). Implementacin. Las clases de objetos y relaciones desarrolladas durante el anlisis de objetos se traducen finalmente a una implementacin concreta. Durante la fase de implementacin es importante tener en cuenta los principios de la ingeniera del software de forma que la correspondencia con el diseo sea directa y el sistema implementado sea flexible y extensible. No tiene sentido que utilicemos AOO y DOO de forma que potenciemos la reutilizacin de cdigo y la correspondencia entre el dominio del problema y el sistema informtico, si luego perdemos todas estas ventajas con una implementacin de mala calidad. La metodologa OMT emplea tres clases de modelos para describir el sistema: Modelo de objetos. Describe la estructura esttica de los objetos del sistema (identidad, relaciones con otros objetos, atributos y operaciones). El modelo de objetos proporciona el entorno esencial en el cual se pueden situar el modelo dinmico y el modelo funcional. El objetivo es capturar aquellos conceptos del mundo real que sean importantes para la aplicacin. Se representa mediante diagramas de objetos. Modelo dinmico. Describe los aspectos de un sistema que tratan de la temporizacin y secuencia de operaciones (sucesos que marcan los cambios, secuencias de sucesos, estados que definen el contexto para los sucesos) y la organizacin de sucesos y estados. Captura el control, aquel aspecto de un sistema que describe las secuencias de operaciones que se producen sin tener en cuenta lo que hagan las operaciones, aquello a lo que afecten o la forma en que estn implementadas. Se representa grficamente mediante diagramas de estado. Modelo funcional. Describe las transformaciones de valores de datos (funciones, correspondencias, restricciones y dependencias funcionales) que ocurren dentro del sistema. Captura lo que hace el sistema, independientemente de cuando se haga o de la forma en que se haga. Se representa mediante diagramas de flujo de datos

14

Extreme programming (XP) La metodologa de Extreme Programming (XP) es una metodologa relativamente nueva y muy polmica porque ataca frontalmente muchos de los principios asentados en la Ingeniera del software y defiende como su nombre bien dice una serie de principios extremos y que en su primera lectura parece simplemente completamente irrealistas. Se confunde a menudo con lo que algunas veces se llama code and fix en la literatura, es decir, el ponerse a programar directamente, sin un proceso de Ingeniera, muchas veces incluso sin contar ni siquiera con una especificacin de requisitos inicial. Tngase en cuenta, adems, que no es un ciclo de vida, sino una metodologa, pero con un ciclo de vida muy caracterstico. El principal objetivo de XP consiste en controlar un problema fundamental en el desarrollo de software: la alta volatilidad, especificaciones incompletas cambios y falta de cultura del negocio hace que los desarrolladores tardan en entender el sistema que deben desarrollar. XP ataca este problema mediante ciclos de iteracin extremadamente cortos en los cuales se aade muy poca funcionalidad construyendo un sistema completo que posiblemente se utilice incluso en produccin, esto permite a los desarrolladores asimilar la problemtica de una forma ms natural. Por otra parte exige una alta implicacin de los usuarios en el desarrollo para crear un autentico clima de trabajo en equipo. En este sentido el ciclo de vida del Extreme Programming se puede ver como el ciclo de vida orientado a prototipos evolutivos llevado al extremo unido a una serie de principios particulares de esta metodologa. Para que el elevado ritmo de integraciones no produzca un sistema degenerado se enfatizan especialmente las pruebas de unidad y prestar una atencin alta a la calidad del cdigo, y la necesidad de diseos sencillos. Por otra parte se debe partir de un diseo de base relativamente estable, ya que los fundamentos del diseo no pueden cambiar continuamente. Pero lo realmente novedoso o podramos decir, curioso, es el contenido del conjunto relativamente sencillo de reglas en las que el Extreme Programming su mtodo de trabajo. A grandes rasgos: Los requerimientos se especifican continuamente y se plasman en las user stories que deben ser documentos mucho ms ligeros que las especificaciones de requisitos clsicas en los que los usuarios cuentan, en dos o tres fases y un lenguaje no tcnico relativamente informal, cada funcionalidad. Entregar un nmero alto de versiones con relativamente pocas funcionalidades nuevas Mantener el mayor nivel de rotacin entre tareas del proyecto con el fin de que no haya personas que concentren todo el conocimiento de un rea y supongan as un alto riesgo. Para que la idea anterior sea factible todo el cdigo de produccin debe ser programado por parejas, ya que esto hace que un miembro de la pareja puede cambiar de tarea mientras que el otro da continuidad a la actividad y apoya a la persona que sustituye al primero Mxima simplicidad en el diseo Utilizar chapuzas controladas para reducir riesgos, es decir probar conceptos con pequeos mdulos o programas rpidos para medir su viabilidad y tirarlos luego No aadir

15

funcionalidad de detalle al principio, mantener la funcionalidad en el nivel ms bsico posible.

Aplicar tcnicas de refactoring siempre que sea aconsejable. Refactoring significa la reconstruccin o reestructuracin de cdigo de una manera disciplinada con el fin de eliminar cdigo obsoleto de un proyecto. Es fundamental en una filosofa que parte de una indefinicin tan alta como el XP, ya que el diseo detallado y el cdigo tiende a quedarse obsoleto con el tiempo y evolucionarlo significa complicarlo cada vez ms. Llegado un momento, resulta ms econmico empezar desde cero. El cliente debe estar siempre disponible. Programar antes el cdigo de las pruebas unitarias que el cdigo del producto en s. Propiedad colectiva del cdigo. Esto se refiere a que todo el mundo debe contribuir en la medida de lo posible con ideas en todas las reas del proyecto. Incluso se concibe que modifiquen cdigo. Esto va unido al hecho de rotar los desarrolladores entre reas Dejar las optimizaciones para el final No trabajar en exceso. El razonamiento es que las implicaciones negativas sobre la motivacin del equipo descompensan las posibles ganancias de tiempo Todo el cdigo debe tener sus pruebas de unidad y no podr ser puesto en produccin hasta pasarlas todas Uso intensivo de tests de aceptacin. Ventajas Parte de una visin muy realista en el sentido que considera la realidad en los desarrollos con los clientes. As, por ejemplo, tiene en cuenta la dinmica con los clientes en la cual disponer de una definicin razonablemente completa de funcionalidad del producto suele ser pura ficcin Extreme Programming enfatiza especialmente la importancia el diseo simple y la importancia de las pruebas, un punto especialmente descuidado en el desarrollo Aporta algunas ideas refrescantes que son tiles como principios incluso sin aplicar la metodologa en s. La programacin en parejas es un buen ejemplo, o los stand up meetings. Inconvenientes La metodologa no es escalable, solamente puede tener sentido en proyectos relativamente pequeos, segn XP proyectos de entre 2 y 12 desarrolladores Algunos de los principios parecen demasiado extremos y no gozan de un respaldo con argumentos slidos por los defensores de esta metodologa. Por ejemplo, el principio de la programacin colectiva, es decir, que en definitiva todos puedan tocar en todas partes, un punto que genera mucho debate porque el peligro de una evolucin anrquica de las funcionalidades de los mdulos parece alta y muy difcilmente controlable. Otro ejemplo es el refactoring, la misma metodologa pide cierta estabilidad en el diseo base, pero a la vez enfatiza la necesidad de refactoring, dos principios que entran fcilmente en conflicto, pero no aporta criterios claros para saber dnde situar punto de equilibrio entre ambos. La metodologa no responde con soluciones o con sugerencias a

16

muchos los problemas que plantean sus principios, lo cual da una impresin de encontrarse an en un estado relativamente hipottico. 3.4 PROYECTO DE SOFTWARE

Para satisfacer estos requerimientos o solucionar los problemas, hemos de desarrollar un producto de software. Cuando hablamos de software nos referimos a un conjunto de programas relacionados, orientados a resolver un problema del mundo real, que por su complejidad y tamao deben ser resueltos por un equipo de especialistas de software. Veamos las siguientes situaciones: a) Un simple programa que calcule la media de los valores almacenados en un arreglo. b) Una aplicacin de gestin de las cuentas corrientes de las sucursales de un banco, que permite realizar transacciones en lnea como depsitos, extracciones, consultas de saldos y movimientos, transferencias, creacin y cancelacin de cuentas y emisin de extractos, entre otras cosas. El primer caso, prcticamente no reviste inconvenientes para realizar el programa en forma inmediata, puesto que el problema es sencillo y esta perfectamente delimitado y acotado. Pero el segundo, trata un problema ms complejo, sern necesarios muchos programas, distintos tipos de estructuras de datos y ser utilizado por varios usuarios a la vez, etc., adems el desarrollo estar a cargo de un equipo de personas, en esta situacin no se debe comenzar a programar en forma inmediata, debe pensarse como un proyecto de software, cumpliendo el ciclo de vida y siguiendo alguna metodologa, en estos casos estaremos haciendo uso de la Ingeniera de Software. El trmino Ingeniera de Software se utiliza para referirse a un mtodo disciplinario de desarrollo de programas de computadoras, a travs de todas las actividades del ciclo de vida de un software.

17

4 4.1

METODOLOGIA DE DESARROLLO DE SOFTWARE 01

NOMBRE : OMT (OBJECT MODELING TECHNIQUE TCNICA DE MODELADO DE OBJETOS).

4.2

CARACTERSTICAS Es una metodologa desarrollada por James Rambaugh.

Enfatiza en el anlisis del sistema de informacin y no en su implementacin. No significa que deja a un lado la implementacin del sistema, solo que se centra ms en el anlisis del mismo. Como lo indica su nombre se basa en la importancia del modelo y el uso de este para la abstraccin del sistema. Esto significa que se encarga ms del camino que se elabora para construir software, el ciclo de ida del software. Se construye alrededor de descripciones de estructuras de datos, constantes, sistemas para procesos de transacciones. Se basa o es una metodologa orientada a los objetos, donde su importancia radica en el trabajo con los objetos, y la forma abstracta de ver un sistema a travs de ellos. Divide el ciclo de vida del software en 4 fases consecutivas: Anlisis de objetos, diseo del sistema, diseo de objetos e implementacin. 4.3 ETAPAS

Anlisis de Objetos En toda la fase de anlisis se describe el comportamiento del sistema como una caja negra. Es aqu donde se revisan los requerimientos, establecidos por un documento, que permitan la construccin del modelo real. El objetivo de esta fase es determinar que necesidades se van a cumplir en el desarrollo del sistema. Para esto se pueden tener diversas fuentes de informacin, que indiquen un punto de referencia, como la piedra angular para el modelo.

18

Teniendo clara una conceptualizacin, se define despus, un diagrama de objetos, con su respectivo diccionario de datos. Se definen las clases, y las relaciones existentes entre ellas, adems de la estructura de cada una; y, en el diccionario, una explicacin o definicin de cada clase. Luego se crea un modelo dinmico, a partir del modelo de objetos. En el se especifica los diagramas de eventos y de estado para cada clase u objeto. En el diagrama de eventos se reflejan las actividades u operaciones de cada clase en el tiempo, con respecto al sistema; y en el de estado, se especifican los valores de los atributos de la clase en determinado momento. El siguiente modelo a elaborar es el modelo funcional. All se describen las funciones, los valores de entrada y salida, y las restricciones del sistema. Aqu se utiliza los tan llamados diagramas de flujo o los diagramas de Actividades. Especifica la forma en la que se realizan operaciones, sin tener en cuenta la estructura del sistema. Cada paso de a etapa de anlisis de objetos, primero, es iterativo, para su refinamiento, desde el modelo de datos, para pulir cada una de las labores que se realizan en cada modelo; segundo, debe estar documentado cada proceso, dentro de la fase. En el primer paso, se establece en un documento, una breve descripcin del problema, junto con la especificacin de los requisitos, en otras palabras delimitar el sistema. La documentacin para el modelo de objetos, es el diagrama de modelo de objetos, y el diccionario de datos. Para el modelo dinmico, se tiene los diagramas de estado y los de colaboracin, de forma individual, y un diagrama global de eventos. Por ltimo en el modelo funcional, se elabora el diagrama de actividades, o diagrama de flujo de datos, y las restricciones. Diseo del sistema Establece la arquitectura bsica del sistema y se toman las decisiones estratgicas. Como se va a trabajar, que tecnologas se van a utilizar, que polticas se van establecer como gua del proyecto. La clave est en la frase divide y vencers, organizar el sistema general en subsistemas, los cuales interaccionan entre s para la consecucin del sistema en total. Los pasos a seguir en el diseo del sistema son: Organizar el sistema en subsistemas (conjunto de capas horizontales). Identificar la concurrencia inherente al problema. Asignar los subsistemas a sus procesos y tareas.

19

 Elegir la estrategia bsica para almacenar datos. Identificar los recursos globales y determinar mecanismos de control de acceso a ellos. Elegir un mtodo de implementacin del control do software. Considerar las condiciones al lmite. Establecer las prioridades.

Diseo de Objetos Es la ltima fase, antes de la implementacin. Es donde se definen completamente las caractersticas de los objetos, elaborando un proceso de refinamiento a cada uno. Donde se especifica, se desmenuza cada uno de los tres modelos ya elaborados, independientemente del lenguaje que se vaya a utilizar. Los pasos a seguir son: Obtener operaciones para el modelo de objetos a partir de los otros modelos. Disear algoritmos para implementar operaciones. Optimizar los accesos a datos. Implementar el control de software mediante el sistema elegido durante el diseo del sistema. Ajustar las estructuras de las clases para aumentar la herencia. Diseo de la implementacin de las asociaciones. Determinar la representacin exacta de los atributos de los objetos. Compactar las clases y asociaciones de mdulos, ocultando en la parte privada toda la informacin que deba estar oculta.

Implementacin El ltimo paso de la tecnologa OMT, es la implementacin, aunque como ya se mencion, el objetivo de la OMT, es el modelado de los objetos, y no de todo el sistema de informacin, en si. Ya con lo tres pasos anteriores, y por supuesto con el lenguaje de codificacin definido, solo queda pasar todo el modelado a un lenguaje de programacin. Sin embargo en el desarrollo de toda la metodologa, se pudo haber hecho esto, implementar poco a poco, paralelo con el modelado de objetos, en el lenguaje de programacin.

20

4.4

DIAGRAMAS UTILIZADOS EN CADA ETAPA

Segn lo definido en las anteriores etapas de la tecnologa OMT. Los diagramas base del sistema, estn definidos en la etapa de Anlisis, y que de ah en adelante, consiste en el refinamiento de cada diagrama o modelo, y su aplicabilidad al momento de subdividir el sistema, en varios subprocesos, a quienes deben aplicrsele a cada uno esta metodologa. Diagrama de modelo de objetos No es mas que el diagrama de clases, utilizado en la metodologa de RUP. Definiendo las caractersticas de cama objeto, y su relacin con los dems objetos del sistema.

21

Este diagrama, es el modelo de un sistema para la gestin de artculos deportivos de una empresa, en el rea de ventas tanto para mayoristas, como para clientes minoristas. Diagrama de Estados Comprende cada una de las actividades que realiza cada objeto, prcticamente se modelan los procesos, en cualquier momento, no se tiene es este diagrama que lo antecede, y que le cede a este proceso, solo se enfatiza en es proceso. Los diagramas de estados muestran los posibles estados en que puede encontrarse un objeto y las transiciones que pueden causar un cambio de estado.

El anterior diagrama de estados, consiste en la solicitud de un pedido, y el envo del mismo; este diagrama solo le pertenece al cliente, ntese que no se tiene en cuenta los otros objetos, solo los estados en los que puede estar el cliente.

Diagrama de flujo de datos Se asemejan a los diagramas de estado, con la diferencia que muestran la secuencia, el flujo de todo el sistema, teniendo en cuenta la interaccin entre los objetos.

22

En este diagrama de actividades, se puede ver, como interacciona el objeto cliente, con el objeto tienda, sealando la diferencia del diagrama de estados, con el diagrama de actividades. Este diagrama establece las relaciones de los procesos de un objeto, con respecto al otros. Nota: Los ejemplos de los diagramas son sacados de otros trabajos. 4.5 EJEMPLO EXPLICATIVO

Descripcin del problema: Se busca crear un sistema de informacin el cual permita llevar un registro de los prstamos que se hacen en las salas de cmputo de la universidad. Donde se guarde la hora, el estudiante, la sala, el equipo y la persona encargada en ese momento de las salas, la cual realiza el prestamo.

23

Para el registro se tiene en cuenta el cdigo del estudiante y el nombre, a parte, que el encargado de la sala puede ser un estudiante autorizado, con la diferencia, qu, adems de ser estudiante, es empleado de la universidad. Lista de objetos: La lista de objetos comprende, objeto Estudiante, Encargado_sala (Hereda de Estudiante), Equipo(Hace parte de una sala), Sala, y el registro Prstamo. Diagrama de objetos:

Diccionario de datos: 1 Estudiante: Persona que va a utilizar el equipo, por cierto tiempo determinado 2 Encargado_Sala: Persona la cual registra el prstamo del equipo. Por lo general es un estudiante de la universidad, que trabaja con la misma. 3 Equipo: Mquina, computador, la cual est al servicio de un estudiante para su uso. Est situada en una sala determinada. 4 Sala: Lugar donde se agrupan, varios computadores o equipos, para el uso del estudiante y de los profesores, en sus clases. 5 Prstamo: Registro donde queda almacenado la hora, quin us, quin autoriz, en que sala, de cierto equipo. 6 AltaPrestamo: Rutina en el cual se asigna el equipo. 7 BajaPrstamo: Rutina en donde se recibe por medio de una ficha el quipo prestado. 8 EstadoEquipo: rutina donde se valida si un equipo est en uso o no. 9 ModificarPrestamo: Rutina, en la cual se modifican los atributos del prstamo. Solo la realiza el encargado.

24

10 EstablecerEstado: Rutina donde se le asigna un estado al equipo. 11 ValidarPrstamo: Rutina donde se valida si un prstamo est activo o incactivo.

Diagrama de estado

Diagrama de estado objeto: Estudiante

25

Diagrama de estado objeto: Encargado_Sala

Diagrama de flujo de datos:

26

METODOLOGA DE DESARROLLO DE SOFTWARE 02.

5.1

NOMBRE: MTRICA 3

5.2

CARACTERSTICAS.

Mtrica es una Metodologa de Planificacin, Desarrollo y Mantenimiento de Sistemas de Informacin. La metodologa MTRICA 3 ofrece a las Organizaciones un instrumento til para la sistematizacin de las actividades que dan soporte al ciclo de vida del software dentro del marco que permite alcanzar los siguientes objetivos: Proporcionar o definir Sistemas de Informacin que ayuden a conseguir los fines de la organizacin mediante la definicin de un marco estratgico para el desarrollo de los mismos. Dotar a la Organizacin de productos software que satisfagan las necesidades de los usuarios dando una mayor importancia al anlisis de requisitos. Mejorar la productividad de los departamentos de Sistemas y Tecnologas de la Informacin y las Comunicaciones, permitiendo una mayor capacidad de adaptacin a los cambios y teniendo en cuenta la reutilizacin en la medida de lo posible. Facilitar la comunicacin y entendimiento entre los distintos participantes en la produccin de software a lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, as como las necesidades de todos y cada uno de ellos. Facilitar la operacin, mantenimiento y uso de los productos software obtenido. Mtrica 3 contempla el desarrollo de Sistemas de Informacin para las distintas tecnologas que actualmente estn conviviendo y los aspectos de gestin que aseguran que un proyecto cumple sus objetivos en trminos de calidad, coste y plazos. Su punto de partida es la versin anterior de MTRICA de la cual se han conservado la adaptabilidad, flexibilidad y sencillez, as como la estructura de actividades y tareas, si bien las fases y mdulos de mtrica versin 2.1 han dado

27

paso a la divisin en procesos, ms adecuada a la entrada-transformacin-salida que se produce en cada una de las divisiones del ciclo de vida de un proyecto. Para cada tarea se detallan los participantes que intervienen, los productos de entrada y de salida as como las tcnicas y prcticas a emplear para su obtencin. En la elaboracin de MTRICA Versin 3 se han tenido en cuenta los mtodos de desarrollo ms extendidos, as como los ltimos estndares de ingeniera del software y calidad, adems de referencias especficas en cuanto a seguridad y gestin de proyectos. Tambin se ha tenido en cuenta la experiencia de los usuarios de las versiones anteriores para solventar los problemas o deficiencias detectados. En una nica estructura la metodologa mtrica 3 cubre distintos tipos de desarrollo: estructurado y orientado a objetos, facilitando a travs de interfaces la realizacin de los procesos de apoyo u organizativos: Gestin de Proyectos, Gestin de Configuracin, Aseguramiento de Calidad y Seguridad. Los procesos principales se han enriquecido especificando el contenido, la forma y el momento en que se obtienen los productos, as como la relacin entre los productos obtenidos en cada tarea, su reutilizacin en tareas posteriores y el producto final de cada actividad o proceso. Tambin se han especificado los participantes de forma ms precisa en cada tarea, reformando la participacin de los usuarios, bien sea usuario final o de sistemas, de forma que dicha participacin no se limite a labores informativas frente a las tareas de verificacin, aumentando as su responsabilidad. Mtrica 3 tiene un enfoque orientado al proceso, ya que la tendencia general en los estndares se encamina en este sentido y por ello, se ha enmarcado dentro de la norma ISO 12.207, que se centra en la clasificacin y definicin de los procesos del ciclo de vida del software. Como punto de partida y atendiendo a dicha norma, mtrica 3 cubre el Proceso de Desarrollo y el Proceso de Mantenimiento de Sistemas de Informacin. 5.3 ETAPAS

Esta metodologa de desarrollo de software no sigue un orden de etapas, sino una serie de actividades o procesos que no tienen que tener un orden en comn (generalmente), pero si es necesario que se realicen todos los procesos. El orden asignado a las actividades no debe interpretarse como secuencia en su realizacin, ya que stas pueden realizare en orden diferente a su numeracin o

28

bien en paralelo. Sin embargo, no se dar por acabado un proceso hasta no haber finalizado todas las actividades del mismo determinadas al inicio del proyecto. As los procesos de la estructura principal de MTRICA Versin 3 son los siguientes: PLANIFICACIN DE SISTEMAS DE INFORMACIN. DESARROLLO DE SISTEMAS DE INFORMACIN. MANTENIMIENTO DE SISTEMAS DE INFORMACIN. Planificacin de Sistemas de Informacin (PSI) El objetivo de un Plan de Sistemas de Informacin es proporcionar un marco estratgico de referencia para los Sistemas de Informacin de un determinado mbito de la Organizacin. La existencia de tecnologa de reciente aparicin, permite disponer de sistemas que apoyan la toma de decisiones a partir de grandes volmenes de informacin procedentes de los sistemas de gestin e integrados en una plataforma corporativa. MTRICA Versin 3 ayuda en la planificacin de sistemas de informacin facilitando una visin general necesaria para posibilitar dicha integracin y un modelo de informacin global de la organizacin. El resultado del Plan de Sistemas debe, por tanto, orientar las actuaciones en materia de desarrollo de Sistemas de Informacin con el objetivo bsico de apoyar la estrategia corporativa, elaborando una arquitectura de informacin y un plan de proyectos informticos para dar apoyo a los objetivos estratgicos. Por este motivo es necesario un proceso como el de Planificacin de Sistemas de Informacin, en el que participen, por un lado los responsables de los procesos de la organizacin con una visin estratgica y por otro, los profesionales de SI (sistemas informticos) capaces de enriquecer dicha visin con la aportacin de ventajas competitivas por medio de los sistemas y tecnologas de la informacin y comunicaciones. Desarrollo de Sistemas de Informacin Desde el enfoque de la norma ISO 12.207, el Proceso de Mantenimiento de Sistemas de Informacin comprende actividades y tareas de modificacin o retirada de todos los componentes de un sistema de informacin (hardware, software, software de base, operaciones manuales, redes, etc). Este marco de actuacin no es el objetivo de mtrica versin 3, ya que esta metodologa est dirigida principalmente al proceso de desarrollo del software. Por lo tanto, mtrica

29

versin 3 refleja los aspectos del mantenimiento, correctivo y evolutivo, que tienen relacin con el Proceso de Desarrollo. Las actividades y tareas propuestas por la norma se encuentran ms en la lnea de un desarrollo clsico, separando datos y procesos, que en la de un enfoque orientado a objetos. En mtrica versin 3 se han abordado los dos tipos de desarrollo: estructurado y orientado a objeto, por lo que ha sido necesario establecer actividades especficas a realizar en alguno de los procesos cuando se utiliza la tecnologa de orientacin a objetos. Para este ltimo caso se ha analizado alguna de las propuestas de otras metodologas orientadas a objetos y se han tenido en cuenta la mayora de las tcnicas que contempla UML 1.2 (Unified Modeling Language). El Proceso de Desarrollo de Sistemas de Informacin, para facilitar la comprensin y dada su amplitud y complejidad se ha subdividido en cinco procesos: ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS). ANLISIS DEL SISTEMA DE INFORMACIN (ASI). DISEO DEL SISTEMA DE INFORMACIN (DSI). CONSTRUCCIN DEL SISTEMA DE INFORMACIN (CSI). IMPLANTACIN Y ACEPTACIN DEL SISTEMA (IAS). Estudio de Viabilidad del Sistema (EVS) El propsito de este proceso es analizar un conjunto concreto de necesidades, con la idea de proponer una solucin a corto plazo. Los criterios con los que se hace esta propuesta no sern estratgicos sino tcticos y relacionados con aspectos econmicos, tcnicos, legales y operativos. Los resultados del Estudio de Viabilidad del Sistema constituirn la base para tomar la decisin de seguir adelante o abandonar. Si se decide seguir adelante pueden surgir uno o varios proyectos que afecten a uno o varios sistemas de informacin. Dichos sistemas se desarrollarn segn el resultado obtenido en el estudio de viabilidad y teniendo en cuenta la cartera de proyectos para la estrategia de implantacin del sistema global. Se ha considerado que este proceso es obligatorio, aunque el nivel de profundidad con el que se lleve a cabo depender de cada caso. La conveniencia de la realizacin del estudio de la situacin actual depende del valor aadido previsto para la especificacin de requisitos y para el planteamiento de alternativas de solucin. En las alternativas se considerarn soluciones "a medida", soluciones basadas en la adquisicin de productos software del mercado o soluciones mixtas.

30

Para valorar las alternativas planteadas y determinar una nica solucin, se estudiar el impacto en la organizacin de cada una de ellas, la inversin y los riesgos asociados. El resultado final de este proceso son los productos relacionados con la solucin que se propone para cubrir la necesidad concreta que se plante en el proceso, y que depende de si la solucin conlleva desarrollo a medida o no.

Anlisis del Sistema de Informacin (ASI) El propsito de este proceso es conseguir la especificacin detallada del sistema de informacin, a travs de un catlogo de requisitos y una serie de modelos que cubran las necesidades de informacin de los usuarios para los que se desarrollar el sistema de informacin y que sern la entrada para el proceso de Diseo del Sistema de Informacin. Como ya se ha mencionado mtrica versin 3 cubre tanto desarrollos estructurados como orientados a objetos, y las actividades de ambas aproximaciones estn integradas en una estructura comn aunque presenta alguna actividad exclusiva para cada tipo de desarrollo. En primer lugar se describe inicialmente el sistema de informacin, a partir de los productos generados en el proceso Estudio de Viabilidad del Sistema (EVS). Se delimita su alcance, se genera un catlogo de requisitos generales y se describe el sistema mediante unos modelos iniciales de alto nivel. Para facilitar el anlisis del sistema se identifican los subsistemas de anlisis, y se elaboran los modelos de Casos de Uso y de Clases, en desarrollos orientados a objetos, y de datos y procesos en desarrollos estructurados. Se ha incorporado una actividad especfica para la definicin de Interfaces de Usuario al tiempo que se van obteniendo y depurando los requisitos y los anteriores modelos. Se especificarn todas las interfaces entre el sistema y el usuario, como formatos de pantallas, dilogos, formatos de informes y formularios de entrada. Finalizados los modelos, se realiza un anlisis de consistencia, mediante una verificacin y validacin, lo que puede forzar la modificacin de algunos de los modelos obtenidos. Una vez realizado dicho anlisis de consistencia se elabora el producto Especificacin de Requisitos Software, que constituye un punto de referencia en el desarrollo del software y la lnea base de referencia para las peticiones de cambio sobre los requisitos inicialmente especificados.

31

En este proceso se inicia tambin la especificacin del Plan de Pruebas, que se completar en el proceso Diseo del Sistema de Informacin (DSI). En este proceso es muy importante la participacin de los usuarios, a travs de tcnicas interactivas, como diseo de dilogos y prototipos, que permiten al usuario familiarizarse con el nuevo sistema y colaborar en la construccin y perfeccionamiento del mismo. Diseo del Sistema de Informacin (DSI) El propsito del Diseo del Sistema de Informacin (DSI) es obtener la definicin de la arquitectura del sistema y del entorno tecnolgico que le va a dar soporte, junto con la especificacin detallada de los componentes del sistema de informacin. A partir de dicha informacin, se generan todas las especificaciones de construccin relativas al propio sistema, as como la especificacin tcnica del plan de pruebas, la definicin de los requisitos de implantacin y el diseo de los procedimientos de migracin y carga inicial, stos ltimos cuando proceda. El diseo de la arquitectura del sistema depender en gran medida de las caractersticas de la instalacin, de modo que se ha de tener en cuenta una participacin activa de los responsables de Sistemas y Explotacin de las Organizaciones para las que se desarrolla el sistema de informacin. Este proceso consta de un primer bloque de actividades, que se realizan en paralelo, y cuyo objetivo es obtener el diseo de detalle del sistema de informacin que comprende la particin fsica del sistema de informacin, independiente de un entorno tecnolgico concreto, la organizacin en subsistemas de diseo, la especificacin del entorno tecnolgico sobre el que se despliegan dichos subsistemas y la definicin de los requisitos de operacin, administracin del sistema, seguridad y control de acceso. En el caso de diseo orientado a objetos, conviene sealar que se ha contemplado que el diseo de la persistencia se lleva a cabo sobre bases de datos relacionles. De este primer bloque de actividades se obtienen los siguientes productos: Catlogo de requisitos (se completa). Catlogo de excepciones. Catlogo de normas para el diseo y construccin. Diseo de la arquitectura del sistema. Entorno tecnolgico del sistema. Procedimientos de operacin y administracin del sistema. Procedimientos de seguridad y control de acceso. Diseo detallado de los subsistemas de soporte. Modelo fsico de datos optimizado.

32

 Asignacin de esquemas fsicos de datos a nodos. Adems, en Diseo Estructurado: Diseo de la arquitectura modular. Diseo de interfaz de usuario. Adems, en Diseo Orientado a Objetos: Diseo de la realizacin de casos de uso. Modelo de clases de diseo. Comportamiento de clases de diseo. Diseo de interfaz de usuario. Al igual que en el proceso de Anlisis del Sistema de Informacin (ASI), antes de proceder a la especificacin de los componentes, se realiza una verificacin y validacin, con objeto de analizar la consistencia entre los distintos modelos y formalizar la aceptacin del diseo de la arquitectura del sistema por parte de los usuarios de Explotacin y Sistemas. Construccin del Sistema de Informacin (CSI) La construccin del Sistema de Informacin (CSI) tiene como objetivo final la construccin y prueba de los distintos componentes del sistema de informacin, a partir del conjunto de especificaciones lgicas y fsicas del mismo, obtenido en el Proceso de Diseo del Sistema de Informacin (DSI). Se desarrollan los procedimientos de operacin y seguridad y se elaboran los manuales de usuario final y de explotacin, estos ltimos cuando proceda. Para conseguir dicho objetivo, se recoge la informacin relativa al producto del diseo Especificaciones de construccin del sistema de informacin, se prepara el entorno de construccin, se genera el cdigo de cada uno de los componentes del sistema de informacin y se van realizando, a medida que se vaya finalizando la construccin, las pruebas unitarias de cada uno de ellos y las de integracin entre subsistemas. Implantacin y Aceptacin del Sistema (IAS) Este proceso tiene como objetivo principal, la entrega y aceptacin del sistema en su totalidad, que puede comprender varios sistemas de informacin desarrollados de manera independiente, segn se haya establecido en el proceso de Estudio de Viabilidad del Sistema (EVS), y un segundo objetivo que es llevar a cabo las actividades oportunas para el paso a produccin del sistema.

33

Se establece el plan de implantacin, una vez revisada la estrategia de implantacin y se detalla el equipo que lo realizar. Para el inicio de este proceso se toman como punto de partida los componentes del sistema probados de forma unitaria e integrada en el proceso Construccin del Sistema de Informacin (CSI), as como la documentacin asociada. El Sistema se someter a las Pruebas de Implantacin con la participacin del usuario de operacin cuya responsabilidad, entre otros aspectos, es comprobar el comportamiento del sistema bajo las condiciones ms extremas. Tambin se someter a las Pruebas de Aceptacin cuya ejecucin es responsabilidad del usuario final. Mantenimiento de Sistemas de Informacin (MSI) El objetivo de este proceso es la obtencin de una nueva versin de un sistema de informacin desarrollado con MTRICA, a partir de las peticiones de mantenimiento que los usuarios realizan con motivo de un problema detectado en el sistema o por la necesidad de una mejora del mismo. Como consecuencia de esto, slo se considerarn en MTRICA Versin 3 los tipos de Mantenimiento Correctivo y Evolutivo. Se excluyen los tipos de Mantenimiento Adaptativo y Perfectivo, que abarcan actividades tales como la migracin y la retirada de software que precisaran el desarrollo de un tipo de metodologa especfica para resolver su cometido. Ante una peticin de cambio de un sistema de informacin ya en produccin, se realiza un registro de las peticiones, se diagnostica el tipo de mantenimiento y se decide si se le da respuesta o no, en funcin del plan de mantenimiento asociado al sistema afectado por la peticin, y se establece con qu prioridad La definicin de la solucin al problema o necesidad planteada por el usuario que realiza el responsable de mantenimiento, incluye un estudio del impacto, la valoracin del esfuerzo y coste, las actividades y tareas del proceso de desarrollo a realizar y el plan de pruebas de regresin. Los productos que se obtienen en este proceso son los siguientes: Catlogo de peticiones de cambio. Resultado del estudio de la peticin. Propuesta de solucin. Anlisis de impacto de los cambios. Plan de accin para la modificacin. Plan de pruebas de regresin. Evaluacin del cambio. Evaluacin del resultado de las pruebas de regresin.

34

INTERFACES DE MTRICA VERSIN 3 La estructura de mtrica versin 3 incluye tambin un conjunto de interfaces que definen una serie de actividades de tipo organizativo o de soporte al proceso de desarrollo y a los productos, que en el caso de existir en la organizacin se debern aplicar para enriquecer o influir en la ejecucin de las actividades de los procesos principales de la metodologa y que si no existen habr que realizar para complementar y garantizar el xito del proyecto desarrollado con mtrica versin 3. La aplicacin de mtrica versin 3 proporciona sistemas con calidad y seguridad, no obstante puede ser necesario en funcin de las caractersticas del sistema un refuerzo especial en estos aspectos, refuerzo que se obtendra aplicando la interfaz. Las interfaces descritas en la metodologa son: Gestin de Proyectos (GP) Seguridad (SEG) Aseguramiento de la Calidad (CAL) Gestin de la Configuracin (GC)

Gestin de proyectos La Gestin de Proyectos tiene como finalidad principal la planificacin, el seguimiento y control de las actividades y de los recursos humanos y materiales que intervienen en el desarrollo de un Sistema de Informacin. Como consecuencia de este control es posible conocer en todo momento qu problemas se producen y resolverlos o paliarlos de manera inmediata. La Interfaz de Gestin de Proyectos de MTRICA Versin 3 contempla proyectos de desarrollo de Sistemas de Informacin en sentido amplio. Es decir, acorde con EUROMTODO se consideran proyectos de desarrollo de nuevos Sistemas de Informacin y tambin los proyectos de ampliacin y mejora de los ya existentes; estos ltimos, contemplados en MTRICA Versin 3 al proceso de Mantenimiento del Sistema de Informacin (MSI).

35

Las actividades de la Interfaz de Gestin de Proyectos se presentan en el siguiente esquema, en el que se aprecian las reas que cubre. Se distinguen tres grupos de actividades: Actividades de Inicio del Proyecto (GPI). Al principio del proyecto, al concluir el proceso Estudio de Viabilidad del Sistema (EVS), se realizarn las actividades de Estimacin de Esfuerzo y Planificacin del proyecto. Actividades de Seguimiento y Control (GPS). Comprenden desde la asignacin de las tareas hasta su aceptacin interna por parte del equipo de 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 realizan durante los procesos de Anlisis, Diseo, Construccin, Implantacin y Aceptacin, y Mantenimiento del Sistema de Informacin, para vigilar el correcto desarrollo de las actividades y tareas establecidas en la planificacin. Actividades de Finalizacin del Proyecto (GPF). Por ltimo, al concluir el proyecto se realizan las tareas propias de Cierre del Proyecto y Registro de la Documentacin de Gestin. Las tcnicas y prcticas utilizadas en la Gestin de Proyectos se describen en la Gua de Tcnicas de MTRICA Versin 3. En funcin de las caractersticas del proyecto puede ser aconsejable emplear herramientas software de soporte a las tcnicas, disponibles en el mercado. Seguridad El objetivo de la interfaz de seguridad de MTRICA Versin 3 es incorporar en los sistemas de informacin mecanismos de seguridad adicionales a los que se proponen en la propia metodologa, asegurando el desarrollo de cualquier tipo de sistema a lo largo de los procesos que se realicen para su obtencin. La seguridad del sistema de informacin ya se considera en MTRICA Versin 3 como requisito funcional (ASI 2.1), es decir previamente al desarrollo del mismo. La interfaz de Seguridad hace posible incorporar durante la fase de desarrollo las funciones y mecanismos que refuerzan la seguridad del nuevo sistema y del propio proceso de desarrollo, asegurando su consistencia y seguridad. El anlisis de los riesgos constituye una pieza fundamental en el diseo y desarrollo de sistemas de informacin seguros. Si bien los riesgos que afectan a un sistema de informacin son de distinta ndole: naturales (inundaciones, incendios, etc.) o lgicos (fallos propios, ataques externos, virus, etc.) son estos ltimos los contemplados en la interfaz de Seguridad de MTRICA Versin 3.

36

De lo anterior se desprende que existen dentro de la interfaz dos tipos de actividades diferenciadas: Actividades relacionadas con la seguridad intrnseca del sistema de informacin (representadas en la parte inferior del grfico). Actividades que velan por la seguridad del propio proceso de desarrollo del sistema de informacin (representadas en la parte superior del grfico). Si en la organizacin ya existe un plan de seguridad o una metodologa de anlisis y gestin de riesgos como por ejemplo MAGERIT, para cada sistema de informacin debern analizarse las necesidades de seguridad del sistema respecto al mtodo vigente, y determinar las diferencias si las hubiera, as como aquellas necesidades concretas que no se encuentren recogidas, estableciendo as el plan de seguridad del sistema de informacin. Si no existe un plan de seguridad en la organizacin habr que desarrollarlo desde el principio. El plan recoger adems las medidas de seguridad activa o preventiva y reactiva, en respuesta a situaciones en que se produce un fallo reduciendo su efecto, relacionadas con la seguridad del sistema de informacin y del proceso de desarrollo. Las valoraciones sobre la seguridad deben ser realizadas en funcin de las caractersticas del sistema: complejidad, tamao, incertidumbre, participantes, etc. por los responsables de la seguridad del sistema de informacin, quienes se apoyarn para sus decisiones en su conocimiento y experiencia en la materia sin perder de vista adems que, al ser finitos los recursos, no pueden asegurarse todos los aspectos del desarrollo de los sistemas de informacin, por lo que habr que aceptar un determinado nivel de riesgo concentrndose en los aspectos ms comprometidos o amenazados, que sern diferentes segn las circunstancias.

Gestin de la configuracin En el desarrollo de software los cambios, debidos principalmente a modificaciones de requisitos y fallos, son inevitables. Normalmente se trabaja en equipo por lo que es preciso llevar un control y registro de los cambios con el fin de reducir errores, aumentar la calidad y la productividad y evitar los problemas que puede acarrear una incorrecta sincronizacin en dichos cambios, al afectar a otros elementos del sistema o a las tareas realizadas por otros miembros del equipo de proyecto. 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

37

productos que manejan. As, entre los elementos de configuracin software, se encuentran no nicamente ejecutables y cdigo fuente, sino tambin los modelos de datos, modelos de procesos, especificaciones de requisitos, pruebas, etc. La gestin de configuracin se realiza durante todas las actividades asociadas al desarrollo del sistema, y contina registrando los cambios hasta que ste deja de utilizarse. La gestin de configuracin facilita el mantenimiento del sistema, aportando informacin precisa para valorar el impacto de los cambios solicitados y reduciendo el tiempo de implementacin de un cambio, tanto evolutivo como correctivo. Asimismo, permite controlar el sistema como producto global a lo largo de su desarrollo, obtener informes sobre el estado de desarrollo en que se encuentra y reducir el nmero de errores de adaptacin del sistema, lo que se traduce en un aumento de calidad del producto, de la satisfaccin del cliente y, en consecuencia, de mejora de la organizacin. La interfaz de gestin de configuracin de MTRICA Versin 3 permite definir las necesidades de gestin de configuracin para cada sistema de informacin, recogindolas en un plan de gestin de configuracin, en el que se especifican las actividades de identificacin y registro de productos en el sistema de gestin de configuracin durante el desarrollo y posterior mantenimiento del sistema de informacin. Si en la organizacin ya existe un sistema de gestin de configuracin estndar, para el sistema de informacin en concreto debern analizarse las necesidades de configuracin especficas respecto a dicho sistema estndar y determinar las diferencias, si las hubiera, as como aquellas necesidades concretas que no se encuentren recogidas, estableciendo as el plan de gestin de configuracin del sistema de informacin. Los productos registrados en el sistema de gestin de la configuracin se encuentran identificados y localizados unvocamente, de manera que la informacin relativa a los productos es de fcil acceso. La informacin que puede solicitarse al sistema de gestin de la configuracin es variada: Informacin relacionada con Anlisis, Diseo, Construccin, Implantacin y Aceptacin del Sistemas de Informacin, como productos globales que integran todos los productos que lo componen.

38

Informacin de un producto en concreto, su versin, estado, traza de su evolucin y cualquier dato que el plan de gestin de la configuracin determine de inters (por ejemplo, participantes en la elaboracin o modificacin del producto). Aseguramiento de la calidad El objetivo de la interfaz de Aseguramiento de la Calidad de MTRICA Versin 3 es proporcionar un marco comn de referencia para la definicin y puesta en marcha de planes especficos de aseguramiento de calidad aplicables a proyectos concretos. Si en la organizacin ya existe un sistema de calidad, dichos planes debern ser coherentes con el mismo, completndolo en los aspectos no contemplados relativos a normas particulares del cliente, usuario o sistema concreto. La calidad se define como "grado en que un conjunto de caractersticas inherentes cumple con unos requisitos" ISO 9000:2000. El Aseguramiento de la Calidad pretende dar confianza en que el producto rene las caractersticas necesarias para satisfacer todos los requisitos del Sistema de Informacin. Por tanto, para asegurar la calidad de los productos resultantes el equipo de calidad deber realizar un conjunto de actividades que servirn para: Reducir, eliminar y lo ms importante, prevenir las deficiencias de calidad de los productos a obtener. Alcanzar una razonable confianza en que las prestaciones y servicios esperados por el cliente o el usuario queden satisfechas. Para conseguir estos objetivos, es necesario desarrollar un plan de aseguramiento de calidad especfico que se aplicar durante la planificacin del proyecto de acuerdo a la estrategia de desarrollo adoptada en la gestin del proyecto. En el plan de aseguramiento de calidad se reflejan las actividades de calidad a realizar (normales o extraordinarias), los estndares a aplicar, los productos a revisar, los procedimientos a seguir en la obtencin de los distintos productos durante el desarrollo en MTRICA Versin 3 y la normativa para informar de los defectos detectados a sus responsables y realizar el seguimiento de los mismos hasta su correccin. El grupo de aseguramiento de calidad participa en la revisin de los productos seleccionados para determinar si son conformes o no a los procedimientos, normas o criterios especificados, siendo totalmente independiente del equipo de desarrollo. Las actividades a realizar por el grupo de aseguramiento de calidad vienen gobernadas por el plan. Sus funciones estn dirigidas a:

39

Identificar las posibles desviaciones en los estndares aplicados, as como en los requisitos y procedimientos especificados. Comprobar que se han llevado a cabo las medidas preventivas o correctoras necesarias. Las revisiones son una de las actividades ms importantes del aseguramiento de la calidad, debido a que permiten eliminar defectos lo ms pronto posible, cuando son menos costosos de corregir. Adems existen procedimientos extraordinarios, como las auditorias, aplicables en desarrollos singulares y en el transcurso de las cuales se revisarn tanto las actividades de desarrollo como las propias de aseguramiento de calidad. La deteccin anticipada de errores evita el que se propaguen a los restantes procesos de desarrollo, reduciendo substancialmente el esfuerzo invertido en los mismos. En este sentido es importante destacar que el establecimiento del plan de aseguramiento de calidad comienza en el Estudio de Viabilidad del Sistema y se aplica a lo largo de todo el desarrollo, en los procesos de Anlisis, Diseo, Construccin, Implantacin y Aceptacin del Sistema y en su posterior Mantenimiento. 5.4 DIAGRAMAS UTILIZADOS EN CADA ETAPA.

Como lo mencionado anteriormente esta metodologa no se divide por etapas, sino por procesos principales, a continuacin se mencionaran algunas tcnicas de modelar con sus respectivos diagramas. 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. 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.

40

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 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. Casos de Uso Los objetivos de los casos de uso son los siguientes:

41

. 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. Casos de Uso es una tcnica para capturar informacin de cmo un sistema o negocio trabaja, o de cmo se desea que trabaje. No pertenece estrictamente al enfoque orientado a objeto, es una tcnica para captura de requisitos. Se emplean para visualizar el comportamiento del sistema, una parte de el o de una sola clase. De forma que se pueda conocer como responde esa parte del sistema. El diagrama de uso es muy til para definir como debera ser el comportamiento de una parte del sistema, ya que solo especifica como deben comportarse y no como estn implementadas las partes que define. Por ello es un buen sistema de documentar partes del cdigo que deban ser reutilizables por otros desarrolladores. El diagrama tambin puede ser utilizado para que los expertos de dominio se comuniquen con los informticos sin llegar a niveles de complejidad. Un caso de uso especifica un requerimiento funcional, es decir indica esta parte debe hacer esto cuando pase esto. En el diagrama nos encontramos con diferentes figuras que pueden mantener diversas relaciones entre ellas: Actores Principales: personas que usan el sistema. Secundarios: personas que mantienen o administran el sistema. Material externo: dispositivos materiales imprescindibles que forman parte del mbito de la aplicacin y deben ser utilizados. Otros sistemas: sistemas con los que el sistema interacta. Se representan por un mueco. Sus relaciones son de Communicates Comunica un actor con un caso de uso, o con otro actor La misma persona fsica puede interpretar varios papeles como actores distintos, el nombre del actor describe el papel desempeado. Los Casos de Uso se determinan observando y precisando, actor por actor, las secuencias de interaccin, los escenarios, desde el punto de vista del usuario. Los casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo estar dirigido por los casos de uso. Un escenario es una instancia de un caso de uso.

42

Casos de uso Representado por una elipse, cada caso de uso contiene un nombre, que indique su funcionalidad. Los casos de uso pueden tener relaciones con otros casos de uso. Sus relaciones son: Include: Representado por una flecha, e4s cuando un caso de uso incluye a uno o mas casos de uso. Extends: Una relacin de una caso de Uso A hacia un caso de uso B indica que el caso de uso B implementa la funcionalidad del caso de uso A. Generalization: Es la tpica relacin de herencia. El Caso de Uso origen hereda la especificacin del Caso de Uso destino y posiblemente la modifica y/o ampla

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.

43

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. . Objetos lmite o interfaz. . Objetos de control. stos son estereotipos de clases. Un estereotipo representa una la metaclasificacin de un elemento. 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.

44

. 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 sonparte-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. 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. 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.

45

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. 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: <<...>>.

Diagrama de Descomposicin El objetivo del diagrama de descomposicin es representar la estructura jerrquica de un dominio concreto. 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. 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. 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

46

particiones. Es decir, las relaciones fsicas entre los componentes software y hardware en el sistema a entregar. 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. 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. 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.) Mtrica 3 no exige su utilizacin. 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:

47

. 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. 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. 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:

48

. 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.

Diagrama de Interaccin El objetivo de esta tcnica es describir el comportamiento dinmico del sistema de informacin mediante el paso de mensajes entre los objetos del mismo. Adems representa un medio para verificar la coherencia del sistema mediante la validacin con el modelo de clases. Un diagrama de interaccin describe en detalle un determinado escenario de un caso de uso. En l se muestra la interaccin entre el conjunto de objetos que cooperan en la realizacin de dicho escenario. Suele ser conveniente especificar en la parte izquierda del diagrama el caso de uso que se est representando para que resulte ms sencilla su validacin. Los elementos que componen los diagramas de interaccin son los objetos y los mensajes:

49

. Un objeto es una entidad que tiene un estado, un comportamiento e identidad. La estructura y el comportamiento comn de diferentes objetos se recogen en una clase. En un diagrama de interaccin, los objetos sern al final instancias de una determinada clase o de un actor. . Un mensaje es una comunicacin entre dos objetos. El envo de un mensaje por parte de un objeto (emisor) a otro (receptor), puede provocar que se ejecute una operacin, se produzca un evento o se cree o destruya un objeto. Hay dos tipos de diagramas de interaccin: diagramas de secuencia y diagramas de colaboracin. Ambos tipos de diagramas tratan la misma informacin pero cada uno hace nfasis en un aspecto particular en cuanto a la forma de mostrarla. Los diagramas de secuencia muestran de forma explcita la secuencia de los mensajes intercambiados por los objetos, mientras que los diagramas de colaboracin muestran de forma ms clara cmo colaboran los objetos, es decir, con qu otros objetos tiene vnculos o intercambia mensajes un determinado objeto. A continuacin se detallan las particularidades de cada uno de ellos. Diagrama de secuencia El diagrama de secuencia es un tipo de diagrama de interaccin cuyo objetivo es describir el comportamiento dinmico del sistema de informacin haciendo nfasis en la secuencia de los mensajes intercambiados por los objetos. Un diagrama de secuencia tiene dos dimensiones, el eje vertical representa el tiempo y el eje horizontal los diferentes objetos. El tiempo avanza desde la parte superior del diagrama hacia la inferior. Normalmente, en relacin al tiempo slo es importante la secuencia de los mensajes, sin embargo, en aplicaciones de tiempo real se podra introducir una escala en el eje vertical. Respecto a los objetos, es irrelevante el orden en que se representan, aunque su colocacin debera poseer la mayor claridad posible. Cada objeto tiene asociados una lnea de vida y focos de control. La lnea de vida indica el intervalo de tiempo durante el que existe ese objeto. Un foco de control o activacin muestra el periodo de tiempo en el cual el objeto se encuentra ejecutando alguna operacin, ya sea directamente o mediante un procedimiento concurrente. Diagrama de colaboracin El diagrama de colaboracin es un tipo de diagrama de interaccin cuyo objetivo es describir el comportamiento dinmico del sistema de informacin mostrando cmo interactan los objetos entre s, es decir, con qu otros objetos tiene vnculos o intercambia mensajes un determinado objeto.

50

Un diagrama de colaboracin muestra la misma informacin que un diagrama de secuencia pero de forma diferente. En los diagramas de colaboracin no existe una secuencia temporal en el eje vertical; es decir, la colocacin de los mensajes en el diagrama no indica cul es el orden en el que se suceden. Adems, la colocacin de los objetos es ms flexible y permite mostrar de forma ms clara cules son las colaboraciones entre ellos. En estos diagramas la comunicacin entre objetos se denomina vnculo o enlace (link) y estar particularizada mediante los mensajes que intercambian. Objeto Un objeto se representa con un rectngulo dentro del que se incluye el nombre del objeto y, si se desea, el nombre de la clase, separando ambos por dos puntos. Vnculo En el diagrama, un vnculo se representa como una lnea continua que une ambos objetos y que puede tener uno o varios mensajes asociados en ambas direcciones. Como un vnculo instancia una relacin de asociacin entre clases, tambin se puede indicar la navegabilidad del mismo mediante una flecha.

Diagrama de Paquetes El objetivo de estos diagramas es obtener una visin ms clara del sistema de informacin orientado a objetos, organizndolo en subsistemas, agrupando los elementos del anlisis, diseo o construccin y detallando las relaciones de dependencia entre ellos. El mecanismo de agrupacin se denomina Paquete. Estrictamente hablando, los paquetes y sus dependencias son elementos de los diagramas de casos de uso, de clases y de componentes, por lo que se podra decir que el diagrama de paquetes es una extensin de stos. En MTRICA Versin 3, el diagrama de paquetes es tratado como una tcnica aparte, que se aplica en el anlisis para la agrupacin de casos de uso o de clases de anlisis, en el diseo de la arquitectura para la agrupacin de clases de diseo y en el diseo detallado para agrupar componentes.

Estos diagramas contienen dos tipos de elementos: . Paquetes: Un paquete es una agrupacin de elementos, bien sea casos de uso, clases o componentes. Los paquetes pueden contener a su vez otros paquetes anidados que en ltima instancia contendrn alguno de los elementos anteriores. . Dependencias entre paquetes: Existe una dependencia cuando un elemento de un paquete requiere de otro que pertenece a un paquete distinto. Es importante resaltar que las dependencias no son transitivas.

51

Se pueden optimizar estos diagramas teniendo en cuenta cuestiones como: la generalizacin de paquetes, el evitar ciclos en la estructura del diagrama, la minimizacin de las dependencias entre paquetes, etc. SADT (Structured Analysis and Design Technique) Un modelo realizado con la tcnica SADT permite representar las actividades de un proceso, definir las dependencias y relaciones entre dichas actividades, los controles que determinan o limitan su ejecucin, los mecanismos que los ponen en marcha, as como los datos que se utilizan, comparten o transforman en los procesos. Los diagramas SADT incorporan los procesos de la organizacin en orden secuencial, de acuerdo a su lgica de ejecucin mediante una numeracin que se refleja en la esquina inferior derecha de cada actividad. De esta manera se consigue un modelo de actividades que refleja el nivel de influencia de una actividad sobre el resto de las del proceso. Modelo Entidad/Relacin Extendido Se trata de una tcnica cuyo objetivo es la representacin y definicin de todos los datos que se introducen, almacenan, transforman y producen dentro de un sistema de informacin, sin tener en cuenta las necesidades de la tecnologa existente, ni otras restricciones. Dado que el modelo de datos es un medio para comunicar el significado de los datos, las relaciones entre ellos y las reglas de negocio de un sistema de informacin, una organizacin puede obtener numerosos beneficios de la aplicacin de esta tcnica, pues la definicin de los datos y la manera en que stos operan son compartidos por todos los usuarios. El modelo entidad/relacin extendido describe con un alto nivel de abstraccin la distribucin de datos almacenados en un sistema. Existen dos elementos principales: las entidades y las relaciones. Las extensiones al modelo bsico aaden adems los atributos de las entidades y la jerarqua entre stas. Estas extensiones tienen como finalidad aportar al modelo una mayor capacidad expresiva. Entidad Es aquel objeto, real o abstracto, acerca del cual se desea almacenar informacin en la base de datos. La estructura genrica de un conjunto de entidades con las mismas caractersticas se denomina tipo de entidad.

52

Relacin Es una asociacin o correspondencia existente entre una o varias entidades. La relacin puede ser regular, si asocia tipos de entidad regulares, o dbil, si asocia un tipo de entidad dbil con un tipo de entidad regular. Dentro de las relaciones dbiles se distinguen la dependencia en existencia y la dependencia en identificacin. Reglas de Transformacin El objetivo de esta tcnica es obtener un modelo fsico de datos a partir del modelo de clases. Para ello es necesario aplicar un conjunto de reglas de transformacin que conserven la semntica del modelo de clases. Cada uno de los elementos del modelo de clases se tiene que transformar en un elemento del modelo fsico. En algunos casos la transformacin es directa porque el concepto se soporta igual en ambos modelos, pero otras veces no existe esta correspondencia, por lo que es necesario buscar una transformacin que conserve lo mejor posible la semntica, teniendo en cuenta los aspectos de eficiencia que sean necesarios en cada caso. Tcnicas Matriciales Las tcnicas matriciales tienen como objetivo representar las relaciones existentes entre distintos tipos de entidades, objetos o cualquier otro elemento del sistema. Se utilizan, principalmente, para analizar la consistencia entre los modelos generados durante el desarrollo, comprobar la tras habilidad con los requisitos especificados por el usuario, etc. Las tcnicas matriciales son tiles para representar las relaciones entre elementos comunes de los distintos modelos, tales como entidades/procesos, procesos/dilogos, datos/localizacin geogrfica, y asegurar que los modelos son coherentes entre s.

Planificacin La planificacin de un proyecto es la previsin en fechas de la realizacin del conjunto de actividades que lo componen, teniendo en cuenta que se deben emplear para ello unos recursos que implican unos costes cuyo conjunto forman el presupuesto base para lograr un resultado comprometido con el Cliente. El objetivo bsico de la planificacin del proyecto es definir y preparar las condiciones de trabajo (estableciendo recursos, fechas y costes) para lograr los objetivos que se persiguen con el proyecto.

53

Para realizar una buena planificacin se deben utilizar diversas tcnicas, algunas de las cuales se exponen a continuacin. El mtodo PERT (Program Evaluation and Review Technique Tcnica de Evaluacin y Revisin de Programas) y el mtodo CPM (Critical Path Method Mtodo del Camino Crtico) constituyen las dos tcnicas pioneras en el campo de la moderna programacin y control de proyectos. Tanto el PERT como el CPM hicieron su aparicin aproximadamente hacia 1960.

PRCTICAS Las prcticas representan un medio para la consecucin de unos objetivos especficos de manera rpida, segura y precisa, sin necesidad de cumplir unos criterios rgidos preestablecidos, aunque se aconsejan determinadas pautas a seguir para la consecucin de los objetivos propuestos. Anlisis de Impacto El anlisis de impacto tiene como objetivo determinar, desde un punto de vista cuantitativo, qu elementos estn realmente implicados en las peticiones de cambio solicitadas por los usuarios, una vez que los sistemas de informacin se encuentran en produccin. Para facilitar la identificacin de dichos elementos, es imprescindible que exista en la organizacin un inventario de todos los componentes y las relaciones existentes entre ellos. Igualmente, es importante evaluar hasta qu punto dichos componentes se han documentado utilizando estndares de nomenclatura, lo que facilitar en mayor o menor medida su localizacin posterior.

Catalogacin La catalogacin tiene como objetivo estructurar y almacenar la informacin de un dominio concreto de forma nica, con el fin de poder gestionarla de manera sencilla a medida que se va modificando y facilitar su tras habilidad a lo largo del ciclo de vida. Se establece el mbito de aplicacin relevante, objeto de la catalogacin, con vista a su futura utilizacin. Ejemplo: requisitos, usuarios, objetivos, etc. A continuacin, se fija la informacin de inters que est asociada a un mbito concreto y se estructura del modo ms conveniente asocindole un nombre y sus caractersticas propias. En algunos casos se recogen aspectos generales que

54

definen la informacin a tratar y en otros, se registran elementos que pueden ir variando a lo largo del tiempo o que se necesitan para realizar la tras habilidad. Clculo de Accesos El clculo de accesos permite realizar una estimacin del nmero de accesos aproximado que debe realizarse para obtener la informacin de cada consulta, tomando como referencia las listas del modelo de datos obtenidas como consecuencia del anlisis de los caminos de acceso a los datos. Esta prctica se utiliza en los procesos Anlisis del Sistema de Informacin (ASI) y Diseo del Sistema de Informacin (DSI) aplicando los mismos criterios, la nica diferencia es que mientras en el primero el acceso es lgico y permite determinar la viabilidad de las consultas, en el segundo es fsico y permite establecer las pautas para la optimizacin del modelo fsico de datos. Caminos de Acceso El objetivo de esta prctica es analizar la secuencia de acceso a los datos que realizan los mdulos a travs del modelo de datos. Tambin puede utilizarse para entornos de ficheros. Permite verificar en el proceso Anlisis del Sistema de Informacin (ASI) que el modelo lgico de datos normalizado satisface las principales consultas de informacin recogidas en el catlogo de requisitos, y en el proceso Diseo del Sistema de Informacin (DSI) que el modelo fsico de datos soporta adecuadamente los principales accesos de actualizacin, cuando proceda, y de consulta.

Diagrama de Representacin El diagrama de representacin tiene como objetivo documentar mediante una imagen una situacin especfica. Se trata de un diagrama libre, en el que se utiliza cualquier objeto grfico, con el fin de reflejar algo de inters para el caso y para el que no existe una tcnica o prctica. Se describe, de la forma que se estime oportuno, cada uno de los elementos que componen el diagrama y, en el caso de ser necesario, la notacin que se haya empleado, con el fin de facilitar la comprensin del mismo. Todas las anteriores son explicaciones de algunas tcticas utilizadas por Mtrica 3, estas son esenciales a la hora de realizar un modelado.

55

5.5

EJEMPLO EXPLICATIVO

Unas de las primeros procesos al realizar un proyecto es hacer una planificacin. Esto lo platea mtrica3 con un proceso llamado planificacin de sistemas de informacin. Este proceso tiene una serie de tcnicas para su realizacin, en la que podemos destacar el diagrama de gantt que nos muestra una serie de actividades desde el inicio hasta el fin del proyecto, en una serie de tiempo. Planificacin proyecto software para una biblioteca.

En este diagrama se divide una serie de actividades en meses, estas actividades van a ser desde la primera actividad hasta la ltima que ya estara realizado el proyecto. El siguiente proceso en la realizacin de un proyecto es el de Desarrollo de sistemas de informacin, este proceso se basa en unas tcnicas que en su mayora son de UML.

56

Mtrica 3 trabaja gran cantidad de tcnicas, ya sean estructuradas o basadas en objetos. Mtrica 3 nos dice que hay que trabajar con estas tcnicas pero en si no es necesario trabar un proyecto con todas. A continuacin se realiza un caso de uso para modelar el comportamiento de una biblioteca que contiene un bibliotecario y un cliente.

Devolucion de ejemplar Bibli otecari o

Prestar ej empl ar

Prestatario Borra reserva

Hacer reserva

57

58

A continuacin se realiza un diagrama de clases donde se especifica un sistema encargado de la gestin de prstamos y reservas de libros de una biblioteca.
<<objeto del negocio>> <<objeto del negocio>>

Ejemplar
id : i nteger encontrar sobre titul o() crear() destruir() encontrar()

Titulo
nombre.stri ng autor.string numero de reserva

0..*

encontrar() crear() destruir()

<<Objeto del negocio>> Titulo DEL LIBRO

T iempo pendiente : Dias = 30

0..1

0..*

<<objeto del negocio>> Prestamo

feacha : Feacha = fecha_actual crear() destruir() encontarr()

<<objeto del negocio>> Reserva

fecha : Fecha = fecha_actual crear() destruir() encontrar()

0..* 0..*

0..* <<Objeto del negocio>> Informacion del prestatario Nombre : string Direccion : String Estado : string Codigo : string Crear() Destruir() Encontrar()

A continuacin se crea un diagrama de secuencia para su respectivo caso de uso. En este hace la simulacin del prstamo de un libro.

59

Ventana de Prestamos
: Bibl iotecario

Titulo

Informacion del prestatario

Prestamo

Ejemplar

1.Encontar titulo()
2.encontrar (string)

3.Encontrar ejemplar()

4.Encontrar sobre titulo(titulo)

5.Identificar prestatario()

6.Encontarr (String) Crear(informacion del texto,ejemplar)

Este es el respectivo diagrama de colaboracin

1: 1.Encontar titulo() 3: 3.Encontrar ej empl ar() 5: 5.Identifi car prestatario()

2: 2.encontrar (stri ng)

Ventana de Prestamos

Titulo

: Bibliotecario

4: 4.Encontrar sobre titulo(titul o) 7: Crear(informacion del texto,ejemplar) 6: 6.Encontarr (String)

Informacion del prestatario

Prestam o

Ejemplar

60

Con estos diagramas ya podemos pasar al siguiente proceso de interfaz que son especificadas atrs en el trabajo. Hay que tener en cuenta que no hay que realizar todas las tcnicas al hacer un proyecto.

61

CONCLUSIONES

A parte de las dos metodologas que presentamos en este trabajo, se nos presentaron en el camino, mas para utilizar. El camino a la hora de desarrollar software es amplio, y se divide, hay alternativas, las cuales se pueden utilizar dependiendo del tipo de software a elaborar. Hay unas que se pueden utilizar para todo, Hay otras como OMT-, que se pueden utilizar en conjunto con otras para conseguir un buen producto, hay metodologas que se centran en una sola parte de todo el desarrollo, otras que generalizan, que tocan lo mas que puedan todas las partes de un sistema. Hay tela de donde cortar, sin embargo, las metodologas que trabajamos, utilizan el lenguaje de modelado UML, pero no todos sus diagramas, unas utilizan solo unos, otras todos. Unas parten de un diagrama, y construyen todo su proyecto. Esto ayuda a que independientemente de la metodologa, el desarrollador, pueda entender un modelo, y modificarlo, puede de hecho mejorarlo, basarse en este, para desarrollar uno ms complejo, con mejor calidad, en fin, gracias a la utilizacin de este lenguaje, se pueden unificar sistemas, que adems, se pueden implementar en diferentes lenguajes de programacin, porque este es transparente al lenguaje que se utilice, con la caracterstica, que el lenguaje sea orientado a objetos, una de las recientes formas de programar.

62

63

BIBLIOGRAFIA

NBR ISO/IEC 12207 tecnologia de informao: processos de ciclo de vida de software. Ro de Janeiro: ABNT, 1998. http://www.mcc.unam.mx/~cursos/Objetos/Omt/omt.html http://www.monografias.com/trabajos6/meto/meto.shtml ISO/IEC TR 15504: Information Technology- software process assessment. Bate Byte 104 Dezembro/2000 - Aderncia do RUP Norma NBR ISO/IEC 12207 WWW.EXTREMEPROGRAMMING.ORG Brinda informacin concerniente a sta metodologa. www.willydev.net/descargas/prev/OMT.pdf

64