Desarrollo de aplicaciones informáticas

Introducción a los Sistemas Informáticos

Compartir 0 Me sirvió 0 No me sirvió

CAPITULO I : INTRODUCCIÓN A LOS S.I.

EL CONCEPTO DE SISTEMA

Definiciones.
Elementos.
Relaciones.
Enfoque Sistémico.

DEFINICIONES

- “Sistema” : Concepto o herramienta genérica para analizar el funcionamiento de un área.

- “Sistema” (según el DRAE) : Conjunto de cosas utilizadas para lograr un objetivo.

ELEMENTOS DEL SISTEMA

Componentes del sistema.
Relaciones entre elementos. (Que determinan la estructura del sistema)
Objetivo del sistema.

OTROS ELEMENTOS

Entorno del sistema.
Límites del sitema. (“Frontera entre el sistema y el entorno”)

REALCIONES DEL SISTEMA

Entre componentes: permiten considerarlo como 1 unidad. Aseguran su cohesión.
Con el exterior. (“Entradas y salidas del sistema)

ENFOQUE SISTÉMICO U HOLÍSTICO

Manera de estudiar o analizar sistemas mediante una visión global y refinamientos sucesivos (descomposición de arriba-abajo: Top-down).
1. Se toma todo el sistema como una caja negra de la que sólo nos interesan sus entradas y salidas.
2. Se identifican los subsistemas y las relaciones entre ellos.
3. Se llevan a cabo descomposiciones sucesivas hasta que los componentes sean tan simples que se puedan estudiar fácilmente
Muy útil en aplicaciones de software grande.

EL CONCEPTO DE INFORMACIÓN

Diferencia entre dato e información
Calidad de Información
Propiedades de la calidad de información

DIFERENCIA ENTRE DATO E INFORMACIÓN

Datos: se constituyen por registros de los hechos, acontecimientos, transacciones…
Información: “datos procesados”. Son útiles o significativos para el receptor.

Se consideran los datos como la “materia prima para obtener información”.
Procesar = “indicar el significado de los datos”.
Procesar = “dar significación a un dato en un contexto”.

CALIDAD DE INFORMACIÓN

Conjunto de cualidades que disminuyen la incertidumbre y ayudan al receptor a tomar la decisión más ventajosa.

PROPIEDADES DE LA CALIDAD DE INFORMACIÓN

Relevante para el el propósito de la decisión o el problema considerado
Precisa (exacta con la realidad). Que se pueda confiar en ella. No existe la `precisón absoluta'.
Suficientemente completa para el problema. Lo “ideal” es contar con toda la información relevante. Lo más importante es que la información sobre los elementos clave sea completa.
Se comunica a la persona adecuada para la decisión.
Se comunica a tiempo para que pueda ser útil.
Llega al nivel de detalle más adecuado.
Es comprensible para el receptor.

LOS SISTEMAS DE INFORMACIÓN

Funciones de la infraestructura de una empresa
Distintas estructuras en las empresas (mariconadas)
Definiciones de Sistema de Información
Elementos de un S.I.
Estructura de un S.I.
Flujos de información en una empresa
Tecnologías de la Información
Otros conceptos

FUNCIONES DE LA INFRAESTRUCTURA DE UNA EMPRESA

Controlar y Gestionar recursos (función o sistema contable y de gestión económica).
Comercializar (Actividad comercial y de ventas)
Fabricar servicios o crear productos (Producción)

DISTINTAS ESTRUCTURAS EN LAS EMPRESAS (Mariconadas)

Por funciones y departamentos.

Control y Gestión.
Comercio.
Producción.

Por localización geográfica.
Por jerarquía y niveles de actuación.

DEFINICIONES DE SI

Las definiciones más empleadas de S.I. parten de la base de que lo principal es el objetivo perseguido.

Def 01 : Conjunto formal de procesos (operando sobre una colección de datos estructurada según las necesidades de la empresa) que recopilan, elaboran y distribuyen la información necesaria para llevar a cabo las operaciones de empresa y las actividades de dirección y control.
Def 02 (by Inma) : El sistema encargado de coordinar los flujos y los registros de información necesarios para desarrollar una actividad de acuerdo a su estrategia o planteamiento.

ELEMENTOS DE UN S.I.

Procedimientos y prácticas habituales de trabajo.
Información.
Personas o usuarios.
Equipo de soporte (parte física: papel, máquina de escribir, ordenadores…)

La información de un S.I. puede ser informal o formal:

Información formal: la información “física”. De la que tenemos constancia y podemos confiar en ella.
Información informal: (Ej.) rumores, diálogos personales…

ESTRUCTURA DE UN S.I.

Operaciones y transacciones: se encarga del procesamiento de actividades diarias o transacciones (acontecimientos rutinarios: pagos, facturación…). Las transacciones constituyen la mayor parte de las actividades que se realizan en la empresa.

Características de las transacciones:

Los procedimientos de tratamiento se comprenden bien y se pueden describir en detalle.
Hay pocas excepciones a procedimientos normales.
Gran volumen de transacciones.
Gran similitud entre transacciones.

Los procedimientos de transacciones han de describir, tanto los pasos a seguir en una situacion normal, como en una excepcional.

Nivel Operativo de Dirección: analizar los resultados (usualmente respecto a los recursos: diner, tiempo…) consumidos en las transacciones para tomar decisiones a corto plazo. Normalmente suele trabajar con información del registro de transacciones.

Características de la información empleada:

Repetitiva (informes periódicos de ventas, pagos…)
Centrada en el pasado (resultados históricos)
Con datos originados internamente
Datos con formato bien estructurado
Datos detallados y precisos.

Nivel táctico de dirección: asignación efectiva de recursos a medio plazo (se suele actuar con un año de antelación), para mejorar el rendimiento de la empresa.

Tipos de informes anailizados

Resúmenes con medias estadísticas.
De excepciones (departamentos que han consumido más de la media, centros con pérdidas…)
Específicos (informes que no se han pedido antes y que los directivos necesitan urgentemente para resolver problemas muy concretos)

Se trabaja con el propósito de descubrir algo nuevo en los datos.

Nivel Estratégico de Dirección: pretende decidir las pautas a seguir por la empresa en el futro (plazos largos: 3-5 años). La información que maneja ha de tener un formato muy resumido para lograr predecir lo mejor para el éxito futuro de la compañía. Normalmente se toman decisiones con un fuerte componente subjetivo.

FLUJOS DE INFORMACIÓN EN LA EMPRESA

Flujos vericales ascendentes: (subordinado superior). Informes sobre resultados de actividades. Carácter histórico y de orientación al pasado.
Flujos verticales descendentes: (jefe subordinado). Órdenes y solicitudes específicas.
Flujos horizontales: (entre personas del mismo nivel). Al contenido de esta información se le llama “información de coordinación”. Se consideran estos flujos un medio esencial para adaptarse mejor al mercado.

TECNOLOGÍAS DE LA INFORMACIÓN

Def: Sofisticadas herramientas que nos permiten implantar los actuales sistemas de información.

OTROS CONCEPTOS

(MIS) Sistema de información para la Gestión: proporcionan a los directivos información y ayuda para decisiones `estructuradas'. Es la parte del S.I. dediacada al nivel operativo táctico y estratégico.
(DSS) Sistema de apoyo a las decisiones: similar al MIS. Da soporte a decisiones poco estructuradas.
Sistema de procesamiento de transacciones: para el tratamiento de operaciones rutinarias diarias o transacciones.

“POSIBLES” PREGUNTAS CAPÍTULO I

1. Señala la respuesta incorrecta, ¿El enfoque TOP-DOWN?:

Se utiliza para el desarrollo de aplicaciones software.
Consiste en analizar y desarrollar un sistema por refinamiento sucesivo mediante descomposición de arriba abajo.
Se denomina también Botton-Up y consiste en dividir el sistema en subsistemas considerándolos cajas negras de las que lo que más nos interesa es su interior.
Es una filosofía de análisis y diseño que permite descomponer un trabajo complicado en tareas de programación más sencillas.

2. ¿Cuál de las siguientes características no forma parte de la calidad de información?:

Se aconseja que sea comunicada a tiempo, pero no es primordial.
Debe tener relevancia y complitud.
Debe llegar a la persona adecuada y con el nivel de detalle más adecuado, para que esta persona pueda decidir con dicha información.
Debe ser fiable y comprensible.

¿Cuál de las siguientes afirmaciones es correcta? Los flujos de información en la empresa:

Los que circulan desde el personal de base a los directivos se llaman verticales descendentes.
Los que van desde superiores al personal subordinado se llaman horizontales ascendentes.
Los que no aparecen en los organigramas de las empresas se llaman comunicaciones informales.

¿Cuál de las siguientes afirmaciones no es correcta?:

Un S.I. forma parte de todos los subsistemas que puedan detectarse en una empresa.
No pueden existir sistemas de soporte de información puramente manuales.
Un S.I. No tiene por qué estar totalmente automatizado.
Cabe distinguir entre S.I., S.I.A. y Sistema Informático de Soporte.

¿Cuál de las siguientes afirmaciones es correcta?:

El único objetivo de una empresa es ganar dinero.
Un dato siempre está guardado en una variable.
Un dato es información si disminuye nuestro nivel de incertidumbre.
La información debe ser tratada siempre informáticamente.

En exámenes anteriores…

Los principales elementos que encontramos en cualquier sistema:

Componentes, relaciones que determinan la estructura y objetivos.
Objetivos, límites y estructura.
Componentes, relaciones y entorno.

Indica cuáles son los elementos de un S.I.:

Los procedimientos y prácticas de trabajo, los objetivos y las relaciones.
Los procedimientos y prácticas de trabajo, la información, las personas y el equipo de soporte.
Los objetivos, la información y los procedimientos y prácticas de trabajo.

¿Cuál de las siguientes afirmaciones no es correcta?:

Las prácticas de trabajo determinan la información que se necesita en un S.I.
Los objetivos de la empresa determinan las prácticas de trabajo.
La información determina las carácterísticas del equipo Humano del S.I.

¿Cuál de las siguientes afirmaciones es correcta?:

La información debe ser tratada siempre informáticamente.
Un dato es información si disminuye nuestro nivel de incertidumbre.
El único objetivo de una empresa es ganar dinero.

La técnica de análisis de sistemas:

Estudia todas sus entradas.
Sigue un enfoque sistémico.
Estudia el sistema adoptando una visión parcial del mismo hasta llegar a su visión global.

La estructura de un S.I.:

Se puede describir mediante una pirámide en la que se distingue la jerarquía de diversos niveles de actuación y gestión.
Se puede describir mediante un grafo de niveles según una organización geográfica.
Se puede describir mediante un organigrama según departamentos o funciones.

CAPITULO II : SISTEMAS DE INFORMACIÓN BÁSICOS EN LAS EMPRESAS

SUBSISTEMA DE RECUROS HUMANOS
ACTIVIDADES	Plantilla Nómina
NIVEL OPERATIVO	Mantenimiento de datos de los empleados Inventario de cualificaciones de empleados Inventario de puestos de trabajo y condiciones Evaluación de empleados Generación de informes Gestión de solicitudes de empleo Envío de instrucciones de pago de salarios
NIVEL TÁCTICO	Perfil de la persona ideal PRO puesto de trabajo Necesidades de contratación de personal Generar planes PRO incentivos y beneficios a empleados Análisis de necesidades de información y creación de planes para mejorar el nivel táctico-profesional de la plantilla
NIVEL ESTRATÉGICO	Crear planes para mejorar la infraestructura de la empresa
TECNOLOGÍAS DE LA INFORMACIÓN	Realización de nóminas mediante aplicaciones de trabajo por lotes Gestión de personal mediante tratamientos interactivos Protección de datos mediante control de acceso

SUBSISTEMA DE CONTABILIDAD Y FINANZAS
ACTIVIDADES	Llevar la contabilidad
NIVEL OPERATIVO	Control de activos fijos Gestión de cobros Gestión de pagos Control de inventario Ejecución de nómina Generación de informes
NIVEL TÁCTICO	Gestión y control de presupuestos Información sobre el flujo de caja Controles de planes de gasto de capital
NIVEL ESTRATÉGICO	Trabajo de forma interactiva Trabajo con gran volumen de datos
TECNOLOGÍAS DE LA INFORMACIÓN	Automatización de transacciones Gestión económica mediante (grandes) bases de datos Análisis financieros mediante simulaciones muy elaboradas Análisis estadístico

SUBSISTEMA COMERCIAL Y DE VENTAS
ACTIVIDADES	Ventas	Gestión y tratamiento de pedidos Facturación Control de detalles de entrega y actualización de inventario
		Comercialización	Información de ventas Investigación de mercados Informes técnicos de producción Datos sobre la capacidad financiera de la empresa
	NIVEL OPERATIVO	Apoyo a vendedores	Gestión de carteras de clientes Control de contactos con clientes Consultas sobre productos Información sobre crédito o consideración económica de cliente Facilidades para la gestión de pedidos y facturas
		Gestión de distribución de productos	Control de envíos Recepción Devoluciones
NIVEL TÁCTICO	Recogida de información de ventas Gestión y control del marketing Establecimiento de precios Decidir la mejor forma de distribución Análisis de competidores
NIVEL ESTRATÉGICO	Dividir mercado Seleccionar segmentos a acceder Planificar productos y servicios a ofertar Predecir ventas a trabajar
TECNOLOGÍAS DE LA INFORMACIÓN	Pedidos y facturación mediante aplicaciones de trabajo por lotes Gestión comercial mediante grandes bases de datos Análisis de mercado mediante simulaciones complejas y análisis estadísticos

SUBSISTEMA DE PRODUCCIÓN
ACTIVIDADES	Control de existencias almacenadas
NIVEL OPERATIVO	Compras de materias primas o componentes Recepción de materias primas o componentes Envío de productos a clientes
NIVEL TÁCTICO	Gestión y control de materias primas y productos Planificación de la capacidad de producción óptima
NIVEL ESTRATÉGICO	(.) Suelen ser decisiones estratégicas de alta dirección
TECNOLOGÍAS DE LA INFORMACIÓN	Sistemas de control y automatización de producción

RESPUESTAS

1	2	3	4	5	6	7	8	9	10	11
c	a	c	b	c	a	b	c	b	b	a

CAPITULO III : CICLO DE VIDA DEL SOFTWARE

Concepto de Ciclo de Vida.
Procesos del Ciclo de Vida.
Modelo en cascada.
Modelo incremental.
Modelo en espiral.

CONCEPTO DE CICLO DE VIDA

Los departamentos de un S.I. requieren un marco de referencia…

…que pueda ser empleado por todas las personas que participan en un desarrollo informático.
…en que se definan los procesos, las actividades y las tareas a desarrollar.

DEFINICIONES

Según IEE 1074: “El Ciclo de Vida es una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software”.
Según ISO 12207-1: “El ciclo de vida es un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto software, abarcando la vida del sistema desde la definición de requisitos hasta la finalización de su uso”.

El Ciclo de Vida abarca toda la vida del sistema (desde su “concepción” hasta que ya “no se utiliza”).

PROCESOS DEL CICLO DE VIDA DEL SOFTWARE

Procesos Principales.
Procesos de Soporte.
Procesos Generales.
Proceso de Adaptación.

MODELO EN CASCADA

Características.
Críticas.

CARACTERÍSTICAS

Cada fase empieza cuando ha terminado la anterior.
Para pasar de una fase a otra se han de conseguir todos los objetivos de la fase previa.
Ayuda a prevenir que se sobrepasen las fechas de entrega y los costes esperados.
Al final de cada fase, el personal técnico y los usuarios pueden pueden revisar el progreso del proyecto.

Es el Ciclo de Vida más antiguo y el más utilizado.

CRÍTICAS

No refleja el “proceso real” del desarrollo del software NO contempla iteraciones en etapas no contiguas.
Se requiere mucho tiempo para pasar todo el ciclo ( hasta que no se finalice una etapa no se comienza la siguiente ).
Acentúa el fracaso de la industria del software con el usuario final El sistema no funciona hasta casi el final.

MODELO INCREMENTAL

CARACTERÍSTICAS

Corrige la necesidad de una secuencia NO lineal añadiendo componentes funcionales al sistema (“incrementos”).
En cada paso se actualiza el sistema.
El sistema software acaba siendo la integración de los resultados sucesivos (obtenidos después de cada iteración).

Se ajusta a entornos de alta incertidumbre.

CRÍTICAS

Cuenta con el problema de que es difícil determinar si los requisitos propuestos son válidos Los errores en los requisitos son detectados tarde y su corrección es costosa.

MODELO EN ESPIRAL

Características.
Diferencias respecto a los modelos tradicionales.
Dificultades.

CARACTERÍSTICAS

Consta de una serie de ciclos. Para cada uno de los ciclos, primero se identifican sus objetivos, alternativas y restricciones. Posteriormente se lleva a cabo dicho ciclo para, una vez acabado éste, comenzar a plantear el siguiente.
Cada ciclo se completa con una revisión.

DIFERENCIAS RESPECTO A LOS MODELOS TRADICIONALES

Reconocimiento explícito de diferentes alternativas para lograr los objetivos del proyecto.
Identificación de riesgos asociados a las alterntivas y la manera de resolverlos (“centro del modelo”).
División de proyectos en ciclos.
El modelo se adapta a cualquier tipo de actividad.

DIFICULTADES

Trabaja bien en desarrollos internos, pero necesita ajustes posteriores para adaptarlo a la subcontratación de software.
Necesidad de expertos en evaluación de riesgos para identificar y manejar los fuertes riesgos del proyecto.

“POSIBLES” PREGUNTAS CAPÍTULO III

1. Indicar la(s) respuesta(s) correcta(s). El Ciclo de Vida:

Comienza con una idea o necesidad que satisfacer y acaba con las pruebas satisfactorias del producto.
No existe ningún estándar que describa sus procesos y actividades.
No es sólo realizar el análisis, diseño, codificación y pruebas; también incluye entre otros, procesos de soporte.
El Mantenimiento son las actividades para mantener sin cambios el sistema.
En la actividad de Análsis de los Requisitos del Software, los desarrolladores obtienen de los futuros usuarios los requisitos que piden al sistema.

En exámenes anteriores…

El Ciclo de Vida del software:

Es un marco de referncia común para las personas que participan en el desarrollo informático.
Se definen sólo los métodos a desarrollar.
Empieza en el análisis y termina cuando ya no se utiliza el software.

Los procesos del Ciclo de Vida:

La norma de ISO al respecto agrupa los procesos en generales, de desarrollo y de la organización.
La norma de ISO al respecto agrupa los procesos principales en adquisición, suministro, desarrollo, explotación y mantenimiento.
La norma de ISO al respecto agrupa los procesos generales en adquisición, suministro, desarrollo, explotación y mantenimiento.

En cuanto a los modelos del Ciclo de Vida:

Las normas no fomentan ni especifican ningún modelo en concreto.
En el modelo en Cascada pueden desarrollarse fases en paralelo, de ahí su nombre.
El modelo incremental exige la necesidad de contar con expertos en evaluación de riesgos.

Los siguientes factores influyen a la hora de elegir un ciclo de vida:

La estreucturación del sistema, la familiaridad con la tecnología a usar.
La norma estándar que se use en el desarrollo.
Las prisas que tenga el cliente por tener en marcha la aplicación.

El Ciclo de Vida:

Empieza con una idea o necesidad de satisfacer y acaba con las pruebas satisfactorias del producto.
El mantenimiento lo constituyen las actividades para mantener sin cambios el S.I.
En la actividad de Análisis de los Requisitos Software, los desarrolladores obtienen de los futuros usuarios los requisitos que piden al sistema.

RESPUESTAS

1	2	3	4	5	6
c - e	a	b	a	a	c

Capítulo III: Ciclo de Vida del Software

Este ejercicio lo pasó Inma a principios de curso (puede que fuese la tercera semana, no tengo ganas ahora de comprobarlo). El caso es que consistía en, una vez leída la descripción de una actividad, indicar la fase o etapa del ciclo de vida con el que se correspondía.

26 cuestiones de las que sólo “acerté” 6 en su momento.

