REVISIONES ESTRUCTURADAS (WALKTROUG)
Anuncio
REVISIONES ESTRUCTURADAS (WALKTROUG) Es un nombre dado a una serie de revisiones, cada una de ellas con diferentes objetivos, hechas durante las distintas fases del desarrollo de un programa. Pueden llevarse a cabo durante la siguientes fases : − Después del desarrollo de las especificaciones. − Después del diseño del programa. − Después de que el test de prueba y sus datos estén preparados. Clases de − Especificaciones − Diseño − Test de prueba y test de datos − Instrucciones para usuario Desarrollo_de_una_Revisión_estructurada 1º Inicio. Cuando el programador está preparado. 2º Invitación: de 2 a 6 compañeros, se trabaja en grupo no individualmente. 3º Guía: 48 horas antes se entrega a los participantes una guía con los datos necesarios. ___________________________________________ | Cabecera | Fecha Autor programa.Fecha de reunión,lu− Información | gar, nombre−programa,tipo Walktroug(Dise− | ño). | Materiales | Especificaciones,VTOC,Entradas/Salidas 1 Adjuntos | IPOS | Objetivos | Completen PSS de logic,nombres significa− | tivos y consistentes | Participan− | tes | |________________________________________ 4º Copias: Entregar todo el material a revisar 5º No personal directivo. Intentamos encontrar errores no evaluar 6º Reunión: Lista de errores encontrados No búsqueda solución Solución posterior por el autor Lista de acciones 7º Reunión − Se selecciona un componente como moderador y a otro (o el mismo) como secretario. − Se persigue detectar, no corregir errores. El autor puede dar una pequeña introducción de su trabajo. − Cuando se encuentre un punto conflictivo el programa− dor debe explicarlo y comprobar si es un error. − No se discutirán los errores triviales. − Todos los miembros habrán buscado antes de la reunión los puntos conflictivos Después 2 − El programador responde a los problemas, proporcionando las soluciones a los problemas. − Si hay un error mayor habrá que rehacer el material y convocará una nueva reunión. − Cada vez que se haga un Walktroug, se enviará una notificación al personal directivo a cargo del proyecto. Puntos a tener en consideración para que el Walktroug sea e− fectivo 1º Personal directivo no presente 2º Sólo detección de errores 3º Dos horas de tiempo limite 4º Participantes adecuados (reales y potenciales) 5º Máximo interés en la participación (conocimiento del sistema) 6º Dar a conocer los resultados (aprendizaje) 7º No usar para evaluar programador. Lista_de_acciones ¿Es el nombre del módulo 120 Cambio de 'Proceso regis− significativo? tro ventas' a 'Producir línea Salida' Inconsistencia en el uso de Cambiar todo a TRAN TR y TRAN Las_revisiones_periódicas_son_necesarias_para: − Punto actual VS plan establecido. − Control áreas especificas. 3 − Se posponen por rechazo a la revisión (efecto psicológico) − No diseñados para sustituir las revisiones necesarias para un proyecto − Diseñadas para: − Complementar: pasar controles de calidad periodi− camente − Herramienta de trabajo para: Analista −−−−> Jefe de programación: debe conocer al personal al que se adjudican los trabajos Programadores −−−−> aprenden Personal directivo: supone que el proyecto va bien. Primer_impacto_de_la_revisión − No son bien acogidas − Pérdida de tiempo. Explicar el trabajo a gente inexperta. − Sirve de evaluación: se cree que ponen nota Una_revisión_estructurada_para_las_organizaciones 1.− Motivación positiva para el equipo que realiza el proyecto − Todos saben − Proyecto de todos VS actitud egoísta. Todos los módulos deben funcionar bien,no importa quien lo haya hecho, tiene que funcionar todo bien. − Capitalización (individual y organización).Mis 4 conocimientos están al servicio de la organiza− ción 2º.− Aprendizaje y excelente manera de ganar experiencia 3º.− Herramienta para analizar el diseño funcional del sistema 4º.− Medio de descubrir errores lógicos en el diseño. In− cluso de omisión. 5º.− Manera de eliminar errores de codificación antes de que entren en el sistema. 6º.− estructura para implementar una estrategia de che− queo PROYECTO INFORMATICO Informática no sólo es hacer programas. Actividades que reunen unas características especiales como: − Volumen considerable − Transcendencia. Importancia − Riesgo acentuado para la organización.Coste económico. − Falta de habitualidad − Necesidad de integrar diferentes especificacio nes. En función de la fase que se encuentre determinaremos los recursos humanos. Frente a: " Tareas( actividades) rutinarias" Que suelen afectar al trabajo del día a día, pues tienen un carácter más urgente. 5 − Se impone frente a proyectos (+ Importantes − urgentes) − Consumen tiempo y recursos (70%). Personas paradas en mantener los programas. − Por ellas los proyectos se retrasan y aumentan los costes: − Calendario − costes − Efectos psicológicos: son más cómodas y reposadas Mayor riesgo y dureza Activo_del_CPD − Horas humanas.Recursos, las horas que se pierden no se recuperan − Recursos técnicos. Ordenadores y metodologías,etc. − Software desarrollado. Se deduce: Programación: último eslabón de la cadena Que hay antes − Análisis de requerimientos − Diseño del Software − Programación Después: − Pruebas − Estrategias Un_sistema_informatico.Concepto de Sistemas − Se usa en muchas disciplinas/áreas 6 − Hay muchas definiciones − Todas tienen cualidades comunes − Elementos − Entornos − Iteración entre sus elementos y el entorno − Tiene objetivos que alcanzar. Una definición de sistemas: Un conjunto organizado de − Personas − Maquinas − Procedimientos − Documentos − Datos − Otras cosas (entes) Interactivados unos con otros, así como con el en− torno para alcanzar unos objetivos predefinidos Definición de subsistema: Parte de un sistema mayor, que se denomina suprasistema. Cosas fundamentales dentro del sistema Datos (100) Información (100º) Conocimientos (el agua hierve a 100º) Mensaje: Un grupo de caracteres que son almacenados, procesados y transmitidos en un sistema de información de una organiza− ción 7 Así pues los mensajes en una organización tienen diferente significado según lleven : datos, información o conocimiento. Un sistema de información: debe proporcionar información, dónde y cuando y a que nivel debe dar información Un sistema de Información debe estar en consonancia con los objetivos de la organización S.I.: conjunto interrelacionado lógicamente de procesos de Negocios para alcanzar los objetivos de la organización Requerimientos y características de la Información en un SI Requerimientos 1.− Entendida por el receptor en el marco de referen− cia adecuados 2.− Relevante para las necesidades( Proceso toma decisiones) 3.− Nueva 4.− Conduce a toma de decisiones (no ación) Atributos − Correcta entrada − Seguridad de integridad − Flexibilidad − Dar satisfacción al usuario La Información debe estar asociada a tres niveles, que dan lugar a tres tipos básicos de operaciones: − Proceso de transacciones − Control − Planificación estratégica Considerada esta relación el S.I. se puede subdividir en 2 subsistemas 8 /|\ Ejecutivo Planificación | ________________________________ | | Control | ______________________ Control Nivel actividades | Superior | Control operacional | ____________________________________ _________\|/_________ || Operaciones |Transacciones| Niveles operativos Personales |____________| − MIS: Subsitema relativo al manejo (gestión) de decisiones para propósitos de control y planificación estratégica − OIS: Subsistema referido al proceso de las transacciones,se conoce como CPD. El MIS se divide en MIS DSS Tema: 1 −− INGENIERIA DEL SOFTWARE Características de lo que ha motivado la aparición de la INGENIERIA DEL SOFTWARE, razones − Los ordenadores datan de los años 50, se veían como algo grande y extraño, se compraban por prestigio, y se ejecutaban procesos muy específicos: clasificacio− 9 nes, listados, es decir funciones muy concretas y se hacía el programa para ese problema − El Hardware ha ido bajando de precio, lo que aumentó la demanda de informáticos − El coste de hoy en día es de 80% Software y 20% de Har− dware, en un sistema − Nos encontramos rigidez frente a la informalidad − Los programas para sistemas: debido a la rigidez de es− tos, se tarda a veces en confeccionar el programa más que para un PC aislado − Cuanto mas complejo es el sistema, más difícil su com− prensión intelectual − Los sistemas son dinámicos y evolucionan en el tiempo − Los grandes sistemas necesitan técnicas mas formales de especificación y diseño Un programa sigue las siguientes fases: − Especificar − Diseñar − Instrumental (No siempre necesaria, pues se puede pro− bar sin instrumentalización) − Pruebas Especificación: El análisis de las necesidades del cliente. Las especificaciones es un contrato entre el usuario y el técnico, un documento único. Cuando se especifica ya se empieza a trabajar en las pruebas del sistema, sin que el sistema esté construido. 10 La construcción de grandes sistemas ,por no utilizar metodo− logía adecuada nos lleva: − Grandes retrasos ( Curva−aprendizaje) − Altos Costes: no quiere decir que haya que haber grandes−retrasos, o que grandes retrasos den grandes costes − Escasa fiabilidad − Escaso rendimiento − Gastos de mantenimiento: valen más que el sistema, por el dinamismo y evolución del sistema Por tanto: Nuevas técnicas Nuevas Metodologías IS (BOTTEM): incluye la aplicación práctica del conocimiento científico en el diseño y construcción de programas para computadoras y la documentación asociada requerida para desa− rrolarlos, operarlos y mantenerlos. El diseño debe incluir A.R. y rediseño durante modifica− ción IS (IEE83 Standard Glossary of Sotfware engineering): Como el enfoque sistemático para el desarrollo, opera− ción, mantenimiento y eliminación del software. Definiendo Software como : Aquellos programas, procedimientos, reglas y documen− tación posible asociada con la computación, así como los da− tos pertenecientes a la operación de un sistema de computa− 11 ción Las metas son − Aumento calidad productos − Aumento productividad − Satisfacción profesional Que abarca el término Software − Programas − Documentación − Instalar | | − Usar | Para un amplio espectro > − Desarrollar | (usuarios) | − Mantener | (Componentes ejecutables y no ejecutable) Grandes sistemas − Programas y documentación reparten esfuerzos Cualidades del Ingeniero del Software − Técnicas − Técnicas de computación − No técnicas | Usuarios − Comunicación < | Técnicos − Oral 12 − Escrita − Administrativo (Control) − Tiempo − Costes Así pues la diferencia entre la ingeniería del Software y la programación tradicional consiste en la utilización de técni− cas de ingeniería, para − Especificar − Diseñar − Instrumentar − Validar − Mantener En tiempo y coste para un proyecto, así como la inciden− cia en aspectos administrativos. Producto de programación incluye − Código fuente − Manuales asociados − Documentación propia del producto − Manual de requisitos − Especificaciones de diseño − Código fuente − Planes de prueba Aproximación_al_ciclo_de_vida_del_software Los grandes sistemas tienen un denominador común: − Necesitan mucho tiempo para su desarrollo − Funcionaran mucho más tiempo 13 Hay muchos modelos. Un marco sería − Análisis y definición de necesidades − Objetivos, rendimientos y restricciones del usuario − Diseño del sistema y del Software − Necesidades de Wardware y software − Representación de funciones − Aplicación y pruebas de Unidades − D.S. como conjunto de programas − Pruebas de los programas − Pruebas del sistema − Integración y pruebas del sistema, asegura cubrir necesidades − Operación y mantenimiento − Pueden ser las mas largas − Corregir, mejorar,aumentar Convine diferenciar Ciclo desarrollo Sotfware Ciclo vida Software Verificación : se esta construyendo correctamente Validación : se esta construyendo el producto correcto Hablemos_de_costes | | _________________________________ COSTE | | |___________________________________ 14 Sistemas comerciales * BOEHM (75) (81) RESTO Necesidades/diseño ..... 44% 44% 46% Aplicación ............. 28% 26% 20% Pruebas ................ 28% 30% 34% CIENTÍFICO DE CONTROL SOFTWARE * Sin operación y mantenimiento (éste supera el coste al desarrollo) Mantenimiento puede ser − Aumentativo − Adaptativo Para reducir mantenimiento y como consecuencia reducir el cos− te del ciclo de vida es necesario una mejor (óptima) defini− ción de necesidades Porque hay que mantener el software − Porque los sistemas son dinámicos: − Por entorno y la comprensión del medio, los cuales son dinámicos en el tiempo Las reglas de la evolución del sistema − Cambio continuo: o se cambia el sistema o cada vez es mas antiguo − Complejidad creciente : la evolución del software im− plica estructuras mas complejas, si no se aplican téc nicas nuevas, estamos a base de parches 15 EVOLUCION DEL SOFTWARE Grandes sistemas son dinámicos − Entorno | > Evolutivos − Comprensión del medio | La evolución del sistema esta sujeta a leyes determinadas por observación experimental (LEHMAN 76) 1.− Cambio continuo: cambio útil 2.− Complejidad creciente − Evolución Software implica estructuras más com− plejas o se evita. 3.− Evolución del programa − Proceso autorregulador − Medición de atributos del sistema − Tamaño − Tiempo entre versiones − Nº de errores 4.− Conservación de la estabilidad organizativa − Desarrollo casi constante e independiente La evolución del software esta ligada a la del Hardware Un mejor rendimiento del Hardware, un tamaño mas pequeño y un coste mas bajo, han dado lugar a sistemas informáticos mas so− fisticados. La evolución del Hardware se ha denominado como "la nueva re− volución industrial" que dará paso a " La sociedad de la in− formación 16 4 etapas en la evolución del Software primeros años La segunda era La tercera era La cuarta era *Orientación *Multi−usuario *Sistemas dis− *Sistemas ex− por lotes *Tiempo−real tribuidos pertos *Distribución *Bases de datos *Inteligencia *Máquinas de limitada *Producción de edmpotrada Int. Artif. *Software a Software *Hardware de *Arquitecturas medida bajo coste paralelas *Impacto en el consumidor _____________________________________________________________ 1.950 1.960 1.970 1.980 1.990 2.000 1ª Etapa − EL Hardware sufrió continuos cambio, mientras que el sof− tware se veía simplemente como un añadido − La programación de computadoras era un arte de andar por casa: No existen métodos,herramientas, técnicas, planifi− ción, control. − El software se realizaba prácticamente sin ninguna plani− ficación, aunque empiezan a aparecer algunos deslices en los costes o planificación. − Se utiliza en la mayoría de los sistemas una orientación por lotes − La mayor parte del Hardware se dedicaba a la ejecución de un único programa que a su vez se dedicaba a una aplica− ción específica. 17 − El software se diseñaba a medida para cada aplicación y tenía una distribución relativamente pequeña − La mayoría del software se desarrollaba y utilizaba por la misma persona u organización. − Debido a esto la misma persona lo escribía, lo ejecutaba y si fallaba lo depuraba − Debido a que la movilidad en el trabajo era baja, los eje cutivos estaban seguros de que esa persona estaría allí cuando se encontrara algún error − Debido e este entorno personalizado del software, el dise ño era un proceso implícito, ejecutado en la cabeza de al guien y la documentación no existía normalmente 2ª Etapa − La multiprogramación, los sistemas multiusuarios, introdu jeron nuevos conceptos de interacción hombre−máquina − La técnicas interactivas abrieron un nuevo mundo de apli− caciones y nuevos niveles de sofisticación del hardware y software. − Los avances en los dispositivos de almacenamiento en lí− nea, condujeron a la primera generación de sistemas de gestión de base de datos. − Se caracterizó por el uso del software como producto y llegada de las "casas de software" − Conforme creció el número de sistemas informáticos, comen zaron a extenderse las bibliotecas de Software de computa doras 18 − Los productos software comprados al exterior añadieron cientos de miles de nuevas sentencias − Todas estas sentencias fuente, tenían que ser corregidas cuando se detectaban fallos, se modificaban por cambios en los requerimientos del usuario o se adaptaban a un nuevo hardware que se había comprado. − Estas actividades se llamaron colectivamente mantenimien− to del software. − El esfuerzo gastado en el mantenimiento del Software comen zo a absorber recursos en una medida alarmante − La naturaleza personalizada de muchos programas los hacía virtualmente imposibles de mantener − Había comenzado una crisis del software 3ª Etapa − Comenzó a mediados de los 70 y continua hoy − El sistema distribuido incrementó notablemente la comple− jidad de los sistemas informáticos − La creciente demanda de acceso instantáneo a los datos, supusieron una fuerte presión sobre los desarrolladores de software − Se caracterizó también por la llegada y amplio uso de los microprocesadores y computadores personales − El microprocesador, es una parte integral de un amplio espectro de productos: automóviles, hornos microondas,ro− bots industriales etc. − Las computadoras personales han sido la catálisis para el 19 crecimiento de muchas compañías de software. − Distribución de software en cientos de miles − El Hardware se ha convertido en las computadoras persona− les en un producto, mientras el software marca la dife− rencia. 4ª Etapa − Está ahora comenzando − Técnicas de la cuarta generación para el desarrollo de software − Los sistemas expertos y el software de inteligencia arti− ficial se han trasladado del laboratorio a aplicaciones prácticas − Conforme nos movemos en la cuarta era, continua intensi− ficándose la crisis del Software. − Ahora podemos describirla como 1: La sofisticación del hardware ha dejado atrás nues tra capacidad de construir software que pueda ex− plotar el potencial del hardware 2: Nuestra capacidad de construir nuevos programas no puede descansar, debido a la demanda de nuevos pro gramas. 3: Nuestra capacidad de mantener los programas exis− tentes está amenazada por el mal diseño y el uso de recursos inadecuados − Como respuesta a la crisis del software aparece la Inge− niería del software. 20 CARACTERISTICAS DEL SOFTWARE Cuando se construye el hardware el proceso creativo humano se traduce finalmente en una forma física El Software es un elemento lógico en vez de físico del siste− ma., luego tiene características considerablemente distintas de las del hardware − El software es desarrollado , no es fabricado en el sentido clásico. Existen algunas similitudes entre el desarrollo del software y la construcción del hardwarrje, pero las dos actividades son fundamental diferentes En ambas, la buena calidad se adquiere median− te un buen diseño, pero la fase de construcción del hardware puede producir problemas de calidad que no existen o son fácilmente corregibles en el Software Ambas actividades, requieren la construcción de un producto, pero los métodos son diferentes. − Los costes del software se concentran en la ingenie− ría. Esto significa que los proyectos no pueden ser gestionados como si fueran proyectos de fabricación. El concepto de fábrica de software recomienda el uso de herramientas automáticas para el desarrollo del software − El Software no se deteriora Propor− /|\ | ción de | Mortandaz | infantil Deterioro 21 fallos | | |________________________________________\ tiempo / La figura representa la proporción de fallos como una función del tiempo , para el Hardware. La relación se llama frecuentemente, la curva de bañera, e indica que el hardware exhibe relati− vamente muchos fallos al principio de su vida. Estos fallos son atribuidos frecuentemente a defectos de diseño o de fabricación. Cuando se corrigen los defectos, caen los fallos hasta su nivel más bajo, en donde permanecen estacio narios durante un cierto periodo de tiempo Sin embargo , conforme pasa el tiempo, los fa− llos vuelven a presentarse conforme las componentes hardware sufren los efectos de los males externos y comienza a deteriorarse El software no es susceptible de males del entor− no como los que hacen que el hardware se deteriore, por lo tanto, en teoría la curva de fallos del Soft− ware tendrá la forma: Propor− /|\ | Continua en la misma cion de | proporción hasta que | queda obsoleto. 22 fallos | | |________________________________________\ tiempo / Los defectos no descubiertos harán que falle du− rante las primeras etapas de la vida del programa Una vez que estos se corrigen, suponiendo que no introduzcan nuevos errores, la curva se aplanará. Esta figura es una gran simplificación de los modelos reales de fallos del Software. Sin embargo el software no se rompe, pero se deteriora. Esta contradicción puede comprenderse mejor con− siderando la figura Propor− /|\ | ción de | curva real | fallos | | | | curva ideal | |_________________________________________\ tiempo / Durante su vida el software sufre cambios(mante− nimiento). Conforme se hacen cambios, es probable 23 que se introduzcan nuevos defectos, haciendo que la curva de fallos tenga picos Antes de que la curva pueda volver al estado estacionario original, se solicita otro cambio, haciendo que de nuevo se cree otro pico. Lentamente el nivel mínimo de fallos comienza a a crecer, el software se va deteriorando debido a los cambios. − Cuando una componente hardware se deteriora, se sus− tituye por una pieza de repuesto. No hay piezas de repuesto para el software Cada fallo en el software indica un error en el diseño o en el proceso mediante el que se tradujo el diseño en Código máquina ejecutable Por tanto el mantenimiento del software supone una complejidad considerablemente mayor que el mante− nimiento del hardware. − La mayor parte del Software se construye a medida,en vez de ensamblar componentes existentes. Ingeniería del software para − Mejorar rendimiento − Mejorar pruebas − Satisfacción del cliente COMPONENTES DEL SOFTWARE El software de computadora es información que existe en dos formas básicas − Componentes no ejecutables en la máquina 24 − Componentes ejecutables en la máquina Todas las componentes del software contienen una configura− ción El diseño del software se traduce a − Un lenguaje que especifica la estructura de datos del software − Los atributos procedimentales − Los requerimientos relacionados Todos los lenguajes de programación son lenguajes artificia− les Las clases de lenguajes que son componentes del software se caracterizan como − Lenguajes a nivel máquina − Lenguajes a alto nivel − Lenguajes no procedimentales APLICACIONES DEL SOFTWARE El software puede aplicarse en cualquier situación en la que se haya definido previamente un conjunto especifico de pasos procedimentales (es decir un algoritmo). Los factores importantes para determinar la naturaleza de una aplicación software son: − La determinación de la información − El contenido de la información El contenido se refiere al significado y la forma de la infor mación de llegada y salida. La determinación de la información se refiere a la necesidad 25 de predecir el orden y tiempo de llegada de los datos Así hay aplicaciones determinadas e indeterminadas siendo es− tas últimas aquellas que tienen como características: − Acepta entradas que tienen un contenido variado y se producen en un tiempo arbitrario − Ejecuta algoritmos que pueden ser interrumpidos por condiciones externas − Produce una salida que depende de una función del entorno y del tiempo Una aplicación determinada − Acepta datos que están en un orden predefinido − Ejecuta un algoritmo sin interrupciones − Produce datos resultantes en formato predefinido Las siguientes áreas del software indican la amplitud de las potenciales aplicaciones 1º Software de sistemas − Es una colección de programas escritos para servir a otros programas − El área del software de sistemas se caracteriza por: − La fuerte interacción con el hardware de la computadora − Su gran utilización por múltiples usuarios − La operación concurrente que requiere plani− ficación − Compartimentación de recursos 26 − Sofisticada gestión de procesos − Estructura de datos complejas − Múltiples interfaces externas 2º Software de tiempo real − El Software que mide, analiza, controla sucesos del mundo real conforme ocurren, se llama de tiempo real − Los elementos del software de tiempo real inclu− yen: − Una componente de acumulación de datos que recolecta y formatea la información de un entorno externo − Una componente de análisis que transforma la información según requiera la aplicación − Una componente de control/salida que respon da al entorno externo − Una componente de monitorización que coor− dina a todas las demás componentes de forma que puedan mantener la respuesta en tiempo real (tipicamente en el rango de 1 milise− gundo a 1 minuto). 3º Software de gestión − Referido al procesamiento de la información co− mercial. − Los sistemas discretos han evolucionado hacia el software de sistemas de información de gestión, 27 que acceda a una o mas bases de datos grandes que contienen la información comercial − Características de las aplicaciones en esta área: − Restructuran los datos existentes en orden a facilitar las operaciones comerciales o gestionar la toma de decisiones − Realizan cálculo interactivo 4º Software de ingeniería y científico − Se ha caracterizado por los algoritmos de manejo de números − Las nuevas aplicaciones del área de ingeniería/ científica se han alejado de los algoritmos convencionales numéricos. − El diseño asistido por computadora, la simulación de sistemas y otras aplicaciones interactivas, han comenzado a tomar caracteristicas del softwa− re de tiempo real e incluso de sistemas 5º Software empotrado − Se utiliza para controlar productos y sistemas de los mercados industriales y de consumidores − Características − Reside en memoria de sólo lectura − Puede ejecutar funciones muy limitadas y esotéricas (eje. control de teclas de un horno) − Suministrar una función significativa 28 − Capacidad de control 6º Software de computadoras personales − Es uno de los diseños del software más innovati− vos en el campo del software. − Entre sus múltiples aplicaciones esta − Tratamiento de textos − Hojas de calculo − Gráficos − Entretenimientos − Gestión de base de datos − Aplicaciones financieras,comerciales y per− sonales − Redes externas o acceso a base de datos 7º Software de inteligencia artificial − Hace uso de algoritmos no numéricos para resolver problemas complejos que no son adecuados para el el cálculo o análisis directo − Actualmente el área mas activa es la de los sis− temas expertos, también llamados sistemas basados en el conocimiento − Otras áreas de aplicación − Reconocimiento de patrones − Prueba de teoremas − Juegos FACTORES DE TAMAÑO Esfuerzo_dedicado_al_software 29 Dinero dedicado a computación (U.S.A.) AÑO 80 5% PNB AÑO 2,3% PNB AÑO 90 12,2% PNB Hardware Software AÑO 60 80% 20% AÑO 80 20% 80% AÑO 90 10% 90% | | | Desarrollo productos P. | | | | Mantenimiento Productos | Programación |___________________________________________________ 1.955 1.978 1.985 Distribución del esfuerzo (Desarrollo−Mantenimiento) Producto Software 1 a 3 años desarrollo 5−15 de vida | | _________ | | 36% | ||| |_____ _______ | | | 16% | | 16% |________| |_________ 30 | |________| | 12% | | 12% | | | 8% | | | | | |_____|________|_____|________|_______|________|____ /|\ /|\ |_____Mantenimiento(60%)__| Deducciones 1º.− Las actividades de mantenimiento gastan más recursos que actualmente el desarrollo 2º.− Gran parte del esfuerzo gastado es la mejora del producto 3º.− La actividad de prueba equivale al 50% fase de desarrollo 4º.− Actividad de prueba ,mejora,adaptación equiva− le al 75% ciclo de vida producto Conclusión Objetivo del análisis, diseño, intrumentación sera aliviar las tareas de pruebas y mantenimiento Clasificación_en_base_al_tamaño El tamaño determina − Nivel de control administrativo − Tipo de herramientas − Técnicas necesarias Según YOUR DON 75 CATEGORIA Nº_PROGRAMADORES DURACION TAMAÑO PRODUCTO TRIVIAL 1 1−4 S 500 L/C 10 − 20 Subpro. 31 − No requiere excesiva formalidad en análisis, documentación, diseño, pruebas,aunque se me− jora aplicando técnicas PEQUEÑO 1 1−6 M 1K − 2K 25 − 50 Subpro. − Normalmente no tiene iteración con otros pro− gramas − Poca interación entre programadores − Poca interación entre programadores y cliente CATEGORIA Nº_PROGRAMADORES DURACION TAMAÑO PRODUCTO MEDIANOS 2 − 5 1− 2 A 5K − 50K 250−1000 Sub − Son la mayoría de los proyectos − Interacción entre los programadores − Interacción entre los programadores y cliente − Formalidad en − Planificación − Análisis y diseño − Documentación − Revisión del producto CATEGORIA Nº_PROGRAMADORES DURACION TAMAÑO PRODUCTO GRANDE 5 − 50 2 − 3 A 50K − 100K − Comprenden varios subsistemas − Mucha iteración con otros subsistemas − Problemas de comunicación entre programadores /gestores/clientes 32 − Pude ser necesario varios grupos de progra− madores − Posibilidad de alta rotación en personal − Es esencial − Procedimientos sistematizados − Documentación estandard − Revisiones formales CATEGORIA Nº_PROGRAMADORES DURACION TAMAÑO PRODUCTO MUY GRANDES 100 − 1.000 4− 5 A 1 M − Varios susbsistemas y cada uno implica un pro− yecto grande − Subsistemas interrelacionados complejamente entre ellos y con otros subsistemas − Formalidad estructura EXTREMADAMENTE 2.000−5.000 5−10 A 1M − 10M GRANDES − Implican igual que los muy grandes − Tiempo real − Comunicaciones − Multitareas y procesos distribuidos − Frecuentemente requisitos de confiabilidad Utilización_del_Tiempo_de_los_programadores Estructuras de programas( 135 y 17% del tiempo del día) Lectura de manuales y programas Comunicaciones de trabajo Usos personales 33 Varios Entrenamiento Correo La_productividad_se_puede_medir − Lineas Código/mes − Páginas documentación por programa/mes − Casos prueba escritos y ejecutados programa/mes Factores_de_calidad_y_productividad − Se aumenta al mejorar los procesos (actividades) − Necesarias para el desarrollo y mantenimiento de los productos − Implican la necesidad de actividades sistemáticas: − Capacidades individuales − Comunicaciones en el grupo − Complejidad del producto − Notaciones apropiadas − Enfoques sistemáticos − Control de cambios − Nivel tecnológico − Tiempo disponible − Nivel confiabilidad − Especialización requerida − Facilidades y recursos − Entretenimiento adecuado − Habilidades gerenciales − Metas apropiadas 34 − Expectativa creciente − Otros factores − Control de Cambios ; comisión que determina cuando se debe realizar un cambio, y evaluar estos. Conceptos_sobre_administración_de_productos − Tanto las actividades técnicas como las gerenciales son necesarias para el éxito de un proyecto − El Gerente controla los recursos y actividades técnicas, son los últimos responsables de que el producto se entregue: − Coste previo − Funcionabilidad y calidad que exige el cliente − Tiempo − Actividades del gerente − Contratación de proyectos − Contratación de personal − Confección plan de trabajo − Desarrollo de estrategias de mercado − Gerente se encarga de la administración y comprende: − Organización − Seguimiento del proyecto − Estimación de costes − Control del presupuesto − Definición de logros del proyecto − Determinación del avance del proyecto − Reasignación de recursos 35 − Ajuste del calendario del proyecto − Establecer procedimientos de control de calidad − Comunicación entre miembros del proyecto − Acuerdos contractuales con los clientes − Observancia términos legales y contractuales LA CRISIS DEL SOFTWARE − Se refiere a los problemas encontrados en el desarrollo del software de computadoras − Los problemas no están limitados al software que no funcio− na − Sino que la crisis del software abarca los problemas aso− ciados con: − Como desarrollar el software − Técnicas − Herramientas − Métodos − Como mantener un volumen creciente de Software existente − Como podemos esperar satisfacer la demanda crecien− te de software − Hay muchos problemas, los más importantes: (1) La planificación y estimación de costes es fre− cuentemente muy imprecisa (2) La productividad de la gente del Software no co− rresponde con la demanda de sus servicios (3) La calidad del software no llega a ser a veces ni 36 adecuada − Estos problemas son debidos a: − Se ha sufrido el sobrepasar los costes en orden de magnitud − Se ha errado en la planificación en meses o años − Se ha hecho muy poco para mejorar la productividad de los trabajadores en software − Los errores de los nuevos programadores producen en los clientes insatisfacción y falta de confianza − Tales problemas son sólo las manifestaciones mas visibles de otras dificultades del Software: − No tenemos tiempo de recoger datos sobre el proce− so de desarrollo del software − Sin datos históricos como guía, la estima− ción no ha sido buena y los resultados pre− dichos muy pobres − Sin una indicación sólida de productividad no podemos evaluar con precisión la eficien− cia de las nuevas herramientas,técnicas o estandares. − La Insatisfacción del cliente con el sistema termi− nado se produce demasiado frecuentemente: − Los proyectos se acomenten frecuentemente con solo una vaga indicación de los requerimien− tos del cliente − Normalmente la comunicación entre el cliente 37 y el que desarrolla el software es muy escasa − La calidad del software es normalmente cuestionable − Se ha empezado a comprender recientemente la importancia de la prueba sistemática y tecni− camente completa del software. − Están comenzando a emerger conceptos cuanti− tativos solidos sobre la fiabilidad del Soft− ware y garantías de calidad. − El software existente puede ser muy difícil de man− tener − Las tareas de mantenimiento del software se llevan la mayor parte de los dólares invertidos en software − El mantenimiento no se ha considerado un crite− rio importante en la aceptación del software − No documentación, aspecto en el que influyen todas las contingencias del proyecto Las causas − Los problemas asociados con la crisis del software se han producido por el carácter del propio soft− are y los errores de las personas encargadas de de su desarrollo − El software es un elemento lógico en vez de físico Por tanto,el éxito se mide por la calidad de una única entidad − EL software no se rompe 38 Si se encuentran fallos,existe una alta probabi− lidad de que se introduzcan inadvertidamente durante el desarrollo y no se detectaran en la prueba − El mantenimiento incluye normalmente la corrección o modificación del diseño − El desafio intelectual del desarrollo del software es seguramente una de las causas de la crisis del software − El gestor de comunicarse con todos los componentes implicados en el desarrollo del software: − Clientes − Realizadores del Software − Equipos de soporte − Otros La comunicación puede romperse debido − A las caracteristicas especiales del soft− ware. − Los problemas particulares asociados con su desarrollo son mas comprendidos Cuando ocurre esto, los problemas asociados con la crisis del software se multiplican − Los trabajadores del software han tenido muy poco en− trenamiento formal en las nuevas técnicas de desarro llo de software. − Malos hábitos que dan como resultado una pobre calidad y mantenimiento del software 39 − Resistencia al cambio.Probablemente la causa real de la crisis del software sea que: Mientras el potencial de calculo (hardware) experimenta enormes cambios, la gente del Software responsables de aprovechar dicho potencial, se o− ponga normalmente a los cambios cuando se discuten y se resistan al cambio cuando se introduce MITOS DEL SOFTWARE − Muchas de las causas de la crisis del software pueden ser encontradas en una mitología que surge durante los primeros años del desarrollo del software − Los mitos del software propagaron información errónea y con fusión − Los mitos del software tienen varios atributos que los hacen insidiosos: − Aparecen como declaraciones responsables de hechos − Tuvieron un sentido intuitivo − Frecuentemente fueron promulgados por expertos que " estaban al día " − Surgen en los primeros años del desarrollo Mitos_de_Gestión − Los gestores están normalmente bajo la presión de cumplir presupuestos, hacer que no se retrase el proyecto y mejorar la calidad. El gestor se agarra a un mito del software aun− que tal creencia sólo disminuya la presión temporalmente Mito: ¿Porqué debemos cambiar nuestra forma de desarro− 40 llar el Software? Estamos haciendo el mismo tipo de programación a− hora que hace diez años Realidad: Aunque el dominio de la aplicación puede ser el mismo, la demanda de una mayor productividad y calidad, y el papel critico del software en obje− tivos comerciales estratégicos, ha aumentado sus− tancialmente Mito : Tenemos un libro que está lleno de estandares y procedimientos para construir software Realidad: ¿Pero se usa?,¿conocen los trabajadores su existencia?,¿refleja las practicas modernas en desarrollo del software?,¿es completo?. En muchos casos la respuesta a todas estas preguntas es no Mito : Nuestra gente dispone de las herramientas de desarrollo de software más avanzadas, después de todo les compramos las computadoras mas nuevas Realidad: Se necesita mucho más que el último modelo de computadora, herramientas de software, las cua− les son mucho mas importantes que el hardware para conseguir buena calidad y productividad. Mito: Si fallamos en la planificación podemos añadir más programadores y adelantar el tiempo perdido Realidad: El desarrollo de software no es un proceso mecá− nico como la fabricación . Añadir gente a un pro− yecto software retrasado lo retrasa aun mas. 41 Cuando se añaden nuevas personas,la necesidad de aprender y comunicarse con el equipo puede y hace que se reduzca la cantidad de tiempo gastado en el desarrollo del producto Puede añadirse gente, pero sólo de una manera planificada y bien conocida Mitos_del_cliente − Un cliente que solicita una aplicación software puede ser interno a la compañía o una compañía exterior − El cliente cree en los mitos que existen sobre el soft− ware debido a que los gestores y trabajadores responsa− sables hacen muy poco para corregir la mala Información − Los mitos conducen a que el cliente se cree una falsa expectativa y finalmente, quede insatisfecho con el de− sarrollo del software Mito: Una declaración general de los objetivos es sufi− ciente para comenzar a escribir los programas, po− demos dar los detalles más adelante Realidad: Una mala definición inicial es la principal causa del trabajo baldío en software. Una descripción for− mal y detallada del dominio de la información, funciones,rendimiento,interfaces, ligaduras de dise− ño y criterios de Validación es esencial. Estas caracteristicas pueden determinarse sólo después de una exhaustiva comunicación entre el cliente y el analista 42 Mito: Los requerimientos del proyecto cambian continuamen− te, pero los cambios pueden acomodarse fácilmente ya que el software es flexible Realidad: El impacto del cambio varia según el tiempo en que se introduzca _____________ ||| Coste | | | ||| del | | 60 − | | __________ | | Cam− | ___________ | | | 100x | bio | | 1x | | 1,5−6x | | | |__|_________|__|________|____|___________|_______ Definición Desarrollo Mantenimiento Si se pone atención en dar la definición inicial,los cambios solicitados pueden pronto acomodarse facil− ente, con relativamente poco coste Cuando los cambios se solicitan durante el diseño diseño del software, el impacto en el coste crece rápidamente. Cuando se solicita al final de un proyecto, los cam− bios pueden producir un orden de magnitud más caro que el mismo cambio pedido al principio. Mitos_de_los_realizadores − Los mitos en los que aún creen muchos programadores 43 se han fomentado durante cuatro décadas de cultura Informática − Las viejas formas y actitudes tardan en morir Mito: No hay realmente ningún metodo para el análisis,dise− ño y prueba que funcione bien, yo simplemente me voy a mi terminal y comienzo a codificar Realidad: Existen en la industria métodos comprobados para el diseño,análisis y prueba, ninguno es infali− ble, pero el uso de una metodología para el de− sarrollo del software está implícito en todos ellos Mito: Una vez que escribimos el programa y hacemos que fun− cione, nuestro trabajo ha terminado. Realidad: Mientras más pronto se comience a escribir código más se tarda en terminarlo El desarrollo del software abarca tres actividades − Definición − Desarrollo − Mantenimiento Además los datos industriales indican que entre el 50% y 70% de todo el esfuerzo dedicado a un programa se realizara después de que se le haya entregado al cliente por primera vez. Mito: Hasta que no tengo el programa ejecutándose, realmente no tengo forma de establecer calidad Realidad: Uno de los mecanismos mas efectivos para garanti− 44 zar la calidad del software puede aplicarse desde el principio de un proyecto, la revisión estructurada (Walktroug). La revisión del software es filtro de calidad que se ha comprobado que es más efectivo que la prueba, para encontrar ciertas clases de defectos en el software Mito: Lo único que se entrega al terminar el proyecto es el programa funcionando Realidad: El programa es solo una parte de una configura− cion del software, que incluye Estructuras / de datos \ /\ /\ Plan => Especificación => Diseño => Listado => Programa requerimientos \ funcionando \/ \ Especifica− / cion de Pruebas La documentación − Base para un buen desarrollo − Base para tareas de mantenimiento Mito: Una vez que el Software se está usando, el manteni− miento es mínimo y puede manejarse sobre la base de hacerlo como se pueda Realidad: La mitad de un presupuesto se gasta en manteni− 45 miento, por tanto el mantenimiento del software debe de − organizarse − Planificarse − Controlarse Como si fuera un cliente PARADIGMAS DE LA INGENIERIA DEL SOFTWARE − Son diferentes enfoques o aproximaciones para la solución de la crisis del software − Aunque hay que ser conscientes, que debido a las propias características del software y a las personas que en el trabajan (diferentes problemas,diferentes procedencias y y formación) esta no desaparezca de un día para otro − Según Fritz Bauer la ingeniería del software es: El establecimiento y uso de principios de ingenieria ro− bustos, orientados a obtener económicamente software que sea fiable y funcione eficientemente sobre máquina − La ingeniería del Software abarca un conjunto de tres elementos claves − Métodos − Herramientas − Procedimientos − Los métodos suministran el cómo construir teóricamente el el software. Abarcan una serie de tareas que incluyen − Planificación y estimación de proyectos − Análisis de los requerimientos del sistema y 46 del software − Diseño de estructuras de datos, arquitectura de programas y procedimientos algorítmicos − Codificación − Prueba − Mantenimiento − Las herramientas de la ingeniería del software suministran un soporte automático o semiautomático para los métodos. Existen herramientas para soportar cada uno de los métodos. Cuando se integran las herramientas de forma que la infor− mación creada por una herramienta pueda ser usada por otra se establece un sistema para el soporte del desarrollo del software, llamado ingeniería del software asistida por computadora − Los procedimientos de la ingeniería del software son la cola que pega a los métodos las herramientas y facilita el desarrollo racional y oportuno del software de la computadora − Los procedimientos definen − La secuencia en la que se aplican los métodos − Las entregas que se requieren (documentos,informes, formas etc.) − Los controles que ayudan a asegurar la calidad y coordinar los cambios − Las guías que facilitan a los gestores del software establecer su desarrollo 47 − La ingeniería del software está compuesta de pasos que abarcan los métodos, herramientas y procedimientos. Estos pasos se denominan frecuentemente paradigmas de la ingeniería del software − Un paradigma para la ingeniería del software se elige: − basándose en la naturaleza del proyecto y de la aplicación − Los métodos y herramientas a usar − Los Controles y entregas requeridos El_ciclo_de_vida_clásico ____________ | |_____ |Ingeniería| | | de | | |Sistemas__|___\|/_____ |________| |____ /|\ | Análisis __|__\|/___ | |__________| |______ | /|\ |Diseño __|____\|/______ | | |_______| |______ | | /|\ |Codificación _|____\|/___ | | | |_____________| |____ | | | /|\ |Pruebas __|__\|/__ | | | | |________| | | | | | | |Manteni | | | | | | |miento | 48 | | | | | |________| |||||| |||||| |_________\|/_______\|/_______\|/__________\|/_______| Ingeniería y análisis de sistemas − Comprende los requerimientos globales a nivel sistema − Contiene una pequeña cantidad de análisis y diseño a nivel superior. − Asigna un subconjunto de los requerimientos al software Ingeniería de sistemas − Ingeniería Hardware − Ingeniería Software − Define un papel para cada elemento del sistema informa− tico, lo que implica el papel del software. Análisis de los requerimientos del software − Comprende la recogida de los requerimientos de los usuarios para la construcción del sistema − Comprende entre otros − Dominio de la información − Función − Rendimiento − Interfaces − Que deben ser documentados y revisados por el cliente para su aprobación Diseño − Consiste en trasladar los requerimientos del software 49 a una representación, para garantizar la calidad antes de acometer la codificación − Se basa en un proceso multipaso que se enfoca sobre tres atributos distintos del programa: − Estructura de datos − Arquitectura del software − Detalle procidimental − Se documenta y forma parte de la configuración del software Codificación − Representa la traslación del diseño a una forma legible para la máquina − Si el diseño se realiza de una forma detallada, puede realizarse mecanicamente. Pruebas − Consiste en confirmar que el sistema funciona correctamente y produce los resultados esperados − Hay diferentes tipos de pruebas según el objetivo per− seguido Mantenimiento − Consiste en la modificación del sistema para su correcto funcionamiento en función de los requeri− mientos del momento − Se realiza una vez que el sistema pasa a explotación − Los cambios ocurrirán debido: − A que se ha encontrado errores 50 − A que el software debe adaptarse por cambios del entorno externo − A que el cliente requiere aumentos funcionales o del rendimiento − El mantenimiento del software se aplica a cada uno de los pasos del ciclo de vida, del un programa existente en vez de a uno nuevo − El ciclo de vida clásico es el mas viejo y mas ampliamente usado de los paradigmas en la ingeniería del software.Fue definido en el 70 por Royce. − Entre los problemas que presenta algunas veces, cuando se aplica el paradigma del ciclo de vida clásico se encuentran 1.− Los proyectos reales raramente siguen el flujo secuencial que propone el modelo. Siempre ocurren iteraciones y se crean problemas en la aplicación del paradigma 2.− Normalmente es difícil para el cliente establecer explícitamente al principio todos los requerimien− tos.Es necesario la duplicidad para acomodar para acomodar posibles incertidumbres. 3.− El cliente debe tener paciencia. El producto sólo se ve al final de las etapas del desarrollo del proyecto Un error importante no detectado hasta que el progra− ma esté funcionando puede ser desastroso. Construcción_de_prototipos − La construcción del prototipo es un proceso que facilita 51 al programador la creación de un modelo de software a construir − El modelo tomará una de las tres formas siguientes − Prototipo en papel que describa la iteración hombre máquina de forma que facilite al usuario la comprensión de como se produce la iteración − Prototipo que funcione que implementa algunos subconjuntos de la función requerida al software deseado − Un programa existente que ejecute parte o toda la función deseada, pero que tenga otras característi− cas que deban ser mejoradas en el nuevo trabajo de desarrollo − La secuencia de sucesos para el paradigma de Construcción de prototipos: _____________ |Recolección|___ |de requeri−|_\|/_______ |mientos_| Diseño__|__\|/______________ /|\ /|\|_Rápido| Construir___|_____\|/______ | | /|\ |_Prototipo| Evaluar y |______ | | | | | refinar los __|____\|/___ | |____|_________| |requerimientos| Producto | | | /|\ |_Construido| |||| |___________________________| |____________| 52 − Pasos de la construcción − Comienza con la recolección de los requerimientos, reunión entre el técnico y el cliente − Luego se produce el diseño rápido: − Se enfoca sobre la representación de los aspec− tos del software, visibles para el usuario − conduce a la construcción del prototipo − Construcción del prototipo − Evaluación del prototipo por el usuario /cliente El prototipo es utilizado − Refinar requerimientos de software a desarrollar − Se produce un proceso interactivo para que el prototipo satisfaga las necesidades del cliente − Facilita al ingeniero una idea clara de que hay que construir − Mecanismo para identificar los requerimientos del software − La construcción de prototipos como paradigma para la inge− niería del software puede ser problemático por: 1.− El cliente ve funcionando lo que parece ser una versión del software ,ignorando que el prototipo se ha hecho con chicle y alambres, ignora que por las prisas, no se han considerado los aspectos de calidad y mantenimiento. El usuario lo quiere de− finido. 2.− El ingeniero adopta compromisos técnicos para su 53 rápida implantación.Cuando hay que construirlo de verdad se siguen respetando dichos compromisos Técnicas_de_cuarta_generación − El término Técnicas de cuarta generación abarca un amplio espectro de herramientas software que tienen una cosa en común: todas facilitan al que desarrolla el software espe− cificar algunas características del software a alto nivel − El paradigma T4G se orienta hacia la habilidad de especi− ficar software a un nivel que sea próximo al lenguaje na− tural o en una notación que proporcione funciones signi− ficativas − Actualmente un entorno para el desarrollo del software que soporte el paradigma de T4G incluye algunas o todas de las siguientes herramientas − Lenguajes no procedimentales para : − La consulta a bases de datos − Generación de informes − Manipulación de datos − interacción y definición de pantallas − Generación de código − Capacidades gráficas de alto nivel − Capacidad de hoja de calculo − Pasos del paradigma ___________________ | |_____ |Recolección de___|___\|/_____ 54 |Requerimientos| |_____ |______________| Estrategia__|___\|/____ /|\ | de diseño |Implemen− |____ | |___________|tación u−__|__\|/__ | /|\ |sando T4G| | | | |_________|Producto| | | /|\ |________| |||| |______________|___________|________| − Empieza con la recolección de requerimientos − En aplicaciones pequeñas,puede ser posible ir di− rectamente desde el paso de establecimiento de re− querimientos, a la implementación , usando un len− guaje de cuarta generación no procedimental − El diseño es fundamental para grandes proyectos − La implementación usando Técnicas de 4G facilita al que desarrolla el software, la descripción de los resultados deseados, los cuales se traducen automáticamente en código fuente para producir los resultados − Para transformar la implementación T4G en un producto debe: − Dirigir una prueba completa − Desarrollar una documentación con sentido − Ejecutar todas las otras actividades de tran− sición requeridas para los demás paradigmas 55 − Los problemas que plantea la aplicación de T4G son entre otros 1.− Con muy pocas excepciones, el dominio de aplicación actual de loas T4G está limitado a las aplicaciones de sistemas de información comerciales, especifica− mente, el análisis de información y la obtención de informes en grandes bases de datos 2.− La recolección de datos preliminares que acompaña al al uso de T4G parece indicar que el tiempo requerido para producir software, se reduce mucho para aplica− ciones pequeñas y de tamaño medio y que la cantidad de análisis y diseño para las aplicaciones pequeñas también se reduce 3.− Sin embargo el uso de T4G para grandes trabajos de desarrollo de software, exige el mismo o más tiempo de análisis, diseño y prueba, perdiéndose así un tiempo sustancial que se ahorra mediante la eli− minación de la codificación.Produciéndose efectos negativos de poca calidad y de indiferencia del cliente. Los paradigmas vistos hasta ahora, no son sólo métodos alter− nativos, si no que también pueden ser métodos complementarios Otros_paradigmas: Desarrollo_incremental Consiste en la construcción del software para satisfa− cer pocos requerimientos inicialmente. 56 La construcción se realiza de forma que facilite la incorporación de nuevos requerimientos, alcanzando así ( el sistema) una más alta adaptabilidad. 1.− Reduce el tiempo inicial de desarrollo porque tie− ne un reducido nivel de funcionalidad 2.− El software puede ser aumentado más fácilmente y por un periodo mayor de tiempo. Prototipos_evolucionados Es una extensión del desarrollo incremental El número y frecuencia de los prototipos operacionales se incrementa. El énfasis se hace en evolucionar a una solución de un modo continuo en vez de la construcción de un número discre− to de sistemas En este enfoque se crea rápidamente un prototipo demos− trando la funcionalidad donde los requerimientos son bien conocidos. Cada prototipo sucesivo explora una nueva área de las necesidades del usuario, consiguiendo así que la solución (final) se acerque mucho más a las necesidades del usuario. UNA VISION GENERICA DE LA INGENIERIA DEL SOFTWARE − El proceso de desarrollo del software contiene tres fases genéricas, independientemente del paradigma de ingeniería elegido: − Definición − Desarrollo 57 − Mantenimiento − Definición − Se enfoca sobre el que hay que hacer independientemente de como hay que hacerlo. − Durante esta fase,el desarrollador debe identificar para definir un sistema correcto: − Información que ha de ser procesada − Función − Rendimiento − Interfaces a establecer − Ligaduras de diseño que existen − Criterios de validación que se necesitan − Por tanto han de identificarse los requerimientos claves del sistema y del software − En la fase de definición independientemente del para− digma empleado se producen tres pasos específicos − Análisis del sistema − Define el papel de cada elemento de un sistema informático, asignando finalmente el papel que jugara el software − Planificación del proyecto software − Una vez asignado el ámbito del software, se a− signan los recursos, se estiman los costes y se definen las tareas y planificación del trabajo − Análisis de requerimientos 58 − El ámbito definido para el software de la dirección, pero antes de comenzar a trabajar, es necesario disponer de una información más detallada del dominio de la información y de la función del software − La fase de Desarrollo − Se centra en el como hay que hacerlo − Intenta descubrir − Como han de diseñarse las estructuras de datos y y arquitectura del software − Como han de implementarse los detalles procedi− mentales − Como ha de trasladarse el diseño a un lenguaje de programación − Como ha de realizarse la prueba − Se producirán tres pasos concretos: − diseño del software Traslada los requerimientos del software a un conjunto de representaciones que describen la estructura de datos, arquitectura y procedi− miento algorítmico − Codificación Las representaciones del diseño deben de trasladarse a un lenguaje artificial que da como resultado unas instrucciones ejecutables en la computadora 59 − Prueba del software Una vez que el software se ha implementado en una forma ejecutable por la maquina, debe ser probado para descubrir los defectos que pueden existir en la función, lógica e implementación − Fase de mantenimiento − Se enfoca sobre el cambio que va asociado con una corrección de errores, adaptaciones requeridas por la evolución del entorno del software y modificaciones debidas a los cambios de los requerimientos del cliente para reforzar o aumentar el sistema. − Durante la fase de mantenimiento se encuentran tres tipos de cambios − corrección El mantenimiento correctivo cambia el software para corregir los errores − Adaptación El mantenimiento adaptativo se traduce en modi− ficaciones del software para acomodarlo a los cambios de su entorno externo − Aumento El mantenimiento perfectivo aumenta el software más allá de sus requerimientos funcionales origi− nales − Otras actividades que inciden en la calidad y fiabilidad del software, que complementan a las fases y subfases 60 vistas son: − Revisiones Se realizan durante cada subfase para asegurar que se mantiene la calidad − Documentación Se desarrolla y controla para asegurar que toda la información sobre el sistema esta disponible para un uso posterior − El control de los cambios Se instituye de forma que los potenciales cambios sean mejorados y registrados − Analiza el impacto del cambio − Lo registra − Controla la evolución del sistema Tema 2 −− PLANIFICACION DE UN PROYECTO SOFTWARE − La crisis del software nace para solucionar que los proyec− tos: − Aumentan los costes − Retrasos de tiempos − Poca calidad y fiabilidad − Aumento coste del mantenimiento − La razón principal es la falta de planificación − La planificación debe aplicarse tanto en el desarrollo como a la operación del sistema − La planificación proporciona una guía para el desarrollo del software y debe proporcionar 61 − Alcance del software − Las actividades a realizar − Las referencias a considerar − El coste del producto − Agenda a seguir − Esto se realiza con dos actividades − Investigación : que proporciona a partir de la especialización del sistema (alcance), la fun− ción, el rendimiento y las interfaces del sis− tema así como su fiabilidad. − Una vez consumida la etapa de investigación, conocido el alcance del software y conocidas las actividades a realizar, se realiza la se− gunda actividad − Estimación: que proporciona los recursos a u− tilizar y el coste del producto Observaciones_sobre_la_estimación − La estimación es mas un arte que una ciencia − Par la estimación es necesario un nivel de experiencia (Función del proyecto), hay técnicas para la estimación de costes, recursos y agenda − Un gran problema a la hora de la estimación, es la fal− ta de información histórica. Esta falta obliga a reali− zar la estimación en base a datos cualitativos en de cuantitativos − 3 factores cuya incidencia en la estimación es muy im− 62 portante − Complejidad del proyecto − El tamaño del proyecto − El grado de estructuración − La complejidad del proyecto − Medida relativa, condicionada por la familiaridad − La incertidumbre de la estimación es directamente proporcional a la complejidad − Se han propuesto ciertas medidas cuantitativas de complejidad del software. Tales medidas se a− plican en el diseño o a nivel de Código y son por tanto difíciles de usar durante la planificación del software − Sin embargo, se puede establecer otras evaluacio− nes mas objetivas de la complejidad al principio del proceso de la planificación − El Tamaño del proyecto − Puede afectar la precisión y eficacia de las es− timaciones − A medida que crece el tamaño aumenta la interde− pendencia entre las partes del software. − Es necesario aplicar partición del problema, para la estimación, pero se hace mas difícil dado que las partes pueden ser aún grandes. − El grado de estructuración − Referido a la facilidad de compartimentalizar las 63 funciones(partición) a procesar y de la estructura jerárquica de las informaciones a procesar − La incertidumbre es inversamente proporcional al grado de estructuración. − La disponibilidad de información histórica también de− termina el riesgo de la estimación − No se dispone de ella debido a las propias carac− terísticas del software. − Todos los proyectos son diferentes − Dificultad de la categorización de los proyectos − El riesgo se mide por el grado de incertidumbre en las estimaciones cuantitativas establecidas para los recursos, costes y métodos Objetivos_de_la_planificación − Después de todo esto podemos decir que el objetivo de la planificación es realizar estimaciones responsables de los recursos,costes y métodos a través de un proceso de descubrimiento de la Información (investigación). − Decíamos que la planificación debe proporcionar − Alcance del software (investigación) − Estimación de los recursos Entre otras cosas Alcance_del−software − La primera actividad en la planificación del proyecto del software es determinar el alcance del software − Utiliza como documento la especificación del sistema, 64 donde está asignado al software una función y un ren− dimiento, que deberán evaluarse para que el alcance no sea ambiguo ni incomprensible tanto para los técnicos como para los directivos. − La declararación del alcance del software debe estar delimitada. Por tanto: − Los datos cuantitativos estarán explicitamen− te establecidos(numero usuarios simultáneos) − Las restricciones y/o limitaciones han de ser señaladas(coste restringe tamaño memoria) − Los factores de mitigación han de ser descri− tos (los algoritmos deseados) − Los aspectos que abarca el alcance del software son: − Función − Rendimiento − Una misma función con diferentes rendimientos, puede variar considerablemente el esfuerzo (Recurso) y coste − La función y el rendimiento deben ser evaluados a la vez − Pueden ser refinadas para la aportación de mayores de talles, dado que la estimación se realiza con una orientación funcional − INTERFACES − Corresponde a las interrelaciones del software con el resto de los elementos que componen el sistema 65 − El interfaz pueden tener repercusión en: − Recursos − Costes − Métodos de desarrollo − Por lo que es necesario analizar tanto su natu− raleza como su complejidad − El software puede tener interfaz con − Hardware que ejecutan el software y dispo− sitivos controlados indirectamente por el software − Software ya existente o no que debe ser en lazado con el nuevo software − Gente que hace uso del software por medio de terminales u otros medios de entrada/ salida − Procedimientos que preceden o suceden al software como una serie secuencial de ope− raciones − El aspecto menos preciso del alcance del software es la discusión de su fiabilidad − Aspecto difícil de cuantificar − " Capacidad de un programa para realizar una función requerida bajo ciertas condiciones durante un periodo determinado " − Sistemas con valor humano véase control de operación (tráfico aéreo o de transporte espa− cial) no tiene qué fallar o se perderían vidas 66 humanas, luego tienen que tener consideraciones especiales para asegurar la fiabilidad. Un sis− tema de control de inventario no debería fallar, pero el impacto del fallo es conside− rablemente menos dramático. Recursos − La segunda tarea de la planificación del desarrollo del software es la estimación de los recursos reque− ridos para acometer el esfuerzo de desarrollo de soft− ware. − Dos tipos de recursos contemplados − Humanos − Técnicos − La evaluación de cada recurso se realiza en base a 4 características − Descripción recursos Técnicos/ habilidad requerida recursos humanos − Disponibilidad general − Intervalo de Utilización de los recursos − fecha de emisión de los recursos técnicos/ fecha de comienzo de los recursos humanos − Las dos ultimas caracteristicas es lo que se denomina " ventana temporal" que representa la disponibilidad de un recurso para un proyecto especifico, que debe ser fijada lo antes posible para una buena planifica− ción de los recursos( Colisión de intereses) 67 Recursos humanos − Representan los recursos primarios para el desarrollo del software − Los buenos recursos humanos escasean lo que implica gran incidencia en la crisis del software − El planificador comienza evaluando el alcance(investi− gación) y seleccionando las técnicas requeridas para completar el desarrollo − Dado que el recurso humano es el primero en especifi− carse, el perfil del mismo se define en base − Alcance del Software − Técnicas especiales − En base a las caracteristicas que definen un recurso − Habilidad requerida − La posición en la organización − La especialidad − Disponibilidad general − Para proyectos relativamente pequeños, una sola persona puede llevar a cabo todos los pasos del software, consultando con especia− listas siempre que lo requiera − Para amplios proyectos, la participación varia a lo largo del ciclo de vida − Duración − Tiempo estimado de uso del recurso − Fecha de comienzo 68 − Fecha de inicio recurso − El número de recursos humanos a asignar a un proyecto sólo se puede determinar después de estimado el es− fuerzo de desarrollo − Decíamos que las 2 ultimas características eran una ventana temporal, efectivamente los recursos humanos no se aplican linealmente durante el desarrollo ,sien− do esta la razón. − La participación de la dirección se da al principio del ciclo de vida, disminuye a niveles mas bajos durante los pasos centrales de la fase de desarrollo y crece a medida que se acerca la conclusión del proyecto − El personal técnico senior también participa activamente durante la planificación del proyecto, el análisis de requerimientos, el diseño y las etapas de pruebas finales − El personal júnior esta más involucrado durante las últimas etapas de diseño, de codificación y los pasos de pruebas finales Recursos Técnicos Pueden ser de dos tipos − Recursos Hardware − considerados herramientas para el desarrollo del software − Existen tres tipos o categorías de hardware du− rante la planificación del proyecto de software: 69 − El de desarrollo − La maquina objetivo − Otros elementos de hardware de nuevo sistema − El sistema de desarrollo ( también llamado siste ma anfitrión) − Hardware para desarrollar software − Acceso a un hardware efectivo − Sistema o máquina objetivo − Hardware para instalación del software − En la mayoría de las aplicaciones de mini− computadoras y de grandes sistemas, la má− quina objetivo y el sistema de desarrollo son idénticos − Otros elementos del hardware − Elementos hardware que facilitan funciones especificas durante el desarrollo − Recursos Software − Son recursos (software) que facilitan el desa− rrollo del proyecto − La primera aplicación del software para el de− sarrollo de software fue la reconstrucción − Hoy se disponen de amplia serie de herramientas de software.La figura muestra una jerarquía de las herramientas de software que están disponibles hoy (herramientas actuales) o que estarán disponibles en corto plazo (futuras) 70 herramientas) − herramientas orientadas al Código: son a menudo las únicas disponibles: compiladores, editores lanzadores y cargadores − Herramientas de metodologia − dan soporte a la planificación del proyecto, al análisis de los requerimientos, al diseño, a las pruebas, a la gestión de configuraciones, al man− tenimiento y otras actividades − Herramientas de 4 Generación − Lenguajes de petición de bases de datos − Generadores de Código − Paradigmas de 4G − Dentro de los recursos Software, hay un concepto fundamental: "La reusabilidad" que representa la facilidad de la Utilización de un software(en explo− tación o no) para la construcción de uno nuevo. − La reusabilidad minimiza el esfuerzo de desarrollo − Existen pocas bibliotecas de software reutilizables debido a: − Escasez de técnicas sistemáticas para hacer adiciones a una biblioteca − Difícil tipificación − Dificultad de imponer interfaces estandard para software reutilizable − Pobreza para alcanzar los objetivos de 71 − Calidad − Fiabilidad − Mantenimiento − La gente que desarrolla desconoce la existen cia de dichas bibliotecas. − Si existe software reutilizable como recurso, el planificador debe considerar: 1 − Si el software existente satisface los re− querimientos,comprarlo.El coste de la adqui− sición del software existente será casi siempre menor que el coste del desarrollo de software equivalente 2.− Si el Software existente requiere alguna modi ficación antes de que pueda ser propiamente integrado en el sistema, pensarlo y evaluar− lo. El coste de modificar software existente puede a veces ser mayor que el coste de desarrollo de software equivalente − Normalmente nos encontramos en el segundo caso − Problema: muchas veces no se hace una buena especi− ficación de los requerimientos software (demasiado General) lo que implica: − Difícil tomar decisiones de compra − Difícil evaluación en el supuesto de modi− ficación En ambos casos no sabemos se ajustan a nuestras 72 necesidades − Resumiendo el software como recurso puede estar en estas tres formas: − Existente en la organización − Existente fuera de la organización, y es ne− cesario adquirirlo − No existente y tiene que ser desarrollado − El primer caso ya visto en el contexto de la reusabi lidad − El tercer caso implica un desarrollo en la organiza− ción − El segundo caso es el analizamos y se refiere a la adquisición (compra de software) Adquisición_del_software − Representa la toma de decisión de Hacer−comprar software, para el desarrollo de un proyecto − Las alternativas son varias: − El Software se compra/alquila ya adecuado (se ajusta a las especificaciones) − El software puede ser comprado y luego modi− ficado para ajustarse a las especificaciones − El software puede ser contratado para su de− sarrollo por un consultor externo de modo que se ajuste a las especificaciones − El coste de oportunidad dentro de las organizaciones es decir, el coste que me va a salir hacerlo,o encar 73 garlo − Una vez vistas las alternativas, la decisión final de hacer−comprar se basará en las condiciones: − Fecha entrega externa menor fecha fin desarro− llo − Coste compra externa menor coste desarrollo interno − Coste soporte externo(mantenimiento) menor coste soporte interno − Volviendo nuevamente a las tres alternativas, para la adquisición, la 1 y 2 (compra y compra con modi− ficaciones) están referidas a paquetes externos − Un procedimiento de evaluación de dichos paquetes sería 1.− Desarrollo especificación función y rendi− miento software deseado 2.− Definir el mayor nº de características medi− bles 3.− Evaluar coste desarrollo interno y fecha fin 4.− Selección de paquetes candidatos que se ajusten a la especificación 5.− Desarrollo matriz comparación funciones clave 6.− Pruebas estandarizadas de comparación de pa− quetes seleccionados 7.− Evaluación de cada paquete basandose en: − Calidad de productos anteriores 74 − Soporte Post−venta − Reputación organización − Etc. 8.− recabar información de otros usuarios − La 3º alternativa (desarrollo interno) exige por parte de la organización constantemente: − Exigir aplicación de ingeniería − Exigir aplicación de estandares − Definir configuraciones − Implementar controles que aseguren el al− cance de los requerimientos − Definición de documentación − En cualquiera de las tres alternativas, un factor importantísimo es la disponibilidad de recursos − Humanos − Técnicos/hardware Por parte de la organización contratante PLANIFICACION Y ESTRUCTURA ORGANIZACIONAL DE UN PROYECTO DE SOFTWARE − Para realizar la planificación lo primero es definir el ciclo de vida del producto que incluye todas las actividades requeridas para − Definirla − Desarrollarlo − Probarlo − Implementarlo 75 − Utilizarlo − Mantenerlo − Una vez elegido el ciclo de vida, hay dos formas de realizar la planificación en base al tiempo 1.− Fecha final de lanzamiento cerrada, lo cual implica la distribución del esfuerzo, en el intervalo definido, en base a las actividades a realizar 2.− Fecha final de lanzamiento estimada, lo cual implica que la distribución del esfuerzo se realiza en base a optimización de recursos, pudiendo implicar el retraso de la fecha final − Cuando comenzamos a hablar de planificación, entre otras cosas Decíamos que debe proporcionar la estimación de recursos: − Humanos − Técnicos − Humanos: los recursos humanos están directamente relacio− nados con las actividades a realizar. Implica que la asig− nación de recursos a actividades en un proyecto involucra muchos recursos humanos. − Existe la creencia (mito) que cuando un proyecto se retrasa, es suficiente añadir más personas para terminarlo a tiempo. Falso por − Los recursos humanos y el tiempo sólo son intercam− biables si la tarea puede ser subdividida entre va− 76 rios trabajadores incomunicados entre si. − Añadir más recursos humanos a un proyecto lo retra− saría más (probablemente) debido al efecto de la curva de aprendizaje, lo que implica un incremento de comunicaciones [N(N−1)/2] que implica que la re− lación del nº de personas trabajando en un proyecto y la productividad global no es lineal. − Curva de aprendizaje: intervalo de tiempo transcurrido que necesita un nuevo miembro para aprender y convertirse en un miembro adaptado al proyecto. − Después de lo visto los grupos de trabajo son malos: No: si la comunicación sirve para mejorar tanto la ca− lidad como la facilidad de mantenimiento − Otra de las cosas que debe proporcionar la planificación son: − Actividades a realizar − Agenda a seguir − Las actividades son las tareas que debemos realizar, y la agenda nos determina cuando y en que orden − La pregunta a formular es: ¿cabe el paralelismo en las actividades o el desarrollo es lineal? Respuesta: paralelismo − La figura representa la naturaleza concurrente de las acti− vidades en la ingeniería del software − Descripción de la figura − El análisis y revisión de los requerimientos son las 77 primeras tareas a realizar y dan la base del paralelismo para las tareas siguientes. − Una vez que los requerimientos han sido identificados y examinados, las actividades del diseño preliminar y planificación de pruebas comienzan en paralelo − La naturaleza modular del software bien diseñado le lleva a si mismo a seguir un desarrollo paralelo del diseño detallado, la codificación y las pruebas de unidad. − Cuando se terminan las componentes del software, comienza la tarea de la prueba de integración − Por ultimo, la prueba de validación prepara el soft− ware para ser entregado al cliente − Las referencias están situadas a intervalos Regulares a lo largo del proceso de ingenieria del software, proporcionado al gestor una indicación regular del proyecto − Cada referencia se alcanza una vez que la documen− tación producida como parte de la tarea de ingenie− ria del software ha sido revisada satisfactoriamen− te. − La naturaleza concurrente de las actividades de la ingeniería del software conducen a un importante numero de requerimientos de planificación. − Debido a que las tareas paralelas se suceden de forma asíncrona, el planificador debe determinar la dependencia 78 entre las tareas para asegurar el progreso continuo hasta la terminación − Además el director del proyecto debe ser consciente de las tareas que están en el camino crítico, es decir, tareas que tienen que completarse a tiempo si el proyecto en conjunto ha de ser terminado a tiempo Distribución de esfuerzos A) con ingenieria − se le suele llamar la regla 40−20−40 − Dentro del 40% de análisis y diseño − 2−3% en planificación − Análisis de requerimientos 10−20% − Diseño 20−30% − La codificación del 10−20 % − Las pruebas y posterior depuración 30−50% B) Sin ingeniería − Planificacion , análisis y diseño 10% − Codificación 50% − Pruebas programadores y pruebas globales 40% Métodos de Planificación − Existen muchos métodos para la planificación − Existen muchos métodos disponibles en PC,s ejemplos: − La técnica de revisión y evaluación del programa(PERT) − El método del paso critico (CPM) − Ambas técnicas desarrollan una descripción de la red de tareas del proyecto, es decir una representación gráfica 79 o tabular de las tareas que deben acometerse desde el principio al fin del proyecto − La red de tareas se obtiene: − Desarrollando una lista de todas las tareas asocia− das con el proyecto especifico − y una lista de ordenamientos que indica en que orden deben acometerse las tareas − Ambos tipos proporcionan herramientas cuantitativas que permiten al planificador del software: − Determinar el camino: la cadena de tareas que de− termina la duración del proyecto − Establecer las estimaciones de tiempo más probable para las tareas individuales − calcular tiempos límites que definen una ventana temporal de tiempo para una tarea particular − El calculo de los tiempos límites incluye − camino critico implica que si me retraso en las tareas de él retraso otras tareas y por tanto re− traso el proyecto − Lo antes que puede comenzar una tarea cuando todas las tareas precedentes se completan en el mínimo tiempo disponible − Lo mas tarde que se puede iniciar la tarea antes de que se retrase el tiempo mínimo para la finaliza− cion del proyecto − El Final mas temprano = suma del comienzo mas tem− 80 prano y la duración de la tarea − El final mas tardío = el mas tardío comienzo sumado a la duración de la tarea − La franja total = cantidad de tiempo sobrante o margen permitido en la planificación de tareas de forma que el camino de la red se mantenga en el plan − Los cálculos de tiempo limite llevan a la determinación del camino critico y proporcionan al gestor un modelo cuantitativo para la evaluación del progreso al terminar las tareas Planificacion organizativa de un proyecto software − Hay tantas estructuras organizativas como organizaciones − Estructura genérica − Recursos libres − Asignación de tareas − Se dispone de las siguientes opciones para la aplicación de recursos humanos a un proyecto que requerirá n personas trabajando k años 1. n personas son asignados a m diferentes tareas funcionales, con: − Relativamente poco trabajo combinado − La coordinación es responsabilidad del gestor del software, el cual puede tener mas proyectos que tratar 2. n personas son asignadas a m diferentes tareas funcionales (m<n) 81 − Se establecen equipos informales − Puede elegirse un lider por equipo − La coordinación responsabilidad del gestor del software 3. n personas se organizan en t equipos − A cada equipo se le asigna una o mas tareas funcionales − Cada equipo tiene una organización especi− fica − La coordinación se controla tanto por el equipo como por el gestor del software Estructura del proyecto − Se corresponden( normalmente) con estructuras organicio nales 1. Formato de proyecto − Un grupo realiza todo el proyecto − Algunos miembros permanecen durante instalación y prueba − Otros se van (a otros proyectos) pero siguen responsables del mantenimiento − Todos los miembros, cuando acaba el proyecto se se asignan a otros nuevos 2. Formato funcional − Varios grupos intervienen − Cada uno realiza una fase − Cada equipo entrega la documentación de la fase 82 al siguiente Variante − 3 Grupos − Análisis − Diseño e instrumentación − Pruebas y mantenimiento − Grupo de apoyo − Documentación − Mantenimiento e instalación − Formación usuario − Los miembros de los equipos rotan (formación, evita tedio, superespecialización) − requiere mas comunicación − Requiere muy buena documentación 3 Formato matricial − Cada función tiene su propia organización y gente dedicada a esa función − Cada grupo funcional participa en cada proyecto − Cada proyecto tiene su jefe − Cada persona tiene 2 Jefes( concretamente uno funcional y otro orgánico) − Mejor control del proyecto − Superespecialización − Mejor optimización de los recursos Estructura de los equipos de programación − Todo equipo de programación debe tener una organización 83 interna − Esta depende del proyecto − Existen tres estructuras básicas − Grupos democráticos − Grupos con jefes − Grupos bajo jerarquía administrativa − Grupos democráticos Características − Equipos sin egoísmo Mi programa Nuestro programa − Metas y decisiones por consenso − Liderazgo rotativo en función de tareas y capaci− dades − Los productos son discutidos por todos los miembros Ventajas − Cada miembro contribuye a las decisiones − Aprenden unos de los otros − Gran comunicación − No presión, si para todo el equipo Inconvenientes − La cantidad de comunicación para todas las decisiones − Necesidad de que todos trabajen juntos − Falta de actividad y responsabilidad − menor iniciativa Adecuados: para proyectos investigación, así como para 84 desarrollos largos y difíciles − Grupos con jefe Caracteristicas − Son grupos muy estructurados − Hay liderazgo − Funciones claras Ventajas − Decisiones centralizadas − Reducción de las comunicaciones − Sirven para capacitar Inconvenientes − Visiones parciales − Sensibles a las capacidades técnicas y administra− tivas del jefe Son adecuados − Aplicaciones de procesamiento de datos: Paque− tes (tipo financiero) que pueden desarrollarse: − Jefe experimentado − Programadores poco calificados − Capacitaciones en ambientes reales En estos grupos las funciones son: − Jefe : Planifica Coordina Revisa actividades técnicas Diseña el producto Instrumenta partes críticas 85 Toma decisiones importantes Asigna trabajo programadores − Respaldo/Copia de seguridad Ayuda al jefe en sus actividades Lo reemplaza cuando sea necesario Realiza tareas en general bajo supervisión del jefe − Técnicos: 2 a 5 Codificar Depuran Documentan Prueban − Bibliotecario − Actua como controlador y coordinador de la confi− guración del software Documentación Listados fuentes Datos Cataloga e índexa módulos Ayuda miembros equipos: Investigar Evaluar Preparar documentos − en un proyecto debe existir un bibliotecario, pues el controla la documentación, y la coordinación de los programadores 86 Grupos bajo jerarquía administrativa Características − Ocupa posición intermedia entre los dos anteriores − Hay un lider del proyecto − Funciones claras − Requiere mucha administración/coordinación Ventajas − Semidescentraliza la toma de decisiones − Flexibilidad en la comunicación Inconvenientes − Proyección de buenos programadores(técnicos) a puestos administrativos Buen técnico no implica buen administrativo o Comunicación −−−−−−−> o /\/\ o o <−−−−− Estructura o −−−− o /|\ /|\ / | \ / | \ o o o o o o o −|−o o−|−−o \ | / \| / oo El_plan_del_proyecto_de_software − Cada paso del proceso de la ingeniería del software debe producir algo a entregar que pueda ser revisado y que pueda servir de base para los pasos posteriores. − El plan del proyecto de software se produce como culmina− ción de la etapa de planificación. 87 − Proporciona una línea base de información de costes y de planificación temporal que se utilizara a lo largo del ci− clo de vida del software. − El plan del proyecto de software es un documento relativa− mente breve que se dirige a una diversa audiencia. − Debe : 1.− Comunicar el alcance y recursos a los gestores del Software 2.− Definir el coste y el plan temporal de la revisión de la gestión 3.− Proporcionar una aproximación global al desarrollo del software para toda la gente involucrada en el proyecto − Se puede usar como guía el siguiente esquema de documento 1. Alcance a. Objetivos del proyecto b. Funciones principales c. Otras características d. Un escenario de desarrollo 2. Recursos a. Recursos humanos b. Recursos hardware c. Recursos de software d. Ventanas de disponibilidad 3. Coste a. Desgloses 88 4. Plan Temporal a. Red Tareas b. Diagrama Gantt c. Tablas Recursos/tareas − Su propósito es ayudar a establecer la viabilidad del esfuerzo de desarrollo del software − El plan se centra en establecer de forma general el qué y en informar especificamente del cuánto y cómo de largo de una forma general. Tema 4 −− ANÁLISIS Y ESPECIFICACIÓN DE LOS REQUERIMIENTOS Problemas_en_proyectos_informáticos − Sobre el desarrollo de grandes aplicaciones software(+ 50K) se dispone de la siguiente estadística: − Más del 25% de los proyectos son cancelados antes de su terminación − Más del 60% de los proyectos terminados, lo hacen con un enorme retraso y con un significativo incremento del coste ( el promedio es un año de retraso y una duplicación del coste estimado) − Mas del 75% de los proyectos terminados presentan posteriormente dificultades de explotación y altos costes de mantenimiento − Solo el 1% de los proyectos se terminan dentro del plazo y costes previstos y cumpliendo requisitos − El problema que se plantea es el problema de la comunica− 89 ción, es decir de comprensión del interlocutor(cliente). Generalidades − Objetivo Especificar total y consistentemente los requerimien− tos del producto de una manera concisa y sin ambigüedades, utilizando para ello una notación formal − Representa la última fase de la etapa de definición (análisis de sistemas y planificación) y es esencial para la siguien− te etapa de desarrollo − Esta fase se centra: Que es el producto a construir, sin importar Como es dicho producto. − Aunque parece una fase sencilla es todo lo contrario, debido al alto grado de comunicación requerida entre / Usuario \ /|\ Documentación −−−−−−−−−−−−−−− Gerente \|/ \ Técnicos/ así como las propiedades que debe tener la especificación , siendo esta la representación formal de los requerimientos para un posterior diseño. − la documentación de entrada de esta fase la proporciona: − La Especificación del sistema (Análisis del sistema) − Asigna la función software al sistema − El plan de Proyecto ( planificación) 90 − define actividades − Define tiempos − Define recursos − Sin un buen análisis y Especificación de requerimientos no es posible realizar un buen desarrollo del software. − Para efectuar la especificación de los requerimientos se realiza el análisis de los requerimientos − Para realizar la Función del análisis se han desarrollado diversos métodos. Cada uno de ellos aborda la tarea desde diferentes ópticas, pero todos ellos están sustentados en una serie de principios, que permiten el enfoque sistemáti− co del problema Principios 1.− Dominio de la información − Referido a la información (DATOS) que va a proce− sar el sistema. − Asociado a este D.I. esta el dominio Funcional que representa a los procesos ( funciones) que trans− forman la información − Ambos Dominios tienen que ser bien comprendidos y representados − El dominio de la información contempla 3 visiones so− bre los datos que procesaran las funciones (programa) − Flujo de la información que muestra la forma en que los datos se transforman a medida que pasan a través del sistema 91 Las transformaciones sobre los datos están realizadas por las funciones o subfunciones que el programa debe de ejecutar El flujo de datos entre 2 transformaciones definen la inerface de cada función − El contenido de la información , referida al contenido de la información de cada elemento de datos individuales. La agrupación de datos indi− viduales componen otros elementos mayores de In− formación − La estructura de la información que representa la organización lógica de los distintos elemen− tos de datos Es decir como debe organizarse los datos para un mejor procesado La Estructura de la Información no implica la estructura de datos, que representa el diseño e implementación de la estructura de Información con el Software 2.− Partición − Consiste en la subdivisión del problema con el fin de hacerlo manejable intelectualmente, subdividiendo, ca− da parte se hace más comprensible y todas las partes juntas dan como resultado la función global. − Tanto el dominio de la Información como el dominio funcional pueden ser particionados − la partición en el dominio funcional lleva a una primera visión de los procesos (contienen las funciones) a realizar (vision de alto nivel) 92 − La partición del dominio de la información en una pri− mera fase viene dado por el flujo de la información y y la temporabilidad − Existen 2 aproximaciones para la partición una vez establecida una representación jerárquica bien de la función o de la información: a) Incrementando los detalles, moviendonos verti− calmente en la jerarquía b) Descomponiendo funcionalmente el problema, moviendose horizontalmente en la jerarquía 3.− Visiones lógicas y físicas de los requerimientos − La lógica representa tanto las funciones que han de realizarse como la información que ha de procesarse independientemente a los detalles de implementación − La física presenta una manifestación del mundo real de las funciones de procesamiento y las estructuras información Tareas_durante_el_análisis_de_requerimientos 1) Reconocimiento del problema − Consiste en reconocer los elementos básicos del sistema tal y como los ve el usuario − Para ello se cuenta con: − La Especificación del sistema (análisis del sis tema) − Plan de proyecto ( Planificación) − Que nos permitirán conocer el contexto del sistema así como el entorno usado para generar las estima− ciones 93 − En esta tarea se estudia los procesos asociados 2) Evaluación y síntesis − Esta tarea proporciona el enfoque para la resolución global del problema − En ella el ingeniero del software: − Evalúa el flujo y estructura de la informa− ción − Refina al detalle las funciones − Establece las características de las inter− faces − Descubre/ligaduras de diseño − Delimita la información tanto de entrada co− mo de salida − Comienza a plantear diferentes soluciones para el problema 3) Especificación − Esta tarea sirve para especificar los requerimientos del software desde una perspectiva del usuario − Representa el producto a producir en la fase de ana− lisis de requerimientos, e incluye los criterios de de validación 4) Revisión − Es la última tarea del análisis − Es realizada por el cliente y el técnico − Produce redefiniciones de los aspectos estudiados − También se revisa el plan de proyecto para determinar 94 si las estimaciones siguen siendo validas después de conocer en detalle que es el sistema − Una vez que se ha completado la revisión se señalan como terminadas tanto por el cliente como por el téc− nico la Especificación de requerimientos de software. La Especificación se convierte en un contrato para el que se desarrolla el programa Problemas_en_la_realización_del_análisis − Los problemas que se plantean están determinados por las caracteristicas de esta fase : la comunicación − Los principales problemas son: − Adquisición de la información, que se realiza en las 2 Primeras Tareas de la función del análisis de Requeri− mientos. Los problemas se centran en − ¿que información debe recogerse y cómo de− de representarse? − ¿quien suministra las distintas partes de la información − ¿que herramientas y técnicas están dispòni− bles para facilitar la recogida de informa− ción? − Manejo de la complejidad del problema − El problema es un conjunto de partes interrelaciona− das. − La introducción de nuevos elementos, ligaduras, etc, 95 como influye, era uno de los aspectos que influían en la estimación − Los problemas se centran − ¿cómo podemos eliminar la inconsistencia cuan− do se especifican grandes sistemas? − ¿es posible detectar las omisiones? − ¿Puede un problema grande ser subdividido con efectividad de forma que se haga mas manejable intelectualmente − Acomodación de los cambios, antes y después del análisis. En todo sistema los cambios se producirán − Los cambios aludidos son cambios de requerimientos − Los problemas se centran − ¿como se coordinan los cambios de otros elementos del sistema con los requerimientos del software? − ¿como establecer el impacto de un cambio sobre otras partes,aparentemente no relacionadas,del software? − Como corregir los errores en la especificación de forma que no se agreguen efectos laterales? − Existen muchas causas que producen los problemas descritos anteriormente, entre otras: 1− Pobre Comunicación que hace difícil la Adquisición de Información 2− técnicas y herramientas inadecuadas que producen 96 especificaciones inadecuadas o imprecisas 3− Tendencia a acortar el análisis de requerimientos, conduciendo a un análisis inestable 4− Un fallo en considerar alternativas antes de la Especificación del software "A_quien"_y_"que"_facilita_el_análisis_de_requerimientos A Quien Que Ingeniero de sistema − Especificar función y rendimiento − Interfaces otros elementos del sistema − Establecer las ligaduras de dise− ño que debe cumplir el sistema Ingeniero de Software − Redefinir la asignación del soft− ware − Representa el dominio de la infor nación que será tratada Al diseñador (I.S) − Representación de − Información − Funciones − Que puede traducirse − Estructura de datos − Arquitectura del software − Diseño procedimental Técnico y cliente − Medios para valorar la calidad del sistema una vez construido (criterios válidos) 97 Caso_particular_del_análisis_de_requerimientos_:_construcción de_prototipos − Se aborda en general cuando − No es factible realizar una especificación detallada de los requerimientos por parte del usuario (No sabe lo que quiere) − El Ingeniero del software tiene dudas del usuario − Pasos para la construcción de un prototipo: PASO 1 Evaluar la Partición del software y determinar si el programa a desarrollar es buen candidato para construir un prototipo − Las variables que intervienen: − Área de aplicación − Complejidad de la aplicación − Caracteristicas del cliente − Caracteristicas del proyecto − Debido a que el cliente debe interaccionar con el prototipo en los últimos pasos,es esencial: − que el cliente participe en la evaluación y refinamiento del prototipo − el cliente sea capaz de tomar decisiones de requerimientos de forma oportuna PASO 2 Dado un proyecto candidato aceptable, el analista desarrolla una representación abreviada de los requerimientos − Antes de que pueda comenzar la construcción de un prototipo, el analista debe representar 98 − los dominios funcionales y de Información del programa − Desarrollar un metodo razonable de Partición PASO 3 Después de que se haya revisado la representación de los requerimientos, se crea un conjunto de es− pecificaciones de diseño abreviadas para el pro− totipo − El diseño se enfoca hacia − la arquitectura − los datos − en vez de − hacia el diseño procedimental detallado PASO 4 El software del prototipo se crea,prueba y refina − Usuario (C,R) − constructor (C,P,R) PASO 5 Una vez que el prototipo ha sido probado, se pre− senta al cliente, el cual conduce la prueba de la aplicación y sugiere modificaciones − Este paso es el núcleo del método de construc− cion del prototipo − Es aquí donde el cliente − Puede examinar una representación implementa− da de los requerimientos del programa − Puede sugerir modificaciones PASO 6 Los pasos 4 y 5 se repiten iterativamente hasta que todos los requerimientos están formalizados o hasta que el prototipo haya evolucionado hacia un 99 sistema de producción Un_paradigma_de_ingenieria_del_software_automatizada ___________________ | Recolección| | | de requeri−|___\|/____________ | mientos | Representación| | |_________| en lenguaje___|___\|/___________ /|\ | formal | Generación | | | |____________| automática_|_____\|/_______/___ | | prototipo| Optimización |\ | | |__________| y ____|__\|/___ | Verificación | | afinamiento| Software | | y modificación | |____________| completo | |_______________________| |___________| Consideraciones_sobre_la_construcción_del_prototipo − Cuando se construye un prototipo se realiza un Manual de Usuario preliminar, siendo este un borrador del definitivo con el fin de: − Al analista: que asuma el punto de vista del usuario del software − Al cliente: revisar el Software desde una pers− pectiva de ingeniería humana − así mismo cuando se construye un prototipo existen 2 fina− lidades: A) Establecer un conjunto de requerimientos formales para después ser traducidos para la producción de 100 programas, mediante el uso de técnicas y métodos de ingeniería B) A partir del prototipo como base, construir el proyecto mediante un desarrollo evolutivo − Así pues, la construcción de prototipos esta orientada, des de una perspectiva de usuario, a conocer tanto cuales son los requisitos del sistema como a evaluar como afectara al trabajo la existencia del nuevo sistema − Las ventajas de la utilización de prototipos durante la fase de análisis de requerimientos son − Los malentendidos entre usuarios y desarrolladores pueden identificarse a medida que se muestran las funciones del sistema − Pueden identificarse los servicios que le falte al usuario − Se pueden identificar y medir los servicios del usuario difíciles de utilizar o confusos − Los desarrolladores pueden detectar requisitos incompletos e inconvenientes − Disponer con rapidez de un sistema de trabajo − Puede servir como especificación para el desarrollo de un sistema − Finalidades − Evolucion a sistemas de producción − Derivación de requerimientos que implica desechar el prototipo y reconstruir el sistema 101 − El problema se centra en el TANDEM Desarrollo rápido y facilidad de mantenimiento, que ra− ra vez son compatibles − De hecho − El desarrollo rápido es el propósito de los desarrolladores del prototipo − La facilidad del mantenimiento debe ser la finalidad del desarrollo de sistemas de calidad de producción − Por eso al menos para grandes Sistemas es mejor desarro− llarlo, pues la estructura se degrada con rapidez a medida que avanza el mantenimiento − El coste del prototipo y coste de sistema − Implica no utilizar las mismas herramientas y Stan− dares del producto final − Reducción confiabilidad y calidad pues es desechado ESPECIFICACIÓN − Especificación de los requerimientos del software consti− tuye el producto final de la fase de análisis de los reque− rimientos y es el documento base para la fase de diseño − Dado que la especificación tiene mucha incidencia en la calidad de la resolución elegida para el desarrollo del software, la abordaremos definiendo sus: − Principios − propiedades Principios de la Especificación 1.− Separación entre funcionalidad e implementación 102 . Se especifica que hay que hacer no "como" se realiza 2.− Necesidad de un lenguaje de Especificación del sistema orientado al proceso . Del "que" se obtiene la especificación de un modelo, del comportamiento deseado en términos de respuestas funcionales 3.− Una especificación debe abarcar el sistema del cual el software es un componente . Dado que un sistema esta formado por componentes que iteractuan . Solo dentro del sistema global y conocida la inter− pretación entre sus partes, se puede definir el comportamiento especifico de un componente 4.− Una especificación debe alcanzar el entorno en el ope− ra 5.− Una especificación del sistema debe ser un modelo cognitivo, en vez de un modelo de diseño o implemen− tación . Debe describir el sistema tal y como es visto por los usuarios . Los objetivos corresponden a objetivos reales del dominio. . Debe poderse incorporar a la especificación las re− glas o leyes que gobiernan los objetivos del dominio, que pueden limitar el comportamiento de los agen− tes 103 6.− Una especificación debe ser operacional de tal manera que pueda usarse para determinar si una implementa− cion propuesta satisface la especificación de pruebas elegidas arbitrariamente 7.− La especificación del sistema debe ser tolerante con con la incompletitud y aumentable . Debido a que la especificación es siempre un modelo (abstracción) de la realidad, será incompleta. 8.− Una especificación debe ser localizada y debidamente acoplada − La especificación no es una entidad estática, se cambiara con el tiempo − Las modificaciones se presentan en tres etapas − Formulación : en la fase de análisis de requerimien− tos − Desarrollo: cuando la Especificación se esta elavo− rando en la fase iterativa de diseño e implementación − Mantenimiento: Cuando se modifica la especificación para reflejar un cambio en el entorno y/o requerimien tos funcionales nuevos Propiedades de la Especificación de los requisitos del soft− ware − Especificación de requisitos como una especificación que establece los requisitos para un sistema − Propiedades que debe cumplir el documento de especificación de requisitos de software 104 − No ambiguo − Completo − Verificable − Consistente − modificable − Rastreable − Usable en fase de operación y mantenimiento − La asociación española para el control de calidad en su Glosario de términos de calidad del software define el software: Programas, procedimientos, reglas y la posible documen− tación asociada y datos que pertenezcan a la explotación de un sistema de ordenadores − No ambiguo: . Un ERS no es ambiguo si y solo si cada requisito enun− ciado en la especificación tiene una única interpretación . Por esto debe de darse estas dos condiciones 1) como mínimo, esto requiere que la característica del producto final sea descrita usando un único termino 2) En los casos donde un termino es un contexto parti− ticular, pueda tener múltiples significados, se debe incluir el término en un glosario, el cual debe ser completo − Completo . Un ERS es completo si posee las siguientes cualidades 1) Incluye todos los requisitos significativos 105 2) Define los requisitos del software para todos los da− tos de entrada en todas las clases de situaciones posible 3) Es conforme al STANDARD ERS en que se basa 4) Define todos los términos, unidades de medida y hace referencia a todas las figuras, tablas y diagramas 5) Cualquier ERS que use la frase se determinará no es completo . Sin embargo los se determinara son necesarios algunas veces. cuando sea necesario utilizarlo ira acompañado por: a) Una descripción de las condiciones que lo causan, de tal manera que la situación pueda ser resuelta b) Una descripción de que debe hacerse para eliminarlo − Verificable . Un ERS es verificable si y solo si cada requisito enuncia− do en el ERS es verificable . Un requisito es verificable si y solo si existe algún proceso finito de coste razonable en el que una persona o maquina pueda probar que el producto software cumple el requisito − Consistente . Un ERS es consistente si y solo si ningún conjunto de requi sitos individuales descritos en el ERS tiene conflictos . Hay tres tipos de conflictos en un ERS: 1) Dos o mas requisitos pueden describir el mismo objeto real, pero usar términos diferentes para ese objeto 2) Las caracteristicas especificas de los objetos del mundo 106 real pueden tener conflicto 3) Puede haber conflictos lógicos o temporales entre dos acciones especificas − Modificable . Un ERS es modificable si su estructura y estilo son tales que cualquier cambio que sea necesario realizar en los requi− sitos puede ser realizado de una manera facil completa y con− sistente . Generalmente se dice que un ERS es modificable: 1) Su organización es facil de usar y es coherente 2) si no es redundante : es decir que el mismo requisito no aparezca en más de un lugar el ERS . La redundancia puede llevar a errores fácilmente . La redundancia da problemas de actualización − Rastreable . Un ERS sera rastreable si el origen de cada requisito es claro y se facilita la referencia de cada requisito para un desarrollo futuro o mantenimiento de la documentación . Un documento puede ser rastreable de dos maneras 1) hacia atrás 2) hacia adelante − Usable en la fase de operación y mantenimiento . El ERS debe de tener en cuenta las necesidades de la fase de operación y de mantenimiento . Esto implica dos acciones: a) que el ERS sea modificable 107 b) que el ERS contenga un registro con las caracteristicas de cada requisito Preparación del documento − Quien lo hace: conjuntamente entre los usuarios y el ana− lista − Con que objetivos: establecer un cuerdo entre el usuario y analista sobre que debe hacer el software − El proceso de desarrollo del software comienza con un acuer− do entre cliente y suministrador que realiza el software. − este acuerdo es en forma de un ERS y debe prepararse conjun− tamente Perfil del analista en esta fase − cuando se habla de perfil del analista se abarcan dos aspec tos: − Trabajo a realizar − Caracteristicas que debe tener − referente a las caracteristicas que debe tener, son habili− dades para: − Comprender conceptos abstractos, reorganizalos en divisiones lógicas y sintetizar soluciones basadas en cada división − entresacar hechos importantes de fuentes conflicti− vas o confusas − Comprender entornos de usuario/cliente − Aplicar elementos Hardware y/o software a entornos de usuarios/cliente 108 − Comunicarse bien en forma oral y escrita − evitar que los arboles no nos dejen ver el bosque Evolucion en la Especificación de los requerimientos del software − Problemas . El ERS puede necesitar evolucionar, a la vez que el desa− rrollo del producto software progresa, debido a dos puntos: 1) Puede ser imposible cuando se inicia el proyecto, espe− cificar algunos detalles 2) Pueden surgir cambios como consecuencia de deficiencias en los requisitos − Consideraciones a) Los requisitos se deberán especificar tan completamente como sea posible b) iniciar un proceso de cambio formal para identificar, controlar, seguir la pista e informar de los cambios tan pronto como sean inicialmente identificados − Para que los cambios que se puedan realizar en el ERS se deben: − Proveer un control de cambios preciso y completo − permitir la revisión de partes actuales reemplazadas en el ERS Estructura de una Especificación de requerimientos (ERS) − Indice de contenidos 1. Introducción 1.1 Propósito 109 1.2 Alcance 1.3 Definiciones, axiomas, abreviaciones 1.4 Referencias 1.5 Vision general − Estructura Introducción . La introducción deberá dar una vision general del ERS entero . El propósito debe contener lo siguiente: − Delinear el propósito particular del ERS − Especificar a quien va dirigido el ERS . La subsección de alcance deberá − Identificar el producto software con su nombre − Explicar que hará y qué no hará el producto software − Describir la aplicación del software que se este especificando . La subseccion de definiciones deberá proveer las definiciones de todos los términos y abreviaciones que son necesarios para interpretar el ERS . La subsección de Referencias deberá: − Prever una lista completa de los documentos referencia− dos − Identificar cada documento por el titulo, nº de informe, fecha y editorial − Especificar donde se puede obtener . La subseccion de Vision general deberá − Describir lo que contiene el resto del ERS − Explicar como esta descrita la ERS 110 − Descripción general 2. Descripción general 2.1 Perspectiva del producto 2.2 Funciones del producto 2.3 Caracteristicas del usuario 2.4 Restricciones generales 2.5 Suposiciones y dependencias − Estructura de la Descripción general . la subsección de Perspectiva del producto hace ver al producto con relación a otro producto o proyectos . La subsección de funciones del producto deberá contener las funciones a nivel general que realizara el software. − Estas funciones sera legibles al usuario, no a alguien que lea este documento por primera vez − Una herramienta de ayuda para esto será un diagrama en bloques . la subseccion de caracteristicas del usuario describirá aquellas caracteristicas generales de los usuarios eventuales del producto que afectará los requisitos específicos . La subseccion de restricciones generales suministrará una descripción general de cualquier otro elemento que limitara las operaciones del desarrollador para diseñar el sistema Pueden ser: − Normas − Limitaciones hardware − Interface otras aplicaciones 111 − consideraciones de seguridad − En la subsección de Suposiciones y Dependencias se indican los factores que afectan a los requisitos enunciados en el ERS. − Estos factores no son restricciones de diseño en el Software si no cualquier cambio en esos factores que puedan afectar los requisitos del ERS − Requisitos específicos 3. Requisitos específicos Tema 6 −− DISEÑO DEL SOFTWARE Fundamentos * La fase de diseño es un proceso creativo que requiere del diseñador ciertas cualidades * Los conceptos del diseño se aprenden en libros; el diseño (como actividad) no, es necesario practicar y aprender por medio de la experiencia * Un sistema de software bien diseñado es facil de aplicar y mantener, y además es comprensible y fiable * Hasta la aparición de la Ingenieria del Software el proble− ma del diseño era de enfoque a) A partir de unas especificaciones generalmente en lengua je natural, se confeccionaba un "diseño informal" normal− mente en forma de organigrama. A partir de esto se empezaba a codificar y se modificaba el diseño a medida que se aplicaba el siste− ma. Al final, el diseño y el sistema no se correspon− 112 dían con lo que el diseño era inútil. b) A partir de la ingeniería del Software se comprende que las especificaciones de requerimientos es fundamental, que las notaciones informales(organigramas,etc) son ina− decuadas para formular el diseño por lo que se desarro− llan diferentes notaciones formales. Así dada una especificación de requisitos, que el ingeniero del software usa para desarrollar el diseño, en los siguientes pasos − Deben establecerse los subsistemas que componen el sistema − Cada subsistema debe dividirse en componentes individuales y ha de establecerse la especifica− cion de los subsistemas definiendo la función de esos componentes. − Después cada programa se puede diseñar a base de subcomponentes que interactuen. − A continuación se debe refinar cada componente, implicando cada componente como una jerarquía de subcomponentes − En algún momento del proceso de refinamiento se debe especificar con detalle los algoritmos uti− utilizados en cada componente. La_fase_de_desarrollo_y_el_diseño_del_software * La fase de desarrollo comprende tres etapas: − Diseño 113 − Generación de Código − Pruebas * La primera (el diseño) es la mas importante y es sobre la que descansa la "calidad" del producto software * Notese en la figura, las entradas para el proceso de diseño − Estructura de la Información (Dominio información) − Función y rendimiento (Comportamiento funcional) Así como las salidas del mismo que muestran que son un refina miento de las entradas * Independientemente de la metodología que use, el proceso de diseño se centra en tres aspectos − Diseño de datos: Se centra en la definición de la es− estructura de datos (refinamiento de la estructura de la información) − Diseño arquitectónico: se centra en las relaciones en− entre los principales elementos del Software (R. Parti− ción) − Diseño procidimental: se centra en la transformación de los elementos estructurales en una descripción procedi− mental del software. * Veamos a continuación cada uno de estos aspectos Diseño_de_datos * Es la primera y mas importante de as tres actividades de diseño. * El diseño de datos se materializa en las estructuras de datos por medio de refinamiento de la estructura de la 114 información * Una actividad asociada a las estructuras de datos es la identificación de los módulos del programa que usara las estructuras de datos * Las estructuras de datos son muy importantes, pues tienen un enorme efecto sobre: − La estructura del programa − La complejidad procedimental * Debido a esto, las estructuras de datos bien diseñadas llevan a : − Una mejor estructura del programa − Una mas eficiente modularidad − Disminución de la complejidad procedimental * Dada la gran importancia de las estructuras de datos, existen normas para la especificación y diseño de las estructuras de datos. Dichos principios podrían ser: 1º Los métodos de análisis sistemáticos aplicados al software deben también aplicarse a los datos . De la misma forma que se determinan y revisan las especificaciones del Análisis de requerimientos y diseño del sistema, y se presentan soluciones alternati− vas, lo mismo debe hacerse con las estructuras de datos debido al gran impacto que tienen sobre el diseño sobre el software 2º Deben identificarse todas las estructuras de datos y operaciones que han de ejecutarse sobre cada una de 115 ellas. . Una estructura eficiente de datos debe contemplar todas las operaciones que han de ejecutarse sobre cada una de ellas (tratamiento astracto de datos). . Ello nos llevara a un mas eficiente diseño del software 3º Debe establecerse y hacerse un diccionario de datos para definir el diseño de los datos y el software . El diccionario muestra de forma explícita las relaciones entre los datos y las ligaduras (interdepen− dencias) de los elementos de una estructura de datos. 4º La decisiones de diseño de los datos a bajo nivel deben retrasarse hasta las ultimas etapas del proceso de diseño. . Aplicar un proceso de refinamiento sucesivo durante las fases de − Análisis de requerimientos − Diseño preliminar | > Descomposición diseño − Diseño detallado | . Este proceso de diseño descendente en los datos proporciona las ventajas (análogas) del diseño descenden te del Software 5º La representación de una estructura de datos debe ser conocida solo por los módulos que hagan uso directo de los datos contenidos dentro de la estructura. 116 . Se basa en los conceptos de − Ocultación de los datos (Información) − Acoplamiento 6º Debe desarrollarse una biblioteca de estructuras de datos útiles y de las operaciones que pueden aplicarse a ellas. . Implica contemplar las estructuras de datos y las operaciones y sus operaciones asociadas como un recurso para el diseño del software. . Se fundamenta en los Tratamientos abstractos de datos , que pueden reducir el trabajo de especificación y diseño de las estructuras de datos 7º El diseño del software y el lenguaje de programación deben soportar la especificación y realización del trata− miento abstracto de datos * Estos principios son la base para cualquier método de dise− ño de datos Diseño_arquitectónico * Tiene como objetivo principal: − Desarrollo de una estructura de programa modular − Representar las relaciones de control entre los módulos * Otros objetivos son: − Asociar − Estructura de programas − Estructuras de datos − Definir las interfaces que facilitan el flujo de los 117 datos a lo largo del programa Diseño_procedimental * Se efectúa después de establecer: − Estructura del programa − Estructura de los datos * Se centra en definir los detalles algorítmicos sin ninguna ambigüedad * La Especificación procedimental debe realizarse de alguna forma * La primera (y peor) es el lenguaje natural (ambiguo), por ello deben utilizarse formas mas restringidas. * Entre ellas: − Programacion estructurada − Herramientas gráficas de diseño − Diagramas de flujo (organigrama) − Diagramas Nassi−Schneiderman (Chapin) − Herramientas tabulares de diseño (tablas verdad) − Lenguajes de diseño de programas (LOP./PSC.) Se han visto cuales son los principios (de c. metodologia) del diseño. Veamos ahora como se logran Proceso_de_diseño * Los principios vistos, representan aspectos técnicos de la función del diseño * Desde la perspectiva de gestión del proyecto (cuando hacer cada cosa) el proceso de diseño se realiza en dos pasos: − Diseño preliminar/externo. 118 . Implica: − Concebir − Planear − Especificar las características de un producto de programación. − Definición de pantallas − Formatos de informes − Definición de entradas − Definición de salidas − Características funcionales − Estructura general del producto − Etc. . Materializándose dichas características en la transfor mación de los requerimientos en − Estructuras de datos − Arquitectura de Software . Este paso del diseño se alimenta (comienza) del análisis de los requerimientos y continua en este paso, por eso es difícil deslindarlos. . En la realidad lo que sucede es que la distinción en− tre ambos (análisis de requerimientos y diseño prelimi− nar) no es clara, sucediendo un cambio gradual de aten− cion entre el "que" y el "como". − Diseño de Detalle/Interno . Implica − Especificar la estructura interna 119 − Detalles de procesamiento − Respetar las decisiones de diseño y documentarla − Elaborar planes de prueba − Suministrar una guia para la instrumentación de − Pruebas − Mantenimiento * Este paso de diseño se orienta hacia los refinamientos de la representación arquitectónica que conducen a una estruc− tura de datos detallada y a la representación algorítmica del software * Así podemos decir que los productos de este paso son: − Especificación de la estructura arquitectónica − Detalles de los algoritmos − Las estructuras de datos en detalle − Los planes de pruebas * Un buen diseño de software se logra mejor utilizando una metodologia consistente de diseño. * Hay muchas, siendo cada una de ellas adecuadas para diferen tes tipos de aplicaciones (productos software) * La mayoría se puede clasificar en las siguientes áreas: − Diseño funcional descendente . Consiste en diseñar el sistema desde un punto de vista funcional . Se parte de una vision de alto nivel hasta llegar al diseño mas detallado . Ha sido muy utilizada tanto para proyectos de pequeña 120 y gran escala en diferentes áreas de aplicaciones − Diseño orientado al objeto . Consiste en ver al sistema mas como una colección de objetos que como funciones . Se basa en la idea del "ocultamiento de la informa− ción" Es un desarrollo relativamente reciente − Diseño controlado por los datos . Consistente en plantear que la estructura de un sistema software debe reflejar la estructura de datos que procesa, lo que implica que el diseño del software se obtiene del análisis de los datos del sistema de entrada y salida. . Se ha usado fundamentalmente en sistemas pequeños, aunque no esta circunscrito solamente a estos. Fundamentos_del_diseño_del_software * Las técnicas son la manifestación de los conceptos en su aplicación a situaciones particulares * Las técnicas son pasajeras, pero los principios funadmenta− les permanecen y proporcionan las bases para el desarrollo y evaluación de las técnicas. * Para evaluar un diseño, se han establecido un conjunto de conceptos fundamentales, que ayudan al ingeniero del software a responder a las siguientes preguntas . Que criterios pueden usarse para subdividir el software en componentes individuales . Como se separan los detalles de una función o estructura 121 de datos de una representación conceptual del software . Existen criterios uniformes que definan la calidad técni técnica de un diseño de programa * M. Jackson: El comienzo del saber de un ingeniero del software es reconocer la diferencia entre obtener un programa que funcione y obtener uno que funcione "correctamente". * Los fundamentos del diseño nos proporcionan: − Como hacerlo − Evaluarlo * Los fundamentos del diseño son: − Refinamiento . El refinamiento (por pasos) es una técnica para la descomposición de una Especificación (Función, in− formación) definida a alto nivel hasta sus niveles mas elementales. . Es decir la Especificación describe (función, infor mación) conceptualmente, pero no detalles . El refinamiento va ampliando ( en cada paso o elabo ración) los detalles . El diseño funcional descendente utiliza el concepto de refinamiento sucesivo. . Fue propuesto por N. Wirth y es análogo al proceso de refinamiento y Partición usado durante el análisis de requerimientos. − Arquitectura del Software . Hace referencia a dos características fundamentales 122 de un programa: − Estructura jerárquica de los componentes procedi− mentales (módulos) − Estructura de los datos . Se deriva mediante un proceso de partición que aso− cia a los elementos de una solución software con las partes de un problema (del mundo real) definido impli− citamente durante el análisis de los requerimientos. . La solución se obtiene cuando cada parte del problema se resuelve mediante uno o mas elementos software. (un programa para calcular; otros progra− mas para listar) . Contingencia: un mismo problema ( para un conjunto de requerimientos puede solucionarse mediante dife− diferentes estructuras . Según metodologia se obtienen diferentes estructu− ras, porque cada una se basa en fundamentos distin− tos. − Estructura del programa . Representa la organización normalmente jerárquica de los componentes procedimentales del programa (módulos) e implica una jerarquía de control . No representa aspectos procedimentales del software (secuencia, repetición, operaciones, etc.) . Para representar una estructura existen muchas nota− ciones 123 − Estructura de datos . Es una representación de la relación lógica entre elementos individuales de datos . Dado que afecta al diseño procedimental es tan importante como la estructura en la Representación de la arquitectura . La estructura de datos determina: − Organización − Métodos de acceso − Alternativas de procesamiento para la infor mación Procedimientos_de_software * Se centra sobre los detalles de procesamiento de cada módu− lo individualmente. * Los procedimientos del software deben proporcionar: − Especificación precisa del procesamiento − Secuencia de sucesos − Puntos de decisión exactos − Operaciones repetitivas − Organización y estructura de datos − Referencia a todos los módulos subordinados, dado que existe una relación estructura y procedimiento * La representación procedimental del software se realiza por capas Modularidad * Existen muchas acepciones del concepto de modularidad. 124 * Van desde una subrutina hasta la asignación de trabajo para un programador. Todas son correctas * La modularidad consiste en subdividir el software en partes denominadas módulos, cada uno con un propósito especifico,que se integran para satisfacer los requerimientos de un problema * La modularidad es el atributo mas sencillo del software,que permite a un programa ser manejable intelectualmente * Asimismo, la modularidad es un enfoque comunmente aceptado tanto para análisis como para diseño. * La modularidad proporciona: − Calidad de diseño − Facilidad de instrumentación − Facilidad de depuración − Facilidad de pruebas − Facilidad de documentación − Facilidad de mantenimiento * Sea: E −−−> Esfuerzo en coste C −−−> Complejidad C(P1) > C(P2) ======> E(P1) > E(P2) C(P1 + P2) > C(P1) + C(P2) || \/ E(P1 + P2) > E(P1) + E(P2) * Nos lleva − Cuantos más módulos mejor ===> mayor sencillez 125 − Contingencia: interfaces entre módulos − Problema: buscar M (nº de módulos) adecuado Abstracción * Es una herramienta intelectual que permite trabajar con con− ceptos y términos que son familiares al entorno independiente mente de los detalles de bajo nivel * La abstracción es una medida inversa al refinamiento (dis− curren parejos) * De hecho cada fase de la ingeniería del software es un refi namiento del nivel de abstracción del producto. Ocultación_de_la_información * Concepto asociado al de modularidad. * Consiste en especificar y diseñar los módulos, de forma que la información (procedimientos y datos) contenida por cada mó dulo sea inaccesible a otros módulos que no la necesiten. * Esto implica que el diseño modular debe realizarse de tal manera que el conjunto de módulos (estructura) se comuniquen unos con otros sólo por la información que necesiten para lo− grar la función asignada. La Ocultación de información como criterio de diseño favorece − Evitar propagación de errores − Modificaciones (prueba) − Modificaciones (mantenimiento) Diseño_modular_efectivo * El enfoque modular sirve para: − Deducir complejidad (no solo procedimental) 126 − Facilitar mantenimiento − Facilitar la implementación − Favorecer el paralelismo * De hecho este enfoque es aceptado en todas las disciplinas de ingeniería * Así el diseño arquitectónico tiene como objetivo producir sistemas modulares bien estructurados * Un módulo puede ser visto como una entidad definida que tie ne las siguientes características: − Los módulos contienen: − Instrucciones − Lógica de proceso − estructuras de datos − Los módulos pueden ser compilados aparte y guardarse en bibliotecas − Los módulos pueden quedar incluidos dentro de un programa − Los segmentos de un módulo pueden ser utilizados por la invocación de un nombre con algunos parámetros − Los módulos pueden usar otros módulos * Para mejor comprender esto, es necesario conocer las carac− terísticas operacionales de los módulos, derivados de los con ceptos de: − Abstrcción − Ocultación de la información * Estas características operacionales son: − Historia del tiempo de incorporación. 127 . Referida al momento en que le módulo se incorpora al software − En compilación − En ejecución − Mecanismos de activación Referido a módulos externos y a como son activados − Call − Interrupción − Camino de control Referido a la forma en la que el módulo se ejecuta inter− namente − Convencionales: un punto de entrada y uno de salida. Secuencial − Reentrante:(tareas concurrentes) El módulo no puede modificarse asimismo * Vistas las caracteristicas operacionales de los módulos, veamos una categorización de los módulos en una estructura software − Secuencial: Características: − Los más comunes − Se ejecutan sin interrupción − Internos o externos − Incremental/o corrutinas: Características: − Pueden ser interrumpidos 128 − Se restablecen en el punto de interrupción − Mantienen puntero para su reinicio − Utiles para sistemas conducidos por interrupcio− nes − Paralelos/o conrrutinas Características: − Se ejecutan simultáneamente con otros en entor− nos de multiprocesadores concurrentes. − Utiles para cálculos de alta velocidad que nece− sitan dos o más C.P.U trabajando en paralelo. * Los dos últimos requieren métodos de diseño especiales des− de las primeras fases de desarrollo, por no poder aplicarse una estructura típica de jerarquía de control. * Una característica fundamental en un módulo, esta contenida en el concepto de Independencia Funcional, que es una deriva− ción de los conceptos de: − Modularidad − Abstracción − Ocultamiento de la información y que consiste en desarrollar módulos con una función clara, es decir, que se enfoque a un requerimiento específico y que tenga la menor interacción con otros módulos, es decir, que la interface con los otros módulos (cuando deba existir) sea lo más sencilla posible * La independencia funcional de un módulo es muy importante debido a: 129 − Facilidad de desarrollo. Su función puede ser compartida con sencillas interfaces − Facilidad de prueba − Facilidad de mantenimiento − Limitación de los efectos secundarios en la modificación tanto de diseño como de código − Reducción de la propagación de errores − Reutilización de módulos * Se puede decir que: Independencia : clave de un buen diseño Buen diseño: clave de la calidad del software * La indepencia funcional se mide por dos criterios cualitati vos: − Cohesión: − Es una extensión del concepto de ocultación de la in formación. − La cohesión interna de un modulo se mide en términos de la fuerza de unión de los elementos dentro de un módulo − Un módulo coherente ejecuta una tarea sencilla(mejor única) en un procedimiento software, requiriendo po− ca interación (la menor) con procedimientos que se ejecutan en otra parte del programa. − La cohesión puede representarse en una banda que va desde la mas baja a la más alta − Siempre se busca la cohesión más alta 130 − Coincidental: los elementos dentro de un módulo no tienen relación aparente entre ellos ( modulariza− ción por segmentación) − Lógica: los elementos están relacionados lógicamente (módulo que ejecute todas E/S; Módulo general para edición de datos) − Temporal: están más altos que los anteriores debido a que todas las funciones se realizan al mismo tiempo ( módulo de inicialización de un programa o sistema) − Procedimental: Cuando los elementos de procesamiento están relacionados y deben ejecutarse en un orden específico (Stock: calculo B.M. y calculo reposición) − De comunicación: Cuando los elementos de procesamien to se centran sobre la misma estructura de datos. (Display en pantalla e imprimir fichero) − Secuencial: Cuando la salida de un elemento es la en trada para el siguiente.(leer siguiente , actualizar maestro) Normalmente tiene parecido con la estructu− ra del problema. − Funcional : cuando los elementos de procesamiento están referidos al desempeño de una sóla función (calcular el cubo, determinar si primo) − Acoplamiento − Es una medida cualitativa de la interconexión entre los módulos en una estructura de programas. 131 − Un módulo busca siempre el menor acoplamiento − El acoplamiento depende de: − La complejidad de la interface − El punto en el que se hace una entrada o referen cia a un módulo − Los datos que pasan a través de la interface. − El acoplamiento puede representarse en una banda que va desde la más baja a la más alta. − Sin acoplamiento directo: cuando los módulos no tie− nen conexión entre si. (Fig 6.13) − Acoplamiento de datos:cuando la interfaz es sencilla Se pasan datos simples con correspondencia de uno a uno. (Fig.6.13) − Por estampado: cuando la interfaz del módulo pasa una parte de la estructura de datos en vez de datos simples. − De control: cuando la interfaz pasa datos de control − Externo: cuando los módulos están ligados a un entor no externo al software (E/S por medio de comunicacio nes, dispositivos, formateos) − Común: cuando varios módulos referencian una misma área de datos comunes (Fig. 6.15) − Por contenido: cuando un módulo modifica los valores locales o las instrucciones de otro módulo. Diseño_y_la_calidad_del_software * La importancia del diseño es tal, que sin un buen diseño no 132 existe un buen sistema. * El diseño es tan importante, que en el se basa la calidad del desarrollo de un sistema, debido a: − Es el único medio para trasladar con precisión los re− querimientos del cliente en un producto o sistema acaba do − Proporciona las representaciones del software que pue− den establecerse para conseguir un producto con calidad − Sirve como base para el resto de los pasos del desarro− llo (código,pruebas) − Facilita el mantenimiento − Permite las revisiones técnicas formales. * En términos generales un diseño debe de mostrar entre otras las siguientes características: − Una organización jerárquica que haga un uso eficiente del control entre los elementos del software. − Debe ser modular. Cada módulo debe realizar funciones específicas − Un diseño debe contener una representación distinta y separable entre datos y procedimientos − Debe conducir a módulos que muestren las máximas carac− terísticas de independencia funcional − Debe derivarse mediante un método repetible que este conducido por la información obtenida de la fase de aná lisis de requerimientos. Notaciones_de_diseño 133 * Hay muchas notaciones diferentes * Cada una de ellas puede ser adecuada a diferentes niveles de diseño o a áreas de aplicación. * Las notaciones de diseño sirven para: − Evaluar − Comparar − Probar − Comunicar * Algunas de estas características son: − Diagramas de flujo de datos (D.F.D). . Se utilizan para describir un diseño de sistemas de alto nivel. . Muestran como se transforman los datos al pasar de un componente a otro del sistema. − Diagramas de estructura (D.E.) . Son gráficas de jerarquía que muestran la relación es tructural de los componentes de un sistema software . Son útiles para descubrir el diseño de alto nivel − Lenguaje para la descripción del diseño . Es una notación con algunos atributos de los lengua− jes de programación . Adecuado para describir operaciones de control y de diseño detallado * Estas tres notaciones son complementarias Atributos_de_las_notaciones_de_diseño − Modularidad: debe soportar el desarrollo de software modular 134 − Simplicidad global: tiene que ser facil de: − Aprender − Usar − Leer − Facilidad de edición: que la representación del diseño pueda ser editado. Facilitara tanto su estudio/comprensión como la modificación del diseño procedimental. − Legible por la máquina − Mantenimiento: cualquier mantenimiento siempre implica modi− ficación de la representación del diseño procedimental. − Exigencia de estructura: notaciones que hagan uso sólo de construcciones estructuradas (programacion estructurada) − Procesamiento automático − Representación de los datos : facilidad para representar datos locales y globales − Verificación lógica: debe reforzar la facilidad para verifi cación lógica − Disposición para la codificación: que el diseño procedimen− tal se convierta con facilidad en Código. Lenguaje_de_diseño_de_programas * Un lenguaje de diseño de programas también llamado inglés estructurado o pseudocódigo, es un lenguaje misto que utiliza el vocabulario de un lenguaje (español,ingles) y la sintaxis general de otro (lenguaje programación estructurada) * La diferencia con un lenguaje de programación estriba en el uso de texto narrativo insertado directamente dentro de las 135 sentencias del lenguaje de diseño de programas * Una sintaxis básica para un lenguaje de diseño de programas debe incluir: − Definición de subprograma − Descripción de interfaces − Declaración y tipificación de datos − Técnicas para estructurar en bloques − Construcciones de condición − Construcciones repetitivas − Construcciones de E/S * Ademas debe tener las siguientes características: − Una sintaxis fija de palabras clave que den todas las construcciones estructuradas, declaraciones de datos, y características de modularidad − Una sintaxis libre en lenguaje natural que describa las características de procesamiento − Facilidades para la declaración de estructuras de da− tos tanto sencillas como complejas − Una definición de subprogramas y técnicas de llamada que soporten los distintos modos de descripción de in− terfaces Tema 13 −− TÉCNICAS DE PRUEBA DEL SOFTWARE * La prueba no puede asegurar que no hay fallos en el pro− ducto software; solo puede demostrar que hay fallos en el. * La prueba constituye el último elemento critico para la garantía de la calidad. * Representa el último repaso de las especificaciones del: 136 − Diseño − Codificación * Las pruebas son imprescindibles, debido a que el software representa (en su conjunto de actividades − desarrollo y man− tenimiento) el mayor coste de un sistema basado en computado− ra * Recordamos que en la distribución de esfuerzos, asignamos a la prueba el 40% del coste de desarrollo. Para sistemas críti cos puede representar hasta cinco veces más que el resto del coste. Fundamentos_de_la_prueba_del_software * La prueba representa una contradicción en el trabajo del in geniero del software. * Hasta ahora, ha intentado construir un producto software (definición/desarrollo), materializado en la generación de có digo. * Ahora tiene que "demostrar" su calidad, es decir, realizar pruebas. * La prueba intenta "derribar" el software producido, por lo que puede ser vista como una actividad destructiva en vez de constructiva. Objetivos_de_la_prueba * Es diseñar pruebas que de forma sistemática descubran dife− rentes clases de errores con el menor esfuerzo y coste posi− ble. * Por lo que podemos decir: 137 − Es un proceso de ejecución de un programa para descubrir errores − Un buen caso de prueba es aquel que tiene una alta proba bilidad de mostrar un error no descubierto hasta enton− ces. − Una prueba tiene éxito si descubre algún error. * Esto lleva a cambiar uno de los conceptos mas erróneamente extendidos, de que una prueba tiene éxito si no se detectan errores. * Las pruebas proporcionan otras ventajas, que son las si− guientes: − Si las funciones del software se corresponden a las espe cificaciones − Si se alcanzan los requerimientos de rendimiento − Proporcionan una indicación de la fiabilidad − Indice de la calidad del software como un todo − Documentación exhaustiva de las pruebas realizadas − Optimizan el mantenimiento Flujo_de_información_de_la_prueba * Hay dos clases de entrada: − Configuración software (incluye para este paso) − Especificación de requerimientos − Especificación de diseño − Configuración de prueba − Plan de prueba (Q) − Procedimiento de prueba (C) 138 − Casos de prueba − Resultados esperados * Cuando los resultados obtenidos no se corresponden con los esperados implica errores y comienza el proceso de depura− ción. * En el paso de evaluación es donde se determina la calidad y fiabilidad del software debido a: − Existen errores serios implica modificaciones en reque− rimientos, diseño, lo que implica fiabilidad y calidad en duda y posteriores pruebas. − Existe errores sencillos, lo que implica: − Calidad y fiabilidad aceptables − Pruebas inadecuadas − No existen errores, lo que implica al menos la duda de que no se han realizado las pruebas adecuadas y que los errores (si existen) serán descubiertos por el usuario. Diseño_de_los_casos_de_prueba * En base a las características del producto o el área de aplicación, el diseño de los casos de prueba puede requerir tanto esfuerzo como el propio diseño del producto. * Hay dos enfoques para probar el producto: − Conociendo la función específica para la que Fue diseña do el producto, se pueden llevar a cabo pruebas que de− muestren que cada función es completamente operativa. A este tipo de pruebas se las denomina de "Caja negra" − Conociendo el funcionamiento del producto se pueden de− 139 sarrollar pruebas que aseguren que todos los componen− tes encajan, es decir, que la operación interna se ajus ta a las especificaciones y que todos los componentes internos son comprobados de forma adecuada. A este tipo de pruebas se la denomina de "Caja blanca". * Veamos cada uno de estos tipos de prueba Prueba_de_la_caja_blanca * Se basa en el examen de los detalles procedimentales. * Se comprueban los caminos lógicos con casos de prueba que ejecutan conjuntos específicos de condiciones y/o bucles. * Se puede examinar el programa en varios puntos para confir− mar si el estado real coincide con el esperado * Utiliza la estructura de control del diseño procedimental para derivar los casos de prueba. * Estos casos de prueba garantizan: − Se ejercitan por lo menos una vez todos los caminos inde pendientes de cada módulo − Se ejecutan todas las decisiones lógicas en sus vertien− tes verdadera y falsa. − Se ejecutan todos los bucles en sus límites y con sus lí− mites operacionales. − Se usan las estructuras de datos internas para asegurar su validez * Parece claro pensar, que si se efectuasen pruebas de caja blanca exhaustivas,nuestro software quedaría perfectamente pro dado. El problema estriba en el nº de pruebas que habría que 140 realizar (recordemos "menor coste y esfuerzo") Prueba_del_camino_básico * Es una técnica de caja blanca * Permite derivar una medida de complejidad lógica de un dise ño procedural, y usar esta medida para definir el conjunto bá sico de caminos de ejecución. * Dado que las pruebas de caja blanca utilizan la estructura de control del diseño procedimental, esta debe ser traducida en una representación de flujo de control que nos permita de− rivar los casos de prueba. * Dicha notación se denomina grafo de flujo o grafo del pro− grama. * Cada nodo representa una o más sentencias procedimentales. * Un nodo puede corresponder a una secuencia de cuadros de proceso y a un rombo de decisión. * Las aristas (flechas grafo) representan el flujo de control * Una arista debe terminar en un nodo, aunque este no repre− sente ninguna sentencia procedural (notación/vacias). * Regiones son las áreas delimitadas por una arista y un nodo * Cuando en el diseño procedural existen condiciones compues− tas se crea un nodo para cada una de las condiciones,llamándo se predicados * Complejidad_ciclomática * Es una medida del software que proporciona una medición cuantitativa de la complejidad lógica de un programa. * En el contexto del medio de prueba del camino básico,la com 141 plejidad ciclomática define el número de caminos independien− tes del conjunto básico del programa. * Camino independiente es cualquier camino del programa que introduce por lo menos un nuevo conjunto de sentencias o una nueva condición * Proporciona por tanto el límite superior del nº de pruebas que se deben realizar para asegurar que se ejecutan al menos una vez cada sentencia del programa * La complejidad ciclomática se obtiene de la siguiente forma: − C.C. = Nº Regiones grafo − C.C. = E − N + 2 E−−−−> aristas N−−−> nodo − C.C. = N + 1 N−−−> nodos * Derivación_de_los_casos_de_prueba 1.− Usando el diseño o el Código, dibujar el grafo de flujo 2.− Determinar la complejidad ciclomática del grafo de flujo resultante 3.− Determinar un conjunto básico de caminos linielmente inde− pendientes 4.− Confeccionar los casos de prueba que ejecutaran cada cami no del conjunto del conjunto básico. Prueba_de_bucles * Es una técnica de caja blanca * Se centra en la validez de las construcciones de bucles * Existen cuatro clases diferentes de bucles: − Simples (N−−> valor límite del bucle) . Saltar el bucle 142 . Pasar una sola vez . Pasar dos veces . Pasar M veces (M<N) (M>2) . Ejecutar N−1 , N , N+1 _________ |_______| | |<−−−−−−| ___\|/___ | |_______| | /\______| \/ | − Anidados . Aplicando la técnica de los simples implicaría un nº de pasos elevadísimo. . Un enfoque puede ser: . Empezar en el bucle más interior. Dejar el resto el resto en sus valores mínimos . Realizar las pruebas de los simples, manteniéndo los exteriores con sus valores mínimos. Añadir otras pruebas para valores fuera de ran go o excluidos . Avanzar hacia afuera manteniendo los externos en los valores mínimos y los internos en los comunes . Continuar hasta probar todos los bucles 143 | ___\|/___ |_______| |/______________ ____|\___ | |_______| | |/_________ | ____|\___ | | |_______| | | /\_________| | \/ | ____|____ | |_______| | /\______________| \/ | \|/ − Concatenados . Si los bucles son independientes aplicar técnicas simples . Si los bucles son dependientes, aplicar técnica de anidados _________ |_______| |/________ ____|\___ | 144 |_______| | /\________| \/ ____|____ |_______| |/________ |/_______ ____|\___ | ____|\___ | |_______| | |_______| | /\________| |/______|____ \/ |\ | | ______/ \ | | − No estructurados | \ / | | | |/_____ | | . Rediseñar __________________\ | |\ | | | / | / \____|_| | |\/|| | ____|____ | | |−>|_______| | | ||| / \____| | \/| || / \__________| \/ Prueba_de_la_caja_negra * Referida a las pruebas que se realizan sobre la interface 145 del software * Pretende demostrar: − Que las funciones software son operativas − Que la entrada se realiza adecuadamente − Que la salida es la correcta − Que la integridad de la información externa se mantiene * Los métodos de prueba de este tipo, se enfocan hacia los requerimientos funcionales del software, es decir, se derivan conjuntos de condiciones de entrada que ejecutan todos los re querimientos funcionales de un programa * Los errores que intentan detectar este tipo de pruebas son: − Funciones incorrectas o ausentes − Errores de interface − Errores en estructuras de datos o en accesos a bases de datos externas − Errores de rendimiento − Errores de inicialización y determinación * Las técnicas de prueba de caja negra tratan de derivar un conjunto de pruebas que satisfagan los siguientes criterios: − Casos de prueba que reducen, en un coeficiente menor que 1, el número de casos que se deben diseñar para alcanzar una prueba razonable − Casos de prueba que indiquen la ausencia o presencia de clases de errores en vez de errores específicos asociados a una prueba particular * Existen diversos métodos de prueba fundamentados sobre la 146 caja negra. Algunos de ellos son: Partición_equivalente * Consiste en dividir el dominio de la entrada de un programa en clases de datos de los que se pueden derivar casos de prue bas * Es decir define clases de errores, reduciendo de esta forma el nº total de casos de prueba que hay que desarrollar * La Partición equivalente se basa en la evaluación de clases de equivalencia, siendo esta el conjunto de estados validos o inválidos para condiciones de entrada(rango,valor numérico,es pecífico,booleana etc.) * Las clases de equivalencia se pueden definir: − Si una condición de entrada especifica un rango, se de− fine una clase de equivalencia válida y dos inválidas − Si una condición de entrada requiere valor específico, definir una clase equivalencia valida y dos invalidas − Si una condición de entrada especifica un miembro de un conjunto, definir una clase equivalencia válida y otra inválida − Si una condición de entrada es booleana, definir una clase equivalencia válida y otra invalida * La aplicación de estas normas para la Derivación de las cla ses de equivalencias, permiten desarrollar y ejecutar casos de prueba para cada elemento de datos del dominio de entrada. Análisis_de_valores_límite * Los errores tienden a darse más en los límites del dominio 147 de entrada que en el centro. * La técnica de prueba de análisis de valores límite deriva casos de prueba para ejercitar estos valores límite. * Se enfoca sobre: − Dominio de entrada − Dominio de salida * Es una prueba complementaria a la de partición equivalente * Las directrices para esta prueba son: − Si C.E. especifica un rango limitado por valores "A" y "B" se deben diseñar casos de prueba : "A", "B", "A−1", "A+1", "B−1", "B+1" (por debajo y por encima) − Si el C.E. especifica un nº de valores, implica desarro llar casos de prueba que: − Ejecuten valores máximos y mínimos − Ejecuten valores justo por debajo y por encima del máximo y mínimo − Aplicar las anteriores al dominio de salida − Si estructuras de datos tienen límites (ej. tabla 100 elementos) implica diseñar casos de prueba que ejerci− ten la estructura en sus limites. Tema 14 −− ESTRATEGIAS DE PRUEBA DE SOFTWARE * En el capítulo precedente se vieron dos métodos de pruebas con algunas de sus técnicas asociadas. * Hemos visto como se derivan casos de pruebas para detectar cierto tipo de errores. Pero el producto software que estamos construyendo, en la fase de pruebas requiere gran formalidad 148 para asegurar la calidad y fiabilidad del mismo. Esto lo pro− porciona la estrategia. * Una estrategia de prueba del software integra las técnicas de diseño de casos de prueba en una serie de pasos bien pla− nificados que llevan a una construcción correcta del softwa− re. * Una estrategia de prueba del software proporciona al − Programador − A la organización − Control de calidad − Cliente Un plan que describe: − Pasos a realizar como parte de la prueba − Cuando se deben planificar − Cuando se deben realizar − Cuanto esfuerzo, tiempo, y recursos serán requeridos * Ello implica que toda estrategia debe llevar: − Planificación de la prueba (Pl y Pr) − Diseño de casos de prueba − Ejecución de las pruebas − Evaluación de resultados * Por último decir que la estrategia debe acomodar dos térmi− nos contrapuestos: . Flexibilidad : que permita la creatividad y adaptabili− dad necesarias para adecuar las pruebas a todos los gran− des sistemas basados en software. 149 . Rigidez: que permita un razonable seguimiento de la pla− nificación y la gestión a medida que progresa el proyecto. Un_enfoque_estratégico_de_la_prueba_del_software * Como hemos visto la prueba comprende un conjunto de activi− dades que se pueden planificar por adelantado y llevar a cabo sistemáticamente. * Existen diferentes enfoques estratégicos, y todos muestran una serie de características generales: − La prueba comienza a nivel de módulo y avanza hacia el exterior hasta conseguir la integración del sistema com− pleto. − En diferentes puntos son adecuadas diferentes técnicas de prueba. − La prueba la realiza el desarrollador y/o un grupo inde− pendiente de prueba. − La prueba y la depuración son actividades diferentes,pe− ro esta puede formar parte de cualquier estrategia de prueba. * Una estrategia debe ser: − Una guía para el profesional − Un conjunto de referencias para el ejecutivo. − Debe permitir medir el progreso. Organización_de_la_prueba_del_software * Este enunciado esta referido a quien prueba el software. * Recordemos que el paso de prueba es destructivo, en contra− posición con el resto de pasos de la ingeniería del software, 150 que son constructivos. * Se plantea una contradicción. A una persona se le encarga un trabajo, que realiza con gran esfuerzo, y cuando lo ha construido, se le pide que lo "tire". * Por una parte, nadie mejor que el conoce el producto * Por otra parte, tendrá la suficiente "independencia" (eva− luación) a la hora de derivar pruebas para probar "eficiente− mente" el software. * También por otra parte, no podría suceder (dado que el es quien mejor conoce el producto) que derivase casos de prueba para aquello que el conoce perfectamente,pero es lo esperado? * Por tanto la cuestión es: ¿ Quien debe realizar las pruebas ? * Después de lo dicho podría deducirse: − El desarrollador no debe realizar el proceso de prueba − El software salvaguardado de extraños que puedan probar− lo exhaustivamente. − La prueba la realiza gente externa al equipo de trabajo y sólo aparecen durante la fase de prueba. * Cualquiera de esas premisas es falsa. El mejor enfoque es el mixto. * Por un lado están los desarrolladores que realizan las prue bas de unidad y comunmente las de integración * Una vez que la arquitectura del software está completa (probada), entra en juego el grupo independiente de prueba (G.I.P.) que realiza las pruebas de validación y del sistema. 151 * Así pues el objetivo ( desde la perspectiva humana) del Grupo independiente de prueba es eliminar el conflicto de in− tereses que se da en la prueba, es decir, que el constructor pruebe lo que ha construido. * El grupo independiente de prueba forma parte del equipo de trabajo, pues desde el análisis de requerimientos (criterios de validación) ya realiza el trabajo de plan y procedimientos de prueba. * El hecho de que forme parte del equipo (paralelismo) no im− plica que pertenezca a la parte de la organización del desa− rrollo del software. * Normalmente es independiente de esta, lo que proporciona la independencia que necesita. * El grupo independiente de prueba, aunque es el encargado de conducirla, mantiene un estrecho contacto con los desarrollado res, tanto para la consulta como para la corrección de erro− res (depuración). La corrección corre a cargo de los desarro− lladores ( organización matricial ). Una_estrategia_de_prueba_del_software * Una estrategia de prueba de software, puede ser vista como un proceso inverso a la construcción de un sistema. * Prueba de unidad: Se enfoca sobre cada una de las unidades del software tal y como están implementadas en código fuente. * Prueba de integración: Se enfoca sobre el diseño, es decir, la construcción de la arquitectura del software * Prueba de validación: se enfoca sobre la validación de los 152 requerimientos especificados en el E.R.S., comparándolos con el sistema construido. * Pruebas del sistema: se enfoca en probar el software y otros elementos como un todo. * Desde un punto de vista del procedimiento, la prueba, en el contexto de la ingeniería del software puede ser vista como una serie de cuatro pasos que se realizan secuencialmente. − Prueba de unidad, que implica: − Prueba de módulos − Desarrollo Procedimental − Caja blanca − Prueba de integración, que implica: − Prueba integración módulos − Desarrollo Arquitectónico − Caja blanca/caja negra − Prueba de validación, que implica: − Prueba sistema software − Arquitectura sistema − Caja negra − Prueba del sistema, que implica: − Fuera alcance − Ingenieria sistemas − Funcionalidad y rendimiento del sistema total Pruebas_de_unidad 1. Características * Se centra en la verificación de la menor unidad del diseño, 153 el módulo. * Usa la descripción del diseño procedimental como guía. * La complejidad relativa de las pruebas y errores esta limi− tada por el alcance establecido para la prueba. * Admite el paralelismo con otros módulos * Siempre usa técnicas de caja blanca. * Los casos que se derivan durante la prueba son orientados a: . Interface del módulo. Se prueba para asegurar que la información fluye correctamente hacia y desde la unidad de prueba. Es la primera que hay que realizar, pues si falla la interface el resto fallará. 1º ¿Es igual el número de parámetros de entrada al núme− ro de argumentos? 2º ¿Coinciden los atributos de los parámetros y los argu mentos? 3º ¿Coinciden los sistemas de unidades de los parámetros y de los argumentos? 4º ¿Es igual el número de argumentos transmitidos a los módulos de llamada que el número de los parámetros? 5º ¿Son iguales los atributos de los argumentos transmi− tidos a los módulos de llamada y los atributos de los parámetros? 6º ¿Son iguales los sistemas de unidades de los argumen− tos transmitidos a los módulos de llamada y de los pa 154 rámetros? 7º ¿Son correctos el número, los atributos y el orden de los argumentos de las funciones incorporadas? 8º ¿Existen referencias a parámetros que no estén asocia dos con el punto de entrada actual? 9º ¿Entran sólo argumentos alterados? 10º ¿Son consistentes las definiciones de variables globa les entre módulos? 11º ¿Se pasan las restricciones como argumentos? Cuando un módulo leve a cabo E/S externa, se deben llevar a cabo pruebas de interfaz adicionales. De nuevo de Myers: 1º ¿Son correctos los atributos de los archivos? 2º ¿Son correctas las sentencias de apertura? 3º ¿Cuadran las especificaciones de formato con las sen tencias de E/S? 4º ¿Cuadran el tamaño del buffer con el tamaño del re− gistro? 5º ¿Se abren los archivos antes usados? 6º ¿Se tienen en cuenta las condiciones de fin−de−archi vo? 7º ¿Se manejan los errores de E/S? 8º ¿Hay algún error textual en la información de salida Las estructuras de datos locales de cada módulo son una fuente potencial de errores: Se deben diseñar casos de prueba para descubrir errores de las siguientes ca− 155 tegorías: 1º Tipificación impropia o inconsistente 2º Iniciación o valores implícitos erróneos 3º Nombres de variables incorrectos(mal escri− tos o truncados) 4º Tipos de datos inconsistentes 5º Excepciones de desbordamiento por arriba o por debajo, o de direccionamiento. . Estructuras de datos locales. Para asegurar que los da tos mantenidos temporalmente conservan su integridad duran te todos los pasos de ejecución del algoritmo. Además también debe probar el impacto de los datos globales sobre el módulo. . Condiciones límite. Para asegurar que el módulo funcio na correctamente en los límites establecidos como res− tricciones de procesamiento. . Caminos independientes. (caminos básicos de la estruc− tura de control) Para asegurar que todas las instruccio− nes del módulo se ejecutan al menos una vez. Es fundamental este tipo de pruebas y está dirigi− do a detectar errores debido a incorrección en: − Cálculos − Comparaciones − Flujos de control. . Caminos de manejos de errores. Enfocados a verificar la terminación "limpia" cuando se detecta un error (Si 156 existe C.M.E). 2. Procedimientos de prueba de unidad * Una vez generado el Código a partir del diseño procedi− mental, es revisado y verificado en su sintaxis. El paso siguiente es la prueba. * Las directrices para la prueba la proporciona la infor− mación del diseño procedimental, permitiendo derivar los casos de prueba que con mayor probabilidad descubrirán errores de los tipos a los que esta orientada la prueba de unidad. * Cada caso de prueba debe tener especificados los resulta− dos esperados. * La prueba de unidad se centra sobre los módulos, y dado que estos no son programas independientes, es necesario de− sarrollar un software especial denominado "conductor" y/o resguardo. * Las funciones de estos elementos software son: − Conductor: Hace de programa principal cuya misión es: − Aceptar los casos de prueba − Pasarlos al módulo que se prueba − Imprimir los resultados que sean relevantes − Resguardo: su misión es: − Sustituir a un módulo subordinado − Usar su interface (del subordinado) − Realizar la mínima manipulación sobre los datos (no se está probando). 157 − Imprimir una verificación de la entrada y devuelve el control. * Ambos, conductores y resguardos, constituyen software adi− cional, y por tanto no se adjunta al software final, asimismo su escritura no requiere considerar aspectos formales. * A veces, algún módulo no es posible probarlo de forma sim− ple, con lo que se pospone su prueba hasta la realización de la de integración. * Para simplificar el trabajo, se deben mantener tanto los conductores como los resguardos lo más simple posible, y esto es favorecido ( grandemente) si los módulos fueron diseñados con un alto grado de cohesión. Pruebas_de_integración * Representan el segundo paso en la fase de prueba. * Se realiza, debido a que no es suficiente con las pruebas de unidad. Es necesario ensamblar los distintos componentes de la estructura. * La Prueba de integración es una técnica sistemática para construir la estructura de un programa al mismo tiempo que se realizan pruebas para detectar errores asociados con la interface. * El objetivo es coger los módulos probados en la prueba de unidad y construir una estructura de programa que coincida con lo dictado en el diseño. 1. Enfoques para la prueba de integración * Integración no incremental(BIG−BANG): consistente en la 158 construcción de la estructura de una sóla vez, es decir, combinando todos los módulos de una sóla vez . Es un enfoque poco operativo debido a que se tiende al caos por: − Se encuentran gran número de errores − La corrección se hace difícil porque es difícil ais− lar la causa de los errores con todo el programa en prueba. − Una vez corregidos los errores, aparecen otros y así sucesivamente en lo que asemeja un ciclo sin fin. * Integración incremental: es todo lo contrario a la no in− cremental. . Este enfoque es adecuado debido a: − La estructura se construye y prueba mediante peque− ños segmentos. − En ellos los errores son más fáciles de aislar − Facilita la prueba completa de las interfaces − Permite la sistematización de la prueba. . La integración incremental, admite diferentes estrate− gias: − Integración descendente . Consiste en construir la estructura del programa integrando módulos, moviendose hacia abajo por la jerarquía de control, comenzando con el módulo de control principal. . Los módulos subordinados se van incorporando en 159 la estructura bien en profundidad o bien en anchura . El proceso de integración descendente, consta de 5 pasos: − Se usa el módulo de control principal como con− ductor de la prueba, sustituyendo por reguardos todos los módulos subordinados − En base a la integración escogida (anchura−pro− fundidad) se van sustituyendo los resguardos por los módulos reales − Se efectúan pruebas cada vez que se integra un módulo − Después de realizar cada conjunto de pruebas, se reemplaza un resguardo por el módulo real − Se realiza la prueba de regresión (todas o algunas de las pruebas ya realizadas) para ase− gurar que no se han introducido nuevos errores. . Se repite el proceso desde el paso segundo, hasta que se haya construido toda la estructura del pro− grama. . La integración descendente permite verificar los puntos de decisión o de control principales antes en al proceso de prueba. . Lo que facilita el detectar los errores de con− trol que son fundamentales. . Así mismo si la integración es en profundidad,nos permite ir implementando y demostrando las funcio− 160 nes completas del software (A,B,M) . Este tipo de integración, puede presentar en la práctica problemas. El más frecuente se da cuando se necesitan procesamientos de los niveles más bajos para probar los superiores . Existen 3 tipos de opciones: − Retrasar las pruebas hasta que los resguardos sean reemplazados por módulos reales.Las conse− cuencias son: − Se pierde control sobre tipos de pruebas − Mayor dificultad en detectar las causas de de los errores. − Se pierde la formalidad de la aproximación descendente. − Desarrollar resguardos que realicen funciones limitadas que simulen el comportamiento de los módulos reales Las consecuencias son: − Mayor esfuerzo en crear software para pruebas − Integrar el software desde abajo, que represen− ta la otra estrategia de integración − Integración ascendente . Consiste en construir la estructura del software partiendo(y probando) de los módulos más bajos. . Esta estrategia puede ser acometida en cuatro pasos 161 − Se combinan los módulos de bajo nivel en grupos (construcciones) que realicen una subfunción del software. − Se implementa (no formal) un conductor (que es un programa de control de prueba) para contro− lar la E/S de los casos de prueba. − Se prueba el grupo (construcciones) − Se elimina los conductores, combinando los gru− pos y moviendose hacia arriba por la estructura del programa. 2.− Ventajas e inconvenientes de las estrategias * Normalmente, las ventajas de una representan inconvenientes de otra. * Descendente: . Ventajas: − Prueba antes los módulos de control − Permite demostrar funciones completas del software(A,B,M) . Desventajas − Necesidad de resguardos − Problemas asociados al procesamiento de módulos bajos * Ascendente: . Ventajas: − No necesita resguardos − Cuanto más progresa la prueba, se necesitan menos 162 conductores − Más facilidad para diseño de casos de prueba. . Desventajas: − Necesita conductores − El programa como unidad no existe hasta la integración del último módulo. * A la hora de realizar la prueba, la estrategia a escoger dependerá de las características del software. * Normalmente se puede escoger una estrategia combinada, de− nominada prueba sandwich, que consiste en aplicar la estrate− gia descendente para los niveles superiores (control) y la ascendente para los niveles inferiores (procesamiento). * Independientemente de la estrategia escogida, el encargado de la prueba debe identificar los módulos críticos del pro− grama, que se caracterizan por lo siguiente: − Dirigido a varios requerimientos del Software − Tiene un mayor nivel de control − Es complejo o propenso a errores − Tiene requerimientos de rendimiento muy definidos 3.− Criterios para las pruebas de integración * Constituyen criterios a probar con la correspondiente documentación − Integridad de la interface: consiste en probar cada in− terface interna y externa a medida que se incorpora cada módulo o grupo a la estructura − Validez funcional: consiste en realizar pruebas 163 diseñadas para descubrir errores funcionales − Seguridad de la información: consiste en realizar pruebas diseñadas para descubrir errores asociados con las estructuras de datos globales y locales − Rendimiento: consiste en realizar pruebas diseñadas para verificar los límites de rendimiento fijados durante el diseño del software Pruebas_de_validación * Constituye el tercer paso de prueba desde el punto de vista del procedimiento * Constituye el conjunto de pruebas a realizar para determi− nar si el software funciona de acuerdo a las espectativas ra− zonables del cliente. * Antes de comenzar la prueba de validación, el software está ensamblado como un paquete y ya se han encontrado y corregido los errores. * Esta prueba persigue confirmar que todos los componentes del software juntos producen la función y el rendimiento de− seado. * La pregunta a esto es ¿ quien determina que se ha logrado el objetivo? * La repuesta es la especificación de los requerimientos del software, que describe todos los atributos del software que son visibles al usuario (F,R). 1.− Criterios para la prueba de validación * La validación se consigue mediante pruebas de caja negra. 164 * El paso de prueba de validación esta alimentado por: − Plan de pruebas: que define las pruebas que se van a rea lizar − Procedimiento de prueba: que define los casos de prueba específicos que serán usados para confirmar la confor− midad con los requerimientos. − Software integrado − E.R.S. − Documentación del usuario. * El plan y procedimiento de prueba se ha diseñado para demos trar que: − Se satisfacen los requerimientos funcionales − Se satisfacen los requerimientos de rendimientos − Se satisfacen los otros requerimientos (portabilidad, recuperación de errores, mantenimiento, etc.) − Que la documentación es correcta * Una vez que se ha ejecutado cada caso de prueba, los re− sultados admiten dos conclusiones: − Las características de funcionamiento y/o rendimiento coinciden con las especificaciones y por tanto es co− rrecto − Se detectan desviaciones de las especificaciones, crean− do una lista de las diferencias, lo que implica a estas alturas renegociar. * Otra actividad que se tiene que finalizar con la prueba de validación la constituye el Repaso de la configuración del 165 Software, consistente en asegurar que todos los elementos de la configuración del software se han desarrollado adecuada− mente, están registrados, y tienen suficiente nivel de deta− lle para facilitar el mantenimiento Pruebas_alfa_y_beta * Es muy difícil Prever como un usuario final usará el soft− ware construido. También es difícil Prever como responderá frente al sistema * Debido a esto, se realizan una serie de pruebas, denomina− das de aceptación, que permiten al cliente validar todos los requerimientos. * Estas pruebas las realiza el usuario final en vez del equipo de desarrollo. * Estas pueden ser "informales" hasta "bien planificadas" (pueden durar semanas o meses) (paralelismo de sistemas) * Estas pruebas son: − Alfa: . La realiza el cliente en el lugar de desarrollo . Consiste en usar el software de forma natural, con el desarrollador controlando dicho proceso para: − Registro de errores − Problemática de uso . Es por lo que se dice que se desarrollan en un entorno controlado. − Beta: . Se realizan en uno o mas lugares del cliente por los 166 usuarios finales. . El desarrollador no está presente . La prueba es en vivo . El entorno no es controlado por el equipo de desarro− llo. . El cliente es el que registra todos los problemas (rea les originados) . Informa a intervalos Regulares al equipo de desarrollo Pruebas_de_sistema * Hasta ahora se ha probado el software que es un componente de un sistema. * Consiste en una serie de pruebas de integración y valida− ción del sistema "global". Proceso_de_depuración * Surge como consecuencia de una prueba efectiva, aunque no es una tarea de prueba consiste en eliminar los errores pro− ducidos por la ejecución de los casos de prueba, y se obtie− nen resultados que difieren de los esperados. * Muchas veces el error es un síntoma de una causa que está oculta (truncado). * El proceso de depuración trata de establecer la correspon− dencia del síntoma con la causa. * El proceso de depuración siempre tiene uno o dos resultados − Se encuentra la causa, se corrige y se elimina − No se encuentra la causa. Se debe sospechar.Diseñar caso de prueba que ayude a confirmar. Así sucesivamente hasta 167 que se encuentre (proceso de rastreo de la causa del error). * El proceso de depuración es difícil porque intervienen facto− res psicológicos: − Se ha cometido un error − Presión de tiempo − Evaluación − Habilidad personal − etc. * También tiene influencia las características de nuestro producto (lógico) y en particular con el diseño. * Algunas características de los errores nos facilitan algu− nas orientaciones: − El síntoma y la causa pueden ser remotos entre si (aco− plamiento) − El síntoma puede estar producido por algo que no es error (redondeos) − Puede ser difícil reproducir las condiciones de entrada (S.T.R) − El síntoma puede desaparecer (temporalmente) al corregir otro error − etc. Enfoques_de_la_depuración * Existen diversos enfoques para el proceso de depuración. − Fuerza bruta: probablemente el más común y menos efecti vo. 168 . Consiste en dejar que el ordenador encuentre error (volcados,write,etc) . Se espera que en toda información facilitada se encuen tre o bien el error, o bien algún indicio. . Se debe aplicar cuando el resto falla − Vuelta atrás: representa un enfoque efectivo, con gran éxito en programas pequeños. . Partiendo del lugar en el que se detecta el síntoma se recorre hacia atrás el código hasta que se identifica el error. . Si el programa es demasiado grande el número de cami− nos se hace "menos manejable". LA DOCUMENTACIÓN DEL PRODUCTO * La documentación así como el mantenimiento son partes tediosas en la construcción de un sistema, pero esenciales tanto para la producción como para el uso de los mismos. * De nada vale construir un sistema de software si: − No se puede comprender − Solo lo saben utilizar los realizadores − Si es difícil o imposible de mantener * Un sistema no se puede mantener, si no existe documentación * La documentación sirve para muchos propósitos: − Describir la manera de uso de un programa − La razón por la que se escribió − Las técnicas utilizadas en su construcción * A pesar de ello, suele ser ignorada, y en grandes sistemas puede requerir tanto esfuerzo como el propio desarrollo Documentación_del_software 169 * Independientemente de su aplicación, todos los grandes sistemas tienen asociada ingentes cantidades de documentación. * Puede clasificarse − De usuario − Del sistema * La información (Doc.) que se proporciona con el sistema tiene que satisfacer diversos requisitos: − Como usar el sistema − Como instalar y operar el sistema − Los requisitos y el diseño de todo el sistema − La aplicación del sistema y los procedimientos de prue− ba, para poder efectuar el mantenimiento * La documentación puede ser útil en cualquier etapa del ciclo de vida del sistema. * En general, todos los tipos de documentación necesitan índices, que permitan a quien consulte acceder con rapidez y seguridad a ella. * Sin indice un documento bueno puede "no" ser útil. Con índice un mal documento puede ser útil. Documentación_del_usuario * Está compuesta por todos los documentos relacionados con las funciones del sistema, sin referirse a la forma de aplicarlas. * Esta, suele ser el primer contacto que tienen los usuarios con el sistema, y debe proporcionar una visión inicial precisa del sistema. * No es necesario que todos los usuarios del sistema lean la mayoría o totalidad de la información para descubrir de forma sencilla como utilizar el sistema. * Ello obliga a que este estructurada de tal manera que el usuario pueda leerla con el nivel de detalle adecuado a sus necesidades. * Existen al menos cinco documentos que pueden agruparse bajo la denominación de documentación de usuario: 1º Descripción funcional sobre lo que puede hacer el sistema . No debe entrar en detalles ni es necesario que cubra todas las características. 170 . Debe proporcionar una visión general − Una visión general − Los requisitos − Breve descripción del propósito de los implantadores 2º Manual introductorio . Que describa en términos sencillos como iniciarse en el sistema, y como se puede utilizar. . También indica como salirse de un problema cuando algo falla. 3º Manual de referencia . Es el documento más importante sobre el uso del sistema. La característica de este es que debe ser completo, incluso es aceptable perder legibilidad en aras de la complitud. . Debe describir: − Ventajas del sistema − Uso de las mismas − Informes de error generado − Situaciones en las que se producen los errores 4º Documento de instalación . Proporciona detalles completos sobre la manera de instalar un sistema en un entorno particular. . Debe contener entre otras: − Como esta escrita la información − Formatos − Archivos que componen el sistema 171 − Configuración mínima de hardware − Archivos permanentes del sistema − Etc. 5º Guia del operador . Solo en el caso de que se requiera un operador del sistema . Describe como actuar cuando se produce cualquier si− tuación durante el uso del sistema . Describe mensajes a recibir y como responder a ellos * Existe una discusión acerca de quien debe realizar la docu− mentación: − Los ingenieros del software − Escritores técnicos profesionales * Si escritores técnicos profesionales implica para el ingeniero del software dedicarse al construcción del software. * Problema: comunicación * Realidad ingeniero del software. Posibilidad mixta. Documentación_del_sistema * Referido a todos los documentos que pertenecen a la aplica− ción del sistema. * Desde la especificación de requerimientos, pasando por el diseño hasta el plan de pruebas de aceptación final * Los documentos asociados al diseño y pruebas son esenciales si se desea comprender y mantener el sistema * De igual forma que la documentación de usuario, la del sis− tema debe estar estructurada con visiones generales que qué− re el usuario hasta las descripciones más detalladas de cada 172 aspecto. * La documentación del sistema debe incluir: − Definición de requisitos y (fundamentación asociada) − Especificación general de sistemas que muestre como se descomponen los requisitos en un conjunto de programas interrelacionados. − Por cada programa del sistema, una descripción de como se descompone el programa en componentes y una especifica− ción de cada componente − Por cada programa una descripción de su operación − Un plan de pruebas amplio que describa como se prueba ca− da unidad − Un plan de pruebas que muestre como se realizó la prueba de validación − Un plan de pruebas de aceptación diseñado con el usuario describiendo las pruebas necesarias para la aceptación del mismo * Cada uno de estos documentos es una representación distinta del mismo producto software. * Uno de los grandes problemas asociados al mantenimiento es asegurar que todas estas representaciones se correspondan con el sistema que representan. * Para ello las relaciones y dependencias se deben reflejar junto a ellos. * Lo mejor es la utilización de herramientas. Calidad_de_la_documentación 173 * La calidad de la documentación es tan importante como el propio programa * Sin la información de su uso o comprensión por ejemplo, la utilidad del sistema queda reducido (mantenimiento status) * Producir buena documentación, no es: − Fácil − Barato * Aspectos que ayudan a producir buenos documentos son los estandares para: − Producir − Revisar − Acomodar * los estandares deben describir con exactitud lo que: − Debe incluir − Notaciones a utilizar * Cada organización puede definir sus propios estandares y exigir que todos los documentos se ajusten a él Estilo_de_redacción * Uno de los factores más importantes en la calidad de la do− cumentación es la habilidad del redactor para elaborar una prosa técnica de forma clara y concisa * La buena documentación requiere buena redacción. * A la hora de realizar un documento, se debe: . Redactar, leer, criticar y volver a escribir repitiendo el proceso hasta que se obtiene el documento satisfactorio. * Es difícil definir un conjunto de reglas que determinen co− 174 mo realizar esta actividad * Unos principios generales pudieran ser: − Utilizar formas gramaticales activas en vez de pasivas. (verá un cursor / sera visto un cursor) − No usar frases largas que presenten varios hechos distintos, usar oraciones cortas. Cada oración puede ser asimilada, sin necesidad de retener varias partes de in− formación para comprender toda la oración − No referenciar información solo con el número de referen cia. Dar referencia y lo que cubre. ( 1.1 /1.1 Describe recursos humanos) − Detallar los hechos siempre que sea posible (como esta relación) mejor lista que frase − Si determinada descripción es compleja debe repetirse. A veces es adecuado presentar dos o mas descripciones de la misma cosa. − Ser concreto (B.Gracián) − Ser preciso y definir los términos utilizados. Hay tér− minos que tienen mas de un significado (Módulo,proceso) − Utilizar párrafos cortos. Como regla general, ningún pa− rrafo debe contener más de siete frases (limitaciones de memoria temporal, retención de información inmediata li− mitada. − Utilizar títulos y subtítulos. Asociados a una numera− ción consistente. − Utilizar construcciones gramaticales y ortografía correc 175 ta . No abusar infinitivos (al ver /cuando vea) . Las faltas irritan y restan credibilidad Como_desarrollar_documentación * Básicamente existen dos modelos: − Manual − Con herramientas (Ej. sistemas edición) * Las ventajas que conllevan la utilización de herramientas son: − La documentación siempre se tiene a mano − Es mas facil modificar y mantener los documentos lo que implica mayor probabilidad de mantener actualizada la documentación del proyecto − Se puede definir un formato para los documentos lo que implica mayor facilidad para la distribución − Los documentos se pueden compartir, varias personas pueden trabajar a la vez en la producción de un docu− mento − Se simplifica el empleo de los documentos − Es posible la recuperación automática de la información . Por ejemplo: recuperar todos los documentos que con− tengan una palabra clave en particular. Mantenimiento_de_la_documentación * A medida que se modifica un sistema, la documentación aso− ciada debe modificarse para reflejar los cambios en el sis− tema. 176 * Por desgracia esto no suele hacerse (al menos no formalmen− te), con lo que con el paso del tiempo la documentación no refleja la situación actual del sistema, lo que implica problemas tanto para el usuario como para las personas que realizan el mantenimiento * Cuando se hace un cambio en un programa debe reflejarse en todos los documentos afectados METODOLOGIA DE LA PROGRAMACION Universidad de La Coruña. Facultad de Informática. ¡Error!Marcador no definido. 177