CAPITULO I : INTRODUCCI N A LOS S.I. EL CONCEPTO DE SISTEMA Definiciones. Elementos. Relaciones. Enfoque Sistmico.

mico. DEFINICIONES - Sistema : Concepto o herramienta genrica para analizar el funcionamiento de un rea. - Sistema (segn 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. Lmites del sitema. (Frontera entre el sistema y el entorno) REALCIONES DEL SISTEMA Entre componentes: permiten considerarlo como 1 unidad. Aseguran su cohesin. Con el exterior. (Entradas y salidas del sistema) ENFOQUE SIST MICO U HOL STICO Manera de estudiar o analizar sistemas mediante una visin global y refinamientos sucesivos (descomposicin de arriba-abajo: Top-down). 1. Se toma todo el sistema como una caja negra de la que slo 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 fcilmente Muy til en aplicaciones de software grande. EL CONCEPTO DE INFORMACI N Diferencia entre dato e informacin Calidad de Informacin Propiedades de la calidad de informacin DIFERENCIA ENTRE DATO E INFORMACI N Datos: se constituyen por registros de los hechos, acontecimientos, transacciones 1

 Informacin: datos procesados. Son tiles o significativos para el receptor. Se consideran los datos como la materia prima para obtener informacin. Procesar = indicar el significado de los datos. Procesar = dar significacin a un dato en un contexto. CALIDAD DE INFORMACI N Conjunto de cualidades que disminuyen la incertidumbre y ayudan al receptor a tomar la decisin ms ventajosa. PROPIEDADES DE LA CALIDAD DE INFORMACI N Relevante para el el propsito de la decisin o el problema considerado Precisa (exacta con la realidad). Que se pueda confiar en ella. No existe la `precisn absoluta'. Suficientemente completa para el problema. Lo ideal es contar con toda la informacin relevante. Lo ms importante es que la informacin sobre los elementos clave sea completa. Se comunica a la persona adecuada para la decisin. Se comunica a tiempo para que pueda ser til. Llega al nivel de detalle ms 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 Informacin Elementos de un S.I. Estructura de un S.I. Flujos de informacin en una empresa Tecnologas de la Informacin Otros conceptos FUNCIONES DE LA INFRAESTRUCTURA DE UNA EMPRESA Controlar y Gestionar recursos (funcin o sistema contable y de gestin econmica). Comercializar (Actividad comercial y de ventas) Fabricar servicios o crear productos (Produccin) DISTINTAS ESTRUCTURAS EN LAS EMPRESAS (Mariconadas) Por funciones y departamentos. Control y Gestin. Comercio. Produccin. Por localizacin geogrfica. Por jerarqua y niveles de actuacin. DEFINICIONES DE SI Las definiciones ms 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 coleccin de datos estructurada segn las necesidades de la empresa) que recopilan, elaboran y distribuyen la informacin necesaria para llevar a cabo las operaciones de empresa y las actividades de direccin y control. Def 02 (by Inma) : El sistema encargado de coordinar los flujos y los registros de informacin necesarios para desarrollar una actividad de acuerdo a su estrategia o planteamiento. ELEMENTOS DE UN S.I. Procedimientos y prcticas habituales de trabajo. Informacin. Personas o usuarios. Equipo de soporte (parte fsica: papel, mquina de escribir, ordenadores) La informacin de un S.I. puede ser informal o formal: Informacin formal: la informacin fsica. De la que tenemos constancia y podemos confiar en ella. Informacin informal: (Ej.) rumores, dilogos personales I ESTRUCTURA DE UN S.I. Operaciones y transacciones: se encarga del procesamiento de actividades diarias o transacciones (acontecimientos rutinarios: pagos, facturacin). Las transacciones constituyen la mayor parte de las actividades que se realizan en la empresa. Caractersticas 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 Direccin: analizar los resultados (usualmente respecto a los recursos: diner, tiempo) consumidos en las transacciones para tomar decisiones a corto plazo. Normalmente suele trabajar con informacin del registro de transacciones. Caractersticas de la informacin empleada: Repetitiva (informes peridicos de ventas, pagos) Centrada en el pasado (resultados histricos) Con datos originados internamente Datos con formato bien estructurado Datos detallados y precisos. Nivel tctico de direccin: asignacin efectiva de recursos a medio plazo (se suele actuar con un ao de antelacin), para mejorar el rendimiento de la empresa. Tipos de informes anailizados Resmenes con medias estadsticas. De excepciones (departamentos que han consumido ms de la media, centros con prdidas) Especficos (informes que no se han pedido antes y que los directivos necesitan 3

urgentemente para resolver problemas muy concretos) Se trabaja con el propsito de descubrir algo nuevo en los datos. Nivel Estratgico de Direccin: pretende decidir las pautas a seguir por la empresa en el futro (plazos largos: 3-5 aos). La informacin que maneja ha de tener un formato muy resumido para lograr predecir lo mejor para el xito futuro de la compaa. 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. Carcter histrico y de orientacin al pasado. Flujos verticales descendentes: (jefe subordinado). rdenes y solicitudes especficas. Flujos horizontales: (entre personas del mismo nivel). Al contenido de esta informacin se le llama informacin de coordinacin. 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 informacin. OTROS CONCEPTOS (MIS) Sistema de informacin para la Gestin: proporcionan a los directivos informacin y ayuda para decisiones `estructuradas'. Es la parte del S.I. dediacada al nivel operativo tctico y estratgico. (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. Seala 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 descomposicin de arriba abajo. Se denomina tambin Botton-Up y consiste en dividir el sistema en subsistemas considerndolos cajas negras de las que lo que ms nos interesa es su interior. Es una filosofa de anlisis y diseo que permite descomponer un trabajo complicado en tareas de programacin ms sencillas. 2. Cul de las siguientes caractersticas no forma parte de la calidad de informacin?: 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 ms adecuado, para que esta persona pueda decidir con dicha informacin. Debe ser fiable y comprensible.

 Cul de las siguientes afirmaciones es correcta? Los flujos de informacin 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. Cul 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 informacin puramente manuales. Un S.I. No tiene por qu estar totalmente automatizado. Cabe distinguir entre S.I., S.I.A. y Sistema Informtico de Soporte. Cul 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 informacin si disminuye nuestro nivel de incertidumbre. La informacin debe ser tratada siempre informticamente. En exmenes anteriores Los principales elementos que encontramos en cualquier sistema: Componentes, relaciones que determinan la estructura y objetivos. Objetivos, lmites y estructura. Componentes, relaciones y entorno. Indica cules son los elementos de un S.I.: Los procedimientos y prcticas de trabajo, los objetivos y las relaciones. Los procedimientos y prcticas de trabajo, la informacin, las personas y el equipo de soporte. Los objetivos, la informacin y los procedimientos y prcticas de trabajo. Cul de las siguientes afirmaciones no es correcta?: Las prcticas de trabajo determinan la informacin que se necesita en un S.I. Los objetivos de la empresa determinan las prcticas de trabajo. La informacin determina las carctersticas del equipo Humano del S.I. Cul de las siguientes afirmaciones es correcta?: La informacin debe ser tratada siempre informticamente. Un dato es informacin si disminuye nuestro nivel de incertidumbre. El nico objetivo de una empresa es ganar dinero. La tcnica de anlisis de sistemas: Estudia todas sus entradas. Sigue un enfoque sistmico. 5

 Estudia el sistema adoptando una visin parcial del mismo hasta llegar a su visin global. La estructura de un S.I.: Se puede describir mediante una pirmide en la que se distingue la jerarqua de diversos niveles de actuacin y gestin. Se puede describir mediante un grafo de niveles segn una organizacin geogrfica. Se puede describir mediante un organigrama segn departamentos o funciones. CAPITULO II : SISTEMAS DE INFORMACI N BSICOS EN LAS EMPRESAS SUBSISTEMA DE RECUROS HUMANOS ACTIVIDADES Plantilla Nmina Mantenimiento de datos de los empleados Inventario de cualificaciones de empleados Inventario de puestos de trabajo y condiciones Evaluacin de empleados Generacin de informes Gestin de solicitudes de empleo Envo de instrucciones de pago de salarios Perfil de la persona ideal PRO puesto de trabajo Necesidades de contratacin de personal Generar planes PRO incentivos y beneficios a empleados Anlisis de necesidades de informacin y creacin de planes para mejorar el nivel tctico-profesional de la plantilla Crear planes para mejorar la infraestructura de la empresa

NIVEL OPERATIVO

NIVEL TCTICO

NIVEL ESTRAT GICO TECNOLOG AS DE LA INFORMACI N

Realizacin de nminas mediante aplicaciones de trabajo por lotes Gestin de personal mediante tratamientos interactivos Proteccin de datos mediante control de acceso SUBSISTEMA DE CONTABILIDAD Y FINANZAS ACTIVIDADES Llevar la contabilidad Control de activos fijos Gestin de cobros Gestin de pagos Control de inventario Ejecucin de nmina Generacin de informes Gestin y control de presupuestos Informacin sobre el flujo de caja Controles de planes de gasto de capital

NIVEL OPERATIVO

NIVEL TCTICO

NIVEL ESTRAT GICO TECNOLOG AS DE LA INFORMACI N

Trabajo de forma interactiva Trabajo con gran volumen de datos

Automatizacin de transacciones Gestin econmica mediante (grandes) bases de datos Anlisis financieros mediante simulaciones muy elaboradas Anlisis estadstico SUBSISTEMA COMERCIAL Y DE VENTAS Gestin y tratamiento de pedidos Facturacin Control de detalles de entrega y actualizacin de inventario Informacin de ventas Investigacin de mercados Informes tcnicos de produccin Datos sobre la capacidad financiera de la empresa Gestin de carteras de clientes Control de contactos con clientes Consultas sobre productos Informacin sobre crdito o consideracin econmica de cliente Facilidades para la gestin de pedidos y facturas Control de envos Recepcin Devoluciones

Ventas

Comercializacin

ACTIVIDADES

NIVEL OPERATIVO

Apoyo a vendedores

Gestin de distribucin de productos

NIVEL TCTICO

Recogida de informacin de ventas Gestin y control del marketing Establecimiento de precios Decidir la mejor forma de distribucin Anlisis de competidores Dividir mercado

NIVEL ESTRAT GICO

 Seleccionar segmentos a acceder Planificar productos y servicios a ofertar Predecir ventas a trabajar Pedidos y facturacin mediante aplicaciones de trabajo por lotes TECNOLOG AS Gestin comercial mediante grandes bases DE LA de datos INFORMACI N Anlisis de mercado mediante simulaciones complejas y anlisis estadsticos SUBSISTEMA DE PRODUCCI N ACTIVIDADES NIVEL OPERATIVO Control de existencias almacenadas Compras de materias primas o componentes Recepcin de materias primas o componentes Envo de productos a clientes Gestin y control de materias primas y productos Planificacin de la capacidad de produccin ptima (.) Suelen ser decisiones estratgicas de alta direccin Sistemas de control y automatizacin de produccin

NIVEL TCTICO NIVEL ESTRAT GICO TECNOLOG AS DE LA INFORMACI N RESPUESTAS 1 c 2 a 3 c

4 b

5 c

6 a

7 b

8 c

9 b

10 b

11 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 informtico. en que se definan los procesos, las actividades y las tareas a desarrollar. DEFINICIONES Segn IEE 1074: El Ciclo de Vida es una aproximacin lgica a la adquisicin, el suministro, el desarrollo, la explotacin y el mantenimiento del software.

 Segn 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 explotacin y el mantenimiento de un producto software, abarcando la vida del sistema desde la definicin de requisitos hasta la finalizacin de su uso. El Ciclo de Vida abarca toda la vida del sistema (desde su concepcin hasta que ya no se utiliza). PROCESOS DEL CICLO DE VIDA DEL SOFTWARE Procesos Principales. Procesos de Soporte. Procesos Generales. Proceso de Adaptacin.

MODELO EN CASCADA Caractersticas. Crticas. 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 tcnico y los usuarios pueden pueden revisar el progreso del proyecto. Es el Ciclo de Vida ms antiguo y el ms 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 ). Acenta 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 aadiendo componentes funcionales al sistema (incrementos). En cada paso se actualiza el sistema. El sistema software acaba siendo la integracin de los resultados sucesivos (obtenidos despus de cada iteracin).

 Se ajusta a entornos de alta incertidumbre. CR TICAS Cuenta con el problema de que es difcil determinar si los requisitos propuestos son vlidos Los errores en los requisitos son detectados tarde y su correccin es costosa. MODELO EN ESPIRAL Caractersticas. 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 revisin. DIFERENCIAS RESPECTO A LOS MODELOS TRADICIONALES Reconocimiento explcito de diferentes alternativas para lograr los objetivos del proyecto. Identificacin de riesgos asociados a las alterntivas y la manera de resolverlos (centro del modelo). Divisin 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 subcontratacin de software. Necesidad de expertos en evaluacin 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 ningn estndar que describa sus procesos y actividades. No es slo realizar el anlisis, diseo, codificacin y pruebas; tambin incluye entre otros, procesos de soporte. El Mantenimiento son las actividades para mantener sin cambios el sistema. En la actividad de Anlsis de los Requisitos del Software, los desarrolladores obtienen de los futuros usuarios los requisitos que piden al sistema. En exmenes anteriores El Ciclo de Vida del software: Es un marco de referncia comn para las personas que participan en el desarrollo 10

