Fases genricas del proceso de desarrollo de software

Fase Definicin Pasos Anlisis del Sistema Planificacin del Proyecto Anlisis de Requerimientos Desarrollo Diseo preliminar Diseo detallado Codificacin Cartas de Estructura PDL Documento del cdigo con comentarios externos e internos Manual del usuario* Documento de las corridas de prueba Documentos Documento de Especificacin del Sistema Documento de Plan de Proyecto Documento de Especificacin de Requerimientos (DFDs)

Pruebas Mantenimiento * Se va desarrollando en todos los pasos anteriores e incluso puede sufrir modificaciones durante el mantenimiento.

Anlisis del Sistema

1. 2. 3. 4. 5. identificar las necesidades estudiar la viabilidad anlisis econmico anlisis tcnico identificar restricciones de costo y tiempo

Resultado: Definicin del sistema

Formato demostrativo del Documento de Especificacin del Sistema

1. Definicin del problema 2. Justificacin del sistema 3. Restricciones del sistema y del proyecto* 4. Funciones que se proporcionarn (hardware/software/personal) 5. Caractersticas del usuario* 6. Ambientes de desarrollo/operacin/mantenimiento 7. Estrategias de solucin* 8. Prioridades para las caractersticas del sistema 9. Criterios de aceptacin del sistema* 10. Fuentes de informacin* 11. Glosario* * Pueden no ser necesarios para sistemas medianos o pequeos.

Planificacin del Proyecto

1. 2. 3. 4. 5. 6. Alcance estimaciones de recursos humanos, software y hardware estimaciones de costos planificacin temporal (PERT-Gantt) planificacin organizativa seguimiento y control

Resultado: Eleccin del paradigma (Prototipos, Fases, 4GL)

Formato demostrativo del Documento de Plan del proyecto

1. Modelo del ciclo de vida. Terminologa, Logros, Productos finales. 2. Estructura organizacional. Estructura de administracin, de equipos, de distribucin de trabajo, definicin de puestos. 3. Requisitos preliminares de personal y recursos. Programacin de personal y recursos.* 4. Programacin preliminar del proyecto (PERT-Gantt) 5. Estimacin preliminar de costos. 6. Mecanismos de supervisin y control del proyecto.* 7. Herramientas y tcnicas que se emplearn. 8. Lenguajes de programacin. 9. Requisitos de pruebas. 10. Documentos de apoyo necesarios.* 11. Formas de demostracin y entrega. 12. Programacin de entrenamiento y materiales.* 13. Plan de instalacin.* 14. Consideraciones de mantenimiento. 15. Mtodo y tiempo de la entrega final. 16. Mtodo y tiempo del pago. 17. Fuentes de informacin * Pueden no ser necesarios para sistemas medianos o pequeos.

Anlisis de Requerimientos
1. 2. 3. 4. descripcin de la informacin representacin del contenido (Diccionario de Datos) descripcin funcional informal o formal descripcin del comportamiento (diagramas de transicin de estados)

Resultado: Modelo funcional realizado con alguna metodologa (orientada al flujo de datos, orientada a las estructuras de datos, orientada a objetos)

Diseo preliminar
1. Arquitectnico (Cartas de estructura) 2. De datos 3. De la interface refinamiento modularidad ocultamiento de la informacin abstraccin de datos independencia funcional: cohesin y acoplamiento

Diseo detallado
Procedimental: notaciones tabulares (Tablas de decisin), textuales (PDL) o grficas (NS, DF) Algoritmos

Codificacin
lenguaje estilo

Pruebas
De Unidad: de caja blanca, de caja negra De Integracin: ascendente, descendente, mixta

Mantenimiento
Correctivo Adaptativo Perfectivo

El Modelo Esencial
Es un modelo de lo que el sistema debe hacer para satisfacer los requerimientos del usuario, diciendo lo mnimo posible acerca de cmo se implementar. Esto supone tecnologa perfecta y que se puede obtener fcilmente y sin costo. Esto significa evitar describir implementaciones especficas de procesos en el sistema. Lo mismo se da para los flujos y almacenes de datos. El modelo debe describir el contenido sin describir el medio u organizacin fsica de los datos.

El modelo esencial consiste de dos componentes principales: 1. Modelo ambiental.

Define la frontera entre el sistema y el resto del mundo. Consiste en el diagrama de contexto, una lista de acontecimientos y una descripcin breve del propsito del sistema.

2. Modelo de comportamiento.
Describe el comportamiento que se requiere del sistema para que interacte de forma exitosa con el ambiente. Consiste de los diagramas de flujo de datos, de entidad relacin, de transicin de estados y diccionarios y especificaciones de proceso.

El Modelo Ambiental.
Adems de determinar qu est en el interior del sistema y qu en el exterior, tambin define las interfaces entre el sistema y el ambiente. Se necesita saber qu informacin entra al sistema desde el ambiente exterior y qu informacin produce al ambiente externo. Como las entradas y las salidas no se producen al azar, otro aspecto crtico del modelo ambiental consiste en identificar los acontecimientos que ocurren en el ambiente al cual debe responder el sistema. Slo aquellos que (1) ocurren en el ambiente exterior y (2) requieren una respuesta del sistema.

La Declaracin de Propsitos Es una declaracin textual breve y concisa del propsito del sistema, dirigida al nivel administrativo superior, la administracin de los usuarios, y otros que no estn directamente involucrados con el desarrollo del sistema. La intencin no es dar una descripcin completa y detallada del sistema.

El Diagrama de Contexto Es un caso especial de DFD donde una burbuja representa todo el sistema. Enfatiza varias caractersticas importantes del sistema: Las personas, organizaciones y sistemas con los que se comunica el sistema (terminadores). Los datos que el sistema recibe del mundo exterior y que deben procesarse de alguna forma. Los datos que el sistema produce y se envan al mundo exterior. Los almacenes de datos que el sistema comparte con otros sistemas. La frontera entre el sistema y el resto del mundo. La Lista de Acontecimientos Es una lista narrativa de los estmulos que ocurren en el mundo exterior a los cuales el sistema debe responder. Cada acontecimiento puede ser de flujo, temporal o de control. El acontecimiento orientado a flujo es el que se asocia a un flujo de datos, el sistema se da cuenta de que ha ocurrido el acontecimiento cuando llega algn dato o posiblemente varios. Esto se corresponde con un flujo de datos del diagrama de contexto. Los acontecimientos temporales arrancan con la llegada de un momento dado en el tiempo. No se inician con flujos de datos de entrada, pero podran requerir que el sistema solicite entradas.

El Diccionario de Datos Inicial Define todos los flujos y almacenes externos. El Modelo de Entidad - Relacin de los almacenes externos

Construccin del Modelo Ambiental.

4

Construccin del Diagrama de Contexto La parte ms fcil del diagrama de contexto es el proceso. Los terminadores se comunican directamente con el sistema a travs de flujos de datos o a travs de almacenes externos. Los terminadores no se comunican entre s. Algunos terminadores tienen un buen nmero de entradas y salidas. Cuando el terminador es una persona individual, es preferible poner el rol que desempea ms que su identidad. Es importante distinguir entre fuentes y manejadores.

Los flujos que aparecen en el diagrama de contexto modelan datos que entran y salen del sistema. Se incluyen en el diagrama de contexto si se ocupan para detectar un acontecimiento en el ambiente al que deba responder el sistema, o si se ocupan (como datos) para producir una respuesta. Tambin se muestran cuando el sistema produce datos para responder a un acontecimiento. El diagrama de contexto no muestra los mensajes y medios especficos de coordinacin que el sistema y los terminadores pasan entre s para indicar que estn listos para las entradas o salidas. En lugar de eso, debe suponerse que las entradas son causadas e iniciadas por los terminadores y que las salidas son causadas e iniciadas por el sistema. Construccin de la Lista de Acontecimientos No confundir un acontecimiento y un flujo relacionado con un acontecimiento. Describir los acontecimientos desde el punto de vista del sistema. La manera de identificar los acontecimientos relevantes para un sistema es examinar cada terminador y preguntar qu efecto pueden tener sus acciones sobre el sistema.

1.2.3 Qu se hace primero, el diagrama de contexto o la lista de acontecimientos? En realidad no importa mientras finalmente se produzcan ambos y se revisen para asegurar que sean consistentes. 1.2.4 Cuando se terminen ambas componentes del modelo ambiental ser posible confirmar lo siguiente: El sistema necesita cada flujo de entrada del diagrama de contexto para reconocer que ha ocurrido un acontecimiento, lo necesita para producir una respuesta a un acontecimiento, o ambas cosas. Cada flujo de salida debe ser respuesta a un acontecimiento. Cada acontecimiento no temporal debe tener entradas a partir de las cuales el sistema pueda detectarlo. Cada acontecimiento debe producir salidas inmediatas como respuesta o bien almacenar los datos que luego sern salidas (como respuesta o parte de una respuesta a algn otro acontecimiento).

UNIDAD N 1: "Concepto de Software e Ingeniera de Software".

La importancia del software.
Durante las tres primeras dcadas de la informtica, el principal desafo era el desarrollo del hardware, de forma que se reduzca el costo de procesamiento y almacenamiento. Hoy el problema es diferente, es mejorar la calidad y reducir el costo de las soluciones basadas en computadoras, soluciones que se implementan con el software. La importancia de las grandes computadoras en la dcada de los 80 est hoy en una computadora personal. Las capacidades del procesamiento y almacenamiento del hardware moderno presentan una gran potencia de clculo. El software es el mecanismo que nos facilita aprovechar, utilizar y explorar este material. La evolucin del software. Un rendimiento en el hardware, una reduccin de costos y tamao han dado lugar a sistemas informticos ms sofisticados. A continuacin se muestra la evolucin dentro del contexto de las reas de aplicaciones: 1950 a 1965: * Sistemas Batch: ejecucin de un solo programa, dedicado a una aplicacin especfica; orient. x lotes. * Diseo a medida: la misma persona que lo escriba lo ejecutaba y si fallaba lo reparaba. * Sin documentacin: el proceso era un proceso implcito realizado en la mente de una persona. Primera etapa: Durante los primeros aos de desarrollo de las computadoras, el hardware sufri continuos cambios, mientras que el software se contemplaba simplemente como un aadido. Se aprendi mucho sobre la implementacin pero relativamente poco sobre la ingeniera de las computadoras. 1960 a 1975: * Multiprogramacin, Multiusuario: introdujeron nuevos conceptos de interaccin hombre mquina. * Tcnicas interactivas: abrieron un nuevo mundo a aplicaciones. * Tiempo Real: poda recoger, analizar y transformar datos de mltiples fuentes, controlando as los procesos y produciendo salidas en milisegundos. * Bases de Datos. * Paquetes de Software. Segunda etapa: el software comienza a distribuirse como un producto, se crean las bibliotecas de software. Estos programas tenan que ser corregidos cuando se producan fallos, modificados si cambiaban los requisitos de los usuarios o adaptados a nuevos dispositivos. Esta actividad se llama mantenimiento del software. Este mantenimiento comenz a absorber recursos en una medida alarmante. An peor, la naturaleza personalizada de muchos programas lo hacan imposible de mantener y as comienza la crisis del software. 1970 a la fecha: * Sistemas Distribuidos: mltiples computadoras, cada una ejecutando funciones concurrentes y comunicndose con alguna otra (aumenta la complejidad del software). * Redes: rea local y global. * Microprocesadores: productos inteligentes. * PC: computadoras personales. * Sistemas expertos. * Inteligencia Artificial. Tercera etapa: Aparece una gran demanda del software. Cuarta etapa: Est empezando ahora, la tecnologa orientada a objetos est desplazando a las convencionales. Las tcnicas de cuarta generacin para el desarrollo de software estn cambiando la forma de construccin de programas. Los sistemas expertos y el software de inteligencia artificial se estn trasladando de los laboratorios a las aplicaciones prcticas. El software de redes neuronales artificiales ha abierto excitantes posibilidades para el reconocimiento de formas y habilidades de procesamiento de informacin al estilo humano. Problemas que se intensifican con el paso de era: 1) La sofisticacin del hardware ha dejado desfasada nuestra capacidad de construir software que pueda explotar el potencial del hardware. 2) La demanda supera la construccin de nuevos programas. 3) Nuestra capacidad de mantener los programas existentes est amenazada por el mal diseo y uso de recursos inadecuado. Como respuesta a esta crisis se ha adoptado la Ingeniera de Software.

Caractersticas del software.

Para poder entender el software analizaremos sus caractersticas: Es un elemento lgico: 1. Se desarrolla, no se fabrica en un sentido clsico. 2. No se estropea. 3. La mayora se construye a medida en vez de ensamblar componentes existentes. Comparacin entre el software y el hardware: SOFTWARE: Elemento Lgico HARDWARE: Elemento Fsico Existen similitudes en su desarrollo pero son fundamentalmente diferentes. En ambos la buena calidad se adquiere mediante un buen desarrollo. Ambos requieren la creacin de un producto pero los mtodos son diferentes. CURVA DE FALLOS: Fallos por defectos no detectados Muchos fallos al principio de su vida, luego No es susceptible a los cambios se estabiliza, se estropea con el paso del del entorno (no se estropea se deteriora) tiempo. Para entender mejor porque se deteriora: Durante su vida, el software sufre cambios (mantenimiento conforme se hacen los cambios) se introducen nuevos defectos haciendo que la curva tenga picos, antes de que vuelva a su estado original, se solicitan otros cambios, haciendo que se cree otro pico. Lentamente el nivel mnimo de fallos comienza a crecer y se deteriora debido a los cambios.

Componentes del software.

El software de computadoras es informacin que existe en dos formas bsicas: 1. Componentes no ejecutables. 2. Componentes ejecutables (se traducen los requisitos del cliente a un cdigo ejecutable). Modelo (prototipo) de requisitos diseo a un lenguaje traductor cdigo La reusabilidad es una caracterstica importante de los componentes de software de alta calidad.

Aplicaciones del software.

El software puede aplicarse en cualquier situacin en la que se haya definido previamente un conjunto especfico de pasos procedimentales (es decir un algoritmo). Existen excepciones como sistemas expertos y redes neuronales. Para determinar la naturaleza de una aplicacin se debe considerar el contenido y el determinismo de la informacin. CONTENIDO: se refiere al significado y a la forma de su informacin de entrada y salida. DETERMINISMO: se refiere a la predecibilidad del orden y del tiempo de llegada de los datos. Posibilidad de aplicacin: Software de Sistemas: Sirve a otros programas. Ej. : compilador. Fuerte interaccin con el hardware. Mltiples usuarios. Estructuras de datos complejas y mltiples interfaces. Software de Tiempo Real: Mide, analiza y controla sucesos del mundo real. Este debe responder dentro de restricciones estrictas de tiempo. Software de Gestin: las aplicaciones de esta rea reestructuran los datos existentes en orden para facilitar las operaciones comerciales o gestiones de toma de decisiones. Software de Ingeniera y Cientfico: caracterizado por los algoritmos de manejo de nmeros. Software empotrado: reside en memoria de solo lectura y se utiliza para control de productos y sistemas de los marcados industriales y de consumo. Pueden ejecutar funciones muy limitadas y curiosas o suministrar una funcin significativa y con capacidad de control. Software de PC: procesamiento de texto, hojas de clculo, grficos por computadoras, juegos, gestin de BD, etc. Software de Inteligencia Artificial: hace uso de algoritmos no numricos para resolver problemas complejos para los que no son adecuados el clculo o el anlisis. El rea ms atractiva es la de los sistemas expertos tambin llamados sistemas basados en conocimiento. Otra rea es el reconocimiento de patrones (imagen, voz) o redes neuronales que simulan la estructura de proceso del cerebro.

Crisis del software.

Se refiere a un conjunto de problemas que aparecen en el desarrollo del software para computadoras. Los problemas no estn limitados al software que no funciona correctamente, es ms, el mal barca los problemas asociados a como desarrollarlo, como mantenerlo y como satisfacer las demandas. Problemas: 1. Planificacin y estimacin de costos son frecuentemente muy imprecisas. 2. La productividad no se corresponde con la demanda. 3. La calidad, a veces, no llega a ser ni aceptable. Tales problemas son solo las manifestaciones visibles de otros: No hay tiempo de recoger datos sobre el proceso de desarrollo sin datos histricos, las estimaciones no han sido buenas. Es frecuente la insatisfaccin del cliente, no hay suficiente indagacin sobre los requisitos. Poca comunicacin con el cliente. La calidad es cuestionable. Recin se empieza a comprender la importancia de las pruebas. El software existente es muy difcil de mantener. Todos los problemas descriptos pueden corregirse. La clave est en dar un enfoque de ingeniera al desarrollo del software.

Ingeniera del software. Una definicin.

El establecimiento y uso de principios de ingeniera robustos para obtener econmicamente software fiable y eficiente. Disciplina tecnolgica para producir y mantener software en tiempo y presupuesto. Abarca un conjunto de tres elementos claves: mtodos, herramientas y procedimientos, que facilitan el control del proceso de desarrollo y suministran las bases para construir software de alta calidad. MTODOS: indican como construir tcnicamente el software, esto abarca un amplio espectro de tareas que incluyen: planificacin y estimacin del proyecto, anlisis de requisitos del sistema y del software, diseo de estructura de datos, arquitectura de programas y procedimientos, algoritmos, codificacin, prueba y mantenimiento. HERRAMIENTAS: suministran un soporte automtico o semiautomtico para los mtodos. Cuando se integran las herramientas de forma que la informacin creada por una, pueda ser usada por otra se establece un sistema para el soporte del desarrollo del software, llamado ingeniera del software asistida por computadora (CASE). PROCEDIMIENTOS: son el pegamento que une a los mtodos y herramientas y facilita un desarrollo racional y oportuno del software de computadoras. Definen la secuencia en que se van a aplicar los mtodos, las entregas (documentos, informes, etc.) que se requieren, los controles que ayudan a asegurar la calidad y coordinar los cambios que ayudan a los gestores a evaluar el progreso.

Paradigmas.
La ingeniera de software est compuesta por una serie de pasos que abarcan los mtodos, las herramientas y los procedimientos. Estos pasos se denominan frecuentemente paradigmas de la ingeniera de software. La eleccin de un paradigma se lleva a cabo de acuerdo con la naturaleza del proyecto y de la aplicacin, los mtodos y herramientas a usar y los controles y entregas requeridas. Los paradigmas son tres: ciclo de vida en fases, construccin de un prototipo y tcnicas de cuarta generacin.

Ciclo de vida en fases.

A veces llamado modelo en cascada, exige un enfoque sistemtico y secuencial del desarrollo del software.
Anlisis de requisitos

Diseo

Codificacin

Prueba

Mantenimiento

a) Ingeniera del sistema: (Planeamiento). Debido a que el software es siempre parte de un sistema mayor, primero debemos analizar con que elementos debe interrelacionarse (hardware, personas, bases de datos). b) Anlisis de requisitos: El proceso de recopilacin de requisitos se centraliza e intensifica especialmente para el software. Para comprender la naturaleza de los programas a construir debemos comprender el mbito de la informacin, as como la funcin, el rendimiento y las interfaces requeridas. Los requisitos tanto del sistema como del software se documentan y revisan con el cliente. c) Diseo: se enfoca sobre cuatro atributos distintos del sistema: la estructura de datos, la arquitectura del software, el detalle procedimental y la caracterizacin de la interfaz. El diseo traduce los requisitos en una representacin del software que pueda ser establecida de forma que obtenga la calidad requerida ates de comenzar la codificacin. Se documenta y forma parte de la configuracin del software. d) Implementacin: el diseo debe traducirse en una forma legible en la mquina: codificacin y depuracin (verificacin de errores). e) Verificacin: Prueba de integracin: se utiliza para probar todas las unidades del sistema en una unidad funcional. Prueba de aceptacin: para demostrar que el sistema implementado responde a las expectativas del usuario. f) Mantenimiento: el software sufrir cambios despus de entregado al cliente. Los cambios se debern a correccin, adaptacin, aumentacin. Desventajas: 1) Los proyectos reales raramente siguen el flujo secuencial, siempre hay interacciones y se crean problemas en la aplicacin del paradigma. 2) Es difcil para el usuario definir todos los requisitos al principio. 3) El cliente debe tener paciencia, hasta la etapa final no ve el sistema. Un error importante no detectado hasta que el programa este funcionando puede ser desastroso.

10

Construccin de Prototipos.
La construccin de prototipos es un proceso que facilita al programador la creacin de un modelo del software a construir. El modelo puede ser: Un modelo en papel: que describa la interaccin hombre mquina. Un prototipo que funcione: que implemente algn subconjunto de funciones del software deseado. Un programa existente: que ejecute parte o toda la funcin deseada, pero que tenga otras caractersticas a ser mejoradas en el nuevo trabajo de desarrollo.
Comienzo Parada Recoleccin y Refinamiento de requisitos Producto de ingeniera Refinamiento del prototipo Diseo rpido Construccin de prototipos Evaluacin del prototipo por el cliente

Pasos: 1) Recoleccin de requisitos: el tcnico y el cliente se renen y definen los objetivos globales para el software, identifican todos los requisitos conocidos y perfilan las reas en donde ser necesario una mayor definicin. No tiene que ser completo como en el ciclo de vida en fases. 2) Diseo rpido: se enfoca sobre la representacin de los aspectos del software visibles al usuario (ej.: mtodos de entrada y formato de salida). 3) Construccin del prototipo. 4) Evaluar y refinar los requerimientos: el prototipo construido es evaluado por el cliente / usuario y se utiliza para refinar los requerimientos del software a desarrollar. Se produce un proceso interactivo en el que el prototipo es afinado para que satisfaga las necesidades del cliente, al mismo tiempo que facilita al que lo desarrolla una mejor comprensin de lo que hay que hacer. 5) Producto construido. Podramos hacer un modelo de prototipo para el punto de definicin de requerimientos del ciclo de vida en fases, para intentar mejorar la comunicacin con el cliente. El prototipo sirve para los requerimientos y luego se desecha. La utilizacin de este paradigma puede ser problemtica por las siguientes razones: a) El cliente ve funcionando lo que parece una versin del software, ignorando que por el apuro en hacer que funcione no se han considerado los aspectos de calidad y mantenimiento a largo plazo. b) El tcnico de desarrollo realiza frecuentemente ciertos compromisos de implementacin para obtener un prototipo que funcione rpido (ej.: un determinado lenguaje) quizs inapropiado para el sistema, luego olvida cuales eran las razones por las cuales era inapropiado y termina utilizndolo. Ventajas: Aunque se presenten problemas, el prototipo es un paradigma efectivo para la ingeniera de software. Al comienzo el tcnico y el cliente debern estar de acuerdo en que se construya para servir solo como un mecanismo para la identificacin de requerimientos; luego se descarta y se construye el software real con miras a la calidad y mantenimiento.

11

Modelo en Espiral
El modelo en espiral para la ingeniera de Software ha sido desarrollado para cubrir las mejores caractersticas tanto del ciclo de vida clsico como de la creacin de prototipos, aadiendo al mismo tiempo un nuevo elemento: el anlisis de riesgo, que falta en esos paradigmas. El modelo define cuatro actividades principales: 1. Planificacin: Determinacin de objetivos, alternativas y restricciones. 2. Anlisis de riesgo: Anlisis de alternativas e identificacin/resolucin de riesgos. 3. Ingeniera: Desarrollo del producto de siguiente nivel. 4. Evaluacin del Cliente: Valoracin de los resultados de la ingeniera. Con cada iteracin alrededor del espiral, comenzando en el centro y siguiendo hacia el exterior, se construyen sucesivas versiones del software, cada vez ms completas. Durante la primera vuelta alrededor de la espiral se definen los objetivos, las alternativas y las restricciones, y se analizan e identifican los riesgos. Si el anlisis de riesgo indica que hay incertidumbre en los requisitos, se puede usar la creacin de prototipos en el cuadrante de ingeniera, para dar asistencia tanto al encargado del desarrollo, como al cliente. Se pueden usar simulaciones y otros modelos para definir ms el problema y refinar los requisitos. El cliente evala el trabajo de ingeniera y sugiere modificaciones. En base a los comentarios del cliente se produce la siguiente fase de planificacin y de anlisis de riesgo. En cada bucle alrededor de la espiral, la culminacin del anlisis de riesgo resulta en una decisin de seguir o no seguir. Si los riesgos son demasiado grandes, se puede dar por terminado el proyecto. Sin embargo, en la mayora de los casos se sigue avanzando alrededor del camino de la espiral, y ese camino lleva a los desarrolladores hacia fuera, haciendo un modelo mas completo del sistema y, al final, al propio sistema operacional. Cada vuelta alrededor de la espiral requiere ingeniera que se puede llevar a cabo mediante el enfoque de vida clsico o de la creacin de prototipos. El paradigma del modelo en espiral utiliza un enfoque evolutivo para la ingeniera de software, permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel evolutivo. Utiliza la creacin de prototipos como un mecanismo de reduccin del riesgo, pero, lo que es ms importante, permite al que lo desarrolla aplicar el enfoque de creacin de prototipos en cualquier etapa de la evolucin del producto. Puede ser difcil convencer a grandes clientes de que el enfoque evolutivo es controlable. Requiere una considerable habilidad para la valoracin del riesgo, y cuenta de esta habilidad para el xito. Si no se descubre un riesgo importante, indudablemente surgirn problemas.

12

Tcnicas de cuarta generacin.

Abarcan un conjunto de herramientas (lenguajes no procedimentales para consulta a B.D., generacin de informes, manipulacin de datos, definicin de pantallas, hojas de clculo, etc.), que facilitan especificar algunas caractersticas de alto nivel del sistema y luego la herramienta genera el cdigo automticamente basndose en la especificacin. Pasos:
Recoleccin de requisitos Estrategias de diseo Implementacin con leng. De 4G Producto

Comienza con la recoleccin, el cliente describe los requisitos, que son a continuacin traducidos directamente a un prototipo operativo. Sin embargo en la prctica no se puede hacer eso. El cliente puede no estar seguro de lo que necesita, puede ser incapaz o no desear especificar la informacin en la forma en que una herramienta de cuarta generacin puede aceptarla. Para aplicaciones pequeas se puede ir directamente desde el paso de recoleccin a implementacin en un lenguaje de cuarta generacin. Sin embargo, es necesario mayor esfuerzo para desarrollar una estrategia de diseo para el sistema. El uso de tecnologa de cuarta generacin sin diseo, para grandes proyectos, causar dificultades (poca calidad, mantenimiento pobre, mala aceptacin por el cliente). La implementacin en lenguajes de cuarta generacin permite, al que desarrolla el software, centrarse en la representacin de los resultados deseados, que es lo que se traduce automticamente en un cdigo fuente que produce dichos resultados. Para poder transformar una implementacin con tecnologa de cuarta generacin en un producto, el que lo desarrolla debe dirigir una prueba completa, desarrollar una documentacin con sentido y ejecutar el resto de actividades de transicin que se dan en los otros paradigmas.

