Está en la página 1de 77

UNIVERSIDAD DE CORDOBA ESCUELA POLITECNICA SUPERIOR ISCBD

APUNTES RESUMEN DE INGENIER DEL SOFTWARE IA

Autor:

Miguel Yepes Moyano


Junio de 2004

PREFACIO
A Resmenes realizados usando una plantilla en L TEX creada por Miguel u Yepes Moyano orientada a la generacin de la documentacin de un proyecto o o (disponible en la direccin http://www.uco.es/i12yemom), usando anjuta o para la edicin de texto, desarrollada bajo linux y usando como fuente de o informacin el libro de Ingenier del Software y apuntes tomados en clase. o a

Indice general
PREFACIO 1. INGENIER DEL SOFTWARE IA 1.1. LA INGENIER DEL SOFTWARE . . . . . . . . . . . . . IA 1.2. PARADIGMAS DE LA INGENIER DEL SOFTWARE . . IA 1.2.1. PARADIGMA DEL CICLO DE VIDA CLASICO . . 1.2.2. PARADIGMA DEL PROTOTIPO . . . . . . . . . . . 1.2.3. PARADIGMA EN ESPIRAL . . . . . . . . . . . . . . 1.2.4. PARADIGMA DRA (DESARROLLO RAPIDO DE APLICACIONES) . . . . . . . . . . . . . . . . . . . . 1.2.5. PARADIGMA INCREMENTAL . . . . . . . . . . . . 1.2.6. COMBINACION DE PARADIGMAS . . . . . . . . . 1.3. PLANIFICACION DEL PROYECTO SOFTWARE . . . . . 1.3.1. DEFINICION DEL PROBLEMA . . . . . . . . . . . . 1.3.2. DESARROLLO DE UNA ESTRATEGIA DE SOLU CION . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.3. ANALISIS DE RIESGO . . . . . . . . . . . . . . . . . 1.3.4. RECURSOS PARA EL DESARROLLO DEL PROYECTO . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4. PLANIFICACION TEMPORAL DEL PROYECTO SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1. PARALELISMO DE TAREAS . . . . . . . . . . . . . 1.4.2. DISTRIBUCION DE ESFUERZOS . . . . . . . . . . 1.4.3. METODOS DE PLANIFICACION TEMPORAL . . . ORGANIZATIVA . . . . . . . . . 1.4.4. PLANIFICACION 1.4.5. PLAN DE PROYECTO SOFTWARE . . . . . . . . . 2. ESTIMACION DE LOS COSTES DEL PROYECTO SOFTWARE 2.1. FACTORES QUE DETERMINAN EL COSTE DEL PROYECTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1. CAPACIDAD DE LOS PROGRAMADORES . . . . . 2.1.2. COMPLEJIDAD DEL PRODUCTO . . . . . . . . . . II I 1 2 3 3 4 6 6 7 8 9 9 10 10 10 11 12 12 12 13 13

14 14 14 14

0. Indice general

Pgina III a

2.1.3. TAMANO DEL PRODUCTO . . . . . . . . . . . . . 2.1.4. TIEMPO DISPONIBLE . . . . . . . . . . . . . . . . . 2.1.5. NIVEL DE CONFIABILIDAD REQUERIDO . . . . . 2.1.6. NIVEL TECNOLOGICO . . . . . . . . . . . . . . . . 2.2. METRICAS DE PRODUCTIVIDAD DEL SOFTWARE . . . 2.2.1. METRICAS ORIENTADAS AL TAMANO . . . . . . 2.2.2. METRICAS ORIENTADAS A LA FUNCION . . . . 2.2.3. RECONCILIACION DE LAS DIFERENTES METRICAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. TECNICAS DE ESTIMACION DE COSTES . . . . . . . . . 2.3.1. JUICIO DEL EXPERTO . . . . . . . . . . . . . . . . 2.3.2. TECNICA DELFI . . . . . . . . . . . . . . . . . . . . 2.3.3. ESTRUCTURAS DE DIVISION DEL TRABAJO . . EMP 2.4. MODELOS DE ESTIMACION IRICA . . . . . . . . . . 2.4.1. MODELO COCOMO . . . . . . . . . . . . . . . . . . 2.4.2. MODELO DE PUTNAM . . . . . . . . . . . . . . . . 3. EL ANALISIS DE REQUISITOS 3.1. PRINCIPIOS DEL ANALISIS DE REQUISITOS . . . . . . . 3.2. ESPECIFICACION DE LOS REQUISITOS . . . . . . . . . . 3.2.1. Actividades de la ERS . . . . . . . . . . . . . . . . . . 3.2.2. TECNICAS DE RECOGIDA DE LA INFORMACION 3.2.3. ESPECIFICACION DE LOS REQUISITOS SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4. ESPECIFICACION DE REQUISITOS DE LAS INTERFACES . . . . . . . . . . . . . . . . . . . . . . . . 3.3. VISION GENERAL DE LAS TECNICAS DE ESPECIFI CACION DE REQUISITOS . . . . . . . . . . . . . . . . . . . 3.4. COMPROBACION DE LA ERS . . . . . . . . . . . . . . . .

15 15 16 16 17 18 18 19 20 20 20 21 21 21 23 24 24 25 25 26 27 28 28 30

4. TECNICAS DE ESPECIFICACION Y MODELACION 31 4.1. ESPECIFICACION Y MODELACION DE LA FUNCION . 31 4.1.1. DIAGRAMAS DEL FLUJO DE DATOS . . . . . . . 31 4.1.2. DESARROLLO DE NIVELES DE ABSTRACCION EN LOS DFD . . . . . . . . . . . . . . . . . . . . . . 34 4.1.3. DICCIONARIO DE DATOS . . . . . . . . . . . . . . 36 4.1.4. DIAGRAMAS DE ACCION . . . . . . . . . . . . . . 36 4.1.5. TABLAS DE DECISION . . . . . . . . . . . . . . . . 36 4.1.6. ARBOLES DE DECISION . . . . . . . . . . . . . . . 39 4.1.7. REJILLAS DE DATOS . . . . . . . . . . . . . . . . . 40 4.1.8. DIAGRAMAS DE ESTRUCTURAS . . . . . . . . . . 41 4.2. ESPECIFICACION Y MODELACION DE LA INFORMA CION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

</i12YeMoM>

0. Indice general

Pgina IV a

4.3. ESPECIFICACION Y MODELACION DEL COMPORTAMIENTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1. DIAGRAMAS DE TRANSICION DE ESTADOS . . . 4.3.2. DIAGRAMAS DE LA HISTORIA DE VIDA DE LAS ENTIDADES . . . . . . . . . . . . . . . . . . . . . . . 4.4. TECNICAS MATRICIALES . . . . . . . . . . . . . . . . . . 4.4.1. MATRIZ ENTIDAD/ENTIDAD . . . . . . . . . . . . 4.4.2. MATRIZ EVENTO/ENTIDAD . . . . . . . . . . . . . 4.4.3. MATRIZ PAPEL DEL USUARIO/FUNCION . . . . 5. EL DISENO DEL SOFTWARE 5.1. EL PROCESO DE DISENO . . . . . . . . . . . . 5.2. CONCEPTOS FUNDAMENTALES DEL DISENO . . . . . . . . . . . . . . . 5.2.1. ABSTRACCION 5.2.2. OCULTACION . . . . . . . . . . . . . . . . 5.2.3. MODULARIDAD . . . . . . . . . . . . . . 5.2.4. CONCURRENCIA . . . . . . . . . . . . . . 5.2.5. VERIFICACION . . . . . . . . . . . . . . . 5.2.6. ESTETICA . . . . . . . . . . . . . . . . . . 5.2.7. ESTRUCTURA DEL PROGRAMA . . . . 5.2.8. PROCEDIMIENTOS SOFTWARE . . . . 5.2.9. REFINAMIENTO . . . . . . . . . . . . . . 5.3. EL DISENO MODULAR . . . . . . . . . . . . . . 5.3.1. TIPOS DE MODULOS . . . . . . . . . . . 5.3.2. INDEPENDENCIA FUNCIONAL . . . . . 5.4. ACTIVIDADES DEL DISENO . . . . . . . . . . . DE DATOS . . . . . . . . . . . . 5.4.1. DISENO 5.4.2. DISENO ARQUITECTONICO . . . . . . . PROCEDIMENTAL . . . . . . . 5.4.3. DISENO

43 43 45 46 46 46 46 47 47 48 48 49 49 50 50 50 51 51 51 51 51 52 54 54 55 55

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

6. LAS PRUEBAS SOFTWARE 56 6.1. OBJETIVO DE LAS PRUEBAS . . . . . . . . . . . . . . . . 57 6.2. EL PROCESO DE PRUEBA . . . . . . . . . . . . . . . . . . 58 6.3. TECNICAS DE DISENO DE LOS CASOS DE PRUEBA . . 58 6.3.1. LAS PRUEBAS ESTRUCTURALES (CAJA BLANCA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6.3.2. LA PRUEBA FUNCIONAL (CAJA NEGRA) . . . . 63 6.3.3. PRUEBAS ALEATORIAS . . . . . . . . . . . . . . . 66 6.4. EJECUCION DE LAS PRUEBAS . . . . . . . . . . . . . . . 66 6.4.1. EL PROCESO DE EJECUCION . . . . . . . . . . . . 66 6.5. LA DEPURACION . . . . . . . . . . . . . . . . . . . . . . . 67 6.6. ESTRATEGIA DE APLICACION DE LAS PRUEBAS . . . 67 6.6.1. PRUEBA UNIDAD . . . . . . . . . . . . . . . . . . . 68 6.6.2. LA PRUEBA DE INTEGRACION . . . . . . . . . . . 68
</i12YeMoM>

0. Indice general

Pgina V a

6.6.3. LA PRUEBA DE VALIDACION . . . . . . . . . . . . 6.6.4. LA PRUEBA DEL SISTEMA . . . . . . . . . . . . . 6.6.5. LA PRUEBA DE ACEPTACION . . . . . . . . . . . BIBLIOGRAF IA

69 69 70 71

</i12YeMoM>

CAP ITULO 1

INGENIER DEL SOFTWARE IA


En cualquier problema relacionado con la informtica en general es nea cesario considerar dos aspectos fundamentales: el hardware y el software. Aunque ambos se han desarrollado de forma paralela, los problemas que presenta el software en vez de solucionarse se han ido incrementando. Las razones de los mismos son las siguientes: La existencia de un hardware muy sosticado hace que exista una mayor independencia entre software y hardware dejando atrs la capacia dad de construir software que explote de forma eciente este hardware. Demanda muy elevada del software que resulta insatisfecha. Actividad de mejora y mantenimiento del software insatisfecha tambin debido a la rpida evolucin del entorno. e a o Para solucionar estos problemas se ha recurrido a la proposicin de un o conjunto de pautas, reglas, heur sticas, modelos a seguir de forma ordenada y perfectamente registrada en el proceso de desarrollo de software a los que se le han llamado Ingenier del Software. a Una denicin de ingenier del software ser la siguiente: o a a Una disciplina tecnolgica y administrativa dedicada a la o produccin sistemtica de los productos de programacin, o a o que son desarrollados y modicados a tiempo, y dentro de un presupuesto denido. De esta denicin podemos obtener los siguientes objetivos: o Construir software de calidad. Aumentar la productividad del proceso de desarrollo. Mejorar la satisfaccin personal de las personas implicadas. o Disminuir costes en produccin y almacenamiento. o Acabar con las leyendas. 1

1. INGENIER DEL SOFTWARE IA

Pgina 2 a

1.1.

LA INGENIER DEL SOFTWARE IA

La ingenier del software est por delante de la programacin clsica a a o a desde el punto de vista administrativo (punto que no se tiene en cuenta en la programacin clsica). o a Sin la realizacin de un estudio previo de un problema de cierta envergao dura ni la planicacin del desarrollo de la solucin pueden que se presenten o o una serie de problemas que generen un coste mayor del previsto. La IS se encarga de intentar evitar estos imprevistos. Las diferencias entre software y otros tipos de productos son: El software no se deteriora con el tiempo. El software no se fabrica sino que se desarrolla. El software es algo intangible y dif de medir o cuanticar, aunque cil existen algunos parmetros que permiten, de alguna forma, medirlo a como pueden ser el nmero de l u neas de cdigo, reusabilidad. . . o Si se considera que el software est libre de errores, ste no est somea e a tido a la inuencia de su entorno y son las modicaciones a las que se somete las que originan errores. El mantenimiento de un producto software es complejo. Estas caracter sticas y otras muchas originan una gran cantidad de problemas en el proceso de desarrollo que se deben resolver, algunos de ellos son: La planicacin y estimacin de los recursos previstos son muy imo o precisos, desbordndose las estimaciones en la mayor de los casos. a a (Leyes de Murphy :P) La productividad no se corresponde con las necesidades de los clientes. La calidad de los productos no es la adecuada, llegando al mercado, en muchos casos, con errores. Estos problemas hace que sea necesario el uso de procedimientos de IS para el desarrollo software. Por tanto otra denicin de IS ser la siguiente: o a El establecimiento y uso de principios de ingenier robustos, a orientados a obtener econmicamente software que sea able o y funcione efectivamente sobre mquinas reales. a Se puede apreciar que la IS est formada por tres elementos: a

</i12YeMoM>

1. INGENIER DEL SOFTWARE IA

Pgina 3 a

Los mtodos: e Suministran informacin de cmo construir el software, abarcando una o o gran variedad de actividades como planicacin y estimacin de costes, o o anlisis de requisitos. . . a Las herramientas: Sirven de soporte al proceso de produccin, suministrando utiles auo tomticos o semiautomticos para la ejecucin de los mtodos. a a o e Los procedimientos: Nexos de unin entre herramientas y mtodos facilitando el desarrollo o e racional y a tiempo del software. Denen la secuencia en la que se deben aplicar los mtodos, la informacin requerida. e o Una nueva denicin de IS ser o a: Un conjunto determinado de mtodos que utiliza un conjunto e de herramientas bajo un conjunto de procedimientos.

1.2.

PARADIGMAS DE LA INGENIER DEL IA SOFTWARE

En los ultimos aos se estn desarrollando paradigmas de distintas na n a turalezas, por lo que el gestor debe elegir el ms adecuado para su producto a software a desarrollar.

1.2.1.

PARADIGMA DEL CICLO DE VIDA CLASICO

Tambin denominado Modelo en cascada. El proceso de desarrollo softe ware se realiza en fases secuenciales: una fase comienza cuando la previa ha concluido. Las fases de las que consta son las siguientes: Ingenier y anlisis de sistemas: a a Actividad encargada del estudio del sistema global. En esta fase se extraen los requisitos globales a nivel de sistema, las relaciones que mantiene con otros subsistemas y el propio subsistema software es estudiado a un nivel de abstraccin elevado. o Anlisis de requisitos del software: a Fase analista en la que se debe recoger toda la informacin sobre el o software a desarrollar y el problema a solucionar. En esta fase se deber conocer el dominio de la informacin que manejar el software, a o a el procesamiento de dicha informacin, su rendimiento y las interfaces o E/S.

</i12YeMoM>

1. INGENIER DEL SOFTWARE IA

Pgina 4 a

Dise o: n Etapa en la que se traducen los requisitos recogidos en la fase anterior en una especicacin formal especicando estructuras de datos, o arquitectura del sistema software, interfaz y procedimientos. En esta fase se crean una serie de documentos que entran a formar parte de la conguracin del software. o Codicacin: o Traduccin de las especicaciones formales anteriores a una especio cacin entendible por el hardware. Si los documentos anteriores son o correctos, en esta fase lo unico que se realiza es una traduccin entre o formatos de especicacin. o Prueba: Fase cuyo objetivo es vericar que todas las partes del producto software generado en la fase anterior producen una salida adecuada esperada a partir de unos datos de entrada. Mantenimiento: Un producto software puede necesitar cambios. En esta fase se llevan a cabo dichos cambios, y pueden afectar a cualquiera de las fases anteriores produciendo, por tanto, modicaciones en la documentacin. o Este es el paradigma ms ampliamente usado aunque presenta una serie a de inconvenientes: Los proyectos raramente siguen este ujo secuencial. Es dif establecer todos los requisitos en fases muy tempranas del cil proceso de desarrollo. No se tiene informacin del producto hasta que no se ha completado o el proceso de desarrollo o nos encontramos en las ultimas etapas.

1.2.2.

PARADIGMA DEL PROTOTIPO

Se construye un prototipo que facilita al ingeniero del software la creacin o de un modelo del producto a seguir. Este modelo puede tomar las siguientes formas: Prototipo en papel que describa la interaccin hombre/mquina. o a Prototipo operativo que implemente algunas de las operaciones requeridas. Programa que presente toda la informacin deseada, pero con algunas o caracter sticas a mejorar en el nuevo trabajo de desarrollo.

</i12YeMoM>

1. INGENIER DEL SOFTWARE IA

Pgina 5 a

Etapas y actividades a realizar en este paradigma para el desarrollo software: Recogida y renamiento de requisitos: Se realiza por el ingeniero y el cliente y se denen objetivos globales viendo qu reas van a necesitar una mayor profundizacin en su ea o anlisis. a Dise o rpido: n a Para representar los aspectos del software visibles para el usuario del producto. Construccin del prototipo: o Diseo de un prototipo del producto que se utiliza para volver a la n fase de anlisis de requisitos para renar y ampliar las especicaciones a iniciales o realizar un nuevo diseo y construir un nuevo prototipo. n Evaluacin y renamiento de requisitos: o Con el prototipo creado se debe optar por: 1. 2. Considerarlo como producto nal. Destruirlo total o parcialmente y construir un producto nal en base al paradigma clsico en el que algunas fases ya se han desaa rrollado y otras debern revisitarse. a

VENTAJAS E INCONVENIENTES CON RESPECTO AL MODELO EN CASCADA Ventajas: El cliente participa de forma activa. El cliente est viendo el producto desde el primer momento. a Los productos se adaptan mejor a los subsistemas de las organizaciones donde se van a instalar. Inconvenientes: El ingeniero deber controlar la impaciencia del cliente por terminar a el producto. Si un prototipo se considera como producto nal de forma prematura puede producir un bajo desempeo debido a las restricciones f n sicas impuestas al crear dicho prototipo.

</i12YeMoM>

1. INGENIER DEL SOFTWARE IA

Pgina 6 a

1.2.3.

PARADIGMA EN ESPIRAL

Pretende resolver los inconvenientes de los paradigmas anteriores combinando las caracter sticas favorables de ellos e incluyendo un nuevo elemento llamado anlisis de riesgo. Etapas de las que consta: a Planicacin: o Se determinan los objetivos o problemas a solucionar, as como las diferentes alternativas para alcanzarlos y las restricciones impuestas. Anlisis de riesgo: a Se realiza un anlisis de cada una de las alternativas especicadas en a la planicacin. o Ingenier a: Se lleva a cabo la construccin del producto nal gracias a toda la o documentacin generada en las etapas anteriores. o Evaluacin del cliente: o El cliente evala cada uno de los sistemas que se le van presentando a u lo largo del proceso. Se trata de un modelo en el que se producen una serie de iteraciones cada una con un modelo cada vez ms depurado del producto nal y en la a que se produce un anlisis de riesgo precedido por la toma de decisin tras a o o cancelar el proyecto su evaluacin consistente en seguir adelante. o Este paradigma es el enfoque ms realista para el desarrollo software. a Presenta las siguientes ventajas: Permite al ingeniero y al cliente conocer los riesgos en cada nivel de evolucin del producto. o Usa la creacin de prototipos para la reduccin del riesgo. o o Mantiene el enfoque sistemtico del modelo en cascada pero incorpoa rado en un proceso iterativo. Requiere una consideracin directa de los riesgos, lo que permite deso cubrir posibles errores o riesgos.

1.2.4.

PARADIGMA DRA (DESARROLLO RAPIDO DE APLICACIONES)

Modelo de desarrollo software lineal secuencial que enfatiza un ciclo de desarrollo estrechamente corto mediante un enfoque de construccin basado o en componentes. Si se utiliza para aplicaciones de sistemas de informacin se consideo rar las siguientes fases: a
</i12YeMoM>

1. INGENIER DEL SOFTWARE IA

Pgina 7 a

Modelado de gestin. o Modelado de datos. Modelado de proceso. Generacin de aplicaciones. o Pruebas y entrega. Si se considera una aplicacin de gestin de manera que pueda completar o o cada una de sus funciones componentes en menos de tres meses, consideraremos que es un candidato a aplicarle el DRA. Cada una de las funciones pueden ser afrontadas por un equipo DRA diferente y ser integradas en un slo modelo conjunto. o Desventajas: Para proyectos grandes requiere un gran nmero de recursos. u Requiere un fuerte compromiso tanto por los desarrolladores como por los clientes para realizar las rpidas actividades. a Necesita sistemas modularizables y que no posean altos riesgos tcnie cos.

1.2.5.

PARADIGMA INCREMENTAL

Modelo que se acomoda a un producto que evoluciona con el tiempo. Combina elementos del modelo secuencial lineal con la losof iterativa de a construccin de prototipos. Cada secuencia lineal produce un incremento en o el nivel de desarrollo software. Fases de que consta: 1. 2. Un primer uncremento en el que se disea un producto esencial en el n que se considera un m nimo de requisitos bsicos. a El cliente evalua el trabajo realizado y o lo considera como producto nal y aqu acaba el ciclo, o decide realizar un renamiento del mismo y se contina. u Se desarrolla un plan para el incremento siguiente, se lleva a cabo y se vuelve al paso dos.

3.

Presenta una diferencia con el modelo en prototipo y es que se produce una entrega del producto en cada incremento. Es un desarrollo util cuando la dotacin de personal es insuciente para o una implementacin completa en la fecha establecida como l o mite de nalizacin. o
</i12YeMoM>

1. INGENIER DEL SOFTWARE IA

Pgina 8 a

1.2.6.

COMBINACION DE PARADIGMAS

En la mayor de las ocasiones los paradigmas deben combinarse para a aprovechar las ventajas que cada uno de ellos ofrece. En todos los casos el proyecto comienza con la determinacin de los o objetivos, alternativas y restricciones (recoleccin de requisitos). o Si la informacin es completa y el sistema se puede especicar compleo tamente se usar el modelo en cascada. Si los requisitos son inciertos se a podr usar el modelo del prototipo para el desarrollo de un prototipo que a podr evolucionar al ciclo de vida clsico en la etapa de prueba. Adems a a a pueden ser usados las T4G. En cualquier caso el desarrollo software comprender tres fases genricas: a e Fase de denicin: o Se centra sobre el QUE, es decir, en intentar identicar la informacin o que ha de ser procesada, la funcin y el rendimiento que se desea, o las interfaces, las restricciones de diseo y los criterios de validacin. n o Generalmente esta fase se compone de tres actividades: 1. Anlisis del sistema: Dene el papel de cada elemento del sistema. a 2. Planicacin del proyecto: Se realiza el anlisis de riesgo asignano a do recursos, estimando costes, deniendo tareas a realizar. . . 3. Anlisis de requisitos: Se describe el mbito del software, la ina a formacin requerida, su procesamiento y su objetivo. o Fase de desarrollo: Se centra en el COMO, es decir, en intentar disear las estructuras n de datos, la estructura y arquitectura del software, para pasarlas a un lenguaje de programacin y hacerle una serie de pruebas para vericar o su exactitud. Actividades que se realizan en esta fase: 1. Diseo del software: Traduccin de las especicaciones del anlisis n o a a representaciones que describan la estructura de datos, interfaz, algoritmos. . . 2. Codicacin: Traduccin de las especicaciones anteriores a una o o especicacin entendible por la computadora. o 3. Prueba: Ver que el programa funciona de forma correcta. Fase de mantenimiento: Se centra en los cambios asociados a la correccin de los errores deteco tados en las pruebas o cambios de requisitos y/o entorno.

</i12YeMoM>

1. INGENIER DEL SOFTWARE IA

Pgina 9 a

1.3.

PLANIFICACION DEL PROYECTO SOFTWARE

La falta de planicacin suele ser fuente de retrasos, incremento de coso tes. . . Para evitar estos problemas es necesario una planicacin cuidadosa o y, aunque en fases iniciales suele ser dif puesto que no se tiene informacil cin suciente para realizarla y quedar incompleta, conviene hacerla. Es o a una planicacin preliminar. Ser necesario, por tanto, realizar revisiones o a temporales que supondrn una modicacin de la planicacin. a o o La planicacin del proyecto consta de tres etapas o 1. 2. 3. Denicin del problema. o Desarrollo de una estrategia de solucin. o Proceso de desarrollo.

1.3.1.

DEFINICION DEL PROBLEMA

Est orientada a que el cliente comprenda en que consiste el proyecto y a se trata de un desarrollo de un enunciado breve del problema, en el que se incluirn las restricciones, situacin actual y los objetivos. a o Esta denicin requiere un entendimiento completo del dominio y de su o entorno, obteniendo esta informacin gracias a una serie de entrevistas con o el cliente. Una vez conocido el problema se debe proponer una solucin compuo tacional aceptada social (la solucin va a suponer una disminucin en el o o personal, y la funcin es asumible por el mismo) y econmicamente (aunque o o no se produzca una disminucin en el personal se va a poder realizar muo chas ms funciones). Despus se deben determinar las funciones principales a e del sistema y de los subsistemas que la componen (operadores, personal de mantenimiento, usuarios, hardware. . . ). Adems hay que establecer los OBa JETIVOS, que son los logros a alcanzar y sirven para establecer el marco de referencia para el proyecto de desarrollo del producto. Estos se aplican tanto al proceso de desarrollo como a los productos nales, pudiendo ser tanto cuantitativos como cualitativos. Los REQUISITOS especican las ca pacidades que debe tener un producto para la solucin del problema. Estos o se establecen en base a la funcionalidad, rendimiento, hardware, personal, interfaces. . . Debido a la dicultad que tiene la especicacin de los requisitos y obo jetivos en esta fase, stos se suelen expresar en trminos de atributos de e e calidad.

</i12YeMoM>

1. INGENIER DEL SOFTWARE IA

Pgina 10 a

1.3.2.

DESARROLLO DE UNA ESTRATEGIA DE SOLU CION

Pretende resolver el problema de eleccin de la primera solucin proo o puesta para proponer y valorar posteriormente varios mtodos de solucin. e o Estos mtodos ser todos los que tenemos a nuestro alcance. Se descartan e an los menos ecientes indicando por qu y se elige la solucin ms ptima. e o a o

1.3.3.

ANALISIS DE RIESGO

Para solucionar las incertidumbres generadas en las primeras fases del desarrollo de un producto software se realiza el anlisis de riesgos que permia te garantizar una buena gestin del proyecto. Este anlisis consta de cuatro o a actividades bsicas: a Identicacin del riesgo: o Se realiza una enumeracin y clasicacin por categor de los riesgos o o as de un proyecto en concreto. Prevencin del riesgos: o Intenta evaluar dos aspectos de cada uno de los riesgos: 1. 2. Posibilidad de que el riesgo sea real. Consecuencias asociadas con el riesgo, suponiendo que se origina el problema que lo genera.

Evaluacin del riesgo: o Cuenta con un conjunto de triadas riesgo, probabilidad y coste para identicar los distintos puntos de ruptura de la forma: riesgo = { ri , i , ci } Es necesario denir una serie de niveles de referencia. Cuando se alcanza uno de estos niveles se dice que se ha llegado a un punto de ruptura y ser necesario tomar una decisin como puede ser seguir o a o abandonar el proyecto. Plan de gestin y supervisin: o o Actividad en la que se documenta el trabajo realizado con parte del anlisis de riesgos, siendo utilizada por el gestor del proyecto como a parte de la planicacin del proyecto global. o

1.3.4.

RECURSOS PARA EL DESARROLLO DEL PROYECTO

Recursos humanos: Son los ms importantes y los que generan ms problemas en el proceso a a
</i12YeMoM>

1. INGENIER DEL SOFTWARE IA

Pgina 11 a

de planicacin y desarrollo del software. En necesario especicar tanto o la posicin orgnica como su especializacin. El nmero de personas o a o u necesarias puede ser variable a lo largo de la ejecucin del proyecto y o slo puede ser determinado tras realizar una estimacin del esfuerzo o o de desarrollo mediante tcnicas de estimacin de esfuerzos. e o Recursos hardware: Un recurso es considerado como tal si pertenece a una de las siguientes categor as: El sistema de desarrollo: Computadora y perifricos. e El sistema de explotacin: Donde se explotar el software desao a rrollado. Otros elementos hardware necesarios para el desarrollo o la explotacin. o Recursos software: Software utilizado durante el proceso de desarrollo. Algunas herramientas software son: Herramientas orientadas a cdigo. o Herramientas de metodolog a. Herramientas de cuarta generacin. o Si en el proceso de desarrollo hace falta un recurso software, en la eleccin o de este recurso es necesario considerar que: Si el software existe es ms barato comprarlo que hacerlo a Si el software existente requiere alguna modicacin es conveniente o estimar el coste de la misma puesto que podr exceder al del desarrollo a del mismo.

1.4.

PLANIFICACION TEMPORAL DEL PROYECTO SOFTWARE

Comprende varias tareas importantes entre las que se encuentra la de denir un modelo para el ciclo de vida del producto. Se va a realizar por alguno de los paradigmas de la IS y puede ser visto desde dos perspectivas: con una fecha de entrega inamovible o con un margen de holgura. La planicacin temporal consiste en ajustar el conjunto de tareas que o deben llevarse a cabo a un calendario ms o menos r a gido. Raramente se ajusta el tiempo de desarrollo del producto al previsto, desbordndolo en la mayor de los casos, por lo que es necesario llevar a a a cabo un seguimiento y control de las previsiones realizadas.
</i12YeMoM>

1. INGENIER DEL SOFTWARE IA

Pgina 12 a

1.4.1.

PARALELISMO DE TAREAS

Cuando ms de una persona est involucrada en un proyecto, puede que a a varias actividades puedan llevarse a cabo en paralelo. Debido a que estas tareas pueden realizarse de forma as ncrona, el planicador debe determinar la dependencia entre las tareas para asegurar el progreso continuo del proyecto hasta su terminacin. o Cada referencia o meta parcial del proyecto es colocada a intervalos regulares y se alcanza una vez la documentacin ha sido revisada satisfaco toriamente.

1.4.2.

DISTRIBUCION DE ESFUERZOS

Va a depender del proyecto, aunque una distribucin muy recomendada o es la siguiente: Fase Anlisis y diseo a n Codicacin o Prueba y depuracin o Esfuerzo total 40 % 20 % 40 %

1.4.3.

METODOS DE PLANIFICACION TEMPORAL

La planicacin de un proyecto software es similar a la de cualquier otro o tipo de proyecto pudindosele aplicar tcnicas PERT o CPM. e e Caracter sticas comunes de los mtodos de planicacin: e o Identicar las tareas que determinan la duracin del proyecto. o Establecimiento de estimaciones de tiempo para tareas individuales de acuerdo con modelos estad sticos. Calcular los tiempos l mite que denen un espacio temporal para cada tarea. Para cada tarea se deber determinar una serie de tiempos que permitan a calcular holguras, caminos cr ticos. . . Son los siguientes: Tiempo early: Lo ms pronto que puede comenzar una tarea sua poniendo que todas las tareas se han ejecutado en su tiempo m nimo. Tiempo last: Lo ms tarde que puede comenzar una tarea sin que a se retrase el tiempo m nimo de nalizacin del proyecto. o Tiempo nal ms temprano: Suma del comienzo ms temprano y a a la duracin de la tarea. o

</i12YeMoM>

1. INGENIER DEL SOFTWARE IA

Pgina 13 a

Tiempo nal ms tard Suma del comienzo ms tard y la dua o: a o racin de la tarea. o A partir de estos datos, como se ha dicho anteriormente, se van a poder calcular holguras y caminos cr ticos (formados por actividades con holgura cero). Deber tenerse en cuenta adems el esfuerzo necesario para llevar a a a cabo el mantenimiento, pero es una tarea dif de programar en esta fase cil de desarrollo del proyecto.

1.4.4.

PLANIFICACION ORGANIZATIVA

Consiste en la asignacin de personal para la ejecucin de distintas tao o reas. Este personal se clasica en tres grupos: Democrticos. a Jerarqu administrativa. a Jefe principal. Se van a establecer grupos de trabajo cuyo esquema genrico ser e a: Un ingeniero senior encargado de la planicacin y revisin de todas o o las actividades del grupo. Personal tcnico que va dirigir el anlisis y las actividades de desarrollo. e a Un ingeniero junior que puede ser reemplazable y que podr desema pear funciones tanto del ingeniero senior como del personal tcnico. n e

1.4.5.

PLAN DE PROYECTO SOFTWARE

Se produce como la culminacin de la etapa de planicacin, proporcioo o nando una l nea base de informacin de costes y de planicacin temporal o o que se utilizar a lo largo del ciclo de vida del software. As se trata de a , un documento que se dirige a una audiencia inversa y que debe tener las siguientes caracter sticas: Debe comunicar el alcance y los recursos a los gestores del software, al personal tcnico y al cliente. e Denir riesgos y sugerir tcnicas de aversin al riesgo. e o Proporcionar una aproximacin global al desarrollo de software para o toda la gente involucrada en el proyecto.

</i12YeMoM>

CAP ITULO 2

ESTIMACION DE LOS COSTES DEL PROYECTO SOFTWARE


La estimacin de costes es una de las primeras tareas que deben realizarse o en la planicacin de un proyecto software y se trata de una dif tarea o cil puesto que no se posee informacin suciente acerca del mismo. o Para intentar solventar este problema se realizan varias estimaciones a lo largo del desarrollo de un proyecto, acercndose cada vez ms al coste a a nal del mismo puesto que cada estimacin se realiza sobre una etapa en la o que ste est ms renado. e a a

2.1.

FACTORES QUE DETERMINAN EL COSTE DEL PROYECTO

Otro problema que se presenta en la estimacin del coste de un proyeco to software es la determinacin del coste de los factores, generalmente no o cuantitativos y por tanto dif de medir. cil

2.1.1.

CAPACIDAD DE LOS PROGRAMADORES

Tiene una relacin directa con la duracin y coste del proyecto. Es una o o medida del nivel de conocimientos y experiencia de las personas dedicadas ala programacin de software as como la experiencia con el tema en concreto o con el que se est tratando. e Tras haber estudiado el rendimiento de grupos de desarrollo se llega a la conclusin de que un grupo ideal ser aquel lo ms homogneo y elevado o a a e en cuanto a su capacidad.

2.1.2.

COMPLEJIDAD DEL PRODUCTO

En una primera aproximacin se pueden considerar tres categor prino as cipales de productos software: 1. Software de aplicacin. o 14

2. ESTIMACION DE LOS COSTES DEL PROYECTO SOFTWARE Pgina 15 a

2. 3.

Software cient co y de apoyo. Software de sistemas.

Brook considera que el software de apoyo es tres veces ms dif de a cil construir que el de aplicacin, y que el de sistemas, a su vez, es tres veces o mas dif de construir que el de apoyo. cil Boehm utiliza tambin tres niveles de complejidad que caracterizan el e desarrollo de un producto software: 1. 2. 3. Productos desarrollados en modo orgnico (similar a software de aplia cacin). o Productos desarrollados en modo semiacoplado (similar a software de apoyo). Productos desarrollados en modo empotrado (similar a software de sistemas).

Un error muy comn es subestimar la cantidad de cdigo no teniendo u o en cuenta el cdigo relativo a entrada/salida, comunicacin con el usuario, o o control de errores. . . siendo ste, a veces, el 50 % del total del cdigo del e o programa.

2.1.3.

TAMANO DEL PRODUCTO

Un proyecto ser ms costoso cuanto ms grande sea. Se puede realizar a a a una medicin atendiendo al nmero de l o u neas de cdigo que necesita un o programa as como al nmero de personas al mes necesarias para llevarlo a u cabo.

2.1.4.

TIEMPO DISPONIBLE

Se busca calcular el tiempo nominal de desarrollo de un proyecto, bien mediante tcnicas de programacin lineal o bien mediante la proposicin de e o o expresiones matemticas como la propuesta por Putnam: a
k P A = (T DA)4 - PA: esfuerzo expresado en personas por ao. n - k: personas. - TDA: tiempo de desarrollo.

Se ha estudiado el factor del tiempo ptimo de desarrollo de un proyecto o y se ha llegado a la conclusin de que los proyectos de programacin requieo o ren ms esfuerzo si el tiempo de desarrollo se reduce o incrementa ms de a a su valor ptimo. o

</i12YeMoM>

2. ESTIMACION DE LOS COSTES DEL PROYECTO SOFTWARE Pgina 16 a

Otro estudio ha demostrado tambin que no por asignarle ms recursos e a a una tarea se va a reducir el tiempo de duracin de la misma. Boehm lo o describe as : existe un l mite ms all del cual un proyecto de programacin no puede a a o reducir su calendario mediante la adquisicin de ms personal o ms equipo. o a a

2.1.5.

NIVEL DE CONFIABILIDAD REQUERIDO

La conabilidad de un producto de programacin se dene como: o La probabilidad de que un programa desempee una funn cin requerida bajo ciertas condiciones espec o cas durante un cierto tiempo. La conabilidad puede expresarse en trmie nos de exactitud, rmeza, cobertura y consistencia del cdigo o fuente. Boehm considera que hay cinco niveles de conabilidad y que a cada uno se le puede asignar un factor multiplicador. NIVEL Muy baja Baja Nominal Alta Muy alta CONSECUENCIA Alguna molestia menor Las prdidas son fciles de recuperar e a Dicultad relativa en a recuperacin o Gran prdida nanciera e Riesgo de prdida de vida e FACTOR 0.75 0.88 1.00 1.15 1.40

2.1.6.

NIVEL TECNOLOGICO

El nivel tecnolgico empleado en un proyecto de programacin se reeja o o en el lenguaje utilizado, la mquina abstracta, las prcticas y las herramiena a tas de programacin. o El nivel tecnolgico va a depender de cuatro factores: o Lenguaje de programacin: o El uso de un lenguaje de alto nivel simplica el nmero de l u neas de cdigo y aumenta la conabilidad, capacidad de modicacin y o o mantenimiento del mismo. Mquina abstracta: a Hace referencia al software y al hardware. Prcticas modernas de programacin: a o Afectarn al esfuerzo empleado en el desarrollo. a Aplicaciones de apoyo: Editores, compiladores. . . y herramientas de manejo de conguracin o y vericacin automtica. o a
</i12YeMoM>

2. ESTIMACION DE LOS COSTES DEL PROYECTO SOFTWARE Pgina 17 a

Boehm introduce tres factores ms: a La experiencia en programacin. o Cmo se utilizan las prcticas modernas de programacin (si se utilizan o a o mucho se produce una disminucin considerable del esfuerzo). o Caracter sticas de las aplicaciones de apoyo.

2.2.

METRICAS DE PRODUCTIVIDAD DEL SOFTWARE

El software se mide por varias razones: 1. 2. 3. 4. Indicar la calidad del producto. Evaluar la productividad de la gente que lo desarrolla. Asegurar los benecios en trminos de productividad y calidad. e Ayudar a justicar el uso de nuevas herramientas de formacin adicioo nal. Se pueden realizar dos tipos de mediciones: 1. Medidas directas: Coste de produccin, velocidad de cmputo, tamao de memoria reo o n querido. . . 2. Medidas indirectas: Funcionalidad, eciencia, calidad, abilidad, complejidad. . . Se puede realizar una nueva clasicacin en base a la productividad, o calidad y medidas tcnicas del producto software en la fase de desarrollo, e son: Mtricas de productividad. e Mtricas de calidad. e Mtricas tcnicas. e e Mtricas orientadas al tamao. e n Mtricas orientadas a la funcin. e o Mtricas orientadas a las personas. e

</i12YeMoM>

2. ESTIMACION DE LOS COSTES DEL PROYECTO SOFTWARE Pgina 18 a

2.2.1.

METRICAS ORIENTADAS AL TAMANO

Se obtienen tras aplicar una serie de operaciones. No estn demasiado a aceptadas puesto que no es el mejor modo de medir un proyecto de desarrollo software debido a la relatividad de lo que estamos midiendo. Las operaciones aplicables son: Productividad = Calidad = Coste = Documentacin = o
KLDC P ersonasmes Errores KLDC Inversin o KLDC P ags.Doc KLDC

2.2.2.

METRICAS ORIENTADAS A LA FUNCION

Se centran en la funcionalidad o utilidad del programa. Los puntos de funcin se obtienen utilizando una relacin emp o o rica basada en medidas contables del dominio de la informacin del software y valoraciones subjetivas o de la complejidad del mismo. Los puntos de funcin se pueden calcular atendiendo a cinco caracter o sticas de la informacin: o N mero de entradas de usuario: Se cuenta cada entrada de usuario u que proporciona al software diferentes datos orientados ala aplicacin. o N mero de salidas al usuario: Nmero de informes, pantallas, menu u sajes de error . . . N mero de peticiones de usuario: Es el nmero de entradas geu u neradas por la interaccin del usuario con el programa que se pueden o producir. N mero de archivos: Se cuenta cada archivo maestro lgico. u o N mero de interfaces externas: Nmero de interfaces que son utiu u lizadas para transmitir informacin a otro sistema. o Elemento del dominio de la informacin o Entradas de usuario Salidas de usuario Peticiones de usuario Nmero de archivos u Interfaces externas Valor FP Simple x3 x4 x3 x7 x5 FP Medio x4 x5 x4 x10 x7 FP Complejo x6 x7 x6 x15 x10 CP

</i12YeMoM>

2. ESTIMACION DE LOS COSTES DEL PROYECTO SOFTWARE Pgina 19 a

Cuando estos datos son calculados se asocia un valor de complejidad a cada cuenta y se calculan los puntos de funcin de la siguiente forma: o P untodef uncin = C.T. (0,65 0,01 o
i=n i=1 Fi )

- C.T. = C.P. - Fi : Valores de ajuste de complejidad. Una vez calculados los puntos de funcin, se usan de forma anloga a las o a LCD, como medida de productividad, calidad y otros atributos del software en base a las siguientes expresiones: Productividad = Calidad = Coste = Documentacin = o
PF P ersonasmes Errores PF Inversin o PF P ags.Doc PF

Las medidas de los puntos de funcin se disearon inicialmente para ser o n utilizadas en aplicaciones de sistemas de informacin de gestin pero Joo o nes ha realizado una serie de ampliaciones en las que los denomina Puntos de Caracter sticas del software, en las que se tiene en cuenta la complejidad algor tmica, que permiten realizar medidas en software de ingenier y a sistemas. Para aplicaciones convencionales de clculo de ingenier de sistemas de a a informacin los PF y los PC dan valores muy similares. No ocurre lo mismo o para sistemas ms complejos, en los que el PC es del orden de entre un 20 % a y un 35 % mayor que el PF.

2.2.3.

RECONCILIACION DE LAS DIFERENTES METRICAS

La relacin entre las LDC y los PF depende del lenguaje de programacin o o utilizado y de la calidad del diseo, y dicha relacin nos va a proporcionar n o una medida de productividad del software evaluado, medida que est soa metida evidentemente a errores debidos a la subjetividad con que se realice adems de otros factores que afectan directamente al software. Son los sia guientes: Factores humanos: tamao y experiencia de la organizacin de den o sarrollo. Factores del problema: complejidad del problema a resolver y el nmero de cambios en las restricciones o requisitos del diseo. u n
</i12YeMoM>

2. ESTIMACION DE LOS COSTES DEL PROYECTO SOFTWARE Pgina 20 a

Factores del proceso: tcnicas de anlisis y diseo utilizadas. e a n Factores del producto: abilidad y rendimiento del sistema basado en la computadora. Factores de los recursos: disponibilidad de herramientas CASE y recursos hardware y software. Una estimacin va a ser ms precisa si tiene una base histrica lo ms o a o a amplia y consolidada posible.

2.3.

TECNICAS DE ESTIMACION DE COSTES

Dentro de la mayor de las organizaciones la estimacin de costes se a o basa en experiencias pasadas. Estas estimaciones se pueden llevar acabo de forma jerrquica hacia abajo (top-down) donde el punto de referencia es el a coste del sistema, manejo de la conguracin, control de calidad. . . o hacia o arriba (bottom-up) donde se considera el coste de los distintos subsistemas para estimar el coste total de sistema.

2.3.1.

JUICIO DEL EXPERTO

Tcnica jerrquica hacia abajo. Es la ms ampliamente utilizada y se e a a basa en la experiencia, conocimiento anterior y sentido comercial de uno o ms individuos dentro de la organizacin. a o La experiencia, factor que en principio puede ser una ventaja, puede que se convierta en una desventaja debido a que el experto puede realizar una mala estimacin debido a la generalizacin del caso. o o

2.3.2.

TECNICA DELFI

Tcnica jerrquica hacia abajo. Intenta eliminar reuniones entre grupos e a para conseguir efectividad. Forma de ejecucin: o 1. 2. 3. 4. 5. Un coordinador proporciona a cada experto annimo una documentao cin. o Cada experto estudia la denicin y estima costes. o El coordinador realiza un resumen de todas las estimaciones. Si el coordinador ve algn razonamiento extrao, se env a los experu n a tos el resumen y se realiza una nueva estimacin. o Se vuelve al paso 3 tantas veces como sea necesario.

</i12YeMoM>

2. ESTIMACION DE LOS COSTES DEL PROYECTO SOFTWARE Pgina 21 a

TECNICA DELFI MODIFICADA Similar a la anterior slo que no evita reuniones de grupo, aunque s se o mantiene el anonimato. Si existe discrepancia en las estimaciones se discuten sobre ellas y si no se llega a una solucin el coordinador deber tomar una o a decisin. o

2.3.3.

ESTRUCTURAS DE DIVISION DEL TRABAJO

Tcnica jerrquica hacia arriba. Hace uso de un organigrama para reejar e a las diferentes partes del sistema y las jerarqu de productos o procesos. as Estas tcnicas son muy usadas. Pueden clasicarse en dos grupos segn e u realicen divisin de trabajo por producto o por procesos. o

2.4.

MODELOS DE ESTIMACION EMP IRICA

Un modelo de estimacin utiliza frmulas emp o o ricas para predecir los datos que se requieren en la etapa de planicacin del proyecto software. o Existen varios modelos de estimacin aplicables a unos u otros proyectos o segn sus caracter u sticas. Atendiendo a las mismas se pueden clasicar en: 1. 2. 3. 4. Modelos univariable estticos. a Modelos multivariable estticos. a Modelos multivariable dinmicos. a Modelos tericos. o Un modelo univariable esttico toma la forma: a Recurso = c1 (caracter sticaestimada)c2 Un modelo multivariable dinmico toma la forma: a Recurso = c11 e1 + c21 e2 . . .

2.4.1.

MODELO COCOMO

El Constructive Cost Model fue propuesto por Boem y es uno de los ms a ampliamente usados. Propone una serie de modelos con distintos grados de complejidad e informacin utilizada: o Modelo Bsico: a Modelo esttico que slo tiene en cuenta el tamao del programa y el a o n coste de desarrollo. Ecuaciones: PM = TD = a KLDC b c PMd
</i12YeMoM>

2. ESTIMACION DE LOS COSTES DEL PROYECTO SOFTWARE Pgina 22 a

Donde a, b, c y d vienen expresados en la siguiente tabla: CoCoMo Bsico a Modo Orgnico a Modo Semiacoplado Modo Empotrado a 2.4 3.0 3.6 b 1.05 1.12 1.20 c 2.5 2.5 2.5 d 0.38 0.35 0.32

Modelo Intermedio: Calcula el esfuerzo de desarrollo en funcin del tamao del software y o n un conjunto de gu de costeque incluyen una evaluacin subjetiva as o del producto, del software, del personal y de los atributos del proyecto. En base a esta evaluacin obtenemos un Factor de Ajuste (FA) que o nos va a permitir el clculo del esfuerzo: a P M = a KLDC b F A Donde a y b vienen expresados en la siguiente tabla: CoCoMo Bsico a Modo Orgnico a Modo Semiacoplado Modo Empotrado a 3.2 3.0 2.8 b 1.05 1.12 1.20

Modelo Avanzado: Incorpora todas las caracter sticas del modelo intermedio con una evaluacin del impacto de las gu de coste en cada fase del proceso de o as la IS. El modelo de CoCoMo est denido para tres tipos diferentes de proyeca tos: Modo Orgnico: Proyectos pequeos y sencillos con equipos pea n queos con buena experiencia que trabajan en un conjunto de requin sitos poco r gidos. Modo Semiacoplado: Proyecto software intermedio en el que trabajan equipos con distintos niveles de experiencia sobre requisitos poco y medio r gidos. Modo Empotrado: Proyectos software que deben ser desarrollados dentro de un conjunto estricto de hardware, software y restricciones operativas.

</i12YeMoM>

2. ESTIMACION DE LOS COSTES DEL PROYECTO SOFTWARE Pgina 23 a

2.4.2.

MODELO DE PUTNAM

Modelo univariable dinmico que asume una distribucin espec a o ca del esfuerzo a lo largo del ciclo de vida de un proyecto. Este modelo, aunque deriva de distribuciones de mano de obra de grandes proyectos es extrapolable pequeos y medianos proyectos. n Se puede utilizar la curva de Rayleigh-Norden para obtener una ecuacin o que relaciona el nmero de l u neas de cdigo esperadas con el esfuerzo y o tiempo de desarrollo, en la forma: LDC = Ck (P A) 3 (T DA) 3 Donde Ck es una constante de estado que puede los siguientes valores: Valor de Ck 2000 Descripcin o Para entorno pobre de desarrollo, sin metodolog modo de ejecucin no interactia, o vo, documentacin y revisiones pobres. o Para un buen entorno de desarrollo. Para un entorno excelente.
1 4

8000 11000

LDC es el nmero de l u neas esperadas de cdigo fuente, PA el esfuerzo o de desarrollo y mantenimiento y TDA el tiempo de desarrollo. La expresin anterior se puede reescribir de la forma: o PA =
(LDC)3 3 Ck (T DA)4

</i12YeMoM>

CAP ITULO 3

EL ANALISIS DE REQUISITOS
Es la segunda fase del proceso de duracin del proyecto software. En esta o fase se origina la documentacin tcnica en la que se especican los requisitos o e tcnicos que debe cumplir el software a un alto nivel de abstraccin y de e o forma concisa, consistente y sin ambigedades. u La Especicacin de Requisitos se basa en denir QUE es o consiste el producto que se desea consel producto, en QUE truir, en lugar de denir COMO ser ese producto. a Un documento ER deber contemplar los siguientes aspectos del produca to software: 1. 2. 3. 4. 5. 6. 7. Un resumen del producto y objetivo del mismo, as como los ambientes de desarrollo, operacin y mantenimiento. o Informacin sobre las interfaces externas y el ujo de la informacin, o o as como de los requisitos funcionales y de operacin. o Informacin sobre el manejo de las aplicaciones. o Descripcin de la arquitectura del sistema. o Informacin sobre los recursos necesarios. o Requisitos para la validacin del sistema. o Informacin de ayuda para el proceso de diseo o n

3.1.

PRINCIPIOS DEL ANALISIS DE REQUISITOS

Existen propuestos muchos mtodos para llevar a cabo el AR, cada uno e con notacin, reglas. . . distintos, pero con las siguientes caracter o sticas en comn: u 24

3. EL ANALISIS DE REQUISITOS

Pgina 25 a

Dominio de la informacin: o Dominio de los datos y de de las funciones. El dominio de la informacin contiene tres visiones diferentes de los datos que son procesados o por las funciones: 1. Flujo de la informacin: Cmo se mueve la informacin. Repreo o o senta como cambian los datos cuando pasan por el sistema. 2. Contenido de la informacin: Qu informacin se mueve y qu sigo e o e nica. Representa elementos de datos individuales que componen a otros elementos de mayor entidad. 3. Estructura de la informacin: Forma de la informacin dentro o o de la estructura del sistema. Organizacin lgica de los distintos o o elementos de datos individuales y relaciones entre ellos. Particin o descomposicin del problema: o o Generalmente un problema es demasiado complejo como para ser entendido como un todo. Se recurre a la divisin jerrquica del probleo a ma en la que se identiquen distintas partes, fciles de entender, y que a en conjunto realicen la funcin global del sistema. Conceptualmente o se establece una representacin jerrquica de la informacin y luego se o a o divide el elemento superior en base a las siguientes tcnicas: e 1. Incrementado de detalles: Nos movemos verticalmente en la jerarqu a. 2. Descomponiendo funcionalmente el problema: Nos movemos horizontalmente en la a jerarqu a. Representacin lgica y f o o sica: 1. Visin lgica: Funciones a realizar e informacin que deben proo o o cesar con independencia de detalles de implementacin. o 2. Visin F o sica: Representa una manifestacin del mundo de las o funciones de procesamiento y las estructuras de informacin. o

3.2.
3.2.1.

ESPECIFICACION DE LOS REQUISITOS


Actividades de la ERS

Consiste en tres actividades: Denicin de requisitos del software: o Tarea iterativa para crear una denicin o especicacin preliminar de o o los requisitos que debe cumplir el software.

</i12YeMoM>

3. EL ANALISIS DE REQUISITOS

Pgina 26 a

Denicin de los requisitos de las interfaces del software con o el resto del sistema y con el exterior: Denicin de las propiedades del software para que logre una interaco cin ecaz con otros elementos u otras aplicaciones software. o Integrar los requisitos en un documento de especicacin y o asignarles prioridades: Una vez descritos los requisitos deben ser revisados por el usuario vara su vericacin y validacin, por ello es necesario asignarles prioridao o des. Una vez realizada dicha revisin se genera un documento llamado o Especicacin de los Requisitos del software. o Raghavan propone otra forma de describir las actividades que se realizan durante la AR: Extraccin de requisitos. o Anlisis de requisitos. a Especicacin de requisitos. o Validacin de requisitos. o La realizacin de las mismas suele apoyarse en distintas tcnicas. As para o e la extraccin de los requisitos se emplean tcnicas de recogida de informao e cin como la observacin, entrevistas, grupos de trabajo. . . Para el anlisis y o o a especicacin existen tcnicas grcas como los Diagramas de ujo de datos. o e a Para la validacin suele recurrirse listas de comprobacin junto con listas de o o revisin. o

3.2.2.

TECNICAS DE RECOGIDA DE LA INFORMACION

Conjunto de tcnicas cuyo objetivo es mejorar la comunicacin usuae o rio/cliente e ingeniero durante la denicin del problema y especicacin de o o la solucin. o El proceso de recogida de informacin suele seguir los siguientes pasos: o 1. 2. 3. 4. 5. Identicar las fuentes de informacin. o Realizar preguntas adecuadas. Analizar la informacin recogida para ver qu aspectos quedan poco o e claros. Conrmar con los usuarios que se han comprendido los requisitos. Sintetizar los requisitos en un documento apropiado.

Las tcnicas principales utilizadas en esta actividad son: entrevistas, dee sarrollo conjunto de aplicaciones, prototipado, observacin, estudio de docuo mentacin, cuestionarios, tormenta de ideas (BrainStorming), ETHICS. . . o
</i12YeMoM>

3. EL ANALISIS DE REQUISITOS

Pgina 27 a

3.2.3.

ESPECIFICACION DE LOS REQUISITOS SOFTWARE

La ERS se dene como: La documentacin de los requisitos esenciales (funciones, o rendimiento, diseo, restricciones y atributos) del software n y de sus interfaces externas. La ERS debe por un lado incluir informacin veraz, coherente con las o necesidades reales del usuario y comunicarla de forma ecaz, pero adems a deber cumplir las siguientes caracter a sticas: No debe ser ambigua, por lo que cada requisito deber tener una unica a interpretacin. Para lograr este objetivo se puede hacer uso de leno guajes formales de especicacin de requisitos como por ejemplo el o Lenguaje Z. Debe ser completa. Debe ser fcil de vericar. a Debe ser consistente: los requisitos no deben ser contradictorios o entrar en conicto entre s Son fuentes de conictos las siguientes situa. ciones: 1. 2. 3. Dos o mas requisitos describen un mismo objetivo. Las caracter sticas especicadas de objetos reales pueden estar en conicto. Puede haber un conicto lgico o temporal entre dos acciones o determinadas.

Debe ser fcil de modicar. a Debe ser fcil de identicar origen y consecuencias de cada requisito. a Debe ser fcil de utilizar durante las fases de diseo, explotacin y a n o mantenimiento del software. Para lograr que una ERS tenga estas caracter sticas, Balzer y Goldman proponen ocho principios que deben satisfacer una buena especicacin: o 1. 2. 3. Una especicacin debe separa funcionalidad de implementacin. o o Se debe utilizar un lenguaje de especicacin formal orientado al proo ceso. Una especicacin debe abarcar al sistema en el cual el software se o implantar. a
</i12YeMoM>

3. EL ANALISIS DE REQUISITOS

Pgina 28 a

4. 5. 6. 7.

Una especicacin debe tener en cuenta el entorno del sistema softwao re. Una especicacin debe ser un modelo cognitivo, en lugar de un modelo o de diseo o implementacin. n o Una especicacin debe ser operativa. o Una especicacin debe ser tolerante a la incomplecin y ampliable. o o

Generalmente la ERS se va cambiando a medida que se avanza en el proceso de desarrollo del software puesto que en principio hay detalles que es imposible especicar. A pesar de esto debemos tener en cuenta que un requisito debe ser especicado de la forma ms completa posible y que si a se producen cambios en el mismo, identicarlos, controlarlos, informarlos e incluirlos en la ERS.

3.2.4.

ESPECIFICACION DE REQUISITOS DE LAS INTERFACES

Las interfaces externas del software juegan un papel crucial en el propio software puesto que es lo que el usuario percibe ms fcilmente y donde ms a a a inuyen sus preferencias. Las interfaces coinciden con las tradicionalmente llamadas Entradas/Salidas del sistema, haciendo referencia por un lado a pantallas de introduccin de o datos, sensores, cheros. . . como entradas y por otro a dilogos de informaa cin, listados o salidas en papel, cheros. . . como salidas de datos. o El objetivo de la denicin de las interfaces de E/S es la estabilidad del o modo en que el sistema va a interactuar con el exterior del mismo, siendo fundamental no slo contar con la opinin de los usuarios, sino con criterios o o que le ayuden a decidir qu es mejor para su trabajo. e

3.3.

VISION GENERAL DE LAS TECNICAS DE ESPECIFICACION DE REQUISITOS

Atendiendo a distintos enfoques se pueden realizar distintos tipos de clasicacin de las tcnicas de especicacin de requisitos. o e o 1. Segn la forma de representacin: u o Tcnicas grcas: Por s solas no sirven de mucho. Su verdadee a ra utilidad se encuentra al combinarla con otras tcnicas. Cada e tcnica utiliza una serie de iconos que representan una serie de e componentes de un aspecto particular del modelo.

</i12YeMoM>

3. EL ANALISIS DE REQUISITOS

Pgina 29 a

Tcnicas textuales: Se utilizan para especicar con ms detalle e a componentes. Se suelen utilizar como complemento de las tcnicas e grcas. a Marcos o plantillas: Se acogen a un formato preestablecido y se usan para especicar informacin sobre componentes denidos o por tcnicas grcas o para especicar informacin sobre otros e a o marcos de nivel superior. Ejemplo: Diccionario de datos. Tcnicas matriciales: Por s solas no constituyen una tcnica. e e Se apoyan en otras tcnicas de denicin haciendo uso de la ine o formacin obtenida por ellas y la comparan para comprobar en o qu medida se han cumplido los requisitos especicados. e 2. Segn el enfoque de modelacin bajo el que se crean modelos del sisteu o ma en base a su funcin, informacin y tiempo. Bajo esta perspectiva o o el sistema es analizado bajo los siguientes tres aspectos: Dimensin de la funcin: o o Diagrama de ujo de datos. Lenguaje estructurado. Arboles de decisin. o Tablas de decisin. o Diagrama de accin. o Diagramas de descomposicin funcional. o Diccionario de datos.

Dimensin en base a la informacin: o o Diagrama Entidad-Interrelacin. o Diagramas de estructura de datos (para representar la visin o lgica de EERR). o Matriz entidad/entidad (cuando el nmero de entidades e u interrelaciones es elevado). Dimensin en base al tiempo: o Listas de eventos. Diagramas de transicin de estados. o Redes Petri. Diagramas de la historia de vida de la Entidad. Matriz Evento/Entidad.

</i12YeMoM>

3. EL ANALISIS DE REQUISITOS

Pgina 30 a

3.4.

COMPROBACION DE LA ERS

Una vez realizada la especicacin de requisitos formada, al menos, por o los DFD, DD y especicaciones de procesos es necesario revisarla en base a: Complecin: Comprobando que los modelos son completos. o Integridad: Comprobando que no haya contradicciones ni inconsistencias. Exactitud: Comprobando que los modelos cumplen los requerimientos. Calidad: Comprobando el estilo, la legibilidad y la facilidad de mantenimiento de los modelos producidos.

</i12YeMoM>

CAP ITULO 4

TECNICAS DE ESPECIFICACION Y MODELACION


En el proceso de modelacin se suele dar ms importancia a una dimeno a sin del sistema que a otras dependiendo de las caracter o sticas del mismo. De este modo, las metodolog de desarrollo software se enfocan en una o as ms dimensiones dando ms importancia a las tcnicas que permiten crear a a e modelos desde este punto de vista. Cada tcnica de especicacin es utilizada en paralelo con una o varias e o tcnicas de modelacin del producto a desarrollar. e o

4.1.

ESPECIFICACION Y MODELACION DE LA FUNCION

Las tcnicas consideradas en este plano permiten desarrollar modelos en e el mbito de la informacin y en el funcional al mismo tiempo descompoa o niendo funcionalmente el sistema a distintos niveles de detalle.

4.1.1.

DIAGRAMAS DEL FLUJO DE DATOS

Es la tcnica ms difundida dentro del anlisis estructurado y se usa para e a a modelar las funciones que debe realizar el sistema y los datos que uyen entre ellas a distintos niveles de abstraccin. o Un diagrama de ujo de datos es una representacin en forma de red que o reeja el ujo de la informacin y las transformaciones que se aplican sobre o ella al moverse desde la entrada hasta la salida del sistema.

31

4. TECNICAS DE ESPECIFICACION Y MODELACION

Pgina 32 a

COMPONENTES DE UN DIAGRAMA DE FLUJO DE DATOS 1. Los procesos: Representa una funcin que transforma los ujos de datos de entrada en o uno o varios ujos de datos de salida. Un proceso debe ser capaz de generar los ujos de datos de salida a partir de los ujos de datos de entrada ms una informacin del proceso, es la a o regla de conservacin de los datos. Se pueden producir dos tipos de errores o de conservacin de datos: que a un proceso no le lleguen todos los datos o necesarios para obtener los datos de salida o que llegue algn componente u que no va a ser utilizado para generar el ujo de salida. Los procesos debe ir numerados y nominados. El nombre debe cumplir las siguientes caracter sticas: 1. 2. 3. Ser lo ms representativo posible de la funcin que especica, debiendo a o englobar a toda la funcin. o Ser breve. El nombre, junto con el nmero deben de ser unicos en el conjunto de u los DFD que representan al sistema.

Cuando se realizan los DFD lgicos, los procesos deben estar desligados o a cualquier connotacin f o sica (lugar donde se realiza el proceso, personas o dispositivos que realizan el proceso, etc). En los DFD f sicos si est permitido a incluir este tipo de connotaciones. 2. Almacenes de datos: Representa un espacio lgico de almacenamiento temporal donde se eno cuentra un dato en reposo. Caracter sticas: 1. 2. 3. 4. Cada almacn debe llevar un nombre que debe ser lo mas representae tivo posible de los datos almacenados en el mismo. Se puede representar varias veces en un DFD para mas legibilidad. En un DFD nivelado, el almacn se situar en el nivel ms alto. e a a Si en un DFD un almacn slo tiene conexin con un proceso, se dice e o o que el almacn es local y debe ser representado en el DFD donde se e represente dicho proceso. Un almacn tiene una estructura simple cuando es de tipo registro, e es decir, est formado por una sucesin de atributos en el que uno o a o varios identican cada ocurrencia en el almacn. e El contenido de los almacenes debe denirse en el Diccionario de Datos.
</i12YeMoM>

5.

6.

4. TECNICAS DE ESPECIFICACION Y MODELACION

Pgina 33 a

7.

Un almacn con estructura compleja es conveniente representarlo mee diante un diagrama Entidad-InterRelacin. o

3. Entidades externas: Representan un generador o consumidor de informacin del sistema ajeno o al mismo. Segn la metodolog puede tener una u otra representacin. Sus u a o aspectos ms signicativos son: a 1. 2. 3. Los ujos E/S de estas entidades denen la interfaz entre el sistema y el mundo exterior. Debe tener un nombre representativo y se pueden representar varias veces para mejorar la legibilidad. Por lo general aparecen en el DFD de mayor nivel (Diagrama de Contexto) aunque se pueden incluir en niveles inferiores.

4. Flujos de datos: Camino a travs del cual viajan los datos de composicin e o conocida de una parte del sistema a otra. Se representan por arcos dirigidos que indican la direccin del ujo. o Segn su persistencia en el tiempo pueden ser discretos (datos en moviu miento en un momento dado) o continuos (ujos de datos persistentes en el tiempo). Tipos de conexiones permitidas: Destino/Fuente Proceso Almacn e Entidad Externa Proceso S I SI S I Almacn e S I NO NO* Entidad Externa S I NO* NO

NO* indica que estas conexiones slo estn permitidas si el almacn de o a e datos externo sirve de interfaz entre sistema y entidad externa (aunque solo puede representarse en el diagrama de contexto). La conexin directa entre procesos slo se puede hacer si la informacin o o o es s ncrona, si no es as se deber crear un almacn que guarde los datos del a e proceso origen y los coja el proceso destino cuando los necesite. Los ujos de datos se pueden clasicar en: Flujo de consulta: El proceso utiliza la informacin del almacn para o e utilizar algunos valores de la misma o para comprobar que cumplan unos criterios determinados.

</i12YeMoM>

4. TECNICAS DE ESPECIFICACION Y MODELACION

Pgina 34 a

Flujo de actualizacin: Altera la informacin del almacn para crear o o e una ocurrencia de una entidad o interrelacin, borrarla o modicar el o valor de algn atributo. u Flujo de dilogo: Representa como m a nimo un ujo de consulta y otro de actualizacin. o Caracter sticas: 1. Debe tener un nombre signicativo del contenido de la informacin que o uye a travs de l. Si son ujos de E/S de almacenes simples, no tiene e e por qu estar nominados y tendrn la estructura de la informacin e a o contenida en dichos almacenes. El contenido de los ujos puede ser elemento (un campo), grupo (varios campos), par de dilogo (doble echa, dos nombres para indicar par a solicitud/respuesta) o mltiple (conjunto de ujo de datos). u Los ujos de datos no indican el control de ejecucin de los procesos o ni cuando va a comenzar o terminar un proceso.

2.

3.

4.1.2.

DESARROLLO DE NIVELES DE ABSTRACCION EN LOS DFD

Para representar modelo de un sistema grande es conveniente hacerlo por niveles y en forma descendente (top-down). Ventajas: Ayudar a construir la especicacin de arriba a abajo. o Los distintos niveles pueden ir dirigidos a personas diferentes. Facilita el trabajo de los analistas, permitiendo a los analistas trabajar de forma paralela. Facilita la documentacin. o Por tanto, un conjunto de DFD estar compuesto por: a Diagrama de contexto o de Nivel 0: Delimita la frontera del sistema con el mundo exterior deniendo los ujos de datos de entrada y salida. Su representacin ser una caja o a negra (el sistema completo) y un conjunto de entidades externas que representa procedencia y destino de la informacin del sistema junto o con los ujos correspondientes por donde circula dicha informacin. o Diagramas de niveles: Representan las funciones principales que debe realizar el sistema. Convienen que dichas funciones sean los ms independientes posible a para facilitar al analista la tarea de descomposicin y construir los o diagramas de niveles medios.
</i12YeMoM>

4. TECNICAS DE ESPECIFICACION Y MODELACION

Pgina 35 a

Procesos primitivos: Procesos atmicos que no pueden ser descompuestos. Para cada funo cin habr una especicacin que la describa. o a o La descomposicin de un diagrama se trata de una decisin subjetiva. o o Algunas reglas orientativas para saber cuando no hay que descomponer ms a son las siguientes: 1. 2. 3. Cuando un requisito funcional se pueda especicar en menos de una pgina. a Cuando los procesos tienen pocos ujos E/S. Cuando al descomponer una funcin en ms se pierde el signicado de o a la misma.

REGLA DEL BALANCEO Se usa para comprobar la consistencia entre los distintos niveles DFD. Se dene de la siguiente forma: Todos los ujos de datos que entran en un diagrama hijo, deben estar representados en el diagrama padre por el mismo ujo de datos entrando en el proceso asociado. Las salidas del diagrama hijo deben ser las mismas salidas del proceso padre asociado, exceptuando el caso de los rechazos triviales. En otras palabras, dado un conjunto de DFD y dado un ujo determinado, las salidas del proceso padre deben la suma de las salidas de los procesos hijo y la suma de las entradas a los procesos hijos deben ser la suma de las entradas al padre. Tambn deben tener las mismas etiquetas aunque si e no las tienen puede ser porque alguna entrada se bifurque en varias. Esta bifurcacin deber estar recogida en el diccionario de datos. o a NUMERACION Los DFD organizados por niveles debern estar numerados. La numeraa cin se realiza de la siguiente forma: o Cada diagrama recibe el nmero y nombre del proceso que se descomu pone. El diagrama de contexto se numera como 0. Los diagramas de nivel 1 se numeran desde 1 a N. En los restantes subniveles un DFD llevar el nmero identicador del que descompone a u mas un punto mas un entero que identique de forma un voca a dicho proceso.
</i12YeMoM>

4. TECNICAS DE ESPECIFICACION Y MODELACION

Pgina 36 a

4.1.3.

DICCIONARIO DE DATOS

Lista organizada de los datos utilizados por el sistema y que grcaa mente se encuentran presentes en los elementos del conjunto DFD (ujos, almacenes y datos), registrando, por tanto, tantas entradas como elementos haya. El DD se crea durante la fase de anlisis. a La denicin de los ujos siguen una aproximacin top-down, es decir, se o o denen unos componentes a partir de otros mas simples hasta llegar a los datos elementales (atributos o campos). Un ujo se puede denir tericamente o mediante la inclusin, seleccin e iteracin de sus componentes, adems de o o o a incluir otros componentes que aportan ms signicado a cada entrada del a DD. Los s mbolos ms comnmente utilizados son: a u S mbolo = [] {} () *texto* @ Signicado Composicin: est compuesto de, o es equivalente a o a Inclusin: y o Seleccin: seleccin de una de las opciones encerradas entre o o los corchetes y separadas por el signo |. Iteracin: iteraciones del componente encerrado entre las llao ves. Opcin: indica que el componente entre parntesis es opcioo e nal. Comentario: el texto entre asteriscos es un comentario. Identicador: se utiliza para sealar un campo o un conjunto n de campos que identican cada ocurrencia en un almacn. e

Los almacenes se denen como entidades repetitivas de datos y/o grupo de datos. En un DD se presentan alias cuando al modelar un sistema hay datos que se nombran de distinta manera y que, en realidad representan el mismo dato. El uso de estos alias, pero hay casos, como aquellos en los que se accede a un elemento desde rutas distintas o la nominacin de un mismo concepto o de forma distinta por varios analistas, en los que es necesario el uso de estos alias.

4.1.4.

DIAGRAMAS DE ACCION

Son una tcnica de especicacin que, a travs de una representacin e o e o jerrquica, representa la estructura lgica de transformacin de la informaa o o cin de entrada en la de salida. o

4.1.5.

TABLAS DE DECISION

Son una tcnica para denir una secuencia de acciones que realiza un e proceso primitivo.
</i12YeMoM>

4. TECNICAS DE ESPECIFICACION Y MODELACION

Pgina 37 a

Se caracterizan por ser un mtodo ecaz que permite representar situae ciones complejas de forma fcil, completa, comprobable y sin ambigedades a u mediante una representacin tabular estandarizada que indica las acciones o que deben ejecutarse cuando se cumplen una serie de condiciones. Las tablas de decisin permiten realizar las siguientes tareas: o Una exposicin global del problema a travs de una descripcin lgica o e o o de toma de decisin. o Representar de forma ordenada los distintos haciendo ms fcil la coa a dicacin. o Encontrar posibles errores por casos no considerados en el problema. Las tablas de decisin estn formadas por los siguientes componentes: o a Condiciones: Columna que recoge todos los casos presentes en el problema en estudio ordenados de forma ascendente segn su importancia. u Acciones: Acciones a realizar en la funcin/sistema. En una condicin se puede o o realizar varias acciones, en tal caso el orden de ejecucin es ascendente. o Entrada de condiciones: Matriz con tantas las como condiciones y tantas columnas como situaciones puedan producir esas condiciones. Salida de acciones: Matriz con tantas las como acciones y tantas columnas como situaciones puedan producir dichas acciones. Se denomina regla de decisin a un grupo de condiciones y a las aco ciones que se ejecutan cuando se cumplen esas condiciones. Estn formadas a por dos elementos: 1. Situacin: o Cada columna representada en la entrada de condiciones. Una situacin puede ser simple (se valoran todas las condiciones) o compuesta o (alguna condicin no se tiene en cuenta). o 2. Tratamiento: Cada columna representada en la matriz de salida de acciones. Existen tres tipos de reglas de condicin: o Regla AND: Se deben cumplir todos los valores de las condiciones. Si hay alguna condicin compuesta se marcar con el signo . o a
</i12YeMoM>

4. TECNICAS DE ESPECIFICACION Y MODELACION

Pgina 38 a

Regla OR: Se debe cumplir uno o ms de los valores de las condia ciones. Si hay alguna condicin compuesta se marcar con el signo o a . Regla ELSE: Cuando no se cumple una regla AND o una regla OR para indicar una alternativa de realizacin de acciones. o TIPOS DE TABLAS DE DECISION Binarias: La evaluacin de las condiciones est limitada a dos posibles valores: o a o NO o la reduccin de ambos. La entrada de acciones slo contiene SI o o el s mbolo X o el espacio en blanco, expresando si se produce o no esa accin. o Ejemplo: C1 C2 A1 A2 A3 A4 Condicin 1 o Condicin 2 o Accin 1 o Accin 2 o Accin 3 o Accin 4 o SI S I X X X SI NO X X NO S I X X X NO NO X X

M ltiples: u La evaluacin de las condiciones puede tener como solucin un rango o o de ms de dos valores. a Ejemplo: C1 C2 A1 A2 Condicin 1 o Condicin 2 o Accin 1 o Accin 2 o A A X A B X A C X B A X B B X X B C X C A X C B C C X X

Mixtas: Combinan condiciones que tengan dos posibles respuestas y otras que tengan ms de dos posibilidades. a Como norma general y para abreviar se suele trabajar slo con tablas o binarias y con reglas AND. Para condiciones y reglas que no sean as res pectivamente, se procede a una transformacin de las mismas. El proceso es o el siguiente: 1. 2. Transformacin de reglas OR en AND. Una regla OR que evala n o u condiciones equivale a n reglas AND. Transformacin de condiciones mltiples en simples. Una condicin o u o mltiple con n valores equivale a n condiciones binarias, consistentes u en transformar cada valor en una condicin. o
</i12YeMoM>

4. TECNICAS DE ESPECIFICACION Y MODELACION

Pgina 39 a

ANALISIS DE LAS TABLAS DE DECISION Para poder analizar y crear un procedimiento se deben cumplir cuatro reglas: 1. 2. 3. Que la tabla sea completa (si hay n condiciones, deber haber 2n a situaciones simples consideradas en la matriz de entrada). Eliminar redundancias (reglas repetidas) e incongruencias (una situacin recibe ms de un tratamiento). o a Simplicar la tabla. Si dos reglas tiene igual tratamiento y sus situaciones coinciden en todos los valores excepto en uno, se elimina esa situacin y se consideran como una unica regla compuesta. o Ordenar la tabla. A la izquierda las reglas de decisin ms importantes o a (mayor nmero de reglas simples a las que equivale) y hacia arriba las u condiciones ms importantes (suma de las importancias de las reglas a en la condicin que es evaluada). o

4.

Una vez ordenada la tabla se puede obtener el diagrama de ujo correspondiente. Para ello hay dos mtodos: e Forma compuesta: Cada regla se expresa mediante una pregunta utilizando operadores AND. A cada respuesta le corresponde un tratamiento. Forma simple: Se va desmenuzando cada una de las condiciones en sus posibles casos, ordenando las subtablas resultantes. El proceso concluye cuando slo o queda una condicin con sus dos valores posibles. o

4.1.6.

ARBOLES DE DECISION

Son diagramas que representan condiciones y sus prioridades y acciones. Estn formados por un elemento inicial (ra del rbol) donde comienza la a z a toma de decisiones, una serie de elementos nales (hojas) que son las acciones a realizar segn las decisiones tomadas y una serie de nodos intermedios que u son nodos que van a indicar condiciones y ruta por la que seguir segn la u toma de una decisin u otra. o Ventajas del uso de rboles de decisin: a o 1. 2. Ayuda a no pasar por alto de variables que van a inuir en la toma de una decisin en un momento dado. o Obligan a considerar una secuencialidad en la toma de decisiones.

</i12YeMoM>

4. TECNICAS DE ESPECIFICACION Y MODELACION

Pgina 40 a

En los rboles de decisin puede haber informacin tanto expl a o o cita como impl cita, por ello es util crear una lista de todos los datos utilizados en el proceso de decisin. o A pesar de que esta tcnica es una tcnica ecaz (obliga a tener en e e cuenta todos los parmetros a la hora de la toma de una decisin), presenta a o un problema cuando se trabaja con un sistema debido a la gran cantidad de ramas y trayectorias a considerar. En esos casos se suele optar por el uso de tablas de decisin. o

4.1.7.

REJILLAS DE DATOS

Es una tcnica util en todas las fases del diseo. Consiste en plasmar en e n un documento normalizado que se verica que todos los datos elementales de las salidas que el sistema deba proporcionar tienen un origen (chero, constante o dato variable) debiendo existir un equilibrio coherente entre las salidas que proporciona el sistema y los diferentes or genes. Un sistema global y completo debe vericar que: Toda salida tiene un origen. Todo dato introducido, memorizado o registrado debe ser usado para producir algn resultado. Esta regla puede no cumplirse en subsistemas u de un sistema global. Etapas y orden de realizacin de la tcnica: o e 1. 2. 3. 4. 5. Relacionar todos los datos elementales de las salidas. Determinar cules son los datos de salida derivables y/o acumulativos. a Relacionar todos los datos fuentes. Extraer e introducir los factores de clculo. a Depurar la regla (proceso a realizar en todos los pasos anteriores). Acciones a realizar en cada etapa: 1. Se crea una tabla. Las columnas son las salidas. Las las los datos elementales. Se marca con una X el cruce de de cada dato elemental con la(s) columna(s) de la(s) salida(s) en que gure. En la tabla se crea otra columna con identicador DERIVABLE y para cada dato elemental se aade en la columna D si es derivable o DA si n es derivable acumulativo. Se inscriben en la las del cuerpo izquierdo del impreso todos los datos no derivables y derivables acumulativos de la salida. Para ello hay dos alternativas:
</i12YeMoM>

2.

3.

4. TECNICAS DE ESPECIFICACION Y MODELACION

Pgina 41 a

a)

Si se est realizando un estudio de la situacin actual se realia o zar en las columnas del cuerpo izquierdo marcando con una X la a interseccin de las y columnas donde haya correspondencia. En o todas las las deber haber una X. a Si estamos tratando con un nuevo sistema para cada dato se har un estudio para ver si es variable o jo e indicarlo con V a o F.

b)

