Planificación Temporal del Proyecto

Esta planificación se puede visualizar desde dos perspectivas:

  • Fecha de Lanzamiento Fija: La fecha de lanzamiento del sistema ya ha sido establecida. Es necesario distribuir el esfuerzo dentro del marco prescrito.
  • Límites Cronológicos Aproximados: Se han estudiado unos límites cronológicos aproximados, pero la organización del sistema fijará la fecha final.

¿Son Antiproductivos los Equipos de Trabajo?

La respuesta es NO, considerando que la comunicación servirá para mejorar la calidad y facilitar el mantenimiento del software.

Definición de Tareas y Paralelismo

Cuando en un proyecto de ingeniería de software están involucradas más de una persona, es posible que las actividades de desarrollo se realicen en forma paralela.

Seguimiento y Control del Proyecto

“Los proyectos de software se salen de la agenda día a día”. Un día no afectará la agenda, pero los días se acumulan y al final esos pequeños retrasos pueden producir grandes problemas.

Por lo anterior, el seguimiento es fundamental para el éxito del proyecto y se puede desarrollar de las siguientes formas:

  • Reuniones periódicas sobre el estado del proyecto, donde cada miembro del equipo informa de los progresos y de los problemas.
  • Evaluación de los resultados de todas las revisiones realizadas en todo el proceso de ingeniería.
  • Determinar si los hitos formales del proyecto se han alcanzado en la fecha programada.
  • Comparar la fecha de comienzo real con la fecha de comienzo planeada, para cada tarea del proyecto.
  • Reunirse informalmente con los técnicos para conocer sus valoraciones subjetivas acerca del progreso y los problemas.

Los gestores de proyecto utilizan el control para administrar los recursos del proyecto, para hacer frente a los problemas y para dirigir al personal del proyecto.

Reingeniería del Software

Casi todas las empresas que utilizan algún sistema de información se encuentran con que el software “envejece”. Muchos programas que son cruciales para la operación de la organización se han vuelto mucho más costosos y difíciles de mantener. Incluso, se llega al grado de implementar “parches” sobre “parches”, logrando un funcionamiento ineficiente, fallas concurrentes y que no responden a las necesidades del usuario.

Para Hacer una Reingeniería Considerar

  • Seleccionar aquellos programas que actualmente se están utilizando mucho y que sea probable que se sigan utilizando durante los próximos 5 o 10 años.
  • Estimar el coste anual de mantenimiento de los programas seleccionados. Este coste debe incluir la corrección de errores, la adaptación al entorno y las mejoras funcionales.
  • Asignar prioridades a los programas seleccionados según su importancia y su coste de mantenimiento.
  • Estimar el coste de la reingeniería de los programas seleccionados.
  • Para cada programa seleccionado, comparar el coste de mantenimiento con el coste de reingeniería.
  • Calcular el tiempo requerido para que empiece a recuperarse la inversión en reingeniería.
  • Considerar ciertos asuntos intangibles como la mejora en la facilidad de cambio, la mejora en la fiabilidad, el mayor rendimiento del sistema y la mejora en las interfaces de usuario.
  • Comenzar la reingeniería a partir de un programa sencillo.
  • Con las lecciones aprendidas en el paso anterior, comenzar la estrategia para los siguientes programas.

Plan de Proyecto del Software

El Plan de Proyecto del Software es la culminación de la planificación y proporciona una línea base con información de costes y agenda que se utilizará a lo largo del desarrollo del proyecto.

Este plan de proyecto es un documento breve que debe incluir:

  • Comunicar el ámbito y los recursos a los gestores del software, al personal técnico y a los clientes.
  • Definir los riesgos y sugerir técnicas de aversión al riesgo.
  • Definir el coste y la agenda de la revisión de la gestión.
  • Proporcionar un enfoque global del desarrollo del software para la gente involucrada en el proyecto.

Diseño del Software

El diseño es la primera de tres actividades técnicas: diseño, codificación y pruebas. Por definición, diseño es el proceso de aplicar distintas técnicas y principios con el propósito de definir un dispositivo, proceso o sistema con los suficientes detalles como para permitir su realización física.

Existen tres metodologías de diseño:

  • Diseño de Datos: Transforma el modelo del campo de información, creado durante el análisis, en las estructuras de datos que se van a requerir para implementar el software.
  • Diseño Arquitectónico: Define las relaciones entre los principales elementos estructurales del programa.
  • Diseño Procedimental: Transforma los elementos estructurales en una descripción procedimental del software.

En la fase de diseño es donde se deben tomar decisiones que afectarán finalmente el éxito de la implementación del software y su facilidad de mantenimiento.

El Proceso de Diseño

El diseño del software se realiza en dos pasos:

  • Diseño Preliminar: Se centra en la transformación de los requisitos en los datos y la arquitectura del software.
  • Diseño Detallado: Se ocupa del refinamiento de la representación arquitectónica que lleva a una estructura de datos detallada y a las representaciones algorítmicas del software.