Ventajas: Los difusores aducen reducciones dramticas en el tiempo de desarrollo del software Y una mejora en la productividad de la gente que construye software. Desventajas: Los detractores aducen que las herramientas actuales de cuarta generacin no son fciles de usar, que el cdigo fuente es ineficiente y el mantenimiento est abierto a discusin. Ambas posturas tienen su parte de razn. Aunque son difciles los hechos de las suposiciones pues hay pocos estudios controlados. 1. En la actualidad su mbito est limitado a sistemas de informacin de gestin, concretamente al anlisis de informacin y a la obtencin de informes relativos a grandes bases de datos. 2. En aplicaciones pequeas los estudios indican que se reduce el tiempo requerido para producir software. 3. Para grandes trabajos exige el mismo o ms tiempo de anlisis, diseo y prueba.

13

Combinacin de Paradigmas.
En muchos casos los paradigmas pueden y deben considerarse de forma que puedan utilizarse las ventajas de cada uno en un nico proyecto. En todos los casos se comienza con la determinacin de objetos, alternativas y restricciones, pasos que se llaman recoleccin preliminar de requisitos. A partir de ese punto se puede tomar cualquier camino como indica la figura. Por ejemplo, se pueden seguir los pasos del ciclo de vida si se puede especificar completamente el sistema al principio de todo. Si los requisitos son inciertos, se puede usar un prototipo para definir mejor los requerimientos. Usando el prototipo como gua, puede despus seguir los pasos del modelo de ciclo de vida clsico. Alternativamente, el prototipo puede evolucionar hacia el sistema y volver al paradigma del ciclo de vida en el momento de prueba. Usar la tecnologa de cuarta generacin para implementar el prototipo o implementar el sistema en el paso de la codificacin del ciclo de vida. No hay necesidad de ser dogmtico en la eleccin del paradigma, la naturaleza de la aplicacin debe dictar el mtodo a elegir. Mediante la combinacin de paradigmas, el todo puede ser mejor que la suma de las partes.

Recoleccin preliminar de requisitos

Anlisis de requisitos

Prototipado

T4G

Modelo en espiral

Diseo

Prototipado Interaccin n-sima

T4G

Codificacin T4G Prueba

Modelo en espiral n-sima

Sistema en operacin

Mantenimiento

14

UNIDAD N 2: "Ingeniera de Sistemas".

Ingeniera de Hardware y Software.
Un sistema basado en computadoras es un conjunto u ordenacin de elementos organizados para llevar a cabo algn mtodo, procedimiento o control mediante el procesamiento de informacin. Los elementos de un sistema basado en computadoras son: Software: programas, estructuras de datos y la documentacin asociada que sirve para realizar el mtodo lgico, procedimiento o control requerido. Hardware: los dispositivos electrnicos (CPU, memoria) que proporcionan la capacidad de computacin y los dispositivos electrnicos (ej.: censores) que proporcionan las funciones del mundo exterior. Gente: los individuos que son usuarios y operadores del software y hardware. Base de Datos: una coleccin grande y organizada de informacin a la que se accede mediante el software. Documentacin: los manuales, los impresos y otra informacin descriptiva que explica el uso y/o la operacin del sistema. Procedimientos: los pasos que definen el uso especfico de cada elemento del sistema o el contexto procedimental en que reside el sistema.
Procedimientos

Documentos ENTRADA Base de datos Gente SISTEMA

Hardware SALIDA Software

La definicin empieza con la etapa de anlisis del sistema. Durante esta etapa se desarrolla una descripcin bien delimitada del alcance del esfuerzo. Para el software se definen los recursos necesarios y se establecen las restricciones de tiempo y costo. La etapa de planificacin tiene como propsito proveer de una indicacin preliminar de la viabilidad del proyecto en la relacin de costo y tiempo establecido. El siguiente paso es el anlisis y definicin de los requerimientos. En este paso el elemento del sistema asignado al software se define en detalle. Los requerimientos se analizan y se definen de una de las dos siguientes maneras: El anlisis formal del dominio de la informacin puede ser usado para establecer una representacin del flujo de informacin y estructura. Estas representaciones se expanden luego para convertirse en una especificacin del software. Alternativamente se construye un prototipo de software y es evaluado por el cliente en un intento de afianzar los requerimientos.

15

Fases Genricas del software.

El proceso de desarrollo del software contiene tres fases genricas independientes del paradigma elegido. Las tres fases, definicin, desarrollo y mantenimiento, se encuentran en todos los desarrollos del software independientes del rea de aplicacin, tamao del proyecto o complejidad. 1) DEFINICIN: (qu). El que desarrolla el software trata de identificar que informacin ha de ser procesada, que funcin y rendimiento se desea, que interfaces hayan de establecerse, que criterios de validacin se usaran. Se aplicarn estos tres pasos: a) Anlisis del sistema: trata de definir el papel de cada elemento del sistema, asignando el papel que jugar el software. b) Planificacin del proyecto: permite analizar riesgos, asegurar los recursos, atenuar los costos, planificar el trabajo. c) Anlisis de requerimientos: obtener de forma ms detallada el dominio de la informacin y las funciones ms importantes del sistema (eleccin de metodologas). 2) DESARROLLO: (como). El que desarrolla el software intenta descubrir como han de disearse las estructuras de datos y la arquitectura del software, como han de implementarse los detalles procedimentales, como ha de trasladarse el diseo a un lenguaje de programacin y como se realizarn las pruebas. Se aplicarn estos tres pasos: a) Diseo: (arquitectnico, estructural o detallado). Trata de trasladar los requerimientos del software a un conjunto de representaciones grficas, tabulares etc. que permiten describir las estructuras de datos, arquitectura y procedimientos algortmicos. b) Codificacin: traslada la representacin obtenida en el diseo a un lenguaje (puede ser convencional o de cuarta generacin). c) Prueba: descubrir los errores en el sistema ya implementado. 3) MANTENIMIENTO: aplica nuevamente los pasos de las fases de definicin y desarrollo, pero en el contexto del software ya existente. En esta fase se encuentran tres tipos de cambios: a) Correccin: corregir errores de software que descubri el cliente. b) Adaptacin: realizar mdulos para adaptar el sistema a nuevos entornos (por ej.: nueva CPU, nuevo S.O.). c) Ampliacin: aumento del sistema desarrollado en funcin de nuevos requerimientos del usuario / cliente. Estas tres fases se complementan con: Recursiones: se realizan durante cada paso para asegurar que se mantiene la calidad. Documentacin: permite que toda la informacin este disponible para su uso posterior.

16

Estrategias de Solucin
El anlisis de sistemas se centra en todos los elementos del sistema y no solo en el software y se realiza con los siguientes objetivos: 1) Identificacin de las necesidades: El analista se entrevista con el cliente y su representante y los objetivos son: a) Identificar los objetivos del sistema: el analista debe distinguir entre lo que necesita el cliente y lo que desea. b) Identificar funciones importantes. c) Identificar informacin que se necesita, rendimiento requerido, lmites de costo y tiempo. Es decir, identificar necesidades del usuario: objetivos, posibilidad de desarrollo en cuanto a equipamiento, restricciones de costo y tiempo, informacin a producir y el rendimiento requerido. La informacin recogida se especifica en un Documento de conceptos del sistema. 2) Estudio de viabilidad: Se centra en los siguientes puntos bsicos: se realiza cuando hay duda de alguno de ellos, de lo contrario no es necesario. VIABILIDAD ECONMICA: evaluar el costo frente al beneficio final. VIABILIDAD TCNICA: estudio de funcionalidad, rendimiento y restricciones que pueden afectar el desarrollo del sistema. Las consideraciones que se asocian normalmente son: Riesgo de desarrollo: trata de ver si el elemento del sistema se puede realizar de manera que la funcin y rendimiento se puedan alcanzar dentro de las restricciones definidas. Disponibilidad de recursos: si se tienen los recursos necesarios de hardware, software y personal. Tecnologa: si est la tecnologa adecuada. VIABILIDAD LEGAL: analizar si violamos la ley con el sistema. ALTERNATIVAS: una evaluacin de enfoques alternativos para el desarrollo del sistema. El estudio de viabilidad puede documentarse en un informe separado de los otros documentos importantes de gestin e incluso como apndice de la especificacin del sistema. 3) Anlisis econmico: El anlisis de costo beneficio seala los costos de desarrollo del proyecto y los contrasta con los beneficios tangibles e intangibles del sistema. El anlisis de beneficios depender de las caractersticas del sistema. 4) Anlisis tcnico: Comienza con una definicin de viabilidad tcnica del sistema propuesto: Qu tecnologas se requieren?, Qu nuevos materiales, algoritmos y mtodos se requieren?. La evaluacin analtica no es siempre posible, sin embargo la modelizacin es un mecanismo efectivo para el anlisis tcnico. El analista comprueba el comportamiento del modelo y lo compara con el mundo real o al sistema esperado, obteniendo informacin para la viabilidad tcnica del sistema propuesto. 5) Asignacin y compromisos: Una vez que se ha respondido a las cuestiones relativas al anlisis hay que considerar soluciones alternativas. Cada funcin del sistema con su rendimiento requerido y sus caractersticas de interfaz, es asignada a uno o ms elementos del sistema.

17

Modelado de la Arquitectura del Sistema

Todos los sistemas basados en computadora pueden modelarse como la transformacin de la informacin empleando una arquitectura del tipo Interfaz de Usuario-Entrada-Proceso-Salida-Autocomprobacin. Mediante esta representacin un ingeniero, para desarrollar un modelo de sistema, emplea un esquema de arquitectura, asignando elementos a cada una de las cinco regiones de tratamiento del esquema: 1. Interfaz de Usuario 2. Entrada 3. Tratamiento y Control del Sistema 4. Salida 5. Mantenimiento y Autocomprobacin El resultado es un Diagrama de Contexto de Arquitectura (DCA):

El Diagrama de Contexto establece el lmite de informacin entre el sistema que se est implementando y el entorno en que va a operar. El DCA define todos los suministradores externos de informacin que emplea el sistema, todos los consumidores externos de informacin creados por el sistema y todas las entidades que se comunican a travs de la interfaz o realiza mantenimiento y autocomprobacin. En esencia el DCA sita a cualquier sistema en el contexto de su entorno exterior. Entre las regiones del DCA se especifica el flujo de informacin entre las mismas y en cada regin se especifican subsistemas y la informacin que fluye entre ellos, logrando llegar a un Diagrama de Flujo de la Arquitectura o DFA.

18

Documento de Especificacin del Sistema

Describe la funcin y el rendimiento de un sistema basado en computadora y las restricciones que gobernarn su desarrollo. La especificacin del sistema es el primer documento en el proceso de ingeniera de sistemas de computadoras: 1. Definicin del problema: descripcin del problema a resolver, situacin del sistema actual, informacin, archivos, etc. 2. Justificacin del sistema: debe justificarse l por qu? de una solucin computarizada. 3. Objetivos del sistema: (lo que se quiere alcanzar). Cuantitativo: tiempo de respuesta que tiene que tener el sistema, etc. Cualitativo: agilizar el control de stock, hacerlo ms seguro, etc. 4. Restricciones del sistema: (capacidad del sistema para resolver el problema). Restricciones de hardware. , si ya existe hardware hacer restricciones, tipos de respuestas que se necesitan para determinadas funciones, necesidad de confiabilidad, etc. 5. Funciones a proporcionar: asignar las funciones del sistema a ser provistas por el hardware , el software (objetivos), el personal. Para cada funcin del software se discute: informacin de entrada, procesamiento e informacin de salida. 6. Caractersticas del usuario: con un organismo de la empresa. 7. Ambiente: ambiente de desarrollo del sistema, de operacin y de mantenimiento. 8. Caractersticas prioritarias: lista de funciones en cuanto a su prioridad. 9. Criterios de aceptacin: pruebas a realizar. 10. Costo: contrato con el usuario. 11. Planificacin temporal: cuando el cliente espera el sistema. 12. Trminos especficos: a veces es necesario hacer un diccionario porque desconocemos trminos del lugar donde nos contratan.

19

UNIDAD N 3: "Planificacin del Proyecto".

La Planificacin del Proyecto es un conjunto de actividades, cuyo objetivo es suministrar un marco de trabajo que permita hacer estimaciones razonables de recursos, costos y tiempos. La estimacin es la base de todas las actividades de la planificacin de proyectos y sirve como una gua para una buena ingeniera de software. Las estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un comienzo de software. Adems, las estimaciones deberan definir los escenarios del mejor caso y peor caso de forma que los resultados del proyecto puedan limitarse. Toda estimacin tiene un riesgo inherente, cuyo efecto es la incertidumbre. Las estimaciones se ven afectadas por la familiaridad por esfuerzos similares anteriores, por lo que la disponibilidad de informacin histrica tambin determina el riesgo de la estimacin. El tamao del proyecto es otro factor importante que puede afectar a la precisin de las estimaciones, ocasionadas generalmente cuando el cliente cambia los requisitos. Incrementos en el tamao del proyecto pueden tener un impacto geomtrico en el coste y la planificacin del proyecto. El riesgo se mide por el grado de incertidumbre en las estimaciones cuantitativas establecidas por recursos, costos y planificacin temporal. Las actividades asociadas con la planificacin son: 1. mbito del Software 2. Recursos 3. Estimacin de Costos y Esfuerzo 4. Mtricas para el Software 5. Anlisis de Riesgo 6. Planificacin Temporal 7. Planificacin Organizativa El Documento del Plan de Proyecto incluye la documentacin resultante de las actividades anteriores.

1. mbito del Software

El mbito del Software describe la funcin, el rendimiento, las restricciones, las interfaces y la fiabilidad del software a implementar. Se evalan las funciones descriptas en el enunciado el mbito, y en algunos casos se refinan para dar ms detalles antes del comienzo de la estimacin. Dado que las estimaciones del costo y de la planificacin temporal estn orientadas a la funcin, muchas veces es til llegar a un cierto grado de descomposicin. Las consideraciones de rendimiento abarcan los requisitos de tiempo de respuesta y de procesamiento. Las restricciones identifican los lmites del software originados por el hardware disponible y por otros sistemas existentes.

2. Recursos
Son los recursos requeridos para hacer el sistema, si lo ubicramos en forma de pirmide en la base se encuentra el Entorno de Desarrollo (herramientas de software y hardware). En un nivel ms alto se ubican los componentes de software reutilizables y en el nivel ms alto se ubica los recursos humanos. Cada recurso se especifica con las siguientes caractersticas: Descripcin el recurso. Informe de disponibilidad. Fecha cronolgica en que se requiere el recurso. Tiempo en el que ser empleado. Tipos de Recursos HUMANOS: Se debe seleccionar los recursos humanos segn las habilidades tcnicas que se requieren para llevar a cabo el desarrollo. El nmero de personas requerido para un proyecto de software slo puede ser determinado despus de hacer una estimacin del esfuerzo de desarrollo. SOFTWARE REUTILIZABLE: La utilizacin de componentes de software existentes lleva a una reduccin importante del costo global. HARDWARE: Cada elemento de hardware debe ser especificado por el planificador del proyecto de software. Se deben considerar tres categoras: El sistema de desarrollo: es la computadora y perifricos asociados que se utilizan en la base de desarrollo. La mquina objetivo: es un procesador que ejecutar software como parte del sistema basado en la computadora. Otros elementos: del hardware del nuevo sistema. SOFTWARE: se utiliza como herramienta para el desarrollo de nuevo software. Existen herramientas que facilitan la creacin de nuevo software (metodologas, cdigo, cdigo reusable, etc.). 20

3. Estimacin de Costo y Esfuerzo

Los factores que influyen en el costo son: La capacidad de las personas que van a desarrollar el sistema Plazos para la finalizacin el sistema. Conocimiento del rea en que se va a desarrollar el sistema Complejidad del software Programa de aplicacin Programa de apoyo ej. : compilador -, programa de sistema ej. : S.O. Tambin influyen: El tamao del programa a desarrollar El tiempo disponible de las personas involucradas El nivel de confiabilidad determinado en la etapa de planificacin El nivel tecnolgico de lenguajes y equipos a usar. Nunca ser una ciencia exacta, son demasiadas las variables humanas, tcnicas de entorno. Para realizar estimaciones seguras de costo y esfuerzo hay varias opciones posibles: 1. Dejar la estimacin para ms adelante: 100% fiable al terminar el proyecto, no es prctica. 2. Basar la estimacin en proyectos similares ya terminados: los proyectos terminados deben tener caractersticas similares (el cliente, las condiciones de gestin, el Entorno de Desarrollo y los plazos). En muchas ocasiones no suelen ser buenos indicadores de futuros resultados. 3. Utilizar tcnicas de descomposicin relativamente sencillas para generar las estimaciones de costo y de esfuerzo de proyecto.

Modelos de Estimacin Existen tcnicas para la estimacin de coto y esfuerzo de dos tipos: Top Down: se estiman los costos globales y despus los parciales. Bottom Up: se estiman los costos de las partes del sistema y luego se obtiene el costo total. TCNICAS DE DESCOMPOSICIN: descompone cada mdulo, calcula el costo de cada uno (estimndolo mediante LCD o PF) y luego resume en general para la estimacin global del proyecto. ESTIMACIN BASADA EN EL PROCESO: es la tcnica ms comn para estimar un proyecto. o JUICIO EXPERTO: la estimacin de todas las tareas, individualmente, la hace una persona experta usando datos histricos de proyectos realizados con anterioridad, para luego obtener el costo total. o DELFI: es una extensin del Juicio Experto, distintas persona (expertas o no) hacen distintas estimaciones y luego por medio de un coordinador se trata de consensuar el costo total. DISTRIBUCIN DE ESFUERZOS:

La figura muestra una distribucin recomendada del esfuerzo donde se enfatiza el inicio (anlisis y diseo) y el final (prueba). Es solo una directriz. Las caractersticas de cada proyecto deben dictar la distribucin del esfuerzo. El esfuerzo gastado en la planificacin rara vez supera el 3%. El anlisis de requerimientos puede ir entre el 10% y el 20%. Normalmente se aplica entre el 20% y el 30% para el diseo del software. Las pruebas y posterior depuracin pueden contabilizar del 30% al 50%, el grado crtico del elemento del sistema de software a menudo dicta la cantidad de pruebas que se requieren. Por ejemplo: si un fallo puede provocar la prdida de una vida humana pueden considerarse porcentajes ms altos para la etapa de prueba.

21

4. Mtricas para el Software

Algunas razones por las que se mide el software son: Hacer una estimacin del costo. Indicar la calidad del producto. Evaluar la productividad de la gente que desarrolla el producto. Evaluar los beneficios (en trminos de productividad y calidad) derivados del uso de nuevos mtodos y herramientas de ingeniera de software. Ayudar a justificar el uso de nuevas herramientas o formacin adicional. Las mtricas de software tienen un conjunto de caractersticas fundamentales que deberan cumplir: Simple y fcil de calcular: debera ser relativamente fcil aprender a obtener la mtrica y su clculo no debera demandar un gran esfuerzo. Consistente y objetiva: debera siempre producir resultados sin ambigedad. Independiente del lenguaje de programacin: deberan basarse en el modelo de anlisis, modelo de diseo o en la propia estructura del programa. Ser un eficaz mecanismo para la realimentacin de calidad: debera proporcionar al desarrollador de software, informacin que le lleve a un producto final de mayor calidad. Consistente en el empleo de unidades y tamao: el clculo matemtico debera emplear medidas que no conduzcan a extraas combinaciones de unidades. Las mtricas pueden catalogarse en directas o indirectas. Las directas son tcnicas cuantitativas (medidas objetivas). Se obtienen del proceso o producto siendo observado y no dependen de otras medidas. Ej.: el costo y el esfuerzo del proceso, de las lneas de cdigo, el tiempo de ejecucin, el tamao de memoria requerido, los defectos observados en un perodo de tiempo. Las indirectas son tcnicas cualitativas (medidas subjetivas), como calidad del software. Dependen de medidas ms elementales. Ej.: la funcionalidad, complejidad, eficiencia, fiabilidad, facilidad de mantenimiento. Podemos clasificar las mtricas de software en: ORIENTADAS AL TAMAO: (directa) se utilizan las lneas de cdigo como medida clave. Son bastante polmicas. Ej. : LDC (lneas de cdigo), KLDC (miles lneas de cdigo). Los defensores ponen nfasis en lo fcil que es obtener una medida. Los opositores sostienen que la medida depende del lenguaje y que se pueden hacer programas ms cortos y mejor diseados. ORIENTADAS A LA FUNCIN: (indirecta) se centran en la utilidad o funcionalidad del programa. Un ejemplo es el mtodo denominado PF (punto de funcin) en la medicin se involucran las interfaces externas, nmero de archivos, nmero de peticiones de usuario, etc. El anlisis por puntos de funcin es un mtodo para cuantificar el tamao y la complejidad de un sistema software en trmino de las funciones de usuario que este desarrolla (o desarrollar). Esto hace que la medida sea independiente del lenguaje o herramienta utilizada en el desarrollo del proyecto. El anlisis por puntos de funcin est diseado para medir aplicaciones de negocios; no es apropiado para otro tipo de aplicaciones como aplicaciones tcnicas o cientficas. Esas aplicaciones generalmente median con algoritmos complejos que el mtodo de puntos de funcin no est diseado para manejar. El enfoque de puntos de funcin tiene caractersticas que sobrellevan los principales problemas de utilizar lneas de cdigo como mtrica del tamao del software. Primero, los puntos de funcin son independientes del lenguaje, herramientas o metodologas utilizadas en la implementacin. Segundo, los puntos de funcin pueden ser estimados a partir de la especificacin de requisitos o especificaciones de diseo, haciendo posible de este modo la estimacin del esfuerzo de desarrollo en etapas tempranas del mismo. Tercero, como los puntos de funcin estn basados en una visin externa del usuario del sistema, los usuarios no tcnicos del software poseen un mejor entendimiento de lo que los puntos de funcin estn midiendo. El mtodo resuelve muchas de las inconsistencias que aparecen cuando se utiliza lneas de cdigo como mtrica del tamao del software. En resumen, los puntos de funcin aparecen con ventajas sustanciales por sobre las lneas de cdigo, para fines de estimacin temprana del tamao del software. Adems es una medida ampliamente utilizada, y con xito, en muchas organizaciones que desarrollan software en forma masiva. Esta mtrica tambin es bastante polmica. Los defensores afirman que PF es independiente del lenguaje de programacin, los opositores afirman que el mtodo requiere destreza porque los clculos se basan ms en la subjetividad que en la objetividad.

22

Tambin se pueden clasificar segn la informacin que entregan: DE PRODUCTIVIDAD: se centran en el rendimiento del proceso de ingeniera de software. DE CALIDAD: proporciona una indicacin de cmo se ajusta el software a los requisitos implcitos y explcitos del cliente. Aunque existen muchas formas de medir la calidad, las mtricas ms usadas incluyen: correccin, facilidad de mantenimiento, integridad y facilidad de uso. DE TCNICA: se centra en las caractersticas del software (por ejemplo: la complejidad lgica o el grado de modularidad), ms que en el proceso a travs del cual ha sido desarrollado el software.

Ejemplos de Utilizacin de Mtricas Orientadas Al Tamao LDC - Lneas De Cdigo Medida directa del software y del proceso: -- productividad = kldc / persona_mes -- calidad = errores / kldc -- costo = $ / kldc Medida discutida porque depende del lenguaje y necesita una estimacin compleja Orientadas a la Funcin PF - puntos de funcin Medida indirecta del software y del proceso: -- productividad = pf / persona_mes -- calidad = errores / pf -- costo = $ / pf Medida independiente del lenguaje, de estimacin ms fcil pero subjetiva Calculo del PF: Parmetros # Entradas De Usuario # Salidas Al Usuario # Peticiones Al Usuario # Archivos # Interfaces Externas Total Factor de Peso Resultado

X X X X X

= = = = =

PF=TOTAL*[0.65+0.01*SUM(Fi)] i=1..14 Fi = Valores de ajuste de complejidad Valores de ajuste de complejidad 0- sin influencia 2- moderado 4- significativo

1- incidental 3- medio 5- esencial

Se debe asignar un valor de ajuste de complejidad a cada una de las siguientes preguntas: 1- copias de seguridad? 2- comunicacin de datos? 3- procesamiento distribuido? 4- rendimiento critico? 5- entorno existente? 6- entradas interactivas? 7- mltiples pantallas de entrada? 8- actualizacin de archivos interactiva? 9- e/s, archivos, peticiones son complejas? 10- procesamiento complejo? 11- Cdigo reutilizable? 12- Se diseo instalacin? 13- Es para distintas organizaciones? 14- fcilmente modificable?

23

5. Anlisis de Riesgo
Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre y el grado de prdida asociado con cada riesgo. Para hacerlo, se consideran diferentes categoras de riego: Riesgos del Proyecto: Amenazan al Plan de Proyecto. Los riesgos del proyecto identifican los problemas potenciales de presupuesto, planificacin temporal, personal, recursos, cliente y requisitos y su impacto en un proyecto de software. Riesgos Tcnicos: Amenazan la Calidad y la Planificacin Temporal del software que hay que producir. Identifican problemas potenciales de diseo, implementacin, de interfaz, verificacin y de mantenimiento. Riesgos del Negocio: Amenazan la viabilidad del software a construir. Los cinco principales riesgos de negocios son: 1. Construir un producto o sistema excelente que no quiere nadie en realidad (Riesgo de Mercado). 2. Construir un producto que no encaja en la estrategia comercial general de la compaa (Riesgo Estratgico). 3. Construir un producto que el departamento de venta no sabe como vender. 4. Perder el apoyo de una gestin experta debido a cambios de enfoque o a cambios de personal (Riesgo de Direccin). 5. Perder presupuesto o personal asignado (Riesgo de Presupuesto). Otra forma de categorizar los riegos es: Riesgos Conocidos: Son todos aquellos que se pueden descubrir despus de una cuidadosa evaluacin del Plan del Proyecto, del entorno tcnico y comercial en que se desarrolla el proyecto y otras fuentes de informacin fiables. Ejemplo: fechas de entrega poco realistas, falta de especificacin de requisitos o de mbitos de software, o un entorno pobre de desarrollo. Riesgos Predecibles: Se extrapolan de la experiencia en proyectos anteriores, por ejemplo: cambio de personal, mala comunicacin con el cliente, disminucin del esfuerzo del personal a medida que atienden peticiones de mantenimiento. Riesgos Impredecibles: Son extremadamente difciles de identificar por adelantado.