4.

Ver a partir de donde se obtienen todos los datos derivables y/o acumulativos. En el caso de que se usen constantes se deber indicar a marcando con una X la la correspondiente. Depuracin, para ver si hay datos de salida sin origen y datos fuente o sin utilizacin y ver donde est la fuente de error. A veces puede que o a se obtengan datos de salida cuyo origen es una constante o un dato condencial. En esto casos y por su carcter inmediato no aparecen a sobre un soporte externo.

5.

4.1.8.

DIAGRAMAS DE ESTRUCTURAS

Son diagramas de descomposicin funcional entre los que se distinguen o diferentes tipos segn los diferentes niveles de abstraccin en el que se apliu o quen y segn los diferentes detalles de la informacin que se representen en u o los mismos. Son la principal herramienta en el anlisis y diseo estructurado para a n representar la estructura de un sistema, subsistema o mdulo del mismo. o DIAGRAMAS DE YOURDON/CONSTATINE Elementos por los que estn compuestos: a Mdulo: o Conjunto de sentencias que realiza una actividad determinada. Se representa por una caja rectangular con su nombre dentro, siendo generalmente una sentencia de su funcin. Un mdulo predenido es un o o mdulo que no tiene que escribir debido a que ya existe en una lio brer del sistema o aplicacin y se representa igual que un mdulo a o o normal aadindole dos l n e neas paralelas e internas a ambos lados del rectngulo. a Conexin intermodular: o Indica conexin entre mdulos, reejando cmo cooperan los distintos o o o mdulos y qu informacin necesitan comunicarse para realizar una o e o tarea.