Fundamentos del Diseño

Durante los últimos tiempos se han desarrollado un conjunto de conceptos fundamentales para el diseño del software. Estos fundamentos entregan al diseñador una base sobre la que puedan aplicarse metodologías de diseño más o menos sofisticadas.

  • Abstracción: La abstracción de datos, como la abstracción procedimental, permite al diseñador representar un objeto de datos a diferentes niveles de detalle.
  • Refinamiento: El refinamiento es realmente un proceso de elaboración. Comenzamos con una declaración de la función definida a un nivel superior de abstracción.
  • Modularidad: Toda arquitectura implica modularidad; esto es, el software se divide en componentes con nombres y ubicaciones determinadas, que se denominan módulos, y que se integran para satisfacer los requisitos del software.
  • Arquitectura del Software: Se refiere a dos características importantes del software:
    • La estructura jerárquica de los componentes procedimentales (módulos).
    • La estructura de los datos.
  • Jerarquía de Control (Estructura de Programa): Representa la organización, regularmente jerárquica, de los componentes del sistema (módulos).
  • Estructura de Datos: Es una representación de la relación lógica existente entre los elementos individuales de datos.
  • Procedimientos del Software: Se centra sobre los detalles de procesamiento de cada módulo individual.
  • Ocultamiento de Información: Está orientado a que los módulos deben especificarse y diseñarse de forma que la información (procedimientos y datos) contenida dentro de un módulo sea inaccesible a otros módulos que no necesiten tal información.

Calidad del Software

¿Qué es la Calidad del Software?

Es la concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente.

La calidad del software hace hincapié en tres puntos importantes:

  • Los requisitos del software son las medidas de la calidad. La falta de concordancia con los requisitos es una falta de calidad.
  • Los estándares específicos definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del software. Si no se siguen esos criterios, casi siempre habrá falta de calidad.
  • El software se debe ajustar a ciertos requisitos implícitos (buen mantenimiento, por ejemplo); si no es así, la calidad queda en entredicho.

Los factores de calidad se centran en tres aspectos importantes:

  • Sus características operativas.
  • Su capacidad de soportar los cambios.
  • Su adaptabilidad a nuevos entornos.

Factores de Calidad

Algunos de los factores a considerar pueden ser:

  • Facilidad de Mantenimiento: ¿Puedo corregirlo?
  • Flexibilidad: ¿Puedo cambiarlo?
  • Facilidad de Prueba: ¿Puedo probarlo?
  • Portabilidad: ¿Podré usarlo en otra máquina?
  • Reusabilidad: ¿Podré reutilizar alguna parte del software?
  • Interoperabilidad: ¿Podré hacerlo interactuar con otro sistema?

Para los factores anteriores, se pueden proporcionar las siguientes descripciones:

  • Corrección: Grado de satisfacción de sus especificaciones y los objetivos de la misión encomendada.
  • Fiabilidad: Grado de precisión esperada en el cumplimiento de sus funciones.
  • Eficiencia: La cantidad de recursos técnicos y de código requerido para llevar a cabo sus funciones.
  • Integridad: El grado de control sobre el software en virtud al acceso al sistema o a los datos por personal no autorizado.
  • Reusabilidad: El grado en que un módulo se puede reutilizar en otras aplicaciones del sistema.
  • Facilidad de Interoperación: El esfuerzo requerido para acoplar un sistema a otro.

Garantía de Calidad del Software (SQA)

La SQA es un planificado y sistemático diseño de acciones que se requieren para asegurar la calidad del software.

Para mantener dicha garantía, el grupo de SQA debe cumplir con las siguientes actividades principales:

  • Aplicación de Métodos Técnicos: Conjunto de herramientas que permiten un diseño y especificaciones de alta calidad.
  • Revisiones Técnicas Formales (RTF): una vez diseñado el prototipo se debe garantizar su calidad a través de la RTF, que es una reunión del personal técnico con el propósito de descubrir problemas de calidad. Estas pruebas a veces suelen ser más efectivas que las pruebas de error aplicadas al mismo software.
  • Pruebas del Software: Combina una serie de múltiples pasos con una serie de métodos de diseño de casos de prueba que ayudan a asegurar una efectiva detección de errores.
  • Ajuste de Estándares: Los estándares de calidad varían de empresa a empresa. Si existen estándares formales se debe establecer una actividad de SQA para garantizar que se cumplan.
  • Control de Cambio: Este proceso contribuye directamente a la calidad del software, al formalizar las peticiones de cambio, evaluar la naturaleza del cambio y controlar el impacto del cambio. El control de cambios se aplica durante las fases de desarrollo y mantenimiento.
  • Medición: Conjunto de medidas técnicas orientadas a la gestión que permiten tener una visión cuantitativa de la calidad a través de métricas.
  • Generación del informe final de calidad: En resumen, la Garantía de Calidad del Software es la guía de los preceptos de gestión y de las disciplinas de diseño de la garantía de calidad para el espacio tecnológico y la aplicación de la ingeniería de software.