Identificacin del Riego La identificacin del riego es un intento sistemtico para especificar las amenazas al Plan de Proyecto. Identificando los riegos conocidos y predecibles, el gestor del proyecto da un paso adelante para evitarlos cuando sea posible y controlarlos cuando sea necesario. Un mtodo para identificar riesgos es crear una lista de comprobacin de elementos de riesgo, que consiste en una serie de preguntas a posibles riegos y las respuestas, analizadas en el Plan de Proyecto. Proyeccin del Riesgo La proyeccin del riego, tambin llamada estimacin del riesgo, intenta medir cada riesgo de dos maneras: - La probabilidad de que el riesgo sea real. - Las consecuencias de los problemas asociados con el riesgo, si ocurriera. Evaluacin del Riesgo Se intenta dar prioridades a los riesgos que no se haban cubierto y se empieza a pensar las maneras de controlar y/o impedir los riesgos que sean ms probables que aparezcan. La evaluacin del riego definir un nivel de referencia del riesgo, que posee un nico punto de referencia o punto de ruptura, que marcar la decisin de seguir con el proyecto o dejarlo. Tratamiento del Riesgo Una estrategia eficaz para tratar los riesgos debe considerar tres aspectos: 1. Evitar el Riesgo: Se plantean las estrategias para evitar los riesgos. 2. Supervisar el Riesgo: Se identifican los factores que pueden proporcionar una indicacin de si el riesgo se est haciendo ms o menos probable. A medida que progresa el proyecto, comienzan las actividades de supervisin del riesgo. El jefe de proyecto supervisa estos factores. 3. Gestin del Riesgo y Planes de Contingencia: Asume que los esfuerzos de reduccin ha fracasado y que el riesgo se ha convertido en una realidad. Se establecen los Planes de Contingencia para el riego.

24

6. Planificacin Temporal
Puede verse desde dos perspectivas diferentes: La fecha final ya est establecida, la establece el cliente. La fecha final es organizada por el que realiza el software. Si un cliente solicita a un grupo de desarrollo de software la construccin de un producto en un tiempo determinado, y despus de una cuidadosa estimacin y anlisis de riesgo, el gestor de anlisis de riesgo llega a la conclusin de que el software, tal y como se ha pedido, requerir ms tiempo para crearlo que el estipulado por el Cliente, se pueden seguir los siguientes pasos: 1. Realizar una estimacin detallada usando informacin de proyectos anteriores. 2. Empleando un modelo incremental, establecer una estrategia de desarrollo que proporcione una funcionalidad critica mnima para la fecha impuesta. Las dems funcionalidades se implementarn ms tarde. 3. Reunirse con el cliente y empleando la estimacin detallada, explicarle porque la fecha lmite impuesta no es realista. 4. Ofertar la estrategia de desarrollo incremental como alternativa. Se puede tambin proponer al cliente un aumento de personal, pero ello implicara un aumento en los costos. La Planificacin Temporal objetiva de un proyecto es necesaria porque si se retrasa el proyecto, la solucin de sumar ms personal al proyecto no es siempre aconsejable pues el personal agregado debe aprenderse el sistema y la gente que les ensea es la misma que estaba trabajando, y el proyecto se retrasa todava ms. Para desarrollar una Planificacin Temporal del proyecto, se debe distribuir un conjunto de tareas a lo larga de la duracin del proyecto. El conjunto de tareas variar dependiendo del tipo de proyecto. El propsito de controlar un proyecto es monitorear su progreso segn un plan, detectando desviaciones si las hay. Al planificar se debe ver como se relacionan el tiempo y el esfuerzo humano, como se divide el trabajo, que acciones son paralelas, como representar la agenda, etc. Para mejorar el control se divide el objetivo en submetas. Identificar las submetas permite asignar estimaciones, responsabilidades, fechas de inicio y fin, establecer la red de tareas. etc., estableciendo un calendario. Hay tcnicas para ayudar a establecer estos calendarios como son los diagramas de Gantt y PERT. La tcnica de evaluacin y revisin de programas (Pert) y el mtodo de camino crtico (CPM) son dos mtodos de planificacin temporal de proyectos que pueden aplicarse al desarrollo de software. Ambas tcnicas desarrollan una descripcin de la red de tareas del proyecto, es decir una representacin grfica o tabular de las tareas que deben acontecerse desde el principio hasta el final del proyecto. La red se define desarrollando una red de tareas asociadas con el proyecto y una lista de ordenamientos que indica en que orden debe ir cada tarea. El camino crtico se puede definir como la cadena de tareas que determina la duracin del proyecto. Tanto Pert como CPM permiten determinar el camino crtico, establecer las dimensiones de tiempo ms probables para las tareas individuales, aplicando modelos estadsticos y calcular los tiempos lmites de cada tarea, estimando el tiempo total del proyecto. Las limitaciones de tiempo que pueden discernirse de una red Pert o CPM pueden ser: Tiempo Temprano: Lo antes posible que se puede comenzar una tarea cuando todas las tareas precedentes se terminan con el mnimo de tiempo posible. Tiempo Tardo: Lo ms tarde que se puede iniciar la tarea sin que se retrase el tiempo mnimo de finalizacin del proyecto. Fecha ms Temprana de Finalizacin: Es la suma del tiempo temprano de la tarea ms la duracin de la tarea. Fecha Lmite de Finalizacin: Es el tiempo tardo de tarea ms la duracin de la tarea. Margen Total: La cantidad de tiempo extra o atrasos permitidos en la planificacin temporal de las tareas, de manera que el camino crtico de la red se mantenga conforme con la planificacin temporal.

25

MTODO PERT 1. Establecer la lista de tareas. 2. Construir una red (grafo dirigido). Nodo: inicio y fin de cada tarea.

i, j: acontecimientos t: tarea

3. Numerar los nodos

t0i t1i Nro.

t0i tiempo temprano: Es el mayor valor que aparece en las puntas de las flechas que llegan a ese nodo, es la suma de t0 del nodo anterior ms la duracin de la tarea. t1i tiempo tardo: Se calcula como el menor valor de cada una de las flechas que de l parten. 4. Calcular el camino crtico. El camino crtico lo forman las tareas crticas o nodos crticos. Nodo crtico: cuando el tiempo temprano es igual al tiempo tardo (t0i = t1i). No hay circuitos en el grafo y todos los nodos, excepto el primero y el final deben tener una tarea de la cul inicio o fin de duracin. Ej.: pg. 68 carpeta. Se empieza con los que no tienen ninguna dependencia, se calcula primero la fecha temprana, en cada uno de los nodos la duracin de la tarea. El nmero (Nro.) indica que vamos a finalizar en el instante nmero y t0i = t1i indica que no vamos a postergar su finalizacin.

GRFICO DE GANTT Es un grfico de tiempo que Permite establecer un calendario de las actividades o tareas. Tambin se pueden usar para la asignacin de recursos. 1. Cada tarea tiene como entrada el esfuerzo, la duracin y la fecha de inicio. Adems se asignan las tareas a individuos especficos. Como consecuencia de esta entrada se genera un grfico de tiempo, que permite vitalizar el desarrollo del proyecto, la concurrencia de tareas y las submetas importantes.

26

7. Planificacin Organizativa
Organizacin de las personas que estn involucradas en el desarrollo del proyecto. ORGANIZACIN DEL PROYECTO: El proceso de la direccin denota el influjo interpersonal mediante el cual los gerentes o directores se comunican con sus subalternos para la ejecucin de un trabajo. No existe una estructura organizacional perfecta para manejar los distintos tipos de proyectos. Existe una variada gama de estructuras organizacionales: Organizacin Funcional: Es la forma de organizacin ms comn y se basa en la estructura jerrquica bsica. Esta organizacin generalmente se descompone en varias unidades funcionales (equipos) diferentes, distribuyendo las tareas. La razn de ser de esta estructura radica en las teoras de administracin basadas en la especializacin, las cuales consideran que es ms fcil dirigir a especialistas si estos son agrupados segn su especialidad y el jefe de departamento tiene conocimientos de esa disciplina en particular. Este tipo de organizacin posee ventajas que descansan sobre su centralizacin de recursos similares, ya que, por ejemplo, brinda caminos de integracin claros y bien definidos para especialistas jvenes y adems, la ayuda mutua es fcilmente encontrada gracias a la proximidad fsica. Sin embargo, este tipo de organizacin posee debilidades. Por ejemplo, cuando se trabaja en proyectos mltiples, generalmente surgen problemas por el uso de los recursos. Otro ejemplo a citar es el de que cada departamento funcional pone nfasis en su especialidad ms que en los objetivos del proyecto. Pese a esto, la mayora de las compaas usan este tipo de organizacin no slo para sus proyectos, sino para todas sus actividades. Organizacin por Proyecto: Representa el opuesto a la organizacin funcional. El mismo equipo de personas realiza todo el desarrollo desde el anlisis hasta el mantenimiento. En una organizacin de proyecto, todos los recursos necesarios para realizar un proyecto son separados de sus unidades funcionales regulares y se renen como una unidad independiente de trabajo dirigida por un jefe de proyecto. Al jefe de proyecto se le concede una amplia autoridad sobre los recursos del proyecto y pueden adquirir nuevos recursos ya sea dentro o fuera de la organizacin. Todo el personal del proyecto esta bajo la autoridad del jefe de proyecto por el periodo que el proyecto dure. Las ventajas de este tipo de organizacin vienen de su objetivo nico y su unidad de comando. Se desarrolla un verdadero espritu de equipo bajo el claro entendimiento de, y enfocado a, un objetivo nico. La comunicacin informal es efectiva en un equipo fuertemente enlazado, y el director de proyecto tiene todos los recursos bajo su disposicin. Sin embargo, la organizacin de proyecto no es la solucin perfecta para todos los problemas de la direccin de proyectos, ya que por lo general, las instalaciones se duplican y los recursos son utilizados de forma ineficiente. Otro problema serio radica en que se produce inestabilidad laboral luego de terminado el proyecto temporal. Organizacin Matricial: varios equipos de personas lleva a cabo distintas tareas, pero cada equipo tiene un coordinador que controla el equipo y hay un jefe de todo el proyecto. La organizacin de matriz es una estructura multidimensional que trata de maximizar los puntos fuertes y minimizar los dbiles tanto de la estructura funcional como la de proyectos. Combina la estructura jerrquica vertical estandard con una estructura lateral u horizontal sobrepuesta de un coordinador de proyecto. Los mayores beneficios de la estructura de matriz son el balance de objetivos, la coordinacin a travs de las lneas de los departamentos funcionales, y la visibilidad de los objetivos del proyecto a travs de la oficina del coordinador de proyecto. La mayor desventaja es que el hombre en el medio trabaja para dos jefes. Verticalmente, responde al jefe del departamento funcional. Horizontalmente, responde al coordinador de proyecto o jefe de proyecto. En una situacin de conflicto puede quedar atrapado en el medio. El director de proyecto a menudo siente que no posee la autoridad suficiente sobre los departamentos funcionales. Por otro lado, el jefe del departamento funcional a menudo siente que el coordinador de proyecto esta interviniendo en su territorio. La eleccin final de la Estructura de Organizacin deber venir luego de considerar varios factores de la naturaleza de la tarea a realizar, las necesidades de la organizacin y el ambiente del proyecto. Es tambin posible ocupar las tres estructuras en una misma compaa, en diferentes proyectos. Tambin todas estas estructuras pueden ser utilizadas en un mismo proyecto en diferentes niveles por ejemplo, una organizacin global de matriz con estructura funcional en ingeniera y una organizacin de proyecto dentro de otra sub-rea funcional. Aunque hay argumentos a favor y en contra de cada alternativa, la opcin general cada vez se inclina ms hacia la organizacin en forma matricial, vislumbrndose como la ms productiva.

27

ORGANIZACIN DE GRUPO: Se refiere a la organizacin interna de los grupos de trabajo. Democrtico: no hay un jefe general, todos participan de la toma de decisiones. Con jerarqua: existe una cabeza conductora. Los equipos pueden estar asesorados por uno o ms especialistas, por plantillas de soporte (ejecutivos) y por un bibliotecario de software.

SEGUIMIENTO Y CONTROL: Quien controla que el proyecto se cumpla. Interno: realizado por las personas que hacen el desarrollo. Externo: auditorias o empresas que realizan la verificacin.

8. Documento del Plan de Proyecto

Proporciona una lnea de base con informacin de costos y de agenda que se utilizar a lo largo del plan de vida del software. 1. Modelo del ciclo de vida: se elige el paradigma a utilizar. 2. Estructura organizacional: se decide la estructura para nuestra organizacin. Estructura de administracin, de equipos, de distribucin de trabajo, definicin de puestos. 3. Personal y recursos: cuantas personas se necesitan y qu recursos fsicos. 4. Plan temporal: Pert - Gantt. 5. Estimacin de costos. 6. Revisin del proyecto: Mecanismos de supervisin y control del proyecto; cuantos, cuales y en que momento se van a realizar. 7. Herramientas y tcnicas. 8. Lenguaje de programacin. 9. Pruebas: se determina que tipo y cuando se realizan las pruebas, depende del ciclo de vida utilizado. 10. Documentacin. 11. Entregas: que entregas se harn (parciales o finales). 12. Entrenamientos y Materiales: quien, como y a quien se va a entrenar. 13. Plan de Instalacin. 14. Mantenimiento: quien lo va a hacer. 15. Mtodo y Tiempo de la Entrega Final. 16. Forma de pago. El plan de proyecto se produce como culminacin de la etapa de planificacin.

28

UNIDAD N 4: Anlisis de Requerimientos.

Para realizar bien el desarrollo del software es esencial realizar una especificacin completa de los requerimientos de los usuarios. Independientemente de lo bien diseado o codificado que este, un programa pobremente especificado decepcionar al usuario y har fracasar el desarrollo. La tarea del anlisis de requisitos es un proceso de descubrimiento y refinamiento. El anlisis de requerimientos es la tarea que plantea la asignacin de software al nivel de sistema y al diseo de programas. Facilita al ingeniero de sistemas especificar la funcin y comportamiento de los programas, indicar la interfaz con otros elementos del sistema y establecer las ligaduras de diseo que debe cumplir el programa. El anlisis de requisitos permite al ingeniero de software refinar la asignacin del software y construir modelos de los mbitos del proceso, de los datos y del comportamiento que sern cubiertos por el software. El anlisis de requerimientos proporciona al diseador una representacin de la informacin y de las funciones que se pueden traducir a un diseo de datos arquitectnico y procedimental.

Tareas del anlisis.

El anlisis se divide en cuatro reas: RECONOCIMIENTO: el analista establece contrato con el cliente y la organizacin de desarrollo, estudia la especificacin y el plan de proyecto, de forma que se asegure el reconocimiento del problema. EVALUACIN Y SNTESIS: el analista debe evaluar el flujo y la estructura de la informacin, definir y evaluar todas las funciones del software, entender el comportamiento del programa en el contexto de los sucesos que afectan al sistema, establecer las caractersticas de la interfaz y de cubrir las restricciones de diseo. El analista se centra bsicamente en el que, no en el como. Qu datos produce y consume el sistema? Qu funciones debe realizar?. ESPECIFICACIN: para definir las caractersticas y atributos del software se escribe una especificacin de requerimientos formal. Adems para los casos en que no se desarrolla un prototipo se realiza un manual del usuario preliminar. REVISIN: los documentos del anlisis de requerimientos sirven como base para una revisin conducida por el cliente y el tcnico. La revisin de los requerimientos casi siempre produce modificaciones en la funcin, comportamiento, representacin de la informacin, ligaduras o criterios de validacin.

Problemas del anlisis de requisitos.

El anlisis de requerimientos es una actividad de intensa comunicacin. Entre otros problemas se encuentra dificultad en la adquisicin de informacin, el manejo de la complejidad del problema, y a la gestin de los cambios que puedan ocurrir durante y despus del anlisis. Los problemas subyacentes al anlisis de requerimientos son atribuibles a muchas causas: Comunicacin pobre: que hace difcil la adquisicin de informacin. Tcnicas y herramientas inadecuadas: que producen especificaciones inadecuadas o imprecisas. Anlisis de requerimientos acotado: existe una tendencia a acotar el anlisis de requerimientos, conduciendo a un anlisis inestable. Fallo en considerar alternativas antes de que se especifique el software.

29

Principios Fundamentales del Anlisis.

En la pasada dcada, se desarrollaron varios mtodos de anlisis y especificacin del software. Cada mtodo de anlisis tiene nica notacin y punto de vista, pero todos ellos estn relacionados por un conjunto de principios fundamentales: 1) Dominio de la informacin: El dominio de la informacin de un problema debe representarse y entenderse. El dominio de la informacin tiene tres visiones diferentes de los datos que se procesan por los programas: EL FLUJO DE LA INFORMACIN: representa como cambian los datos y el control, a medida que se mueven dentro de un sistema. La entrada se transforma en datos intermedios y despus en datos de salida. EL CONTENIDO DE LA INFORMACIN: representa los elementos de datos individuales, de datos o de control, que componen otros elementos mayores de informacin. LA ESTRUCTURA DE LA INFORMACIN: representa la organizacin lgica de los distintos elementos de datos o de control. 2) Dominio Funcional: Deben definirse las funciones que debe realizar el software. 3) Comportamiento del Software: Debe representarse el comportamiento del software (como consecuencia de acontecimientos externos). 4) Divisin del problema: Normalmente los problemas son demasiado grandes y complejos para ser comprendidos como un todo. Por eso, tendemos a particionarlos. 5) Alcance: El proceso de anlisis debera ir de la informacin esencial hasta el detalle de la implementacin. Aplicando estos principios, el analista enfoca el problema sistemticamente. Se examina el dominio de la informacin de un modo que pueda entenderse completamente la funcin. La particin se aplica para reducir la complejidad. Son necesarias las visiones esenciales y de implementacin del software para acomodar las restricciones lgicas impuestas por los requerimientos del procesamiento, y las restricciones fsicas impuestas por otros elementos del sistema.

Construccin de Prototipos.
En muchos casos no es posible especificar completamente un problema en una etapa tan temprana. La construccin de prototipos ofrece un mtodo alternativo que da como resultado un modelo ejecutable del programa desde el cual pueden refinarse los requerimientos. Para construir los prototipos se aplican los siguientes pasos: 1) Evaluar las peticiones del software para determinar si el software a desarrollar es un buen candidato para la construccin de un prototipo. Los factores para saber si es un buen candidato son: rea de aplicacin, complejidad de aplicacin, caractersticas del cliente y del proyecto. Es esencial que el cliente participe en la evaluacin y refinamiento del prototipo y que sea capaz de tomar decisiones de requerimiento de forma oportuna. 2) Desarrollar una representacin abreviada de los requerimientos. 3) Crear una especificacin de diseo abreviada para el prototipo, luego de revisar la representacin de requerimientos. 4) Construir el prototipo, probar y refinar. 5) Una vez probado el prototipo, se presenta al cliente. El cliente conduce la prueba y sugiere modificaciones. 6) Modificaciones: los pasos 4 y 5 se repiten hasta que el prototipo haya evolucionado hacia el sistema de produccin, reuniendo todos los requerimientos del cliente y se perfeccionen sus errores o falencias. Mtodos y herramientas para la construccin. Para que la construccin de prototipos sea efectiva, un prototipo debe desarrollarse rpidamente, de forma que el cliente pueda comprobar los resultados y recomendar cambios. Para conseguir una construccin rpida, existen tres clases genricas de mtodos y herramientas: TCNICAS DE CUARTA GENERACIN: son ideales debido a que facilitan cdigo ejecutable rpidamente. COMPONENTES DE SOFTWARE REUSABLES: ensamblar en lugar de construir el prototipo, usando componentes existentes. ESPECIFICACIN FORMAL: son lenguajes que facilitan al analista crear interactivamente una especificacin. Llaman a herramientas automticas que traducen especificaciones en cdigo ejecutable y facilitan al cliente utilizar este cdigo para refinar los requerimientos formales.

30

Caractersticas de la Especificacin.
La forma de especificar tiene mucho que ver con la calidad de la solucin. Puede ser en papel (DFD), ejecutable (prototipo) o formal (lenguaje formal). Total y Completa. Consistente. Sin ambigedades. Que y no como. Funcionalidad. Verificable. Modificable. Formal. Refleje Dinamismo. Representacin Adecuada del Problema. Por niveles. Notacin Consistente.

Tcnicas Formales de Especificacin.

Una especificacin es formal si est en un lenguaje cuyo vocabulario, sintaxis y semntica estn definidos formalmente, por lo que en general estn basados en matemticas. Las Tcnicas Formales sirven para especificar las caractersticas funcionales y de comportamiento del sistema. Una de las razones ms fuertes para usar especificaciones formales es que stas ayudan a detectar errores y omisiones. Caractersticas: Concisas y no ambiguas Apoyan el razonamiento formal Dan una base para la verificacin de resultados Las especificaciones formales no se usan mucho por el esfuerzo que requiere escribirlas. Sin embargo existe evidencia que al usarlas se incremente la calidad del sistema y se reducen los costos de desarrollo. En la siguiente figura se ilustra como la especificacin formal se relaciona con otras actividades de desarrollo.

Ventajas: 1. Desarrollar una especificacin formal permite un buen entendimiento de los requerimientos del software y proporciona la base para un diseo ms confiable del software ayudando a reducir errores y omisiones. 2. Como las especificaciones formales estn compuestas por entidades matemticas, pueden analizarse usando mtodos matemticos, por lo que puede probarse consistencia y completitud, as como demostrar que la implementacin se corresponde a la especificacin. 3. Pueden procesarse automticamente usando herramientas que ayuden a desarrollar, entender y depurarlas. Las especificaciones pueden ayudar a definir los casos de prueba en la verificacin, de hecho se inici su estudio para apoyar la verificacin de programas. Dependiendo del lenguaje formal que se use, se puede construir un prototipo.

31

Razones por las que no se usan mucho: 1. No se adoptan nuevas tcnicas que no se este claro que reduzcan costos. 2. Muchos desarrolladores no han sido entrenados en su uso, en matemticas o lgica. 3. No se esta familiarizado con esas tcnicas. 4. No son fciles de usar para componentes interactivos de interfaces, procesamiento paralelo o sistemas dirigidos por interrupciones. 5. Hay pocos sistemas especificados formalmente. 6. Mucho del esfuerzo de investigacin se ha dedicado a notaciones y tcnicas ms que en herramientas de soporte. 7. Los que desarrollan especificaciones formales no entienden a los que hacen ingeniera de software prctica. En general hay mtodos formales maduros para sistemas secuenciales, hay avances en concurrencia que requieren ms refinamiento.

Existen dos tcnicas: Relacionales: se basan en definir las entidades y los atributos. Orientadas a Estados: se basan en describir los estados de las entidades en un momento dado. Relacionales. Ecuaciones implcitas: establecen las propiedades de una solucin sin establecer el mtodo para resolverlo. Ej.: M * M = I (dice qu voy a hacer y no como). Relaciones recurrentes: se utiliza para especificar funciones recurrentes, para describir el valor de una funcin en funcin de otros valores de la misma funcin. Ej. : Fibonacci f(0) = 0; f(1) = 1; f(n) = f(n 1) + f(n 2) con n > 1. Axiomas algebraicos: establecen las propiedades de una funcin definiendo un conjunto de axiomas y tambin demuestran teoremas por medio de los axiomas. Una especificacin algebraica es una tcnica en la que un objeto o tipo de datos se especifica en trminos de las operaciones definidas en este tipo (el lgebra). Este estilo de especificacin esta basado en el uso del lgebra y definen a un sistema como un lgebra heterognea, por ejemplo, una coleccin de conjuntos diferentes que tienen a un conjunto de operaciones definidas. Hay varias notaciones para especificaciones algebraicas, todas con caractersticas comunes. Una caracterstica importante que debe cumplir cualquier lenguaje de especificacin formal y en particular las algebraicas es promover la modularidad. a) Sintaxis de operadores: (ej. : pila) nuevo() pila tope(pila) elem pone(pila, elem) pila vaco(pila) V o F extrae(pila) pila Axiomas: (relacin entre los operadores) vaco(nuevo) = V tope(nuevo) = error vaco(pone(pila, elem)) = F extrae(pone(pila, elem)) = pila extrae(nuevo) = error tope(pone(pila, elem)) = elem b) Teorema: reemplazo (pila, elem) = error, si vaco(pila) = V o pone(extrae(pila), elem) Expresiones regulares: se basan en la descripcin de un alfabeto y reglas sobre dicho alfabeto. Ej. : tomos = a, b, c (componentes del alfabeto) alternacin a|b = {a, b} (elige una de las dos) composicin (a b) = {a b} iteracin (a)* = {e, a, aa, aaa,...} (a)+ = {a, aa, aaa,...} = (a)* - e

32

Orientadas a estados. El estado siguiente se obtiene aplicndole un estmulo al estado anterior. Tablas de Decisin: Trasladan las condiciones y acciones descriptas en un texto narrativo del procesamiento, a una forma tabular. Permiten al mdulo evaluar una combinacin compleja de condiciones y seleccionar las acciones apropiadas basndose en esas condiciones. Las reglas son 2n, donde n es el nmero de condiciones. Las columnas son reglas de decisin. Regla 1 Especificacin Condicin 1 de Condicin 2 Condiciones Condicin k (V,F) Especificacin Accin 1 de Acciones de Accin 2 (X) Accin t Regla 2 Especificaci n de Condiciones (V,F) Especificaci n de Acciones de (X) Especificacin de Condiciones (V,F) Especificacin de Acciones de (X) Regla n Especificaci n de Condiciones (V,F) Especificaci n de Acciones de (X)

Una tablas es completa si para cada posible decisin hay una accin, no se deja ninguna regla sin contemplar. Una tabla es incompleta en caso contrario. Una tabla es ambigua o contradictoria si para dos reglas iguales tenemos dos acciones distintas (contradictoria) y cuando dos columnas de decisin dicen lo mismo (redundante). Para desarrollar una tabla de decisin se aplican los siguientes pasos: 1. Hacer una lista de todas las acciones que pueden asociarse con un procedimiento especfico mdulo. 2. Hacer una lista de todas las condiciones o decisiones tomadas durante la ejecucin del procedimiento. 3. Asociar conjuntos especficos de condiciones con acciones especficas, eliminando combinaciones imposibles de condiciones; alternativamente, desarrollar cualquier permutacin posible de combinaciones. 4. Definir reglas indicando que accin o acciones ocurren para un conjunto de condiciones. Ejemplo: Sistemas de facturacin de un servicio pblico. Si la cuenta del cliente se factura usando un mtodo de tarifacin fijo, se establece un cargo mensual mnimo para consumos de 100 kWh (kilowatios-hora). En los dems casos, la facturacin por computadora aplica la tarifa A. Sin embargo, si la cuenta se factura usando un mtodo de facturacin variable, se aplicar la tarifa A para consumos por debajo de 100 kWh, con un consumo adicional facturado de acuerdo con la tarifa B. 1 V F V F X 2 V F F V X 3 F V V F X X X 4 F V F V 5 F F