</i12YeMoM>

4. TECNICAS DE ESPECIFICACION Y MODELACION

Pgina 42 a

Comunicacin intermodular: o Los signos de comunicacin son datos y ags. Los datos se procesan y o estn relacionados con el mundo exterior; se representan por un c a rculo vac Los ags o informacin de control no se procesan; se representan o. o por un c rculo relleno. Llamada iterativa: Para representarla se utiliza un arco dirigido que abarca los mdulos o que estn dentro de la iteracin. a o Centro de transaccin: o Se utiliza para representar una invocacin condicional. Se representa o por un rombo relleno. Conectores y continuidad de una pgina: a Se usan para lograr ms legibilidad. Cuando un mdulo no quepa en a o una pgina, se sita al nal de pgina, y en la siguiente pgina se a u a a vuelve a colocar junto con sus subordinados y con una referencia de pgina. a DIAGRAMAS DE JACKSON Tcnica que permite representar las construcciones lgicas de secuene o cialidad, iteracin y opcionalidad a nivel arquitectnico y estructural del o o sistema. Caracter sticas de estos diagramas: Cada mdulo, funcin o proceso es representado por una estructura o o jerrquica mediante un rectngulo etiquetado, cuya etiqueta represena a ta al mdulo y debe ser unica. o La jerarqu es representada mediante arcos sin punta de echa. a El diagrama debe ser interpretado de arriba a abajo. Representacin de las construcciones: o Secuencia: Todos los mdulos de un mismo nivel son procesados o secuencial mente hacia la izquierda. Repeticin: Representada por el signo * en la parte superior deo recha del rectngulo. Un mdulo de repeticin representa el proa o o cesamiento iterativo de todos sus mdulos hijos. o Opcionalidad: Se representa mediante un c rculo vac en la parte o superior derecha del rectngulo. a En un mismo nivel del rbol slo puede haber mdulos del mismo tipo. a o o Un mdulo del diagrama slo puede tener un unico mdulo de repetio o o cin subordinado (hijo). o
</i12YeMoM>

