METRICA V3
1. Introducción
2. Herramientas utilizadas
3. Ciclo de Vida
INTRODUCCIÓN
• Objetivos metodología:
–
–
–
–
–
Definir SI para conseguir fines de la organización
Dotar a organización de productos software para usuarios
Mejorar productividad
Facilitar comunicación entre participantes
Facilitar operación, mantenimiento y uso.
• Características
–
–
–
–
–
–
Flexible y formalista
Identifica grupos implicados y responsabilidades
Muy centrada en la organización de la administración
Parte de versión anterior de METRICA (2)
Esta soportada por herramientas CASE comerciales
Permite desarrollo estructurado y OO
INTRODUCCIÓN
• Ciclo de vida:
– Se compone de:
• Procesos (que pueden tener a su vez otros procesos)
• Actividades
• Tareas
– Procesos de que consta :
• Planificación de Sistemas de Información
• Desarrollo de Sistemas de Información
–
–
–
–
–
Estudio de Viabilidad del Sistema
Análisis del Sistema de Información
Diseño del Sistema de Información
Construcción del Sistema de Información
Implantación y Aceptación del Sistema de Información
• Mantenimiento de Sistemas de Información
– Se ha desarrollado: Gestor Metodológico y un Selector
de herramientas
INTRODUCCIÓN
• Interfaces:
– Definen procesos de apoyo al desarrollo u organizativos
– Son las siguientes:
–
–
–
–
Gestión de Proyectos
Seguirdad
Gestión de la Configuración
Aseguramiento de la calidad
• Herramientas utilizadas. En función del propósito
• Técnicas, se apoya en estándares y notaciones específicas en
términos de sintaxis y semántica.
• Prácticas, medio para la consecución de unos objetivos, sin
reglas preestablecidas.
Técnicas de desarrollo
• Estructuradas
• DFDs, Diagramas de estructura, Diagramas de transición de estados
• Modelo Entidad Relación Extendido, normalización, optimización, obtención
del modelo físico desde el lógico.
• Orientadas a objetos
• Casos de Uso, diagrama de clases, de componentes, de paquetes
• Diagramas de interacción (secuencia y colaboración).
• Reglas de transformación
• Otras
•
•
•
•
Análisis Coste-Beneficio
Diagramas de descomposición, Diagramas de despliegue
SADT (Structured Analysis and Design technique)
Técnicas matriciales
• Técnicas de gestión de proyectos
•
•
•
•
•
Estimación, PERT y Gantt
Métodos para el análisis de Ptos.Función: Albrecht, MARKII
Staffing Size (OO)
Estructura de descomposición de trabajo (WBS)
Diagrama de extrapolación
Prácticas
• Las prácticas que contempla la metodología son las siguientes:
•
•
•
•
•
•
•
•
•
Análisis de impacto
Catalogación
Cálculo de accesos y Caminos de Acceso
Diagramas de representación
Factores críticos de éxito
Impacto en la Organización
Presentaciones
Prototipado
Pruebas: unitarias, de integración, del sistema, de implantación, de aceptación
y de regresión
• Revisión formal, Revisión técnica
• Sesiones de trabajo: entrevistas, reuniones, JAD (Joint Application Design),
JRP (Joint Requierements Planning)
Técnicas estructuradas
• DFDs
• Diagramas de estructura
• Diagramas de transición de estados
•
•
•
•
Modelo Entidad Relación Extendido
Normalización
Optimización
Obtención del modelo físico desde el lógico
Diagramas estructura
• Muestra la estructura modular del sistema. Parte del
modelo de procesos (conjunto DFDs)
• Elementos
– Módulo, representa un programa, subprograma o rutina. Interface
clara con el resto modulos. Debe cumplir:
• Pequeño
• Independientes
• Realiza función clara y sencilla
– Conexión, llamada entre módulos.
– Parámetro, información intercambiada
• Control, sincronizan la operativa de los módulos
• Datos, información que se comparte entre módulos
– Otros : Módulo predefinido, almacén de datos, dispositivo físico
– Estructuras: secuencial, repetitiva, alternativa
Diagramas estructura
Análisis centrado en transformación
1.
2.
3.
4.
Identificar el centro de
transformación
Realizar primer nivel de
factorización: Entrada,
Transformación, Salida
Elaborar segundo nivel
de factorización
Refinar la estructura
usando medidas y guías
diseño
Diagramas estructura
Análisis centrado en transacción
1.
Identificar el centro de
transacción
2. Se construye una
estructura con una
bifurcación de entrada y
otra de salida
3. Factorizar la estructura de
cada camino
4. Refinar la estructura
usando medidas y guías
diseño
Diagramas de transición de estados
• Muestra comportamiento dependiente del tiempo.
• Elementos
– Estado, comportamiento que perdura en tiempo. Un
estado inicial, uno o varios finales excluyentes
– Transición, cambio de estado producido por un evento
(nom_evento (par.) [cond]/acción)
• Acción: op. instantánea asociada a evento
• Actividad: op. Asociada a estado que se ejecuta hasta que se
produce el cambio a otro estado
• Se puede hacer una jerarquía de DTE.
Diagramas de transición de
estados
Modelo Entidad Relación Extendido
• Objetivo: representación de todos los datos que se introducen,
almacenan, transforman y producen dentro de un sistema de
información, sin tener en cuenta las necesidades de la tecnología
existente, ni otras restricciones.
• Nuevos conceptos
– Generalización /Especialización
– Categorías
– Agregación
– Exclusividad
Normalización
• Objetivo: eliminación de dependencias entre atributos que
originen anomalías en la actualización de los datos,
constituyendo el soporte para el diseño de bases de datos
relacionales.
• Resultado: modelo lógico de datos normalizado.
• Formas normales:
– Primera forma normal (1FN): No tiene grupos repetitivos, es decir,
un atributo sólo puede tomar un único valor de un dominio simple.
– Segunda forma normal (2FN): Todos los atributos que no forman
parte de las claves candidatas tienen dependencia funcional
completa respecto de éstas.
– Tercera forma normal (3FN): Todos los atributos no principales
dependen directamente de la clave primaria, es decir, no hay
dependencias transitivas.
Obtención del modelo físico desde el lógico
• Objetivo: obtener el módelo físico de datos a partir del modelo
lógico de datos normalizado.
• Descripción:
– Transformación de entidades: Una entidad se transforma en una tabla.
– Transformación de atributos: una columna de la tabla en la que se transformó
la entidad a la que pertenece. El identificador único se convierte en clave
primaria.
– Transformación de relaciones:
• Relaciones 1:N, se propaga el identificador de la entidad de cardinalidad máxima
1 a la que es N.
• Relaciones 1:1, es un caso particular de las 1:N y por tanto se propaga la clave
en las dos direcciones.
• Las relaciones de agregación se transforman del mismo modo que las 1:N.
• Transformación de relaciones exclusivas
– Transformación de la jerarquía:
• Opción a: Crear una tabla para el supertipo y una tabla para cada subtipo
• Opción b: Se crea una tabla para cada subtipo
• Opción c: Una tabla todos los atributos de la entidad supertipo y de los subtipos
Optimización
• Objetivo: reestructurar el modelo físico de datos con el fin de asegurar que
satisface los requisitos de rendimiento establecidos y conseguir una adecuada
eficiencia del sistema.
• Consiste en una desnormalización controlada del modelo físico de datos
• Recomendaciones:
–
–
–
–
Introducir elementos redundantes (atributos, relaciones...)
Dividir entidades.
Combinar entidades si los accesos son frecuentes dentro de la misma transacción.
Definir claves secundarias o índices para permitir caminos de acceso alternativos.
• Factores a tener en cuenta:
–
–
–
–
–
–
–
–
–
Los tiempos de respuesta requeridos.
La tasa de actualizaciones respecto a la de recuperaciones.
Las veces que se accede conjuntamente a los atributos.
La longitud de los mismos.
El tipo de aplicaciones (en línea / por lotes).
La frecuencia y tipo de acceso.
La prioridad de los accesos.
El tamaño de las tablas.
Requisitos de seguridad: accesibilidad, confidencialidad, integridad y disponibilidad
Técnicas Orientadas a Objetos
•
•
•
•
•
Casos de Uso
Diagrama de clases
Diagrama de componentes
Diagrama de paquetes
Diagramas de interacción
– Secuencia
– Colaboración
• Reglas de transformación
Casos de Uso
• Objetivos:
– Capturar requisitos funcionales del sistema desde pto.vista del usuario
– Guiar todo el proceso de desarrollo del SI
• Describe el comportamiento del sistema para dar respuestas a los
usuarios.
• Diagramas de Casos de Uso, elementos:
– Actores, se encuentra fuera del sistema e interactúa con él.
– Casos de uso, representa el comportamiento que ofrece el sistema.
– Relaciones, es una comunicación:
• entre el actor y un caso de uso (línea contínua)
• entre casos de uso:
– <<usa>>, comportamiento común a varios casos de uso (de básico al común)
– <<extiende>>, comportamiento opcional de un caso de uso (de opcional al básico)
Casos de uso
Diagrama de Clases
• Objetivo: representar los aspectos estáticos del sistema; recogiendo las
clases de objetos y sus asociaciones.
• Elementos:
– Clases: conjunto de objetos con propiedades similares y comportamiento
común.
– Relaciones:
•
•
•
•
•
Asociaciones: dependencias semánticas. Se puede indicar rol y multiplicidad.
Herencia (generalización/especialización)
Agregación (parte de)
Composición (agregación fuerte)
Dependencia (una clase requiere de otra para proporcionar algún servicio)
– Interface: operaciones visibles desde otras clases o paquetes
– Paquetes: agrupación de clases o paquetes según el criterio que se
considere.
Diagrama de Clases
Diagrama de Componentes
• Objetivo: visión física de la construcción del sistema de información.
Muestra la organización de los componentes software, sus interfaces y
las dependencias.
• Elementos:
– Componente: módulo software
– Interfaz: operaciones externas del componente
– Dependencias, esto indica que uno de ellos usa los servicios o facilidades
del otro.
Diagrama de Componentes
Diagramas de Interacción
• Objetivo: describir el comportamiento dinámico del sistema, paso de
mensajes entre objetos.
• Representa un escenario de un Caso de Uso.
• Elementos:
– Objetos: entidad que tiene un estado, un comportamiento y una identidad.
– Mensajes: comunicación entre dos objetos.
• Dos tipos:
– Diagramas de secuencia: muestran las secuencias de mensajes
intercambiados por los objetos.
– Diagramas de colaboración: Muestran de forma más detallada cómo
colaboran los objetos.
Diagramas de secuencia
• Objetivo: describir el comportamiento dinámico del sistema.
Concretamente muestran las secuencias de mensajes intercambiados
por los objetos.
• Tiene dos dimensiones
– Vertical: representa el paso del tiempo
– Horizontal: los distintos objetos, el orden es indiferente.
• Elementos:
– Objetos y línea de vida
– Foco del control o activación
– Mensaje: se indica el nombre del mensaje y los argumentos. Pueden
representar también condiciones e iteraciones.
Diagramas de secuencia
Diagramas de colaboración
• Objetivo: Muestran de forma más detallada cómo colaboran los
objetos, o sea, qué objetos tienen vínculos o intercambian mensajes.
• Se muestra la misma información que en el caso anterior pero de forma
diferente.
• Elementos:
– Objeto, un rectángulo con el nombre del objeto y/o de la clase
– Vínculo: línea continua que indica una asociación entre clases.
– Mensaje: flecha que indica el mensaje que va del objeto emisor al
receptor.
Diagramas de colaboración
Diagramas de paquetes
• Objetivo: Dar una visión de más alto nivel del sistema agrupando
determinadas partes en paquetes. Pueden agrupar: casos de usos, clases
o componentes.
• Elementos:
– Paquetes, pueden contener otros paquetes.
– Dependencias: que indican que un paquete necesita de un elemento de
otro paquete.
Diagramas de paquetes
Otras técnicas: Diagrama de despliegue
• Muestran las particiones físicas del sistema y la asignación de
componentes software a esas particiones. O sea, las relaciones entre el
hardware y el software del sistema a entregar.
• Se representan:
– nodos:que representa una partición física (cubos)
– conexión: línea, representa una red, un canal, un protocolo, etc.
Otras técnicas:
Análisis Coste-Beneficio
• Objetivo: Proporcionar una medida de los costes de
realización del proyecto.
• Pasos:
– Producir estimaciones de costes-beneficios.
• Costes,tangibles: Equipo hardware, Personal (+ formación),
Conversión, Consultoría
• Beneficios: Aspectos tangibles: dinero, tiempo...y no tangibles
– Determinar viabilidad y su aceptación. Métodos:
• Retorno de la inversión. En que año se recupera el coste estimado
inicialmente.
• Valor actual. Cuanto conviene invertir indicando el periodo de
tiempo.
Otras técnicas: Diagrama de
descomposición
• Representan la estructura
jerárquica de un dominio
concreto.
• Toma un nombre distinto
dependiendo del dominio al que
se aplique:
– de descomposición funcional
– de descomposición
organizativo
– de descomposición en diálogos
• Los elementos del dominio se
representan mediante
rectángulos y las relaciones con
líneas.
Otras técnicas: SADT (Structured
Analysis and Design technique)
• Describe el modelo de procesos de la organización
– Proceso de la organización, se descompone en actividades (qué) y
procedimientos (cómo), además se identifica quien lo hace.
– Modelo de procesos, diagrama que representa las interacciones entre
actividades, objetos y recursos.
– Tipos de procesos: principales y de soporte.
• SADT puede construir el diagrama de procesos de la organización.
– Los procesos se describen de forma secuencial, de acuerdo a su ejecución.
– Se describen con un enfoque de descomposición por niveles
– Hay cuatro tipos de interconexiones entre actividades:
•
•
•
•
Entrada de información (entra por la izq..)
Salida de información (sale por la dcha..)
Control, restricciones que afecta a la actividad (entra por arriba)
Mecanismos, el ejecutor de la actividad; se indican en el caso de que difieran
en el entorno actual y el futuro.
SADT (Structured Analysis and Design Technique)
Otras técnicas: Técnicas matriciales
• Se designan así a la representación cruzada de distintos objetos para la
Organización.
• Se recogen las siguientes matrices:
–
–
–
–
–
–
Procesos-localización geográfica
Almacenes de datos -Entidades de Datos
Procesos-Entidades de Datos
Diálogos-Procesos
Objetos del diagrama de interacción- Clases
Y muchas más...
• Notación: matriz en la que se indican los dos tipos de elementos y en el
cruce entre ambos se tendrá el modo en el que se relacionan o si se
relacionan o no.
Técnicas de gestión de proyectos
•
•
•
•
•
•
PERT: Muestran las relaciones entre las distintas tareas del proyecto, para
ayudar en su planificación.
Gantt: indica el plan de trabajo, o sea, las tareas a realizar y el punto de
comienzo y fin de cada una de ellas.
Estimación : Métodos para el análisis de Ptos.Función: Albrecht, MARKII: El
objetivo de las técnicas de estimación es calcular, de la forma más fiable
posible, el coste total del desarrollo de un sistema de información
Staffing Size (OO): Son métricas para estimar el número de personas
necesarias en un desarrollo OO, en función del número y tipo de clases que es
necesario definir y el lenguaje de programación.
Estructura de descomposición de trabajo (WBS): Permite estructurar las
actividades gráficamente.
Diagrama de extrapolación. Permite realizar el seguimiento del proyecto,
viendo las desviaciones con respecto al tiempo previsto.
Prácticas
• Análisis de impacto
– Objetivo: determinar, desde un pto. de vista cuantitativo, qué elementos
están implicados en las peticiones de cambio solicitadas por los usuarios.
– Se necesita un inventario de todos los componentes, para identificar los
afectados de forma eficiente y a partir de ellos se determina la
complejidad del cambio.
• Catalogación: Indica cómo estructurar la información de un dominio
concreto
• Cálculo de accesos: Calcula el núm. de accesos que debe hacerse para
una consulta (pto de vista del modelo de vistas del modelo de datos).
Puede ser lógico y físico. Se usa una notación matricial
• Caminos de Acceso
– Analiza la secuencia de accesos de los módulos a los datos.
– Se generarán tantas vistas como sea necesario
– Se aplicara a módulos con tratamientos críticos, accesos complejos a los
datos o alta concurrencia.
Prácticas
• Diagramas de representación. Documenta mediante una imagen una
situación específica.
• Impacto en la Organización. Analiza las consecuencias que tienen para
la organización un cambio en los sistemas y tecnologías utilizadas.
• Presentaciones. Es necesario establecer el alcance de la presentación,
indicando objetivos y contenido general. Es importante el ponente
(experto), tiempo, importancia del contenido y de la forma, etc.
• Prototipado. Modelo de la interface entre el sistema y el usuario, éste
ha de colaborar en su desarrollo.
• Revisión formal. Objetivo: detectar y registrar los defectos de un
producto intermedio, mediante un proceso riguroso
• Revisión técnica. Objetivo: evaluar un producto intermedio, para
comprobar que se ajusta a especificaciones y estándares.
Prácticas: Factores críticos de éxito
• Tiene como objetivo ayudar a la planificación de actividades y
recursos de una Organización.
• Factor de Éxito: algo que debe ocurrir para conseguir un objetivo. Si es
imprescindible para conseguir los objetivos de la Organización =>
Factor crítico de éxito.
• Habrá al menos un F. de Éxito por cada Objetivo.
• Procedimiento:
1. Lista de Objetivos de la Organización.
2. Depurar la lista de Objetivos.
3. Identificar los factores de éxito.
4. Eliminar los factores de éxito no críticos.
5. Agrupar los factores de éxito de acuerdo con los objetivos
6. Identificar componentes de esos Factores
7. Seleccionar los factores críticos de éxito.
8. Finalizar el estudio (Obtención de las Areas)
Prácticas: Sesiones de trabajo
• Entrevistas: sesiones de trabajo dirigidas a obtener la información de
una forma individual
• Reuniones: varias personas y es necesario trabajar en grupo. Es
necesario prepararla previamente y tener un orden del día, resumir
resultados y plasmarlos en un acta.
• JAD (Joint Application Design). Objetivo: reducir el tiempo de
desarrollo de un sistema, manteniendo su calidad.
– Se establece un equipo de trabajo, con componentes y responsabilidades
fijas
– Se llevan a cabo pocas reuniones largas y bien preparadas
– Durante la sesión se elaboran los modelos, empleando diagramas sobre la
propia CASE.
• JRP (Joint Requierements Planning). Objetivo: potenciar la
participación activa de la alta dirección. Dinámica semejante al caso
anterior, aunque se obtienen visiones de más alto nivel del sistema.
Prácticas:Pruebas
• Objetivo: Encontrar errores.Componente que permite asegurar la calidad del
software, junto con otros.
• Para cada sistema se realizarán:
– Prueba de la Unidad: Caja blanca y Caja negra
– Prueba de Integración: Incremental o no incremental.
• Top-Down. No necesario módulos conductores
• Bottom-Up. Difícil de planificar, más paralelo.
• Combinadas.
– Prueba del Sistema
•
•
•
•
•
•
•
•
•
•
Pruebas funcionales
Pruebas de comunicaciones
Pruebas de rendimiento
Pruebas de volumen
Pruebas de sobrecarga
Pruebas de disponibilidad de datos
Pruebas de facilidad de uso
Pruebas de operación
Pruebas de entorno
Pruebas de seguridad
• Pruebas de Aceptación. Realizadas por el usuario. Ej. en paralelo con el viejo
sistema.
• Pruebas de Regresión. Debidas a cambios en el código y al mantenimiento.
Ciclo de Vida
• Los procesos principales de MÉTRICA 3, son los siguientes:
– Planificación de Sistemas de Información (PSI). Proporciona el marco
estratégico de referencia
– Desarrollo de Sistemas de Información
• Estudio de Viabilidad del Sistema (EVS). Se estudian las necesidades para
proporcionar una solución a corto plazo.
• Análisis del Sistema de Información (ASI). Especificación detallada del SI.
• Diseño del Sistema de Información(DSI). Definición de la arquitectura del
sistema y especificación detallada de los componentes del mismo.
• Construcción del Sistema de Información(CSI). Construcción y prueba de los
distintos componentes del sistema
• Implantación y Aceptación del Sistema (IAS). Entrega y aceptación del
sistema en su totalidad.
– Mantenimiento de Sistemas de Información (MSI). Obtener una nueva
versión de un sistema a partir de los cambios solicitados por los usuarios.
Descargar

METRICA Versión 3