Cuenta de Tarifa Fija Cuenta de Tarifa Variable Consumo < 100 KWH Consumo >= 100 KWH Cargo Mensual Mnimo Facturacin Tarifa A Facturacin Tarifa B Otro Tratamiento

33

Tablas y Diagramas de Transicin: El Diagrama de Transicin de Estados (DTE) representa el comportamiento de un sistema que muestra los estados y los sucesos que hacen que el sistema cambie de estado. En lugar de un diagrama se puede usar una representacin tabular. Adems el DTE indica que acciones (por ejemplo, activacin de procesos) se llevan a cabo como consecuencia de un suceso determinado. Un estado es un modo observable de comportamiento. Un DTE indica como pasa un sistema de un estado a otro. Se representan los estados de E/S posibles y en la tabla se refleja cul es el estado resultante al aplicar cierta entrada a un estado. Ej. : Estado Actual
S0 S1

Entrada a
S0 S1

a b
S1 S0 S0

a b b
S1

Ej.: Se reciben telegramas que comienzan con INTEL y terminan con FINTEL. Cada telegrama est formado por frases, cada frase est compuesta por palabras y termina con la palabra STOP. Al terminar cada frase hay que imprimirla.
Palabras
INTEL

Recibir frase Palabras

FINTEL

STOP

Recibir telegrama

Imprimir frase

Mecanismos de Estados Finitos: Un Mecanismo de Estado Finito combina los DFD, las expresiones regulares (para flujos de datos) y las tablas de transicin para realizar la descripcin ms detallada de los procesos del DFD incluyendo los distintos estados por los que puede pasar cada proceso. Los estados de cada proceso dependen de los datos de entrada del mismo.

34

 Redes de Petri: Se disearon para especificar y modelizar sistemas con componentes concurrentes o que requieren paralelismo, sincronizacin, etc., sobre todo sistemas de tiempo real. Tienen dos elementos fundamentales: - Eventos: actividades que estoy modelizando. - Condiciones: precondiciones o postcondiciones para esos eventos. De la validez o no de las precondiciones depende la ejecucin de la actividad para que se cumplan las postcondiciones. En trminos formales se define como una cuaterna: C = (lugares, transiciones, arcos, tokens) Lugares: condiciones (pre/post). Se definen como un conjunto {P1,..., Pn}. Representadas grficamente por crculos. Transiciones: tareas {t1,..., tn}. Representadas grficamente con una barra. Arcos: relaciones entre condiciones y tareas. {(Pi, tj),..., (tk, P1)}. Conectan Lugares y Transiciones. precond. para tj postcond. para tk Tokens: marcaciones en los lugares o condiciones {M(Pi) = x}, donde x es la cantidad de Tokens o marcaciones en los lugares. Para habilitar las transiciones: una transicin est habilitada cuando cada lugar (Pi) tiene al menos tantos tokens como arcos a la transicin . Cuando disparo una transicin habilitada: 1. Remuevo los tokens de lugares de entrada (Precondiciones) 2. Distribuyo tokens en lugares de salida (Postcondiciones). 3. Cambio la marca. Ej. : 1 token en P1 puedo habilitar t1, significa pasar un token a P2, P3 y P4 puedo habilitar t2, esto implica poner un token en P5.

Expresin de paralelismo: Esto implica que se tienen que ejecutar en forma paralela para poder llegar al final. Empiezan y terminan juntos.

Este se llega a ejecutar cuando los 3 anteriores terminan.

35

Expresin de exclusin mutua: P1 t1 P2 t2 P3 Puedo disparar t1 o t2. Pero s primero ejecuto una, despus la otra ya no la podr ejecutar.

Condicin de bloqueo: P0 t1 1 P1 0 0 P2 t2 P3 1 t1 y t2 estn bloqueados pues para para poder disparar t1 necesito disparar t2 pero para t2 tengo que disparar t1. no lo puedo resolver.

Problema: seccin crtica

Problema: productor - consumidor:

36

Redes de Petri Ejemplo C = (P, T, I, O) P = {p1, p2, p3, p4, p5} T = {t1, t2, t3, t4} I (t1) = {p1} O (t1) = {p2, p3, p5} I (t2) = {p2, p3, p5} O (t2) = {p5} I (t3) = {p3} O (t3) = {p4} I (t4) = {p4} O (t4) = {p2, p3}

Anlisis de Redes de Petri Permiten evaluar el modelo Podemos verificar Ausencia de deadlock Alcanzabilidad Seguridad Ejemplo: Fbrica y Pedidos La fbrica espera hasta un pedido, lo produce y lo enva para su entrega. Las condiciones son: A. Fbrica esperando B. Pedido esperando C. Fbrica trabajando D. Pedido completo Las Eventos son: 1. Llega un pedido 2. La fbrica comienza con el pedido 3. La fbrica termina con el pedido 4. El pedido es enviado para su entrega Precondiciones & Postcondiciones: Eventos 1 2 3 4 Condiciones -> modelamos con sitios Eventos -> modelamos con transiciones Precondiciones -> Entradas a transiciones Postcondiciones -> Salidas de transiciones Grfico Precondiciones ninguna a, b c d Postcondiciones b c d, a ninguna

37

Documento de Especificacin de Requerimientos (SRD).

Objetivos. 1. Descripcin de la informacin: flujo / contenido / estructura / interface / DFD. 2. Descripcin funcional: particin del sistema, explicacin de las funciones, rendimiento esperado de las funciones, sugerencias de diseo, se pueden usar las tcnicas formales para describir las funciones. 3. Criterios de validacin: que criterios se van a tener en cuenta para validar el sistema, costo del rendimiento, clases de test, respuesta esperada, consideraciones especiales. 4. Diccionario de datos asociados: el que desarrolla el software y el cliente deben realizar una revisin de la especificacin de requerimientos de software (y el prototipo). Debido a que la especificacin constituye el fundamento de la fase de desarrollo, se debe tener un cuidado extremo en realizar esta revisin. Una vez completada la revisin queda terminada la especificacin de requerimientos de software y se convierte en un contrato para el desarrollador.

Metodologas de Anlisis de Requerimientos.

Orientadas al Flujo de Datos. Orientadas a la Estructura de Datos. Orientadas al Objeto. (comparte las dos anteriores)

Orientados al Flujo de Datos.

A medida que la informacin se mueve a travs del software, es modificada por una serie de transformaciones. El diagrama de flujo de datos (DFD) es una tcnica grfica que describe el flujo de la informacin y las transformaciones que se aplican a los datos conforme se mueven de la entrada a la salida.
Entidad externa Inf. de e/ Inf. de s/ Entidad externa

Sistema basado en computadora

Entidad externa

Inf. de e/

Inf. de s/

Entidad externa

Se puede usar el diagrama de flujo de datos para representar un sistema o un software a cualquier nivel de abstraccin. De hecho, los DFDs pueden ser refinados en niveles que representan un mayor flujo de la informacin y un mayor detalle funcional. Un DFD de nivel 0 tambin se denomina modelo fundamental del sistema o modelo de contexto y representa el elemento de software completo como una sola burbuja con datos de entrada y salida representados por flechas de entrada y salida respectivamente. A partir del DFD de Nivel 0 para mostrar ms detalle aparecen representados procesos (burbujas) y caminos de flujo de informacin adicionales. Cada uno de los procesos representados en el nivel 1 es una subfuncin del sistema general en el modelo del contexto. Notacin bsica. Entidad externa: un productor o consumidor de informacin que reside fuera de los lmites del sistema. Funcin: un transformador de informacin que reside dentro de los lmites del sistema. es lo que determina la funcin especfica Flujo de datos: un elemento o una coleccin de elementos. La cabeza de la flecha indica la direccin del flujo de datos. Archivo: un depsito de datos puede ser tan sencillo como un buffer, una cola o tan sofisticado como una base de datos relacional. IDENT Desc.

Elemento de datos Almacn de Datos

38

Flujos permitidos. Funcin Archivo. Funcin Funcin. Funcin Entidad externa. Archivo Entidad externa Es importante sealar que el diagrama no proporciona ninguna indicacin explcita de la secuencia de procesamiento. Podemos refinar cada una de las burbujas en distintos niveles para mostrar un mayor detalle. Ej. :
NIVEL N A F V A F1 W F3 Y Z F4 F5 B F2 X B

Se debe mantener la continuidad del flujo de informacin, es decir que la entrada y la salida de cada refinamiento deben ser las mismas. La notacin bsica que se usa para desarrollar el DFD no es en si misma suficiente para describir los requisitos. Para responder a esto se utiliza el diccionario de datos. En el nivel 0 es el nico nivel que se pueden pasar flujos sin nombrarlos. Diccionario de datos. Un anlisis de dominio de informacin puede ser incompleto si solo se considera el flujo de datos. Como cada flecha del DFD puede representar ms de un elemento de informacin, el analista debe disponer de algn mtodo para representar el contenido de dichas flechas, este es el diccionario de datos. Define los elementos de informacin sin ambigedades, puede dar informacin sobre la funcin, la cual no puede ser inmediatamente obvia a partir de un examen del DFD. El diccionario de datos se expande hasta que todos los datos compuestos han sido representados como elementales o son trminos que pueden ser bien conocidos. Estructuras: Funcionales: o Nombre o Descripcin(referencia a lo que hace) o Entrada o Salida

Archivos: o Descripcin o Nombre o Contenido o Flujo de datos de E/S Datos Elementales: o Nombre o Descripcin o Alfanumrico o Numrico

Flujo de Datos: o Nombre o Fuente o Destino o Descripcin o Estructura de datos con que hice el flujo o Volumen de informacin(estimacin de cuantos hace en el da) Estructura: o Nombre o Descripcin o Descripcin de campos o Flujos relacionados o Volumen

Notacin: = compuesto por + secuencia [ ] seleccin [ ]n n repeticiones ( ) datos opcionales * * comentario

39

Orientados a las Estructuras de Datos.

Representan los requerimientos de software centrndose en las estructuras de datos en vez de en el flujo de datos. Aunque cada mtodo tiene un enfoque y una notacin distinta, todos tienen algunas caractersticas comunes: 1. Todos ayudan al analista en la identificacin de los objetos de informacin clave (tambin llamadas entidades o elementos) y de las operaciones (tambin llamadas acciones o procesos). 2. Todos asumen que la estructura de la informacin es jerrquica. 3. Todos requieren que se represente la estructura de datos usando las construcciones secuencia, seleccin y repeticin. 4. Todos proporcionan un conjunto de pasos para transformar una estructura jerrquica en una estructura de programa. Diagrama de Warnier. CLP (construccin lgica de programas), presenta elementos para el anlisis y el diseo. Comenzando con la representacin formal de las estructuras de datos, el mtodo conduce a la derivacin de procedimientos y culmina con mtodos sistemticos, para la generacin de pseudo cdigo, verificacin y optimizacin. La notacin para las estructuras de datos, usada en CLP, es el diagrama de Warnier que describe jerarquas, repeticin explcita e informacin condicional. Entonces el CLP comienza con la especificacin de E/S usando diagramas de Warnier. Warnier ha desarrollado una tcnica llamada organizacin detallada, en la que el conjunto de instrucciones puede desarrollarse a partir de la organizacin lgica del programa. Warnier define los siguientes tipos de instrucciones: Entrada y preparacin de la entrada. Bifurcaciones. Salida y preparacin de la salida. Llamadas a subprogramas. Una organizacin detallada se desarrolla generando listas de instrucciones mediante tipo. La instruccin se escribe y correlaciona con los bloques de procesamiento apropiados con una indicacin numrica. Para cada tipo de instrucciones se prepara una lista, despus se agrupan y organizan las instrucciones con el mismo identificador de bloque de procesamiento en una secuencia de entrada procesamiento salida. Ej. : Organizacin de un peridico. Seccin Principal Diagrama de Warnier Noticia Cabecera Noticia Nacional Seccin Noticia Cabecera Noticia Local Principal Noticia Nacional Seccin Editorial Noticia Local Columna editorial Seccin Editoriales(1,3) Cartas al director Peridico Editorial Cartas(1,1) Caricatura satrica Caricaturas(0,1) {puede haber 1 o Seccin Secundaria Seccin Not. Dep. ninguna} Noticias Deportivas Secundaria Not. Econ. Perfil empresarial Noticias Econmicas Anuncios Perfil laboral Anuncios por palabras Se usa { para diferenciar niveles. Todos los nombres dentro de la llave indican secuencia + representa seleccin

40

Metodologa de Jackson. Primero identifico: - Entidades (analizando los sustantivos) - Acciones (analizando los verbos) 1. Modelar el problema especificando las estructuras de datos de entrada y salida.
SECUENCIA SELECCIN ITERACIN

2. Identificar puntos de correspondencia entre rboles de entrada y salida y obtener el modelo estructural. 3. Expandir el modelo estructural a un diseo detallado. Hacer lista de operaciones. Asociar operaciones con la estructura del programa. Desarrollar pseudo cdigo.

41

Ejemplo: 1. Archivo de entrada dto. Especialidad nombre 01 perforaciones Juan 01 perforaciones Jos 01 perforaciones NN 01 albail NN 01 albail NN 01 pintor NN 02 albail NN 02 soldadura NN

Empezamos representando datos de entrada

Arch. de Empl.

Grupos de reg. por dto. y por * especialidad

iteracin

Reg. de Empl. *

Dto.

Espec.

Nombre

Listado de Esp. Ttulo Lnea por dto. y espec.

Dto. Reporte: Dto. Espec. Cant. 01 perf. 3 01 albail 2 01 pintor 1 02 albail 1 02 soldador 1

Espec.

Cant.

Estructura de datos de salida

2. Identificar puntos de correspondencia Hay correspondencia en el nivel

Grupos de reg. por * dto. y por especialidad Lnea por dto. * y espec.

Entonces el modelo estructural queda:

Procesar listado

1 2

3
Procesar titulo

Procesar grupo por dto. y esp.

9 10 8

4 5 6 7 3

Procesar por reg.

Imprimir lnea

3. Expandir: Listado de operaciones 1 abrir archivos de empleados. 2 imprimir ttulo 3 leer registro 4 cantidad empleados = 0 5 dto. actual = dto. 6 esp. actual = esp. 7 cant. emp = cant. emp. + 1 8 imprimir lnea 9 cerrar archivo 10 terminar

42

Diagramas de Entidad Relacin (DER). Es una notacin grfica para modelar datos. Es un modelo de red que describe con un alto nivel de abstraccin la distribucin de datos almacenados en un sistema. Es una herramienta efectiva de modelado de datos para comunicarse con los usuarios ejecutivos de mayor nivel de una organizacin o el grupo de administracin de bases de datos. Los componentes de un DER son: Entidades: objetos (concretos o conceptuales) de la aplicacin. Las entidades del mismo tipo se agrupan en un conjunto de entidades. Relaciones: asociaciones entre una o ms entidades. Las relaciones se definen en funcin del grado, cardinalidad y dependencia de existencia. Atributos: describen propiedades de las entidades y relaciones. Son identificadores (sirven como clave) o descriptores. De acuerdo a su grado las relaciones pueden ser: unarias, binarias, ternarias o n-rias. La cardinalidad de una relacin puede ser: N:N de muchos a muchos 1:N uno a muchos 1:1 uno a uno La cardinalidad puede ser mandataria u opcional. A las entidades que no tienen clave propia y no tienen existencia propia se las denomina entidades dbiles. Generalizacin: En el DER es posible establecer jerarquas de generalizacin entre las entidades. Una entidad E es una generalizacin de un grupo de entidades E1...En si cada objeto de E1...En es tambin un objeto de E. En la generalizacin se utilizan los conceptos de herencia. Especializacin: En una especializacin existen entidades del super-tipo que no estn en los subtipos. Tambin existe el concepto de herencia.

43

Orientados a los Objetos.

Introduce el concepto de objeto, clase, atributo, miembro, herencia. Para un objeto se definen sus atributos, y de que clase es miembro. Un objeto hereda todos los atributos y operaciones de la clase. Las operaciones modifican uno o ms atributos del objeto. El objeto encapsula datos, operaciones y otros objetos. La encapsulacin significa que toda esa informacin esta empaquetada bajo un solo nombre y puede ser reutilizada como especificacin o como componente de otro programa. Orientacin a los objetos = objetos + clasificacin + herencia + comunicacin Se deben: Identificar los objetos Especificar atributos Definir operaciones Comunicacin entre objetos Ejemplo:
A Op. 1 Op. 2 mensaje C Op. 6 Op. 7 Op. 8 B Op.3 OP. 4 Op.5

44

UNIDAD N 5: Diseo del software.

Fase de desarrollo.
Traduce un conjunto de requerimientos en un software. El primer paso de esta fase se centra en el diseo. Se desarrolla una estructura modular, se definen las interfaces, y se establecen las estructuras de datos. Los criterios de diseo se utilizan para conseguir la calidad. Se realiza un primer borrador del documento de diseo. A continuacin se consideran los aspectos procedimentales de cada componente modular del diseo del software Despus que se ha realizado el diseo se comienza a codificar. Se genera un programa usando un lenguaje de programacin apropiado. El cdigo se revisa para mantener un estilo y claridad, pero debe ser directamente asociable a una descripcin de diseo detallada. L etapa final del desarrollo est asociada a la prueba del software Se realizan tres tipos de pruebas: Las pruebas de unidad intentan validar el rendimiento funcional de un componente individual del software. La prueba de integracin es un mtodo de construccin de la arquitectura de software a la vez que prueba las funciones e interfaces. La prueba de validacin prueba que se hayan cumplido todos los requerimientos.

Diseo.
Es el proceso de aplicar distintas tcnicas y principios con el propsito de definir el sistema con los suficientes detalles para permitir su realizacin fsica. Usando una de las distintas metodologas de diseo se realiza (desde el punto de vista tcnico) el diseo de datos, arquitectnico y el diseo procedimental. Diseo de datos: transforma el modelo del campo de informacin creado durante el anlisis, en las estructuras de datos que se van a requerir para implementar el software. Diseo arquitectnico: define las relaciones entre los principales elementos estructurales del programa. Diseo procedimental: transforma los elementos estructurales en una descripcin procedimental. Es aqu donde se toman decisiones que afectaran finalmente al xito de la implementacin del programa y con igual importancia a la facilidad de mantenimiento. Sin diseo nos arriesgamos a construir un sistema inestable, un sistema que fallar cuando se realicen pequeos cambios, que puede ser difcil de probar y cuya calidad puede no ser evaluada ms tarde. Desde el punto de vista de gestin de proyecto el diseo de software se realiza en dos pasos: Diseo preliminar: involucra el diseo de datos y arquitectnico, se refiere a la transformacin de los requerimientos de datos y arquitectura de software (se realiza un documento de diseo preliminar). Diseo detallado: involucra nuevamente el diseo de datos, pero ahora en detalle, aqu el refinamiento de la representacin arquitectnica conduce a una estructura de datos detallada y a representaciones algortmicas del software (diseo procedimental).

45

Fundamentos del diseo. proporcionan la base necesaria para que funcione correctamente.
Refinamiento: la arquitectura de un programa se desarrolla en niveles sucesivos de refinamientos de los detalles procedimentales. Se desarrolla una jerarqua descomponiendo una declaracin de una funcin muy grande de una forma sucesiva hasta que alcancen las sentencias del lenguaje del programa. El proceso de refinamiento es anlogo al usado en el anlisis de requerimientos. La diferencia est en el nivel de detalle, no en el mtodo. Arquitectura del software: se refiere a dos caractersticas importantes de los programas: Estructura jerrquica de los mdulos. Estructura de los datos. La arquitectura del software se obtiene mediante un proceso de particin, que relaciona los elementos de una solucin de software como parte de un problema del mundo real definido en anlisis de requisitos. Cada mtodo de diseo da como resultado una estructura distinta. Modularidad: el software se divide en elementos con nombres y direcciones separados, llamados mdulos, que se integran para satisfacer los requerimientos del problema. Es ms fcil resolver un problema complejo cuando se lo parte en trozos manejables. El esfuerzo para desarrollar un mdulo individual decrece conforme el nmero de mdulos se incrementa, pero aumenta el esfuerzo asociado con las interfaces entre ellos. La modularidad mejora la calidad del diseo y a su vez facilita la implementacin, depuracin, pruebas, documentacin y mantenimiento del producto. Abstraccin: cuando se considera una solucin modular a cualquier problema pueden formarse muchos niveles de abstraccin. En el nivel superior de abstraccin se establece una solucin en trminos amplios, en los niveles inferiores se toma orientacin ms detallada y en el nivel inferior se establece la solucin de forma que pueda implementarse directamente. Hay abstraccin de datos (coleccin de datos que describe un objeto) y de procedimientos (determina la secuencia de instrucciones que tienen una funcin limitada y especfica) y de control (al igual que la procedimental y de datos implica un mecanismo de control del programa sin especificar los detalles internos). Ocultamiento de informacin: oculta a otros mdulos los detalles de implementacin, mostrando solo las interfaces. El ocultamiento implica que una modularidad efectiva pueda lograrse definiendo un conjunto de mdulos independientes que se comuniquen con los otros mediante la informacin necesaria para realizar la funcin del software. Impide que se propaguen errores improductivos inadvertidamente. Independencia funcional: Es una derivacin directa del concepto de modularidad y de los conceptos de abstraccin y ocultamiento. Se trata de disear software de forma que cada mdulo se centre en una subfuncin especfica de los requisitos y tenga una interfaz sencilla, cuando se ve desde otras partes de la estructura del software.La independencia funcional se mide con dos criterios: cohesin y acoplamiento. COHESIN:
ALTA

SI

Funcin nica ?

NO Relacin

BAJA

Funcional: cada mdulo ejecuta una funcin. Secuencial: la salida de una tarea es la entrada de otra en el mismo mdulo. Por eso importa la Relacin secuencia, la forma en que las por tareas estn asignadas. datos Comunicacional: abarca mdulos cuyas tareas realizan actividades sobre una misma estructura de datos. de Procedimiento: son mdulos cuyas actividades estn Relacin relacionadas por el control y por deben ejecutarse en un orden control especfico. Temporal: un mdulo contiene tareas que estn relacionadas porque se ejecutan al mismo tiempo. Lgica: son mdulos que tienen tareas Ni datos lgicamente relacionadas (ej.: Ni control conjunto de tareas de entrada). Coincidental: segmentacin arbitraria del cdigo, un mdulo que realiza tareas debidamente relacionadas ente si.

46

Lo importante es intentar conseguir una alta cohesin y saber reconocer la baja cohesin, de forma que se pueda modificar el diseo para obtener mayor independencia funcional. ACOPLAMIENTO: El acoplamiento depende de la complejidad de las interfaces entre los mdulos, del punto en que se hace una entrada o referencia aun mdulo y de los datos que pasan a travs de la interfaz. En el diseo de software buscamos el ms bajo acoplamiento posible. El acoplamiento es la interdependencia entre los mdulos.
BAJO

ALTO

1) Sin acoplamiento 2) De datos: hay relacin entre los mdulos por el pasaje de datos. 3) De estructura de datos: ambos mdulos conocen la misma estructura. 4) De control: se pasan datos de control, son aquellos datos que significan algn tipo de evaluacin en el mdulo receptor. 5) Externo: se refiere a mdulos con interface en el mundo exterior (perifricos). 6) Globales o por reas comunes: distintos mdulos acceden al mismo conjunto de datos. 7) Por contenido: un mdulo utiliza informacin de datos o control contenida dentro de otro mdulo.

Criterios para obtener calidad en el diseo.

Organizacin jerrquica: debe exhibir una organizacin jerrquica que haga uso inteligente del control de cada uno de los elementos de software. Diseo modular: debe estar particionado lgicamente en elementos que realicen funciones y subfunciones especficas. Debe contener una representacin distinta y separable de los datos y procedimientos. Debe conducir a mdulos que exhiban caractersticas funcionales independientes. Debe derivarse del anlisis de requisitos. Debe reducir el acoplamiento y mejorar la cohesin.

Diseo de Datos.
Es la primera y quizs la ms importante de las tres actividades de diseo. El impacto de la estructura de datos sobre la estructura del programa y la complejidad procedimental hace que el diseo de datos tenga una profunda influencia en la calidad del software. Los datos bien diseados conducen a una mejor estructura de programa, modularidad y reduccin de la complejidad procedimental. PRINCIPIOS: 1) Aplicar metodologas de anlisis de datos (Se deben desarrollar y revisar las representaciones de flujos y contenido de datos.). 2) Identificar todas las estructuras de datos y las operaciones que se han de realizar sobre estas. 3) Usar diccionario de datos (para definir el diseo de los datos y el software). 4) Refinar el diseo (obtener una estructura de datos ms detallada a medida que se avanza en el refinamiento). 5) Ocultar la representacin de la estructura de datos. 6) Desarrollar bibliotecas de estructuras de datos y operaciones.

Diseo Arquitectnico.
El objetivo principal del diseo arquitectnico es desarrollar una estructura de programa modular y representar las relaciones de control entre los mdulos. Adems el diseo arquitectnico mezcla la estructura del programa y la estructura de datos y define las interfaces que facilitan el flujo de los datos a lo largo del programa (se hace la carta de estructura derivada del DFD).

Diseo de la Interfaz.
El Diseo de Interfaz se concentra en tres reas importantes: 1. El diseo de interfaces entre los mdulos de software. 2. El diseo de interfaces entre el software y otros productores y consumidores no humanos de informacin. 3. Entre el hombre y la computadora.

47

Diseo Procedimental o Detallado.

El diseo procedimental se realiza despus de que se ha establecido la estructura del programa y de los datos, el diseo procedimental debe especificar los detalles de los procedimientos sin ambigedades. Es por ello que no se usa un lenguaje natural sino que debe usarse una forma ms restringida para tal especificacin. Programacin Estructurada. Cualquier programa, independientemente del rea de aplicacin o complejidad tcnica, puede disearse e implementarse usando solo las tres construcciones estructuradas: secuencia, condicin y repeticin. El uso de las construcciones estructuradas reduce la complejidad, y por lo tanto facilita la legibilidad, prueba y mantenimiento. Herramientas para el Diseo Procedimental. GRFICAS: Diagramas de flujo: Es la herramienta grfica ms ampliamente usada (se pueden representar construcciones no estructuradas). Condicin Repeticin Seleccin Secuencia
F V F V F F V F V V