4. TECNICAS DE ESPECIFICACION Y MODELACION

Pgina 43 a

Para que se cumplan estas caracter sticas se pueden introducir mdulos o cticios para lograr uniformidad entre niveles. Estos diagramas de pueden utilizar para muchos nes. Desde el punto de vista funcional pueden usarse para representar desde el sistema completo hasta para representar procesos primitivos. Desde el punto de vista de la informacin se usa para representar la estructura de los objetos de informacin o o pudindose usar, por ejemplo, para representar el DD de forma grca. e a

4.2.

ESPECIFICACION Y MODELACION DE LA INFORMACION

Con esta actividad se intenta describir el dominio de la informacin que o ser manejado por el sistema, describiendo cada uno de los items de datos a que son aceptados por el mismo, los cambios a los que son sometidos y los que el sistema devuelve como salida. Para ello se utilizan Diagramas Entidad-Interrelacin y Diagramas de Estructuras de Datos. o

4.3.

ESPECIFICACION Y MODELACION DEL COMPORTAMIENTO

Una especicacin del comportamiento de un sistema consiste en la deso cripcin del modelo dinmico del mismo, constituida por los aspectos relao a cionados con el tiempo y los cambios. Los conceptos ms importantes en el modelado dinmico son los sucesos, a a que representan est mulos externos, y los estados, que representan los valores de los objetos.