En su momento. También. Detalle bastante importante: estuvimos comprobando con los apuntes todo el tiempo, lo cual induce a pensar que tampoco debería aparecer una cuestión de este tipo en el examen. De todas formas, para seguir con la buena costumbre de no obviar nada, como este ejercicio `relativamente teórico' apareción en clase, he aquí su correspondiente réplica en el Breathe Proyect 0.2 .

E intentando no desviarnos, hacer mención a que varias de las “descripciones” Inma las trató como “definiciones propiamente dichas de las fases”. Éstas se indican convenientemente.

Por fin, sin más dilaciones:

Identificar la fase o etapa del ciclo de vida:

Organizar el equipo de personas que va a llevar a cabo el estudio de un SI, así como la elaboración de un calendario de ejecución.

Proponer una solución a corto plazo que tenga en cuenta las restricciones económicas, técnicas, legales y operativas.

Determinar qué usuarios participan en la obtención de requisitos.

Elaborar un modelo de datos.

Identificar servidores, monitores, impresoras que formarán parte del equipo de un SI.

Especificar infraestructura tecnológica necesaria para soportar un SI.

Determinar la formación necesaria para el personal encargado de la implantación de un SI.

Comprobar el funcionamiento correcto de un SI en su entrono operativo.

Estudiar qué parte de un SI se ve afectada cuando realizamos una modificación concreta.

Elaborar un modelo de SI válido que soporte a los procesos de la organización.

Recogida de requisitos que debe cumplir un software para identificar funcionalidades.

Identificar objetivos estratégicos a los que apoya un SI, así como el ámbito general de la organización a la que afectará.

Especificar los niveles de servicio que se prestarán una vez implantado el SI.

Recogida y análisis de los antecedentes generales que puedan afectar a los procesos y unidades organizativas implicadas en un SI.

Proponer diversas alternativas que respondan a los requisitos planteados para un SI.

Posibilidad de efectuar un pago tanto en metálico como en efectivo.

Especificar los requisitos de implantación de un SI relacionados con la formación, infraestructura e instalación.

Estudio del SI actual.

Identificar los factores críticos para el éxito de un SI, así como sus participantes nombrando máximos responsables.

Generar un diagnóstico estimando la eficiencia de los existentes SI identificando posibles problemas y mejoras.

Definir los formatos de pantalla, diálogos e informes.

Diseñar un modelo físico de datos.

Codificar los componentes de un SI a partir de las especificaciones del diseño.

Verificar los recursos necesarios disponibles para realizar la instalación de todos los componentes de un SI.

Definir qué compromisos se adquieren con la entrega del SI.

Creación y puesta a punto de Base de Dato.

SOLUCIONES
1	Proceso de Adquisición.
2	Proceso de Suministro.
3	Proceso de Desarrollo - Análisis de Requisitos del Sistema.
4	Proceso de Desarrollo - Análisis de Requisitos del Software.
5	Proceso de Desarrollo - Diseño de la Aquitectura del Sistema.
6	Proceso de Desarrollo - Diseño de la Arquitectura del Software.
7	Proceso de Explotación.
8	Proceso de Explotación.
9	Proceso de Mantenimiento.
10	Proceso de Adquisición.
11	Proceso de Desarrollo - Análisis de Requisitos del Sistema.
12	Proceso de Adquisición.
13	Proceso de Suministro.
14	Proceso de Adquisición.
15	Proceso de Suministro.
16	Proceso de Desarrollo - Análisis de Requisitos del Sistema.
17	Proceso de Desarrollo - Diseño de la Arquitectura del Software.
18	Proceso de Adquisición ( Definición ).
19	Proceso de Adquisición.
20	Proceso de Suministro ( Definición ).
21	Proceso de Desarrollo - Análisis de Requisitos del Software.
22	Proceso de Desarrollo - Diseño Detallado del Software.
23	Proceso de Desarrollo - Codificación y Prueba del Sofware.
24	Proceso de Explotación.
25	Proceso de Suministro.
26	Proceso de Explotación.

CAPITULO IV : METODOLOGÍAS DE DESARROLLO DE SOFTWARE

Conceptos generales.
Evolución histórica.
Características.
Clasificación.
Principales metodologías.

CONCEPTOS GENERALES

Origen.
Definiciones.
Distinciones.
Especificaciones.
Necesidades a cubrir.
Objetivos.
Anexo 0.

APARICIÓN DE LAS METODOLOGÍAS

Las metodologías surgen de la necesidad de unas determinadas reglas fijas a las que ceñirse a la hora de desarrollar un software.

DEFINICIONES

“Metodología”: conjunto de pasos y procedimientos para el desarrollo de software.
“Metodología”: camino para desarrollar software de manera sistemática.

DISTINCIONES

Ciclo de Vida: indica QUÉ productos obtengo.
Metodología: indica CÓMO obtengo los productos.

Método: se aplica a cada fase del ciclo de vida.
Metodología: conjunto de métodos que se aplican durante todo el ciclo de vida.

ESPECIFICACIONES DE UNA METODOLOGÍA

Una metodología ha de indicar:

Cómo se debe dividir un proyecto en etapas.
Qué tareas se llevan a cabo en cada etapa.
Qué salidas se producen y cuándo se deben producir.
Qué restricciones se aplican.
Qué herramientas se van a utilizar.
Cómo se gestiona y controla un proyecto.

NECESIDADES A CUBRIR CON UNA METODOLOGÍA

- Mejores aplicaciones: (considerando mejores sistemas los de mejor calidad).

- Mejor proceso de desarrollo: identificar las salidas de las fases para planificar y controlar el proyecto. Así los sistemas se desarrollan más rápidamente y con los recursos apropiados.

- Proceso estándar en la organización: (aporta claros beneficios).

OBJETIVOS DE LAS METODOLOGÍAS

Registrar los requisitos del S.I de forma adecuada.
Proporcionar un método sistemático de desarrollo para controlar su progreso.
Construir un S.I. en el tiempo adecuado y con unos costes aceptables.
Construir un sistema bien documentado y fácil de mantener.
Ayudar a identificar lo más pronto posible cualquier cambio posible en el proceso de desarrollo.
Proporcionar un sistema que satisfaga a todas las personas afectadas por el mismo.

PROCEDIMIENTOS, TÉCNICAS Y HERRAMIENTAS

Procedimiento: “define la forma de ejecutar una tarea. El resultado de aplicar un procedimiento es un producto”.
Técnica: “se usa para aplcar un procedimiento”.
Herramienta: “se usa para aplicar una técnica”.

EVOLUCIÓN HISTÓRICA

Convencional.
Estructurado.
Orientado a Objetos.

ENFOQUE-DESARROLLO CONVENCIONAL

Características.
Problemas.

Caracteríticas:

Sin metodologías de desarrollo.
Distintos papeles: analistas, programadores (funcionales y orgánicos) y operadores.

Problemas:

Los resultados finales son impredecibles (no se sabe cuándo puede acabar realmente el proyecto).
No hay forma de controlar lo que está sucediendo en el proyecto (por no existir fases establecidas y productos intermedios concretos).
Los cambios organizativos afectan negativamente al proceso de desarrollo (por no existir documentos extandarizados o porque no se actualizan adecuadamente).

ENFOQUE-DESARROLLO ESTRUCTURADO

Conceptos.
Programación estructurada.
Diseño estructurado.
Análisis estructurado.

Conceptos:

Se puede considerar el nacimiento de las técnicas estructuradas como el origen de los desarrollos automatizados.
El origen del desarrollo estructurado comenzó con la programación estructurada.

Programación estructurada:

Se pretendió que la visión de un programa fuese lo más comprensible posible.
Normas para la aplicación de las estructuras de datos y control.

Diseño estructurado:

Se utiliza el módulo de programa como componente básico de construcción.
Se refina el concepto de modularidad (normalizando la estructura de un módulo de programa, restringiendo las relaciones entre módulos y estableciendo medidas en la calidad de los programas).

Análisis estructurado:

Conceptos.
Diferencias respecto al análisis clásico.
Evolución.

Conceptos:

Se conoce también como “análisis descendente” o “top-down”.
Se utilizaba principalmente en organizaciones de desarrollo de sistemas de gestión.

Diferencias respecto al anális clásico:

Analisis Clásico:

Se hacía una especificación narrativa de los requisitos, tal como los percibía el analista.
Las especificaciones contaban con el problema de ser monolíticas, redundantes, ambiguas e imposibles de mantener.

Analisis Estructurado:

Movimiento gradual a las especificaciones funcionales.
Las especifiaciones funcionales se caracterizaban por ser: gráficas, particionadas y mínimamente redundantes.

Evolución respecto al análisis estructurado clásico:

Dar menor importancia a la construcción de los modelos físicos actuales y modelos lógicos actuales.
Diferenciar más los modelos físicos y lógicos.
Ampliar las técnicas de análisis estructurado para poder modelar sistemas de tiempo real.
Enfocarse en el modelo de datos.
Estudio de los eventos.

ENFOQUE-DESARROLLO ORIENTADO AL OBJETO (No se estudia)

CARACTERÍSTICAS PRINCIPALES DE LAS METODOLOGÍA

Impacto.
Características deseables.

INMPACTO DE LA METODOLOGÍA EN EL ENTORNO DE DESARROLLO

La metodología proporciona CALIDAD y PRODUCTIVIDAD en el desarrollo de software.
La metodología está influenciada por consideraciones como el tamaño y la estructura de la organización o el tipo de aplicaciones que se va a desarrollar.

CARACTERÍSTICAS DESEABLES DE UNA METODOLOGÍA

- Existencia de reglas predefinidas: indicar reglas que definan las fases, tareas, productis intermedios, etc.

- Cobertura total del ciclo de desarrollo: indicar los pasos a seguir desde el planteamiento hasrta el mantenimiento (proporcionando mecanismos para integrar los resultados en la fase siguiente).

- Verificaciones intermedias: contemplar la realización de verificaciones sobre los productos generados en cada fase para comprobar su corrección.

- Planificación y control: para proporcionar una forma de desarrollar software planificada y controlada, con objeto de que no se disparen costes ni se amplíen los tiempos de entrega.

- Comunicación efectiva: para facilitar el trabajo en grupo y con los usuarios.

- Utilización sobre un abanico amplio de proyectos: la metodología ha de ser flexible para poder cubrir diverrsos proyectos.

- Fácil formación: los desarrolladores deben comprender las técnicas y procedimientos de gestión.

- Herramientas CASE: debe ser soportada por herramientas automatizadasa.

- Contener actividades que mejoren el proceso de desarrollo: se hace necesario conocer los resultados para hacer mediciones en cada etapa.

- Soporte al mantenimiento: para facilitar las modificaciones en sistemas existentes.

- Soporte a la reutilización del software: incluir procedimientos para la creación, mantenimiento y recuperación de los componentes reutilizables (y no sólo del código).

CLASIFICACIÓN DE LAS METODOLOGÍAS

Metodologías Estructuradas.
Sistemas de Tiempo Real.

METODOLOGÍAS ESTRUCTURADAS

Orientadas a procesos.
Orientadas a datos.
Mixtas.

Metodologías Orientadas a procesos:

Conceptos.
Componentes de una especificación estructurada.
Principales metodologías.

Conceptos:

Están basadas en un método descendente (Top-down) de descomposición funcional, para describir los requisitos del sistema.
Se apoyan en técnicas gráficas, dando lugar a un nuevo concepto que es la especificación estructurada.

Componentes de una especificación estructurada:
Diagramas de Flujo de Datos (DFD).
Diccionario de Datos.
Especificaciones de proceso.

Principales metodologías estructuradas:
Metodología de De Marco.
Metodología de Gane y Sarson.
Metodología de Yourdon/Constantine.

Metodologías Orientadas a datos:

Orientadas a datos jerárquicos.
Orientadas a datos no jerárquicos.

Metodologías Orientadas a datos jerárquicos:

Estudia las entradas y salidas para averiguar qué procesos genera.
La estructura de control del programa debe ser jerárquica y se debe derivar de la estructura de datos del programa.
En el proceso de diseño: 1. Se definen las estructuras de los datos de entrada y salida, 2. se mezclan todas en una estructura jerárquica de programa, 3. se ordena detalladamente la lógica procedimental para que se ajuste a esa estructura.
El diseño lógico debe preceder y estar separado del físico.

Metodologías Orientadas a datos NO jerárquicos:

Se considera a los datos como el “núcleo” del SI.
Con este enfoque, todos los sistemas construídos están integrados sobre un mismo modelo de datos.

Metodologías Mixtas:

No se referencian en el libro.

SISTEMAS DE TIEMPO REAL

Conceptos.
Características.
Requisitos.

Conceptos:

Son sistemas muy dependientes del tiempo.
Procesan información más orientada al control que a los datos.
Son controlados por eventos externos.
Hay que distinguir entre “sistemas en tiempo real” y “sistemas en línea”. Los sistemas interactivos (en línea) interactúan con personas mientras que los sistemas en tiempo real interactúan con personas y dispositivos físicos externos.

Características:

Se lleva a cabo el proceso de muchas actividades simultáneamente (“concurrencia”).
Se asignan prioridades a determinados procesos.
Se interrumpe una tarea antes de que concluya para comenzar otra de mayor prioridad.
Existe comunicación entre tareas (resultado tarea nueva tarea).
Acceso simultáneo a datos comunes (en memoria y en almacenamiento secundario).

Requisitos:

Manejo de inetrrupciones.
Comunicación y sincronización entre tareas.
Gestionar procesos concurrentes.
Dar respuesta oportuna y `a tiempo' ante eventos externos.
Datos continuos o discretos.

PRINCIPALES METODOLOGÍAS DE DESARROLLO

MERISE.
SSADM.
MÉTRICA.

METODOLOGÍA MERISE

Francesa
Ciclo de vida más largo que los existentes anteriormente.
Introducción de dos ciclos complementarios: de abstracción y de decisión.

METODOLOGÍA SSADM

Inglesa.
Énfasis en los usurios: sus requisitos y su participación.
Definición del proceso de producción: qué hacer, cuándo y cómo.
Tres puntos de vista: datos, eventos y procesos.
Máxima flexibilidad en herramientas y técnicas de implementación.
NO cubre aspectos como la planificación estratégica ni la construcción de código.

METODOLOGÍA MÉTRICA

Española.
Objetivo: crear un marco metodológico común para la palnificación y desarrollo de la Administración Pública Española.
Se enfoca directamente al desarrollo.

El libro hace referencia a la versión 2.0 de MÉTRICA, por tanto es absolutamente improbable que Inma pregunte algo de lo que en éste se describe (exceptuando cualquier cuestión relativa los tres puntos anteriores). Así que… FIN!

“POSIBLES” PREGUNTAS CAPÍTULO III

1. El análisis estructurado se diferencia del clásico en:

Emplear un método de particionamiento efectivo.
Construir un modelo lógico del sistema.
Definir los procesos.
Definir las líneas de diseño.

2. En el análisis estructurado:

El texto se introduce en todos los detalle inmediatamente.
Se va de lo abstracto al detalle, es gráfico y unidimensional.
Se usa un método para particionar exclusivamente problemas complejos.
Ninguna de las anteriores.

3. Una metodología es un conjunto de componentes que especifican:

Cómo se debe dividir un proyecto en etapas y las tareas de cada etapa.
Qué estándares se van a utilizar en el desarrollo.
El modelo de ciclo de vida a utilizar.

RESPUESTAS

1	2	3
a	d	a

CAPITULO V : GESTIÓN DE PROYECTOS SOFTWARE

Definición de proyecto.
Planificación.

PLANIFICACIÓN - CONCEPTOS GENERALES

Plan de Proyecto.
Gestión de Compromisos.

Conceptos.
Características del Plan de Proyecto.
Elementos del proyecto.

CONCEPTOS GENERALES

Consiste en el “estudio de etapas, actividades y tareas necesarias para alcanzar un objetivo que implica un trabajo no inmediato a un plazo relativamente largo”
La Gestión de Proyectos aborda distintos aspectos: planificación, control, dirección y organización.
El director de proyecto debe planificar, controlar y dirigir las actividades del proyecto.
Las unidades organizativas se encargan de organizar las actividades del proyecto.
La Planificación de proyectos ha de cubrir: la realización de un plan de proyecto (por parte del director de proyecto) y, la gestión de compromisos.
La función principal del director de proyecto es la realización del plan de proyecto.

CARÁCTERÍSTICAS DEL PLAN DE PROYECTO

Proporcionar un resumen del proyecto a altos directivos.
Permitir que el director del proyecto y los clientes puedan supervisar el progreso del proyecto desde el inicio hasta el final.
Debe ser un documento orientado al cliente.
Debe ser un documento base que cuente con la aprobación del cliente y además sea actualizable.

ELEMENTOS ESENCIALES DEL PROYECTO

Resumen del proyecto. Comprendido por cualquier persona. Que indique los productos entregables.
Lista de hitos alcanzables.
Procedimientos y estándares a aplicar.
Especificación del proceso de revisión para determinar `quién', `cómo', `cúando' y `para qué' se revisa el proyecto.
Plan que defina la comunicación entre la organización de desarrollo y el cliente.
Diagrama de descomposición del trabajo (WBS).
Lista del personal del proyecto y asignación en relación al WBS.
Red de actividades que muestre la secuencia de activiades en el tiempo y las relaciones entre actividades.
Presupuestos y calendarios para todas las actividades que tienen un responsable.

PLANIFICACIÓN - ACTIVIDADES PARA LA PLANIFICACIÓN DE UN PROYECTO

Plan de desarrollo.
Características de un Programa de Tiempos efectivo.
Pasos para la realización de un calendario.

PLAN DE DESARROLLO

El objetivo principal del plan de desarrollo es la configuración del calendario de proyecto (o “programa de tiempos”).

El calendario de proyecto consiste en una representación gráfica de todas las actividades del proyecto, necesarias para el resulado final.
El calendario permite al director de proyecto coordinar de forma efectiva al equipo de desarrollo.
Un calendario debe ser `dinámico' (que pueda variar).

CARÁCTERÍSTICAS DE UN PROGRAMA DE TIEMPOS