Diagrama de Nassi Schneiderman: Es un diagrama de cajas, surgi del deseo de desarrollar una representacin del diseo procedimental que no permitiera la violacin de las construcciones estructuradas.

TABULARES: Tablas de decisin: Dan una herramienta que traslada las acciones y condiciones (descriptas en un texto narrativo del procesamiento) a una forma tabular. TEXTUALES: PDL: (lenguaje de diseo de programas o lenguaje de pseudo cdigo) A primera vista se parece a Pascal o Ada, la diferencia es que se usa texto narrativo insertado directamente dentro de la secuencia del lenguaje de diseo de programas.

48

Metodologas de Diseo.
Diseo orientado al flujo de datos.
Este diseo permite una cmoda transicin de la informacin (por ejemplo, el DFD contenido en la especificacin de requisitos) a una descripcin de diseo de estructura del programa. Se realiza como parte de un proceso de 5 pasos: 1) Establecer el tipo de flujo de informacin. 2) Determinar los lmites del flujo. 3) Convertir el DFD en la estructura del programa. 4) Definir la estructura de control mediante factorizacin. 5) Refinar la estructura. El tipo de flujo s lo que determina el mtodo de conversin requerido en el paso 3. Hay dos tipos de flujos: de transformacin y de transaccin. Flujo de Transformacin. La informacin entra al sistema mediante caminos que transforman los datos externos a una forma interna y se identifica como flujo entrante. En el interior del software se produce una transicin. Los datos entrantes pasan a travs del centro de transformacin movindose a lo largo de caminos que conducen ahora hacia la salida.

Flujo de Entrada

Centro de transformacin

Flujo de salida

ANLISIS DE TRANSFORMACIN: Es un conjunto de pasos que permiten a un DFD, con caractersticas de flujo de transformacin convertirse en una carta de estructura. 1. Revisar el DFD: nivel 0 del DFD e informacin complementaria. 2. Refinar el DFD: se examinan los siguientes niveles para obtener ms niveles. 3. Determinar tipo de flujo: el diseador selecciona una caracterstica global del flujo basndose en la naturaleza prevaleciente del DFD. 4. Identificar el centro de transformacin: de esta manera se especifican los lmites del flujo de llegada y salida (que estn abiertos a interpretaciones). 5. Realizar el primer nivel de factorizacin: Flujo de Entrada Transformacin Flujo de salida

M: Este mdulo coordina las acciones de los de nivel inferior.

Controla la llegada de informacin

Controla el flujo de transformacin

Controla la salida de informacin

6. Realizar el segundo nivel de factorizacin: se desarrollan los mdulos de nivel inferior. 7. Se refina la estructura usando medidas heursticas de diseo: con los dos pasos anteriores obtuve a partir del DFD una carta de estructura, ahora la perfecciono usando criterios para el buen diseo.

49

Flujo de Transaccin. El flujo de transaccin se caracteriza por el movimiento de datos a travs de un camino de llegada que convierte la informacin del mundo exterior en una transaccin. Se evala la transaccin y de acuerdo con su valor el flujo sigue por uno de los muchos caminos de accin. El centro del flujo de informacin desde el que emanan los caminos de accin se denomina Centro de Transaccin. La funcin decide a que mdulo mandar la informacin. Hay que tener en cuenta que en el DFD de un gran sistema, pueden estar presentes los dos tipos , de transformacin y de transaccin. Por ejemplo, dentro de un flujo de transaccin, el flujo de la informacin a travs de un camino de accin puede tener un flujo de transformacin. ANLISIS DE TRANSACCIN: Los pasos en el anlisis de transaccin son similares y en algunos casos idnticos a los pasos para el anlisis de transformaciones. La principal diferencia se refiere a la conversin de un DFD en carta de estructura. 1. Revisar el DFD. 2. Refinar el DFD. 3. Identificar tipo de flujo. 4. Identificar el centro de transaccin y las caractersticas del flujo de cada camino de accin.
5.

Transformar el DFD en una estructura de software adecuada al procesamiento de transacciones. (Factorizar Transaccin, primer nivel)

6. Factorizar y refinar la estructura de transacciones y la estructura de cada camino de accin (Factorizar caminos de accin, segundo nivel).
7.

Refinar usando unidades y heursticas de diseo.

CARTA DE ESTRUCTURA: rbol jerrquico.

Nombre del Mdulo

Dato transferido

Relacin de control

Seleccin

Mdulo E/S

Iteracin

50

Diseo Orientado a la Estructura de Datos.

Transforma una representacin de la estructura de datos en una representacin del software. Se aplica con xito a las aplicaciones que tengan una estructura jerrquica bien definida de la informacin. 1.- La Construccin Lgica de Programas (CLP) desarrollada por Warnier, da un mtodo riguroso para el diseo de software. Sobre el esquema de la relacin entre la estructura de datos y la estructura procedimental, Warnier desarrolla un conjunto de tcnicas que realizan una transformacin de la estructura de datos de E/S en una representacin procedimental detallada del software. 2.- El Desarrollo de Sistemas Estructurados de Datos (DSED), tambin llamado metodologa de Warnier Orr, es una extensin de CLP y potencia el anlisis, as como las capacidades de diseo. Estudia el flujo de informacin y caractersticas funcionales, as como la jerarqua de datos. 3.- Las Metodologas de Desarrollo de Sistemas Jackson (DSJ) parten de que la paralelizacin de la estructura de los datos de entrada y salida (informe) que aseguran un diseo de calidad, desarrollando tcnicas pragmticas para transformar los datos en estructuras de programa.. CARACTERSTICAS DE ESTAS ESTRUCTURAS: Cada mtodo orientado a la estructura de datos tiene su propio conjunto de reglas, sin embargo, deben realizarse siempre las siguientes tareas de diseo. 1. Evaluar las caractersticas de la estructura de datos. 2. Representar los datos en trminos de formas elementales tales como secuencia, seleccin y repeticin. 3. Transformar la representacin de la estructura de datos en una jerarqua de control para el software. 4. Refinar la estructura de software usando los criterios definidos como parte del mtodo. 5. Desarrollar finalmente una descripcin procedimental.

Diseo Orientado al Objeto.

El diseo orientado al objeto (DOO) permite al ingeniero de software indicar los objetos que se derivan de cada clase y las interacciones entre ellos. Adems, el DOO debe proporcionar una notacin que refleje las relaciones entre los objetos. El primer intento en describir un mtodo de DOO establece que este debe comenzar con una descripcin en lenguaje natural de la estrategia de solucin, mediante una realizacin en software, de un problema real. A partir de esta descripcin el diseador identifica objetos y operaciones. Otras contribuciones introdujeron una notacin ms amplia para asistir a esa actividad y argumentaron que se trataba realmente de una actividad de anlisis. Los mtodos actuales de DOO combinan elementos de las tres categoras de diseo: diseo de datos, arquitectnico y procedimental. Los mtodos de DOO se caracterizan por los siguientes pasos: 1. Definir el problema. 2. Desarrollar una estrategia informal para la realizacin en software del campo del problema del mundo real. 3. Formalizar una estrategia mediante los siguientes subpasos: a. Identificar objetos y sus atributos. b. Identificar las operaciones que le puedo aplicar a los objetos. c. Establecer interfaces para mostrar interaccin entre objetos y operaciones. d. Describir aspectos del diseo detallado que proporcionen una descripcin de la implementacin de los objetos. 4. Volver a aplicar los pasos 2, 3 y 4 recursivamente. {los pasos 1,2 y 4 se realizan durante el anlisis. Para el diseo se aaden los siguientes pasos}. 5. Refinar el trabajo realizado en el anlisis, buscando subclases, caractersticas de los mensajes y otros detalles de elaboracin. 6. Representar la/s estructura/s de datos asociada/s con los atributos del objeto. 7. Representar los detalles procedimentales asociados con cada operacin.

51

Diseo de Tiempo Real.

Los sistemas de tiempo real generan alguna accin en respuesta a sucesos externos. Para realizar esta funcin, ejecutan una adquisicin y control de datos a alta velocidad bajo varias restricciones de tiempo y fiabilidad. Debido a que estas restricciones son muy rigurosas los sistemas de tiempo real estn frecuentemente dedicados a una aplicacin. CARACTERSTICAS DE LOS SISTEMAS DE TIEMPO REAL: Responden al mundo real. En un tiempo prefijado. Debe ser fiable, reiniciable y reparable en fallas. Anlisis y Diseo. Atributos dinmicos que no pueden separarse de los requisitos funcionales de un sistema de tiempo real. MANEJO DE INTERRUPCIONES: Se salva el estado del programa interrumpido. Se determina la naturaleza de la interrupcin. Se sirve la interrupcin. Se restaura el estado del programa interrumpido. Se vuelve al programa interrumpido. TIEMPO DE RESPUESTA: Es el tiempo en el que un sistema debe detectar un suceso interno o externo y responder con una accin.

MANEJO DE E/S: transferencia de datos y tiempo invertido. Rendimiento dispositivos. Transferencia Tamao de buffers. Bus de datos. ASIGNACIN DE RECURSOS Y MANEJO DE PRIORIDADES. SINCRONIZACIN DE TAREAS Y COMUNICACIN ENTRE TAREAS: un sistema multitarea debe suministrar un mecanismo por el que las tareas se pasan informacin unas a otras, as como para asegurar su sincronizacin. Se utilizan para esto: semforos, reas compartidas, mensajes, tcnicas cclicas.

52

Mtodo Ward. El mtodo de diseo Ward comienza con la aplicacin de los principios fundamentales de anlisis de software aplicado en el contexto de la notacin de flujo de datos. Se crean los DFDs, se define el correspondiente diccionario de datos y se establecen las interfaces entre las principales funciones del sistema. Anlisis y diseo estructurado + conexin con el mundo real + mecanismo para representar comunicacin y sincronizacin de tareas + representacin de la dependencia de estados. Para hacer la conexin con el mundo real, al DFD agregamos: DESCRIPCIN FLUJO DE CONTROL: Elemento de control o suceso: interrupciones. Toma un valor lgico o discreto.
PROCESOS DE CONTROL:

REPRESENTACIN seales o

burbujas que coordinan o sincronizan las actividades de otras burbujas. Acepta control como entrada y produce control como salida. ALMACN DE CONTROL: depsitos de elementos de control, que se guardan para ser utilizados por uno o ms procesos FLUJO DE DATOS CUASI CONTINUOS: Un objeto de datos que entra o sale de un proceso de una forma continua. PROCESO MLTIPLE: Mltiples ocurrencias equivalentes del mismo proceso.

53

Documentacin de Diseo.
En primer lugar se describe el Alcance del Diseo; la mayora de la informacin se obtiene de la Especificacin del Sistema y del modelo de anlisis (Especificacin de los Requisitos de Software). En segundo lugar se describe el Diseo Arquitectnico del Sistema, que indica como se ha obtenido la Arquitectura del Programa del Modelo de Anlisis. Se utilizan grficos para la representacin de la Estructura del Programa, como los Diagramas de Flujo de Datos, Cartas de Estructura, que junto con los conceptos de programacin estructurada, permite al diseador representar los detalles procedimentales, facilitando su traduccin al cdigo. En tercer lugar se describen detalladamente los Mdulos que componen el sistema, indicando de cada uno de ellos una descripcin del proceso, descripcin de la interfaz, lenguaje de diseo, mdulos que lo componen, estructuras de datos internas y por ultimo comentarios, restricciones y limitaciones. Luego se especifica una seccin de Diseo de Datos, que describe la estructura de los datos internos y externos. Y por ltimo, si es necesario se describe el Diseo de Interfaz, con una Especificacin de la Interfaz Hombre-Mquina y las Normas de Diseo utilizadas.

Prototipo de Documento de Diseo 1. AMBITO Objetivos Hardware, Software e Interfaces Humanas Funciones de Software Bases de Datos Definidas Externamente Restricciones y Limitaciones de Diseo 2. DOCUMENTO DE REFERENCIA Documento de Software Existente Documento del Sistema Referencia Tcnica 3. DESCRIPCIN DEL DISEO Descripcin de Datos (Flujo y Estructura) Estructura de Programa Derivado Interfaces Dentro de la Estructura 4. MDULOS Texto Explicativo Descripcin de la Interfaz Descripcin en Lenguaje de Diseo Mdulos Usados Organizacin de los Datos 5. ESTRUCTURA DE ARCHIVOS Y DATOS GLOBALES Estructura de Archivos Externos (Estructura Lgica, Descripcin Lgica de Registros y Mtodos de Acceso) Datos Globales Referencias Cruzadas Entre Archivos y Datos 6. PROVISIONES DE PRUEBAS Directrices Estrategias de Integracin 7. EMPAQUETAMIENTO Solapamiento del Programa Transferencia 8. APENDICE

54

UNIDAD N 6: Aspectos de la Implementacin.

Codificacin.
Transforma el diseo en un lenguaje de programacin. El proceso de transformacin contina cuando el compilador acepta el cdigo fuente como entrada y produce como salida un cdigo objeto dependiente de la mquina que luego es linkeditado para ser traducido a cdigo mquina. Las caractersticas del lenguaje de programacin pueden influir en nuestra forma de pensar, tienen un impacto directo sobre la calidad y la eficiencia de la traduccin.

Caracterstica de los lenguajes.

VISIN PSICOLGICA Varias caractersticas psicolgicas aparecen como resultado del diseo de un lenguaje de programacin. Aunque esas caractersticas no se pueden medir de forma cuantitativa se reconoce su manifestacin en todos los lenguajes de programacin. Las caractersticas psicolgicas de un lenguaje tienen una gran importancia asociada a nuestra capacidad de aprenderlo y de aplicarlo. Uniformidad. Indica el grado en que un lenguaje usa una notacin consistente, aplica restricciones aparentemente arbitrarias o excepciones a reglas sintcticas. Por ejemplo: Fortran usa parntesis para encerrar ndices de arrays, listas de parmetros en la llamada a un procedimiento y en las expresiones asimtricas para modificar la precedencia. A (i) Esta notacin multiuso puede llevar a varios subrutina Pepe (B) errores sutiles. (2 + A) * D Ambigedad. Un compilador siempre interpreta una sentencia de una nica manera, pero el lector humano puede interpretar de distintas formas. A = A / B * C un lector puede interpretarlo X = (A / B) * C y otro X= A / (B * C). Compacto. Lo compacto que sea un lenguaje es indicativo de la cantidad de informacin respecto del cdigo que se debe retener en la memoria humana. Un lenguaje compacto tiene muchos smbolos, abreviaturas, operadores, etc. Cuantas ms cosas de estas tiene ms compacto es. Lo ptimo es que tenga pocas cosas y con ellas se pude hacer mucho. APL, por ejemplo, es un lenguaje extremadamente compacto, se pueden escribir procedimientos asimtricos y lgicos con relativamente poco cdigo, desgraciadamente esto hace que el lenguaje sea difcil de leer y comprender. Localizacin. Relacionada con la memoria de los humanos. La localizacin se potencia cuando el lenguaje permite identificar fcilmente sentencias en bloques, cuando las construcciones estructuradas se pueden implementar directamente, cuando el diseo y el cdigo resultante son altamente modulares y cohesivos. Linealidad. Relacionada con la memoria secuencial que los humanos tenemos (por lo cual podemos reconocer el siguiente elemento en una secuencia). Los grandes saltos, los grandes bucles violan el procesamiento secuencial, nuevamente las construcciones estructuradas ayudan a la linealidad. Tradicin. Qu exista en los lenguajes es una caracterstica muy importante que el programador debe tener en cuenta para elegir en que programar. La tradicin tambin afecta al grado de innovacin durante el diseo de un lenguaje.

55

VISIN DE LA INGENIERA DE SOFTWARE Se centra en la necesidad que puede tener un proyecto especfico de desarrollo de software. Facilidad de traduccin del diseo detallado al cdigo fuente. En teora la generacin del cdigo fuente a partir del diseo detallado debera ser algo directo. El grado de facilidad indica cmo se aproxima un lenguaje a la representacin del diseo. Eficiencia del compilador. Aunque los rpidos avances en velocidad de procesamiento y densidad de memoria han comenzado a disminuir la necesidad de un cdigo super eficiente muchas aplicaciones todava requieren programas rpidos y ajustados en memoria. Portabilidad del cdigo fuente. Capacidad de que el cdigo fuente sea transportado de un procesador a otro con ninguna o pocas modificaciones. Tambin la capacidad de permanecer inalterado cuando cambia su entorno de funcionamiento. Disponibilidad de herramientas de desarrollo. Que pueden acortar el tiempo requerido para la generacin del cdigo fuente y mejorar la calidad del cdigo. Tratar de tener la mayor cantidad de herramientas para escribir el cdigo. Facilidad de mantenimiento. Es crticamente importante para cualquier esfuerzo no trivial de desarrollo de software. El cdigo debe estar suficientemente documentado para que se pueda entender, ya que a partir de ah comienza su mantenimiento.

Criterios para la eleccin de un lenguaje.

La eleccin de un lenguaje para un proyecto especfico debe tener en cuenta tanto las caractersticas de ingeniera como las psicolgicas. Entre los criterios que se aplican estn: rea de aplicacin. Es el criterio que ms se aplica, a menudo C es un lenguaje elegido para el desarrollo de software de sistemas, Ada y C para tiempo real, Cobol para desarrollos comerciales. Si queremos trabajar con objetos, Smalltalk sera una buena eleccin, Fortran para campos especficos y de ingeniera, etc. Complejidad algortmica. Entorno en que se ejecutar. Consideraciones de rendimiento. Complejidad de las estructuras de datos. Staff de desarrollo conocimiento del lenguaje. Disponibilidad de un buen compilador.

56

Caractersticas tcnicas de los lenguajes.

Los fundamentos de los lenguajes de programacin se presentarn dentro del contexto de tres grandes reas y se puede juzgar la calidad global evaluando la potencia o debilidad de cada rea. TIPIFICACIN DE DATOS Al hablar de tipos de datos nos referimos a una clase de objetos de datos junto con un conjunto de operaciones para crearlos y manipularlos. Las operaciones que se pueden realizar sobre un tipo de datos particular se controlan por la comprobacin de tipos incluida en el compilador del lenguaje. Se definen 5 niveles de comprobacin: NIVEL 0: Sin tipos. No incluye medios explcitos para la tipificacin de datos y por lo tanto no hacen ninguna comprobacin (Cobol). NIVEL 1: Conversin automtica de tipos. Es un mecanismo de comprobacin de tipos que permite una conversin de operadores de tipos incompatibles permitiendo una mezcla de tipos, por ejemplo PL/1 asigna 0 a FALSE y 1 a TRUE de esta manera valores booleanos pueden intervenir en una expresin aritmtica. NIVEL 2: Modo mixto. Parecido a la conversin automtica pero aqu se pueden mezclar tipos de una determinada categora, por ejemplo reales y enteros (Fortran). NIVEL 3: Verificacin ligera de tipos. Tiene todas las caractersticas de la fuerte comprobacin de tipos pero se implementa de forma que existan uno o ms escapes (Simula). NIVEL 4: Fuerte comprobacin de tipos. Solo permite llevar a cabo operaciones entre objetos de datos que son del mismo tipo previamente especificado (Ada). MECANISMOS DE SUBPROGRAMA Un subprograma es un componente de un programa compilado por separado que contiene datos y estructuras de control. Dependiendo del lenguaje un subprograma puede llamarse subrutina, procedimiento, funcin u otro nombre especializado. Un subprograma tiene un conjunto de caractersticas genricas: Una seccin de la especificacin que incluye su nombre y la descripcin de la interfaz. Una seccin de implementacin que incluye datos y las estructuras de control. Un mecanismo de activacin que permite activarlo desde el programa principal. ESTRUCTURAS DE CONTROL los lenguajes modernos permiten al programador usar las construcciones lgicas de programacin estructurada: secuencia, repeticin y condicin. Adems puede haber otras estructuras de control: La recursividad: crea una segunda activacin del subprograma durante la primera. La concurrencia: da soporte a la creacin de mltiples tareas, a la sincronizacin de tareas y a la comunicacin de tareas. El manejo de excepciones: atrapa los errores del sistema o los definidos por el usuario pasando el control a un manipulador de excepciones.

57

Clases de lenguajes.
PRIMERA GENERACIN: el cdigo de mquina y su equivalente ms humanamente legible, el lenguaje ensamblador, representan la primer generacin. Estos lenguajes dependientes de la mquina representan el menor grado de abstraccin. SEGUNDA GENERACIN: fue desarrollada afines de los 50 y principios de los 60 y han servido como base para los lenguajes modernos (tercera generacin). Ejemplos de ellos son: Fortran, Cobol, Basic y Algol. TERCERA GENERACIN: tambin llamados de programacin moderna o estructurada, estn caracterizados por sus potentes posibilidades procedimentales y de estructuracin de datos, pueden dividirse en dos categoras: De propsito general: PL/1, Pascal, Modula2, C y Ada. Lenguajes especializados: Lisp, Prolog (sistemas expertos), APL (para manejo de vectores y matrices), Forth, Smalltalk. CUARTA GENERACIN: combinan caractersticas procedurales y no procedurales, los podemos clasificar en: Lenguajes de peticin: asociados al uso de Bases de Datos, permiten al usuario manipular de forma sofisticada la informacin contenida en la base de datos previamente creada. Generadores de programas: son ms sofisticados que los anteriores, permiten al usuario crear programas en lenguajes de tercera generacin usando notablemente menos sentencias, son de muy alto nivel, hacen un fuerte uso de la abstraccin de datos y de procedimientos. La mayora es para desarrollos comerciales en Cobol. Otros L4G: Lenguajes de soporte a la toma de decisiones: permiten que los no programadores lleven a cabo una gran variedad de anlisis (hojas de clculo). Lenguajes de prototipos: asisten en la creacin de prototipos. Lenguajes de especificacin formal: se pueden considerar L4G si producen cdigo ejecutable.

58

Estilo de codificacin.
Los elementos de estilo incluyen la documentacin interna (nivel de cdigo fuente), los mtodos de declaracin de datos, la aproximacin a la construccin de sentencias y las tcnicas de E/S. DOCUMENTACIN DEL CDIGO La eleccin de los nombres para los identificadores (variables y etiquetas) es importante, estos deben ser mnemotcnicos. Un lenguaje que limita los nombres de los identificadores a unos pocos caracteres implcitamente limita la comprensin. COMENTARIOS: la posibilidad de expresar comentarios en lenguaje natural como parte del listado del cdigo fuente es algo que aparece en todos los lenguajes de propsito general. Hay dos categoras de comentarios: de prlogo(deben aparecer al principio de cada mdulo) y descriptivos(se incluyen por el cuerpo del cdigo y se usan para describir las funciones de procesamiento). ORGANIZACIN VISUAL DEL PROGRAMA: la identacin del cdigo fuente realza las construcciones lgicas y los bloques ayudando a la legibilidad. DECLARACIN DE DATOS Se pueden establecer varios mtodos para hacer ms compresibles los datos y ms fciles de manejar. El orden de las declaraciones de datos se debe estandarizar incluso aunque el lenguaje de programacin no tenga requerimientos especficos. Por ejemplo: conviene declarar mltiples variables en una sola sentencia, merece la pena ponerlas en orden alfabtico, etc. CONSTRUCCIN DE SENTENCIAS Cada sentencia debe ser simple y directa, muchos lenguajes permiten colocar varias en un mismo rengln, el ahorro de espacio que esto implica est difcilmente justificado por la pobre legibilidad del resultado. Las sentencias del cdigo fuente se pueden simplificar a: evitar el uso de complicadas comparaciones condicionales, eliminar las comparaciones con condiciones negativas, evitar grandes anidamientos y usar parntesis para expresiones lgicas o aritmtica. TCNICAS DE E/S El estilo variar de acuerdo al grado de interaccin humana. E/S ORIENTADA A LOTES (poca interaccin humana)sern deseables: Organizacin lgica de la entrada. Comprobacin de errores de E/S significativos. Buena recuperacin de errores de E/S. Formatos de informes de salida relacionados. E/S INTERACTIVA Entrada simple y dirigida. Extensa comprobacin y recuperacin de errores. Salida humanizada. Consistencia de formato de E/S. PRINCIPIOS GENERALES PARA LA E/S Hacer invisibles a los usuarios los aspectos internos de la computadora. Evitar que el usuario pueda hacer terminar anormalmente el programa. Advertir al usuario cuando una peticin puede traer consecuencias. Proporcionar asistencia interactiva. Adecuar los requerimientos de entrada a las posibilidades del usuario. Adecuar los mensajes de salida a las velocidades de los dispositivos de salida. Distinguir entre distintas clases de usuarios. Mantener tiempos de respuesta consistentes. Minimizar el trabajo extra del usuario en los casos de errores.

59

Eficiencia.
En primer lugar la eficiencia es un requerimiento de rendimiento y por lo tanto se debe establecer durante el anlisis de requerimientos del software. El software debe ser tan eficiente como se requiera y no como sea humanamente posible. En segundo lugar la eficiencia se incrementa con el buen diseo y en tercer lugar la eficiencia del cdigo y la simplicidad del cdigo van de la mano. En general no hay que sacrificar la claridad, la legibilidad o la correccin en aras de una mejora de eficiencia que no sea esencial. Eficiencia en el cdigo. La eficiencia del cdigo fuente est ligada a la eficiencia de los algoritmos definidos durante el diseo detallado. Sin embargo el estilo de codificacin puede afectar la velocidad de ejecucin y los requerimientos de memoria. En el paso del diseo detallado al cdigo debemos tener en cuenta este conjunto de directrices: Simplificar expresiones aritmticas y lgicas. Evaluar los bucles anidados intentando sacar fuera de ellos algunas sentencias. Evitar arreglos multidimensionales. Evitar el uso de punteros y listas complejas. No mezclar tipos de datos. Usar cuando sea posible aritmtica entera y expresiones booleanas. Eficiencia en memoria. Las restricciones de memoria en el mundo de las grandes computadoras son generalmente algo del pasado, la gestin de memoria virtual proporciona a las aplicaciones de software un espacio de direcciones lgicas enorme. Sin embargo, en las PC (microprocesadores) las restricciones de memoria son algo muy real. Si los requerimientos del sistema demandan minimizar la memoria se deben evaluar los compiladores de lenguajes de alto nivel y como ltimo recurso usar Assembler. Eficiencia de E/S. Debemos distinguir entre dos tipos de E/S: DIRIGIDA A LA PERSONA: se considera eficiente cuando la informacin se puede suministrar o comprender con el mnimo esfuerzo intelectual. DIRIGIDA A OTRO DISPOSITIVO: la eficiencia es interna, muy complicada, fuera de los alcances de la materia. Directrices para mejorar la E/S: Minimizar el nmero de peticiones. E/S con buffers para reducir el embotellamiento en la comunicacin. En memoria secundaria se debe seleccionar el mtodo de acceso ms simple dentro de lo aceptable y debe hacerse por bloques. Importante: super eficiencia en la E/S no vale la pena si no se puede comprender.