informtico. Se definen slo los mtodos a desarrollar. Empieza en el anlisis 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 organizacin. La norma de ISO al respecto agrupa los procesos principales en adquisicin, suministro, desarrollo, explotacin y mantenimiento. La norma de ISO al respecto agrupa los procesos generales en adquisicin, suministro, desarrollo, explotacin y mantenimiento. En cuanto a los modelos del Ciclo de Vida: Las normas no fomentan ni especifican ningn 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 evaluacin de riesgos. Los siguientes factores influyen a la hora de elegir un ciclo de vida: La estreucturacin del sistema, la familiaridad con la tecnologa a usar. La norma estndar que se use en el desarrollo. Las prisas que tenga el cliente por tener en marcha la aplicacin. 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 Anlisis de los Requisitos Software, los desarrolladores obtienen de los futuros usuarios los requisitos que piden al sistema. RESPUESTAS 1 c-e 2 a 3 b 4 a 5 a 6 c

Captulo 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 consista en, una vez leda la descripcin de una actividad, indicar la fase o etapa del ciclo de vida con el que se corresponda. 26 cuestiones de las que slo acert 6 en su momento. En su momento. Tambin. Detalle bastante importante: estuvimos comprobando con los apuntes todo el tiempo, lo cual induce a pensar que tampoco debera aparecer una cuestin de este tipo en el examen. De todas formas, para seguir con la buena costumbre de no obviar nada, como este ejercicio `relativamente terico' aparecin en clase, he aqu su correspondiente rplica en el Breathe Proyect 0.2 . E intentando no desviarnos, hacer mencin a que varias de las descripciones Inma las trat como definiciones propiamente dichas de las fases. stas se indican convenientemente.

11

Por fin, sin ms 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 elaboracin de un calendario de ejecucin. Proponer una solucin a corto plazo que tenga en cuenta las restricciones econmicas, tcnicas, legales y operativas. Determinar qu usuarios participan en la obtencin de requisitos. Elaborar un modelo de datos. Identificar servidores, monitores, impresoras que formarn parte del equipo de un SI. Especificar infraestructura tecnolgica necesaria para soportar un SI. Determinar la formacin necesaria para el personal encargado de la implantacin 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 modificacin concreta. Elaborar un modelo de SI vlido que soporte a los procesos de la organizacin. Recogida de requisitos que debe cumplir un software para identificar funcionalidades. Identificar objetivos estratgicos a los que apoya un SI, as como el mbito general de l a organizacin a la que afectar. Especificar los niveles de servicio que se prestarn una vez implantado el SI. Recogida y anlisis 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 metlico como en efectivo. Especificar los requisitos de implantacin de un SI relacionados con la formacin, infraestructura e instalacin. Estudio del SI actual. Identificar los factores crticos para el xito de un SI, as como sus participantes nombrando mximos responsables. Generar un diagnstico estimando la eficiencia de los existentes SI identificando posibles problemas y mejoras. Definir los formatos de pantalla, dilogos e informes. Disear un modelo fsico de datos. Codificar los componentes de un SI a partir de las especificaciones del diseo. Verificar los recursos necesarios disponibles para realizar la instalacin de todos los componentes de un SI. Definir qu compromisos se adquieren con la entrega del SI. Creacin y puesta a punto de Base de Dato. SOLUCIONES 1 Proceso de Adquisicin. 2 Proceso de Suministro. 3 Proceso de Desarrollo - Anlisis de Requisitos del Sistema. 4 Proceso de Desarrollo - Anlisis de Requisitos del Software. 5 Proceso de Desarrollo - Diseo de la Aquitectura del Sistema. 6 Proceso de Desarrollo - Diseo de la Arquitectura del Software. 7 Proceso de Explotacin. 8 Proceso de Explotacin. 9 Proceso de Mantenimiento. 10 Proceso de Adquisicin. 12

11 Proceso de Desarrollo - Anlisis de Requisitos del Sistema. 12 Proceso de Adquisicin. 13 Proceso de Suministro. 14 Proceso de Adquisicin. 15 Proceso de Suministro. 16 Proceso de Desarrollo - Anlisis de Requisitos del Sistema. 17 Proceso de Desarrollo - Diseo de la Arquitectura del Software. 18 Proceso de Adquisicin ( Definicin ). 19 Proceso de Adquisicin. 20 Proceso de Suministro ( Definicin ). 21 Proceso de Desarrollo - Anlisis de Requisitos del Software. 22 Proceso de Desarrollo - Diseo Detallado del Software. 23 Proceso de Desarrollo - Codificacin y Prueba del Sofware. 24 Proceso de Explotacin. 25 Proceso de Suministro. 26 Proceso de Explotacin. CAPITULO IV : METODOLOG AS DE DESARROLLO DE SOFTWARE Conceptos generales. Evolucin histrica. Caractersticas. Clasificacin. Principales metodologas. CONCEPTOS GENERALES Origen. Definiciones. Distinciones. Especificaciones. Necesidades a cubrir. Objetivos. Anexo 0. APARICI N DE LAS METODOLOG AS Las metodologas surgen de la necesidad de unas determinadas reglas fijas a las que ceirse a la hora de desarrollar un software. DEFINICIONES Metodologa: conjunto de pasos y procedimientos para el desarrollo de software. Metodologa: camino para desarrollar software de manera sistemtica. DISTINCIONES Ciclo de Vida: indica QU productos obtengo. Metodologa: indica C MO obtengo los productos.

13

 Mtodo: se aplica a cada fase del ciclo de vida. Metodologa: conjunto de mtodos que se aplican durante todo el ciclo de vida. ESPECIFICACIONES DE UNA METODOLOG A Una metodologa ha de indicar: Cmo se debe dividir un proyecto en etapas. Qu tareas se llevan a cabo en cada etapa. Qu salidas se producen y cundo se deben producir. Qu restricciones se aplican. Qu herramientas se van a utilizar. Cmo 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 ms rpidamente y con los recursos apropiados. - Proceso estndar en la organizacin: (aporta claros beneficios). OBJETIVOS DE LAS METODOLOG AS Registrar los requisitos del S.I de forma adecuada. Proporcionar un mtodo sistemtico 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 fcil de mantener. Ayudar a identificar lo ms 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. Tcnica: se usa para aplcar un procedimiento. Herramienta: se usa para aplicar una tcnica. EVOLUCI N HIST RICA Convencional. Estructurado. Orientado a Objetos. ENFOQUE-DESARROLLO CONVENCIONAL Caractersticas. Problemas. Caracterticas:

14

 Sin metodologas de desarrollo. Distintos papeles: analistas, programadores (funcionales y orgnicos) y operadores. Problemas: Los resultados finales son impredecibles (no se sabe cundo 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. Programacin estructurada. Diseo estructurado. Anlisis estructurado. Conceptos: Se puede considerar el nacimiento de las tcnicas estructuradas como el origen de los desarrollos automatizados. El origen del desarrollo estructurado comenz con la programacin estructurada. Programacin estructurada: Se pretendi que la visin de un programa fuese lo ms comprensible posible. Normas para la aplicacin de las estructuras de datos y control. Diseo estructurado: Se utiliza el mdulo de programa como componente bsico de construccin. Se refina el concepto de modularidad (normalizando la estructura de un mdulo de programa, restringiendo las relaciones entre mdulos y estableciendo medidas en la calidad de los programas). Anlisis estructurado: Conceptos. Diferencias respecto al anlisis clsico. Evolucin. Conceptos: Se conoce tambin como anlisis descendente o top-down. Se utilizaba principalmente en organizaciones de desarrollo de sistemas de gestin. Diferencias respecto al anlis clsico:

Analisis Clsico: 15

 Se haca una especificacin narrativa de los requisitos, tal como los perciba el analista. Las especificaciones contaban con el problema de ser monolticas, redundantes, ambiguas e imposibles de mantener. Analisis Estructurado: Movimiento gradual a las especificaciones funcionales. Las especifiaciones funcionales se caracterizaban por ser: grficas, particionadas y mnimamente redundantes. Evolucin respecto al anlisis estructurado clsico: Dar menor importancia a la construccin de los modelos fsicos actuales y modelos lgicos actuales. Diferenciar ms los modelos fsicos y lgicos. Ampliar las tcnicas de anlisis 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. Caractersticas deseables. INMPACTO DE LA METODOLOG A EN EL ENTORNO DE DESARROLLO La metodologa proporciona CALIDAD y PRODUCTIVIDAD en el desarrollo de software. La metodologa est influenciada por consideraciones como el tamao y la estructura de la organizacin 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 realizacin de verificaciones sobre los productos generados en cada fase para comprobar su correccin. - Planificacin y control: para proporcionar una forma de desarrollar software planificada y controlada, con objeto de que no se disparen costes ni se amplen los tiempos de entrega. - Comunicacin efectiva: para facilitar el trabajo en grupo y con los usuarios. - Utilizacin sobre un abanico amplio de proyectos: la metodologa ha de ser flexible para poder cubrir diverrsos proyectos. - Fcil formacin: los desarrolladores deben comprender las tcnicas y procedimientos de gestin. 16

- 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 reutilizacin del software: incluir procedimientos para la creacin, mantenimiento y recuperacin de los componentes reutilizables (y no slo del cdigo). CLASIFICACI N DE LAS METODOLOG AS Metodologas Estructuradas. Sistemas de Tiempo Real. METODOLOG AS ESTRUCTURADAS Orientadas a procesos. Orientadas a datos. Mixtas. Metodologas Orientadas a procesos: Conceptos. Componentes de una especificacin estructurada. Principales metodologas. Conceptos: Estn basadas en un mtodo descendente (Top-down) de descomposicin funcional, para describir los requisitos del sistema. Se apoyan en tcnicas grficas, dando lugar a un nuevo concepto que es la especificacin estructurada. Componentes de una especificacin estructurada: Diagramas de Flujo de Datos (DFD). Diccionario de Datos. Especificaciones de proceso. Principales metodologas estructuradas: Metodologa de De Marco. Metodologa de Gane y Sarson. Metodologa de Yourdon/Constantine. Metodologas Orientadas a datos: Orientadas a datos jerrquicos. Orientadas a datos no jerrquicos. Metodologas Orientadas a datos jerrquicos: Estudia las entradas y salidas para averiguar qu procesos genera. 17

 La estructura de control del programa debe ser jerrquica y se debe derivar de la estructura de datos del programa. En el proceso de diseo: 1. Se definen las estructuras de los datos de entrada y salida, 2. se mezclan todas en una estructura jerrquica de programa, 3. se ordena detalladamente la lgica procedimental para que se ajuste a esa estructura. El diseo lgico debe preceder y estar separado del fsico. Metodologas Orientadas a datos NO jerrquicos: Se considera a los datos como el ncleo del SI. Con este enfoque, todos los sistemas construdos estn integrados sobre un mismo modelo de datos. Metodologas Mixtas: No se referencian en el libro. SISTEMAS DE TIEMPO REAL Conceptos. Caractersticas. Requisitos. Conceptos: Son sistemas muy dependientes del tiempo. Procesan informacin ms orientada al control que a los datos. Son controlados por eventos externos. Hay que distinguir entre sistemas en tiempo real y sistemas en lnea. Los sistemas interactivos (en lnea) interactan con personas mientras que los sistemas en tiempo real interactan con personas y dispositivos fsicos externos. Caractersticas: Se lleva a cabo el proceso de muchas actividades simultneamente (concurrencia). Se asignan prioridades a determinados procesos. Se interrumpe una tarea antes de que concluya para comenzar otra de mayor prioridad. Existe comunicacin entre tareas (resultado tarea nueva tarea). Acceso simultneo a datos comunes (en memoria y en almacenamiento secundario). Requisitos: Manejo de inetrrupciones. Comunicacin y sincronizacin 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. 18

 M TRICA. METODOLOG A MERISE Francesa Ciclo de vida ms largo que los existentes anteriormente. Introduccin de dos ciclos complementarios: de abstraccin y de decisin. METODOLOG A SSADM Inglesa. nfasis en los usurios: sus requisitos y su participacin. Definicin del proceso de produccin: qu hacer, cundo y cmo. Tres puntos de vista: datos, eventos y procesos. Mxima flexibilidad en herramientas y tcnicas de implementacin. NO cubre aspectos como la planificacin estratgica ni la construccin de cdigo. METODOLOG A M TRICA Espaola. Objetivo: crear un marco metodolgico comn para la palnificacin y desarrollo de la Administracin Pblica Espaola. Se enfoca directamente al desarrollo. El libro hace referencia a la versin 2.0 de M TRICA, por tanto es absolutamente improbable que Inma pregunte algo de lo que en ste se describe (exceptuando cualquier cuestin relativa los tres puntos anteriores). As que FIN! POSIBLES PREGUNTAS CAP TULO III 1. El anlisis estructurado se diferencia del clsico en: Emplear un mtodo de particionamiento efectivo. Construir un modelo lgico del sistema. Definir los procesos. Definir las lneas de diseo. 2. En el anlisis estructurado: El texto se introduce en todos los detalle inmediatamente. Se va de lo abstracto al detalle, es grfico y unidimensional. Se usa un mtodo para particionar exclusivamente problemas complejos. Ninguna de las anteriores. 3. Una metodologa es un conjunto de componentes que especifican: Cmo se debe dividir un proyecto en etapas y las tareas de cada etapa. Qu estndares se van a utilizar en el desarrollo. El modelo de ciclo de vida a utilizar. RESPUESTAS

19

1 2 a d CAPITULO V : GESTI N DE PROYECTOS SOFTWARE Definicin de proyecto. Planificacin. PLANIFICACI N - CONCEPTOS GENERALES Plan de Proyecto. Gestin de Compromisos. Conceptos. Caractersticas del Plan de Proyecto. Elementos del proyecto. CONCEPTOS GENERALES

3 a

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 Gestin de Proyectos aborda distintos aspectos: planificacin, control, direccin y organizacin. 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 Planificacin de proyectos ha de cubrir: la realizacin de un plan de proyecto (por parte del director de proyecto) y, la gestin de compromisos. La funcin principal del director de proyecto es la realizacin del plan de proyecto. CARCTER 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 aprobacin del cliente y adems sea actualizable. ELEMENTOS ESENCIALES DEL PROYECTO Resumen del proyecto. Comprendido por cualquier persona. Que indique los productos entregables. Lista de hitos alcanzables. Procedimientos y estndares a aplicar. Especificacin del proceso de revisin para determinar `quin', `cmo', `cando' y `para qu' se revisa el proyecto. Plan que defina la comunicacin entre la organizacin de desarrollo y el cliente. Diagrama de descomposicin del trabajo (WBS). Lista del personal del proyecto y asignacin en relacin 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