4.3.1.

DIAGRAMAS DE TRANSICION DE ESTADOS

Se usan para representar el comportamiento de un sistema en tiempo real. SUCESOS Y ESTADOS Un estado es el conjunto de valores de los atributos y las relaciones mantenidas en un objeto. A lo largo del tiempo los objetos se estimulan unos a otros dando lugar a una serie de cambios en sus estados. Se denomina suceso al est mulo individual proveniente de un objeto y que llega a otro. La respuesta a un suceso depende del objeto que lo recibe y del estado del mismo. Esta respuesta puede ser un cambio del estado del objeto o el env o de otro suceso al emisor o a un tercer objeto. La trama de sucesos, estados y transiciones de estados para una clase dada se denomina Diagrama de Transicin de Estados. El modelo dinmico consta de muchos DTE, uno para o a
</i12YeMoM>

4. TECNICAS DE ESPECIFICACION Y MODELACION

Pgina 44 a

cada clase de objeto que tenga un comportamiento dinmico importante, a mostrando la actividad para todo el sistema. Un suceso es algo que transcurre durante un tiempo pero que no tiene duracin (en comparacin con la abstraccin de la granularidad de la eso o o cala temporal usada). Los sucesos pueden estar relacionados, habiendo una secuencialidad lgica entre ellos, o no (sucesos concurrentes). Se puede cono siderar a un suceso como una transmisin de informacin (seales o datos) o o n de un objeto a otro. A la secuencia de sucesos que tiene lugar en un sistema se denomina escenario. La secuencia de sucesos y objetos que intercambian sucesos se puede mostrar en un escenario mejorado denominado Diagrama de Trazas o Seguimiento de Sucesos que reeja, adems de los sucesos entre los distintos a objetos, la secuencialidad de los mismos. Un estado corresponde al intervalo entre dos sucesos recibidos por un objeto, por tanto tiene duracin, ocupan un intervalo de tiempo. Un objeto o puede responder de forma distinta segn el estado en el que encuentre ante u un mismo suceso. Al denir estados realizamos una agrupacin en un unico o estado de las combinaciones de valores de atributos y relaciones que tiene una misma respuesta a los sucesos. DESARROLLO DE DIAGRAMAS DE TRANSICION DE ESTADOS Un Diagrama de Transicin de Estados relaciona sucesos y estados. Una o transicin es un cambio de estado. o Un DTE es un grafo cuyos nodos son estados (cuadros redondeados) y cuyos arcos dirigidos son transiciones rotuladas con los nombres de los sucesos que provocan dicha transicin (echa). o Todas las transiciones que salgan de un estado deben corresponder a sucesos distintos. Un DTE especica la secuencia de estados que causa una cierta secuencia de sucesos. Adems describe el comportamiento de una sola clase de objetos. a Los DTE pueden representar ciclos vitales unicos o bien bucles continuos. Los diagramas de un slo uso representan objetos de duracin nita y tienen o o estados iniciales y nales. El estado inicial se muestra mediante un c rculo negro. El estado nal se denota mediante un c rculo blanco. Una condicin es una funcin booleana lgica que tiene a objetos como o o o valores. Se puede denir un estado en trminos de una condicin o se puede estar e o en un estado en base a una condicin. o Las condiciones se pueden utilizar como protecciones en las transiciones. Una transicin con proteccin se dispara cuando se produce un suceso, pero o o slo si la condicin es verdadera. o o