60

UNIDAD N 7: Verificacin y Validacin.

Verificacin: garanta que el sistema es completo. Validacin: es la calidad del producto en su medio. La verificacin se refiere a un conjunto de actividades que aseguran que el software implementa correctamente una funcin especfica. Estamos construyendo el producto correctamente?. La validacin se refiere a un conjunto diferente de actividades que aseguran que el software construido se ajusta a los requerimientos del cliente. Estamos construyendo el producto correcto?. La verificacin y la validacin comprenden un amplio rango de actividades de SQA que incluyen revisiones tcnicas formales, auditorias de configuracin y calidad, supervisin del rendimiento, simulacin, estudio de la viabilidad, revisin de la documentacin, revisin de la base de datos, anlisis de algoritmos, prueba de desarrollo, prueba de cualificacin y prueba de instalacin.

Objetivos de las Pruebas

Luego de la codificacin, se realiza la prueba. Es un proceso de ejecucin de un programa con la intencin de descubrir un error, y tiene xito si se encuentra un error que no ha sido detectado hasta entonces. El objetivo es disear pruebas que sistemticamente saquen a la luz diferentes clases de errores, en la menor cantidad de tiempo y esfuerzo. Si la prueba se lleva a cabo con xito (de acuerdo al objetivo anteriormente establecido), descubrir errores en el software. Principios de la Prueba Los principios bsicos que guan las pruebas de software son: A todas las pruebas se les debera poder hacer un seguimiento hasta los requisitos del cliente. Los defectos ms graves desde el punto de vista del cliente son aquellos que impiden al programa cumplir sus requisitos. Las pruebas deberan planificarse mucho antes de que empiecen. La definicin detallada de los casos de prueba puede empezar tan pronto como el modelo de diseo se ha consolidado. El Principio de Pareto es aplicable a la prueba de software. Este principio implica que el 80% de todos los errores descubiertos durante las pruebas surgen al hacer un seguimiento de slo el 20% de todos los mdulos del programa. La complicacin est en aislar estos mdulos sospechosos y probarlos concienzudamente. No son posibles las pruebas exhaustivas, pues es imposible ejecutar todas las combinaciones de caminos existentes durante la prueba. Para ser ms efectivas, deberan ser conducidas por un equipo independiente.

Diseo de Casos de Prueba

Se deben disear pruebas que tengan la mayor probabilidad de encontrar el mayor nmero de errores, con la mnima cantidad de esfuerzo y tiempo posible. Existen varios mtodos de diseo de prueba, que proporcionan un mecanismo de ayuda para asegurar la mayor completitud de las pruebas, y mayor probabilidad de encontrar errores. Cualquier producto de ingeniera puede ser probado de una de las dos formas: 1) Las pruebas de caja negra se pueden realizar slo conociendo la funcin especfica para el que fue diseado el producto. Se llevan a cabo para demostrar que cada funcin es completamente operativa. Estas pruebas se llevan a cabo sobre la interfaz del software. Lo que pretenden demostrar es que la entrada se acepta de forma adecuada y que se produce la salida correcta. No tiene mucho en cuenta la estructura lgica del software. 2) La prueba de caja blanca se utiliza cuando se conoce el funcionamiento del producto, se prueba que todas las piezas encajan, es decir, que las operaciones internas se ajustan a las especificaciones y que todos los componentes internos se han comprobado en forma adecuada. Se comprueban los caminos lgicos del software, proponiendo casos de prueba que ejerciten conjuntos especficos de condiciones y/o bucles. A primera vista parecera ser que una prueba de caja blanca muy profunda llevara a tener programas 100% correctos, sin embargo no es posible ya que la prueba exhaustiva es materialmente imposible por la enorme cantidad de caminos lgicos posibles. Sin embargo, no debe ser desechada como impracticable. Se puede elegir y ejecutar una serie de importantes caminos lgicos para los casos de prueba. Se pueden combinar los atributos de la prueba de caja blanca con los de la prueba de caja negra para llegar a una aproximacin que valide la interfaz y asegure selectivamente que el funcionamiento interno del software es correcto.

61

Tcnicas de Prueba. Prueba de Caja Blanca.

Mediante este mtodo de prueba se garantiza que: Se ejecutan todos los caminos independientes de cada mdulo. Se ejecutan todas las condiciones lgicas en true y false. Se ejecutan todos los bucles en sus lmites. Se ejecutan todas las estructuras internas de datos para asegurar su validez. Por que se realizan estas pruebas y no nos dedicamos directamente a ver si los requerimientos fueron alcanzados?(usando pruebas de caja negra). La respuesta est en la naturaleza de los defectos del software: Los casos especiales son los ms factibles de errores. A menudo creemos que un camino lgico tiene pocas posibilidades de ejecutarse y resulta que se ejecuta regularmente (el flujo de control intuitivo muchas veces es distinto del real). Los errores tipogrficos son aleatorios. Prueba del camino bsico. Los casos de prueba derivados del conjunto bsico garantizan que durante la prueba se ejecutan por lo menos una vez cada sentencia del programa. Se utilizan diagramas de flujo. Construcciones estructuradas en forma de diagrama de flujo: Sentencia If Until While Case

El grafo de flujo representa el flujo de control lgico. Cada nodo representa una o ms sentencias procedimentales. Un solo nodo puede corresponder a una secuencia de cuadros de proceso y a un rombo de decisin. Una arista debe terminar en un nodo, cuando contabilizamos las regiones se cuenta tambin la exterior. Cuando en el diseo procedural se encuentran condiciones compuestas (expresiones booleanas con los operadores and, or, etc.) el grafo se complica un poco, por ejemplo: If a or b then x else y endif a b y Un camino independiente es cualquier camino que introduce por lo menos un nuevo conjunto de sentencias de procesamiento o una condicin. En trminos del diagrama un camino independiente se debe mover por lo menos por una arista que no haya sido recorrida anteriormente. El conjunto de caminos bsicos no es nico, para saber el nmero de caminos independientes que hay que ejecutar para asegurar que todas las sentencias del programa se ejecuten por lo menos una vez, tenemos que calcular la complejidad ciclomtica, que se calcula de la siguiente forma: 1. Nmero de regiones. 2. Nmero de aristas nmero de nodos + 2. 3. Nmero de nodos predicados + 1. PASOS A SEGUIR 1. Usar el diseo o el cdigo para hacer el grafo de flujo. 2. Determinar la complejidad ciclomtica. 3. Determinar un conjunto bsico de caminos linealmente independientes. 4. Preparar los casos de prueba que fuercen la ejecucin de cada camino. x x

62

Matrices de grafos. Para desarrollar una herramienta de software que ayude en la prueba del camino bsico puede ser bastante til una estructura de datos denominada matriz de grafos. Es otra herramienta de software para esta prueba. Es una matriz cuadrada cuyas filas y columnas representan los nodos del grafo y cada entrada de la matriz representa la conexin entre los nodos. Si hay conexin ponemos en 1, sino un 0. La suma de las filas nos da el peso de enlace. Si el peso de enlace es mayor a 1 representa un nodo predicado. Ejemplo: 1 2 3 4 5 1 2 3 4 5 conexiones 1 1 a 1 1 1 a 2 2 0 3 3 d b 3 1 1 2 e 4 c f 4 1 1 2 5 R2 b 5 g e 5 1 1 2 f 4 R1 d Matriz de grafo Matriz de conexiones g R3 c 2 nodos predicados = 3 complejidad ciclomtica = 4 R1, R2, R3 y R4 = regiones

Prueba de Bucles. Se centra en la validez de la construccin de bucles se pueden definir cuatro clases diferentes de bucles. Simples Anidados Concatenados No estructurados

Adems del anlisis del camino bsico que mide todos los caminos de un bucle, se recomienda una lista de pruebas adicionales para cada clase de bucle. SIMPLE: sea n el nmero mximo de pasos permitidos por el bucle, se deben hacer estas pruebas: Saltar totalmente el bucle. Pasar una sola vez por el bucle. Pasar dos veces por el bucle. Hacer m pasos por el bucle donde m < n. Hacer n-1, n y n+1pasos por el bucle. ANIDADOS: Llevar a cabo las pruebas de bucle simples con el bucle ms interior manteniendo los exteriores con los valores mnimos en sus parmetros de iteracin. Progresar hacia fuera, llevando a cabo las pruebas para el siguiente bucle, pero manteniendo los ms externos en los valores mnimos y los dems bucles anidados (internos) con valores tpicos. CONCATENADOS: cuando los bucles son independientes se pueden probar independientemente como los simples, pero cuando existe dependencia entre ellos (por ejemplo si se usa un contador del bucle 1 como valor inicial del bucle 2) se recomienda hacer el tratamiento como los anidados. NO ESTRUCTURADOS: se deben redisear para ajustarlo a los requisitos de la programacin estructurada.

63

Pruebas de Caja Negra.

Los mtodos de prueba de caja negra se centran en los requerimientos funcionales del software. O sea, la prueba de caja negra permite al ingeniero de software derivar conjuntos de condiciones de entrada que ejerciten completamente todos los requerimientos funcionales de un programa. Intenta encontrar errores de la siguiente categora: 1) Funciones incorrectas o ausentes. 2) Errores de interfaz. 3) Errores en estructuras de datos o accesos a bases de datos externas. 4) Errores de rendimiento. 5) Errores de inicializacin y terminacin. Particin equivalente. Es un mtodo de caja negra que consiste en particionar el dominio de la entrada de un programa en clases de datos que puedan derivar clases de prueba. Un caso de prueba descubre en forma inmediata una clase de error. Se basa en una clase de equivalencia de una condicin de entrada. Una clase de equivalencia representa un conjunto de entradas vlidas o invlidas para condiciones de entrada. Los casos pueden ser seleccionados de forma que se ejecuten el mayor nmero de atributos de cada clase a la vez. Anlisis de valores lmites. Los errores tienden a darse ms en los valores lmites del campo de entrada que en el centro. El anlisis de valores lmites nos lleva a una eleccin de casos de prueba que ejecuten los valores lmites. Es una tcnica que complementa a la particin equivalente. En lugar de seleccionar cualquier elemento de una clase de equivalencia, este mtodo lleva a la eleccin de casos de prueba en los bordes de las clases. En lugar de centrarse solamente en las condiciones de entrada, este mtodo deriva casos de prueba tambin para el campo de salida. Directrices: 1. Entrada rango [a, b] casos de prueba a, b y por debajo y por encima de a y b. 2. Valores casos de prueba por el valor mximo, mnimo y por debajo y por encima. 3. Aplicar 1 y 2 a la salida. 4. Si la estructura de datos tiene lmites preestablecidos (ej.: array 100 entradas) hay que asegurarse una prueba que analice su lmite. Tcnica de grafo causa y efecto. Son una tcnica de diseo de casos de prueba que proporcionan una concisa representacin de las condiciones lgicas y sus correspondientes acciones. Pasos: 1. Listas para cada mdulo de causa (condiciones de entrada) y efecto (acciones) asegurando un identificador a cada uno de ellos. 2. Se desarrolla el grafo de causa y efecto. 3. Se convierte el grafo a tablas de decisin. 4. Se convierten las reglas de la tabla de decisin a pruebas. Prueba de validacin de datos. Hay casos en que varios equipos de ingeniera desarrollan separados versiones independientes de una aplicacin. En estas situaciones se debe probar cada versin con los mismos datos de prueba, para asegurar que todos proporcionan una salida idntica. Luego, se ejecutan todas las versiones en paralelo y se hace una comparacin en tiempo real de los resultados, para garantizar la consistencia. Si las salidas de todas las implementaciones son idnticas entonces todas las implementaciones son correctas. Si hay alguna diferente se investiga para descubrir el error.

64

Estrategias de Prueba.
La prueba es realmente una serie de cuatro pasos que se llevan a cabo secuencialmente. Inicialmente la prueba se centra en cada mdulo individual asegurando que funciona como una unidad, de ah el nombre de prueba de unidad (orientada a la caja blanca). A continuacin se debe ensamblar o integrar los mdulos para formar el paquete de software completo, la prueba de integracin se dirige a todos los aspectos asociados con el doble problema de verificar y de construccin del programa. Finalmente se deben comprobar los criterios de validacin (establecidos durante la fase de definicin), en la prueba de validacin se usa exclusivamente pruebas de caja negra. El software una vez validado, se debe combinar con otros elementos del sistema (hardware gente, bases de datos), la prueba el sistema verifica que cada elemento encaja de forma adecuada. Cualquier estrategia de prueba debe incorporar la planificacin de la prueba, el diseo de casos de prueba, la ejecucin de pruebas y la recoleccin y evaluacin de los datos resultantes. Se han propuesto varias estrategias, todas ellas proporcionan al ingeniero de software una plantilla para la prueba y todas tienen las siguientes caractersticas generales: Comienza en el mdulo y trabaja hacia fuera, hacia la integracin del sistema completo. La lleva acabo el que desarrolla el software y (para grandes proyectos) un grupo de prueba independiente. La prueba y la depuracin son actividades diferentes, pero la depuracin puede entrar en cualquier estrategia de prueba.

Prueba de Unidad.
La prueba de unidad centra el proceso de verificacin del funcionamiento correcto en la menor unidad de diseo del software, el mdulo. Usando la descripcin del diseo detallado la prueba de unidad siempre est orientada a la caja blanca. Se puede realizar en paralelo para mltiples mdulos. El diseo de casos de prueba comienza una vez que se ha desarrollado, revisado y verificado en su sintaxis el cdigo fuente. Debido a que el mdulo no es un programa independiente se debe desarrollar para cada prueba de unidad un software que conduzca y/o resguarde.
Casos de prueba Conductor Mdulo a ser probado Resultados

Resguardo 1

Resguardo 2

Resguardo n

En la mayora de los casos un conductor es un programa principal que acepta los datos de los casos de prueba pasndolos al mdulo que debe ser probado e imprime los resultados relevantes. Los resguardos sirven para reemplazar a los mdulos subordinados al que estamos probando (es decir llamado por l). Los resguardos y conductores son software adicional. Si se mantiene simple el trabajo extra ser pequeo. Desgraciadamente muchos mdulos requieren un gran soporte de este software adicional. La prueba de unidad se simplifica cuando hay un alto grado de cohesin, si un mdulo se dirige solo a una funcin se reduce el nmero de casos de prueba.

65

Prueba de Integracin.
La prueba de integracin es una tcnica sistemtica para construir la estructura del programa mientras que al mismo tiempo se llevan a cabo pruebas para detectar errores asociados con la interaccin. A menudo hay una tendencia a la integracin no incremental, a construir el programa de un paso, todos los mdulos se combinan por anticipado y se prueba todo el programa en conjunto, esto normalmente lleva al caos. La integracin incremental es la anttesis de la anterior. El programa se va construyendo y probando en pequeos segmentos. La integracin incremental puede ser ascendente, descendente o una mezcla de ambas. INTEGRACIN DESCENDENTE Es una aproximacin incremental a la construccin de la estructura de programas. Se integran los mdulos comenzando con el mdulo de control principal y se van incorporando a la estructura los subordinados de alguna de estas dos formas: primero en profundidad o primero en anchura.
M1

M2

M3

R4

M5

M6

R7

Este esquema muestra una integracin descendiente primero en profundidad. Ahora le toca incorporar el mdulo 7, quien al integrarse puede necesitar de otros resguardos.

M8

El proceso de integracin lleva a cabo una serie de cinco pasos: 1. Se usa el mdulo de control principal como conductor de la prueba, disponiendo resguardos para todos los directamente subordinados a l. 2. Dependiendo de la aproximacin de integracin elegida (profundidad o anchura) se van sustituyndolos resguardos subordinados uno a uno por los mdulos reales. 3. Se llevan a cabo pruebas cada vez que se integra un mdulo. 4. Al terminar estas pruebas, se reemplaza otro resguardo con el mdulo real. 5. Se hace la prueba de regresin (o sea, todas o algunas de las pruebas anteriores) para asegurarnos de no haber introducido nuevos errores. El proceso contina desde el paso 2 hasta que se ha construido el programa. La estrategia de integracin descendente verifica los puntos de decisin o de control principales ms pronto en el proceso de prueba ( en una estructura de programa bien diseada la toma de decisiones est en los niveles superiores). Si se selecciona la integracin primero en profundidad, se puede ir implementando y demostrando las funciones completas del software, ya que vamos agarrando cada rama (subfuncin) y la vamos desarrollando completamente. La demostracin anticipada de las posibilidades funcionales es un generador de confianza tanto para el encargado del desarrollo como para el cliente. INTEGRACIN ASCENDENTE Empieza la construccin y la prueba con los mdulos atmicos (o sea con los mdulos de los niveles ms bajos de la estructura). Dado que los mdulos se integran de abajo hacia arriba los mdulos subordinados ya estn integrados por lo tanto no se necesitan resguardos. La integracin ascendente se puede implementar siguiendo los pasos: 1. Se combinan los mdulos de bajo nivel en grupos que realicen una subfuncin especfica del software. 2. Se describe u conductor para coordinar la entrada y la salida de los casos de prueba. 3. Se prueba el grupo. 4. Se eliminan los conductores y se combinan los grupos movindose hacia arriba por la estructura del programa.

66

COMENTARIOS SOBRE LA PRUEBA DE INTEGRACIN La principal desventaja de la aproximacin descendente es la necesidad de resguardos y las dificultades de prueba que pueden estar asociadas con ello. Los problemas asociados con los resguardos pueden quedar desplazados por la ventaja de poder probar de antemano las principales funciones de control. La principal desventaja de la aproximacin ascendente es que el programa como entidad no existe hasta que se ha aadido el ltimo mdulo. Este inconveniente se soslaya con la mayor facilidad de diseo de casos de prueba y con la falta de resguardos. En general el mejor compromiso puede ser una aproximacin combinada que use la descendente para los niveles superiores de la estructura del programa junto con la ascendente para los niveles subordinados. A medida que progrese la prueba de integracin, el encargado de la prueba debe identificar los mdulos crticos. Un mdulo crtico es aquel que tiene alguna de estas caractersticas: 1. Est dirigido a varios requerimientos. 2. Tiene un mayor nivel de control (alto en la carta de estructura). 3. Es complejo o propenso a errores. 4. Tiene requerimientos de rendimiento muy definidos. Los mdulos crticos deben ser probados lo antes posible adems las pruebas de regresin deben enfocarse sobre estos mdulos. DOCUMENTO DE ESPECIFICACIN DE LA PRUEBA DE INTEGRACIN 1. Alcance: resume las caractersticas que van a ser probadas. 2. Plan: describe la estrategia general para la integracin. a. Fases de prueba. b. Esquema. c. Software adicional. d. Entorno y recursos. 3. Procedimiento: se describe en forma detallada el procedimiento de prueba requerido para llevar a cabo el plan descrito anteriormente. a. Descripcin fase n: 1) Orden de integracin. 2) Propsito y mdulos a ser probados. 3) Herramientas o tcnicas especiales. 4) Descripcin de software adicional. 5) Datos de los casos de prueba. b. Resultados esperados. 4. Resultados Obtenidos. 5. Referencias. 6. Apndices.

67

Prueba de Validacin.
Tras la culminacin de la prueba de integracin, el software est completamente ensamblado como un paquete. La validacin se logra cuando el software funcione de acuerdo con las expectativas razonables del cliente. Las expectativas razonables estn definidas en la Especificacin de requerimientos del software. CRITERIOS PARA LA PRUEBA DE VALIDACIN: La validacin se consigue mediante una serie de pruebas de caja negra que demuestran la conformidad con los requerimientos. Se intenta asegurar que: Se satisfacen todos los requerimientos funcionales. Se alcanzan todos los requerimientos de rendimiento. La documentacin es correcta e inteligible. Se alcanzan otros requerimientos (portabilidad, compatibilidad, recuperacin de errores, facilidad de mantenimiento). Como resultado de la prueba de validacin puede descubrirse que existe una desviacin de las especificaciones y se crea una lista de deficiencias. Raramente estas desviaciones se pueden corregir antes de terminar el plan, a menudo es necesario negociar con el cliente un mtodo para resolver la deficiencia. PRUEBAS ALFA Y BETA: La mayora de los desarrolladores de software llevan a cabo un proceso denominado prueba alfa y beta para descubrir errores que slo el usuario final puede descubrir (se debe a que nosotros no podemos predecir cmo el cliente usar realmente el sistema). La prueba alfa es conducida por el cliente en el lugar de desarrollo. Se usa el software de forma natural, con el encargado del desarrollo supervisando al usuario y registrando errores y problemas de uso. Las pruebas alfa se llevan a cabo en un entorno controlado. La prueba beta se lleva a cabo en uno o ms lugares de clientes por los usuarios finales del software. A diferencia de la prueba alfa, el encargado del desarrollo no est presente. El cliente registra todos los problemas (reales o imaginarios) que encuentra durante la prueba beta e informa a intervalos regulares al equipo de desarrollo.

Prueba del Sistema.

Estas pruebas caen fuera del alcance del proceso de ingeniera de software y no son conducidos nicamente por el encargado del desarrollo, sin embargo el ingeniero de software debe anticiparse a los problemas de interaccin y: 1. Disear caminos de manejos de errores que prueben toda la informacin procedente de otros elementos del sistema. 2. Llevar a cabo una serie de pruebas que simulen la presencia de datos en mal estado. 3. Registrar los resultados de las pruebas. 4. Participar en la planificacin y el diseo de las pruebas del sistema para asegurarse de que el software es probado adecuadamente. Hay cuatro tipos de pruebas para hacer. Aunque cada una tiene un propsito distinto, todas trabajan para verificar que se han integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas. PRUEBA DE RECUPERCIN: Muchos sistemas basados en computadoras deben recuperarse de fallas. En algunos casos un sistema debe ser tolerante a fallas, es decir no se debe caer por esas fallas. La prueba de recuperacin fuerza el fallo del software de muchas formas y verifica que la recuperacin se lleva a cabo apropiadamente. PRUEBA DE SEGURIDAD: Intenta verificar que los mecanismos de proteccin incorporados en el sistema lo protegern de la penetracin impropia. Durante la prueba de seguridad, el encargado de la prueba juega el papel de un individuo que desea penetrar en el sistema, donde todo vale. Con el suficiente tiempo y recursos una buena prueba termina penetrando. La idea es que el costo de la penetracin se mayor que el valor de los datos obtenidos mediante la penetracin. PRUEBA DE RESISTENCIA: Estas pruebas estn diseadas para enfrentar a los programas con situaciones anormales (sobre carga del sistema). La prueba consiste en ejecutar el sistema de forma que demande recursos de manera exagerada. Por ejemplo, incrementando la frecuencia de los datos de entrada, encontrar casos de prueba que requieran un mximo de memoria, o que produzcan excesivas bsquedas de datos en disco. Esencialmente el encargado de la prueba intenta tirar abajo el programa. PRUEBA DE RENDIMIENTO: Est diseada para probar el rendimiento del software en tiempo de ejecucin dentro del contexto de un sistema integrado. La prueba de rendimiento se da durante todos los pasos del proceso de prueba (incluso a nivel de unidad), sin embargo, hasta que no estn completamente integrados todos los elementos del sistema no se puede asegurar realmente el rendimiento del sistema.

68

Depuracin.
La depuracin aparece como una consecuencia de una prueba efectiva. O sea, cuando un caso de prueba descubre un error, la depuracin es el proceso que resulta en la eliminacin del error. Lo difcil es encontrar la causa de ese error, para lo cual puede ser necesario volver a realizar otras pruebas. Una vez encontrada la causa se hacen correcciones para eliminar ese error. El proceso de depuracin comienza con la ejecucin de un caso de prueba, se evalan los resultados y s aparece una falta de correspondencia entre los esperados y los reales estamos ante la presencia de un sntoma de error. En el proceso de depuracin pueden pasar dos cosas: se encuentra la causa, se corrige y se elimina; o no se encuentra la causa, en este caso la persona que realiza la depuracin debe sospechar las causas, disear un nuevo caso de prueba que ayude a validar sus sospechas y se realizan nuevas pruebas. Varias caractersticas de los errores hacen que la depuracin se difcil: El sntoma y la causa pueden ser geogrficamente remotos entre s. El sntoma puede desaparecer (temporalmente) al corregir otros errores. El sntoma puede estar causado por un error humano difcil de descubrir. El sntoma puede aparecer de forma intermitente. CONSIDERACIONES PSICOLGICAS: Desgraciadamente todo parece indicar que la habilidad en la depuracin es un rasgo innato del ser humano. Se han detectado grandes variaciones en la destreza para la depuracin de distintos programadores con el mismo bagaje educativo y experimental. ENFOQUES DE LA DEPURACIN: En general existen tres enfoques: FUERZA BRUTA: la ms comn y menos eficiente, se hacen volcados de memoria y se escriben sentencias write por todo el programa. Confiamos en que en algn lugar de la gran cantidad de informacin generada encontraremos alguna pista que nos lleve a la causa del error. VUELTA ATRS: se puede usar con xito para pequeos programas. Partiendo del lugar donde se descubre el sntoma, se recorre hacia atrs (manualmente) el cdigo fuente hasta que se llega a la posicin del error. ELIMINACIN DE LA CAUSA: los datos relacionados con la ocurrencia del error son organizados para las posibles causas. Se llega a una hiptesis de causas y se usan los datos anteriores para probar o revocar la hiptesis.

69

UNIDAD N 8: Mantenimiento.
El software no trivial se debe mantener. El reconocimiento de este hecho es el primer paso hacia la disminucin de peso de una tarea que constituye del 50% al 70% del presupuesto de muchas grandes empresas de software. La fase de mantenimiento comienza antes de la distribucin del software y contina a lo largo de su vida til. Durante esta etapa se corrigen errores, se hacen adaptaciones y se implementan mejoras. Despus de la fase de desarrollo, se realiza una revisin de la configuracin para asegurar que toda la documentacin est disponible y es la adecuada para las tareas de mantenimiento a seguir, se establece una organizacin para el mantenimiento y se define un esquema para las modificaciones del sistema y los errores. Las tareas relacionadas con el mantenimiento del software dependen del tipo de mantenimiento a realizar. En todos los casos el mantenimiento del software incluye la configuracin entera (o sea, todos los documentos desarrollados en las fases de planificacin y desarrollo), y no solo el cdigo.