Comprensible por las personas que van a utilizarlo.
Suficientemente detallado para que pueda servir de base para medir y controlar el progreso del proyecto.
Capaz de señalar actividades críticas.
Flexible (`fácilmente modificable').
Basados en estimaciones de tiempo fidedignas.
Ajustable a recursos disponibles.
Compatible con los planes de otros proyectos que compartan los mismos recursos.

PASOS PARA LA REALIZACIÓN DE UN CALENDARIO

1. Definición de los objetivos del proyecto:

Objetivo del proyecto: “enunciado que especifica los resultados que se desean conseguir”.
Los objetivos deben definirse al comienzo para identificar responsbilidades del equipo de desarrollo y se revisarán durante el poyecto para señalar los cambios que se aparten del alcance inicial. Esto ayudará al director de proyecto a revisar los resultados finales respecto a los objetivos iniciales.

…Para que el objetivo quede bien definido tiene que ser:

Asequible:
Definitivo: especificar `qué lograr' y `con qué grado de detalle'.
Cuantificable: especificar el criterio de finalización.
De duración específica: especificar la duración de las actividades.

2. Descomposición de las actividades:

Para que el director de proyecto pueda:

Aumentar la supervisión de trabajos.
Observar el seguimiento de actividades críticas de gran repercusión.

3. Relación entre las actividades:

Deben determinarse las secuencias y dependencias entre las actividades.

4. Estimación de tiempos y costes de las actividades:

5. Reajuste del programa de tiempos a las restricciones del proyecto:

Objetivos principales:

Determinar la duración total del proyecto.
Identificar las activiades que contribuyen a la duración total del proyecto (“actividades críticas”).
Calcular las holguras de las actividades NO críticas.

Excepto en proyectos muy sencillos, se hace necesario el uso de herramientas automatizadas que realicen el análisis de los tiempos de red y la distribución de los recursos pertinenentes.

6. Asignación de recursos / Definición de la organización del equipo:

Objetivos principales:

Ajustar el calendario respecto a los recursos disponibles.
Ajustar las fechas de comienzo de algunas actividades NO mcríticas.
Suavizar las cargas de trabajo.
Ajustar costes al presupuesto.

7. Revisión del calendario:

Para determinar si es o no realista.

PLANIFICACIÓN - GESTIÓN DE COMPROMISOS

Es importante que los directivos tomen las decisiones y adopten los compromisos despues de que el grupo de software haya emitido sus opiniones sobre si los compromisos se consideran o no factibles.
Si los directivos se deciden a adoptar un compromiso poco factible, deben estar preparados para un posible aumento de los costes o un retraso en la fecha de entrega.

PLANIFICACIÓN - TÉCNICAS PARA LA REALIZACÓN DE UN CALENDARIO

Diagrmas de Hitos.
Diagramas de Gantt.
Programas de tiempos Full Wall.
Redes de precedencia.

Pert.
CPM.

DIAGRAMAS DE HITOS

Actividad

Fecha finalización

Es el método más simple para la realización de un calendario.
Consiste en un cuadro con dos columnas: en la primera se especifican las actividades y en la segunda las fechas de finalización.
Ventajas:

Facilidad de uso.
Mínimo coste de preparación.

Desventajas:

Incertidumbre sobre las fechas de comienzo de las actividades.
Imposibilidad de reflejar interrelaciones entre actividades.

DIAGRAMAS DE GANTT

Tarea1

Tarea2

Tarea3

Tarea4

Tarea5

Tarea6

Tarea7

Se usa normalmente para proyectos pequeños (menos de 25 actividades).
Es posiblemente el tipo de calendario más utilizado.
No es posible representar dependencias entre actividades.
Hace más sencillo representar el solapamiento entre actividades.
Consiste en un diagrama de barras donde se hace una referencia cruzada entre las tareas (“filas”) y su tiempo de duración (“columnas”).

PROGRAMA DE TIEMPOS FULL WALL

Parte de una reunión donde intervienen todas personas involucradas en el proyecto.

El director de proyecto desarrolla un diagrama de hitos y una lista de actividades donde se indica los responsables de cada una.
Cada actividad se escribe en dos tarjetas (“inicio” y “final”).
Cada persona clava la tarjeta en la pared en la semana de su elección.

Alto grado de interacción entre los participantes de la reunión.
No muestra claridad en los camminos críticos.

REDES DE PRECENCIA: PERT Y CPM

Conceptos generales.
Casos en los que es conveniente su utilización.
Diferencias.
Reglas.
Holguras de los diagramas PERT.

Conceptos generales:

Red: “modelo gráfico que señala las relaciones secuenciales entre los sucesos clave del proyecto”.

PERT y CPM pueden mostrar el camino crítico (“secuencia más larga de las actividades conectadas a travñes de la red, y que determina la duración total del proyecto”).
Para disminuir el tiempo total deben reducirse los tiempos de las actividades dentro del camino crítico.

Conviene utilizar las Redes de Precedencia cuando un proyecto:

Todas las actividades están bien definidas.
Las actividades se puedan comenzar, interrumpir y realizar de forma separada respecto a la secuencia dada.
Las actividades se puedan relacionar unas con otras.
Las actividades estén ordenadas (de modo que se pueda seguir una secuencia).
Una vez comenzada una actividad, debe continuar sin interrupción hasta su finalización.

Principales diferencias entre PERT y CPM:

CPM se centra en las actividades y PERT en los eventos o sucesos. Esto da la ventaja a PERT, por considerar los eventos como los `hitos del proyecto', lo que favorece el control de la gestión.
PERT permite el tratamiento de la probabilidad para la estimación de tiempos. CPM no.

Reglas en el desarrollo de PERT y CPM:

Como mínimo, la red debe poseer 20 eventos
Las redes realizadas manualmente deben contar con un máximo de 300 sucesos.
Los proyectos que justifican un gran número de actividades o eventos poseen las siguientes características:

Muy críticos.
Poseen un alto riesgo o incertidumbre.
Involucran a muchas personas u organizaciones.
Técnicamente complejos.
Con actividad en diversas localidades geográficas.

Holguras de los diagramas PERT:

Holgura	Número de unidades de tiempo que un suceso puede retrasar su finalización SIN aumentar la duración total del proyecto.	Hi = TLi - TEi
Holgura total	Número de unidades de tiempo que la realización de una actividad puede retrasar su finalización, respecto al tiempo PERT previsto, sin aumantar la duración total del proyecto.	HTij = TLj - TEi - Tij
Holgura libre	Parte de la holgura total que puede consumirse sin afectar a las actividades siguientes.	HLij = TEj - TEi - Tij
Holgura independiente	Cantidad de holgura disponible si todas las actividades han comenzado en sus `tiempos last'.	HIij = TEj - TLi - Tij

MÉTODOS DE ESTIMACIÓN DE COSTES

Todos los metodos de estimación de costes dependen de la información.
Los métodos están infuídos por el tiempo y el sueldo del trabajador.

DINERO

(coste del proyecto)

estimado por

SALARIOS DE LOS TRABAJADORES

Opinión de expertos.
Estimación por analogía.
Descomposición.
Ecuaciones o modelos de estimación.
Recomendaciones.

OPINIÓN DE EXPERTOS

Características.
Técnicas.

Características:

Muy subjetiva.
Permite contemplar simultáneamente distintos proyectos anteriores junto con el actual.

Técnicas para sintetizar la Opinión de Expertos:

Pasos:

Los expertos ofrecen su punto de vista.
Se realiza la media de las valoraciones.
Se organiza una reunión con el propósito de llegar a un consenso.

“Delphi”: variante que consiste en calcular la media de las valoraciones de `expertos anónimos'. La media es devuelta a cada uno de ellos. A continuación, se vuelve a opinar sobre la media hasta lograr un consenso.

ESTIMACIÓN POR ANALOGÍA

Consiste en tomar un proyecto similar para que sirva de base.
Se basa en una `experiencia real'.
Cosntituye un complemento a la opinión de expertos.
Es difícil conocer el grado de similitud con el sistema a comparar.
El tamaño del tiempo y el coste del proyecto NO guardan una ecuación lineal (por lo cual no pueden calcularse mediante la estimacion por analogía).

DESCOMPOSICIÓN

Se divide el proyecto en etapas y se estima el coste de cada una de ellas.
Sigue un enfoque Botton-Up (abajo-arriba).
La estimación es personal del responsable de cada componente. Esto la hace más fiable.
No contempla las nuevas actividades que se puedan precisar.

ECUACIONES O MODELOS DE ESTIMACIÓN

Consiste en lograr las estimaciones mediante fórmulas matemáticas.
Modelos de coste: estimaciones directas del esfuerzo o de la duración. Suelen ser X = CTE * Y.
Modelos de restricciones: relacionan en el tiempo dos o más parámetros de coste.

ENFOQUE RECOMENDADO

Realizar un juicio de expertos mediante Delphi en la negociación de contratos.
Valorar la similitud con proyectos anteriores.
Crear un modelo propio.
Refinar a medida que se avanza en el desarrollo.

TEORÍA RESTANTE

Siguiendo el libro, nos encontramos con otra posible clasificación de los modelos de estimación:

Modelos empíricos: basados en la opinión de expertos y la estimación tanto Top-Down como Botton-Up, apoyada en datos históricos.
Modelos estadísticos (lineales y no lienales): obtenidos mediante el análisis de regresión estadística.
Basados en una teoría: sobre el esfuerzo de desarrollar software (y comprobaciones de datos) (P ej: SLIM).
Modelos compuestos: combinan varias técnicas (P ej: COCOMO).

Sigue la explicación de cómo realizar los modelos SLIM y COCOMO.
Hasta el final del capítulo, otros puntos a tener en cuenta son:

El enfoque recomendado para la estimación de costes (4 puntos).
Los objetivos que pretende conseguir el seguimiento y la supervisión del proyecto (3 puntos).
Las áreas de riesgo quedebe tratar un director de proyecto en la gestión de riesgos del software (7 puntos).

…Inma apenas ha incidido en estos puntos, pero como vienen en el libro, aviso de que están ahí por si acaso. Si nos sobra tiempo y tenemos ganas, nos los miramos también.

“POSIBLES” PREGUNTAS CAPÍTULO V

1. La Gestión de Proyectos Software:

Estudio de etapas, actividades y tareas necesarias para alcanzar un objetivo que implica un trabajo no inmediato a un plazo relativamente largo, según distintos aspectos como Planificación, Control, Dirección y Organización.
Conjunto de personas, entre ellas el jefe de proyecto y desarrolladores que trabajan para obtener un producto software.
Planificación del desarrollo del software en cuanto a funciones que debe realizar.

La Planificación de un Proyecto Software incluye dos aspectos importantes:

Plan de Proyecto y Gestión de Compromisos.
Plan de Proyecto y Calendario.
Calendario y Descomposición de Trabajos del Proyecto (WBS)

Son técnicas para realizar un calendario:

Redes de Precedencia.
Diagramas de Gantt y Diagramas de Hitos.
Todas son correctas.

Las técnicas de construcción de calendario que no muestran las interrelaciones entre las distintas actividades:

Redes de Precedencia.
Diagramas de Gantt y Diagramas de Hitos.
Todas son correctas.
La Gestión de Compromisos:

Los directivos deben tomar decisiones una vez emitida la opinión del grupo de software.
Forma parte de la Estimación de Costes.
Todas son correctas.
Los métodos de Estimación de Coste:

Opinión de Expertos, Estimación por Analogía y Descomposición.
Ecuaciones o Modelos de Estimación.
Todas son correctas.
La primera versión del Plan de proyecto incluye:

Qué, Cómo, Quién y Cuándo se hace.
Herramientas y Técnicas de Gestión y de Desarrollo.
Todas son correctas.

RESPUESTAS

1	2	3	4	5	6	7
a	a	c	b	a	c	c

CAPITULO VI : ANÁLISIS DE NECESIDADES Y ESTUDIO DE VIABILIDAD

CÓMO COMIENZA UN PROYECTO

Inicio a nivel de empresa.
Inicio a nivel de proyecto.

INICIO A NIVEL DE EMPRESA

Es el precedente necesario del inicio a nivel de proyecto.
Elementos principales:

Decisión de emprender el proyecto.
Selección del jefe de proyecto (responsable de establecer el entorno inicial de trabajo).

Decisión de emprender el proyecto:

Orígnes de la idea de emprender un proyecto.
Conceptos.
Análisis de Viabilidad.

Orígenes de la idea de emprender un proyecto:

En el caso de un departamento de desarrollo de la empresa:

La constatación de los requisitos del software está cambiando.
Petición específica del cliente o usuario.
Propuesta desde dentro de la propia organización de desarrollo.
Necesidad detectada por el departamento de marketing.
Recomendación específica del presonal de mantenimiento.
Detectada a partir de la información de los usuarios.

Primero se debe obtener una idea clara de lo que se pretende hacer, para después evaluar la viabilidad del proyecto.

En el caso de una empresa de servicios informáticos:

Respuesta a una demanda del cliente.

Conceptos generales:

Es necesario definir y analizar los requisitos del sistema que se debe construir.
Para lograr mejores resultados se debe obtener de los usuarios, información sobre las necesidades que desean que el software satisfaga.
Los resultados de estudios previos se indican en un documento llamado “informe de necesidades”.

Consideraciones para analizar la viabilidad del proyecto:

Considerar diferentes alternativas que se puedan concebir (comprar un software comercial ya creado, desarollar el producto internamente…).
Evaluación de cada alternativa.
Especificación detallada de la alternativa desarrollada.
Establecimiento de fechas y compormisos de trabajo por parte de las personas y los departamentos implicados (`definición de un plan alternativo para el proyecto').

Selección del director del proyecto:

Conceptos.
Características.

Conceptos generales:

Normalmente, la elección del director de proyecto es posterior la decisión de emprender el proyecto.
Seguramente sea el elemento más crítico de cara a conseguir el éxito del proyecto.

Carácterísticas deseables en un director de proyecto:

Liderazgo: habilidad para motivar a los componentes del equipo de proyecto.
Comprensión técnica: conocimientos para tomar las decisiones correctas.
Competencia en la gestión: capacidad para controlar las activiades, costes y presupuestos del proyecto.
Presteza y decisión: para observar, evaluar y decidir.
Versatilidad y flexibilidad: para encauzar acontecimientos imprevistos.
Integridad: para reclutar al personal más adecuado y ganarse la confianza del cliente.
Previsión: para anticiparse al problema y aportar soluciones.

INICIO A NIVEL DE PROYECTO

Establecer el entorno inicial de trabajo del proyecto (por parte del director de proyecto).
Definir el soporte necesario para el equipo de proyecto.
Definir las técnicas de comunicación entre miembros.
Definir los requisitos que deben cumplir los posibles subcontratistas.
Definir la manera de aboradar la interacción con el cliente.

ESTUDIOS DE VIABILIDAD

Aspectos a abordar.
Análisis Coste-Beneficio.
Aspectos para análisis coste-beneficio eficaz.

ASPECTOS A ABORDAR EN EL ESTUDIO DE VIABILIDAD

Económico: si el beneficio compensa los costes.
Técnico: si la funcionalidad, el rendimiento o las restricciones son razonables.
Legal: si los requisitos atentan contra alguna ley o reglamento.
Operativo: si se puede implantar de forma efectiva en la empresa.

Se debe prestar especial atención al análisis económico. Sus conclusiones son determinantes para continuar o cancelar el proyecto.

ANÁLISIS COSTE-BENEFICIO

Costes.
Beneficios.
Conceptos.

Costes a tener en cuenta:

Coste del personal informático implicado en el proyecto (desde el análisis hasta la instalación del sistema).
Coste de consultoría.
Coste de software adicional.
Coste de hardware.
Coste de infraestructura.
Costes debidos al usuario.
Costes contínuos: mantenimiento del sistema y alquileres.

Beneficios:

Nuevas funcionalidades.
Eliminación de errores.
Reducción de errores.
Aumento de la velocidad.
Aumento de la fiabilidad.

Conceptos:

Uno de los mayores problemas del análisis económico es que ha de ser realista.
En la mayoría de los casos la valoración de beneficios es necesariamente subjetiva.

ASPECTOS IMPORTANTES PARA QUE EL ANÁLISIS COSTE-BENEFICIO SEA EFICAZ

La mayoría de las estimaciones de costes y beneficios deben consistir en rangos de valores probables.
Es recomendable emplear estimaciones pesimistas o conservadoras.
Se debe contar con factores que influyen en toda prospectiva económica.
Tratar de valorar y prever todos los riesgo.

TÉCNICAS DE RECOGIDA DE INFORMACIÓN

“Medio para mejorar la comunicación entre los usuarios o clientes y los desarrolladores de software”.

Pasos del proceso de Análisis.
Técnicas de recogida de información.
Entrevistas.
JAD.
Prototipado.

PASOS DEL PROCESO DE ANÁLISIS

Identificar fuentes de información (usuarios) relevantes para el proyecto.
Realizar preguntas adecuadas para comprender las necesidades.
Analizar la información recogida para detectar aspectos que quedan poco claros.
Confirmar con los usuarios lo comprendido de los requisitos.
Sintetizar requisitos en un documento de especificación apropiado

El resultado del proceso debería ser un documento que especifique lo más claramente posible, los requisitos que debe cumplir el software.

TÉCNICAS PRINCIPALES DE RECOGIDA DE INFORMACIÓN

Entrevistas	Quiza la técnica más empleada y la que require mayor preparación por parte del analista.
Desarrollo conjunto de aplicaciones (JAD)	Se crean equipos de usuarios y analistas para determinar las características que debe tener el software. Cuenta con una mayor probabilidad de éxito, ya que involucra al usuario en el proyecto de modo que lo aprecia como `algo propio'.
Prototipado	Construcción de un modelo o maqueta del sistema que permite al usuario evaluar mejor las necesidades.
Observación	Analizar `in situ' cómo funciona la unidad o departamento que se desea informatizar.
Cuestionarios	Para recoger información de un gran número de personas en poco tiempo.
Estudio de documentación	Para hacerse una idea sobre la normativa que rige la empresa.
Tormenta de ideas	Reunión de 4 a 10 personas. Sugieren cualquier idea sin juzgar su validez. Realizan un análisis detallado de cada propuesta.
ETHICS	Para fomentar la perticipación de usuarios en varios proyectos. Objetivo: satisfación de los empleados en el trabajo, mediante estudios integrales.

Es una práctica habitual utilizar combinaciones de distintas técnicas.

LAS ENTREVISTAS

Conceptos.
Cualidades del entrevistador.

Preparación.
Realización.
Análisis.

Conceptos:

Entrevista: “intento sistemático de recoger información de otra persona”.
La preparación es esencial para cumplir sus objetivos.
Los elementos principales son: el entrevistador y el entrevistado.
Es muy importante la forma en que se plantea la conversación.

Cualidades del entrevistador:

Imparcial.
Ponderado.
Buen oyente: capaz de escuchar mostrando interés (muy importante).
Cierto grado de habilidad en el trato.
Cordialidad y accesibilidad.
Paciencia.

1. Preparación:

Fase en la que el entrevistador debe documentarse e investigar la situación de la organización.
Es esencial para que la entrevista sea eficaz.
La entrevista debe centrarse en aspectos del trabajo no accesibles por otros medios.
Otra actividad importante es la identificación de personas que se debe entrevistar (para minimizar el número necesario de personas a entrevistar).
Por último se debe incluír: la preparación del objetivo y el contenido de la entrevista y, la planificación del lugar y la hora donde se desarrollará la entrevista (el lugar ha de ser confortable y la fecha y hora deben adaptarse a la agenda del entrevistado).

2. Realización:

La realización se considera “el núcleo central de la entrevista”.
Se distinguen tres etapas: apertura, desarrollo y terminación.

Apertura.
Desarrollo.
Terminación.

Apertura:

El entrevistador se presenta e informa al entrevistado sobre la razón de la entrevista.
Los primeros minutos son fundamentales para crear un ambiente confortable.
La primera impresión en el entrevistado es muy importante.

Desarrollo:

No debería exceder de 2 horas.

Técnicas durante el desarrollo:

Preguntas abiertas en los primeros momentos para proseguir con otras más directas y cerradas.
Utilizar palabras y frases aropiadas (evitando tecnicismos o palabras o frases que puedan perturbar la comunicación).
Asentir mientras se escucha.
Repetir respuestas dadas (transmite la sensación de que el interlocutor atiende y entiende. Esre recurso debe utilizarse moderadamente).
Pausas, para ejercer presión y obligar al entrevistado a hablar.

Lo ideal es que el entrevistador hable un 20% del tiempo y el entrevistado un 80%..

Terminación:

Se finaliza recapitulando la entrevista, agradeciendo el esfuerzo al entrevistado y citándolo para una nueva entrevista si fuese necesario.
Es importante dejar abierta la posibilidad de volver a contactar.
Hay que convencer al entrevistado de que se le ha entendido.

3. Análisis:

Leer las notas, reorganizar la información, etc
Es importante evaluar cómo ha ido la entrevista así como los aspectos mejorables.

DESARROLLO CONJUNTO DE APLICACIONES (JAD)

Conceptos.
Razones base.
Proceso JAD.

Conceptos generales:

Su finalidad es promover la coperación y el trabajo en equipo entre los usuarios y los analistas.
Consisten en un conjuto de reuniones (2-4 días) en las que participan tanto usuarios cualificados como analistas de software.
JAD no se utiliza demasiado debido a que require una mayor preparación que las entrevistas y el ambiente o los métodos de trabajo convencionales en las empresas no facilitan este tipo de actividades.

Razones que sirven de base a JAD:

Las entrevistas requieren mucho tiempo. JAD precisa pocos días.
Es más difícil apreciar los posibles errores en la especificación de requisitos cuando sólo un analista revisa el documento. En el JAD todo el grupo puede actuar como revisor y detectar defectos.
JAD propugna una participàción más profunda de los usuarios en el proyecto.

Proceso típico JAD:

1. Adaptación o preparación

Tareas de preparación de sesión por parte del jefe del JAD:

Selección de participantes (conjunto lo más representativo posible).
Recabar cierta información sobre el sistema a construír.
Organizar la reunión.

2. Sesión JAD

Reuniones donde se parte de un documento de trabajo que hay que analizar para completar el conjunto de requisitos del sistema.
Al final de la sesión se habrá concluído el documento de especificación, aprobado por los presentes

3. Documentación

Completar el documento final de sesión.

EL PROTOTIPADO

Conceptos.
Casos en los que resulta útil.
Razones.
Herramientas.

Conceptos generales:

Consiste en la elaboración del modelo o maqueta del sistema para evaluar mejor los requisitos que se desea que cumpla el sistema.
Una cualidad esencial del prototipo es su posibilidad de ser construído más rápidamente que la aplicación.

Casos en los que resulta más útil:

Cuando el área de aplicación NO está bien definida.
El coste de rechazo de la aplicación por parte de los usuarios es muy alto.
Es necesario evaluar previamente el impacto del sistema en los usuarios y la organización.

Razones principales para utilizar el prototipado:

(Ordenadas por frecuencia de uso).

1. Prototipado de la interfaz de usuario:	Para asegurarse de que está bien diseñada y satisface las necesidades de los usuarios. No es caro. Muy frecuente. Usualmente consiste en simples modelos de pantallas.
2. Modelos de rendimiento:	Para evaluar el posible rendimiento del diseño.
3. Prototipado funcional:	Prototipo: “primera versión del sistema, con funcionalidad limitada”. Tras comprobar si las funciones implentadas son apropiadas, se corrigen, refinan y añaden nuevas hasta obtener el sistema final.

Herramientas para la realización del prototipado:

Nivel inferior herramientas comunes y facilmente disponibles (P ej: programas de dibujo o presentación, hojas de cálculo o generadores de informes. Con éstas se consigue que el usuario pueda ver la entrada/salida que se tendrá cuando la aplicación esté acabada.
Nivel un poco más evolucionado algunos gestores de bases de datos.
Otra opción posibilidades de prototipados que proporcionan las herramientas CASE o determinados generadores de aplicaciones.

“POSIBLES” PREGUNTAS CAPÍTULO VI

1. Un Estudio de Viabilidad debe abordar aspectos como:

Económico y Técnico.
Legal y Operativo.
Todas son correctas.

2. El encarrgado de establecer el entorno inicial de trabajo de un proyecto software:

Jefe de Proyecto.
Desarrolladores y usuarios.
Directivos.

3. El Informe de Necesidades incluye:

Resultados de Estudio Previo.
La Viabilidad del Proyecto.
Todas son correctas.

RESPUESTAS

1	2	3
c	a	a

CAPITULO VII : ANÁLISIS DE SISTEMAS

INTRODUCCIÓN AL ANÁLISIS DE REQUISITOS

Definiciones.
Clasificación de actividades.

DEFINICIONES

Análisis (aplicado a sistemas): “descomponer el sistema en sus componentes para estudiar cada uno de ellos”.
Análisis (aplicado a una fase del ciclo de vida): “producir un documento de especificación de requisitos que describa lo que el futuro sistema debe hacer (pero NO cómo debe hacerlo)”.
Análisis de Requisitos: “proceso del estudio de las necesidades de los usuarios para llegar a una definición de los requisitos del sistema de hardware o de software”. También: “Proceso y estudio de dichos requisitos”.
Requisito: “Condiciones que debe cumplir o poseer un sistema o uno de sus componentes para satisfacer un contrato, una norma o una especificación”.

Para obtener los requisitos se requiere del trabajo conjunto de: suministradores, desarrolladores, clientes y usuarios.

CLASIFICACIÓN DE LAS ACTIVIDADES DEL ANÁLISIS DE REQUISITOS

Según IEEE 1074.
Clasificación alternativa.

Según el estándar IEEE 1074

Definir los requisitos del software.
Definir los requisitos de las interfaces.
Integrar los requisitos (en un documento de especificación) y asignarle prioridades.

Otra clasificación (by RAGHAVAN)

Actividades	Técnicas que emplean
Extracción o determinación de requisitos:	Técnicas de recogida de información ( capítulo 6 ) ( Ej: observación, cuestionarios, entrevistas…)
Análisis de requisitos:	Técnicas gráficas. Modelos competos ( Ej: Análisis Estructurado )
Especificación de requisitos:	Técnicas gráficas. Modelos competos ( Ej: Análisis Estructurado )
Validación de requisitos:	Listas de comprobación. Técnicas de revisión.

Estas actividades NO tienen por qué realizarse en secuencia.

ESPECIFICACIÓN DE REQUISITOS DEL SOFTWARE

Definiciones.
Definiciones ERS.
Características principales.
Características generales.
Evolución.
Especificación de requisitos de interfaces.

DEFINICIONES

Especificación: “documento que define el diseño, el comportamiento u otras características de un sistema o componente de un sistema”.
Software: “conjunto de programas, procedimientos y documentación asociada a la operación de un sistema informático”.

DEFINICIONES DE ERS

Def 01: “documentación de los requisitos esenciales del software y de sus interfaces externas”.
Def 02: “documento en el que se integran los requisitos una vez superada su verificación y validación”.
Def 03: “descripción de `lo que hay que desarrollar', lo cual implica una descripción correcta de todos los requisitos del software (evitando requisitos innecesarios) y, NO describir ningún detalle del diseño de software (excepto las restricciones del diseño que influyen en los requisitos).

Una ERS debe especificar SOLAMENTE `lo que desea el usuario'.

CARACTERÍSTICAS FUNDAMENTALES DE UNA ERS

Información veraz: coherente con las necesidades reales de los usuarios.
Comunicada de forma eficaz: de modo que se pueda comprender perfectamente.

CARACTERÍSTICAS GENERALES PARA UNA BUENA ERS

No ambigua.
Completa.
Fácil de verificar.
Consistente.
Fácil de modificar.
Facilidad para identificar el origen y las consecuencias de cada requisito.
Facilidad de utilización en la fase de explotación y mantenimiento.

No ambigua:

Cada requisito ha de tener una única interpretación.

Completa:

Incluir todos los requisitos significativos del software.
Definir la respuesta del software a todas las posibles clases de datos de entrada y en todas las situaciones posibles.
Estar conforme con cualquier estándar de especificación a cumplir.
Las figuras, tablas y diagramas han de estar etiquetadas y referenciadas en el texto.

By Bruce: A continuación nos encontramos en el libro con la explicación de que existe un simpático recurso empleado en las ERS. Consistente en utilizar unas siglas: TBD (To Be Determined) que viene a significar “vamos, esto… ya lo haremos, tú tranquilo”, y que se añaden en las especificaciones cuando llegamos a un punto que aún no tenemos claro. Lógicamente nos cuenta que es un recurso `no demasiado elegante' y que cuando nos veamos obligados a usarlo, incluyamos también la forma en que pensamos solucionar la situación en un futuro para así deshacernos del TBD. … No creo que vaya a caer en el examen, es una estupidez, así que… mención hecha y… seguimos.

Fácil de verificar:

Cualquier requisito referenciado se pueda verificar fácilmente.

Consistente:

Ningún conjunto de requisitos han de ser contradictorios o entrar en conflicto.

Posibles conflictos:

Empleo de distintos términos para el mismo objeto.
Características de objetos reales entran en conflicto.
Conflicto lógico o temporal entre dos acciones determinadas

Fácil de modificar:

La estructura y el estilo deben permitir que cualquier cambio necesario en los requisitos se pueda realizar fácil, completa y consistentemente.

La ERS debe:

Tener una organización coherente y manejable (con tablas de contenidos, índices y refernecias cruzadas).
No ser redundante (el mismo requisito NO debe aparecer en más de un lugar de la ERS).

La “redundancia” NO equivale a “error”, pero puede conducir a errores.

Facilidad para identificar el origen y las consecuencias de cada requisito (facilidad de traza):

Establecer el origen claro para cada uno de los requisitos.
Posibilitar la referencia de los requisitos en desarrollos futuros o incrementos de la documentación.

Referencias recomendas:

Referencias hacia atrás: a documentos previos.
Referencias hacia delante: a documentos originados a partir del ERS.

Fácilidad de utilización en la fase de explotación y mantenimiento:

Causas.
Objetivos.

Causas:

El personal que NO ha estado relacionado con el desarrollo se encarga del mantenimiento.
Gran parte de los conocimientos y de la información se dan por supuestos, pero suelen estar ausentes.

Objetivos:

Ser fácilmente modificable.
Prever el registro de las características especiales de cada componente (su criticidad, su relación con las necesidades temporales y su origen).

EVOLUCIÓN DE LA ERS

Conceptos.
Causas.

Conceptos:

La ERS, normalmente, necesitará ser cambiada q medida que progresa el producto software.
Muy posiblemente se realizarán cambios adicionales como consecuencia de haber encontrado deficiencias.

Consideraciones a tener en cuenta en este proceso:

El requisito debe ser especificado de la forma más completa posible (aún en el caso de que se prevean revisiones en el proceso de desarrollo).
Debe iniciarse un proceso formal de cambio (para identificar, controlar, seguir e informar de cambios tan pronto como sean identificados).

ESPECIFICACIÓN DE REQUISITOS DE LAS INTERFACES

Interfaces con el exterior ≈ “Entradas y salidas (E/S) del sistema”.
La definición de las interfaces E/S tiene como objetivo la estabilización del modo en que el sistema va a interactuar con el exterior del sistema.
Debe contarse además de con lo que exprese el usuario, con criterios que le ayuden a decidir qué es lo mejor para su trabajo.
VISIÓN GENERAL DE LAS TÉCNICAS DE ESPECIFICACIÓN

Intro.
Según forma de representación.
Según enfoque de modelización.

INTRO

No hay un criterio definitivo (trivial) por el que se puedan organizar las técnicas.

CLASIFICACIÓN SEGÚN LA FORMA DE REPRESENTACIÓN

Gráficas.
Textuales.
Marcos o plantillas.
Matriciales.

Gráficas:

Utilizan una serie de iconos en el que cada uno representa un componente de un aspecto en particular del modelo.
Preferidas cuando es importante resaltar la conexión entre los distintos componentes.
Se suelen utilizar en combinación con las demás técnicas.

Textuales:

Emplea una gramática definida (más o menos formal).
Para especificar con más detalle los componentes definidos en los gráficos.
Ej: pseudocódigoempleado en las especificaciones de procesos.

Marcos o plantillas:

Se representan mediante un formulario en el que se incluyen todas las características del componente por medio de campos en el que cada entrada puede tener una gramática particular.
Especifican la información relativa a un componente de un modelo que ha sido declarado en un diagrama o en otro marco.

ENTIDAD: Estudiante.

DESCRIPCIÓN: Un estudiante es cualquier persona que está matriculada en una de las asignaturas ofertadas.

ATRIBUTOS: Nº DNI, apellidos, nombre, dirección provincia, teléfono.

IDENTIFICADORES: Nº DNI.

RESTRICCIONES:

VOL. MAX. OCURRENCIAS: 2000.

Ejemplo de plantilla de una entidad

Matriciales:

No se consideran técnicas de definición, sino de comprobación entre modelos.
Permiten estudiar referencias cruzadas entre los componentes de los modelos.

CLASIFICACIÓN SEGÚN EL ENFOQUE DE MODELIZACIÓN

Técnicas para analizar un sistema. Clasificación 1.

Atendiendo a las funciones: DFD.
Atendiendo a la información: MER (E/R).
Atendiendo al tiempo: Lista de eventos.

Técnicas para analizar un sistema. Clasificación 2: según perspectivas.

Plano Información-Función: DFD.
Plano Función-Tiempo: Redes de Petri.
Plano Información-Tiempo: Diagrama de Historia de Vida de la Entidad.

MODELIZACIÓN DE FUNCIONES

By Bruce 2: Este apartado se corresponde en su mayoría a las instrucciones para realizar la “parte práctica”. Por lo tanto he obviado `algunos ` puntos, lo cual ha hecho que la estructura del apartado no sea del todo lustrosa.

De todos modos, y como siempre: comprobar con el libro e incluir los apuntes extras que se consideren necesarios.

Diagramas de Flujo de Datos.
Diccionario de Datos.
Especificación de Procesos.
Diagramas de Descomposición Funcional.
Comprobaciones sobre una especificación estructurada.

Diagramas de Flujo de Datos (DFD):

Componentes:

Procesos: componentes funcionales del sistema.
Almacenes: representan los datos almacenados o en reposo.
Entidades externas: representan las fuentes y destinos de la información del sistema.
Flujos de datos: representan los datos que fluyen entre las funciones. Pueden ser “discretos” (representan datos en movimiento en un momento determinado), o “continuos” (flujos de datos persistentes en el tiempo).

Diccionario de Datos (DD):

Definición: “lista organizada de los datos utilizados por el sistema (que gráficamente se encuentran representados por los flujos de datos y almacenes presentes sobre el conjunto del DFD).

Especificación de Procesos:

Objetivo.
Métodos.

Objetivo:

“Especificar `lo que hace el proceso'. Cómo transforma las entradas en salidas”.

Métodos para la Especificación de Procesos:

Lenguaje Estructurado.
Árboles de Decisión.
Tablas de Decisión.
Diagramas de Acción.

Diagramas de Descomposición Funcional:

Objetivo:

“Representar la jerarquía de los procesos del sistema en diferentes niveles de abstracción”.

Comprobaciones a efectuar sobre una especificación estructurada:

Aspectos a tener en cuenta.
Apunte chorra final.

Aspectos a tener en cuenta:

Compleción: si los modelos son completos.
Integridad: si NO existen contradicciones ni inconsistencias entre los distintos modelos.
Exactitud: si los modelos cumplen los requisitos del usuario.
Calidad: estilo, legibilidad y facilidad de mantenimiento de los modelos producidos.

Leer tabla 7.9 (Pág. 212 del libro) y si en el examen reconocemos alguna de las frases, marcamos la opción “Es una pregunta empleada en la revisión de una especificación estructurada”.

Ejercicio práctico que nos sirve de ejemplo:

La cuestión “¿Hay almacenes locales?”:

Opción que NO es.
Se utiliza para la revisión de una especificación estructurada.
Esta tampoco es.

Muy poco probable que aparezca en el examen una cuestión sobre la susodicha tabla, pero… por si acaso… la leemos un par de veces.

“POSIBLES” PREGUNTAS CAPÍTULO VII

1. La Especificación de Requisitos Software:

Descomposición en componentes y estudio de cómo se realiza cada componente.
Documento resultado del Análisis de un SI, describiendo qué debe hacer dicho SI.
Todas son correctas.

2. Requisito:

Condición que necesita un usuario para resolver un problema o alcanzar un objetivo.
Proceso de estudio de las necesidades de los desarrolladores.
Todas son correctas.

3. Son técnicas para el Análisis de Requisitos:

Gráficas como el Diagrama de Flujo de Datos.
Entrevistas y Observación para recogida de requisitos.
Todas son correctas.

4. Las dos características fundamentales de una Especificación de Requisitos:

InformaciónVeraz y Comunicada de forma Eficaz.
Fácil de Modificar y Fácil de Verificar.
Todas son correctas.

5. Las comprobaciones a realizar sobre una Especificación estructurada:

Si los modelos son Completos y Exactos con respecto a los requisitos impuestos.
Si no existen Contradicciones ni Inconsistencia entre modelos y si son de Calidad en cuanto a estilo, legibilidad y facilidad de mantenimiento.
Todas son correctas.

RESPUESTAS

1	2	3	4	5
B	a	b	a	c

CAPITULO VII - VIII :

- ANÁLISIS DE SISTEMAS -

- DISEÑO ESTRUCTURADO DE SISTEMAS -

Intro.
DED.
Técnicas de Especificación de Control.
Comprobaciones entre modelos.
Distinción chorra.
Intro Diseño Estructurado.
Atributos de Calidad.
Normalización.
Metodologías de Diseño Detallado de Programas.

By Bruce.

Análisis de Sistemas.

Análisis/Diseño.

Diseño Estructurado de Sistemas.

INTRO BY BRUCE

A ver…

Sí, he mezclado apartados del Tema 7 con otros del Tema 8. ¿Por qué? … Las razones son varias, siendo la principal de ellas: “porque soy yo quien hace los resúmenes”.

Realmente hay unas cuantas de razones más, pero no me voy a dedicar ahora a justificarme.

“Capítulo 78 by Bruce” y no hay más que discutir .

En otro orden de cosas. Una de las preguntas incluidas al final no puede responderse con este resumen. Esto es porque la pregunta es relativa al modelo relacional, que sí aparece en el tema del libro, pero al que yo he decidido tratar aparte.

DIAGRAMA DE ESTRUCTURA DE DATOS (DED)

Es un modelo de datos más sencillo y de menor nivel de abstracción que el E/R.
Todas sus interrelaciones son 1:N.
Mas que a nivel conceptual, este modelo se emplea para representar el modelo lógico de datos.

TÉCNICAS DE ESPECIFICACIÓN DE CONTROL

Lista de Eventos.
Diagramas de transición de Estados.
Redes de Petri.

LISTA DE EVENTOS

Conceptos generales.
Definiciones.
Tipos de eventos.

Conceptos generales:

La lista de eventos consiste en un “listado de los eventos que se producen en el sistema”.
Los eventos se obtienen de los DFD. A efectos prácticos: un evento por cada función.

Definiciones:

Evento: “suceso que modifica el estado de los datos”.
Disparador: lo que da lugar a que comience un evento. Suelen ser flujos de datos que entran en el sistema.

Tipos de eventos:

Generados externamente: si el disipador es un flujo que entra en el sistema.
Reconocidos internamente: provocado por el estado interno de un dato. (Ej: cuando un dato toma un determinado valor).
Basados en el tiempo: cada cierto tiempo se lanza el evento.

DIAGRAMA DE TRANSICIÓN DE ESTADOS (DTE)

Conceptos generales.
Componentes.
Aplicaciones.

Conceptos generales:

Def: “gráfico que recoge los distintos estados que puede tomar el SI”.
Enfocado al “comportamiento del sistema en función del tiempo”.
Se utiliza comunmente para comprobar el funcionamiento de sistemas en tiempo real.

Componentes:

Estados: representan los modos externos de comportamiento.
Transiciones: obligan al paso de un estado a otro (o a sí mismo) si se cumple una condición.

Aplicaciones:

Especificar transformaciones de datos.
Especificar transformaciones de control.

REDES DE PETRI

Conceptos generales.
Componentes.
Similitud con el DTE.

Conceptos generales:

Especialmente indicada para la descripción de sistemas de control asíncronos y concurrentes.

Componentes:

Conjunto finito de lugares.
Conjunto diniro de transiciones.
Conjunto finito de conexiones o arcos.

Similitud con el Diagrama de Transición de Estados:

Los DTE pueden considerarse como un determinado tipo de redes de Petri.
Ambos modelos deben contar con las siguientes propiedades: limitación y vivacidad.
COMPROBACIONES ENTRE LOS DISTINTOS MODELOS DE ANALISIS

Principales modelos.
Comprobaciones.
Técnicas.

Matriciales.
HVE.

PRINCIPALES MODELOS SOBRE LOS QUE EFECTUAR COMPROBACIONES

Dimensión de función: DFD, DD y Especificaciones de Procesos (modelos de la Especificación Estructurada).
Dimensión de información: E/R y Diagrama de Estructura de Datos.
Dimensión de tiempo: Lista de Eventos.

COMPROBACIONES A REALIZAR ENTRE LOS MODELOS

Plano información-función :

Comprobar que todos los elementos (o datos elementales) definidos en los diagramas E/R están definidos en el DD.
Realizar la misma comprobación con los diagramas de estructuras de datos.
Comprobar que cada entidad e interrelación del E/R es consultada y actualizada al menos una vez por alguna función primitiva del DFD.

Plano información-tiempo :
Plano tiempo-función :

By Bruce: las comprobaciones entre modelos del plano información-tiempo y tiempo-función involucran ciertas comprobaciones respecto a los diagramas HVE. Inma en su día dijo: “Los HVE… con que sepáis que existen me vale.” (Sin embargo sí han caído un par de preguntas sobre los HVE) Por lo tanto… bastante dudosa la aparición en el examen de alguna pregunta relativa a estos puntos. En todo caso, si no te fías demasiado, cogemos el libro y lo miramos también (son cuatro chorradas contadas).

TÉCNICAS PARA EFECTUAR COMPROBACIONES ENTRE MODELOS

Matriciales.
HVE.

Técnicas Matriciales:

Objetivo: se utilizan principalmente para ayudar a verificar la consistencia entre los compontes de los distintos modelos de un sistema.

Funciones

Entidades

Gestionar Presupuesto Cliente

Gestionar Cliente

…

CLIENTE

I, M, B

…

PRESUPUESTO

I, M, B

…

Entidad

CLIENTE

PRESUPUESTO

CLIENTE

Realiza

PRESUPUESTO

Entidades

Eventos

CLIENTE

PRESUPUESTO

Datos del Cliente

I, M, B

Datos del presupuesto

I, M, B

Matriz Entidad/Función: permite ver la relación existente entre las funciones del sistema y la información necesaria para llevar a cabo cada una de las funciones.
Matriz Entidad/Entidad: permite ver las relaciones que tiene una entidad con otras del modelo E/R.
Matriz Evento/Entidad: muestra las alteraciones de las entidades, causadas por los eventos del sistema.

Modelado Evento/Entidad - HVE: Historia de Vida de la Entidad:

Conceptos.
HVE en el análisis.
HVE en el diseño.

Conceptos:

“Esta técnica permite ver cómo las entidades han evolucionado en el tiempo”.
La HVE muestra el ciclo de proceso de una entidad desde su creación hasta su desaparición.
HVE utiliza la notación de diagrama de estructura.

HVE en el Análisis:

Proporciona una validación para los DFD y el modelo de datos.

HVE en el Diseño:

Aquí se añaden los indicadores de estado a las HVE para permitir la validación semántica.

DISTINCIÓN ENTRE ANÁLISIS Y DISEÑO

ANÁLISIS

DISEÑO

Define QUÉ hacer.

Son técnicas empleadas en la fase de análisis:

E/R (…relativa a datos).
DFD (…relativa a funciones).

Define CÓMO hacerlo.

Se siguen dos enfoques:

De Datos.
Funcional.

8.1 DISEÑO ESTRUCTURADO DE SISTEMAS - CONCEPTOS

Objetivo: desarrollar la estructura de programa, así como las relaciones entre los elementos que componene dicha estructura (“módulos”).
El diseño estructurado nos permite, partiendo del DFD, obtener una descripción de la estructura del programa. Esta descripción se representa mediante un diagrama de estructuras.

8.2 ATRIBUTOS DE CALIDAD DE UN DISEÑO

Acoplamiento.
Cohesión.

ACOPLAMIENTO

Definición: “grado de interdependencia entre módulos”.
Lo óptimo sería que el acoplamiento fuese mínimo (hacer los módulos tan independientes los unos de los otros como sea posible).
Para que el acoplamiento sea mínimo ningún módulo tiene que preocuparse de los detalles de la construcción interna del resto de los módulos.

Acoplamientos MÁS deseados:

1.Acoplamiento normal: SÓLO se produce una llamada entre los módulos (no se pasan parámetros).
2.Acoplamiento de datos.

Acoplamientos MENOS deseados:

Uff 1.Acoplamiento por contenido: un módulo hace referencia al interior de otro.
Uff 2. Acoplamiento global: los módulos comparten una estructura global de datos.

COHESIÓN

Definición: “relación que existe entre los elementos de un mismo módulo”.
Lo óptimo es que la cohesión sea máxima.
Deben agruparse en módulos los elementos que guarden una determinada relación.

FUNCIONAL

SECUENCIAL

COMUNICACIONAL

Mayor Cohesión

Módulo como caja negra

PROCEDURAL

TEMPORAL

LÓGICA

COINCIDENTAL

Menor Cohesión

Módulo transparente

8.3 TEORÍA DE LA NORMALIZACIÓN

Conceptos.
1FN - Dependencia Funcional.
2FN - Dependencia Funcional Completa.
3FN - Dependencia Funcional Transitiva.
Boyce-Codd.

CONCEPTOS GENERALES

Objetivo: eliminar la “dependencia” entre los atributos (eliminar la redundancia de datos).
“Normalización”: conjunto de restricciones que deben satisfacer los datos. Cada conjunto de restricciones se conoce como “forma normal”.

1FN - DEPENDENCIA FUNCIONAL

1FN: prohíbe que en un registro haya grupos repetitivos (“todos los campos han de ser atómicos”). Por tanto, para que un registro esté en 1FN, no puede contar con atributos multivaluados.

La 1FN está definida formalmente por la Dependencia Funcional.

Dependencia Funcional: “Se dice que un descriptor Y (conjunto de campos) depende funcionalmente del descriptor X, si y sólo si, cada valor de X tiene asociado en todo momento un único valor de Y”.

X Y

2FN - DEPENDENCIA FUNCIONAL COMPLETA

2FN: en el caso de que la clave sea compuesta, un registro está en 2FN “si además de estar en 1FN, todos los campos que no formen parte de la clave candidata suministran información acerca de la clave completa”.
2FN: “Un registro está en 2FN si está en 1FN y todo campo no clave tiene una dependencia funcional completa respecto de las claves candidatas”.

La 2FN está definida formalmente por la Dependencia Funcional Completa.

Dependencia Funcional Completa: “Si el descriptor X es compuesto, se dice que Y tiene dependencia funcional completa o plena respecto de X si depende funcionalemente de X pero no depende de ningún subconjunto del mismo”.

X(X1, X2)

X --> Y

X1 -/-> Y

X2 -/-> Y

3FN - DEPENDENCIA FUNCIONAL TRANSITIVA

3FN: para que un registro esté en 3FN, además de estar en 2FN, los atributos que NO son clave, proporcionan información SÓLO sobre la clave (y no acerca de otros atributos).
3FN: “Un registro está en 3FN si está en 2FN y ningún campo no clave depende transitivamente de ninguna clave”.

La 3FN está definida formalmente por la Dependencia Funcional Transitiva.

Dependencia Funcional Transitiva: Dado un registro con tres descriptores en el que existen las siguientes dependencias funcionales:

…”se dice que Z tiene una dependencia transitiva respecto de X a través de Y”.

X --> Y

Y --> Z

Y -/-> X

X - --> Z

FORMA NORMAL DE BOYCE-CODD (FNBC)

Se emplea para evitar solapamientos entre claves compuestas.
“Se dice que un registro está en FNBC si, y sólo si, todo determinante es clave”.

METODOLOGÍAS DE DISEÑO DETALLADO DE PROGRAMAS

Conceptos.

Jackson.
Warnier.

CONCEPTOS GENERALES

Permiten obtener una estructura jerárquica del programa.
Permiten generar una codificación en forma de pseudocódigo (que puede ser fácilmente traducida a un lenguaje procedimental de programación).
El enfoque que siguen estos métodos se basa en el análisis de los datos que deben manejar los programas.
Toman como punto de partida: una especificación detallada de la entrada, la salida y los algoritmos del programa a construir.
Las principales metodologías para el Diseño Detallado de Programas son: el Método Jackson y la Metodología Warnier.

“POSIBLES” PREGUNTAS CAPÍTULO 78

1. Las técnicas de modelado enfocado en el comportamiento de un SI dependiendo del tiempo:

Lista de Eventos.
Diagramas de Transición y Redes de Petri.
Ambas son correctas.

2. Para efectuar comprobaciones entre los distintos modelos:

Técnicas Matriciales.
Historia de Vida de Entidad.
Ambas son correctas

3. En análisis, la Historia de vida de Entidades proporciona:

Visualizar relaciones existentes entre entidades de un modelo de datos.
Una validación para DFD y modelos de datos.
Ambas son correctas.

4. Con respecto al Análisis y el Diseño:

Análisis se refiere a Qué hacer y Diseño a Cómo hacerlo.
Análisis se refiere a Cómo hacerlo y Diseño a Qué hacer.
Ninguna es correcta.

5. Un Modelo Conceptual como el modelo E-R:

Técnica utilizada en Análisis.
Técnica utilizada en Diseño.
Ninguna es correcta.

6. El Modelo Relacional es:

Modelo Conceptual de Datos.
Modelo Lógico de Datos.
Modelo Físico de Datos.

7. Las métricas que miden la calidad estructural del diseño:

Verificación y Cohesión.
Integridad y Validación.
Cohesión y Acoplamiento.

8. El grado de independencia entre módulos lo mide el atributo de calidad:

Cohesión.
Acoplamiento.
Ambas son correctas.

9. El Acoplamiento óptimo:

Es Mínimo (Acoplamiento Normal).
Es Máximo (Acoplamiento por Contenido).
Ambas son correctas.

10. La Cohesión óptima:

Es Máxima (Cohesión Funcional).
Es Máxima (Cohesión Coincidental).
Ambas son correctas.

11. La Dependencia Funcional Transitiva define formalmente:

1FN.
2FN.
3FN.

12. Generan una estructura lógica partiendo de especificaciones detalladas de datos de entrada, de datos de salida y de algoritmos necesarios :

Metodologías de Diseño Arquitectónico de Programas.
Metodologías de Diseño Detallado de Programas.
Metodologías de Análisis Estructurado.

13. Jackson y Warnier:

Proponen un método para generar una codificación en forma de pseudocódigo.
Proponen un método para el Diseño Detallado de Programas.
Ambas son correctas.

RESPUESTAS

1	2	3	4	5	6	7	8	9	10	11	12	13
c	c	b	a	a	b	c	b	a	a	c	b	c

CAPITULO XII : PRUEBAS DEL SOFTWARE

INTRO

Conceptos.
Definiciones.

CONCEPTOS GENERALES

Durante el desarrollo de software se requieren una serie de controles periódicos para evaluar los productos generados con el fin de encontrar defectos.
Las pruebas consisten en ejecuciones o ensayos, posteriores a la terminación del código y previos a la entrega del software al cliente.
Las pruebas permiten VERIFICAR y VALIDAR el software:

VERIFICAR: comprobar `si lo estamos haciendo tal como lo habíamos planteado'.
VALIDAR: comprobar `si estamos haciendo lo que nos han pedido'.

La verificación y validación se llevan a cabo cuando nuestro producto ya es ejecutable.

DEFINICIONES

Prueba: proceso de ejecutar un programa con el fin de encontrar errores. (Tb: conjunto de casos y procedimientos de prueba).
Caso de prueba: entradas, condiciones y resultados preconcebidos para estudiar un objetivo concreto.
Defecto (bug): `algo mal programado'. (Ej: variable mal declarada, paso de parámetros erróneo, etc.).
Fallo: el sistema (o uno de sus componentes) no satisface los requisitos de rendimiento especificados.
Error: diferencia entre un valor calculado, observado o medido y e la valor verdadero (“Margen de error”). (Tb: acción humana que conduce a un resultado incorrecto. Ej: “el programador pulsa una tecla equivocada” ¿?).

FILOSOFÍA DE LAS PRUEBAS DEL SOFTWARE

Conceptos.
Recomendaciones.
Conclusiones.

CONCEPTOS GENERALES

La prueba exhaustiva del software es impracticable (NO se pueden probar todas las posibilidades de un programa).
Descubrir un defecto debe considerarse el “éxito de una prueba”.
La realización de pruebas se trata de una actividad de detección (NO de prevención) de problemas en el software.
Los defectos no son siempre el resultado de una negligencia.

RECOMENDACIONES PARA LAS PRUEBAS

Definir el resultado de salida esperado y compararlo con el obtenido.
El programador debe evitar probar sus propios programas.
Inspeccionar a conciencia el resultado de cada prueba.
Definir casos de prueba que incluyan datos de entrada tanto válidos y esperados, como no válidos e inesperados.
Se debe probar que el software hace lo que debe y NO hace lo que NO debe.
Evitar los casos desechables (`casos demasiado lamentables').
Asumir que SIEMPRE habrá fallos a la hora de hacer planes de prueba.
Donde hay un defecto suele haber otros (`¿recursividad fallil?').
Concienciarnos de que “probar es una tarea tanto o más creativa que el desarrollo de software”.

CONCLUSIONES

La filosofía más adecuada para las pruebas consiste en planificarlas y diseñarlas de forma sistemática (para poder detectar el máximo número y variedad de defectos con el mínimo consumo de tiempo y esfuerzo).
“Un buen caso de prueba es aquel que tiene una gran probabilidad de encontrar un defecto no descubierto aún”.
“El éxito de una prueba consiste en detectar un defecto no encontrado antes”.

EL PROCESO DE PRUEBA
Generación del Plan de Pruebas: en base a la documentación del proyecto y del software a probar.
Diseño detallado de pruebas específicas: se especifican los casos y procedimientos (basándose en la documentación del software).
Ejecución de los casos de prueba: sobre la configuración del software.
Evaluar los resultados: comparándolos con las salidas esperadas. La evaluación permite dos actividades:

Depuración (localización y corrección de defectos): en caso de NO conseguir detectar los defectos puede ser necesario la realización de pruebas adicionales. Si se corrige un defecto debe volver a probarse el software.
Análisis de la estadística de errores: puede ser útil para realizar predicciones de la fiabilidad del software y para detectar las causas más habituales de error y mejorar los procesos de desarrollo.
TÉCNICAS DE DISEÑO DE CASOS DE PRUEBA

Conceptos.
Enfoques.

CONCEPTOS GENERALES

Objetivo: conseguir una confianza aceptable en la detección de defectos sin necesidad de consumir una cantidad excesivo de recursos. Debe lograrse, por tanto, un equilibrio entre disponibilidad de recursos y confianza en la detección de defectos.
El diseño de casos de prueba está totalmente mediatizado por la imposibilidad de probar exhaustivamente el software.
NO pueden probarse todas las posibilidades del software deben elegirse algunas de ellas que se consideren “representativas”. Dificultad: elegir los casos representativos a ejecutar.

PRINCIPALES ENFOQUE PARA EL DISEÑO DE CASOS

Estructural.
Funcional.
Aleatorio.

Enfoque Estructural (o de caja blanca):

Se centra en la estructura interna del programa.
Prueba exhaustiva: probar todos los posibles caminos de ejecución.

Enfoque Funcional (o de caja negra):

Se centra en la especificación de funciones (entradas y salidas).
Prueba exhaustiva: probar todas las posibles entradas y salidas.

Enfoque Aleatorio:

Utiliza modelos (normalmente estadísticos) que representen las posibles entradas al programa.
Prueba exhaustiva: probar todas las posibles entradas.

Estos enfoques NO son excluyentes entre sí, ya que se pueden combinar para conseguir una detección de defectos más eficaz..

PRUEBAS ESTRUCTURALES

Conceptos.
Clasificación de Criterios de Cobertura Lógica.
Métrica de McCabe.

CONCEPTOS GENERALES

El diseño de casos tiene que basarse en la elección de caminos importantes que ofrezcan una seguridad aceptable en descubir defectos Para ello se utilizan los criterios de cobertura lógica.
No requieren el uso de ninguna representación gráfica específica (aunque es habitual el empleo de los diagramas de flujo de control (flowcharts)).

CLASIFICACIÓN DE LOS CRITERIOS DE COBERTURA LÓGICA

Menor coste

Menor nº ejecuciones

Cobertura de sentencias: generar los casos de prueba necesarios para que cada sentencia (instrucción) del programa se ejecute al menos vez.

Cobertura de decisiones: ... cada decisión tenga, al menos 1 vez, un resultado verdadero y, al menos 1 vez, un resultado falso.

Cobertura de condiciones: … cada condición de cada decisión adopte el valor `verdadero' al menos 1 vez, y el valor `falso' al menos 1 vez.

Criterio de decisión/condición: exigir el cumplimiento de la cobertura de decisiones y la cobertura de condiciones.

Criterio de condición múltiple: (en el caso de dividir una decisión multicondicional en varias unicondicionales) conseguir que todas las combinaciones posibles de resultados (verdadero/falso) de cada condición de cada decisión se ejecuten al menos 1 vez.

Cobertura de caminos: …cada camino se ejecute al menos 1 vez.

Mayor coste

Mayor nº ejecuciones

Cobertura de Caminos

Criterio de cobertura más elevado.
Requiere que cada uno de los caminos del programa se ejecuten al menos 1 vez.
Camino.definición: “secuencia de sentencias encadenadas desde la sentencia inicial del programa hasta su sentencia final”.
Los bucles constituyen el elemento que que genera un mayor número de problema en la cobertura de caminos.
Para reducir el número de caminos se emplean los caminos de prueba: “camino del programa que atraviesa, como máximo, 1 vez el interior de cada bucle que encuentra”. (Como alternativa al camino de prueba, otros especialistas recomiendan que se pruebe cada bucle 3 veces: una vez sin entrar en su interior, otra ejecutándolo 1 vez y otra ejecutándolo 2 veces).
Existen algoritmos basados en matrices (que representan el grafo de flujo del programa) que permiten contar el número total de caminos de prueba.

UTILIZACIÓN DE LA COMPLEJIDAD CICLOMÁTICA DE MCCABE

Objetivo: indicar el número de caminos independientes que existen en un grafo.
By Bruce: a ver… dado el carácter teórico de los presentes resúmenes, esta parte me la salto. Si tienes especial interés en saber cómo se calcula la complejidad de McCabe a partir de un grafo de flujo, te miras las páginas 402, 403, 404 y 405 del libro. Como adelanto: es otra mariconada más entre tantas que aparecen el el libro. Inciso concluido. Hasta luego .

PRUEBAS FUNCIONALES

Conceptos.
Técnicas.

CONCEPTOS GENERALES

Se centra en el estudio de la especificación del software, del análisis de las funciones que debe realizar, de las entradas y de las salidas.
Deben “buscarse criterios que permitan elegir un subconjunto de casos cuya ejecución aporte una cierta confianza en detectar los posibles defectos del software”.
Para elegir los casos de prueba, se considera Caso de Prueba Bien Elegido aquel que:

Reduce el número de otros casos necesarios.
Cubre un conjunto extenso de otros casos posibles.

TÉCNICAS DE DISEÑO DE CASOS DE CAJA NEGRA

Particiones o Clases de Equivalencia.
AVL.
Conjetura de errores.

Particiones o Clases de Equivalencia:

Cualidades.
Método de Diseño.

Cualidades de la Técnica:

Cada caso debe cubrir el máximo número de entradas.
Debe tratarse el dominio de valores de entrada (divido en un número finito de clases de equivalencia) que cumplan la siguiente propiedad: “la prueba de un valor representativo de una clase permite suponer `razonablemente' que el resultado obtenido será el mismo que el obtenido probando cualquier otro valor de la misma clase.

Método de Diseño:
Identificación de Clases de Equivalencia.
Creación de Casos de Prueba.
Identificación de Clases de Equivalencia:
Identificación de las condiciones de entrada (restricciones de formato o contenido de los datos de entrada).
Identificación de las clases de equivalencia (a partir de los datos de entrada). Éstas clases pueden ser:

De datos válidos.
De datos no válidos o erróneos.

“Todos los valores de la clase deben ser tratados de la misma forma por el programa” (Principio de Igualdad de Tratamiento).
REGLAS para identificar clases:

Rango de valores	Ej: “El número estará comprendido entre 1 y 49”	C. válida: (1 ≤ nº ≥ 49) C. no válida (nº < 1) C. no válida (nº > 49)
Número de valores	Ej: “se pueden registrar de uno a tres propietarios de un piso”	C. válida: (1 ≤ propiet. ≥ 3) C. no válida (propiet. < 1) C. no válida ( propiet. > 3)
Situación booleana	Ej: “el primer carácter debe ser una letra”	C. válida (“es una letra”) C. no válida (“no es una letra”)
Conjunto de valores admitidos (tratando el programa de distinta forma a cada uno de ellos)	Ej: “pueden registrarse tres tipos de inmuebles: pisos, chalés y locales comerciales”	C. válida (“piso”) C. válida (“chalé”) C. válida (“local”) C. no válida (“garaje”)
Si se sospecha que ciertos elementos de una clase no se tratan igual que el resto de la misma, deben dividirse en clases menores.

Creación de Casos de Prueba:
Asignación de un número único a cada clase de equivalencia.
Hasta que se hayan cubierto todas las clases de equivalencia con casos de prueba escribir un caso que cubra tantas clases válidas como sea posible.
Hasta que se hayan cubierto todas las clases de equivalencia no válidas con casos de prueba escribir un caso para una única clase no válida sin cubrir.

Análisis de Valores Límite (AVL):

Conceptos.
Reglas.

Conceptos Generales:

Complementa a la técnica de particiones de equivalencia.
Los casos de prueba que exploran las condiciones límite de un programa producen mejor resultado para la detección de defectos.
Condiciones Líminte.def: “situaciones que se hallan directamente arriba, abajo y en los márgenes de las clases de equivalencia”.
El proceso de selección de casos es también heurístico¹.

1. Heurístico: (gr. εϋρίσηω, hallar, inventar), adj. Perteneciente o relativo a la heurística.

REGLAS para identificar clases:

(1) Rango de valores. (Como condición de entrada)	Ej: “el valor estará comprendido entre 1 y -1”	2 Casos válidos para los extremos: ( - 1.0 ) ( + 1.0 ) 2 Casos no válidos para valores justo más allá de los extremos: ( - 1.001 ) ( + 1.001 )
(2) Número de valores. (Como condición de entrada)	Ej: “el fichero de entrada tendrá de 1 a 255 registros”	Máximo: ( 255 registros ) Mínimo: ( 1 registro ) Máximo + 1: ( 256 registros ) Mínimo - 1: ( 0 registros )
(3) Rango de valores. (Como condición de salida)	Ej: “el descuento máximo aplicable en una compra al contado será el 50%, el mínimo será el 6%”	(Idem regla 1). Se escribirán casos para obtener: 6%, 50%, 5.99% y 50.01%.
(4) Número de valores. (Como condición de salida)	Ej: “el programa puede mostrar de 1 a 4 listados”	(Idem regla 2). Se escribirán casos para obtener: 0, 1, 4 y 5 listados.
Conjunto ordenado de elementos. (Entrada o salida)	Ej: tablas, archivos secuenciales…	Caso concentrado en el primer elemento. Caso concentrado en el último elemento.
Tanto en la regla 3 como en la 4, debe tenerse en cuenta que: Los valores límite de entrada no generan necesariamente los valores límite de salida. No siempre se pueden generar resultados fuera del rango de salida.

Conjetura de Errores:

Conceptos.
Recomendaciones.

Conceptos Generales:

Consiste en:
Enumerar una lista de equivocaciones que pueden cometer los desarrolladores y de situaciones propensas a ciertos errores.
Generar los casos de prueba en base a dicha lista.

La generación de casos se basa en la intuición o la experiencia.

Valores propensos a error y Recomendaciones a tener en cuenta para los casos especiales:

Valor cero (tanto en la salida como en la entrada).
En listas o tablas: ningún valor, todos los valores iguales.
Recomendable: imaginar que le programador hubiese interpretado algo mal en la especificación.
Recomendable: imaginar lo que el usuario puede introducir como entrada a un programa.

PRUEBAS ALEATORIAS

Simulan la entrada habitual del programa creando datos de entrada (en la secuencia y con la frecuencia con las que podrían aparecer en una situación real), de forma contínua y sin parar.
Utilizan una herramienta llamada “generador de pruebas”, que debe contener la descripción de entradas y secuencias de entrada junto con su posibilidad de ocurrir en la práctica.
Empleadas comunmente en la prueba de compiladores.
Son menos utilizadas que las técnicas de caja blanca y de caja negra.

ENFOQUE PRÁCTICO RECOMENDADO PARA EL DISEÑO DE CASOS

Pretende mostrar el uso más apropiado de cada técnica para la obtención de un conjunto de casos útiles (sin prejuicio de las estrategias de casos de prueba).

RECOMENDACIONES A LA HORA DE DISEÑAR CASOS

Comenzar formando los grafos causa-efecto si la especificación contiene combinaciones de condiciones de entrada.
Usar el análisis de valores-límites.
Identificar las clases válidas y no válidas de equivalencia para la entrada y la salida, y añadir los casos no incluidos anteriormente.
Utilizar la técnica de conjetura de errores.
Ejecutar los casos generados hasta el momento y analizar la cobertura obtenida.
Examinar la lógica del programa.

DOCUMENTACIÓN DEL DISEÑO DE LAS PRUEBAS

Conceptos.
Documentos.

Plan de Pruebas.
Especificación del Diseño de Pruebas.
Especificación de Caso de Prueba.
Especificación de Procedimiento de Prueba.

CONCEPTOS GENERALES

Es necesaria tanto para una mejor organización de las pruebas, como para asegurar su reutilización.
Los documentos contemplados en el estándar se asocian a las distintas fases de las pruebas.

DOCUMENTOS

Plan de Pruebas: señalar el enfoque, los recursos y el esquema de actividades de prueba, así como los elementos a probar, las características, las actividades de prueba, el personal responsable y los riesgos asociados.
Especificación del Diseño de Pruebas: especificar los refinamientos necesarios sobre el enfoque general reflejado en el plan e identificar las características que se deben probar con este diseño de pruebas.
Especificación de Casos de Prueba: definir uno de los casos de prueba identificado por una especificación del diseño de las pruebas.
Especificación de Procedimiento de Prueba: especificar los pasos para la ejecución de un conjunto de casos de prueba.

EJECUCIÓN DE LAS PRUEBAS

Proceso.
Documentación.
Depuración.
Análisis de Errores.

EL PROCESO DE EJECUCIÓN

General.
Ejecución.
Comprobación.

Proceso General de Pruebas:

Ejecución de las pruebas.

Comprobación de la Terminación de las Pruebas.

Evaluación de Resultados. (NOTA: este subproceso se lleva a cabo en el caso de que las pruebas hayan terminado, en caso contrario hay que generar pruebas adicionales).

Subproceso de Ejecución:

Ejecución de las pruebas (`paso por el ordenador de los datos de prueba').
Comprobación de posibles fallos de ejecución.
Si ha habido algún fallo se realizan nuevas pruebas.
Si NO existen fallos, se pasa a la comprobación de la terminación de las pruebas.

Subproceso de Comprobación:

Comprobar si se cumplen los criterios de compleción (descritos en el Plan de Pruebas).
En caso de terminar las pruebas Evaluar los productos probados sobre la base de los resultados obtenidos.
En caso de NO terminar las pruebas Comprobar la presencia de condiciones anormales de prueba.
Si han existido condiciones anormales, se pasa de nuevo a la evaluación. En caso contrario se pasa a generar y ejecutar pruebas adicionales.

Los criterios de compleción de pruebas hacen referencias a áreas que deben cubrir las pruebas y el grado de cobertura para cada área (Ej: `se debe cubrir cada característica del software mediante un caso de prueba o una excepción aprobada en el plan de pruebas')

DOCUMENTACIÓN DE LA EJECUCIÓN DE LAS PRUEBAS

DEPURACIÓN

Conceptos.
Consejos.

Conceptos Generales:

Depuración.def: “proceso de localizar, analizar y corregir los defectos que se sospecha que tiene el software”.
Suele ser la consecuencia de una prueba con éxito.
Las consecuencias de una depuración pueden ser dos:

Encontrar la causa del error, analizarla y corregirla.
No encontrar la causa (y tener que generar nuevos casos de prueba).

Las dos principales etapas de la depuración son:

Localización del defecto (que conlleva la mayor parte del esfuerzo).
Corrección del defecto (modificando el software convenientemente).

Consejos chorras para la Depuración:

Localización del error:

Analizar la información y pensar.
Al llegar a un punto muerto, pasar a otra cosa.
Al llegar a un punto muerto, describir el problema a otra persona.
Usar herramientas de depuración sólo como recurso secundario.
No experimentar cambiando el programa.
Se deben atacar los errores individualmente.
Se debe fijar la atención también en los datos.

Corrección del error:

Donde hay un defecto suele haber más.
Debe fijarse el defecto, no sus síntomas.
La probabilidad de corregir perfectamente un defecto no es del 100%.
Cuidado con crear nuevos defectos.
La corrección debe situarnos temporalmente en la fase de diseño.
Cambiar el código fuente, no el código objeto.

ANÁLISIS DE ERRORES (o Análisis Causal)

Se emplea para obtener información sobre la “naturaleza de los defectos”.
El objetivo principal es la formación del personal sobre los errores que comete para que se puedan prevenir en el futuro.

12.11 ESTRATEGIA DE APLICACIÓN DE LAS PRUEBAS

Conceptos.
Prueba de Unidad.
Prueba de Integración.
Prueba del Sistema.
Prueba de Aceptación.

CONCEPTOS GENERALES

Conceptos.
Niveles de Prueba.
Niveles de Prueba - Productos de Desarrollo.

Conceptos:

Pretende integrar el diseño de los casos de prueba en una serie de pasos bien coordinados (a través de la creación de distintos niveles de prueba con diferentes objetivos).
Permite la coordinación del personal de desarrollo, del departamento de aseguramiento de calidad y del cliente (gracias a la definición de los papeles que deben desempeñar cada uno de ellos y la forma de llevarlos a cabo).

Etapas de la Estrategia de Pruebas (“Niveles de Prueba”):

Prueba de Módulo (prueba de unidad): el propio personal de desearrollo (normalmente) realiza la prueba de cada módulo.
Prueba de Integración: se integran los módulos probados (en base al esquema del diseño del software), para comprobar sus interfaces en el trabajo conjunto.
Prueba de Validación (o funcional): el software totalmente ensamblado se prueba como un conjunto para comprobar si cumple o no los requisitos.
Prueba del Sistema: se integra el software ya validado con el resto del sistema para probar su funcionamiento conjunto.
Prueba de Aceptación: el usuario comprueba el producto final en su propio entorno de explotación para aceptarlo como está, o no.

Relación entre Niveles de Prueba y Etapas de Desarrollo:

La relación entre productos de desarrollo y niveles de prueba se concreta en un modelo de ciclo de vida denominado “Ciclo en Uve”.

Prueba de Módulo (prueba de unidad): ejercitar la lógica del módulo (caja blanca) y la especificación de las funciones que debe realizar el módulo (caja negra) “Especificación y lógica de módulo”.
Prueba de Integración: tratar los mecanismos de agrupación de módulos (fijados en la estructura del programa) “Diseño modular”.
Prueba de Validación (o funcional): comprobar posibles desajustes entre el software y los requisitos fijados para su funcionamiento en la ERS (No asociado a ningún producto del desarrollo según el `Ciclo en Uve').
Prueba del Sistema: comprobaciones del cumplimiento de objetivos indicados para el sistema “Especificación de requisitos”.
Prueba de Aceptación: para que el usuario verifique si el producto final se ajusta a los requistos por él fijados (o al contrato) “Requisitos de usuario”.

PRUEBA DE UNIDAD

Conceptos.
Definiciones.
Enfoque.

Conceptos Generales:

Suelen ser realizadas por el personal de desarrollo (evitando que las realice el programador).
Se intenta el máximo acercamiento al ideal de exhaustividad (a través de los criterios de cobertura lógica y funcional).
La planificación de este nivel de pruebas se realiza para la globalidad de pruebas de unidad.
Consisten en las pruebas formales que nos permiten declarar que un módulo está listo y terminado.
Puede realizarse tanto a un único módulo como a un conjunto indefinido de éstos.

Definiciones:

“Módulo.def1”: bloque básico de construcción de programas.
“Módulo.def2”: parte del código que implementa una función simple.
“Módulo.def3”: fragmento de código que se puede compilar independientemente.
“Unidad de prueba”: uno o más módulos que cumplen las siguientes condiciones:

Todos pertenecen al mismo programa.
Al menos uno de ellos NO ha sido probado.
El conjunto de módulos es el objeto de un proceso de prueba.

Enfoque para una Prueba de Unidad:

Orientado claramente al diseño de casos de caja blanca (aunque complementado con caja negra).
Suele seguirse el `Enfoque Recomendado'.

Las razones por las que incluir casos de caja blanca son:

El tamaño del módulo (o grupo de módulos) es apropiado para poder usar técnicas de caja blanca para examinar toda la lógica.
El tipo de defectos que se busca coincide con los propios de la lógica detallada de módulos.

PRUEBA DE INTEGRACIÓN

Conceptos.
Integración Incremental.

Ascendente.
Descendente.

Integración NO Incremental.
Sandwich.
Incremental - No Incremental.
Incremental ascendente - Incremental descendente.
Recomendaciones.

Conceptos Generales:

Objetivo: probar las interfaces (`flujos de datos') entre componentes o módulos.
Consiste en integrar los distintos componentes del software (`realiazión de pruebas de los distintos módulos'), hasta contar con el producto global (`sistema completo').
Los tipos fundamentales de integración son: la integración incremental (ascendente y descendente )y la integración no incremental (o `Big-Bang').
NO es siempre obligatorio que, en la estrategia de aplicación de las pruebas, deba terminarse la prueba de todos los módulos antes de empezar a integrar. (“La prueba de módulos y las pruebas de integración se solapan”).
El orden de integración elegido influye en aspectos como:

La forma de preparar casos.
Las herramientas necesarias.
El orden de codificar y probar los módulos.
El coste de la depuración.
El coste de la preparación de casos.

Integración Incremental Ascendente:

Comenzando por los módulos de más bajo nivel (`módulos hoja'), se combina el siguiente módulo que se debe probar con el conjunto de módulos que ya están probados. Se incrementa progresivamente el número de módulos hasta formar el programa completo.

Fases: ( En el ejemplo se parte de un esquema idéntico al de la fase 4).

Se combinan los módulos de bajo nivel en grupos (no obligatoriamente) que realizan alguna subfunción específica. (Para reducir el número de pasos de integración).
Se escribe para cada grupo un módulo impulsor.
Se prueba cada grupo probando su impulsor.
Se eliminan los impulsores de cada grupo y se sustituyen por los módulos del nivel superior de la jerarquía.

En todas las integraciones incrementales se combinan pruebas de unidad y de integración.

Integración Incremental Descendente:

Comenzando por el módulo de control principal (`módulo raíz'), se van incorporando módulos subordinados progresivamente hasta formar el programa completo.
Se basa en el empleo de modulos ficticios, cuya codificación es más compleja que la creación de impulsores.

Debido a la dificultad de construcción existen varios niveles de sofisticación de módulos ficticios (de mayor a menor nivel de complejidad):
Módulos que sólo muestran un mensaje de traza.
Módulos que muestran los parámetros que se les pasa.
Módulos que devuleven valores que NO dependen de los parámetros de entrada.
Módulos que devuleven valores que dependen de los parámetros de entrada.

No existe un procedimiento general para determinar cuál de los modulos subordinados es mejor incorporar primero. (Hay que estudiar en cada caso cuál es el mejor orden de incorporación).

Consejos para elegir el orden de incorporación:

Si hay secciones críticas, se debe planear la secuencia de integración para que se prueben lo antes posible.
El orden de integración debe incorporar cuanto antes los módulos de entrada/salida para facilitar la ejecución de las pruebas.

Principales tipos de órdenes (`ordenaciones') de integración:

Primero en profundidad: se van completando ramas del árbol modular. (En el ejemplito anterior, la secuencia sería: A-B-E-C-F-G-D).
Primero en anchura: se van completando niveles (horizontales) de jerarquía modular. (En el ejemplito: A-B-C-D-E-F-G).

Fases:

Se escriben módulos ficticios para simular la presencia de los subordinados ausentes que serán llamados por el módulo raíz.
Se sustituye uno de los subordinados ficticios por el módulo correspondiente según el orden elegido, y se incorporan ficticios para recoger las llamadas del último incorporado.
Se ejecutan las correspondientes pruebas cada vez que se incorpora un módulo nuevo.
Al terminar cada prueba se sustituye el ficticio por su correspondiente real.
[Conviene repetir algunos casos de prueba de ejecuciones anteriores para asegurarse de que no se ha incluído ningún defecto nuevo.]

Integración no Incremental:

Es el único caso en el que las pruebas de unidad y de integración estám totalmente separadas.
Cada módulo requiere para ser probado:

Un módulo impulsor (transmite los datos de prueba al módulo y muestra los resultados de dichos casos de prueba).
Uno o más módulos ficticios..

Fases:

Se prueba cada módulo por separado.
Se ensamblan todos los módulos para formar el programa completo.
Se prueba el conjunto.

Aproximación Combinada o Sandwich:

Fases:

Se comienza en los módulos de niveles superiores de forma descendente.
Se comienza simultáneamente de forma descendente desde los módulos inferiores.
Se continúa hasta que ambas aproximaciones se encuentren en algún nivel intermedio.

Ventajas de la Integración Incremental frente a la Integración no Incremental:

Integración Incremental

Integración NO Incremental

Requiere menos tiempo para la máquina de pruebas (si NO se tiene en cuenta el tiempo de máquina para los módulos auxiliares).
Existen más oportunidades de probar módulos en paralelo.

Requiere menos trabajo (se escriben menos módulos impulsores y ficticios).
Los defectos y errores en las interfaces se detectan antes.
La depuración es mucho más fácil.
Se examina con mayor detalle el programa.

Comparación Integración Ascendente - Integración Descendente:

Integración Ascendente - Ventajas		Integración Descendente - Ventajas
Ventajosa si aparecen grandes fallos en la parte inferior del programa. Las entradas para las pruebas son más fáciles de crear. Más fácil observar los resultados de la prueba.		Ventajosa si aparecen grandes defectos en la parte superior del programa. Es fácil manejar los casos de prueba (una vez incorporadas las funciones de entrada/salida). Permite ver antes una estructura previa del programa.
Integración Ascendente . Desventajas		Integración Descendente . Desventajas
Se requieren módulos impulsores, que deben codificarse. El programa, como entidad, sólo aparece cuando se incorpora el último módulo.		Se requieren módulos ficticios (que suelen ser compejos de crear). Antes de incorporar la entrada/salida resulta complicado el manejo de los casos de prueba. Las entradas para las pruebas pueden ser difíciles o imposibles de crear. Es más difícil observar la salida. Puede inducir a diferir la terminación de la prueba de ciertos módulos.

PRUEBA DEL SISTEMA

Definición.
Requisitos.
Casos.

Definición:

Prueba del Sistema: “proceso de prueba de un sistema integrado de hardware y software para comprobar si cumple los requisitos especificados”.

Requisitos:

Todos los requistos funcionales.
Funcionamiento y rendimiento en las interfaces de hardware, software, de usuario y de operador.
Adecuación a la documentación de usuario.
Ejecución y rendimiento en condiciones límite y de sobrecarga.

Principales Tipos de Casos para la Prueba del Sistema:

Basados en los requisitos (aplicando técnicas de caja negra).
Necesarios para probar el rendimiento del sistema y de su capacidad funcional (“Pruebas de Sobrecarga”).
Basados en el diseño de alto nivel (aplicando técnicas de caja blanca)

PRUEBA DE ACEPTACIÓN

Conceptos.
Características.
Consejos.
Casos de Prueba.

Conceptos Generales:

Def: “prueba planificada y organizada formalmente para determinar si se cumplen los requisitos de aceptación marcados por el cliente.
Objetivo: comprobar si el producto está listo para ser implantado para el uso operativo en el entorno de usuario.
Lo principal para evaluar el uso operativo del software suele ser su fiabilidad y facilidad de uso.

Características:

Participación del usuario. (Suele ser quienejecuta las pruebas).
Enfocada hacia la prueba de requisitos de usuario.
Considerada como la `fase final del proceso'.

Consejos:

Evitar probar pensando en demostrar que el sistema es perfecto.
Evitar probar sin planificar.

Contar con criterios de aceptación previamente aprobados por el usuario.
No olvidar la documentación y los procedimientos de uso.
Las pruebas deben realizarse en el entorno en el que se utilizará el sistema:

Sistemas contratados: pruebas bajo el control de la organización de desarrollo en el entorno real de trabajo, ayudando al usuario “Pruebas Alfa”.
Productos de interés general: entrega de versiones a usuarios de confianza (sin control directo de la organización) que informarán de la opinión que les merece la aplicación “Pruebas Beta”.

Posibilidades para los Casos de Prueba de Aceptación:

Normalmente: proceden de casos de caja negra y se pueden reutilizar casos creados para la prueba del sistema.
Procesamiento de una carga de trabajo típica. (Implica una gran cantidad de datos).
En sistemas que remplazan a uno anterior se puede operar con ambos en paralelo para comparar resultados.
Pruebas especiales de fiabilidad o robustez, para comprobar el nivel de degradación del sistema.

“POSIBLES” PREGUNTAS CAPÍTULO XII

1. Objetivos de Técnicas para Diseño de Casos de Prueba:

Conseguir equilibrio entre disponibilidad de recursos y confianza en detectar defectos.
Conseguir confianza aceptable en detección de defectos sin consumo excesivo de recursos.
Todas son correctas.

2. Los tres enfoques principales para el Diseño de Casos de Pruebas:

Estructural, Estratégico y Práctico.
Funcional, Aleatorio y Conjetura de Errores.
Estructural, Funcional y Aleatorio.

3. Las Pruebas Estructurales se basan el la elección de caminos que ofrezcan una seguridad aceptable a la hora de descubrir defectos, utilizando los llamados:

Criterios de Cobertura Lógica.
Caso de Prueba Bien Elegido.
Ambas son correctas.

4. La Prueba Funcional o Caja Negra, se centra en:

Estudio de la especificación del software.
Análisis de funciones a realizar y de las entradas y salidas.
Ambas son correctas.

5. Clases de Equivalencia:

Enfoque Estructural.
Técnicas para Prueba Funcional.
Cobertura de Sentencias.

6. El Enfoque Práctico recomendado:

Utilizar técnicas de Conjetura de Errores y Análisis de Valores Límites.
Elegir en cada caso las técnicas de un enfoque determinado.
Ambas son correctas.

7. El Informe de Incidencias:

Documento asociado a la Ejecución de Pruebas.
Documento asociado a la Planificación de Pruebas.
Documento asociado a Procedimientos de Pruebas.

8. La Depuración:

Localiza defectos.
Corrige defectos.
Ambas son correctas.

9. La Prueba Beta se realiza en el entorno real de trabajo:

Bajo el control de la organización de desarrollo ayudando al usuario.
Sin control directo de la organización de desarrollo, entregando versiones a usuarios de confianza.
Es la prueba definitiva del sistema.

10. Dada la especificación El nombre es de 6 caracteres:

Una clase válida (nombre de 6 caracteres) y dos clases no válidas (nombre < 6 caracteres y nombre > 6 caracteres).
Una clase válida (nombre es de 6 caracteres) y una clase no válida (nombre no es de 6 caracteres).
Una clase válida (nombre es de 6 caracteres) que se dividirá en clases menores por ser trarados sus elementos de forma distinta.

11. Dado el siguiente diagrama modular, suponiendo que no hay ningún tipo de agrupación de módulos para hacer pruebas de unidad:

Para una integración descendente, el número mínimo de módulos ficiticios es 5.
Para una integración ascendente, el número mínimo de módulos implusores es 5.
Ambas son correctas.

RESPUESTAS

1	2	3	4	5	6	7	8	9	10	11
c	c	a	c	b	a	a	c	b	a	c

METRICA ES FÁCIL (V 2.0)

Intro

Comenzamos comentando que salvo un par de ellas, todas las preguntas aparecieron en el examen parcial del tercer trimestre, aunque la mayoría no de forma literal.

En la parte dedicada a las preguntas del test de Métrica, lo que se han indicado han sido las RESPUESTAS CORRECTAS (NO son distintas opciones entre las que haya que escoger). Así que si leemos por ejemplo:

4. ¿Cuáles son los principales productos de un proceso de análisis estructurado?

- Modelo de procesos.

- Modelo conceptual de datos.

- Modelo lógico de datos.

- Especificación de interfaz de usuario.

Viene a decir que los productos del proceso de análisis estructurado son esos cuatro. Los memorizas. Y si en el examen te encuentras con una opción que no se corresponda con ninguno de esos cuatro es porque dicha opción es falsa.

La pregunta 11 del último examen, la 6 del apartado Construcción del Sistema de Información de los “apuntes” aquí presentes, digamos que… mmmmm… esto… CASCA! Nosotros optaremos por la respuesta que se incluye en el test de Métrica, que es también la que se expone aquí (que también es la que se dio por válida en el anterior examen) y que, muy curiosamente, contradice a lo que podemos leer en el apartado dedicado a la actividad CSI 5 de Métrica. A continuación, con todos nosotros la susodicha preguntita junto a su correspondiente respuesta:

6. ¿Qué participantes NO intervienen en la actividad CSI 5 “Ejecución de las Pruebas del Sistema”?

- Técnicos de Sistemas

- Técnicos de Comunicaciones

- Equipo del Proyecto

- Analistas

Y si nos localizamos el cuadro resumen de la actividad CSI 5, nos encontramos con lo siguiente:

Tarea		Productos	Técnicas y Prácticas	Participantes
CSI 5.1	Preparación del Entorno de las Pruebas del Sistema	- Entorno de Pruebas del Sistema		- Técnicos de Sistemas - Técnicos de Comunicaciones - Equipo de arquitectura - Equipo del Proyecto
CSI 5.2	Realización de las Pruebas del Sistema	- Resultado de las Pruebas del Sistema	- Pruebas del Sistema	- Equipo del Proyecto
CSI 5.3	Evaluación del resultado de las Pruebas del Sistema	- Evaluación del Resultado de las Pruebas del Sistema		- Analistas - Jefe de Proyecto

Lo que viene a decir que nos aprendamos las respuestas a modo de dogma de fe y que la suerte esté presente durante el examen.

Procesos Principales

Métrica 3 es una metodología orientada a procesos que pretende abarcar el ciclo de vida completo del software. Por consiguiente, tenemos que, los procesos principales de su estructura son la planificación, el desarrollo y el mantenimiento del SI.

El proceso de desarrollo del SI a su vez se descompone en otros 5 procesos, 4 de los cuales sería conveniente memorizar en el caso de pretender aprobar la parte dedicada a Métrica del examen.

Planificación del Sistema de Información (PSI)
Desarrollo del Sistema de Información

Estudio de Viabilidad del Sistema (EVS)
Análisis del Sistema de Información (ASI)
Diseño del Sistema de Información (DSI)
Construcción del Sistema de Información (CSI)
Implantación y Aceptación del Sistema de Información (IAS)

Mantenimiento del Sistema de Información (MSI)

Procesos que hay que estudiar

Análisis del Sistema de Información

Obtener una especificación detallada del SI que se plasmará en un catálogo de requisitos.

Los productos generados en este proceso son: el catálogo de requisitos, el glosario y el contexto del sistema.

Diseño del Sistema de Información

Definición de la arquitectura del SI, del entorno tecnológico que le va a dar soporte y la especificación detallada de sus componentes.

Se generan las especificaciones de construcción, la descripción técnica del plan de pruebas, la definición de los requisitos de implantación y el diseño de los procedimientos de migración y carga inicial.

Construcción del Sistema de Información

Generar el código de los componentes del SI, desarrollar los procedimientos de operación y seguridad y elaborar los manuales de usuario final.

Implantación y Aceptación del Sistema de Información

Entrega y aceptación del sistema en su totalidad, y realización de todas las actividades necesarias para el paso a producción.

ANALISIS DEL SISTEMA DE INFORMACION

1. Objetivo del proceso de Análisis de Sistema de Información (ASI):

- La obtención de una especificación detallada del sistema que satisfaga las necesidades de información de los usuarios y sirva de base para el posterior diseño del sistema.

2. Qué tipo de desarrollos contempla Métrica 3:

- Estructurados.

- Orientados a objetos.

3. La técnica de Casos de Uso se utiliza en el:

- Análisis orientado a objetos.

- Análisis estructurado.

4. ¿Cuáles son los principales productos de un proceso de análisis estructurado?

- Modelo de procesos.

- Modelo conceptual de datos.

- Modelo lógico de datos.

- Especificación de interfaz de usuario

DISEÑO DEL SISTEMA DE INFORMACIÓN

1. Objetivo del proceso de Diseño de Sistema de Información (DSI):

- Definir la arquitectura del SI, el entorno tecnológico que le va a dar soporte y la especificación detallada de sus componentes.

2. Los productos generados en el DSI son:

- Especificación de Construcción.

- Descripción Técnica del Plan de Pruebas.

- Definición de los Requisitos de Implantación.

- Diseño de los Procedimientos de Migración y Carga Inicial (si procede).

3. Los objetivos que se persiguen con la actividad “Diseño de la Arquitectura de Módulos del Sistema” (DSI 5) son:

- Realizar el diseño detallado de la interfaz de usuario.

- Concretar las interfaces entre módulos de cada subsistema, entre subsistemas y con el resto de sistemas.

- Definir los módulos del sistema de información, identificando los procesos que se van a implementar en cada subsistema específico.

4. Las tareas que hay que llevar a cabo para cumplir los objetivos de la actividad DSI 7 “Verificación y aceptación de la arquitectura del sistema” son:

- Verificación de la calidad técnica de cada modelo o especificación.

- Asegurar la coherencia entre los distintos modelos.

- Aceptación del diseño de la arquitectura por parte de los responsables de Explotación y Sistemas.

5. Los objetivos a cumplir de la actividad Especificación Técnica del Plan de Pruebas (DSI 10) son:

- Determinar los Conocimientos o Aptitudes adicionales que requieren los usuarios finales para operar con el nuevo sistema.

- Completar la Planificación de las Pruebas (determinando los distintos perfiles implicados en su preparación, ejecución y evaluación de resultados).

- Diseño Detallado de los Niveles de Prueba especificados en el proceso de Análisis del Sistema de Información (ASI).

- Definir con precisión las verificaciones a realizar sobre el sistema conforme a los niveles de prueba establecidos.

CONSTRUCCION DEL SISTEMA DE INFORMACION

1. Objetivo del proceso de Construcción del Sistema de Información (CSI)

- Generar código de componentes del SI.

- Elaborar los procedimientos de operación y seguridad.

- Elaborar manual de usuario final

2. Tareas de la actividad CSI 1 “Preparación del Entorno de Generación y Construcción”:

- Implantación de la Base de Datos Física o Ficheros.

- Preparación del entorno de Construcción.

3. La generación del código correspondiente a cada uno de los componentes del sistema de información se realiza a partir de la información del proceso:

- Diseño del Sistema de Información (DSI).

4. Objetivos de las Pruebas Unitarias:

- Comprobar que la estructura de cada uno de los componentes del Sistema de Información es la correcta y que se ajustan a la funcionalidad establecida

5. Objetivos de las Pruebas de Integración:

- Verificar si los componentes o subsistemas interactúan correctamente a través de sus interfaces internas

- Verificar si los componentes o subsistemas interactúan correctamente a través de sus interfaces externas.

- Verificar si los componentes o subsistemas cubren la funcionalidad establecida.

- Verificar si los componentes o subsistemas se ajustan a los requisitos especificados.

6. ¿Qué participantes NO intervienen en la actividad CSI 5 “Ejecución de las Pruebas del Sistema”?

- Técnicos de Sistemas

- Técnicos de comunicaciones

- Equipo del proyecto

- Analistas

7. Según la actividad CSI 8 “Construcción de los Componentes y Procedimientos de Migración y Carga inicial de Datos”, ¿qué acción es necesaria antes de llevar a cabo la generación de código?

- Preparación de la infraestructura tecnológica necesaria para realizar la codificación

IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA

1. Objetivo principal del proceso de Implantación y Aceptación del Sistema (IAS):

- Entrega y aceptación del sistema en su totalidad para realizar el paso a producción.

2. En la actividad IAS1 “Establecimiento del plan de implantación”:

- Se revisa la estrategia establecida en el proceso Estudio de Viabilidad del Sistema.

3. Aspectos considerados dentro del Plan de Formación del Equipo de Implantación en la actividad IAS 2 “Formación Necesaria para la Implantación”:

- Esquema de formación.

- Materiales de formación.

- Recursos de formación.

- Planificación de la formación.

4. Productos obtenidos en la actividad IAS 4 “Carga de datos al Entorno de Operación”:

- Bases de datos / Ficheros cargados.

5. Participantes de las actividades de Pruebas de Implantación y Pruebas de Aceptación del SI:

- Jefes de Proyectos.

- Responsables de implantación.

- Usuarios expertos.

- Directores de los usuarios.

6. ¿Qué afirmaciones son ciertas sobre la figura del Responsable de Mantenimiento del sistema?:

- Forma parte del equipo de implantación.

- Recibe una formación adecuada para adquirir una visión global del sistema.

- Analiza en detalle el sistema que va a implantar.

- Valora si la información disponible es suficiente para abordar el futuro mantenimiento del sistema.

- Lleva a cabo las pruebas de implantación.

7. Objetivos de la actividad IAS 8 “Establecimiento de Acuerdo de Nivel de Servicio”:

- Determinar los servicios que requiere el sistema.

- Especificar los niveles de servicio con los que se va a valorar la calidad del servicio.

- Definir los compromisos que se adquieren con la entrega del sistema.

8. Una vez efectuadas las pruebas de implantación y aceptación como paso previo a la puesta en producción, la aprobación del SI es formalizada por:

- Comité de Dirección

METRICA ES FÁCIL (V 2.0)

Intro

Comenzamos comentando que salvo un par de ellas, todas las preguntas aparecieron en el examen parcial del tercer trimestre, aunque la mayoría no de forma literal.

4. ¿Cuáles son los principales productos de un proceso de análisis estructurado?

- Modelo de procesos.

- Modelo conceptual de datos.

- Modelo lógico de datos.

- Especificación de interfaz de usuario.

6. ¿Qué participantes NO intervienen en la actividad CSI 5 “Ejecución de las Pruebas del Sistema”?

- Técnicos de Sistemas

- Técnicos de Comunicaciones

- Equipo del Proyecto

- Analistas

Y si nos localizamos el cuadro resumen de la actividad CSI 5, nos encontramos con lo siguiente:

Tarea		Productos	Técnicas y Prácticas	Participantes
CSI 5.1	Preparación del Entorno de las Pruebas del Sistema	- Entorno de Pruebas del Sistema		- Técnicos de Sistemas - Técnicos de Comunicaciones - Equipo de arquitectura - Equipo del Proyecto
CSI 5.2	Realización de las Pruebas del Sistema	- Resultado de las Pruebas del Sistema	- Pruebas del Sistema	- Equipo del Proyecto
CSI 5.3	Evaluación del resultado de las Pruebas del Sistema	- Evaluación del Resultado de las Pruebas del Sistema		- Analistas - Jefe de Proyecto

Lo que viene a decir que nos aprendamos las respuestas a modo de dogma de fe y que la suerte esté presente durante el examen.

Procesos Principales

El proceso de desarrollo del SI a su vez se descompone en otros 5 procesos, 4 de los cuales sería conveniente memorizar en el caso de pretender aprobar la parte dedicada a Métrica del examen.

Planificación del Sistema de Información (PSI)
Desarrollo del Sistema de Información

Estudio de Viabilidad del Sistema (EVS)
Análisis del Sistema de Información (ASI)
Diseño del Sistema de Información (DSI)
Construcción del Sistema de Información (CSI)
Implantación y Aceptación del Sistema de Información (IAS)

Mantenimiento del Sistema de Información (MSI)

Procesos que hay que estudiar

Análisis del Sistema de Información

Obtener una especificación detallada del SI que se plasmará en un catálogo de requisitos.

Los productos generados en este proceso son: el catálogo de requisitos, el glosario y el contexto del sistema.

Diseño del Sistema de Información

Definición de la arquitectura del SI, del entorno tecnológico que le va a dar soporte y la especificación detallada de sus componentes.

Construcción del Sistema de Información

Generar el código de los componentes del SI, desarrollar los procedimientos de operación y seguridad y elaborar los manuales de usuario final.

Implantación y Aceptación del Sistema de Información

Entrega y aceptación del sistema en su totalidad, y realización de todas las actividades necesarias para el paso a producción.

ANALISIS DEL SISTEMA DE INFORMACION

1. Objetivo del proceso de Análisis de Sistema de Información (ASI):

- La obtención de una especificación detallada del sistema que satisfaga las necesidades de información de los usuarios y sirva de base para el posterior diseño del sistema.

2. Qué tipo de desarrollos contempla Métrica 3:

- Estructurados.

- Orientados a objetos.

3. La técnica de Casos de Uso se utiliza en el:

- Análisis orientado a objetos.

- Análisis estructurado.

4. ¿Cuáles son los principales productos de un proceso de análisis estructurado?

- Modelo de procesos.

- Modelo conceptual de datos.

- Modelo lógico de datos.

- Especificación de interfaz de usuario.

DISEÑO DEL SISTEMA DE INFORMACIÓN

1. Objetivo del proceso de Diseño de Sistema de Información (DSI):

- Definir la arquitectura del SI, el entorno tecnológico que le va a dar soporte y la especificación detallada de sus componentes.

2. Los productos generados en el DSI son:

- Especificación de Construcción.

- Descripción Técnica del Plan de Pruebas.

- Definición de los Requisitos de Implantación.

- Diseño de los Procedimientos de Migración y Carga Inicial (si procede).

3. Los objetivos que se persiguen con la actividad “Diseño de la Arquitectura de Módulos del Sistema” (DSI 5) son:

- Realizar el diseño detallado de la interfaz de usuario.

- Concretar las interfaces entre módulos de cada subsistema, entre subsistemas y con el resto de sistemas.

- Definir los módulos del sistema de información, identificando los procesos que se van a implementar en cada subsistema específico.

4. Las tareas que hay que llevar a cabo para cumplir los objetivos de la actividad DSI 7 “Verificación y aceptación de la arquitectura del sistema” son:

- Verificación de la calidad técnica de cada modelo o especificación.

- Asegurar la coherencia entre los distintos modelos.

- Aceptación del diseño de la arquitectura por parte de los responsables de Explotación y Sistemas.

5. Los objetivos a cumplir de la actividad Especificación Técnica del Plan de Pruebas (DSI 10) son:

- Determinar los Conocimientos o Aptitudes adicionales que requieren los usuarios finales para operar con el nuevo sistema.

- Completar la Planificación de las Pruebas (determinando los distintos perfiles implicados en su preparación, ejecución y evaluación de resultados).

- Diseño Detallado de los Niveles de Prueba especificados en el proceso de Análisis del Sistema de Información (ASI).

- Definir con precisión las verificaciones a realizar sobre el sistema conforme a los niveles de prueba establecidos.

CONSTRUCCION DEL SISTEMA DE INFORMACION

1. Objetivo del proceso de Construcción del Sistema de Información (CSI)

- Generar código de componentes del SI.

- Elaborar los procedimientos de operación y seguridad.

- Elaborar manual de usuario final

2. Tareas de la actividad CSI 1 “Preparación del Entorno de Generación y Construcción”:

- Implantación de la Base de Datos Física o Ficheros.

- Preparación del entorno de Construcción.

3. La generación del código correspondiente a cada uno de los componentes del sistema de información se realiza a partir de la información del proceso:

- Diseño del Sistema de Información (DSI).

4. Objetivos de las Pruebas Unitarias:

- Comprobar que la estructura de cada uno de los componentes del Sistema de Información es la correcta y que se ajustan a la funcionalidad establecida

5. Objetivos de las Pruebas de Integración:

- Verificar si los componentes o subsistemas interactúan correctamente a través de sus interfaces internas

- Verificar si los componentes o subsistemas interactúan correctamente a través de sus interfaces externas.

- Verificar si los componentes o subsistemas cubren la funcionalidad establecida.

- Verificar si los componentes o subsistemas se ajustan a los requisitos especificados.

6. ¿Qué participantes NO intervienen en la actividad CSI 5 “Ejecución de las Pruebas del Sistema”?

- Técnicos de Sistemas

- Técnicos de comunicaciones

- Equipo del proyecto

- Analistas

- Preparación de la infraestructura tecnológica necesaria para realizar la codificación

IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA

1. Objetivo principal del proceso de Implantación y Aceptación del Sistema (IAS):

- Entrega y aceptación del sistema en su totalidad para realizar el paso a producción.

2. En la actividad IAS1 “Establecimiento del plan de implantación”:

- Se revisa la estrategia establecida en el proceso Estudio de Viabilidad del Sistema.

3. Aspectos considerados dentro del Plan de Formación del Equipo de Implantación en la actividad IAS 2 “Formación Necesaria para la Implantación”:

- Esquema de formación.

- Materiales de formación.

- Recursos de formación.

- Planificación de la formación.

4. Productos obtenidos en la actividad IAS 4 “Carga de datos al Entorno de Operación”:

- Bases de datos / Ficheros cargados.

5. Participantes de las actividades de Pruebas de Implantación y Pruebas de Aceptación del SI:

- Jefes de Proyectos.

- Responsables de implantación.

- Usuarios expertos.

- Directores de los usuarios.

6. ¿Qué afirmaciones son ciertas sobre la figura del Responsable de Mantenimiento del sistema?:

- Forma parte del equipo de implantación.

- Recibe una formación adecuada para adquirir una visión global del sistema.

- Analiza en detalle el sistema que va a implantar.

- Valora si la información disponible es suficiente para abordar el futuro mantenimiento del sistema.

- Lleva a cabo las pruebas de implantación.

7. Objetivos de la actividad IAS 8 “Establecimiento de Acuerdo de Nivel de Servicio”:

- Determinar los servicios que requiere el sistema.

- Especificar los niveles de servicio con los que se va a valorar la calidad del servicio.

- Definir los compromisos que se adquieren con la entrega del sistema.

8. Una vez efectuadas las pruebas de implantación y aceptación como paso previo a la puesta en producción, la aprobación del SI es formalizada por:

- Comité de Dirección

“POSIBLES” PREGUNTAS MÉTRICA 3.0

1. La estructura de Métrica V3:

Fases, Actividades y Tareas.
Procesos, Actividades y Tareas.
Procesos, Fases y Tareas.

2. Métrica V3 divide los procesos principales en:

Planificación, Estudio de Viabilidad y Desarrollo.
Análisis, Diseño y Construcción.
Planificación, Desarrollo y Mantenimiento.

3. Objetivos del Proceso de Diseño del Sistema de Información (DSI):

Obtención de un marco de referencia para el desarrollo de Sistemas de Información que responda a los objetivos estratégicos de la organización.
Definir la arquitectura del SI, el entorno tecnológico que le va a dar soporte y la especificación detallada de sus componentes.
Ambas son correctas.

4. Los productos generados en el proceso DSI:

Especificación de construcción y Descripción Técnica del Plan de Pruebas.
La elaboración del Modelo de Datos.
Ambas son correctas.

5. Los objetivos perseguidos en la actividad DSI 5 “Diseño de la arquitectura de módulos del Sistema”:

Definir los módulos del SI, identificando los procesos que se van a implementar en cada Subsistema específico
Las especificaciones necesarias para la definición y creación de los elementos del modelo físico de datos.
Aceptar el Diseño de la Arquitectura por parte de los responsables de Explotación y Sistemas.

6. Las tareas que hay que llevar a cabo para cumplir los objetivos de la actividad DSI 7 “Verificación y Aceptación de la Arquitectura del Sistema”:

Asegurar la coherencia entre los distintos modelos.
Aceptación del Diseño de la Arquitectura por parte de los responsables de Explotación y Sistemas.
Ambas son correctas.

7. Los objetivos de la actividad DSI 10 “Especificación Técnica del Plan de Pruebas”:

Definición detallada del entorno necesario para la realización de las pruebas.
Diseño detallado de los niveles de prueba especificadas en el proceso ASI.
Ambas son correctas.

8. Objetivos del proceso de Construcción del Sistema de Información (CSI):

Generar código de componentes del SI y elaborar los procedimientos de Operación y Seguridad.
Elaborar Manual de Usuario final.
Ambas son correctas.

Las tareas de la actividad CSI 1 “Preparación del Entorno de Generación y Construcción”:

Implantación de la BD Física o Ficheros.
Generación del código de componentes.
Preparación del entorno de pruebas unitarias.
Objetivos de Pruebas Unitarias:

Comprobar que la estructura de cada componente del SI es la correcta y se ajusta a la funcionalidad establecida.
Verificar que todos los componentes o subsistemas interactuan correctamente.
Ambas son correctas.
La generación de código correspondiente a cada uno de los componentes del SI se realiza a partir de la información del Proceso:

ASI (Análisis del Sistema de Información).
DSI (Diseño del Sistema de Información).
IAS (Implantación y Aceptación del Sistema).
Objetivos de Pruebas de Integración:

Verificar si los componentes o subsistemas interactúan correctamente a través de sus interfaces internas.
Verificar si los componentes o subsistemas interactúan correctamente a través de sus interfaces externas, cubren la funcionalidad establecida y se ajustan a los requisitos especificados.
Ambas son correctas.
No participan en la actividad CSI 5 “Ejecución de Pruebas del Sistema”:

Usuarios.
Analistas.
Jefe de Proyecto.
Objetivo principal del Proceso de Implantación y Aceptación del Sistema (IAS):

Estudiar la visión de los usuarios previa a la entrega del Sistema.
Entrega y Aceptación del Sistema en su totalidad para realizar el paso a producción.
Ambas son correctas.
En la actividad IAS 1 “Establecimiento del Plan de Implantación”:

Se revisa la estrategia establecida en el Proceso de Estudio de Viabilidad del Sistema.
Se revisa la estrategia establecida en el Proceso de Análisis del Sistema de Información.
Se revisa la estrategia establecida en el Proceso de Diseño del Sistema de Información.
Los aspectos considerados en la actividad IAS 2 “Formación necesaria para la Impantación”:

Recursos de Formación.
Planificación de la Formación.
Ambas son correctas.
Los productos obtenidos en la actividad IAS 4 “Carga de Datos al Entorno de Operación”:

Código Fuente del Sistema.
Resultados de las Pruebas de Aceptación.
BD y/o Ficheros.
Participan en las Pruebas de Implantación y Aceptación del Sistema:

Analistas.
Jefe de Proyecto.
Consultores.
La figura del Responsable de Mantenimiento:

Forma parte del Equipo de Implantación.
Lleva a cabo las Pruebas de Implantación.
Ambas son correctas.
Objetivos de la actividad IAS 8 “Establecimiento del Acuerdo de Nivel de Servicio”:

Definir los compromisos que se adquieren con la entrega del Sistema.
Planificar Pruebas de Mantenimiento.
Ambas son correctas.
Una vez efectuadas las Pruebas de Implantación y Aceptación como paso previo a la puesta en producción, la aprobación del SI es formalizada por:

Jefe de Proyecto.
Responsable de Implantación.
Comité de Dirección

RESPUESTAS

1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21
b	c	b	a	a	c	b	c	a	a	b	c	b	b	a	c	c	b	c	a	c

SISTEMAS DE GESTIÓN DE BASES DE DATOS - BREATHE

DEFINICIONES

Diseño LÓGICO de los datos: apariencia que presentan los datos almacenados en un ordenador. (Cómo se ven).
Diseño FÍSICO de los datos: forma en que los datos son guardados en un soporte de almacenamiento.
FICHEROS:

-De DATOS: estructura de almacenamiento de los datos a manejar.

-De PROGRAMAS: estructura de almacenamiento del código del programa.

Sistemas de gestión (de la información) basados en ficheros: sistema que gestiona la información almacenándola en ficheros de datos y de programas. (Bastante obvio).
Sistema de gestión de Base de Datos: sistema que gestiona la información en un tipo de almacenamiento único o “Base de Datos”. (Obvio tb)

SISTEMAS TRADICIONALES DE FICHEROS Y SITEMAS DE BASES DE DATOS

Sistemas de FICHEROS

Los datos se recogen varias veces “Redundancia” Malgasta recursos y crea divergencias en los resultados.
Énfasis en los tratamientos (por ello se conoce estos sistemas como “orientados hacia el proceso”). Las aplicaciones son independientes unas de otras Los datos NO se transfieren entre ellas = los datos se duplican.
Se repiten los mismos controles y operaciones en los distintos ficheros Ocupación inútil de memoria secundaria y aumento de los tiempos de proceso.
Dependencia respecto al soporte físico Falta de flexibilidad y adaptabilidad respecto a cambios.
Incapacidad de tener un auténtico SI orientado a la toma de decisiones, o de realizar demandas inesperadas de información.

Sistemas de BASES DE DATOS

Los datos son recogidos y almacenados UNA SÓLA vez.
Independencia de los datos respecto a los tratamientos. Y vicersa.
Los datos son guardados y organizados en un conjunto estructurado que tiende a satisfacer las necesidades de TODA la organización.

COMPONENTES PRINCIPALES DE UN SISTEMA DE BASES DE DATOS

INFORMACIÓN: debe estar integrada, compartida e interrelacionada.

...”Integrada” (consistir en una unificación de muchos archivos sin redundancia).

...”Compartida” (que varios usuarios puedan acceder simultáneamente a la BD = “concurrencia”)

...”Interrelacionada” (que las tablas estén relacionadas entre sí).

HARDWARE (equipo físico)
SOFTWARE (equipo lógico o programas)
USUARIOS:

Administradores:
Adm. De empresa (se encarga del modelo conceptual y lógico)
Adm. De la BD (diseño físico)
Adm. De aplicaciones (vistas o esquemas externos)

Programadores: escriben los programas.
Usuarios finales: utilizan los programas para acceder a la BD.

El éxito o fracaso de las BBDD está condicionado por “el uso que sepamos hacer de ellas”.

VENTAJAS E INCONVENIENTES DE LAS BASES DE DATOS

VENTAJAS

Independencia de los datos respecto a los tratamientos y viceversa.
Coherencia de los resultados: la información de la BD se recoge UNA SÓLA vez en los tratamientos se usan los mismos datos.
Mejor disponibilidad de los datos para el conjunto de usuarios: los datos se COMPARTEN entre el conjunto de aplicaciones. TRANSPARENCIA respecto a la información (todos los datos están relacionados en un diccionario ampliamente difundido y accedido).
Mayor valor informativo: debido a que se recogen las interrelaciones entre los datos el valor informativo del conjunto (es mayor que) el valor informativo de los elementos individuales.
Mejor y más normalizada documentación de la información, la cual está integrada con los datos: en la misma BD se incluyen los datos y la semántica de los mismos.
Mayor eficiencia en la recogida, validación e introducción de los datos en el sistema: no existen redundancias los datos se recogen y validan UNA SÓLA vez.
Reducción del espacio de almacenamiento: desaparición (o disminución) de redundancias y técnicas de compactación.

INCONVENIENTES

Instalación costosa: (coste equipo físico + equipo lógico)
Personal especializado: son imprescindibles conocimientos para una utilización correcta y eficaz, especialmente para el diseño y la administración.
Implantación larga y difícil.
Falta de rentabilidad a corto plazo: debido al coste en personal y al tiempo que tarda el sistema en estar operativo.
Escasa estandarización.
Desfase entre teoría y práctica: (avance de la teoría en relacción con la práctica).

Las BD NO constituyen sólo una nueva tecnología Nacen de una CONCEPCION DISTINTA del SI.

DEFINICION DE BASE DE DATOS OFRECIDA POR INMA EL 21 DE ENERO

“Colección de datos integrados, almacenados en un sistema de soporte secundario, con redundancia controlada. Los datos que van a ser tratados por distintas aplicaciones han de mantenerse independientes. Además de los datos la base de datos ha de recoger las interrelaciones entre estos. De igual forma, deben recogerse las restricciones”.

CARACTERÍSTICAS COMUNES DE LAS DEFINICIONES DE BASES DE DATOS

Conjunto de datos almacenados en un soporte NO volátil.
Deben recogerse las interrelaciones y restricciones semánticas entre los datos.
Redundancia controlada.
La BD debe servir al conjunto de la organización (`a toda la empresa').
Independencia física y lógica entre datos y tratamientos.
Definición o descripción de los datos (“metadatos”), única e integrada con los datos.
Actualización y recuperación de datos mediante procesos bien determinados.

DEFINICIÓN DE SISTEMA DE GESTIÓN DE BASE DE DATOS (SGBD)

Def: “conjunto de programas que permiten la implantación, acceso y mantenimiento de la BD”.

Def 2: “conjunto de programas, procedimientos, lenguajes, etc. Que permiten a los usuarios describir y manipular los datos de la BD garantizando su seguridad.

Sistema de BD = SGBD + BD + Usuarios.

NIVELES DE ABSTRACCIÓN EN UN SISTEMA DE INFORMACIÓN

Estructura lógica (vista del usuario).
Estructura física (forma en que se encuentran los datos en el almacenamiento).

NIVELES DE ABSTRACCIÓN EN UNA BASE DE DATOS

Estructura lógica de usuario (esquema externo): = “visión que de la BD tiene un usuario en particular”. Deben reflejarse SÓLO los datos en interrelaciones que necesite el correspondiente usuario.
Estructura lógica global (esquema conceptual): = “visión global de los datos”. Debe reflejar TODOS los datos e interrelaciones entre éstos, además de las restricciones de integridad y confidencialidad. * (esquema intermedio entre la parte física y lógica de usuario)
Estructura física (esquema interno): = “Forma en que se organizan los datos en el almacenamiento físico”. Deben especificarse en este nivel: la estrategia de almacenamiento, los caminos de acceso y (otros detalles) relacionados con el almacenamiento en el soporte físico.

EL SGBD COMO INTERFAZ ENTRE EL USUARIO Y LA BASE DE DATOS

El SGBD debe suministrar la interfaz entre el “conjunto de datos y usuarios” para los tres niveles de gestión de la empresa: operativo, táctico y estratégico.

TIPOS DE USUARIOS IMPLICADOS EN EL SGBD

Usuarios informáticos
Diseñadores
D. Lógicos: identifican los datos que han de estar contenidos en la BD de acuerdo con las necesidades de los usuarios, y definien las estructuras lógicas adecuadas. Persiguen: la “eficacia de la BD”.
D. Físicos: transforman las estructuras lógicas en estructuras físicas.

Administradores: se encargan de la VIGILANCIA y GESTION de los datos. Objetivos:

Que los datos no se destruyan ni se contaminen.
Impedir consultas o actualizaciones NO autorizadas.
Proteger la BD contra fallos.
Establecer el sistema de autorizaciones de acceso.

Analistas y programadores:

Análisis y programación de tareas que no pueden llevar a cabo los usuarios finales.
Desarrollar procedimientos y programas para facilitar el trabajo de los usuarios finales.

Usuarios finales
Habituales: realizan CONULTAS y ACTUALIZACIONES. Utilizan menús que suelen haber sido desarrollados por los analistas y programadores.
Esporádicos: similar a los `usuarios habituales', pero hacen un uso esporádico (lógicamente) de la BD.

FUNCIONES ESENCIALES DE UN SGBD

DESCRIPCIÓN (o definición)

Llevada a cabo por el diseñador de la BD. Esta función se encarga de...

Especificar los elementos de datos.
Especificar la estructura de los datos.
Especificar las relaciones entre los datos.
Indicar las validaciones (reglas de integridad semántica).

MANIPULACIÓN

CONSULTA

Total: recuperar TODOS los datos o TODOS los de un determinado TIPO.
Selectiva: recuperar los registros que cumplan una determinada CONDICIÓN.

ACTUALIZACIÓN

Inserción: incluir NUEVOS ELEMENTOS.
Borrado: ELIMINACIÓN de elementos.
Modificación: (modificación de los datos) = `cambios en los registros'.

La manipulación se lleva a cabo mediante un Lenguaje de Manipulación de Datos (LMD).

CONTROL

Proporciona...

...a los USUARIOS INTERFACES para comunicarse con la BD.

...al ADMINISTRADOR un CONJUNTO de PROCEDIMIENTOS.

LENGUAJES DE LOS SGBD

LENGUAJES, SEGÚN EL TIPO DE USUARIO QUE LOS EMPLEA

Destinados a USUARIOS INFORMÁTICOS.
Destinados a USUARIOS FINALES.
Para APLICACIONES FORMALIZABLES: (Ej: gestión de personal). Normalmente el programador escribe los correspondientes programas o se usan paquetes soportados por el SGBD.
Para APLICACIONES NO FORMALIZABLES: (Ej: procesos de toma de decisiones). En estos casos es conveniente que el usuario final resuelva la consulta mediante los instrumentos del SGBD.

LENGUAJES DE DATOS SEGÚN EL TIPO DE FUNCIÓN

Lenguajes de DEFINCION de datos (LDD):

Debe permitir al administrador DEFINIR las distintas estructuras; para ello se cuenta con los siguientes lenguajes:

Lenguaje de definición de la estructura lógica global.
Lenguajes para la definición de la estructura interna.
Lenguaje de definición de estructura externa.

Lenguajes de MANIPULACIÓN de datos (LMD):

Lenguaje HUESPED:

PROCEDIMENTAL.
NO CONVERSACIONAL (“diferido” = por lotes)
NAVEGACIONAL (actúa `registro a registro')

Un lenguaje “huésped” se encuentra embebido en un lenguaje de programación (como por ejemplo C) al que se denomina “anfitrión”.

Lenguaje AUTOCONTENIDO:

NO PROCEDIMENTAL.
CONVERSACIONAL (interactivo)
NO NAVEGACIONAL (trata CONJUNTOS de registros)

Suele consistir en menús interactivos con especificaciones sencillas. NO necesitan el apoyo de ningún tipo de lenguaje anfitrión. Están destinados especialmente a los usuarios finales NO informáticos.

LENGUAJES DE CUARTA GENERACIÓN (L4G)

Los L4G generan de manera automática un L3G (C, Pascal, Cobol...) con el código necesario para una aplicación que trabajará con la BD. Prácticamente la totalidad de los SGBD disponen de L4G.

RELACION ENTRE EL SGBD Y EL SO

¡!!!En este punto, volvamos a recurrir a las fotocopias que todos hemos de tener. Concretamente a las páginas 35 y 36.

ALMACENES DE DATOS

DICCIONARIO DE DATOS: guarda las características de los datos a nivel lógico. (Descripción comprensible para el usuario).
DIRECTORIO DE DATOS: facilita el paso de los datos, representados de forma lógica, a su almacenamiento en un soporte físico.

Diccionario activo: depende el diccionario de datos del directorio de datos.
Diccionario pasivo: NO depende el diccionario de datos del directorio de datos.

ENCICLOPEDIA: almacena todas las tareas llevadas a cabo durante el ciclo de vida.
DICCIONARIO DE RECURSOS DE INFORMACIÓN (DRI): aúna el diccionario de datos y el directorio de datos. Posee toda la información de la empresa, permitiendo integrar toda la estructura del SI de la empresa (operativo, táctico y estratégico)

INTERFACES DEL DRI CON LOS COMPONENTES DEL SISTEMA

Con las herramientas CASE: actúa como almacén de datos donde se recoge toda la información que se va generando a lo largo del ciclo de vida del sistema.
Con los generadores de informes y pantallas: almacena las descripciones.
Con los L4G: fuente de información para estos lenguajes. Proporciona las descripciones necesarias para programar en dichos lenguajes.
Con los programas: es la fuente de datos de éstos (similar a la relación con los L4G).
Con utilidades de usuario: contribuye a que se presenten interfaces amigables para facilitar las consultas al sistema.
Con el SGBD y el SO: se pueden considerar éstos como servidores del DRI, puesto que dan soporte a su funcionamiento.

PROTECCION DE DATOS

SEGURIDAD

Objetivo: proteger la BD contra fallos. Los principales tipos de fallos son:

Los que provocan la pérdida de memoria volátil (la RAM).
Los que provocan la pérdida de memoria secundaria.

Transacciones:

Su cometido es asegurar que la BD quede en un estado consistente.
Es una “secuencia de operaciones que han de ejecutarse de forma atómica” (o se realizan TODAS O no se realizan NINGUNA).
Si las transacciones son finalizadas con éxito se graban. Por el contrario, si fallan ha de restaurarse el estado de la BD antes de que comenzara la transacción.
Los SGBD suelen incorporar sentencias para la gestión de transacciones.
El método más extendido para anular y recuperar transacciones es el uso de un FICHERO DIARIO (fichero “log”).

FICHERO LOG:

En él se guarda la información necesaria para “deshacer”, en el caso de fracasar, o “rehacer”, en el caso de recuperar las transacciones.
Durante un fallo que de lugar a pérdida de memoria volátil, se lleva a cabo la RECUPERACIÓN EN CALIENTE (se consulta el fichero “log” para determinar las transacciones que hay que deshacer porque no han sido completadas y cuáles hay que rehacer porque, pese a haber sido completadas, no se grabaron antes de producirse el fallo. Para evitar tener que recorrer el archivo “log” completo, se utilizan los CHECKPOINTS (Páginas 41 y 42).

OTROS SISTEMAS PARA GARANTIZAR LA SEGURIDAD:

Si se produce un fallo de memoria que afecte a la BD se utiliza una copia de seguridad de la base (RECUPERACION EN FRÍO).
Otro sistema para recuperar datos ante un fallo es utilizar la técnica de PÁGINAS OCULTAS (recuperación en caliente). Esta técnica consiste en disponer de dos tablas, en una se van efectuando y grabando los cambios mientras en la segunda se mantiene el estado original. Si todo va bien, se graba la primera tabla, desechando la segunda. En caso de fallo se recuperan los datos almacenados en la segunda tabla.

INTEGRIDAD

Objetivo: proteger la base contra operaciones que produzcan inconsistencias en los datos.

Operaciones que atentan contra la integridad de la BD:

Operaciones semánticas inconsistentes: (las que violan las restricciones semánticas impuestas por el administrador).
Interferencia por accesos concurrente: (fallos provocados por el acceso simultáneo de varios usuarios a los mismos datos).

CONFIDENCIALIDAD

Objetivo: proteger la BD de accesos NO autorizados.

La protección debe incluir a datos, interrelaciones, esquemas, programas, etc.

“POSIBLES” PREGUNTAS SGBD

1. El concepto de BD tiene que ver con:

Colección o depósito de datos almacenados en un soporte informático no volatil, interrelacionados y estructurados de acuerdo a un modelo capaz de recoger el máximo contenido semántico.
Redundancia de datos controlada, independencia de datos con respecto a tratamientos, así como la posible atención a múltiples usuarios y distintas aplicaciones.
Ambas son correctas.

2. El lenguaje de manipulación de datos:

Medio para describir las tres estructuras de datos (interno, externo y lógico global).
Mandatos en lenguaje huésped o autocontenido que permite tanto la recuperación como la actualización de datos.
Ambas son correctas.

3. Los niveles de abstracción de una BD:

Estructura Lógica de Usuario y Estructura Lógica Global.
Estructura Física.
Ambas son correctas.

4. Lenguaje Huésped:

Mandatos en un LMD (Lenguaje de Manipulación de Datos).
Lenguaje de programación donde se insertan mandatos de un LMD.
LMD que no necesita apoyarse en ningún otro lenguaje.

5. Lenguaje Anfitrión:

Mandatos en un LMD (Lenguaje de Manipulación de Datos).
Lenguaje de programación donde se insertan mandatos de un LMD.
LMD que no necesita apoyarse en ningún otro lenguaje.

6. Lenguaje Autocontenido:

Mandatos en un LMD (Lenguaje de Manipulación de Datos).
Lenguaje de programación donde se insertan mandatos de un LMD.
LMD que no necesita apoyarse en ningún otro lenguaje.

7. Los Lenguajes de Cuarta Generación (L4G):

Generadores de Aplicaciones para BD.
Generadores de Informes para BD.
Ambas son correctas.

8. La función de descripción de la Estructura Lógico Global de una BD:

Usuarios Informáticos.
Usuarios no Informáticos.
Usuarios Administradores.

9. La Integridad de los Datos:

Proteger la BD contra fallos lógicos, físicos o humanos que provoquen la pérdida total o parcial de datos.
Proteger la BD contra operaciones que introduzcan inconsistencia en los datos.
Proteger la BD contra accesos no autorizados.

10. La Seguridad de los Datos:

Proteger la BD contra fallos lógicos, físicos o humanos que provoquen la pérdida total o parcial de datos.
Proteger la BD contra operaciones que introduzcan inconsistencia en los datos.
Proteger la BD contra accesos no autorizados.

11. La Confidencialidad de los Datos:

Proteger la BD contra fallos lógicos, físicos o humanos que provoquen la pérdida total o parcial de datos.
Proteger la BD contra operaciones que introduzcan inconsistencia en los datos.
Proteger la BD contra accesos no autorizados.

12. Diccionario de Recursos de Información (DRI):

Núcleo de una arquitectura de datos integradora.
Contiene la descripción de todos los datos de un SI.
Ambas son correctas.

RESPUESTAS

1	2	3	4	5	6	7	8	9	10	11	12
c	b	c	a	b	c	c	c	b	a	c	c

MODELO DE DATOS - BREATHE

MODELO DE DATOS - INTRO

Definiciones.
Distinciones.

DEFINICIONES

“Modelar”: definir un mundo abstracto y teórico que coincidirá con las manifestaciones aparentes del mundo real.
“Modelo de datos.def 1”: mecanismo de abstracción que permite ver la información contenida en los datos (no los valores de los datos, sino el significado de esos valores).
“Modelo de datos.def 2”: instrumento que se aplica a una parcela del mundo real (“Universo de Discurso” - UD) para obtener una estructura de datos (“esquema”).
“Modelo de datos.def 3”: conjunto de conceptos, reglas, convenciones y restricciones que permiten describir el UD.

DISTINCIONES

Modelo - Esquema.
Mundo Real - UD.

Modelo - Esquema:

El Modelo es el instrumento, conjunto de reglas, conceptos, convenciones, etc; y Esquema es el resultado de aplicar el modelo al UD.

Mundo Real - Universo de Discurso:

El UD es la visión que el diseñador tiene del mundo real. (Por lo tanto, lo primero en la concepción de la BD es definir el UD, fijando una serie de objetivos sobre el mundo real a analizar).

MODELO DE DATOS - OBJETIVOS

Formalización.
Diseño.

FORMALIZACIÓN

Consiste en definir la estructura y restricciones para representar los datos del sistema de información que se recogerán en la base de datos.

DISEÑO

Permite, junto a los lenguajes, documentación y otras herramientas, desarrollar una metodología para diseñar la BD.

MODELO DE DATOS - DEFINICIÓN FORMAL

Propiedades.
Estática.
Dinámica.

PROPIEDADES

Todo modelo de datos se define formalmente como el par.

Propiedades Estáticas: estructuras que se corresponden con el lenguaje de definición de datos (LDD). Son relativamente invariables en el tiempo.
Propiedades Dinámicas: datos o valores almacenados en las estructuras. Se corresponden con el Lenguaje de Manipulación de Datos (LMD). Varían con el tiempo.

Mod = < E, D >

Modelo de datos = < Parte Estática, Parte Dinámica >

COMPONENTE ESTÁTICA

Objetos permitidos.
Objetos no permitidos.

Objetos permitidos :

Entidades: objeto sobre el que queremos guardar información en la BD.
Atributos: propiedades de las entidades.
Dominios: rango de valores que puede tomar cada atributo.
Interrelaciones: asociaciones entre entidades.

Objetos NO permitidos (“restricciones”) :

Inherentes: restricciones impuestas por la propia naturaleza del modelo. (Ej: NO se puede dibujar en el grafo E/R las entidades dentro de corazoncitos por muy insulso que nos parezca el rectángulo clásico. Ejemplo gráfico abajo).

De Usuario: restricciones que permiten captar la semántica del UD que se modela:

Controlados por el SGBD. (Ej: rango DÍA comprendido entre 1-31).
Responsabilidad del usuario. (by el Andrés: “…cuando escribe cosas raras…”).

COMPONENTE DINÁMICA

Componente dinámica: “definición de una serie de operaciones sobre el esquema”.
Ocurrencia del esquema: “valores que toma un objeto del esquema en un momento dado”.

Empleado sueldo	(( gana ))
Juan 6000 €	OCURRENCIA

Posibles operaciones sobre el esquema :

Selección: busqueda de un conjunto de ocurrencias que tienen uno o varios campos comunes.
Acción: se realiza sobre las ocurrencias previamente seleccionadas. Pueden ser recuperaciones de datos o actualizaciones (altas, bajas y modificaciones).

MODELO DE DATOS - TIPOS DE MODELOS DE DATOS

ANSI.
Alternativa.

CLASIFICACION DE MODELOS DE DATOS SEGÚN ANSI

Modelos lógicos.
Modelos físicos.

Modelos lógicos :

“Pretenden representar los aspectos lógicos de los distintos tipos de datos del UD”.

Modelos lógicos Externos:

Se utilizan en la construccion de esquemas externos (vistas de usuario).
Persigen la eficiencia humana.

Modelos lógicos Globales:

Se utilizan en la construccion de los esquemas lógicos globales.
Persigen la eficiencia en los recursos de información de la organización.

Modelos físicos :

Sirven para construir el esquema físico.
Persiguen la eficiencia en los recursos informáticos.

CLASIFICACION ALTERNATIVA DE MODELOS DE DATOS

Modelos lógicos.
Modelos físicos (no varía respecto a ANSI).

Modelos lógicos :

Modelos lógicos CONVENCIONALES

(red, jerárquico y relacional)

Modelos lógicos CONCEPTUALES

Implementados en el SGBD.
Dependen del SGBD.
Más próximos al ordenador.
Poca capacidad semántica.
Más enfocado a la implementación.
Interfaz informático/sistema.

No implementados en el SGBD.
No dependen del SGBD.
Mayor nivel de abstracción.
Mayor capaciadad semántica.
Más enfocados al diseño.
Interfaz informático/usuario.

MODELO DE DATOS - ARQUITECTURA DE COEXISTENCIA

By Bruce: apartado de relleno que viene a decir que los 3 modelos de datos convencionales se diferencian en la forma de representar las relaciones entre entidades y en la forma de acceso a la BD. Todos tienen sus ventajas e inconvenientes, habiendo defensores de cada uno de ellos.

“POSIBLES” PREGUNTAS MODELO DE DATOS

1. Modelo de Datos:

Visión que tiene un desarrollador del mundo real.
Instrumento que se aplica a una parcela del mundo real para obtener una estructura de datos.
Resultado obtenido al aplicar a un universo de discurso un conjunto de reglas, conceptos, convenciones, etc.

2. Todo modelo de datos se define formalmente como el par:

Propiedades estáticas y dinámicas de un UD.
Modelo de datos más una sintaxis.
Ambas son correctas.

3. La componente estática de un modelo de datos:

Conjunto de operaciones (selección y acción) que se define sobre una estructura de datos.
Está compuesta por objetos permitidos y restricciones.
Ambas son correctas.

RESPUESTAS

1	2	3
b	a	b

Información

Personal

Equipo

OBJETIVOS

Procedimientos y practicas de trabajo

- Diseño detallado del software:

- Diseño de la arquitectura del software: se transforman los requisitos en una arquitectura o estructura de alto nivel que identifique los componesntes principales.

- Análisis de requisitos del software: establecer y documentar requisitos.

- Diseño de la arquitectura del sistema: identificar principales componentes del hardware, el software y operaciones del sistema.

- Análisis de requisitos del sistema:

TAREAS

- P. D DESARROLLO:

- P. D SUMNISTRO: tareas del suminsitrador. Primero se toma la decisión de preparar la propuesta que responda a la petición del comprador o se firma el contrato paraproporcionar el producto software.

- Codificadión y prueba del software: se desarrollan y documentan los componentes del software y las bases de datos para después probarlos.

- P. D ADQUISICIÓN: tareas que el comprador, cliente o usuario lleva a cabo para adquirir el sistema o producto.

PROCESOS PRINCIPALES: Útiles para las personas implicadas en el Ciclo de Vida

- Integración del software:

- Prueba del software:

- Integración del sistema: integrar los elementos del software y el hardware junto con las operaciones manuales.

- Prueba del sistema:

- Instalación del software en el entorno:

- Soporte del proceso de adaptacón del soft: el desarrollador debe apoyar la revisión de aceptación y la prueba del software por parte del comprador.

- P. D EXPLOTACIÓN: explotación del software y soporte operativo a los usuarios. Las actividades y tareas del procesose aplican al sistema completo.

- P. D MANTENIMIENTO: aparece cuando el software necesita modificaciones (de código o de documentación). Su objetivo es modificar el software existente manteniendo la consistecia.

…para:

- Identificar, definir y establecer la línea base de los elementos de configuración del sistema.

- Controlar las modificaciones y las versiones de los elementos.

- Registrar e informar sobre el estado de los elementos y las peticiones de modificación.

- Asegurar la compleción, la consistencia y la corrección de los elementos.

- Controlar el almacenamiento, la manipulación y la entrega de los elementos.

- P. D GESTIÓN D CONFIGURACIÓN:

Aplica procedimientos administrativos y técnicas para…

- P. D ASEGURAMIENTO D LA CALIDAD: aporta confianza en qué procesos y productos software cumplen los requisitos especificados y se ajustan a los planes establecidos.

- P. D VERIFICACIÓN: determian si los requisitos del sistema y los requisitos del software cumplen los requisitos especificados y se ajustan la los planes establecidos.

- P. D VALIDACIÓN: determian el sistema o software dinal cumple los requisitos previstos.

- P. D REVISIÓN CONJUNTA: evaluar el estado del software y sus productos en una actividad del Ciclo de Vida o una fase de un proyecto.

- P. D AUDITORÍA: determinar si se han cumplido los requisitos, los planes y el contrato.

- P. D RESOLUCIÓN DE PROBLEMAS: analizar y eliminar los problemas descubiertos en el desarrollo, la explotación, el mantenimiento u otro proceso.

PROCESOS DE SOPORTE: Sirven de apoyo al resto. Se aplican a cualquier punto del ciclo de vida.

- P. D DOCUMENTACIÓN: registra la información producida por un proceso o una actividad del ciclo de vida.

PROCESOS GENERALES (o Procesos de la Organización): ayudan a establecer, implementar y mejorar la organización.

- P. D GESTIÓN: actividades y tareas para gestionar los procesos de la organización.

- P. D INFRAESTRUCTURA: establece la infraestructura necesaria para cualquier otro proyecto.

- P. D MEJORA: establecer, valorar, mdedir, controlar y mejorar los procesos del ciclo de vida del software.

- P. D FORMACIÓN: (formación del personal).

PROCESO D ADAPTACIÓN: para realizar la adaptación básica de la norma ISO 12207-1 con respecto a los proyectos software.

Según ENFOQUE

FORMALES

NO FORMALES

Según FORMALIDAD

DE GESTIÓN

DE TIEMPO REAL

ESTRUCTURADO

Según el tipo de SISTEMA

ORIENTADO A OBJETOS

Orientadas a PROCESOS

Orientadas a DATOS

MIXTAS

NO Jerárquicos

Jerárquicos

1. EJECUTAR

3. PRUEBAS ADICIONALES

3. EVALUAR RESULTADOS

2. COMPROBAR SI TERMINÓ LA PRUEBA

Doc. de ENTRADA: (especificaciones de casos y procedimientos de prueba que se van a usar)

Doc. de SALIDA:

Informe de Incidente: documenta cada incidente ocurrido en la prueba y que requiera una posterior investigación.

Histórico de Pruebas: documenta todos los hechos relevantes ocurridos durante la ejecución de las pruebas.

Informe Resumen de Pruebas: resume los resultados de las actividades de prueba y aporta una evaluación del software..

Imp. D

Imp. E

Imp. F

Imp. G

Imp. E

Imp. F

Programa

Cálculo

Imprimir

Lerr-Reg

Prima-Dir

Prima-No-Dir

EMPLEADO

PROYECTO

TRABAJA

- Info

- Hardware

- Software

- Usuarios

- Administradores

- Programadores

- Usuarios finales

El Administrador debe especificar

- Correspondencias entre esquemas

- Caminos de acceso

- Dispositivos de memoria

- Organizaciones físicas

- Diseñadores (lógicos y físicos)

- U. informáticos

- Administradores

- Analistas y programadores

- Habituales

- Esporádicos

- U. finales…….

- DESCRIPCIÓN

- MANIPULACIÓN

- Inserción

- Total

- Selectiva

- CONSULTA…….

- Borrado

- ACTUALIZACIÓN

- Modificación

- CONTROL

- L. de MANIPULACIÓN

- L. de DEFINICIÓN

- CONFIDENCIALIDAD.…(accesos NO autorizados)

- SEGURIDAD……………..(fallos)

- INTEGRIDAD……………(incosistencias)

Farmacia

Almacén

tiene

- MODELOS LÓGICOS

- MODELOS FÍSICOS

- Globales

- Externos

- ANSI

- MODELOS LÓGICOS

- MODELOS FÍSICOS

- Concecptuales

- Convencionales

- Alternativa

Tal vez te pueda interesar:

Descargar

Enviado por:	Bruce
Idioma:	castellano
País:	España

Palabras clave:

Datos Información Equipo Tecnología Empresa Ventas Comercialización Vendedores Costes Restricciones Prototipo

Te va a interesar