</i12YeMoM>

4. TECNICAS DE ESPECIFICACION Y MODELACION

Pgina 45 a

Una actividad es una operacin cuya realizacin requiere un cierto tiemo o po. Una accin es una operacin instantnea que va asociada a un proceso. o o a La notacin para una accin que afecta a una transicin es una barra y o o o un nombre o descripcin despus del nombre del suceso que la produce. o e

4.3.2.

DIAGRAMAS DE LA HISTORIA DE VIDA DE LAS ENTIDADES

Muestra el ciclo de procesos de una entidad desde su creacin hasta o su desaparicin y proporcionan una forma de modelar todos los posibles o cambios de valor de sus atributos durante la vida de la entidad y la secuencia en que dichas actuaciones transcurren. En los D-HVE se utiliza la notacin de los diagramas de estructuras de o Jackson. La caja superior representa a la entidad, las cajas intermedias a los tipos de existencia y las hojas a los eventos y sus efectos. Proceso de creacin de los D-HVE: o 1. 2. Se crea la matriz evento/entidad. Se dibujan las primeras aproximaciones del D-HVE: a) b) Se seleccionan todas las entidades hijas y las padres. Se identican, a partir de la matriz evento/entidad los eventos responsables de la creacin y borrado de la entidad y se identican o las posibles secuencias de actuacin. o Se identican los eventos que producen cambios de en el estado de los atributos de las entidades y se representan.

c) 3. 4. 5.

Se revisa el D-HVE comprobando interacciones entre entidades y posibles excepciones. A cada hoja se le aaden las operaciones. n A cada hoja se le asigna un indicador de estado (atributo que cambia cada vez que una entidad se ve afectada por un evento). Para ello: a) b) c) d) Cada hoja tiene dos valores (antes y despus), con un valor inicial e que cambia con cada evento. El primer y ultimo valor son siempre nulos y se representan por . En una iteracin los indicadores vlidos previos incluyen al nuevo o a indicador vlido. a Si un indicador no cambia, se muestra con .

</i12YeMoM>

4. TECNICAS DE ESPECIFICACION Y MODELACION

Pgina 46 a

Los D-HVE proporcionan una validacin para los DFD y el modelo de o datos, muestran la evolucin de una entidad y mediante ellos se puede cono rmar qu procesos de actualizacin estn conectados a los almacenes de e o a datos ms importantes del DFD. a

4.4.

TECNICAS MATRICIALES

Surgen como consecuencia de aplicar una metodolog para el desarrollo a de los sistemas de informacin y la necesidad de realizar una vericacin de o o las distintas actividades desarrolladas. El objetivo de estas tcnicas es ayudar e realizar distintas vericaciones, como pueden ser entre datos y procesos, y para ayudar a comprender mejor el sistema.

4.4.1.

MATRIZ ENTIDAD/ENTIDAD

Son sistemas pequeos que se utilizan en sistemas grandes para aclararlos n marcando con una X el elemento de la matriz que relaciona a dos entidades. A veces se indica en los elementos de la matriz la cardinalidad en la interseccin o o bien el nombre de la relacin. o

4.4.2.

MATRIZ EVENTO/ENTIDAD

En estas matrices, las columnas corresponden a las entidades identicndolas en el Modelo Lgico de Datos, y las las corresponden a los evena o tos identicados en el diagrama del ujo de datos. Una vez identicadas las entidades y los eventos se deben relacionar mediante la matriz indicando qu efecto tiene cada evento sobre las entidades, y se ha de marcar en el e lugar correspondiente de la matriz, debiendo asegurarse que cada entidad es creada, de algn modo borrada y preferiblemente borrada alguna vez. u

4.4.3.

MATRIZ PAPEL DEL USUARIO/FUNCION

En esta matriz se muestra qu papel de usuario puede iniciar qu cone e junto de funciones. Cada interseccin en la matriz representa un dilogo y o a cada la identica todos los dilogos que necesita un usuario dado. Esta a matriz debe vericarse con los usuarios para asegurar su correccin y que se o han identicado todos los dilogos que se requieren y que ninguno de ellos a es superuo.

</i12YeMoM>

CAP ITULO 5

EL DISENO DEL SOFTWARE


El diseo es el primer paso en la fase de desarrollo de cualquier producto n o sistema de ingenier Se dene como: a. El proceso de aplicar distintas tcnicas y principios con el e propsito de denir un dispositivo, proceso o sistema con los o sucientes detalles como para permitir su realizacin f o sica. El objetivo es construir un modelo o representacin de entidad que o ser construido ms adelante. a a Una caracter stica del diseo del software es que cambia continuamente n conforme aparecen nuevos mtodos, mejores anlisis y ms conocimiento. e a a Se diferencia de los dems diseos en que se encuentra en una etapa muy a n temprana de su evolucin, faltndole profundidad, exibilidad y la natuo a raleza cuantitativa asociada normalmente con las disciplinas de diseo de n ingenier ms clsicas. as a a A pesar de sto, se han propuesto algunas normas a seguir y criterios e para cualicar un diseo, entre ellos los propuestos por Daris. n

5.1.

EL PROCESO DE DISENO

La importancia del diseo se basa en que en esta fase es donde se asienta n la calidad del desarrollo del producto. El diseo del software sirve de base n para todas las fases de desarrollo y el mantenimiento y el que asegura que el producto va a ser estable y de calidad. El diseo es un proceso mediante el que se traducen los requisitos n en una representacin del software que, inicialmente es hol o stica, para despus, debido a sucesivos renamientos, conducir a una representacin e o prxima al cdigo fuente. o o El diseo se realiza en dos etapas: n 1. Dise o preliminar: n Transformacin de los requisitos en estructuras de datos y arquitectura o del software. 47

5. EL DISENO DEL SOFTWARE

Pgina 48 a

2. Dise o detallado: n Renamiento de las estructuras de datos y de la arquitectura de la fase anterior. Llevar al diseo procedimental. a n La calidad del diseo se establecer mediante una serie de revisiones n a tcnicas formales. Para ello hay una serie de criterios: e Debe exhibir una organizacin jerrquica. o a Debe ser modular. Debe contener una representacin distinta y separable de datos y proo cedimientos. Debe conducir a mdulos que exhiban caracter o sticas funcionales independientes. Debe derivarse usando un mtodo repetible conducido por la informae cin obtenida en el anlisis de requisitos. o a Estas caracter sticas se consiguen a base de revisiones y aplicando metodolog y herramientas. Existen muchos tipos de stas, pero todas tienen as e los siguientes puntos en comn: u 1. 2. 3. 4. Un mecanismo de traslacin de la representacin del dominio de la o o informacin en representacin de diseo. o o n Una notacin para representar componentes e interfaces. o Heur sticas para el renamiento y particin. o Criterios para la valoracin de la calidad. o

5.2.

CONCEPTOS FUNDAMENTALES DEL DI SENO


ABSTRACCION

5.2.1.

Actividad intelectual que permite trabajar con conceptos y no con instancias particulares de los mismos. Hay tres tipo: Abstraccin funcional: o Incluye el uso de subprogramas parametrizados, que permitirn aislar a comportamientos iguales pero distintos resultados dependiendo de los parmetros. a

</i12YeMoM>

5. EL DISENO DEL SOFTWARE

Pgina 49 a

Abstraccin de datos: o Especicacin de los tipos de datos u objetos eliminando detalles de la o representacin y manipulacin. Sus caracter o o sticas internas son visibles unicamente para las funciones que los manipulan, quedando ocultas para otros grupos que los utilicen (igual concepto que en C++ para tipos abstractos de datos). Puede haber adems una jerarquizacin, a o construyndose un tipo abstracto a partir de otros tipos abstractos. e Abstraccin de control: o Se usa para establecer un efecto deseado sin necesidad de denir el mecanismo exacto del control. Por ejemplo las proposiciones SI o MIENTRAS.

5.2.2.

OCULTACION

Consiste de la ocultacin de los detalles internos de cada mdulo, produo o cindose la comunicacin intermodular a travs de interfaces bien denidas. e o e Esta tcnica se basa en que los mdulos deben especicarse y disearse e o n de forma que la informacin contenida dentro de los mismos sea inaccesible o a otros mdulos que no necesiten dicha informacin. o o La ocultacin ayuda a conseguir ms efectividad en la modularizacin o a o haciendo que se intercambie unicamente la informacin necesaria. Ayuda o tambin en la tarea mantenimiento y la modicacin del software y hace e o que los errores se propaguen con menos probabilidad. El diseo debe comenzar con una lista de decisiones dif n ciles y otra con decisiones que probablemente se modiquen. Cada mdulo debe ocultar eso tas decisiones a los dems mdulos. Adems de ocultar estas decisiones se a o a pueden considerar los siguientes puntos como sujetos a la ocultacin: o Una estructura de datos, su ligado de datos y los detalles internos de la implementacin de los procedimientos (principio de abstraccin de o o datos). El formato de bloques de control. Los cdigos de caracteres, el ordenamiento de conjuntos de caracteres o y otros detalles de instrumentacin. o El corrimiento y enmascaramiento de informacin binaria. o

5.2.3.

MODULARIDAD

Un sistema modular consiste en unidades claramente denidas y manejables con las interfaces claramente denidas entre los diversos mdulos. o Propiedades de un sistema modular:

</i12YeMoM>

5. EL DISENO DEL SOFTWARE

Pgina 50 a

Cada abstraccin de un proceso es un subsistema claramente denido o y con el potencial de ser util para otras aplicaciones. Cada funcin en cada abstraccin tiene un propsito espec o o o co, claramente denido. Cada funcin maneja no ms de una estructura de datos del sistema. o a Las funciones comparten datos globales en forma selectiva. Es fcil de identicar todas las subrutinas. a Las funciones que manejan instancias de un tipo abstracto de datos quedan encapsuladas con la estructura de datos en cuestin. o La modularidad es un enfoque aceptado en todas las disciplinas. Reduce la complejidad, facilita la implementacin, mejora la claridad del diseo, o n facilita las pruebas, depuracin y documentacin. . . o o Cada mdulo debe tener un tamao intermedio. Tanto entorpece la moo n dularizacin a gran escala como a baja escala. o

5.2.4.

CONCURRENCIA

Los sistemas de programacin pueden clasicarse en secuenciales y cono currentes. Los secuenciales slo tienen en ejecucin una pequea parte de o o n los mismos. Los concurrentes tiene procesos independientes ejecutndose sia multneamente. a Los sistemas concurrentes presentan problemas de bloqueo (varios procesadores bloqueados esperando a que otros acaben una operacin), exclusin o o mutua (error en el acceso a una variable compartida por varios procesos) y sincronizacin (comunicacin entre procesos lentos y rpidos). o o a

5.2.5.

VERIFICACION

Un diseo es vericable si puede demostrarse que el producto satisface n los requisitos del cliente. Pasos para la vericacin: o 1. Vericacin de requisitos: Los requisitos de programacin satisfacen o o las necesidades del cliente. 2. Vericacin del diseo: El diseo satisface la denicin de los requisio n n o tos.

5.2.6.

ESTETICA

Las consideraciones estticas como simplicidad, elegancia y claridad son e fundamentales en el diseo. n Es dif establecer criterios para evaluar factores estticos, sin embargo cil e un producto estticamente agradable es fcilmente reconocido. e a
</i12YeMoM>

5. EL DISENO DEL SOFTWARE

Pgina 51 a

5.2.7.

ESTRUCTURA DEL PROGRAMA

El uso de una estructuracin permite que un sistema grande sea denido o en trminos de unidades ms pequeas y manejables con una clara denicin. e a n o La estructura de programa representa la organizacin de los componeno tes del mismo e implica una jerarqu de control. Esta estructura se puede a representar de varias formas, aunque el mtodo ms comn es en forma de e a u a rbol.

5.2.8.

PROCEDIMIENTOS SOFTWARE

El procedimiento del software se enfoca sobre los detalles de procedimientos de cada mdulo individualmente. o El procesamiento debe dar una especicacin precisa del procedimiento, o incluyendo secuencia de sucesos, puntos de decisiones exactos, operaciones repetitivas e incluso organizacin/estructura de datos. o

5.2.9.

REFINAMIENTO

El renamiento sucesivo es una estrategia temprana del diseo descenn dente y consiste en ir renando jerrquicamente, de forma descendente hasta a llegar a sentencias del lenguaje de programacin. o Cada paso de renamiento implica algunas decisiones de diseo. A medin da que se avanza en el renamiento se ampl la declaracin original, dando a o ms detalles sobre el diseo. Por este motivo el renamiento podr consia n a derarse como un proceso de elaboracin. o

5.3.

EL DISENO MODULAR

Se trata del mtodo de diseo ms aceptado. Un diseo modular reduce e n a n la complejidad, facilita los cambios y da como resultado una implementacin o ms fcil, posibilitando el desarrollo paralelo de diferentes partes del sistema. a a