Tareas de mantenimiento.
ORGANIZACIN DEL MANTENIMIENTO: Raramente existe una organizacin formal, de modo que el mantenimiento se lleva a cabo como se puede. Un esquema de organizacin puede ser este.
FPM Peticin de mantenimiento FPM Controlador del mantenimiento Supervisor del sistema ICS

Equipo de mantenimiento

Las peticiones del mantenimiento se dirigen hacia un controlador del mantenimiento que remite cada peticin a un supervisor del sistema para que la evale. Una vez evaluado el controlador de mantenimiento debe determinar las acciones a realizar y las dirige al equipo de mantenimiento. La peticin de mantenimiento debe estar estandarizada. Normalmente el equipo de desarrollo genera un formulario de peticin de mantenimiento (FMP) que ha de rellenar el usuario que requiere mantenimiento, de la siguiente manera: Para peticiones de mantenimiento correctivo (por error) el FMP debe incluir una completa descripcin de las circunstancias que llevaron al error incluyendo datos de E/S. Para peticiones de mantenimiento perfectivo o ampliativo una breve descripcin de los cambios (especificacin de requerimientos abreviada). El FMP es un documento generado exteriormente, internamente la organizacin de desarrollo genera un informe de cambios del software (ICS) indicando: Esfuerzo requerido para los cambios. Naturaleza de las modificaciones. Prioridad de la peticin. Otros datos sobre las modificaciones. FLUJO DE SUCESOS: Se tratan de manera distinta los distintos tipos de mantenimientos. Una vez llegada la peticin de mantenimiento se evala al tipo. Si es por un error hay que evaluarlo de inmediato y determinar si es crtico o no, si es crtico hay que actuar de inmediato, sino se caracteriza por prioridad y se coloca en la cola de prioridades. Si el pedido es una mejora se evala, puesto que esta puede ser rechazada, si no lo es se caracteriza y coloca en la cola de prioridades.

70

Tipos de Mantenimiento del Software.

Durante la fase de mantenimiento se encuentran cuatro tipos: MANTENIMIENTO CORRECTIVO: Modifica el software para corregir los defectos. El proceso incluye el diagnstico y correccin los errores. (20%). MANTENIMIENTO ADAPTATIVO: Con el paso del tiempo, es probable que cambie el entorno original para que se desarroll el software. El mantenimiento adaptativo produce modificaciones en el software para acomodarlo a los cambios de su entorno externo. (20%). MANTENIMIENTO AMPLIATIVO O PERFECTIVO: A medida que se usa el software, se reciben de los usuarios recomendaciones sobre nuevas posibilidades, sobre modificaciones de funciones ya existentes y sobre mejoras en general. Para satisfacer estas peticiones se lleva a cabo el mantenimiento perfectivo. Esta actividad contabiliza la mayor cantidad de esfuerzo gastado en el mantenimiento.(60%). MANTENIMIENTO PREVENTIVO: Hace cambios en los programas a fin de que se puedan corregir, adaptar y mejorar ms fcilmente. Para adaptar o perfeccionar debemos determinar nuevos requerimientos, redisear, generar cdigo y probar el software (son las mismas tareas que se aplican en la fase de desarrollo).

Efectos secundarios del mantenimiento.

La modificacin del software es peligrosa. Cada vez que se introduce un cambio en un complejo procedimiento lgico, la posibilidad de error aumenta. La documentacin del diseo y una cuidadosa prueba de regresin ayudan a eliminar los errores, pero aparecern efectos secundarios. EFECTOS SECUNDAIOS SOBRE EL CDIGO: Cuando se modifica el cdigo se introducen muchas veces errores de diferentes clases, estos errores pueden provenir de anular o cambiar subprogramas, eliminar o cambiar un cuantificador, modificacin de apertura o cierre de archivos, modificar operadores lgicos, etc. EFECTOS SECUNDAIOS SOBRE LOS DATOS: Durante el mantenimiento, a menudo se hacen cambios sobre determinados elementos de una estructura de datos o sobre la propia estructura de datos. Cuando se cambian los datos, el diseo de software puede no cuadrar con los datos y aparecen errores. Por ejemplo redefinir constantes, redefinir el formato de archivos o registros, aumento o disminucin del tamao de un array, reorganizacin de parmetros de subprogramas. EFECTOS SECUNDAIOS SOBRE LA DOCUMENTACIN: Se dan cuando no se reflejan los cambios del cdigo fuente en la documentacin de diseo y en los manuales del usuario. Si la documentacin no refleja fielmente el estado actual del software es peor incluso que la ausencia de ella. Algunas peticiones de mantenimiento pueden no requerir cambios en el diseo o en el cdigo, sino indican una falta de claridad en la documentacin del usuario, en tales casos el mantenimiento se centra en la documentacin.

Ciclo de mantenimiento.
ANLISIS: comprender el alcance y efecto de la modificacin y las restricciones. DISEO: redisear para incorporar los cambios. IMPLEMENTACIN: recodificacin, actualizacin de la documentacin interna del cdigo. ACTUALIZAR DOCUMENTACIN DE APOYO. DISTRIBUIR E INSTALAR LAS VERSIONES NUEVAS.

71

Ingeniera Inversa o Reingeniera.

INGENIERA INVERSA: La ingeniera inversa para el software es el proceso de analizar un programa en un esfuerzo de crear una representacin del programa de mayor nivel de abstraccin que el cdigo fuente. La ingeniera inversa extrae informacin del diseo de datos, arquitectnico y procedimental de un programa. REINGENIERA INVERSA: (renovacin o reclamacin) Adems de recuperar la informacin de diseo de un software existente, usa esa informacin para alterar o reconstruir el sistema existente, para mejorar la calidad general (aade nuevas funciones y/o mejoras de rendimiento a la funcin del sistema ya existente). Estas tcnicas solo sirven para una clase limitada de aplicaciones y el coste (esfuerzo y dinero) puede ser prohibitivo. ELEMENTOS DE INGENIERA INVERSA: 1. El nivel de abstraccin de un proceso de ingeniera inversa se refiere al nivel de sofisticacin que se puede extraer del cdigo fuente. Se busca representar el diseo procedimental (bajo nivel de abstraccin), informacin de la estructura del programa y de los datos, modelos de los flujos de datos y control y modelos de relaciones en entidades (alto nivel de abstraccin). A mayor nivel de abstraccin se permitir mayor comprensin del programa. 2. La completitud es el nivel de detalle que proporciona en el nivel de abstraccin, generalmente decrece cuando aumenta el nivel de abstraccin. 3. Es importante el grado de interactividad del analista con las herramientas automticas de la ingeniera inversa, generalmente al aumentar el nivel de abstraccin, la interactividad debe aumentar para que no sufra la completitud. 4. La direccionalidad, si es en un solo sentido, la informacin extrada del cdigo fuente se la proporciona al ingeniero. Si es en ambos sentidos, la informacin alimenta una herramienta de reingeniera para reestructurar o regenerar un programa antiguo.

Facilidad de Mantenimiento.
La facilidad de mantenimiento se puede definir como la facilidad para comprender, corregir, adaptar y/o mejorar el software. En cada paso de la ingeniera del software se puede trabajar en miras a la facilidad del mantenimiento. En el anlisis: Sealar principios generales. Identificar posibles mejoras. Estimar recursos para mantenimiento (interno o externo). Especificar controles de calidad. Diseo arquitectnico: Claro. Modular. Fcil de modificar. Notacin estndar. Diseo detallado: Notacin para algoritmos, estructuras de datos e interfaces estndar. Especificar efectos colaterales. Especificar manejo de excepciones. Implementacin: Estructurar una entrada y una salida. Identacin. Comentarios. Codificacin simple y clara. Pruebas: Anotaciones sobre las partes del programa que puedan necesitar mantenimiento preventivo.

72

UNIDAD N 9: Calidad
Calidad de un producto o servicio es el conjunto de caractersticas que le confieren la capacidad de satisfacer las necesidades explcitas e implcitas del cliente (Definicin ISO). En el desarrollo de software se pueden encontrar dos tipos de calidad: Calidad de Diseo: Se refiere a las caractersticas que acompaan a los requisitos, las especificaciones y al diseo de sistema. El grado de materiales, tolerancias, y especificaciones de rendimiento, todos contribuyen a la calidad de diseo. Cuando se utilizan materiales de alto grado y se especifican tolerancias ms estrictas y niveles ms altos de rendimiento, la calidad de diseo de un producto aumenta, si el producto se fabrica de acuerdo con las especificaciones, pues usar el mejor material, el mejor equipo, absolutamente cero defectos, libre de errores, pero que no satisfaga las necesidades del cliente no se considera de alta calidad. Calidad de Concordancia: Es el grado de cumplimiento de las especificaciones de diseo durante su realizacin. Est centrado principalmente en la implementacin, si la implementacin sigue el diseo y el sistema resultante cumple los objetivos de requisitos y rendimiento, la calidad de concordancia es alta. Factores que determinan la calidad del software: Operacin del sistema: Correccin Fiabilidad Eficiencia Integridad Facilidad de uso Modificacin y revisin: Mantenimiento Flexibilidad Prueba Adaptacin: Probabilidad Rentabilidad Interaccin con otro sistema

Calidad Total
La Gestin Total de Calidad es un enfoque sistemtico de la eliminacin de las causas raz de defectos en productos, que se compone de cuatro pasos: 1. El primer paso se refiere a un sistema de mejora continua del proceso (Calidad Total). El objetivo es desarrollar un proceso que sea visible, repetible y medible (mensurable). 2. El segundo paso, invocado una vez que se ha alcanzado el primer paso, examina lo intangible que afecta al proceso y trabaja para optimizar su impacto en el proceso. El proceso de software se puede ver afectado por cambios reorganizativos (por ejemplo, cambios de turno). Puede ser que una estructura organizativa estable sea importante para mejorar la calidad del software. 3. El tercer paso se centra en el usuario del producto, en esencia, examinando la forma que el usuario aplica el producto. Esto conduce a la mejora en el producto mismo. 4. El cuarto paso est orientado a buscar la oportunidad en reas relacionadas, observando la utilizacin del producto en el mercado. Se puede ver como un intento de detectar productos nuevos y beneficiosos.

Control de Calidad
El Control de Calidad es una serie de inspecciones, revisiones y pruebas utilizados a lo largo del ciclo de desarrollo para asegurar que cada producto cumple con los requisitos que le han sido asignado, es decir, que los productos sean de calidad aceptable y cumplan con los criterios de completitud y correctitud establecidos.

Garanta de Calidad
El objetivo de la Garanta de Calidad es proporcionar los datos necesarios sobre la calidad del producto, y asegurar que la calidad de producto est cumpliendo los objetivos.

73

Garanta de Calidad de Software. (SQA: Software Quality Assurance)

Los ingenieros de software afrontan la calidad y realizan garanta de calidad aplicando mtodos tcnicos slidos y medidas, realizando revisiones tcnicas formales, y llevando a cabo pruebas de software bien planificadas. El propsito de un grupo SQA es proporcionar la garanta de que los procedimientos, las herramientas y las tcnicas utilizadas durante el desarrollo y la modificacin del producto son adecuados para alcanzar el nivel de confianza deseado en los productos. El grupo SQA puede ser o no el mismo que el grupo de desarrollo del software, pero es aconsejable que sea un grupo distinto para asegurar imparcialidad a la actividades de control de calidad. Las actividades que realiza un grupo independiente SQA son: Establecimiento de un Plan SQA para un Proyecto: El plan se desarrolla durante la planificacin del proyecto y es revisado por todas las partes interesadas. El plan identifica: - Evaluaciones a realizar - auditorias y Revisiones a Realizar - Estndares que se pueden aplicar al proyecto - Procedimientos para informacin y seguimiento de errores. - Documentos producidos por el grupo SQA - Realimentacin de la informacin (FEEDBACK) proporcionada al equipo del proyecto de software. Por cada proceso que realizar el equipo de ingeniera del software, el grupo de SQA revisa la descripcin del proceso para ajustarse a la poltica de la empresa, los estndares internos del software, los estndares impuestos externamente (por ejemplo ISO 9001) y a otras partes del proyecto del software. Luego el grupo de SQA identifica, documenta y sigue la pista de las desviaciones desde el proceso y verifica que se han hecho las correcciones e informa peridicamente de los resultados de su trabajo al gestor del proyecto. Debe tambin asegurar que las desviaciones del trabajo y los productos del software se documenten y se manejen de acuerdo con un procedimiento establecido. Finalmente, los elementos que no se ajustan a los requisitos estn bajo seguimiento hasta que se resuelven. Adems de estas actividades, el grupo de SQA coordina el control y la gestin de cambios y ayuda a recopilar y a analizar las mtricas del software. En sntesis, las actividades SQA engloban: Mtodos y herramientas de anlisis, diseo, codificacin y prueba. Revisiones tcnicas formales que se aplican durante cada paso de la ingeniera del software. Estrategia de prueba. Control de la documentacin del software y cambios realizados. Un procedimiento que asegure un ajuste a los estndares. Mecanismos de medida y de informacin.

74

El Plan SQA
El Plan SQA describe las actividades de SQA para cada proyecto de software. En las secciones iniciales se describe el propsito y el alcance del documento e indican que actividades del proceso del software son abarcadas por la garanta de calidad. Se listan todos los documentos sealados en el Plan de SQA y se destacan todos los estndares aplicables. La seccin de gestin del plan describe la situacin de la SQA dentro de la estructura organizativa; las tareas y actividades de SQA y su emplazamiento a lo largo del proceso del software; y los papeles y responsabilidades organizativas relativas a la calidad del producto. La seccin de documentacin hace referencia cada uno de los productos de trabajo producidos como parte del proceso de software. Entre estos se incluyen: Documentos del Proyecto (por ejemplo, plan del proyecto) Modelos (por ejemplo, DERs, jerarquas de clases) Documentos Tcnicos (por ejemplo, especificaciones, planes de prueba) Documentos de Usuario (por ejemplo, archivos de ayuda) La seccin de estndares, prcticas y convenciones lista todos los estndares y prcticas que se aplican durante el proceso de software, por ejemplo estndares de documentos, estndares de comunicacin y directrices de revisin. Adems se listan todos los proyectos, procesos, y en algunos casos mtricas de productos, que se obtienen del proceso de ingeniera de software. La seccin de revisiones y auditorias del plan identifica las revisiones y auditorias que se van a llevar a cabo por el equipo de ingeniera de software, el grupo de SQA y el cliente. La seccin prueba hace referencia al plan y procedimientos de pruebas del software. Tambin define requisitos de mantenimiento de registros de prueba. La seccin de informacin sobre problemas y accin correctora define procedimientos para informar, hacer seguimientos y resolver errores y defectos, e identifica las responsabilidades organizativas para stas actividades. El resto del plan de SQA identifica las herramientas y mtodos que soportan actividades y tareas de SQA; hace referencia a los procedimientos de gestin de configuracin de software para controlar el cambio, define un enfoque de gestin de contratos; establece mtodos para reunir, salvaguardar y mantener todos los registros; se detallan los mtodos para identificar, evaluar, supervisar y controlar riesgos. Revisiones: PFR: Factibilidad del Producto. SRR: Requisitos del Software. PDR: Diseo Preliminar. CDR: Diseo Crtico. ATR: Prueba de Aceptacin. PRR: Revisin Final. Ventajas del SQA: Software con menos defectos. Mayor fiabilidad. Menor costo de mantenimiento. Costo total del ciclo disminuye. Problemas del SQA: Difcil en organizaciones pequeas. Representa cambios. Requiere gastos.

75

Revisiones Tcnicas Formales. (RTF)

Las revisiones se aplican en varios momentos del desarrollo del software y sirven para detectar defectos, que puedan as ser eliminados. Las revisiones del software sirven para purificar las actividades de ingeniera del software que suceden como resultado del anlisis, el diseo y la codificacin. Una revisin tcnica formal (a veces denominada inspeccin) es el filtro ms efectivo desde el punto de vista de garanta de calidad y es llevada a cabo por los ingenieros de software. Los Objetivos de la RTF son: Descubrir errores en la funcin, la lgica o la implementacin. Verificar que el software alcanza los requisitos. Garantizar que el software sigue estndares predefinidos. Conseguir un software desarrollado de forma uniformemente. Hacer que los Proyectos sean ms manejables. La RTF incluye recorridos, inspecciones y otras tareas de revisin tcnica de software. Cada RTF se lleva a cabo mediante una reunin entre 3 a 5 personas para la revisin, preparada por adelantado (a lo sumo 2 hs. de trabajo cada persona), de duracin menor de 2 horas. Cada RTF se centra en una parte especfica del software (inspecciones de un mdulo o grupo de mdulos). Al final de la revisin los participantes deciden si: aceptan el producto, rechazan el producto o aceptan el producto provisionalmente. Inspecciones: Directrices para las revisiones Revisar el producto. Fijar agenda y mantenerla. Limitar el debate. Enunciar el problema. Tomar notas. Limitar el nmero de participantes. Preparar revisin anticipada. Listar comprobaciones. Planificar tiempo. Entrenar a los revisores. Repasar revisiones anteriores.

76

Estndares de Calidad
Un sistema de garanta de calidad se puede definir como la estructura organizativa, responsabilidades, procedimientos, procesos y recursos para implementar gestin de calidad. CMM En 1987 Watts Humphrey idea un Modelo de Maduracin de las Organizaciones por Niveles (Managing the Software Process). Es un modelo de calidad basado en el control estadstico de la calidad del proceso de desarrollo de software, desarrollado por el Software Engineering Institute (SEI) de la Universidad de Carnegie & Mellon. Este modelo de calidad se basa en un conjunto de funciones de Ingeniera de Software que deberan estar presentes conforme las organizaciones alcanzan diferentes niveles de madurez del proceso. Para determinar el estado actual de madurez del proceso se utiliza un cuestionario de evaluacin y un esquema de 5 grados, que determina la conformidad con el Modelo de Capacidad de Madurez (CMM)

Los cinco niveles definidos se obtienen como consecuencia de evaluar las respuestas del cuestionario de evaluacin basado en el CMM. Los resultados del cuestionario se filtran en un nico grado numrico que proporciona una indicacin de la madurez del proceso de una organizacin. Los cinco niveles que considera el CMM son: Nivel 1: Informal Proceso catico. No existen formalismos en los procedimientos, ni en la estimacin de costos, ni en la planificacin. La Gerencia no comprende los aspectos clave. Desafos Clave: o Gerenciamiento de proyectos. o Planificacin de Proyectos. o Aseguramiento de Calidad del Software. o Administracin de Configuraciones.

77

Nivel 2: Repetible Proceso centrado en el individuo. El proceso depende de los individuos. Dominio del proceso slo en proyectos similares. Ausencia de una estructura ordenada para el mejoramiento. Desafos Clave: o Capacitacin. o Actividades Tcnicas: Revisiones y Testing. o Focalizacin en el Proceso: Estndares y Grupos de Proceso. Nivel 3: Definido Proceso con metodologas comunes. Las mejoras son administradas por el grupo de proceso. Desafos Clave: o Procesos de anlisis y de mediciones. o Planes de calidad. Nivel 4: Gerenciado Proceso medido. Base de datos del proceso, para anlisis. Desafos Clave: o Cambios de tecnologas. o Prevencin de problemas Nivel 5: Optimizado Fuerte utilizacin de las mediciones para: Identificar elementos dbiles del proceso. Justificar cambios de tecnologa. Prevencin de defectos. Realimentar el proceso de mejoras. Desafos Clave: o Suavidad en la gestin del proceso. o Mantenimiento del nivel ptimo. En cada nivel del modelo se busca desarrollar en la organizacin las siguientes reas clave de resultados: Nivel 1: Inicial Compromiso con la calidad Nivel 2: Repetible Planeacin de Proyectos de Software Seguimiento del Proyecto de Software Administracin de Requerimientos Administracin de la Configuracin del Software Aseguramiento de la Calidad del Software Administracin de Subcontratos de Software Nivel 3: Definido Enfocamiento en el Proceso de la Organizacin Definicin del Proceso de la Organizacin Programa de Entrenamiento Administracin del Software Integrado Ingeniera de Producto de Software Coordinacin Intergrupal Revisiones entre Pares Nivel 4: Administrado Administracin Cuantitativa del Proceso Administracin de la Calidad del Software Nivel 5: Optimizado Prevencin de Defectos Administracin del Cambio Tecnolgico Administracin del Cambio del Proceso

78

ISO 9000 Para identificarse con uno de los modelos de sistema de garanta de calidad de ISO 9000, el sistema de calidad y las operaciones de una compaa son examinados minuciosamente por unos auditores externos para ajustarlo a los estndares y a la operacin efectiva. Despus de un registro correcto, la compaa recibe un certificado avalado por los auditores. Las auditorias de seguimiento cada 6 meses aseguran el ajuste continuado a los estndares. El enfoque de ISO en sistemas de garanta de calidad Los modelos de garanta de calidad ISO 9000 tratan la empresa como una red de procesos interconectados. Para que un sistema de calidad se ajuste a ISO, estos procesos deben afrontar reas identificadas en el estndar y se deben documentar y practicar como se ha descrito. Documentar un proceso ayuda a que una organizacin lo entienda, controle y mejore. ISO 9000 describe en trminos generales, los elementos de un sistema de garanta de calidad. Estos elementos incluyen la estructura organizativa, procedimientos, procesos y recursos necesarios para implementar la planificacin de la calidad, el control de la calidad, la garanta de calidad y la mejora de calidad. Sin embargo, ISO 9000 no describe como debera implementar una organizacin stos elementos del sistema de calidad. Por consiguiente, el reto se encuentra en disear e implementar un sistema de garanta de calidad que cumpla los estndares y acople los productos, servicios y cultura de la compaa. El estndar ISO 9001 ISO 9001 es el estndar de garanta de calidad que se aplica a la ingeniera del software. El estndar contiene 20 requisitos que deben estar presentes en un sistema de garanta de calidad efectiva. Como el estndar ISO 9001 es aplicable a todas las disciplinas de la ingeniera de software, se ha desarrollado un conjunto especial de directrices ISO (ISO 9000-3) para ayudar a interpretar el estndar para su uso en el proceso de software. Para que una organizacin de software se registre como ISO 9001, debe establecer normas y procedimientos que afronten los requisitos sealados a continuacin y que puedan demostrar que se estn cumpliendo: 1. Responsabilidad de la gestin 2. Sistemas de calidad 3. Revisin de contratos 4. Control de diseo 5. Control de datos y documentos 6. Compras 7. Control del producto suministrado por el cliente 8. Identificacin y posibilidad de seguimiento del producto 9. Control del proceso 10. Inspeccin y prueba 11. Control de inspeccin, medicin y equipo de pruebas 12. Inspeccin y estado de prueba 13. Control de producto no aceptado 14. Accin correctora y preventiva 15. Tratamiento, almacenamiento, empaquetamiento, preservacin y entrega 16. Control de registros de calidad 17. Auditorias internas de calidad 18. Formacin 19. Servicios 20. Tcnicas estadsticas

79

Una comparacin entre CMM e ISO 9001 El modelo de Capacidad y Madurez para Software (CMM) desarrollado por el Instituto para la Ingeniera de Software (SEI) y la serie de estndares ISO 9000, desarrollados por la Organizacin Internacional de Estndares, comparten su preocupacin por la calidad y la administracin del proceso. Ambos son impulsados por preocupaciones similares y estn intuitivamente correlacionados. El estndar especfico de la serie ISO 9000 concerniente a las organizaciones de software es ISO 9001. Algunas preguntas frecuentes sobre la relacin entre ISO 9001 y CMM son: A qu nivel del CMM puede considerar s e que una organizacin acata el ISO 9001? Puede una organizacin nivel 2 3 considerar s e conforme a ISO 9001? Deben basarse mis esfuerzos de administracin de calidad y mejor a de procesos en ISO 9001 o en CMM? El propsito de este trabajo es comparar el CMM con ISO 9001, identificar sus diferencias y similitudes, y responder esas preguntas. Administracin de la Responsabilidad ISO 9001 requiere que la poltica de calidad sea definida, documentada, entendida, implementada y mantenida; esas responsabilidades y las autoridades para toda la especificacin del personal para lograr y monitorear la calidad son definidas ; y los recursos internos par a verificacin son definidos y entrenados. Un administrador es designado par a asegurar que el programa de calidad es implementado y mantenido. En CMM, la administracin de responsabilidad para la poltica de calidad y las actividades de verificacin son dirigidas en principio por el Aseguramiento de Calidad de Software, aunque la Planeacin de Proyectos de Software y el Seguimiento y Vigilancia de Proyectos de Software tambin incluyen actividades que identifican responsabilidades. La administracin de responsabilidad, tanto en la alta direccin como a nivel de la administracin de proyectos, est contemplada por la Verificacin de la Implementacin. Ms genricamente, los asuntos de liderazgo son tratados por el aspecto de Compromiso con el Cumplimiento, y la estructura organizacional y asuntos de recursos son tratados en el aspecto de Capacidad para el Cumplimiento. Es posible argumentar que la poltica de calidad descrita por la Administracin de Calidad de Software en el nivel 4 es tambin tratada por esta clusula, pero en el nivel 4 la poltica de calidad es cuantitativa. ISO 9001 es algo ambiguo en la medicin del sistema de administracin de calidad. Sistema de Calidad ISO 9001 requiere que se documente el sistema de calidad, incluyendo procedimientos e instrucciones. ISO 9000-3 caracteriza el sistema de calidad como un proceso integrado a travs de todo el ciclo de desarrollo. Las actividades del sistema de calidad son tratadas por CMM, en principio, por el Aseguramiento de Calidad de Software. Los procedimientos que deben ser usados se distribuyen a lo largo de varias reas claves de proceso (KPA). Los procedimientos especficos y estndares que un proyecto de software deben usar son especificados en el Plan de Desarrollo de Software descrito por la Planeacin de Proyectos de Software. La conformidad con esos estndares y procedimientos es asegurada por el Aseguramiento de Calidad de Software y por las prcticas de auditoria dadas por la Verificacin de la Implementacin. La Ingeniera de Producto de Software requiere que s e definan las tareas de Ingeniera de Software, se integren y ejecuten consistentemente. Es posible argumentar correspondencia con la Definicin de Procesos Organizacionales, que describe estndares, procedimientos y descripciones de procesos a nivel Organizacional. Ciertamente contribuye a lograr esta clusula, pero los estndares y procedimientos pueden tratar s e a nivel de proyecto. ISO 9001 discute el sistema de calidad del proveedor, pero no discute la relacin entre el soporte organizacional y la implementacin del proyecto como lo hace el CMM. Revisin de Contratos ISO 9001 requiere que los contratos se revisen para determinar s i los requerimientos son adecuadamente definidos, estn de acuerdo con la oferta y si pueden ser implementados. La revisin de requerimientos del cliente se describe por CMM en la Administracin de Requerimientos. La organizacin de Software (proveedor) asegura que los requerimientos del sistema asignados al Software son documentados y revisados, y que los requerimientos faltantes o ambiguos son aclarados. Dado que CMM se restringe a la perspectiva del Software, los requerimientos del cliente como un todo estn ms all del alcance de esta KPA. La Planeacin de Proyectos de Software describe el desarrollo de una propuesta, una declaracin de trabajo y un plan de desarrollo de software. El CMM tambin especifica explcitamente la adquisicin de software a travs de subcontratacin de organizaciones de software, tal y como s e describe en la Administracin de Subcontratacin de Software. Los contratos pueden ser con un cliente o un subcontratista, esa distincin no se hace explcitamente en ISO 9001.

