ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE. EJERCICIOS PRÁCTICOS

...

Plan de Continuidad, detalla cómo se debe actuar en diferentes situaciones críticas cuando ocurre un desastre, debe contemplar todas las medidas preventivas y de recuperación para cuando se produzca una contingencia que afecte al negocio.

- ¿las alternativas producen otros riesgos?

Las alternativas no necesariamente producen otros riesgos aunque en algunos casos, tomar una alternativa para un problema dado puede traer otros riesgos o solucionar el problema.

En algunos casos el no actuar a tiempo produce otros riesgos, hay que actuar en el momento adecuado.

Ejercicio 4

¿Un error común en ciencias de la computación es pensar que la codificación consume la mayor parte del tiempo de desarrollo del software. Apelando a la experiencia individual, establecer qué porcentaje de tiempo requieren aproximadamente las fases de especificación de requerimientos, diseño, codificación, testeo y mantenimiento en el desarrollo de un programa. ?

Dependiendo de la complejidad del sistema a desarrollar las fases pueden tardar:

- Especificación de Requerimientos: de 2 a 3 semanas (4 horas al día)

- Diseño: de 3 semanas a 1 mes.

- Codificación: de 1 a 6 meses (esto depende si las especificaciones están claramente definidas)

- Pruebas: esta fase durara de 1 a 2 semanas.

- Mantenimiento: esta fase durara durante todo el ciclo de vida del sistema.

Ejercicio 5

Definir el concepto de riesgo en el desarrollo de software. Enumerar algunos de los riesgos que deberían tenerse en cuenta a lo largo de la producción de software.

El Riesgo: es la probabilidad de que un proyecto experimente sucesos no deseables, como retrasos en la fecha de entrega, excesos de coste, cancelación del proyecto, entre otros factores.

Riesgo del Software:

A pesar de las diferentes definiciones para los riesgos del software, existe un acuerdo común en que el riesgo siempre implica dos características:

- Incertidumbre: El acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por ejemplo, no hay riesgos de un 100% de probabilidad (ya que un riesgo del 100% es una limitación del proyecto).

- Pérdida: Si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas o pérdidas.

Riesgos del Proyecto

Amenazan al plan del proyecto, es decir, si los riesgos del proyecto se hacen realidad, es probable que la planificación temporal del proyecto se retrase y que los costos aumenten. Los riesgos del proyecto identifican:

- Problemas potenciales de presupuesto

- Planificación temporal

- Tamaño y grado de incertidumbre estructural

Riesgos Técnicos

Amenazan la calidad y la planificación temporal del software que hay que producir. Si un riesgo se convierte en realidad, la implementación puede llegar a ser difícil o imposible. Los riesgos técnicos identifican problemas potenciales de:

- Diseño

- Implementación

- De interfaz

- Verificación

- Mantenimiento

- Las ambigüedades de especificaciones

- Tecnologías

Riesgos del Negocio

- Construir un producto o sistema excelente que no quiere nadie en realidad (Riesgo de Mercado).

- Construir un producto que no encaja en la estrategia comercial general de la compañía (Riesgo Estratégico).

Ejercicio 6

Explicar brevemente cómo funciona el modelo en espiral del ciclo de vida del software. Los modelos en espiral o en cascada (con feedback), ¿se pueden usar indistintamente? Justificar la respuesta suministrada.

El modelo en espiral trabaja por versiones que son iteraciones o vueltas completas, se realizan todas las etapas del ciclo de vida y se presenta al cliente una versión del software, cada vez que se requiere modificar el software pues se comienza un nuevo ciclo en espiral y esta es la segunda versión del software y así sucesivamente hasta que el software este completado.

Modelo en espiral.

- Definición de objetivos

- Evaluación y reducción de riesgos

- Desarrollo y validación

- Planeación

Definición de objetivos: se definen los objetivos específicos, se identifican las restricciones del proceso y el producto y se estipula un plan detallado de administración. Se identifican los riesgos y dependiendo de esos se planea un plan de estrategias alternativas.

Evaluación y reducción de riesgos: se lleva a cabo un análisis detallado para uno de los riesgos del proyecto. Se definen los pasos para reducir dichos riesgos.

Desarrollo y validación: después de la evaluación de riesgos, se elige un modelo para el desarrollo del sistema.

Planeación: se planifican los siguientes pasos y se volverá a empezar la espiral

Justificación-Modelo en espirar y modelo en cascada.

El desarrollo de un proyecto debería escoger el más apropiado según sus necesidades pero en ocasiones puede que una combinación de varios sea apropiado.

Ejercicio 7

Explicar por qué está mal pensar que la Ingeniería de Software consume mucho tiempo e interfiere con la productividad del programador. Repasar la respuesta dada en el ejercicio 4. Con todo esto en mente, ¿cuál sería la mejor estrategia para reducir los tiempos de codificación?

La ingeniería de software influye positivamente y no afecta o interfiere en la productividad debido a que una de sus principales ventajas es la reutilización del código.

Una