5.3.1.

TIPOS DE MODULOS

Dentro de una estructura software un mdulo puede ser categorizado o como: Mdulo secuencial: o Se referencia y ejecuta sin interrupcin aparente. Son los ms frecueno a tes. Mdulo incremental (corrutina): o Puede ser interrumpido y restablecido posteriormente. Estos mdulos o mantienen un puntero de entrada que permite al mdulo restablecer o el punto de interrupcin. o
</i12YeMoM>

5. EL DISENO DEL SOFTWARE

Pgina 52 a

Mdulo paralelo (conrutina): o Se ejecuta simultneamente con otro u otros mdulos en entornos de a o multiprocesadores paralelos. Las corrutinas y conrutinas requieren unos mtodos especiales de diseo e n desde las primeras etapas del desarrollo. Caracter sticas de los mdulos: o Contienen instrucciones, lgica de proceso y estructuras de datos. o Pueden ser compilados de forma individual y usados o almacenados como bibliotecas. Pueden incluirse dentro de un programa. Se pueden usar invocando un nombre y cero o ms parmetros. a a Pueden usar a otros mdulos. o Existen muchos criterios para denir la modularidad del sistema que van a determinar las estructuras resultantes para un sistema. Entre ellos: El criterio convencional: Cada mdulo junto con sus subordinados coo rresponden a un paso del proceso en la secuencia de ejecucin. o El criterio de ocultacin: Cada mdulo oculta a otros mdulos una o o o decisin dif o modicable del diseo. o cil n El criterio de abstraccin de datos: Cada mdulo oculta detalles de o o representacin y manipulacin de la informacin. o o o Niveles de abstraccin: Los mdulos y colecciones de mdulos proporo o o cionan una jerarqu de servicios ms complejos. a a Acoplamiento y cohesin: Estructuracin del programa para lograr la o o mxima cohesin y el m a o nimo acoplamiento. Modelizacin de problemas: La estructura modular de un problema se o ajusta a la estructura del problema a resolver.

5.3.2.

INDEPENDENCIA FUNCIONAL

Es una derivacin directa del concepto de modularidad y los conceptos o de abstraccin y ocultacin de la informacin. Consiste en disear software o o o n de forma que cada mdulo se enfoca a una subfuncin espec o o ca de requisitos y tenga una interfaz sencilla. La independencia funcional se mide usando criterios cualitativos de cohesin y acoplamiento. o

</i12YeMoM>

5. EL DISENO DEL SOFTWARE

Pgina 53 a

COHESION Es una medida de la fuerza esttica de un mdulo. Se trata de una a o extensin del concepto de ocultacin. Un mdulo coherente ejecuta una tarea o o o sencilla necesitando poca interaccin con otros mdulos. Tipos de cohesin: o o o Coincidental: Un mdulo ejecuta tareas poco relacionas con otras. o Lgica: Un mdulo ejecuta tareas relacionadas de forma lgica. o o o Temporal: Tareas relacionadas por tenerse que producir dentro de un tiempo. Procedimental: Los elementos de procesamiento estn relacionados a y deben ejecutarse de forma secuencial. Comunicacin: Todos los elementos de procesamiento se concentran o en un rea de una estructura de datos. a Secuencial: Cuando la salida de un elemento es la salida para el siguiente. Una cohesin baja provoca grandes prdidas de eciencia. Una cohesin o e o media tiene una eciencia bastante similar a la de la cohesin alta. El obo jetivo es por tanto conseguir una cohesin lo ms alta posible y detectar y o a eliminar la cohesin baja. o Stevens propone una tcnica util para determinar si un mdulo est acoe o a tado funcionalmente es escribir una sentencia que describa la funcin del o mdulo y luego hacer un chequeo de la misma: o 1. Si la descripcin est formada por una sentencia compuesta el mdulo o a o ejecutar ms de una funcin. Por tanto tendr una cohesin secuencial a a o a o o de comunicacin. o Si tiene palabras relativas al tiempo ser una cohesin secuencial o a o temporal. Si el predicado no contiene un objeto despus del verbo ser una cohee a sin lgica. o o Palabras como inicializar, limpiar. . . indican una vinculacin tempoo ral.

2. 3. 4.

ACOPLAMIENTO El acoplamiento es una medida de la independencia relativa entre los mdulos. En el diseo software se busca un acoplamiento lo ms bajo posible o n a para que sea ms fcil de comprender y menos propenso a la propagacin a a o
</i12YeMoM>

5. EL DISENO DEL SOFTWARE

Pgina 54 a

de errores. El acoplamiento se consigue mediante el paso de argumentos sencillos (datos simples). Tipos de acoplamiento (de menor a mayo importancia): 1. 2. 3. 4. 5. 6. No directo: Mdulos independientes. o De datos: Paso de datos simples. Por estampado: Paso de una porcin de una estructura. o De control: Acoplamiento entre mdulos y dispositivos. o Comn: Varios mdulos referencian a un rea de datos global. u o a Por Contenido: Se produce cuando un mdulo hace uso de control o de o datos mantenidos dentro de los l mites de otro mdulo o bien cuando o se bifurca a mitad de un mdulo. o

Se podr permitir hasta un acoplamiento por estampado, los dems a a tipos de acoplamiento deben evitarse todo lo que sea posible. Los programas con acoplamientos considerables consumen mucho tiempo y si tienen errores son dif ciles de resolver. Fuentes del acoplamiento son debidos generalmente a decisiones en el diseo que se hacen cuando se desarrolla la estructura, aunque tambin n e puede producirse acoplamiento externo durante la codicacin. o

5.4.
5.4.1.

ACTIVIDADES DEL DISENO


DISENO DE DATOS

Es la primera, y se podr considerarse la actividad ms importante del a a diseo, dependiendo de sta de forma directa la complejidad y calidad del n e software. Segn Wasserman el proceso de diseo de datos puede se resumir en: u n La actividad primaria es seleccionar representaciones lgicas de objetos o de datos identicadas en la ER. El proceso de seleccin puede implicar anlisis de algoritmos de eso a tructuras alternativas, el uso de mdulos. . . o Identicar los mdulos del programan que van a operar directamente o sobre las estructuras lgicas para as restringir el mbito del efecto de o a las decisiones de diseo de datos individuales. n La tarea de diseo de datos suele formar parte del anlisis de requisin a tos. Un buen diseo conduce a que el software tenga una buena estructura, n modularidad y menor complejidad procedimental. Un diseo de datos debe cumplir los siguientes puntos: n
</i12YeMoM>

5. EL DISENO DEL SOFTWARE

Pgina 55 a

1. 2. 3. 4. 5. 6. 7.

Los mtodos de anlisis sistemtico aplicados al software deben aplie a a carse tambin a datos. e Deben identicarse todas las estructuras de datos y operaciones sobre ellas. Debe establecerse y crearse un diccionario de datos. Las decisiones de diseo de datos a bajo nivel debe retrasarse a las n ultimas etapas del diseo. n La representacin de la estructura de datos debe ser conocida slo por o o los mdulos que hagan uso directo de ella. o Debe desarrollarse una biblioteca de datos utiles o reusables y opera ciones que se pueden realizar con ellos. El diseo software lenguaje usado deben soportar operaciones con tipos n abstractos de datos.

5.4.2.

DISENO ARQUITECTONICO

Su objetivo es desarrollar una estructura de programa modular y representar las relaciones de control entre los mdulos. El diseo arquitectnico o n o mezcla la estructura del programa y la estructura de datos y dene las interfaces que facilitan el ujo de datos a lo largo del programa, lo que aporta una visin general del programa. o

5.4.3.

DISENO PROCEDIMENTAL

Se realiza despus de establecer la estructura del programa y de los datos. e Consiste en una descripcin completa y sin ambigedades de los distintos o u algoritmos en lenguaje natural, pero es el uso del lenguaje natural el que provoca las ambigedades, pues muchas interpretaciones dependen del contexto u donde se hagan. Esto ha dado lugar a numerosas investigaciones, algunas como la de Dijkstra que propone un conjunto de construcciones lgicas con las que se o puede formar cualquier programa. En otras tcnicas se combinan diagramas de ujos y lenguaje natural e para deniciones ms complejas. a

</i12YeMoM>

CAP ITULO 6

LAS PRUEBAS SOFTWARE


Es un elemento cr tico para garantizar la calidad del producto. El asegurar el buen funcionamiento de un producto software es un hecho que cada vez tiene ms importancia. a La prueba es un paso destructivo consistente en intentar derribar el trabajo realizado con el n de vericar y validar el software. Una vericacin se puede denir como: o El proceso de evaluacin de un sistema o uno de sus como ponentes para determinar si los productos de una fase dada satisfacen las condiciones impuestas al comienzo de dicha fase. Por otra parte la validacin puede denirse como: o El proceso de evaluacin de un sistema o uno de sus como ponentes durante o al nal del proceso de desarrollo para determinar si satisface los requisitos especicados. Es conveniente conocer algunos de los trminos que se utilizan en esta e fase del ciclo de vida: Prueba: Actividad en la que un sistema o algunos de sus componentes se ejecuta bajo circunstancias especicadas y que da unos resultados que se observan, registran y evalan. u Caso de prueba: Conjunto de entradas, condiciones de ejecucin y resultados esperados o desarrollados para un objetivo particular. Defecto: Defecto software como un proceso, denicin de datos, procesamieno to. . . incorrectos. Fallo: Incapacidad del sistema o algunos de sus componentes para realizar una funcin. o 56

6. LAS PRUEBAS SOFTWARE

Pgina 57 a

Error: Varias acepciones: La diferencia entre el valor calculado y el valor verdadero. Un defecto. Un resultado incorrecto. Accin humana que conduce a un resultado errneo. o o

6.1.

OBJETIVO DE LAS PRUEBAS

Las principales caracter sticas del software (ausencia de leyes que rijan su comportamiento) hacen dif la tarea de probarlo. Es ms, estas caraccil a ter sticas hacen imposible la realizacin una prueba exhaustiva al software. o Se ha de tomar una actitud o losof para realizar esta labor. Ser la a a siguiente: El objetivo de una prueba es descubrir un error. Un buen caso de prueba es aquel que tiene una gran probabilidad de descubrir un error no descubierto hasta entonces. Una prueba tiene xito si descubre un error no detectado hasta entone ces. Si con las pruebas no se detectan errores se llega a la conclusin de que o el software parece funcionar de acuerdo a las especicaciones alcanzando los requisitos de rendimiento. Sin embargo esto no garantiza la ausencia de errores. Myers realiza las siguientes recomendaciones para las pruebas: 1. 2. 3. 4. 5. 6. Cada caso de prueba debe denir el resultado de salida esperado. Si discrepancia es s ntoma de error y posible defecto en el software. El programador debe evitar ser quien realice las pruebas puesto que stas ser menos rigurosas de lo deseable. e an Se debe hacer una inspeccin detallada del resultado de cada prueba o para no pasar por alto s ntomas de error. Al realizar una prueba se debe hacer con datos de entrada vlidos y a no vlidos o inesperados. a Una prueba debe comprobar por un lado que el software hace lo que debe hacer y por otro que el software no hace lo que no debe hacer. Se deben evitar casos desechables, es decir, es necesario documentar o guardar los casos para as no repetir constantemente el diseo de casos n de prueba.
</i12YeMoM>

6. LAS PRUEBAS SOFTWARE

Pgina 58 a

7. 8. 9.

No deben hacerse planes de prueba suponiendo que apenas hay errores, sino asumiendo que siempre los hay y hay que detectarlos. Parece ser que donde se encuentra un defecto suele haber ms. a Las pruebas son una tarea creativa, debiendo recurrir al ingenio y hacer uso de los recursos disponibles para alcanzar un buen nivel de deteccin de defectos. o

6.2.

EL PROCESO DE PRUEBA

El primer paso es generar un plan de pruebas base en base a la documentacin sobre el proyecto y la documentacin sobre el software a probar. A o o partir de ste se generan pruebas espec e cicas. Una vez detalladas se coge la conguracin del software a probar para ejecutar sobre ella los casos. Las o salidas se debern documentar y comprobar con la salida esperada. A partir a de sta se van a realizar dos actividades: e 1. La depuracin: o Para intentar corregir los defectos, aunque no siempre se asegura la correccin por lo que una vez realizada se deber volver a probar (con o a las pruebas anteriores y/o con otras nuevas) el software para ver si est resuelto. a 2. Anlisis de la estad a stica de errores: Para predecir errores y detectar causas habituales de error. A medida que se van realizando pruebas se va viendo la calidad del software que se est analizando. Si se obtienen errores serios es debido la a calidad del diseo y del software quedan en entredicho. Si se obtienen errores n leves es o porque es un software de calidad y able o bien porque las pruebas no son adecuadas. Si la prueba no descubre errores queda la sospecha de que la prueba no es demasiado buena, y lo normal es que el usuario vaya descubriendo los errores de forma eventual.

6.3.

TECNICAS DE DISENO DE LOS CASOS DE PRUEBA

Como se dijo anteriormente realizar una prueba exhaustiva del software es imposible. Los casos de prueba se limitan, por tanto, a ver si el software tiene un nivel de conanza aceptable intentando detectar los defectos existentes sin necesidad de consumir una cantidad excesiva de recursos.

</i12YeMoM>

6. LAS PRUEBAS SOFTWARE

Pgina 59 a

Para detectar los errores se ha de realizar una seleccin de pruebas pero o no de forma aleatoria, sino aquellas que se consideren representativas de un conjunto de ellas. Para ello podemos atender a los siguientes criterios: El enfoque estructural (caja blanca): Se centra en la estructura interna y es una prueba exhaustiva que busca probar todos los posibles caminos de ejecucin. o El enfoque funcional (caja negra): Estudia la especicacin de las funciones y las E/S. La prueba exo haustiva consiste en probar todas las posibles entradas y salidas del programa. El enfoque aleatorio: Utiliza modelos que representan las posibles entradas al programa a partir de los cuales crear casos de prueba. La prueba exhaustiva consiste en probar todas las posibles entradas al programa.

6.3.1.

LAS PRUEBAS ESTRUCTURALES (CAJA BLANCA)

Myers introduce un ejemplo para visualizar la imposibilidad de realizar la prueba exhaustiva: En un programa de 50 l neas con 25 sentencias IF en serie, existe un nmero total de caminos que contienen 33,5 millou nes de sentencias potenciales (contando dos posibles salidas para cada IF que suponen 225 posibles caminos.) Para disear los casos hay que elegir los caminos importantes que ofrezn can una seguridad aceptable en descubrir defectos. Para ello se utilizan criterios de cobertura lgica que: o Garanticen que se ejecutan al menos una vez todos los caminos independientes de cada mdulo. o Se ejercitan todas las decisiones lgicas en sus caras verdaderas y falsas. o Se ejecutan todos los bucles en sus l mites y con sus l mites opcionales. Se ejecutan las estructuras de datos internas para asegurar su validez. Estas tcnicas no requieren ninguna representacin grca, aunque es e o a habitual el uso de diagramas de ujo de control. Realizacin de estos diao gramas: 1. Sealar sobre el cdigo cada condicin de cada decisin. n o o o

</i12YeMoM>

6. LAS PRUEBAS SOFTWARE

Pgina 60 a

2. 3.

Agrupar el resto de sentencias situadas entre cada dos condiciones segn los esquemas de representacin de las estructuras bsicas. u o a Numerar tanto condiciones como grupos de sentencias, asignndole un a identicador unico. Para ello se recomienda: a) b) Alterar el orden de la restricciones en decisiones multicondicionales de mayor a menor restriccin. o Identicar los nodos que representan condiciones asignndoles a una letra y sealar cual es el resultado de las aristas que surn gen de ellos. Por ejemplo, de una condicin saldrn dos aristas, o a VERDADERO y FALSO, pues estos valores representarlos en cada una de ellas.

Myers propone la siguiente clasicacin para los criterios de cobertura o lgica: o Cobertura de sentencias: Generar casos de prueba para que se ejecuten todas las sentencias del programa al menos una vez. Cobertura de decisiones: Escribir sucientes casos como para que se de en cada decisin al o menos una vez un valor verdadero y falso. Engloba a la cobertura de sentencias. Cobertura de condiciones: Disear tantos casos de prueba como para que se den los dos resultados n de las condiciones al menos una vez en todas las decisiones. Cobertura de decisin/condicin: o o Hacer que se cumpla tanto el criterio de condiciones haciendo que se cumpla el criterio de decisiones. Criterio de condicin m ltiple: o u Consiste en descomponer una decisin multicondicional en varias deo cisiones unicondicionales para as evaluar todas las combinaciones po sibles de soluciones en una condicin. o PRUEBAS DEL CAMINO BASICO Es el criterio ms importante a considerar en este tipo de pruebas. Se a dene como: La secuencia de sentencias encadenadas desde la sentencia del nal hasta su sentencia nal.

</i12YeMoM>