80

Control del Diseo ISO 9001 requiere que los procedimientos de control y verificacin del diseo se establezcan. Esto incluye planeacin de actividades de diseo, identificar entradas y salidas, verificar el diseo y controlar cambios al diseo. ISO 9000-3 elabora esta clusula basndose en los requerimientos del cliente, planeacin del desarrollo, planeacin de calidad, diseo e implementacin, pruebas y validacin, y administracin de la configuracin. En CMM, las actividades del ciclo de desarrollo de anlisis de requerimientos, diseo, codificacin y pruebas se describen por la Ingeniera de Producto de Software. La planeacin de estas actividades se describe en la Planeacin de Proyectos de Software. El seguimiento y Vigilancia del Proyecto describe el control de ese ciclo de desarrollo, y la Administracin de la Configuracin de Software describe la administracin de la configuracin de los productos de software generados por esas actividades. ISO 9001 requiere de mediciones para el control del diseo. Establece que el proveedor debe llevar a cabo revisiones para asegurar que los requerimientos se cumplen y que los mtodos de diseo se llevan a cabo correctamente. ISO 9001 permite flexibilidad en los controles especficos que se usan. En contraste, CMM implica un mecanismo especfico de control de calidad: las "peer reviews", que dan sopor te a los procesos a travs del ciclo de desarrollo, desde el anlisis de requerimientos hasta las pruebas. Control de Documentos ISO 9001 requiere que los productos adquiridos sean conformes a sus requerimientos especficos. Esto incluye la estimacin de subcontratistas potenciales y verificacin de productos adquiridos. En CMM, esto es abordado por la Administracin de Subcontratacin de Software. Identificacin y Rastreo del Producto ISO 9001 requiere que el producto sea identificable y rastreable durante todas las fases de produccin, entrega e instalacin. El CMM cubre esta clusula primeramente en la Administracin de Configuracin de Software, pero la Ingeniera de Productos de Software establece necesidades especficas de consistencia y rastreabilidad entre los trabajos de produccin de software. Inspeccin y Pruebas ISO 9001 requiere que los materiales entrantes sean inspeccionados y verificados antes de usar los y que se lleven a cabo inspecciones y pruebas dentro del proceso. Inspeccin final y pruebas son llevadas a cabo antes de liberar el producto terminado. Se guardan registros de las inspecciones y pruebas. Los asuntos concernientes a la inspeccin de materiales de entrada en CMM son tratados por la Ingeniera de Producto de Software. Las inspecciones dentro del proceso se llevan a cabo mediante las "peer reviews". Inspeccin, medicin y prueba de equipos ISO 9001 requiere que el equipo usado para demostrar conformidad debe ser controlado, calibrado y mantenido. Cuando se usa Hardware o Software de prueba, se checa antes de usar lo, y es revisado a intervalos prescritos. ISO 9000-3 aclara esta clusula con clusulas sobre validacin y pruebas, reglas, prcticas, convenciones, herramientas y tcnicas. Esta clusula es genricamente abordada en CMM bajo las prcticas de prueba en la Ingeniera de Productos de Software. Control de Productos no conformes ISO 9001 requiere el control de productos no conformes par a prevenir su uso o instalacin inadvertida. ISO 9000-3 mapea este concepto a clusulas de diseo e implementacin; pruebas y validacin; replicacin, entrega e instalacin; configuracin y administracin. La no conformidad del producto no est especficamente abordada por CMM. La administracin de la configuracin de software aborda el estatus de los artculos que contengan defectos conocidos an no arreglados. Acciones Correctivas ISO 9001 requiere que las causas de no conformidad de los productos se identifiquen. Las causas potenciales de no conformidad son eliminadas; los procesos cambian como resultado de las acciones correctivas. Una lectura literal de esta clusula implica muchas prcticas de Prevencin de Defectos. Est clusula es conducida por las quejas de los clientes.

81

Manejo, Almacenamiento, Empaque y Entrega ISO 9001 requiere que los procedimientos de manejo, almacenamiento, empaque y entrega sean establecidos y mantenidos. ISO 9000-3 mapea estas clusulas en aceptacin, replicacin, entrega e instalacin. Replicacin, entrega e instalacin no son cubiertos por el CMM. Las pruebas de aceptacin se tratan en la Ingeniera de Productos de Software y el la Administracin de Configuracin de Software. Entrega e instalacin del producto, de cualquier manera, no estn descritos en CMM. Registros de Calidad ISO 9001 requiere que se recolecten y mantengan registros de calidad. Las prcticas que definen los registros de calidad son distribuidas en CMM a travs de muchas actividades. Especficamente pertinentes a esta clusula son las pruebas y "peer reviews" en la Ingeniera de Producto de Software. Auditorias de Calidad Internas ISO 9001 requiere que las auditorias sean planeadas y ejecutadas. El resultado de las auditorias se comunica a la administracin, y las deficiencias encontradas se corrigen. El proceso de auditoria es descrito por el Aseguramiento de Calidad de Software. Las auditorias especficas en CMM se encuentran en las prcticas de auditoria en la Verificacin de la Implementacin. Entrenamiento ISO 9001 requiere que las necesidades de entrenamiento se identifiquen y que el entrenamiento se lleve a cabo, dado que ciertas tareas requieren de personal calificado. Registros del entrenamiento son mantenidos. Las necesidades especficas de entrenamiento en CMM son identificadas en las prcticas de orientacin y entrenamiento que se encuentran en la Capacidad para Ejecucin. La infraestructura general de entrenamiento se describe en el Programa de Entrenamiento. Servicio ISO 9001 requiere que las actividades de ser vicio se ejecuten tal y como se especificaron. ISO 9000-3 aborda esta clusula como mantenimiento. Aunque CMM est pensado para ser aplicado en ambientes tanto de desarrollo como de mantenimiento de Software, las prcticas en CMM no estn directamente relacionadas con loas aspectos nicos que caracterizan el ambiente de mantenimiento. El mantenimiento est embebido a travs de las prcticas del CMM, y deben ser apropiadamente interpretadas en los contextos de desarrollo o mantenimiento. Tcnicas Estadsticas ISO 9001 establece que, cuando sea posible, se deben identificar y usar tcnicas estadsticas adecuadas para verificar qu tan aceptable es la capacidad del proceso y las caractersticas del producto. ISO 9000-3 simplemente caracteriza esta clusula como mediciones. Las prcticas que describen las mediciones en CMM se distribuyen a travs de varias KPA. Las mediciones del producto son tpicamente incorporadas a las prcticas de Actividades Ejecutadas, y las mediciones del proceso son descritas por la Medicin y Anlisis. La definicin de procesos organizacionales describe que el establecimiento de una base de datos que contenga datos de productos y del proceso.

82

Contrastando ISO 9001 y CMM La mayor diferencia entre estos documentos es el nfasis que pone CMM en la mejor a continua del proceso. ISO 9001 establece los criterios mnimos par a un sistema de calidad aceptable. Debe notar se que CMM se enfoca estrictamente en Software, mientras que ISO 9001 tiene un alcance mucho mayor: hardware, software, materiales procesados y servicios. La mayor similitud es que tanto CMM como ISO 9001, en ltima instancia, se fundamentan en Di lo que haces, has lo que dices. La premisa fundamental de ISO 9001 es que cada proceso importante debe ser documentado y cada producto ser probado por medio de una actividad de control de calidad. ISO 9001 requiere que la documentacin contenga instrucciones de qu se debe hacer y cmo se debe hacer. CMM comparte este nfasis en los procesos que son documentados y prcticas que se ejecutan tal y como se documentaron. Una comparacin preliminar de los conceptos de ISO 9001 y CMM podra sugerir que una organizacin certificada en ISO 9001 se encontrara en un nivel de madurez 3 4. En realidad, hay organizaciones de nivel 1 certificadas. Una razn es la variabilidad de la interpretacin. Dado el alto nivel de abstraccin en ISO 9001, es poco claro qu grado de sofisticacin es requerido por una auditoria. El lograr el nivel 2 implica dominar las KPA del nivel 2. Estas KPA de nivel 2 estn fuertemente relacionadas con ISO 9001, por lo tanto, una organizacin que obtiene y mantiene una certificacin ISO 9001 debera estar cerca del nivel 2. Aunque hay asuntos especficos que no se tratan adecuadamente en CMM, en general se puede decir que los requerimientos de ISO 9001 estn contemplados por el CMM. Es cierto que sujetar se a CMM puede ayudar a una organizacin a preparar se para una auditoria de ISO 9001. Aunque ambos enfoques pueden usarse para estructurar un programa de mejora de procesos, la gua ms detallada y la mayor profundidad par a las organizaciones de software dada por CMM sugiere que es la mejor opcin.

83

UNIDAD N 10: CASE. (Ingeniera de Software Asistida por Computadora).

Evolucin histrica del CASE.
El CASE proporciona al ingeniero la capacidad de automatizar las actividades manuales y de mejorar su enfoque de trabajo.

Objetivos del CASE.

El objetivo ms importante del CASE (a largo plazo) es conseguir la generacin automtica de programas desde una especificacin a nivel de diseo. El CASE es el conjunto de herramientas que compone un entorno de apoyo de proyectos integrados.

Bloques que componen el CASE.

El CASE puede ser tan simple como una nica herramienta que permite desarrollar una actividad especfica, o tan compleja como un entorno que integre distintas herramientas, una base de datos, gente, hardware , una red, S.O., etc. Cada bloque constituye la base del siguiente y las herramientas se sitan en la cima de la pila. Los buenos entornos de ingeniera de software se construyen sobre una arquitectura de entorno que engloba los correspondientes sistemas e software y hardware. Adems dicha arquitectura debe considerar los patrones de trabajo humano que se aplican durante el proceso de ingeniera de software. La arquitectura de entorno, compuesta por la plataforma de hardware y el soporte del S.O. (incluida la red y la gestin de base de datos) constituye la base del CASE. Un conjunto de servicios de portabilidad constituyen un puente entre las herramientas CASE y su marco de integracin y la arquitectura de entorno. El marco de integracin es un conjunto de programas especializados que permiten a cada herramienta CASE comunicarse con las dems, para crear una base de datos de proyectos y mostrar una apariencia homognea al usuario final. Los servicios de portabilidad permiten que las herramientas CASE y su marco de integracin pueden migrar a travs de diferentes plataformas de hardware y S.O. sin grandes esfuerzos de adaptacin.
Herramientas CASE Marco de Integracin Servicios de Portabilidad Sistema Operativo Plataforma de Hardware Arquitectura de Entorno

La mayor parte de las herramientas CASE que se utilizan en la actualidad no han sido construas empleando los bloques de construccin CASE. Algunas herramientas CASE siguen siendo soluciones puntuales que prestan apoyo a una actividad concreta (como por ejemplo: anlisis y modelado), las cuales no se comunican directamente con otras; no estn unidas a una Base de Datos de Proyecto y no forma parte de un entorno integrado ( I-CASE ).

84

Herramientas CASE
Las herramientas CASE se pueden clasificar: por su funcin, por su papel como instrumentos para administradores o personal tcnicos, por su utilizacin en los distintos pasos del proceso de ingeniera de software, por la arquitectura de entorno (hardware y software) que les presta su apoyo, o incluso por su origen o su costo. La clasificacin siguiente utiliza como criterio principal la funcin. 1. -Herramientas de Ingeniera de la Informacin Al modelar los requisitos de informacin estratgica de una organizacin, las herramientas de la ingeniera de la informacin proporcionan un metamodelo del cual se derivan sistemas de informacin especficos. 2. -Modelado de Procesos y Herramientas de Administracin Se utilizan para representar los elementos claves del proceso de modo que sea posible entenderlo mejor. Tambin se denominan herramientas de tecnologa de proceso. 3. -Herramientas de Planificacin de Proyecto Las herramientas de sta categora se concentran en dos reas primordiales: estimacin de esfuerzo de proceso y de coste de software, y planificacin de proyecto. Las herramientas de estimacin calculan el esfuerzo estimado, la duracin del proyecto y el nmero recomendado de personas empleando una o ms tcnicas de descomposicin. Las herramientas de planificacin de proyectos capacitan al administrador para definir todas las tareas del proyecto, para crear una red de tareas, para representar las interdependencias entre tareas y para modelar la cantidad de paralelismo que sea posible para ese proyecto. 4. -Herramientas de Anlisis de Riesgo Capacitan al administrador del proyecto para construir una tabla de riesgos, proporcionando una gua detalladas en la identificacin y anlisis de riesgos. 5. -Herramientas de Administracin de Proyectos Se utilizan para realizar un seguimiento y monitorizacin de forma continua de la planificacin del proyecto y el plan del proyecto. 6. -Herramientas de Seguimientos de Requisitos El objetivo es proporcionar un enfoque sistemtico para el aislamiento de requisitos en el desarrollo de grandes sistemas. 7. -Herramientas de Mtricas y Gestin Las herramientas orientadas a la administracin capturan mtricas especficas del proyecto (por ejemplo, LDC/persona/mes, defectos por puntos de funcin) que proporcionan una indicacin global de productividad o de calidad. 8. -Herramientas de Documentacin Son herramientas de produccin de documentos y de autoedicin. 9.Herramientas de Software de Sistema CASE es una tecnologa de estaciones de trabajo. Por tanto, el entorno CASE debe adaptarse a un software de sistema en red de alta calidad, al correo electrnico, a los boletines electrnicos y a otras capacidades de comunicacin. 10.Herramientas de Control de Calidad Son herramientas mtricas que hacen una auditoria del cdigo fuente para determinar si se ajusta o no a ciertos estndares del lenguaje. 11.Herramientas de Gestin de Base de Datos Mantienen la base de datos del proyecto.

12.-Herramientas de Gestin de Configuracin de Software 85

La Gestin de Configuracin de Software (GCS) se encuentra en el ncleo de todos los entornos CASE. Las herramientas pueden ofrecer su asistencia en las 5 tareas principales de GCS: identificacin, control de versiones, control de cambios, auditoria y contabilidad de estados. 13.-Herramientas de Anlisis y Diseo Capacitan al ingeniero de software para crear modelos del sistema. Los modelos contienen una representacin de los datos, de la funcin y del comportamiento (en el nivel de anlisis), as como caracterizaciones del diseo de datos, arquitectura, procedimientos e interfaz. 14.-Herramientas PRO/SIM Son herramientas de prototipos y simulacin, proporcionan la capacidad de predecir el comportamiento de un sistema en tiempo real antes de llegar a contruirlo. 15.-Herramientas de Desarrollo y Diseo de Interfaz Son herramientas de generacin de prototipos de interfaz que permiten una rpida creacin en pantalla de sofisticadas interfaces de usuarios. 16.-Herramientas de Generacin de Prototipos Permiten la creacin de un diseo de datos, acoplado con las disposiciones de la pantalla y de los informes simultneamente. 17.-Herramientas de Programacin La categora de herramientas de programacin abarca los compiladores, editores y depuradores que estn disponibles para prestar su apoyo en la mayora de los lenguajes de programacin convencionales. Adems, los entornos de programacin orientados a objetos, los lenguajes de cuarta generacin, los entornos de programacin grfica, los generadores de aplicaciones y los lenguajes de consulta de base de datos residen tambin en esta categora. 18.-Herramientas de Integracin y Comprobacin de Software Existen las siguientes categoras de herramientas de integracin y comprobacin: Adquisicin de datos: herramientas que adquieren datos que se utilizarn durante la comprobacin. Medida esttica: herramientas que analizan el cdigo fuente sin ejecutar casos de prueba. Medida dinmica: herramientas que analizan el cdigo fuente durante la ejecucin. Simulacin: herramientas que simulas las funciones del hardware o de otros elementos externos. Administracin de comprobaciones: herramientas que prestan su asistencia en la planificacin, desarrollo y control de las comprobaciones. Herramientas de funcionalidad cruzada: se trata de herramientas que cruzan los lmites de las categoras anteriores. 19.-Herramientas de Anlisis Esttico Prestan su asistencia al ingeniero de software a efectos de derivar casos de prueba. 20.-Herramientas de Depuracin Interactan con un programa que se est ejecutando (Debug). 21.-Herramientas de Comprobacin Cliente Servidor Realizan comprobaciones especializadas en las comunicaciones en red para el cliente y el servidor. 22.-Herramientas de Reingeniera Las herramientas de estas categoras se pueden subdividir en las funciones siguientes: Herramientas de ingeniera inversa para producir especificaciones. Herramientas de reestructuracin y anlisis de cdigo. Herramientas de reingeniera para sistemas en lnea.

86

Integracin de las Herramientas

Los beneficios del CASE integrado (I-CASE) incluyen: 1. Una transferencia suave de informacin (modelos, programas, documentos, datos) entre una herramienta y otra, y entre un paso de ingeniera y el siguiente. 2. Una reduccin del esfuerzo necesario para efectuar actividades globales, tales como la administracin de configuracin de software, el control de calidad y la produccin de documentos. 3. Un aumento del control del proyecto que se logra mediante una mejor planificacin, monitorizacin y comunicacin. 4. Una mejor coordinacin entre los miembros del personal que estn trabajando en grandes proyectos de software. Los requisitos del I-CASE son: Proporcionar un mecanismo para compartir la informacin de ingeniera del software entre todas las herramientas que estn contenidas en el entorno. Hacer posible que un cambio de un elemento de informacin se siga hasta los dems elementos de informacin relacionados. Proporcionar un control de versiones y una gestin de configuracin general para toda la informacin de la ingeniera de software. Permitir un acceso directo y no secuencia a cualquiera de las herramientas contenidas en el entorno. Establecer un apoyo automatizado para un contexto de procedimientos para el trabajo de la ingeniera del software que integra las herramientas y los datos en una estructura de desglose de trabajo estandarizada. Recoger mtricas tanto de gestin como tcnicas que se puedan utilizar para mejorar el proceso y el producto. El depsito de un Entorno CASE es el conjunto de mecanismos y de estructuras de datos que consiguen la integracin entre datos y herramientas y entre datos y datos. Proporciona las funciones y herramientas de un sistema de Gestin de Base de Datos y servicios que son especficos de un entorno CASE. Muchos requisitos del depsito son iguales a los de las aplicaciones tpicas que se construyen tomando como base un Sistema de Gestin de Base de Datos (SGBD). Muchos de los depsitos CASE actuales hacen uso de un SGBD (normalmente relacional u Orientado a Objetos) como tecnologa de gestin de datos bsica. Las caractersticas de un SGBD estndar en un depsito CASE incluyen lo siguiente: Almacenamiento de datos no redundante Acceso de alto nivel Independencia de datos Control de transacciones Seguridad Apertura (mecanismo de importacin/exportacin sencillo) Apoyo multiusuario El entorno CASE tambin efecta demandas especiales con respecto al depsito que van ms all de lo disponible en un SGBD comercial: Almacenamiento de estructuras de datos sofisticadas Integridad Interfaz de herramientas ricas en trminos semnticos Gestin de procesos/proyectos Tambin debe incluir: Manejo de versiones de software Seguimiento de dependencias y gestin de cambios Gestin de requisitos Gestin de configuracin Seguimiento de una auditoria

87

UNIDAD N 11: Gestin de Configuracin.

La Gestin de Configuracin de Software (GCS) es un conjunto de actividades desarrolladas para gestionar los cambios a lo largo del ciclo de vida del software de computadora. La GCS es una actividad de garanta de calidad del software que se aplica en todas las fases del proceso de ingeniera del software. La meta es maximizar la productividad minimizando los errores. Las actividades de GCS sirven para: 1. Identificar el cambio. 2. Controlar el cambio. 3. Garantizar que el cambio se implemente adecuadamente. 4. Informar del cambio a todos aquellos a los que les interese. Es importante distinguir claramente entre el mantenimiento del software y la gestin de configuracin de software. El mantenimiento es un conjunto de actividades de ingeniera del software que se producen despus de que el software se ha entregado al cliente y est en funcionamiento. La gestin de configuracin del software es un conjunto de actividades de seguimiento y control que comienzan cuando se inicia el proyecto de desarrollo del software y termina slo una vez que queda fuera de circulacin. Uno de los objetivos principales de la ingeniera del software es mejorar la facilidad con la que se pueden implantar los cambios y reducir la cantidad de esfuerzo necesario para implementarlos. Los elementos de configuracin de software (ECS) componen toda la informacin producida como parte del proceso de ingeniera de software, que colectivamente se denominan configuracin del software. Los ECS se pueden clasificar en tres amplias categoras: 1. Programas de computadoras, tanto en forma de cdigo fuente como ejecutable. 2. Documentos que describen los programas de computadora, tanto tcnicos como de usuario. 3. Datos, contenidos en el programa o externos a l. El cambio de cualquier ECS se puede producir en cualquier momento del ciclo de vida del sistema y por cualquier razn. Hay cuatro fuentes fundamentales de cambios: Nuevos negocios o condiciones comerciales que dictan los cambios en los requisitos del producto o en las normas comerciales. Nuevas necesidades del cliente que demandan la modificacin de los datos producidos por sistemas de informacin, funcionalidades entregadas por productos o servicios entregados por un sistema basado en computadora. Reorganizacin y/o reduccin del volumen comercial que provoca cambios en las prioridades del proyecto o en las estructuras del equipo de ingeniera de software. Restricciones presupuestarias o de planificacin que provocan una redefinicin del sistema o producto.

88

Lneas Base Una lnea base es un concepto de gestin de configuracin del software que ayuda a controlar los cambios. Una lnea base se define como una especificacin o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ah en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a travs de procedimientos formales de control de cambios. Antes de que un ECS se convierta en una lnea base, los cambios sobre ese ECS se pueden llevar a cabo rpida e informalmente. Una vez que se establece una lnea base, se pueden llevar a cabo los cambios, pero se debe aplicar un procedimiento formal para evaluar y verificar cada cambio. En el contexto de la ingeniera de software, definimos una lnea base como un punto de referencia en el desarrollo del software que queda marcado por el envo de uno o ms elementos de configuracin de software y la aprobacin del ECS obtenido mediante una revisin tcnica formal. Aunque se pueden definir las lneas base con cualquier nivel de detalle, las lneas base ms comunes en la ingeniera de software son:

Los ECS producidos por la ingeniera del software se revisan y una vez aprobados se colocan en una base de datos de proyecto, y se convierten en una lnea base del proyecto. Cuando del equipo de ingeniera de software quiere hacer modificaciones en un ECS de lnea base puede hacerlo slo si se siguen los controles de GCS.

El Proceso de GCS
La responsabilidad principal del GCS es el control de cambios. Sin embargo, tambin es responsable de la identificacin de los ECS individuales y de las distintas versiones del software, de las auditorias de la configuracin del software y de la generacin de informes sobre todos los cambios realizados en la configuracin.

89

Identificacin de Objetos en la Configuracin de Software

Para controlar y gestionar los elementos de configuracin, se debe identificar cada uno de forma nica t luego organizarlos mediante un enfoque orientado a objetos. Los objetos evolucionan a lo largo del proceso de ingeniera del software. El grafo de evolucin describe la historia de los cambios de un objeto. Por ejemplo, el objeto de configuracin 1.0 pasa la revisin y se convierte en el objeto 1.1

Control de Versiones
El control de versiones combina procedimientos y herramientas para gestionar las versiones de los objetos de configuracin creadas durante el proceso de ingeniera de software. La gestin de configuracin permite a un usuario especificar configuraciones alternativas del sistema de software mediante la seleccin de las versiones adecuadas. Esto se puede gestionar asociando atributos a cada versin del software y permitiendo luego especificar (y construir) una configuracin describiendo el conjunto de atributos deseado. Los atributos que se mencionan pueden ser tan sencillos como un nmero especfico de versin asociado a cada objeto o tan complejo como una cadena de variables lgicas (indicadores) que especifiquen tipos de cambios funcionales aplicados al sistema. Una representacin de las diferentes versiones de un sistema es el grafo de evolucin. Cada nodo del grafo es un nodo agregado, es decir, una versin completa del software. Cada versin del software es una coleccin de ECS y cada versin puede estar compuesta de diferentes variantes.

Control de Cambios
El control de cambios combina los procedimientos humanos y las herramientas automticas para proporcionar un mecanismo para el control del cambio. Se hace una peticin de cambio y se evala para calcular el esfuerzo tcnico, los posibles efectos secundarios, el impacto global sobre otras funciones del sistema y los costes estimados. Los resultados de la evaluacin se presentan como un informe de cambios a la autoridad de control de cambios (ACC). Un ACC es una persona o grupo que toma la decisin final del estado y la prioridad del cambio. Para cada cambio aprobado se genera una orden de cambio de ingeniera (OCI). La OCI describe el cambio a realizar, las restricciones que se deben respetar y los criterios de revisin y auditoria. El objeto a cambiar es dado de baja de la base de datos del proyecto; se realiza el cambio y se aplican las adecuadas actividades de SQA. Luego, el objeto es dado de alta en la base de datos y se usan los mecanismos de control de versin apropiados para crear la siguiente versin del software. Los procesos de alta y baja implementan dos elementos importantes del control de cambio: Control de Acceso: Gobierna el derecho de los ingenieros del software a acceder y modificar objetos de configuracin concretos. Control de Sincronizacin: Asegura que los cambios en paralelo, realizados por personas diferentes no se sobrescriben mutuamente.

Estndares de GCS
Toda organizacin debe implementar un GCS, como el de lnea base, o implementar uno propio para la empresa, que debe ser un estndar para todos los proyectos dentro de la organizacin.

90