Prueba del Software

La prueba del software es un elemento crítico para la garantía de calidad del software y representa una revisión final de las especificaciones, del diseño y de la codificación. La prueba es uno de los pasos de ingeniería que se puede ver como algo más “destructivo” que “constructivo”. La prueba, ¿debe infundir culpabilidad?, ¿es realmente destructiva? La respuesta a las consultas anteriores es NO; sin embargo, los objetivos de las pruebas pueden ser algo diferente a lo que podríamos esperar.

Objetivos de la Prueba

El objetivo principal es diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, al menor tiempo y esfuerzo posible.

Flujo de Información de la Prueba

Por otro lado, si el funcionamiento del software parece ser correcto y los errores que se encuentran son fácilmente corregibles, se pueden sacar dos conclusiones:

  • La calidad y la fiabilidad del software son correctas.
  • Las pruebas son inadecuadas para descubrir errores serios.

Por último, si no se han detectado errores por pruebas poco eficientes, estos serán detectados por el usuario final y corregidos posteriormente en la fase de mantenimiento.

Diseño de Casos de Prueba

Los métodos de prueba han proporcionado un mecanismo de ayuda para asegurar la completitud de las pruebas y para conseguir la mayor probabilidad de descubrimiento de errores en el software.

Estas pruebas se denominan Prueba de Caja Negra y Prueba de Caja Blanca, respectivamente.

  • Prueba de Caja Negra: Se refiere a las pruebas que se llevan a cabo sobre la interfaz del software: las funciones del software son operativas, que la entrada se acepta en forma adecuada, se produce una salida correcta y la integridad de la información externa se mantiene.
  • Prueba de Caja Blanca: Se basa en el minucioso examen de los detalles procedimentales: se comprueban los caminos lógicos del software proponiendo casos de prueba que ejerciten conjuntos específicos de condiciones.

Prueba de Caja Blanca

Mediante esta técnica, se pueden obtener casos de prueba que:

  • Garanticen que se ejercitan por lo menos una vez todos los caminos independientes de cada módulo.
  • Se ejerciten todas sus decisiones lógicas.
  • Se ejecuten todas sus condiciones en sus límites y con sus límites operacionales.
  • Se ejerciten las estructuras internas de datos para asegurar su validez.

Las pruebas de caja blanca se orientan principalmente a los siguientes tipos de errores:

  • Los errores lógicos y las suposiciones incorrectas.
  • A menudo creemos que los caminos lógicos tienen pocas posibilidades de ejecutarse cuando, de hecho, se pueden ejecutar en forma regular.
  • Los errores tipográficos son aleatorios (traducción al lenguaje de programación).

Prueba de Caja Negra

Los métodos de prueba de caja negra se centran en los requisitos funcionales del software, orientadas al conjunto de condiciones de entrada del sistema.

Esta prueba intenta encontrar errores en las siguientes categorías:

  • Funciones incorrectas o ausentes.
  • Errores de interfaz.
  • Errores de estructuras de datos o en accesos a bases de datos externas.
  • Errores de rendimiento.
  • Errores de inicialización o de terminación.

La prueba de caja negra ignora intencionalmente la estructura de control (caja blanca) y centra su atención en el campo de la información.

Partición Equivalente

Es un método de prueba de caja negra que divide el campo de entrada de un sistema en clases de datos de los que se pueden derivar casos de prueba.

Análisis de Valores Límites (AVL)

Ya que los errores tienden a darse en los límites del campo y no en el centro, se desarrolla esta técnica que nos lleva a la elección de casos de prueba que ejerciten aquellos valores límites.

Técnica de Grafos Causa-Efecto

Es una técnica de diseño de casos de prueba que proporciona una concisa representación de las condiciones lógicas y sus correspondientes acciones.

Prueba de Comparación

A menudo, donde la fiabilidad del software es absolutamente crítica (sistema de control de vuelo, centrales nucleares, etc.), desde el punto de vista del software se desarrollan versiones independientes de una aplicación usando las mismas especificaciones.

Prueba de Sistema de Tiempo Real

Por la naturaleza de los sistemas en tiempo real, a las pruebas se le agregará un nuevo y difícil elemento en su tratamiento: el tiempo.

Esta estrategia incluye cuatro pasos:

Pruebas de Tareas

Este es el primer paso en las pruebas de tiempo real y consiste en probar todas las tareas en forma independiente.

Pruebas de Comportamiento

Se basa en la simulación del comportamiento del sistema y examinar dicho comportamiento en base a sucesos externos.

Prueba Intertareas

Una vez que se han aislado los errores de tareas individuales y del comportamiento del sistema, la prueba se dirige a los errores relativos al tiempo.

Prueba del Sistema

El software y el hardware están integrados, por lo que se lleva a cabo una serie de pruebas complejas del sistema para intentar descubrir errores en la interfaz software/hardware.