Es el proceso cretivo de transformación del problema en una solución. Una vez que se analizan y especifican los requisitos, el diseño es la siguiente actividad técnica a realizar. Es independiente del modelo de procesos que se use. El diseño se centra en 4 áreas importantes:
- Datos
- Arquitectuas
- Interfaces
- Componentes
El diseño es la etapa, en la que se fomenta la calidad. Sin diseño se corre riesgo de construir un sistema inestable, y difícil de probar.
El diseño deberá implementar todos los requisitos explícitos del modelo de análisis y deberá ajustarse a los requeridos por el cliente. El diseño tiene que ser una guía comprensible para los que implemente en software y consencuentemente, los que den soporte al mismo.
Es tanto un proceso como un modelo. Es un proceso porque es una secuencia de pasos que el diseñador describe con el fin de construir el diseño del software. Es un modelo porque comienza con la totalidad, y luego refina.
-
Diseño de datos: Transforma el model del dominio obtenido del análisis, en estructuras de datos, objetos, relaciones, etc. Por ejemplo un diagrama de entidad relación.
-
Diseño arquitectónico: Define la relación entre los componentes más importantes del software para lograr los requisitos del sistema. La información puede derivarse de la especificación, del modelo de análisis y de la interacción de ls subsistemas definidos.
-
Diseño a nivel de componentes: Transforma los elementos estructurales de la arquitectura en una descripción procedimental de los componentes del software. La información obtenida del diseño de datos, sirven como base.
-
Diseño de interface: Describe la forma de comunicación dentro del mismo sistema, con otros sistemas y con las personas. Una interface implica flujo de información (datos o control) y comportamiento.
- Un diseño deberá presentar una estructura arquitectónica que:
- Se haya creado mediante patrones reconocibles.
- Que esté formado por componentes que exhiban características de buen diseño.
-
Un diseño deberá ser modular e independiente. El software deberá dividirse lógicamente en elementos que realicen funciones y subfunciones específicas.
-
Un diseño deberá contener distintas representaciones de datos, arquitectura, interfaces y componentes.
-
Un diseño deberá conducir a interfaces que reduzcan la complejidad de las conexiones entre módulos y con el entorno externo.
-
Debe comunicar de manera eficaz su significado.
- Se deben tener en cuenta enfoques alternativos.
- Deberá poderse rastrear hasta el modelo de análisis.
- No inventar nada que ya esté inventado.
- Minimizar la distancia intelectual entre el software y el problema.
- Uniformidad e integración.
- Admitir cambios.
- Deberá estructurarse para degradarse poco a poco, incluso cuando se enfrenta con datos, sucesos o condiciones de operaciones aberrantes.
- El diseño no es escribir código y escribir código no es diseñar.
- El diseño deberá evaluarse en función de la calidad mientras se va creando, no después de terminado.
- El diseño deberá revisarse para minimizar los errores conceptuales.
-
Abstracción: La noción de abstracción permite concentrarse en un problema a un nivel de generalización sin tener en cuenta los detalles irrelevantes de implementación. Existen 2 tipos de abstracción:
- Procedimental: Secuencia "nombrada" de instrucciones que tienen una funcionalidad específica. Ej. Una funcion o procedimiento.
- De Datos: Colección "nombrada" de datos que definen un objeto real. Por ejemplo, un registro que representa a una persona.
-
Arquitectura: Es la estructura general del software y las formas en que proporciona una integridad conceptual para un sistema.
-
Patrones: Describe una estructura de diseño que resulve un problema de diseño particular dentro de un contexto específico.
-
Modularidad: El software se divide en componentes nombrados y abordados por separado, llamados frecuentemente módulos, que se integran para satisfacer los requisitos del problema.
-
Ocultamiento de información: La información que esta dentro de un módulo no es accesible a otros que no la necesiten. Con esto se mantiene la independencia de los mismos.
-
Independencia Funcional: Se mide mediante cohesión y el acoplamiento entre los módulos. Se busca alta cohesión y bajo acoplamiento.
- Cohesión (Coherente): Un módulo es altamente cohesivo cuando lleva a cabo solo una tarea dentro del procedimiento y requiere poca interacción con el resto de los procedimientos. De lo contrario, es poco cohesivo cuando realiza tareas muy diferentes o sin relación entre ellas.
- Tipo de Cohesión:
- Funcional: Cuando las sentencias de un mismo módulo están relacionadas en el desarrollo de una única función (alta cohesión).
- Coincidental (Casual): Cuando las tareas llevadas a cabo no están relacionadas o tienen poca relación (baja cohesión).
- Lógica: Cuando las sentencias se relacionan lógicamente.
- Temporal: Cuando las sentencias deben ejecutarse en el mismo intervalo de tiempo.
- Procedimental: Cuando las sentencias tienen que ejecutarse en un orden específico.
- Comuniacional: Cuando los elementos de procesamiento se centran en los datos de entrada y salida.
- Acoplamiento: Es la medida de interconexión entre los módulos. Existen diferentes niveles de acoplamiento:
- Bajo: Acoplamiento de datos o de marca.
- Moderado: Acoplamiento de control.
- Alto: Acoplamiento común. externo o de contenido.
-
Refinamiento: El refinamiento es un proceso de elaboración. Con la abstracción son conceptos complementarios. La abstracción permite especificar procedimientos y datos sin considerar detalles de grado menor. El refinamiento ayuda a revelar los detalles de grado menor mientras se realiza el diseño.
-
Refactoring: Es una técnica de reorganización que simplifica el diseño de un componente sin cambiar su función o comportamiento. Cuando se refactoriza se busca redudancias, elemenos innecesarios, algoritmos o estructuras de datos que no aplican.
- Una estrategia de pruebas integra los métodos de diseño de los casos de prueba para lograr un software eficaz.
- La prueba es un conjunto de actividades que se planean con anticipación y se realizan de manera sistemática.
- Una estrategia de pruebas debe incluir tanto pruebas de alto como de bajo nivel.
- Son parte de la Verficación y Validación incluidas en el aseguramiento de la calidad del software.
Verificación: Comprobar que el software está de acuerdo con su especificación, donde se debe comprobar que satisface tanto los requermientos funcionales como los no funcionales.
Validación: El objetivo es asegurar que el software satisface las expectativas del cliente.
Aspectos estratégicos:
- Establecer explícitamente los objetivos de las pruebas.
- Comprender cuáles son los usuarios del software y desarollar un perfil para cada categoría.
- Plan de pruebas para ciclos rápidos.
- Construir un software robusto para probarse a sí mismo.
- Usar revisiones técnicas formales y efectivas antes de las pruebas.
- Desarrollar un enfoque de mejora continua para el proceso de pruebas.
-
Pruebas de unidad: Verifican que el componente funciona correctamente a partir del ingreso de diferentes casos de prueba. Los errores más comunes son detectados en estas pruebas.
- Se examinan las estructuras de datos locales
- Se prueban condiciones límite.
- Se ejercitan todos los caminos independientes. Se utiliza un controlador independiente para cada caso. Este es un programa que recibe las pruebas, las envía al modulo y muestra el resultado.
-
Pruebas de integración: Verifican que los componentes trabajan correctamente en forma conjunta.
- Se toman los componentes que han pasado las pruebas de unidad y se los combina.
- Estos tests sirven ya que los datos podrían perderse en alguna interfaz.
- La combinación de los mismos podría traer efectos que no son los esperados.
La integración puede ser: * Descendente: Inician por el programa principal. * En profundidad: Integra todos los módulos de un camino de control principal de la estructura * En anchura: Incorpora todos los módulos directamente subordinados a cada nivel. * Ascendente: Se empieza la prueba con los módulos atómicos. Datos que los módulos se integran de abajo hacia arriba, el proceso requerido de los módulos subordinados siempre está disponisble, pero no asi los conductores.
-
Pruebas de regresión: Esta prueba consiste en volver a ejecutar un subconjunto de pruebas que se han llevado a cabo anteriormente para asegurarse de que los cambios que se aplicaron no han propagado efectos colaterales no deseados.
-
Pruebas de validación: Proporcionan una seguridad final de que el software satisface los requermientos.
- Revisión de la configuración: Asegurar que todos los elementos de la configuración del software se hallan desarrollado apropiadamente.
- Pruebas de aceptación (ALFA y BETA): Las realiza el usuario final en lugar del responsable del desarrollo.
- Pruebas ALFA: Desarrolladores con clientes antes de liberar el producto.
- Pruebas BETA: Seleccionando los clientes que efectuarán la prueba. El desarrollador no se encuentra presente.
-
Pruebas deñ sistema: Verifica que cada elemento encaja de forma adecuada y que se alcanza la funcionalidad y el rendimiento del sistema total.
- Pruebas de recuperación: Se controla que el software se recupere ante fallas. Generalmente se fuerza el fallo.
- Pruebas de seguridad: Se comprueban los mecanismos de protección integrados.
- Pruebas de resistencia: Se diseñan para enfrentar a los programas a situaciones anormales.
- Pruebas de rendimiento: Se prueba el sistema en tiempo de ejecución. A veces va emparejada con la prueba de resistencia.
Es el proceso de identificar y corregir errores en programas informáticos. La depuración no es una prueba pero siempre ocurre como consecuencia de una. Los enfoques de la depuración son:
- Diseñar programas de prueba adicionales que repitan la falla y ayuden a descubrir la fuente de la falla.
- Rastrear el programa manualmente y simular la ejecución.
- Usar herramientas interactivas.
- Una vez corregido el error debe reevaluarse el sistema. (Prueba de regresión)
A medida que el software se hace más complejo, crece también la necesidad de enfoques de pruebas especializados.
- Pruebas de interfaces gráficas.
- Pruebas de arquitecturas cliente-servidor: Esto incluye pruebas de servidor, de bases de datos, de transacciones de comunicacion de red.
- Pruebas de la documentación y ayuda: Es importante para la aceptación del programa. Revisar la claridad. Usar la documentación junto con el programa real.
El diseño de los casos de prueba, además de los convenciales deben incluir el manejo de eventos (interrupciones), temporización de los datos, el paralelismo entre las tareas, etc.
- Pruebas de tareas
- Probar las tareas de forma independientes, en búsqueda de errores lógicos y funcionamiento (no de tiempo ni de comportamiento).
- Pruebas de comportamiento
- Simular el comportamiento del sistema de tiempo real y examinarlo como consecuencia de eventos
- Pruebas inter-tareas
- Se prueban las tareas asincrónicas entre las cuales se sabe que hay comunicación
- Pruebas de sistemas
- Se prueba el software y hardware integrados.
Atención del sistema a lo largo de su evolución despues de entregado. En ocasiones debe realizarse mantenimiento a sistemas "heredados". Consta de soluciones de errores, añadir nuevas mejoras o optimizar lo actual. Esto provoca altos costos adicionales, y el fenómeno de la Barrera de mantenimiento.
Es necesario evaluar cuándo es conveniente cerrar el ciclo de vida de ese sitema y reemplazarlo por otro.
- La decisión se toma en función del costo del ciclo de vida del viejo proyecto y la estimación del nuevo proyecto.
- En ocasiones la complejidad del sistema crece por los cambios.
Su consecuencia son:
- Reducción de tiempo de otros desarrollos.
- Posible reducción de la calidad.
- A veces los cambios provocan reiniciar fases de análisis, diseño e implementación.
- Los errores provocan insatisfacción en el cliente.
- No es un trabajo que de gusto hacerlo
- No siempre en el diseño preveen los cambios
- Es difícil comprender código ajeno, mas aún sin documentación o con documentación inadecuada.
- Análisis: Comprender el alcance y el efecto de la modificación.
- Diseño: Rediseñar para incorporar los cambios.
- Implementación: Recodificar y actualizar la documentación interna del código.
- Prueba: Revalidar el software.
- Actualizar la documentación de apoyo.
- Distribuir e instalar las nuevas versiones.
- Mantenimiento correctivo:
- Diagnóstico y corrección de errores.
- Mantenimiento adaptativo:
- Modificación del software para interaccionar correctamente con el entorno.
- Mantenimiento perfectivo:
- Mejoras al sistemas.
- Mantenimiento preventivo:
- Se efectúa antes que haya una petición, para facilitar el futuro mantenimiento. Se aprovecha el conocimiento sobre el producto.
Es un desafío del mantenimiento, intentando aumentar la calidad global de un sistema existente. Existen diferentes tipo de rejuvenicimiento como:
- Re-Documentación: Representa un análisis del código para producir la documentación del sistema.
- Re-Estructuración: Se reestructura el software para hacerlo más fácil de entender.
- Ingeniería Inversa: Parte del código fuente y recupera el diseño y en ocasiones la especificación.
- Re-Ingeniería: Extensión de la ingeniería inversa. Produce un nuevo fuente correctamente estructurado, mejorando la calidad sin cambiar la funcionalidad.