20

 Plan de desarrollo. Caractersticas de un Programa de Tiempos efectivo. Pasos para la realizacin de un calendario. PLAN DE DESARROLLO El objetivo principal del plan de desarrollo es la configuracin del calendario de proyecto (o programa de tiempos). El calendario de proyecto consiste en una representacin grfica 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 `dinmico' (que pueda variar). CARCTER 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 sealar actividades crticas. Flexible (`fcilmente 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. Definicin 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 revisarn durante el poyecto para sealar 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 finalizacin. De duracin especfica: especificar la duracin de las actividades. 2. Descomposicin de las actividades: Para que el director de proyecto pueda: Aumentar la supervisin de trabajos. Observar el seguimiento de actividades crticas de gran repercusin. 3. Relacin entre las actividades: Deben determinarse las secuencias y dependencias entre las actividades.

21

 4. Estimacin de tiempos y costes de las actividades: 5. Reajuste del programa de tiempos a las restricciones del proyecto: Objetivos principales: Determinar la duracin total del proyecto. Identificar las activiades que contribuyen a la duracin total del proyecto (actividades crticas). Calcular las holguras de las actividades NO crticas. Excepto en proyectos muy sencillos, se hace necesario el uso de herramientas automatizadas que realicen el anlisis de los tiempos de red y la distribucin de los recursos pertinenentes. 6. Asignacin de recursos / Definicin de la organizacin del equipo: Objetivos principales: Ajustar el calendario respecto a los recursos disponibles. Ajustar las fechas de comienzo de algunas actividades NO mcrticas. Suavizar las cargas de trabajo. Ajustar costes al presupuesto. 7. Revisin 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 Es el mtodo ms simple para la realizacin de un calendario. Consiste en un cuadro con dos columnas: en la primera se especifican las actividades y en la segunda las fechas de finalizacin. Ventajas: 22

 Facilidad de uso. Mnimo coste de preparacin. Desventajas: Incertidumbre sobre las fechas de comienzo de las actividades. Imposibilidad de reflejar interrelaciones entre actividades. Actividad Fecha finalizacin DIAGRAMAS DE GANTT

Se usa normalmente para proyectos pequeos (menos de 25 actividades). Es posiblemente el tipo de calendario ms utilizado. No es posible representar dependencias entre actividades. Hace ms 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 duracin (columnas). 1 2 3 4 5 6 7 8 9 10 Tarea1 Tarea2 Tarea3 23

Tarea4 Tarea5 Tarea6 Tarea7 PROGRAMA DE TIEMPOS FULL WALL Parte de una reunin 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 eleccin. Alto grado de interaccin entre los participantes de la reunin. No muestra claridad en los camminos crticos. REDES DE PRECENCIA: PERT Y CPM Conceptos generales. Casos en los que es conveniente su utilizacin. Diferencias. Reglas. Holguras de los diagramas PERT. Conceptos generales: Red: modelo grfico que seala las relaciones secuenciales entre los sucesos clave del proyecto. PERT y CPM pueden mostrar el camino crtico (secuencia ms larga de las actividades conectadas a traves de la red, y que determina la duracin total del proyecto). Para disminuir el tiempo total deben reducirse los tiempos de las actividades dentro del camino crtico. Conviene utilizar las Redes de Precedencia cuando un proyecto: Todas las actividades estn 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 estn ordenadas (de modo que se pueda seguir una secuencia). Una vez comenzada una actividad, debe continuar sin interrupcin hasta su finalizacin. 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 gestin. PERT permite el tratamiento de la probabilidad para la estimacin de tiempos. CPM no.

24

 Reglas en el desarrollo de PERT y CPM: Como mnimo, la red debe poseer 20 eventos Las redes realizadas manualmente deben contar con un mximo de 300 sucesos. Los proyectos que justifican un gran nmero de actividades o eventos poseen las siguientes caractersticas: Muy crticos. Poseen un alto riesgo o incertidumbre. Involucran a muchas personas u organizaciones. Tcnicamente complejos. Con actividad en diversas localidades geogrficas. Holguras de los diagramas PERT: Nmero de unidades de tiempo que un suceso puede retrasar su finalizacin SIN aumentar la duracin Holgura total del proyecto. Nmero de unidades de tiempo que la realizacin de una actividad puede retrasar su finalizacin, Holgura total respecto al tiempo PERT previsto, sin aumantar la duracin total del proyecto. Parte de la holgura total que puede consumirse sin Holgura libre afectar a las actividades siguientes. Cantidad de holgura disponible si todas las Holgura actividades han comenzado en sus `tiempos last'. independiente M TODOS DE ESTIMACI N DE COSTES

Hi = TLi - TEi

HTij = TLj - TEi Tij HLij = TEj - TEi Tij HIij = TEj - TLi - Tij

Todos los metodos de estimacin de costes dependen de la informacin. Los mtodos estn infudos por el tiempo y el sueldo del trabajador.

DINERO (coste del proyecto) estimado por SALARIOS DE LOS TRABAJADORES Opinin de expertos. Estimacin por analoga. Descomposicin. Ecuaciones o modelos de estimacin. Recomendaciones. OPINI N DE EXPERTOS Caractersticas. Tcnicas. 25

 Caractersticas: Muy subjetiva. Permite contemplar simultneamente distintos proyectos anteriores junto con el actual. Tcnicas para sintetizar la Opinin de Expertos: Pasos: Los expertos ofrecen su punto de vista. Se realiza la media de las valoraciones. Se organiza una reunin con el propsito de llegar a un consenso. Delphi: variante que consiste en calcular la media de las valoraciones de `expertos annimos'. La media es devuelta a cada uno de ellos. A continuacin, 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 opinin de expertos. Es difcil conocer el grado de similitud con el sistema a comparar. El tamao del tiempo y el coste del proyecto NO guardan una ecuacin lineal (por lo cual no pueden calcularse mediante la estimacion por analoga). 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 estimacin es personal del responsable de cada componente. Esto la hace ms fiable. No contempla las nuevas actividades que se puedan precisar. ECUACIONES O MODELOS DE ESTIMACI N Consiste en lograr las estimaciones mediante frmulas matemticas. Modelos de coste: estimaciones directas del esfuerzo o de la duracin. Suelen ser X = CTE * Y. Modelos de restricciones: relacionan en el tiempo dos o ms parmetros de coste. ENFOQUE RECOMENDADO Realizar un juicio de expertos mediante Delphi en la negociacin 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 clasificacin de los modelos de estimacin: Modelos empricos: basados en la opinin de expertos y la estimacin tanto Top-Down como Botton-Up, apoyada en datos histricos. Modelos estadsticos (lineales y no lienales): obtenidos mediante el anlisis de regresin estadstica. 26

 Basados en una teora: sobre el esfuerzo de desarrollar software (y comprobaciones de datos) (P ej: SLIM). Modelos compuestos: combinan varias tcnicas (P ej: COCOMO). Sigue la explicacin de cmo realizar los modelos SLIM y COCOMO. Hasta el final del captulo, otros puntos a tener en cuenta son: El enfoque recomendado para la estimacin de costes (4 puntos). Los objetivos que pretende conseguir el seguimiento y la supervisin del proyecto (3 puntos). Las reas de riesgo quedebe tratar un director de proyecto en la gestin de riesgos del software (7 puntos). Inma apenas ha incidido en estos puntos, pero como vienen en el libro, aviso de que estn ah por si acaso. Si nos sobra tiempo y tenemos ganas, nos los miramos tambin. POSIBLES PREGUNTAS CAP TULO V 1. La Gestin 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, segn distintos aspectos como Planificacin, Control, Direccin y Organizacin. Conjunto de personas, entre ellas el jefe de proyecto y desarrolladores que trabajan para obtener un producto software. Planificacin del desarrollo del software en cuanto a funciones que debe realizar. La Planificacin de un Proyecto Software incluye dos aspectos importantes: Plan de Proyecto y Gestin de Compromisos. Plan de Proyecto y Calendario. Calendario y Descomposicin de Trabajos del Proyecto (WBS) Son tcnicas para realizar un calendario: Redes de Precedencia. Diagramas de Gantt y Diagramas de Hitos. Todas son correctas. Las tcnicas de construccin 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 Gestin de Compromisos: Los directivos deben tomar decisiones una vez emitida la opinin del grupo de software. Forma parte de la Estimacin de Costes. Todas son correctas. Los mtodos de Estimacin de Coste: Opinin de Expertos, Estimacin por Analoga y Descomposicin. Ecuaciones o Modelos de Estimacin. Todas son correctas. 27

 La primera versin del Plan de proyecto incluye: Qu, Cmo, Quin y Cundo se hace. Herramientas y Tcnicas de Gestin y de Desarrollo. Todas son correctas. RESPUESTAS 1 a 2 a 3 c 4 b 5 a 6 c 7 c

CAPITULO VI : ANLISIS 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: Decisin de emprender el proyecto. Seleccin del jefe de proyecto (responsable de establecer el entorno inicial de trabajo). Decisin de emprender el proyecto: Orgnes de la idea de emprender un proyecto. Conceptos. Anlisis de Viabilidad. Orgenes de la idea de emprender un proyecto: En el caso de un departamento de desarrollo de la empresa: La constatacin de los requisitos del software est cambiando. Peticin especfica del cliente o usuario. Propuesta desde dentro de la propia organizacin de desarrollo. Necesidad detectada por el departamento de marketing. Recomendacin especfica del presonal de mantenimiento. Detectada a partir de la informacin de los usuarios. Primero se debe obtener una idea clara de lo que se pretende hacer, para despus evaluar la viabilidad del proyecto. En el caso de una empresa de servicios informticos: 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, informacin 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:

28

 Considerar diferentes alternativas que se puedan concebir (comprar un software comercial ya creado, desarollar el producto internamente). Evaluacin de cada alternativa. Especificacin detallada de la alternativa desarrollada. Establecimiento de fechas y compormisos de trabajo por parte de las personas y los departamentos implicados (`definicin de un plan alternativo para el proyecto'). Seleccin del director del proyecto: Conceptos. Caractersticas. Conceptos generales: Normalmente, la eleccin del director de proyecto es posterior la decisin de emprender el proyecto. Seguramente sea el elemento ms crtico de cara a conseguir el xito del proyecto. Carctersticas deseables en un director de proyecto: Liderazgo: habilidad para motivar a los componentes del equipo de proyecto. Comprensin tcnica: conocimientos para tomar las decisiones correctas. Competencia en la gestin: capacidad para controlar las activiades, costes y presupuestos del proyecto. Presteza y decisin: para observar, evaluar y decidir. Versatilidad y flexibilidad: para encauzar acontecimientos imprevistos. Integridad: para reclutar al personal ms adecuado y ganarse la confianza del cliente. Previsin: 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 tcnicas de comunicacin entre miembros. Definir los requisitos que deben cumplir los posibles subcontratistas. Definir la manera de aboradar la interaccin con el cliente. ESTUDIOS DE VIABILIDAD Aspectos a abordar. Anlisis Coste-Beneficio. Aspectos para anlisis coste-beneficio eficaz. ASPECTOS A ABORDAR EN EL ESTUDIO DE VIABILIDAD Econmico: si el beneficio compensa los costes. Tcnico: 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 atencin al anlisis econmico. Sus 29

conclusiones son determinantes para continuar o cancelar el proyecto. ANLISIS COSTE-BENEFICIO Costes. Beneficios. Conceptos. Costes a tener en cuenta: Coste del personal informtico implicado en el proyecto (desde el anlisis hasta la instalacin del sistema). Coste de consultora. Coste de software adicional. Coste de hardware. Coste de infraestructura. Costes debidos al usuario. Costes contnuos: mantenimiento del sistema y alquileres. Beneficios: Nuevas funcionalidades. Eliminacin de errores. Reduccin de errores. Aumento de la velocidad. Aumento de la fiabilidad. Conceptos: Uno de los mayores problemas del anlisis econmico es que ha de ser realista. En la mayora de los casos la valoracin de beneficios es necesariamente subjetiva. ASPECTOS IMPORTANTES PARA QUE EL ANLISIS COSTEBENEFICIO SEA EFICAZ La mayora 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 econmica. Tratar de valorar y prever todos los riesgo. T CNICAS DE RECOGIDA DE INFORMACI N Medio para mejorar la comunicacin entre los usuarios o clientes y los desarrolladores de software. Pasos del proceso de Anlisis. Tcnicas de recogida de informacin. Entrevistas. JAD. Prototipado. PASOS DEL PROCESO DE ANLISIS Identificar fuentes de informacin (usuarios) relevantes para el proyecto. 30

 Realizar preguntas adecuadas para comprender las necesidades. Analizar la informacin recogida para detectar aspectos que quedan poco claros. Confirmar con los usuarios lo comprendido de los requisitos. Sintetizar requisitos en un documento de especificacin apropiado El resultado del proceso debera ser un documento que especifique lo ms claramente posible, los requisitos que debe cumplir el software. T CNICAS PRINCIPALES DE RECOGIDA DE INFORMACI N Quiza la tcnica ms empleada y la que require mayor preparacin por parte del analista. Se crean equipos de usuarios y analistas para determinar las caractersticas que debe tener el software. Desarrollo conjunto Cuenta con una mayor probabilidad de de aplicaciones (JAD) xito, ya que involucra al usuario en el proyecto de modo que lo aprecia como `algo propio'. Construccin de un modelo o maqueta del sistema que permite al usuario Prototipado evaluar mejor las necesidades. Analizar `in situ' cmo funciona la unidad o departamento que se desea Observacin informatizar. Para recoger informacin de un gran Cuestionarios nmero de personas en poco tiempo. Para hacerse una idea sobre la Estudio de normativa que rige la empresa. documentacin Reunin de 4 a 10 personas. Sugieren cualquier idea sin juzgar su validez. Tormenta de ideas Realizan un anlisis detallado de cada propuesta. Para fomentar la perticipacin de usuarios en varios proyectos. Objetivo: satisfacin de los empleados ETHICS en el trabajo, mediante estudios integrales. Entrevistas Es una prctica habitual utilizar combinaciones de distintas tcnicas. LAS ENTREVISTAS Conceptos. Cualidades del entrevistador. Preparacin. Realizacin. Anlisis. Conceptos:

31

 Entrevista: intento sistemtico de recoger informacin de otra persona. La preparacin 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 conversacin. Cualidades del entrevistador: Imparcial. Ponderado. Buen oyente: capaz de escuchar mostrando inters (muy importante). Cierto grado de habilidad en el trato. Cordialidad y accesibilidad. Paciencia. 1. Preparacin: Fase en la que el entrevistador debe documentarse e investigar la situacin de la organizacin. 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 identificacin de personas que se debe entrevistar (para minimizar el nmero necesario de personas a entrevistar). Por ltimo se debe inclur: la preparacin del objetivo y el contenido de la entrevista y, la planificacin 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. Realizacin: La realizacin se considera el ncleo central de la entrevista. Se distinguen tres etapas: apertura, desarrollo y terminacin. Apertura. Desarrollo. Terminacin. Apertura: El entrevistador se presenta e informa al entrevistado sobre la razn de la entrevista. Los primeros minutos son fundamentales para crear un ambiente confortable. La primera impresin en el entrevistado es muy importante. Desarrollo: No debera exceder de 2 horas. Tcnicas durante el desarrollo: Preguntas abiertas en los primeros momentos para proseguir con otras ms directas y cerradas. Utilizar palabras y frases aropiadas (evitando tecnicismos o palabras o frases que puedan perturbar la comunicacin). Asentir mientras se escucha. Repetir respuestas dadas (transmite la sensacin de que el interlocutor atiende y entiende. Esre recurso debe utilizarse moderadamente). 32

 Pausas, para ejercer presin y obligar al entrevistado a hablar. Lo ideal es que el entrevistador hable un 20% del tiempo y el entrevistado un 80%.. Terminacin: Se finaliza recapitulando la entrevista, agradeciendo el esfuerzo al entrevistado y citndolo 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. Anlisis: Leer las notas, reorganizar la informacin, etc Es importante evaluar cmo 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 coperacin y el trabajo en equipo entre los usuarios y los analistas. Consisten en un conjuto de reuniones (2-4 das) en las que participan tanto usuarios cualificados como analistas de software. JAD no se utiliza demasiado debido a que require una mayor preparacin que las entrevistas y el ambiente o los mtodos 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 das. Es ms difcil apreciar los posibles errores en la especificacin de requisitos cuando slo un analista revisa el documento. En el JAD todo el grupo puede actuar como revisor y detectar defectos. JAD propugna una particip cin ms profunda de los usuarios en el proyecto. Proceso tpico JAD: 1.Adaptacin o preparacin Tareas de preparacin de sesin por parte del jefe del JAD: Seleccin de participantes (conjunto lo ms representativo posible). Recabar cierta informacin sobre el sistema a construr. Organizar la reunin. 2. Sesin 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 sesin se habr concludo el documento de especificacin, aprobado por los presentes 33

3.Documentacin Completar el documento final de sesin. EL PROTOTIPADO Conceptos. Casos en los que resulta til. Razones. Herramientas. Conceptos generales: Consiste en la elaboracin 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 construdo ms rpidamente que la aplicacin. Casos en los que resulta ms til: Cuando el rea de aplicacin NO est bien definida. El coste de rechazo de la aplicacin por parte de los usuarios es muy alto. Es necesario evaluar previamente el impacto del sistema en los usuarios y la organizacin. Razones principales para utilizar el prototipado: (Ordenadas por frecuencia de uso). Para asegurarse de que est bien diseada y satisface las necesidades de los usuarios. 1. Prototipado de la No es caro. interfaz de usuario: Muy frecuente. Usualmente consiste en simples modelos de pantallas. 2. Modelos de Para evaluar el posible rendimiento rendimiento: del diseo. Prototipo: primera versin del sistema, con funcionalidad limitada. 3. Prototipado Tras comprobar si las funciones implentadas son apropiadas, se funcional: corrigen, refinan y aaden nuevas hasta obtener el sistema final. Herramientas para la realizacin del prototipado: Nivel inferior herramientas comunes y facilmente disponibles (P ej: programas de dibujo o presentacin, hojas de clculo o generadores de informes. Con stas se consigue que el usuario pueda ver la entrada/salida que se tendr cuando la aplicacin est acabada. Nivel un poco ms evolucionado algunos gestores de bases de datos. Otra opcin 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:

34

 Econmico y Tcnico. 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 : ANLISIS DE SISTEMAS INTRODUCCI N AL ANLISIS DE REQUISITOS Definiciones. Clasificacin de actividades. DEFINICIONES Anlisis (aplicado a sistemas): descomponer el sistema en sus componentes para estudiar cada uno de ellos. Anlisis (aplicado a una fase del ciclo de vida): producir un documento de especificacin de requisitos que describa lo que el futuro sistema debe hacer (pero NO cmo debe hacerlo). Anlisis de Requisitos: proceso del estudio de las necesidades de los usuarios para llegar a una definicin de los requisitos del sistema de hardware o de software. Tambin: 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 especificacin. Para obtener los requisitos se requiere del trabajo conjunto de: suministradores, desarrolladores, clientes y usuarios. CLASIFICACI N DE LAS ACTIVIDADES DEL ANLISIS DE REQUISITOS Segn IEEE 1074. Clasificacin alternativa. Segn el estndar IEEE 1074 Definir los requisitos del software. Definir los requisitos de las interfaces. Integrar los requisitos (en un documento de especificacin) y asignarle prioridades. Otra clasificacin (by RAGHAVAN)

35

Tcnicas que emplean Tcnicas de recogida de informacin ( captulo 6 ) Extraccin o determinacin ( Ej: observacin, de requisitos: cuestionarios, entrevistas) Tcnicas grficas. Modelos competos ( Ej: Anlisis de requisitos: Anlisis Estructurado ) Tcnicas grficas. Modelos competos ( Ej: Especificacin de requisitos: Anlisis Estructurado ) Listas de comprobacin. Validacin de requisitos: Tcnicas de revisin. Estas actividades NO tienen por qu realizarse en secuencia. ESPECIFICACI N DE REQUISITOS DEL SOFTWARE Definiciones. Definiciones ERS. Caractersticas principales. Caractersticas generales. Evolucin. Especificacin de requisitos de interfaces. DEFINICIONES Especificacin: documento que define el diseo, el comportamiento u otras caractersticas de un sistema o componente de un sistema. Software: conjunto de programas, procedimientos y documentacin asociada a la operacin de un sistema informtico. DEFINICIONES DE ERS Def 01: documentacin 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 verificacin y validacin. Def 03: descripcin de `lo que hay que desarrollar', lo cual implica una descripcin correcta de todos los requisitos del software (evitando requisitos innecesarios) y, NO describir ningn detalle del diseo de software (excepto las restricciones del diseo que influyen en los requisitos). Una ERS debe especificar SOLAMENTE `lo que desea el usuario'. CARACTER STICAS FUNDAMENTALES DE UNA ERS Informacin 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

Actividades

36

 No ambigua. Completa. Fcil de verificar. Consistente. Fcil de modificar. Facilidad para identificar el origen y las consecuencias de cada requisito. Facilidad de utilizacin en la fase de explotacin y mantenimiento. No ambigua: Cada requisito ha de tener una nica interpretacin. 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 estndar de especificacin a cumplir. Las figuras, tablas y diagramas han de estar etiquetadas y referenciadas en el texto. By Bruce: A continuacin nos encontramos en el libro con la explicacin de que existe un simptico 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 aaden en las especificaciones cuando llegamos a un punto que an no tenemos claro. Lgicamente nos cuenta que es un recurso `no demasiado elegante' y que cuando nos veamos obligados a usarlo, incluyamos tambin la forma en que pensamos solucionar la situacin en un futuro para as deshacernos del TBD. No creo que vaya a caer en el examen, es una estupidez, as que mencin hecha y seguimos. Fcil de verificar: Cualquier requisito referenciado se pueda verificar fcilmente. Consistente: Ningn conjunto de requisitos han de ser contradictorios o entrar en conflicto. Posibles conflictos: Empleo de distintos trminos para el mismo objeto. Caractersticas de objetos reales entran en conflicto. Conflicto lgico o temporal entre dos acciones determinadas Fcil de modificar: La estructura y el estilo deben permitir que cualquier cambio necesario en los requisitos se pueda realizar fcil, completa y consistentemente. La ERS debe: Tener una organizacin coherente y manejable (con tablas de contenidos, ndices y refernecias cruzadas). No ser redundante (el mismo requisito NO debe aparecer en ms de un lugar de la ERS). 37

 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 documentacin. Referencias recomendas: Referencias hacia atrs: a documentos previos. Referencias hacia delante: a documentos originados a partir del ERS. Fcilidad de utilizacin en la fase de explotacin 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 informacin se dan por supuestos, pero suelen estar ausentes. Objetivos: Ser fcilmente modificable. Prever el registro de las caractersticas especiales de cada componente (su criticidad, su relacin 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 realizarn cambios adicionales como consecuencia de haber encontrado deficiencias. Consideraciones a tener en cuenta en este proceso: El requisito debe ser especificado de la forma ms completa posible (an 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 definicin de las interfaces E/S tiene como objetivo la estabilizacin del modo en que el sistema va a interactuar con el 38

exterior del sistema. Debe contarse adems 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. Segn forma de representacin. Segn enfoque de modelizacin. INTRO No hay un criterio definitivo (trivial) por el que se puedan organizar las tcnicas. CLASIFICACI N SEG N LA FORMA DE REPRESENTACI N Grficas. Textuales. Marcos o plantillas. Matriciales. Grficas: 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 conexin entre los distintos componentes. Se suelen utilizar en combinacin con las dems tcnicas. Textuales: Emplea una gramtica definida (ms o menos formal). Para especificar con ms detalle los componentes definidos en los grficos. Ej: pseudocdigoempleado en las especificaciones de procesos. Marcos o plantillas: ENTIDAD: Estudiante. Se representan mediante un formulario en el que DESCRIPCI N: Un estudiante es cualquier se incluyen todas las caractersticas del persona que est componente por medio matriculada en una de las de campos en el que cada asignaturas ofertadas. entrada puede tener una gramtica particular. ATRIBUTOS: N DNI, apellidos, nombre, Especifican la informacin relativa a direccin provincia, un componente de un telfono. modelo que ha sido declarado en un IDENTIFICADORES: diagrama o en otro N DNI. marco. RESTRICCIONES:

39

VOL. MAX. OCURRENCIAS: 2000. Ejemplo de plantilla de una entidad Matriciales: No se consideran tcnicas de definicin, sino de comprobacin entre modelos. Permiten estudiar referencias cruzadas entre los componentes de los modelos. CLASIFICACI N SEG N EL ENFOQUE DE MODELIZACI N Tcnicas para analizar un sistema. Clasificacin 1. Atendiendo a las funciones: DFD. Atendiendo a la informacin: MER (E/R). Atendiendo al tiempo: Lista de eventos. Tcnicas para analizar un sistema. Clasificacin 2: segn perspectivas. Plano Informacin-Funcin: DFD. Plano Funcin-Tiempo: Redes de Petri. Plano Informacin-Tiempo: Diagrama de Historia de Vida de la Entidad. MODELIZACI N DE FUNCIONES By Bruce 2: Este apartado se corresponde en su mayora a las instrucciones para realizar la parte prctica. 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. Especificacin de Procesos. Diagramas de Descomposicin Funcional. Comprobaciones sobre una especificacin 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 informacin 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). 40

 Diccionario de Datos (DD): Definicin: lista organizada de los datos utilizados por el sistema (que grficamente se encuentran representados por los flujos de datos y almacenes presentes sobre el conjunto del DFD). Especificacin de Procesos: Objetivo. Mtodos. Objetivo: Especificar `lo que hace el proceso'. Cmo transforma las entradas en salidas. Mtodos para la Especificacin de Procesos: Lenguaje Estructurado. rboles de Decisin. Tablas de Decisin. Diagramas de Accin. Diagramas de Descomposicin Funcional: Objetivo: Representar la jerarqua de los procesos del sistema en diferentes niveles de abstraccin. Comprobaciones a efectuar sobre una especificacin estructurada: Aspectos a tener en cuenta. Apunte chorra final. Aspectos a tener en cuenta: Complecin: 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 (Pg. 212 del libro) y si en el examen reconocemos alguna de las frases, marcamos la opcin Es una pregunta empleada en la revisin de una especificacin estructurada. Ejercicio prctico que nos sirve de ejemplo: La cuestin Hay almacenes locales?: Opcin que NO es. Se utiliza para la revisin de una especificacin estructurada. Esta tampoco es. Muy poco probable que aparezca en el examen una cuestin sobre la susodicha tabla, pero por si acaso la leemos un 41

par de veces. POSIBLES PREGUNTAS CAP TULO VII 1. La Especificacin de Requisitos Software: Descomposicin en componentes y estudio de cmo se realiza cada componente. Documento resultado del Anlisis de un SI, describiendo qu debe hacer dicho SI. Todas son correctas. 2. Requisito: Condicin 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 tcnicas para el Anlisis de Requisitos: Grficas como el Diagrama de Flujo de Datos. Entrevistas y Observacin para recogida de requisitos. Todas son correctas. 4. Las dos caractersticas fundamentales de una Especificacin de Requisitos: InformacinVeraz y Comunicada de forma Eficaz. Fcil de Modificar y Fcil de Verificar. Todas son correctas. 5. Las comprobaciones a realizar sobre una Especificacin 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 B 2 a 3 b 4 a 5 c

CAPITULO VII - VIII : - ANLISIS DE SISTEMAS - DISE O ESTRUCTURADO DE SISTEMAS Intro. DED. By Bruce. Anlisis de Sistemas. 42

 Tcnicas de Especificacin de Control. Comprobaciones entre modelos. Distincin chorra. Intro Diseo Estructurado. Atributos de Calidad. Normalizacin. Metodologas de Diseo Detallado de Programas.

Anlisis de Sistemas. Anlisis de Sistemas. Anlisis/Diseo. Diseo Estructurado de Sistemas. Diseo Estructurado de Sistemas. Diseo Estructurado de Sistemas. Diseo 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 resmenes. Realmente hay unas cuantas de razones ms, pero no me voy a dedicar ahora a justificarme. Captulo 78 by Bruce y no hay ms 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 ms sencillo y de menor nivel de abstraccin que el E/R. Todas sus interrelaciones son 1:N. Mas que a nivel conceptual, este modelo se emplea para representar el modelo lgico de datos. T CNICAS DE ESPECIFICACI N DE CONTROL Lista de Eventos. Diagramas de transicin de Estados. Redes de Petri. LISTA DE EVENTOS

43

 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 prcticos: un evento por cada funcin. 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: grfico que recoge los distintos estados que puede tomar el SI. Enfocado al comportamiento del sistema en funcin 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 condicin. 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 descripcin de sistemas de 44

control asncronos y concurrentes. Componentes: Conjunto finito de lugares. Conjunto diniro de transiciones. Conjunto finito de conexiones o arcos. Similitud con el Diagrama de Transicin de Estados: Los DTE pueden considerarse como un determinado tipo de redes de Petri. Ambos modelos deben contar con las siguientes propiedades: limitacin y vivacidad. COMPROBACIONES ENTRE LOS DISTINTOS MODELOS DE ANALISIS Principales modelos. Comprobaciones. Tcnicas. Matriciales. HVE. PRINCIPALES MODELOS SOBRE LOS QUE EFECTUAR COMPROBACIONES Dimensin de funcin: DFD, DD y Especificaciones de Procesos (modelos de la Especificacin Estructurada). Dimensin de informacin: E/R y Diagrama de Estructura de Datos. Dimensin de tiempo: Lista de Eventos. COMPROBACIONES A REALIZAR ENTRE LOS MODELOS Plano informacin-funcin : Comprobar que todos los elementos (o datos elementales) definidos en los diagramas E/R estn definidos en el DD. Realizar la misma comprobacin con los diagramas de estructuras de datos. Comprobar que cada entidad e interrelacin del E/R es consultada y actualizada al menos una vez por alguna funcin primitiva del DFD. Plano informacin-tiempo : Plano tiempo-funcin : By Bruce: las comprobaciones entre modelos del plano informacin-tiempo y tiempo-funcin involucran ciertas comprobaciones respecto a los diagramas HVE. Inma en su da dijo: Los HVE con que sepis que existen me vale. (Sin embargo s han cado un par de preguntas sobre los HVE) Por lo tanto bastante dudosa la 45

aparicin en el examen de alguna pregunta relativa a estos puntos. En todo caso, si no te fas demasiado, cogemos el libro y lo miramos tambin (son cuatro chorradas contadas). T CNICAS PARA EFECTUAR COMPROBACIONES ENTRE MODELOS Matriciales. HVE. Tcnicas Matriciales: Objetivo: se utilizan principalmente para ayudar a verificar la consistencia entre los compontes de los distintos modelos de un sistema. Matriz Entidad/Funcin: permite ver la relacin existente entre las funciones del sistema y la informacin necesaria para llevar a cabo cada una de las funciones. Funciones Entidades Gestionar Presupuesto Cliente Gestionar Cliente CLIENTE L I, M, B PRESUPUESTO I, M, B

46

 Matriz Entidad/Entidad: permite ver las relaciones que tiene una entidad con otras del modelo E/R. Entidad Entidad CLIENTE PRESUPUESTO CLIENTE Realiza PRESUPUESTO Matriz Evento/Entidad: muestra las alteraciones de las entidades, causadas por los eventos del sistema. Entidades Eventos CLIENTE PRESUPUESTO Datos del Cliente I, M, B Datos del presupuesto I I, M, B Modelado Evento/Entidad - HVE: Historia de Vida de la Entidad: Conceptos. HVE en el anlisis. HVE en el diseo. Conceptos: Esta tcnica permite ver cmo las entidades han evolucionado en el tiempo. La HVE muestra el ciclo de proceso de una entidad desde su creacin hasta su desaparicin. HVE utiliza la notacin de diagrama de estructura. HVE en el Anlisis: Proporciona una validacin para los DFD y el modelo de datos. HVE en el Diseo: Aqu se aaden los indicadores 47

de estado a las HVE para permitir la validacin semntica. DISTINCI N ENTRE ANLISIS Y DISE O ANLISIS Define QU hacer. Son tcnicas empleadas en la fase de anlisis: DISE O Define C MO hacerlo. Se siguen dos enfoques:

E/R (relativa a De Datos. datos). Funcional. DFD (relativa a funciones). 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 (mdulos). El diseo estructurado nos permite, partiendo del DFD, obtener una descripcin de la estructura del programa. Esta descripcin se representa mediante un diagrama de estructuras. 8.2 ATRIBUTOS DE CALIDAD DE UN DISE O Acoplamiento. ACOPLAMIENTO Definicin: grado de interdependencia entre mdulos. Lo ptimo sera que el acoplamiento fuese mnimo (hacer los mdulos tan independientes los unos de los otros como sea posible). Para que el acoplamiento sea mnimo ningn mdulo tiene que preocuparse de los detalles de la construccin interna del resto de los mdulos. Acoplamientos MS deseados: 1.Acoplamiento normal: S LO se produce una llamada entre los mdulos (no se pasan parmetros). 2.Acoplamiento de datos. Acoplamientos MENOS deseados: Uff 1.Acoplamiento por contenido: un mdulo hace referencia al interior de otro. Uff 2. Acoplamiento global: los mdulos comparten una estructura global de datos. COHESI N Cohesin.

48

 Definicin: relacin que existe entre los elementos de un mismo mdulo. Lo ptimo es que la cohesin sea mxima. Deben agruparse en mdulos los elementos que guarden una determinada relacin. FUNCIONAL SECUENCIAL COMUNICACIONAL PROCEDURAL TEMPORAL L GICA Menor Mdulo Cohesin transparente Mdulo Mayor como caja Cohesin negra

COINCIDENTAL 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). Normalizacin: conjunto de restricciones que deben satisfacer los datos. Cada conjunto de restricciones se conoce como forma normal. 1FN - DEPENDENCIA FUNCIONAL 1FN: prohbe que en un registro haya grupos repetitivos (todos los campos han de ser atmicos). 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, XY si y slo si, cada valor de X tiene asociado en todo momento un nico valor de Y. 2FN - DEPENDENCIA FUNCIONAL COMPLETA 2FN: en el caso de que la clave sea compuesta, un registro est en 2FN si adems de estar en 1FN, 49

todos los campos que no formen parte de la clave candidata suministran informacin 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. X(X1, X2)

Dependencia Funcional Completa: Si el descriptor X es compuesto, se dice que X --> Y Y tiene dependencia funcional completa o plena respecto de X si depende X1 -/-> funcionalemente de X pero no depende de Y ningn subconjunto del mismo. X2 -/-> Y 3FN - DEPENDENCIA FUNCIONAL TRANSITIVA 3FN: para que un registro est en 3FN, adems de estar en 2FN, los atributos que NO son clave, proporcionan informacin S LO sobre la clave (y no acerca de otros atributos). 3FN: Un registro est en 3FN si est en 2FN y ningn campo no clave depende transitivamente de ninguna clave. La 3FN est definida formalmente por la Dependencia Funcional Transitiva. X --> Y Dependencia Funcional Transitiva: Dado un registro con tres descriptores en Y --> Z el que existen las siguientes dependencias funcionales: Y -/-> X se dice que Z tiene una dependencia transitiva respecto de X a travs de Y. 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 slo si, todo determinante es clave. METODOLOG AS DE DISE O DETALLADO DE PROGRAMAS Conceptos. Jackson. Warnier. 50

CONCEPTOS GENERALES Permiten obtener una estructura jerrquica del programa. Permiten generar una codificacin en forma de pseudocdigo (que puede ser fcilmente traducida a un lenguaje procedimental de programacin). El enfoque que siguen estos mtodos se basa en el anlisis de los datos que deben manejar los programas. Toman como punto de partida: una especificacin detallada de la entrada, la salida y los algoritmos del programa a construir. Las principales metodologas para el Diseo Detallado de Programas son: el Mtodo Jackson y la Metodologa Warnier. POSIBLES PREGUNTAS CAP TULO 78 1. Las tcnicas de modelado enfocado en el comportamiento de un SI dependiendo del tiempo: Lista de Eventos. Diagramas de Transicin y Redes de Petri. Ambas son correctas. 2. Para efectuar comprobaciones entre los distintos modelos: Tcnicas Matriciales. Historia de Vida de Entidad. Ambas son correctas 3. En anlisis, la Historia de vida de Entidades proporciona: Visualizar relaciones existentes entre entidades de un modelo de datos. Una validacin para DFD y modelos de datos. Ambas son correctas. 4. Con respecto al Anlisis y el Diseo: Anlisis se refiere a Qu hacer y Diseo a Cmo hacerlo. Anlisis se refiere a Cmo hacerlo y Diseo a Qu hacer. Ninguna es correcta. 5. Un Modelo Conceptual como el modelo E-R: Tcnica utilizada en Anlisis. Tcnica utilizada en Diseo. Ninguna es correcta. 6. El Modelo Relacional es: Modelo Conceptual de Datos. Modelo Lgico de Datos. 51

 Modelo Fsico de Datos. 7. Las mtricas que miden la calidad estructural del diseo: Verificacin y Cohesin. Integridad y Validacin. Cohesin y Acoplamiento. 8. El grado de independencia entre mdulos lo mide el atributo de calidad: Cohesin. Acoplamiento. Ambas son correctas. 9. El Acoplamiento ptimo: Es Mnimo (Acoplamiento Normal). Es Mximo (Acoplamiento por Contenido). Ambas son correctas. 10. La Cohesin ptima: Es Mxima (Cohesin Funcional). Es Mxima (Cohesin Coincidental). Ambas son correctas. 11. La Dependencia Funcional Transitiva define formalmente: 1FN. 2FN. 3FN. 12. Generan una estructura lgica partiendo de especificaciones detalladas de datos de entrada, de datos de salida y de algoritmos necesarios : Metodologas de Diseo Arquitectnico de Programas. Metodologas de Diseo Detallado de Programas. Metodologas de Anlisis Estructurado. 13. Jackson y Warnier: Proponen un mtodo para generar una codificacin en forma de pseudocdigo. Proponen un mtodo para el Diseo Detallado de Programas. Ambas son correctas. RESPUESTAS 1 c 2 c 3 b 4 a 5 a 6 b 7 c 8 b 9 a 10 11 12 13 a c b c

CAPITULO XII : PRUEBAS DEL SOFTWARE 52

 INTRO Conceptos.

Definiciones. CONCEPTOS GENERALES Durante el desarrollo de software se requieren una serie de controles peridicos para evaluar los productos generados con el fin de encontrar defectos. Las pruebas consisten en ejecuciones o ensayos, posteriores a la terminacin del cdigo 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 habamos planteado'. VALIDAR: comprobar `si estamos haciendo lo que nos han pedido'. La verificacin y validacin 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 parmetros errneo, 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: accin 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 realizacin de pruebas se trata de una actividad de deteccin (NO de prevencin) de problemas en el software. Los defectos no son siempre el resultado de una negligencia. RECOMENDACIONES PARA LAS PRUEBAS 53

 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 vlidos y esperados, como no vlidos 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 ms creativa que el desarrollo de software. CONCLUSIONES La filosofa ms adecuada para las pruebas consiste en planificarlas y disearlas de forma sistemtica (para poder detectar el mximo nmero y variedad de defectos con el mnimo consumo de tiempo y esfuerzo). Un buen caso de prueba es aquel que tiene una gran probabilidad de encontrar un defecto no descubierto an. El xito de una prueba consiste en detectar un defecto no encontrado antes. EL PROCESO DE PRUEBA Generacin del Plan de Pruebas: en base a la documentacin del proyecto y del software a probar. Diseo detallado de pruebas especficas: se especifican los casos y procedimientos (basndose en la documentacin del software). Ejecucin de los casos de prueba: sobre la configuracin del software. Evaluar los resultados: comparndolos con las salidas esperadas. La evaluacin permite dos actividades: Depuracin (localizacin y correccin de defectos): en caso de NO conseguir detectar los defectos puede ser necesario la realizacin de pruebas adicionales. Si se corrige un defecto debe volver a probarse el software. Anlisis de la estadstica de errores: puede ser til para realizar predicciones de la fiabilidad del software y para detectar las causas ms habituales de error y mejorar los procesos de desarrollo. T CNICAS DE DISE O DE CASOS DE PRUEBA 54

 Conceptos. Enfoques. CONCEPTOS GENERALES Objetivo: conseguir una confianza aceptable en la deteccin 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 deteccin de defectos. El diseo 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 ejecucin. Enfoque Funcional (o de caja negra): Se centra en la especificacin de funciones (entradas y salidas). Prueba exhaustiva: probar todas las posibles entradas y salidas. Enfoque Aleatorio: Utiliza modelos (normalmente estadsticos) 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 deteccin de defectos ms 55

eficaz.. PRUEBAS ESTRUCTURALES Conceptos. Clasificacin de Criterios de Cobertura Lgica. Mtrica de McCabe. CONCEPTOS GENERALES El diseo de casos tiene que basarse en la eleccin de caminos importantes que ofrezcan una seguridad aceptable en descubir defectos Para ello se utilizan los criterios de cobertura lgica. No requieren el uso de ninguna representacin grfica especfica (aunque es habitual el empleo de los diagramas de flujo de control (flowcharts)). CLASIFICACI N DE LOS CRITERIOS DE COBERTURA L GICA Menor cost e Cobertura de sentencias: generar los casos de Menor n prueba necesarios para ejecuciones que cada sentencia Mayor coste (instruccin) del programa se ejecute al Mayor n menos vez. ejecucionesCobertura de decisiones: ... cada decisin tenga, al menos 1 vez, un resultado verdadero y, al menos 1 vez, un resultado falso. Cobertura de condiciones: cada condicin de cada decisin adopte el valor `verdadero' al menos 1 vez, y el valor `falso' al menos 1 vez. Criterio de decisin/condicin: exigir el cumplimiento de la cobertura de decisiones y la cobertura de condiciones. Criterio de condicin mltiple: (en el caso de dividir una decisin multicondicional en varias unicondicionales) conseguir que todas las combinaciones posibles 56

de resultados (verdadero/falso) de cada condicin de cada decisin se ejecuten al menos 1 vez. Cobertura de caminos: cada camino se ejecute al menos 1 vez. Cobertura de Caminos Criterio de cobertura ms elevado. Requiere que cada uno de los caminos del programa se ejecuten al menos 1 vez. Camino.definicin: secuencia de sentencias encadenadas desde la sentencia inicial del programa hasta su sentencia final. Los bucles constituyen el elemento que que genera un mayor nmero de problema en la cobertura de caminos. Para reducir el nmero de caminos se emplean los caminos de prueba: camino del programa que atraviesa, como mximo, 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 ejecutndolo 1 vez y otra ejecutndolo 2 veces). Existen algoritmos basados en matrices (que representan el grafo de flujo del programa) que permiten contar el nmero total de caminos de prueba. UTILIZACI N DE LA COMPLEJIDAD CICLOMTICA DE MCCABE Objetivo: indicar el nmero de caminos independientes que existen en un grafo. By Bruce: a ver dado el carcter terico de los presentes resmenes, esta parte me la salto. Si tienes especial inters en saber cmo se calcula la complejidad de McCabe a partir de un grafo de flujo, te miras las pginas 402, 403, 404 y 405 del libro. Como adelanto: es otra mariconada ms entre tantas que aparecen el el libro. Inciso concluido. Hasta luego . 57

 PRUEBAS FUNCIONALES Conceptos. Tcnicas. CONCEPTOS GENERALES Se centra en el estudio de la especificacin del software, del anlisis de las funciones que debe realizar, de las entradas y de las salidas. Deben buscarse criterios que permitan elegir un subconjunto de casos cuya ejecucin 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 nmero 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. Mtodo de Diseo. Cualidades de la Tcnica: Cada caso debe cubrir el mximo nmero de entradas. Debe tratarse el dominio de valores de entrada (divido en un nmero 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. Mtodo de Diseo: Identificacin de Clases de Equivalencia. Creacin de Casos de Prueba. Identificacin de Clases de Equivalencia: Identificacin de las condiciones de entrada (restricciones de formato 58

o contenido de los datos de entrada). Identificacin de las clases de equivalencia (a partir de los datos de entrada). stas clases pueden ser: De datos vlidos. De datos no vlidos o errneos. 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:

Ej: El Rango de nmero valores o estar

C. v (1 n 49 C. n

v comprendido entre 1 y 49

Ej: se pueden Nmero registrar de de valores o uno a tres propietarios de un piso 59

(n < C. no v (n > 49 C. v (1 pr 3) C. n

v (p <

 C.

no v ( pr >

60

Ej: el primer Situacin carcter booleana debe ser una o letra

C. v ( un let C. n

Conjunto de valores Ej: pueden admitidos registrarse (tratando tres tipos de el programa de distinta forma a cada uno de ellos) inmuebles: pisos, chals y locales comerciales

v ( es un let C. v ( C. v

( C. v

(l C. no

v (

Si se sospecha que ciertos elementos de una clase no se tratan igual que el resto de la misma, deben dividirse en clases menores. Creacin de Casos de Prueba: Asignacin de un nmero 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 vlidas como sea posible. Hasta que se hayan cubierto todas las clases de equivalencia no vlidas con casos de prueba escribir un caso para una nica clase no vlida sin cubrir. Anlisis de Valores Lmite (AVL): 61

 Conceptos. Reglas.

62

 Conceptos Generales: Complementa a la tcnica de particiones de equivalencia. Los casos de prueba que exploran las condiciones lmite de un programa producen mejor resultado para la deteccin de defectos. Condiciones Lminte.def: situaciones que se hallan directamente arriba, abajo y en los mrgenes de las clases de equivalencia. El proceso de seleccin de casos es tambin heurstico. 1. Heurstico: (gr. , hallar, inventar), adj. Perteneciente o relativo a la heurstica. REGLAS para identificar clases:

63

(1) Rango de valores. (Como condicin de entrada) Ej: el valor estar comprendido entre 1 y -1 2 Casos vlidos para los extremos: ( - 1.0 ) ( + 1.0 ) 2 Casos no vlidos para valores justo ms all de los extremos: ( 1.001 ) ( + 1.001 ) (2) Nmero de valores. (Como condicin de entrada) Ej: el fichero de entrada tendr de 1 a 255 registros Mximo: ( 255 registros ) Mnimo: ( 1 registro ) Mximo + 1: ( 256 registros ) Mnimo - 1: ( 0 registros ) (3) Rango de valores. (Como condicin de salida) Ej: el descuento mximo aplicable en una compra al contado ser el 50%, el mnimo ser el 6% (Idem regla 1). Se escribirn casos para obtener: 6%, 64

50%, 5.99% y 50.01%. (4) Nmero de valores. (Como condicin de salida) Ej: el programa puede mostrar de 1 a 4 listados (Idem regla 2). Se escribirn 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 lmite de entrada no generan necesariamente los valores lmite de salida. No siempre se pueden generar resultados fuera del rango de salida. Conjetura de Errores: Conceptos. Recomendaciones. Conceptos Generales: Consiste en: Enumerar 65

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 gene de caso se basa en la intui o la expe

Valo prop a erro y Rec a tene en cuen para los caso espe Valo cero (tant en la salid com en la entr 66

 En lista o tabla ning valo todo los valo igua Rec ima que le prog hubi inter algo mal en la espe Rec ima lo que el usua pued intro com entr a un prog PRUEBAS ALEATORIAS Simulan la entrada habitual del programa creando datos de entrada (en la secuencia 67

y con la frecuencia con las que podran aparecer en una situacin real), de forma contnua y sin parar. Utilizan una herramienta llamada generador de pruebas, que debe contener la descripcin de entradas y secuencias de entrada junto con su posibilidad de ocurrir en la prctica. Empleadas comunmente en la prueba de 68

compiladore Son menos utilizadas que las tcnicas de caja blanca y de caja negra. ENFOQUE PRCTICO RECOMENDADO PARA EL DISE O DE CASOS Pretende mostrar el uso ms apropiado de cada tcnica para la obtencin de un conjunto de casos tiles (sin prejuicio de las estrategias de casos de prueba). RECOMENDACIO A LA HORA DE DISE AR CASOS

69

 Comenzar formando los grafos causa-efecto si la especificaci contiene combinacion de condiciones de entrada. Usar el anlisis de valores-l Identificar las clases vlidas y no vlidas de equivalenci para la entrada y la salida, y aadir los casos no incluidos anteriorment Utilizar la tcnica de conjetura de errores. Ejecutar los casos generados hasta el 70

momento y analizar la cobertura obtenida. Examinar la lgica del programa. DOCUMENTACI DEL DISE O DE LAS PRUEBAS Conceptos. Documentos Plan de Prue Espe del Dise de Prue Espe de Cas de Prue Espe de Proc de Prue CONCEPTOS GENERALES

Es necesaria tanto para una mejor organizaci de las pruebas, como para asegurar 71

su reutilizaci Los documentos contemplado en el estndar se asocian a las distintas fases de las pruebas. DOCUMENTOS

Plan de Pruebas: sealar el enfoque, los recursos y el esquema de actividades de prueba, as como los elementos a probar, las caracterst las actividades de prueba, el personal responsable y los riesgos asociados. 72

 Especificaci del Diseo de Pruebas: especificar los refinamiento necesarios sobre el enfoque general reflejado en el plan e identificar las caracterst que se deben probar con este diseo de pruebas. Especificaci de Casos de Prueba: definir uno de los casos de prueba identificado por una especificaci del diseo de las pruebas. Especificaci 73

de Procedimie de Prueba: especificar los pasos para la ejecucin de un conjunto de casos de prueba.

EJECUCI N DE LAS PRUEBAS Proceso. Documentac Depuracin Anlisis de Errores. EL PROCESO DE EJECUCI N General. Ejecucin. Comprobaci Proceso General de Pruebas: Ejecucin de las pruebas. Comprobacin de la Terminacin de las Pruebas. Evaluacin de Resultados. 74

(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 Ejecucin: Ejecucin de las pruebas (`paso por el ordenador de los datos de prueba'). Comprobacin de posibles fallos de ejecucin. Si ha habido algn fallo se realizan nuevas pruebas. Si NO existen fallos, se pasa a la comprobacin de la terminacin de las pruebas.

Subproceso de Comprobac Comprobar si se 75

cumplen los criterios de complecin (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 evaluacin. En caso contrario se pasa a generar y ejecutar pruebas adicionales. Los criterios de compleci de pruebas hacen referencias a reas que deben

76

cubrir las pruebas y el grado de cobertura para cada rea (Ej: `se debe cubrir cada caracterst del software mediante un caso de prueba o una excepcin aprobada en el plan de pruebas')

DOCUMENTACI DE LA EJECUCI N DE LAS PRUEBAS DEPURACI N Conceptos. Consejos. Conceptos Generales:

Dep pro de loca anal y 77

corr los defe que se sosp que tiene el soft Suel ser la cons de una prue con Las cons de una depu pued ser dos:

Las dos prin etap de 78

la depu son:

Consejos chorras para la Depuraci Localizacin del error: Analizar la informaci y pensar. Al llegar a un punto muerto, pasar a otra cosa. Al llegar a un punto muerto, describir el problema a 79

otra persona. Usar herramientas de depuracin slo como recurso secundario. No experimenta cambiando el programa. Se deben atacar los errores individualm Se debe fijar la atencin tambin en los datos. Correccin del error:

Donde hay un defecto suele haber ms. Debe fijarse el defecto, no sus sntomas. La probabilidad de corregir perfectamen 80

un defecto no es del 100%. Cuidado con crear nuevos defectos. La correccin debe situarnos temporalme en la fase de diseo. Cambiar el cdigo fuente, no el cdigo objeto. ANLISIS DE ERRORES (o Anlisis Causal)

Se emplea para obtener informaci sobre la naturaleza de los defectos. El objetivo principal es 81

la formacin 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 Integracin Prueba del Sistema. Prueba de Aceptacin CONCEPTOS GENERALES Conceptos. Niveles de Prueba. Niveles de Prueba Productos de Desarrollo. Conceptos: 82

 Pretende integrar el diseo de los casos de prueba en una serie de pasos bien coordinados (a travs de la creacin de distintos niveles de prueba con diferentes objetivos). Permite la coordinaci del personal de desarrollo, del departament de aseguramien de calidad y del cliente (gracias a la definicin de los papeles que

83

deben desempe cada uno de ellos y la forma de llevarlos a cabo). Etapas de la Estrategia de Pruebas (Niveles de Prueba): Prueba de Mdulo (prueba de unidad): el propio personal de desearrollo (normalmente) realiza la prueba de cada mdulo. Prueba de Integracin: se integran los mdulos probados (en base al esquema del diseo del software), para comprobar sus interfaces en el trabajo conjunto. Prueba de Validacin 84

(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 Aceptacin: el usuario comprueba el producto final en su propio entorno de explotacin para aceptarlo como est, o no. Relacin entre Niveles de Prueba y Etapas de Desarrollo: La relacin entre productos de desarrollo 85

y niveles de prueba se concreta en un modelo de ciclo de vida denominado Ciclo en Uve. Prueba de Mdulo (prueba de unidad): ejercitar la lgica del mdulo (caja blanca) y la especificacin de las funciones que debe realizar el mdulo (caja negra) Especificacin y lgica de mdulo. Prueba de Integracin: tratar los mecanismos de agrupacin de mdulos (fijados en la estructura del programa) Diseo modular. Prueba de Validacin (o 86

funcional): comprobar posibles desajustes entre el software y los requisitos fijados para su funcionamiento en la ERS (No asociado a ningn producto del desarrollo segn el `Ciclo en Uve'). Prueba del Sistema: comprobaciones del cumplimiento de objetivos indicados para el sistema Especificacin de requisitos. Prueba de Aceptacin: 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

87

 Conceptos. Definiciones Enfoque. Conceptos Generales: Suelen ser realizadas por el personal de desarrollo (evitando que las realice el programador Se intenta el mximo acercamient al ideal de exhaustivida (a travs de los criterios de cobertura lgica y funcional). La planificaci de este nivel de pruebas se realiza para la globalidad de pruebas 88

de unidad. Consisten en las pruebas formales que nos permiten declarar que un mdulo est listo y terminado. Puede realizarse tanto a un nico mdulo como a un conjunto indefinido de stos. Definicione

Mdulo.d bloque bsico de construcci de programas. Mdulo.d parte del cdigo que implementa una funcin simple. Mdulo.d fragmento de cdigo 89

que se puede compilar independien Unidad de prueba: uno o ms mdulos que cumplen las siguientes condiciones: Tod pert al mis prog Al men uno de ellos NO ha sido prob El conj de m es el obje de un proc de prue Enfoque para una Prueba de Unidad: Orientado claramente al 90

diseo de casos de caja blanca (aunque complement con caja negra). Suele seguirse el `Enfoque Recomendad Las razones por las que incluir casos de caja blanca son: El tam del m (o grup de m es apro para pode usar t de caja blan para exa toda la lg El tipo de 91

PRUEBA DE INTEGRACI N

defe que se bus c coin con los pro p de la lg deta de m

Conceptos. Integracin Incremental. Asc Des Integracin NO Incremental. Sandwich. Incremental No Incremental. Incremental ascendente Incremental descendente Recomendac Conceptos Generales: Objetivo: probar las interfaces (`flujos de datos') entre componente o mdulos. Consiste en 92

integrar los distintos componente del software (`realiazin de pruebas de los distintos mdulos'), hasta contar con el producto global (`sistema completo'). Los tipos fundamental de integracin son: la integraci incremental (ascendente y descendente )y la integraci no incremental (o `Big-Bang'). NO es siempre obligatorio que, en la estrategia de aplicacin de las 93

pruebas, deba terminarse la prueba de todos los mdulos antes de empezar a integrar. (La prueba de mdulos y las pruebas de integracin se solapan). El orden de integracin elegido influye en aspectos como: La form de prep caso Las herr nece El orde de codi y prob los m El cost 94

de la depu El cost de la prep de caso Integraci Incrementa Ascendente Comenzand por los mdulos de ms bajo nivel (`mdulos hoja'), se combina el siguiente mdulo que se debe probar con el conjunto de mdulos que ya estn probados. Se incrementa progresivam el nmero de mdulos hasta formar el programa 95

completo. Fases: ( En el ejemplo se parte de un esquema idntico al de la fase 4). Se combinan los mdulos de bajo nivel en grupos (no obligatoriamente) que realizan alguna subfuncin especfica. (Para reducir el nmero de pasos de integracin). Se escribe para cada grupo un mdulo impulsor. Se prueba cada grupo probando su impulsor. Se eliminan los impulsores de cada grupo y se sustituyen 96

por los mdulos del nivel superior de la jerarqua.

En todas las integracione incrementale se combinan pruebas de unidad y de integracin Integraci Incrementa Descendent Comenzand por el mdulo de control principal (`mdulo raz'), se van incorporand mdulos subordinado progresivam hasta formar el programa completo. Se basa en el empleo de modulos ficticios, cuya codificaci 97

es ms compleja que la creacin de impulsores. Deb a la dific de cons exis vari nive de sofis de m ficti (de may a men nive de com M que sl mue un men de traza M que mue los par que se les pasa M que devu valo que NO 98

depe de los par de entr M que devu valo que depe de los par de entr

99

10 0

 Se escr m ficti para simu la pres de los subo ause que ser llam por el m ra Se susti uno de los subo 10 1

ficti por el m corr seg el orde eleg y se inco ficti para reco las llam del lti inco Se ejec las corr prue cada vez que se inco un m nuev Al term cada prue se susti el ficti por su corr real. [Co repe algu caso de prue de 100

ejec ante para aseg de que no se ha incl ning defe nuev

101

 Se prue cada m por sepa Se ensa todo los m para form el prog com Se prue el conj

Se com en los m de nive supe de form desc Se com simu de 102

form desc desd los m infer Se cont hast que amb apro se encu en alg nive inter

Inte Incr

103

Inte Asc - Ve

104

Inte Asc Des

105

PRU DEL SIS

106

107

PRU DE AC

108

109

110

111

112

PO PRE CA XII

1. Obje de T para Dise de Cas de Prue

2. Los 113

tres enfo prin para el Dise de Cas de Prue

3. Las Prue Estr se basa el la elec de cam que ofre una segu acep a la hora de desc defe utili los llam

114

4. La Prue Fun o Caja Neg se cent en:

5. Clas de Equ

115

6. El Enfo Pr reco

7. El Info de Inci

116

8. La Dep

9. La Prue Beta se reali en el ento real de trab

117

10. Dad la espe El nom es de 6 cara

118

11. Dad el sigu diag mod supo que no hay ning tipo de agru de m para hace prue de 119

unid

RES

12 c c ME ES F (V 2.0)

Intr

Com com que salv un par de ellas toda las 120

preg apar en el exa parc del terce trim aunq la may no de form liter

En la part dedi a las preg del test de M lo que se han indi han sido las RES COR (NO son disti opci entr las que haya que esco As que si leem 121

por ejem

4. C son los prin pro de un proc de an estr

Mod de proc

Mod conc de dato

Mod lg de dato

Espe de inter de usua

Vien a deci que los prod del proc de an estru son 122

esos cuat Los mem Y si en el exa te encu con una opci que no se corr con ning de esos cuat es porq dich opci es falsa

La preg 11 del lti exa la 6 del apar Con del Siste de Info de los apu aqu pres diga que 123

mm esto CAS Nos opta por la resp que se incl en el test de M que es tam la que se expo aqu (que tam es la que se dio por vl en el ante exa y que, muy curi cont a lo que pode leer en el apar dedi a 124

la activ CSI 5 de M A cont con todo noso la suso preg junt a su corr resp

6. Q part NO inte en la acti CSI 5 Eje de las Pru del Sist

T de Siste

T de Com

Equ del Proy

125

Ana

Y si nos loca el cuad resu de la activ CSI 5, nos enco con lo sigu

Tar

CSI 5.1

CSI 5.2

CSI 5.3

Lo que vien a deci que nos 126

apre las resp a mod de dog de fe y que la suer est pres dura el exa

Proc Prin

M 3 es una met orie a proc que pret abar el ciclo de vida com del soft Por cons tene que, los proc prin de su estru son la 127

plan el desa y el man del SI.

El proc de desa del SI a su vez se desc en otro 5 proc 4 de los cual ser conv mem en el caso de pret apro la part dedi a M del exa

128

Proc que hay que estu

129

Obte una espe deta del SI que se plas en un cat de requ

Los prod gene en este proc son: el cat de requ el glos y el cont del siste

Defi de la arqu del SI, del ento tecn que le va 130

a dar sopo y la espe deta de sus com

Se gene las espe de cons la desc t del plan de prue la defi de los requ de impl y el dise de los proc de migr y carg inici

Gen el cd de 131

los com del SI, desa los proc de oper y segu y elab los man de usua final

Entr y acep del siste en su total y reali de toda las activ nece para el paso a prod

AN DEL SIS DE INF 132

1. Obj del proc de An de Sist de Info (AS

La obte de una espe deta del siste que satis las nece de info de los usua y sirva de base para el post dise del siste

2. Qu tipo de desa cont M 3: Estr 133

Orie a obje

3. La t de Cas de Uso se utili en el:

An orie a obje

An estru

4. C son los prin pro de un proc de an estr

Mod de proc

Mod conc de dato 134

Mod lg de dato

Espe de inter de usua

DIS DEL SIS DE INF

1. Obj del proc de Dise de Sist de Info (DS

Defi la arqu del SI, el ento tecn que le va a dar sopo y la espe deta de sus com 135

2. Los pro gene en el DSI son:

Espe de Con

Des T del Plan de Prue

Defi de los Req de Imp

Dise de los Proc de Mig y Carg Inici (si proc

3. Los obje que se pers con la acti 136

Dis de la Arq de M del Sist (DS 5) son:

Real el dise deta de la inter de usua

Con las inter entr m de cada subs entr subs y con el resto de siste

Defi los m del siste de info iden los proc 137

que se van a impl en cada subs espe

4. Las tare que hay que llev a cab par cum los obje de la acti DSI 7 Ve y acep de la arq del siste son:

Veri de la calid t de cada mod o espe Ase 138

la cohe entr los disti mod

Ace del dise de la arqu por part de los resp de Exp y Siste

5. Los obje a cum de la acti Esp T del Plan de Pru (DS 10) son:

Dete los Con o Apti adic que requ los 139

usua final para oper con el nuev siste

Com la Plan de las Prue (det los disti perf impl en su prep ejec y eval de resu

Dise Deta de los Nive de Prue espe en el proc de An del Siste de Info (AS

Defi 140

con prec las verif a reali sobr el siste conf a los nive de prue esta

CO DEL SIS DE INF

1. Obj del proc de Con del Sist de Info (CS

Gen cd de com del SI.

Elab los proc de oper y segu

141

Elab man de usua final

2. Tar de la acti CSI 1 Pr del Ent de Gen y Con

Imp de la Base de Dato F o Fich

Prep del ento de Con

3. La gene del c corr a cad uno de los com 142

del siste de info se real a part de la info del proc

Dise del Siste de Info (DS

4. Obj de las Pru Unit

Com que la estru de cada uno de los com del Siste de Info es la corr y que se ajus a 143

la func esta

5. Obj de las Pru de Inte

Veri si los com o subs inter corr a trav de sus inter inter

Veri si los com o subs inter corr a trav de sus inter exte

Veri si los com o subs cubr 144

la func esta

Veri si los com o subs se ajus a los requ espe

6. Q part NO inte en la acti CSI 5 Eje de las Pru del Sist

T de Siste

T de com

Equ del proy Ana 145

7. Seg la acti CSI 8 Co de los Com y Pro de Mig y Car inici de Dat q acci es nece ante de llev a cab la gene de c

Prep de la infra tecn nece para reali la codi

IMP Y AC DEL SIS 1. 146

Obj prin del proc de Imp y Ace del Sist (IAS

Entr y acep del siste en su total para reali el paso a prod

2. En la acti IAS Est del plan de imp

Se revi la estra esta en el proc Estu de Viab del 147

Siste

3. Asp cons dent del Plan de For del Equ de Imp en la acti IAS 2 Fo Nec par la Imp

Esq de form

Mat de form

Rec de form

Plan de la form

4. Pro obte en la acti 148

IAS 4 Ca de dato al Ent de Ope

Base de dato / Fich carg

5. Part de las acti de Pru de Imp y Pru de Ace del SI:

Jefe de Proy

Res de impl -

Usu expe

Dire de los 149

usua

6. Q afir son cier sobr la figu del Res de Man del siste

For part del equi de impl

Reci una form adec para adqu una visi glob del siste

Ana en deta el siste que va a impl

Valo si 150

la info disp es sufic para abor el futu man del siste

Llev a cabo las prue de impl

7. Obj de la acti IAS 8 Est de Acu de Nive de Serv

Dete los serv que requ el siste

Espe los nive de serv 151

con los que se va a valo la calid del serv

Defi los com que se adqu con la entr del siste

8. Una vez efec las pru de imp y acep com paso prev a la pue en pro la apr del SI es form por: 152

Com de Dire

ME ES F (V 2.0)

Intr

Com com que salv un par de ellas toda las preg apar en el exa parc del terce trim aunq la may no de form liter

En la part dedi a las preg del test de M lo que 153

se han indi han sido las RES COR (NO son disti opci entr las que haya que esco As que si leem por ejem

4. C son los prin pro de un proc de an estr

Mod de proc

Mod conc de dato

Mod lg 154

de dato

Espe de inter de usua

Vien a deci que los prod del proc de an estru son esos cuat Los mem Y si en el exa te encu con una opci que no se corr con ning de esos cuat es porq dich opci es falsa

155

La preg 11 del lti exa la 6 del apar Con del Siste de Info de los apu aqu pres diga que mm esto CAS Nos opta por la resp que se incl en el test de M que es tam la que se expo aqu (que tam es la que se 156

dio por vl en el ante exa y que, muy curi cont a lo que pode leer en el apar dedi a la activ CSI 5 de M A cont con todo noso la suso preg junt a su corr resp

6. Q part NO inte en la acti CSI 5 157

Eje de las Pru del Sist

T de Siste

T de Com

Equ del Proy Ana

Y si nos loca el cuad resu de la activ CSI 5, nos enco con lo sigu

Tar CSI 5.1

158

CSI 5.2

CSI 5.3

Lo que vien a deci que nos apre las resp a mod de dog de fe y que la suer est pres dura el exa

Proc Prin

M 3 es una met orie a proc 159

que pret abar el ciclo de vida com del soft Por cons tene que, los proc prin de su estru son la plan el desa y el man del SI.

El proc de desa del SI a su vez se desc en otro 5 proc 4 de los cual ser conv 160

mem en el caso de pret apro la part dedi a M del exa

161

Proc que hay que estu

Obte una espe deta del SI que se plas en un cat de requ

Los prod gene en este proc son: el cat de requ el glos y 162

el cont del siste

Defi de la arqu del SI, del ento tecn que le va a dar sopo y la espe deta de sus com

Se gene las espe de cons la desc t del plan de prue la defi de los requ de 163

impl y el dise de los proc de migr y carg inici

Gen el cd de los com del SI, desa los proc de oper y segu y elab los man de usua final

Entr y acep del 164

siste en su total y reali de toda las activ nece para el paso a prod

AN DEL SIS DE INF

1. Obj del proc de An de Sist de Info (AS

La obte de una espe deta del siste que satis las nece de info de los 165

usua y sirva de base para el post dise del siste

2. Qu tipo de desa cont M 3: Estr

Orie a obje

3. La t de Cas de Uso se utili en el:

An orie a obje

An estru 4. 166

C son los prin pro de un proc de an estr

Mod de proc

Mod conc de dato

Mod lg de dato

Espe de inter de usua

DIS DEL SIS DE INF

1. Obj del proc de Dise de Sist de Info 167

(DS

Defi la arqu del SI, el ento tecn que le va a dar sopo y la espe deta de sus com

2. Los pro gene en el DSI son:

Espe de Con

Des T del Plan de Prue

Defi de los Req 168

de Imp

Dise de los Proc de Mig y Carg Inici (si proc

3. Los obje que se pers con la acti Dis de la Arq de M del Sist (DS 5) son:

Real el dise deta de la inter de usua

Con las inter 169

entr m de cada subs entr subs y con el resto de siste

Defi los m del siste de info iden los proc que se van a impl en cada subs espe

4. Las tare que hay que llev a cab par cum los obje de la acti DSI 170

7 Ve y acep de la arq del siste son:

Veri de la calid t de cada mod o espe

Ase la cohe entr los disti mod

Ace del dise de la arqu por part de los resp de Exp y Siste

5. Los obje 171

a cum de la acti Esp T del Plan de Pru (DS 10) son:

Dete los Con o Apti adic que requ los usua final para oper con el nuev siste

Com la Plan de las Prue (det los disti perf impl en su prep ejec y eval 172

de resu

Dise Deta de los Nive de Prue espe en el proc de An del Siste de Info (AS

Defi con prec las verif a reali sobr el siste conf a los nive de prue esta

CO DEL SIS DE INF

1. Obj del proc 173

de Con del Sist de Info (CS

Gen cd de com del SI.

Elab los proc de oper y segu

Elab man de usua final

2. Tar de la acti CSI 1 Pr del Ent de Gen y Con

Imp de la Base 174

de Dato F o Fich

Prep del ento de Con

3. La gene del c corr a cad uno de los com del siste de info se real a part de la info del proc

Dise del Siste de Info (DS 4. Obj de las Pru 175

Unit

Com que la estru de cada uno de los com del Siste de Info es la corr y que se ajus a la func esta

5. Obj de las Pru de Inte

Veri si los com o subs inter corr a trav de sus inter inter 176

Veri si los com o subs inter corr a trav de sus inter exte

Veri si los com o subs cubr la func esta

Veri si los com o subs se ajus a los requ espe

6. Q part NO inte en la acti CSI 5 177

Eje de las Pru del Sist

T de Siste

T de com

Equ del proy Ana

7. Seg la acti CSI 8 Co de los Com y Pro de Mig y Car inici de Dat q acci es nece ante de llev a 178

cab la gene de c

Prep de la infra tecn nece para reali la codi

IMP Y AC DEL SIS

1. Obj prin del proc de Imp y Ace del Sist (IAS

Entr y acep del siste en su total para reali el paso a prod 179

2. En la acti IAS Est del plan de imp

Se revi la estra esta en el proc Estu de Viab del Siste

3. Asp cons dent del Plan de For del Equ de Imp en la acti IAS 2 Fo Nec par la Imp Esq de 180

form

Mat de form

Rec de form

Plan de la form

4. Pro obte en la acti IAS 4 Ca de dato al Ent de Ope

Base de dato / Fich carg

5. Part de las acti de Pru de Imp y 181

Pru de Ace del SI:

Jefe de Proy

Res de impl -

Usu expe

Dire de los usua

6. Q afir son cier sobr la figu del Res de Man del siste

For part del equi de impl

Reci una 182

form adec para adqu una visi glob del siste

Ana en deta el siste que va a impl

Valo si la info disp es sufic para abor el futu man del siste

Llev a cabo las prue de impl 7. Obj de la acti IAS 183

8 Est de Acu de Nive de Serv

Dete los serv que requ el siste

Espe los nive de serv con los que se va a valo la calid del serv

Defi los com que se adqu con la entr del siste

8. Una vez 184

efec las pru de imp y acep com paso prev a la pue en pro la apr del SI es form por:

Com de Dire

PO PRE M 3.0

1. La estru de M V3:

185

2. M V3 divi los proc prin en:

3. Obje del Proc de Dise del Siste de Info (DS

186

4. Los prod gene en el proc DSI

187

5. Los obje pers en la activ DSI 5 Dis de la arqu de m del Siste

188

6. Las tarea que hay que lleva a cabo para cum los obje de la activ DSI 7 Ve y Ace de la Arq del Siste

189

7. Los obje de la activ DSI 10 Esp T del Plan de Prue

190

8. Obje del proc de Con del Siste de Info (CSI

Las tarea de la activ CSI 1 Pre del Ento 191

de Gen y Con

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286