Pruebas de Caja Blanca

Se centran en los detalles procedimentales del software, por lo que su diseño está fuertemente ligado al código fuente.

• La prueba de caja blanca usa la estructura de control descrita como parte del diseño para derivar los casos de prueba.

De esta forma se obtienen casos de prueba que:

• Garantizan que se recorren todos los caminos independientes de cada módulo.
• Ejercitan todas las decisiones lógicas en su vertientes verdadera y falsa.
• Ejercitan todos los bucles en sus límites.
• Ejercitan las estructuras internas de datos.

Pruebas de Caja Negra

• Las pruebas de caja negra se centran en los requisitos funcionales del software.
• Estas pruebas permiten obtener conjuntos de condiciones de entrada para ejercitar todos los requisitos funcionales de un programa.
• Se proporcionan unas entradas y se estudian las salidas para ver si concuerdan con las esperadas.
• Son complementarias a las pruebas de caja blanca.

Métodos de prueba de caja negra:

• Método basado en grafos
• Partición equivalente
• Análisis del valor límite
• Tabla ortogonal

Modelo de Proceso

Se utilizará un modelo de proceso evolutivo, concretamente la espiral de Boehm simplificada (Modelo Boston). Para el cual ya se ha hecho la identificación de riesgos y evaluación de los mismos. Tras el prototipo operativo, el diseño, codificación y pruebas de errores, si el producto no es satisfactorio, se evaluarán los cambios a realizar, repitiéndose el proceso y a su vez anexando la documentación pertinente.

Actividades Estructurales

• Reuniones preliminares: Servirán para preparar el diseño de la aplicación y recopilar ideas para el proyecto, o cambios necesarios en la aplicación ya codificada.
• Planificación: Se definirán recursos y tiempo y se asignarán a actividades de ingeniería.
• Análisis de riesgos: Se han evaluado los riesgos que pueden causar un fallo en el resto del proceso o retrasos insostenibles en el mismo.
• Ingeniería: Con esto se refiere al diseño de la aplicación, base de datos, casos de uso…
• Construcción y adaptación: En esta AE codificaremos la aplicación con respecto al diseño que se haya producido en la fase de ingeniería.
• Evaluación por el cliente: Se hará entrega del material acordado y se esperará a la evaluación para realizar cambios si procediese.

Definición de Modelo de Proceso

Un modelo de proceso del software (o paradigma de IS) es una representación abstracta de un proceso del software.

• Plantilla, patrón o marco que define el proceso a través del cual se crea software.

Un modelo de proceso ha de definir sus actividades estructurales así como su flujo de realización.

Estrategia de Gestión del Riesgo

Para nuestro proyecto software aplicaremos una estrategia proactiva de gestión del riesgo. Lo que significa que se prevé y se anticipa para los cambios. Para aplicar esta estrategia se comienza identificando los riesgos, se priorizan y se produce un plan de gestión del riesgo.

Ejemplo de Gestión de Riesgo

El tiempo estimado para desarrollar el software está subestimado

Reducción:

Ya que existe un tiempo fijado para el desarrollo del software, una manera eficaz de poder reducir este riesgo es reutilizar código, así se ahorraría tiempo en la implementación de uno nuevo.

Supervisión:

El control y supervisión de este riesgo se hará mediante reuniones periódicas de todos los componentes del equipo para saber si la implementación del código se está llevando a cabo de manera eficiente.

Plan de Contingencia:

En primer lugar se incrementaría el esfuerzo de todo el equipo para no salirse de los límites del plazo.

En segundo lugar vamos a priorizar el desarrollo e implementación de algunas partes del software con el fin de que las funcionalidades principales del producto puedan ejecutarse correctamente.

Requisitos Funcionales vs. Requisitos No Funcionales

Definición

Los requisitos funcionales son los servicios que proporcionan el sistema (funciones), la respuesta del sistema ante determinadas entradas, el comportamiento del sistema en situaciones particulares y en algunos casos también determinan lo que no debería hacer el sistema.

Los requisitos no funcionales son restricciones de los servicios o funciones que ofrece el sistema. Hay tres tipos:

• Del producto, que especifican el comportamiento del producto.
• Organizativos, se derivan de las políticas y procedimientos de los clientes y desarrolladores.
• Externos, que vienen de factores externos al sistema y al proceso.

Ejemplo

Requisitos funcionales serían por ejemplo las funciones de dar de alta y de baja a un usuario y un requisito no funcional sería que la aplicación pueda soportar a tres usuarios conectados a la vez.

Estructura de Equipo

Utilizaremos una estructura Centralizada Controlada (CC) siendo Álvaro Lázaro el jefe del equipo, por la experiencia que aporta y su capacidad de repartición de tareas. Elegimos este modelo porque consideramos que el Descentralizado Democrático no es el más adecuado al tener que cambiar de jefe para cada tarea y el Descentralizado Controlado requeriría más gente y no es resistente a riesgos.

Características de la Estructura Centralizada Controlada

• Hay un único jefe de equipo.
• Este jefe resuelve los problemas a alto nivel, y la coordinación del equipo.
• Comunicación vertical entre el jefe y los miembros del equipo.
• Fue el primer organigrama que se empezó a aplicar.

Gestión de Configuración del Software

La Gestión de Configuración (del Software) (GCS) es una actividad de protección que gestiona el cambio en los artefactos a lo largo del ciclo de vida del producto.

En nuestro proyecto vamos a realizar la Gestión de Configuración del software para poder gestionar el cambio a lo largo del ciclo de vida del software a realizar. Las actividades que vamos a realizar para controlar dicha gestión son las siguientes:

• Identificación de elementos de configuración del software (ECSs).
• Control de versiones.
• Control de cambios.
• Revisiones.

Relación entre Modelo de Proceso y Planificación Temporal

Uno de los objetivos de la planificación temporal es evitar los retrasos en las entregas del software ya sea por fechas límite de entrega, cambios de los requisitos, falta de comunicación, riesgos predecibles e impredecibles, etc. Y aquí viene su relación con el modelo de proceso. Si queremos que todos estos “contratiempos” sean los mínimos posibles, deberemos elegir un modelo de proceso que se adecúe lo mejor posible a dicha planificación temporal y así evitar cuantos más problemas mejor.

El Camino Crítico

El camino crítico está formado por las tareas críticas. El camino crítico es el camino de mayor duración. Formado por la cadena de tareas de mayor duración del proyecto.

• Un retraso en una tarea crítica implica automáticamente un retraso en el proyecto.