6. LAS PRUEBAS SOFTWARE

Pgina 61 a

Debido a que existe una gran cantidad de caminos posibles se intenta hacer una reduccin. Para ello se introduce el concepto de camino de prueba: o Camino del programa que atraviesa, como mximo una vez, a el interior de cada bucle que encuentra. McCabe propuso la prueba del camino bsico como un tipo de prueba a de caja blanca. Este camino permite al diseador derivar una medida de la n complejidad lgica y usarla como gu de un conjunto de caminos bsicos de o a a ejecucin. Esta medida es complejidad ciclomtica y aporta el l o a mite superior para el nmero de pruebas que se deben realizar para asegurar que cada u sentencia se ejecuta al menos una vez. Un camino independiente es cualquier camino del programa que introduce por lo menos un nuevo conjunto de sentencias de procesamiento o una nueva condicin. En trminos del o e grafo de ujo, un camino independiente se debe mover por lo menos por una arista que no haya sido recorrida anteriormente. La complejidad ciclomtica se puede expresar mediante una de las sia guientes expresiones: V (G) = V (G) = V (G) = Donde: A: Nmero u N: Nmero u R: Nmero u C: Nmero u de de de de AN +2 R C +1

aristas. nodos. regiones cerradas del grafo. nodos predicado (condicin) del grafo. o

Un nodo predicado es aquel que contiene una condicin y se o caracteriza porque de l emergen dos o ms aristas. e a Procedimiento a seguir para la derivacin de los casos de prueba: o 1. 2. 3. 4. Dibujar el grafo de ujo. Determinar la complejidad ciclomtica. a Determinar el conjunto bsico de caminos linealmente independientes. a Preparar los casos de prueba que forzarn la ejecucin de cada camino a o del conjunto bsico. a

</i12YeMoM>

6. LAS PRUEBAS SOFTWARE

Pgina 62 a

Es posible mecanizar la determinacin del conjunto bsico de caminos a o a travs de la matriz de conexiones. El clculo de de la complejidad ciclomtica e a a se puede calcular tambin haciendo uso de esta matriz, aadindole una e n e nueva columna en el que cada elemento ser la suma de los elementos la a de dicho elemento menos uno. La complejidad ciclomtica ser el sumatorio a a de los elementos de esta columna ms uno. a La experimentacin con mtrica de McCabe ha dado las siguientes cono e clusiones: 1. 2. V(G) marca un l mite m nimo del nmero de casos de prueba para un u programa (cada condicin como un nodo individual). o Si V(G) es mayor de 10 y no es debida a sentencias CASE-OF o similares, la probabilidad de error crece mucho. Conviene en estos casos modularizar ms. a

LA PRUEBA DE LOS BUCLES Tcnica de prueba que se centra en validar las construcciones de los e bucles. Se distinguen cuatro tipo de bucles: Bucles simples: Pruebas a realizar (n: mximo de pasos en el bucle): a 1. 2. 3. 4. 5. Pasar por alto el bucle. Pasar una sola vez por el bucle. Pasar dos veces por el bucle. Pasar m veces por el bucle siendo m < n. Pasar n 1, n y n + 1 veces por el bucle.

Bucles anidados: Para evitar la realizacin de un nmero muy elevado de pruebas deo u bemos usar la siguiente tcnica propuesta por Beizer. e 1. 2. Comenzar en el bucle ms exterior. Establecer los dems bucles a a en sus valores m nimos. Realizar las pruebas de los bucles simples para el bucle ms ina terior manteniendo los contadores de los bucles exteriores en sus valores m nimos. Aadir otras pruebas para valores fuera de rann go. Progresar hacia fuera llevando a cabo pruebas para el siguiente bucle (en orden de anidamiento) pero manteniendo todos los bucles externos en sus valores m nimos y los dems bucles anidados a en sus valores t picos. Continuar hasta que se hayan probado todos los bucles.
</i12YeMoM>

3.

4.

6. LAS PRUEBAS SOFTWARE

Pgina 63 a

Bucles concatenados: Si los bucles son independientes conviene usar el procedimiento para bucles simples, si no se recomienda usar el de los bucles anidados. Bucles no estructurados: Deben redisearse siempre que sean posible a las construcciones de n programacin estructurada. o

6.3.2.

LA PRUEBA FUNCIONAL (CAJA NEGRA)

Se centra en el estudio de la especicacin del software, anlisis de las o a funciones que debe realizar, de las entradas y salidas. Como ocurre con la prueba estructural, una prueba exhaustiva de la caja negra es impracticable por lo que es necesario elegir una serie de criterios para realizar una serie de pruebas que aporten un nivel lo ms alto de abilidad posible. a Myers aporta dos deniciones que ayudan en esta eleccin: o El que reduce el nmero de otros casos necesarios para que u la prueba sea razonable. Esto implica que el caso ejecute el mximo nmero de posibilidades de entrada diferentes para a u as reducir el total de casos. El que cubre un conjunto extenso de otros posibles casos, es decir, nos indica algo acerca de la ausencia o la presencia de defectos en el conjunto espec co de entradas que prueba, as como de otros conjuntos similares. Este tipo de pruebas se centra en descubrir errores como: Funciones incorrectas o ausentes. Errores de la interfaz. Errores en estructuras de datos o acceso a bases de datos externas. Errores de rendimiento. Errores de inicializacin y terminacin. o o Se puede considerar por tanto un mtodo complementario a las pruebas e estructurales. PARTICION O CLASES DE EQUIVALENCIA Cada caso debe cubrir el mximo nmero de entradas. a u El dominio de valores de entrada debe estar dividido en un nmero u nito de clases de equivalencia que cumplan:
</i12YeMoM>

6. LAS PRUEBAS SOFTWARE

Pgina 64 a

La prueba de un valor representativo de una clase permite suponer razonablemente que el resultado obtenido ser el a mismo que el obtenido probando cualquier otro valor de la clase. Para identicar las clases de equivalencia se puede seguir los siguientes pasos: 1. 2. Identicacin de las condiciones de las entradas del programa. o Identicacin de las clases de equivalencia para datos vlidos y no o a vlidos usando el principio de equivalencia enunciado a continuacin: a o Todos los valores de la clase deben ser tratados de igual forma por el programa. Existen algunas reglas que ayudan a identicar las clases de equivalencia: Regla 1: Para un rango de valores [a, b]. Se crean dos clases no vlidas (valor < a a) y (valor > b), y una vlida (a valor b). a Regla 2: Para un nmero de valores: de a a b. Se crean dos clases no vlidas u a (valor < a), (valor > b), y una vlida (a valor b). a Regla 3: Para situaciones del tipo debe ser o booleana, se crean dos clases, una vlida y otra no vlida. a a Regla 4: Para un conjunto de valores admitido tantas clases vlidas como valoa res admitidos y una clase no vlida. a Regla 5: Si se sospecha que en una clase hay elementos que se tratan de forma distinta que al resto de la clase debe dividirse la clase. Estas reglas nos permiten desarrollar casos de prueba para cada elemento del dominio de entrada. El proceso de identicacin de estos casos de prueba o consiste en: 1. 2. 3. Asignacin de un nmero unico a cada clase de equivalencia. o u Escribir por cada clase de equivalencia vlida un caso de prueba. a Escribir por cada clase de equivalencia no vlida un caso de prueba. a

Separamos clases vlidas y no vlidas para que se detecten todos los a a defectos a la hora de evaluar un dato.
</i12YeMoM>

6. LAS PRUEBAS SOFTWARE

Pgina 65 a

ANALISIS DE VALORES L IMITE (AVL) La experiencia ha dejado en constancia que los casos de prueba que exploran las condiciones l mite de un programa producen un mejor resultado para la deteccin de defectos. o Esta tcnica complementa a la tcnica de clases de equivalencia y se e e caracteriza por: Requiere la seleccin de no slo uno, sino de al menos un elemento o o para que los mrgenes se sometan a prueba. a Se centran no slo en el dominio de entrada sino tambin en el de o e salida. El proceso de seleccin es heur o stico, pero podr ajustarse a las siguiena tes reglas: Regla 1 (entrada): Para un rango [a, b], se crearn dos casos con los l a mites, (a) y (b) y otros dos con valores fuera del rango. Regla 2 (entrada): Para un nmero de valores comprendido entre a y b, se crearn cuatro u a casos: (a 1, a, b, b + 1). Regla 3 (salida): Para salidas que deben estar dentro de un rango. Usar la regla 1 para intentar obtener una serie de valores de salida dentro de este rango l mite y fuera de estos l mites. Regla 4 (salida): Para salidas que deben tener un valor comprendido entre dos valores. Usar la regla 2 para intentar obtener una serie de valores de salida dentro l mite de valores admitidos y fuera de este l mite (en una unidad). En las reglas 3 y 4 hay que considerar que no siempre se va a poder obtener valores fuera de los l mites y que los valores de entrada l mite no generan valores de salida l mite. CONJETURA DE ERRORES Tcnica que consiste en intentar detectar errores haciendo uso de la e experiencia y viendo las situaciones propensas a error que suelen provocar fallos para as realizar una extrapolacin al programa analizado e intentar o descubrirle errores. Por ello a esta tcnica se le suele denominar generacin e o de casos (o valores) especiales.
</i12YeMoM>

6. LAS PRUEBAS SOFTWARE

Pgina 66 a

Algunos ejemplos ser considerar el cero es un valor propenso a error, an o, para el tratamiento de listas, tener en cuenta que los casos en los que no hay valores o hay un solo valor suelen ser conictivos. . .

6.3.3.

PRUEBAS ALEATORIAS

Consiste en la prueba de programas haciendo uso de entradas creadas de forma aleatoria por un generador de pruebas alimentado con una descripcin o de entradas y las secuencias de entrada posibles y su probabilidad de ocurrir en la prctica. a Si el proceso de generacin ha sido correcto se crearn eventualmente o a todas las entradas posibles del programa o incluso si se hace uso de una distribucin de estad o stica que indique la frecuencia en que se producen las entradas se podr realizar pruebas que se ajustan ms a la realidad. an a Esta tcnica es usada sobre todo en compiladores. En el diseo de softe n ware se usa sobre todo las tcnicas de la caja blanca y la caja negra. e

6.4.
6.4.1.

EJECUCION DE LAS PRUEBAS


EL PROCESO DE EJECUCION

Atendiendo al estndar IEEE 1008 la ejecucin de las pruebas abarca a o las siguientes fases: 1. 2. 3. Ejecutar las pruebas. Ver si ha concluido el proceso de prueba. Si han concluido, evaluar resultados. Si no hay que generar casos adicionales que satisfagan los criterios de complecin de pruebas. o El proceso de ejecucin consta de: o 1. 2. 3. Se ejecutan las pruebas. Se comprueba si ha habido algn fallo de ejecucin. u o Si se ha producido un fallo puede ser debido o a un defecto software o a un error en el diseo de pruebas. Se deber corregir el error y volver n a al paso 1. El proceso de comprobacin de terminacin de las pruebas consta de: o o 1. 2. Se comprueba si se cumplen los criterios de complecin de las pruebas. o Si las pruebas han concluido se evalan los productos en base a los u resultados obtenidos (terminacin normal). o
</i12YeMoM>

6. LAS PRUEBAS SOFTWARE

Pgina 67 a

3. 4.

Si no han acabado se debe comprobar que no hay condiciones anormales en la prueba. Si hay condiciones anormales se pasa a la evaluacin (terminacin o o anormal), si no las hay se deber generar y ejecutar pruebas adicionaa les.

6.5.

LA DEPURACION

La depuracin se dene como: o El proceso de localizar, analizar y corregir los defectos que se sospecha que contiene el software. Tiene dos etapas: 1. 2. Localizacin de defecto. o Correccin del defecto, efectuando las modicaciones necesarias en el o software.

A partir de los s ntomas de defectos de error resultado del proceso de prueba, se pasa a un proceso de deteccin y correccin del error en el proceso o o de depuracin. Si no se detecta dicho error se pasar a la generacin de ms o a o a pruebas que ayuden a detectarlo. Una vez corregido el error se efectuarn a nuevas pruebas que comprueben si se ha eliminado el problema.

6.6.

ESTRATEGIA DE APLICACION DE LAS PRUEBAS

Tcnica que pretende dividir la aplicacin y planicacin de las pruebas e o o haciendo uso de niveles de prueba. Cada nivel se va a centrar en probar el software en referencia al trabajo realizado en una etapa de desarrollo diferente, haciendo distinguir cinco niveles: 1. 2. 3. 4. 5. Prueba mdulo. o Prueba de integracin. o Prueba de validacin. o Prueba del sistema. Prueba de aceptacin. o

</i12YeMoM>

6. LAS PRUEBAS SOFTWARE

Pgina 68 a

6.6.1.

PRUEBA UNIDAD

Centra sus actividades en ejercitar la lgica de mdulo (caja blanca) y o o los distintos aspectos de la especicacin de las funciones (caja negra). o Esta prueba abarca desde un mdulo, hasta un grupo de mdulos o o o incluso un programa entero y suele ser llevada a cabo por el personal de desarrollo.

6.6.2.

LA PRUEBA DE INTEGRACION

Est totalmente ligada a la forma en que los distintos componentes softa ware estn integrados. Comprende por tanto una serie de pruebas realizadas a de forma progresiva desde mdulos hasta el sistema completo. Su objetivo o es comprobar los ujos de datos entre los distintos componentes del sistema. Existen dos tipos fundamentales de integracin: o Integracin incremental: o Un mdulo se prueba con el resto de mdulos ya probados. Si funciona o o pasa al conjunto de los probados. En funcin del orden elegido esta o integracin puede ser ascendente o descendente, que, a su vez, puede o ser en anchura o en profundidad. Integracin no incremental (Big-Bang): o Se prueba cada mdulo de forma independiente y despus se integran o e todos para probar el programa completo. INTEGRACION INCREMENTAL ASCENDENTE 1. 2. 3. 4. Se combinan mdulos de bajo nivel en grupos que realizan alguna o subfuncin espec o ca. Se escribe para cada mdulo cul es su impulsor o conductor que va a o a permitir simular la llamada a los mdulos del grupo. o Se prueba cada grupo empleando su impulsor. Se eliminan los mdulos impulsores de cada grupo y se sustituyen por o los mdulos de nivel superior. Se vuelven a construir impulsores para o stos y se vuelven a probar, as hasta llegar a la ra de la jerarqu e z a.

INTEGRACION INCREMENTAL DESCENDENTE Comienza por el mdulo ra de la jerarqu de mdulos y va incorpoo z a o rando nuevos mdulos de forma progresiva. En este caso no va a haber un o procedimiento que indique qu modulo es mejor incorporar antes. e Es similar a la anterior slo que en vez de usar mdulos impulsores usan o o mdulos stubs que primero se supondr que funcionan correctamente para o a
</i12YeMoM>

6. LAS PRUEBAS SOFTWARE

Pgina 69 a

probar el mdulo de nivel superior y luego se sustituirn por los originales o a y se descender en la jerarqu a a. La construccin de mdulos stubs es ms compleja. Se distinguen cuatro o o a grados distintos de complejidad: Tipo 1: Muestra un mensaje de traza. Tipo 2: Muestra un mensaje que va a depender de los parmetros que a se le pase. Tipo 3: Devuelve un valor que no depende de los parmetros que a recibe. Tipo 4: Devuelve un valor que depende, en mayor o menor grado, de los parmetros que recibe. a INTEGRACION NO INCREMENTAL En esta integracin cada mdulo requiere: o o 1. 2. Un mdulo impulsor. o Uno o ms mdulos cticios. a o

Cada mdulo es probado de forma independiente para luego realizar una o prueba del sistema a nivel global.

6.6.3.

LA PRUEBA DE VALIDACION

Debe comprobar si existen desajustes entre el software y los requisitos jados para su funcionamiento en la especicacin de los mismos. o

6.6.4.

LA PRUEBA DEL SISTEMA

El objetivo de esta prueba es ver si se cumplen todos los requisitos especicados (funcionales, de rendimiento, en documentacin correcta y ejecucin o o y buen rendimiento en condiciones l mite) Los casos de prueba se disean generalmente teniendo en cuenta tres n fuentes: 1. Tcnicas de caja negra. e

2. Stress testing, pruebas de rendimiento del sistema y su capacidad funcional. 3. Tcnicas de la caja blanca. e

</i12YeMoM>

6. LAS PRUEBAS SOFTWARE

Pgina 70 a

6.6.5.

LA PRUEBA DE ACEPTACION

Prueba cuyo objetivo es comprobar que el producto est listo para ser a implantado dando fe al usuario del que el producto es able, robusto, fcil a de usar y, sobre todo, que cumple los requisitos marcados.

</i12YeMoM>

BIBLIOGRAF IA
1. 2. Gmez-Nieto, M.A., Luque Ruiz, I., Ingenier del Software, Servicio o a de publicaciones Universidad de Crdoba, Ao o n Yepes Moyano, M., Apuntes tomados en clase en el curso 2003-2004.

71