Universidad Nacional Autónoma de México
Facultad de Ingeniería
Materia: Admin. de Proyectos de software
Grupo: 2
“Capítulo 9 y 10 del libro de inglés”
Valdivia Enciso Luis Enrique
Prueba del sistema
Sector del sistema de prueba
Errores que la prueba del sistema no puede detectar mientras el software es diseñado y codificado. Asumimos que los errores serán detectados y corregidos durante la fase de prueba del sistema. Incluso, en la práctica algunos errores a menudo permanecen después de que la prueba del sistema es completada.
Crecimiento de los errores no detectados:
Consisten en errores que escapan de la prueba del sistema. Los errores que no son detectados no permanecen inactivos hasta la detección y corrección durante la fase del sistema de prueba. Lideran una”existencia activa”, produciendo más y más errores en el sistema. Por ejemplo, un error en el diseño que permanece sin ser detectado hasta la prueba del sistema causa errores adicionales en el código, usuario, y manuales de mantenimiento, etc.
Shooman determina que la detección y corrección de errores durante la fase de diseño es una décima parte del esfuerzo que podría ser necesitado para detectar y corregirlo después durante la fase de prueba del sistema debido a un inventario adicional de especificaciones, código, usuario y manuales de mantenimiento, etc.
Dinámicas de los errores de producción:
Se asume que los errores que no son detectados se convertirán en ambos: “Errores Activos ” (aquellos que producen más errores) o “Errores pasivos”. Debido a que las especificaciones del diseño son los planos/programas del sistema de código cualquiera de los errores debe ser activo. Como el desarrollo se mueve dentro de la etapa de codificación, una mezcla de errores activos y pasivos se pueden esperar. Si asumimos, por ejemplo, que el sistema es codificado en cascada, entonces en la etapa temprana de codificación, la mayoría de los errores cometidos están en los módulos de alto nivel y serán activos.
“Errores Pasivos No Detectados”
Permanecen inactivos hasta que son detectados y corregidos durante la fase de sistema de prueba.
“Errores Activos No Detectados”
Por el otro lado son una gran causa de preocupación, desde que ellos introducen más y más errores al sistema.
El proceso de producción de errores que continua alimentándose así mismo. Es representado en el modelo de loop de retroalimentación positiva , el cual un incremento en los niveles de “Errores No Detectados” llevan a un incremento en el “Rango de Regeneración de Errores Activos”, lo cual lleva a un incremento más allá en el nivel.
Rango de Regeneración de Errores Activos
Es una función del “Rango de Desarrollo del Software”, desde errores pueden ser generados sólo como nuevas tareas son desarrolladas. Si el desarrollo se detiene, ningún error puede ser generado. El rango de regeneración es una función del del “Densidad de Error Activo”, el cual es simplemente el número de errores activos existentes divididos entre las tareas de desarrollo. Más preciso, el rango de generación es una función de la “Densidad de Error Relativo”, debido a que cuando los errores son cometidos en una parte del sistema, ellos no, en general, afectan a otras partes que están siendo desarrolladas en paralelo. Los errores tienden a propagarse a través de las tareas exitosas que construyen sobre alguna otra, tales como tareas de codificación construidas sobre especificaciones incorrectas. De ese modo hay un retraso ante un error que reproduce diferentes errores.
Error Activo de retiro
Como se mencionó: “Errores Activos que no son detectados” pueden continuar produciendo más errores así como nuevas tareas vayan siendo desarrolladas. No todos los errores activos lo harán, sin embargo. Para algunos errores la actividad de producción no continuará hasta el la fase final; en el mejor de los casos, puede cesar después de producir una o dos “generaciones” de errores. Por ejemplo, un error de en un alto nivel de módulo puede producir una interfaz de errores como en bajo nivel sin la necesidad de lleva a cualquier otro error en los manuales de usuario. Cuando los errores que no son detectados cesan en reproducción, ellos efectivamente se convierten en “Errores Pasivos No Detectados”.
Detección y Corrección de Errores
Es necesario detectar y corregir cualquier error permaneciente. El esfuerzo es el producto de la “Densidad de Error” y la “Prueba Nominal de Mano de Obra Necesidades por Error ”. Dicho esfuerzo se obtendrá dividiendo la suma de los errores activos por el número de tareas que no han sido probadas aún.
Controlando
Controlando el Subsistema
Medida- Detección de lo que está pasando en la actividad que está siendo controlada.
Evaluación- Asesoramiento de este significado, usualmente al comparar información sobre qué está pasando actualmente con algunos estándares o expectaciones de que debería estar pasando. Comunicación- Reporte de lo que ha sido medido y asesorado, así ese comportamiento puede ser alterado si la necesidad de hacerlo es indicada.
El progreso en un proyecto de software es medido por el número de recursos consumidos, tareas completadas, o ambos El “total de días de trabajo percibidas para ser necesitadas” para completar el proyecto son determinadas desde la medida. Días totales de trabajo incluidos aquellos percibidos para ser necesitados para desarrollar tareas de pruebas de sistema, para trabajar cualquier detección de error, y para completar el sistema de prueba. La necesidad del esfuerzo percibido es comparado con el actual “Jornadas de Trabajo Restantes” en los planes de proyectos.
Una vez que una evaluación es realizada de cualquier día de trabajo, escasez, comportamiento sobre el proyecto puede ser alterado si la necesidad de hacerlo es indicada. En cualquier punto de la cantidad de trabajo que sea percibida como restante será en general una combinación de tres cosas:
1) Necesidad de trabajo para desarrollo y prueba de trabajo con nuevas tareas. 2) Necesidad de trabajo para retribuir a la detección de errores.
3) Necesidad de trabajo para conducir el sistema de prueba de actividades.
De ese modo el “Total de Días de Trabajo Percibidas para ser Necesitadas” para completar el proyecto es la suma de “Días de trabajo percibidos para aún ser Necesitadas para nuevas tareas”, “Días de trabajo percibidos para aún ser necesitados para retribuir a la detección de errores”, y “Días de trabajo percibidos aún necesitados para pruebas”.
Medidas de Progreso sobre nuevas Tareas
Debido a que el software es un producto intangible durante la mayoría del desarrollo de proceso y porque no hay indicadores visibles para la medida del progreso como existen con un producto físico, “es difícil medir la interpretación en la programación ... E difícil evaluar el status de trabajo intermedio tal como los programas sobre depurados o diseño de especificación y su valor potencial para completar el proyecto”
Fase temprana del desarrollo de Software
En la fase temprana del desarrollo del Software, el progreso tiende a ser medido por el rango del cual los recursos son gastados. Como resultado el reporte del status termina siendo nada más que un eco del plan original. “Los días de trabajo percibidos aún necesitados para nuevas tareas” se convierten, bajo tales condiciones, simplemente equivalentes a los “Días de trabajo restantes percibidos para nuevas tareas”.
Transición desde una temprana a una etapa final
Las suposiciones de las personas acerca de su productividad cambian como el desarrollo del proyecto. El cambio es a menudo gradual y no abrupto. La Transición en la suposición de la gente acerca de su productividad es representada en el modelo por el factor peso WTPJDP. El rango del cual WTPJDP se mueve desde el valor de 1 al valor de 0 es el producto de dos factores: el rango de los gastos de los recursos y el rango de desarrollo de tareas.
Medidas de Progreso sobre la Retribución y Prueba
Por un lado más sabemos que sólo ha sido discutido el como “”Los días de trabajo percibidos de necesidades para nuevas tareas” es determinado. En cierto punto en el proyecto la cantidad de trabajo percibida como restante en general consistirá no sólo por necesidad de trabajo para el desarrollo y tareas nuevas de pruebas de sistema, sino también de la necesidad de volver a retribuir cualquier error detectado y conducir la prueba del sistema. Por ello, los “Días totales de trabajo percibidos aún necesitados para nuevas tareas,” “Días de trabajo percibidos necesitados para retribución de detección de errores.” y “Días de trabajo percibidos aún necesitados para pruebas.”
Ajuste de la locación de los Días de trabajo
La pieza final de la estructura que se debe de discutir es la única que modela el proceso por el cual el descubrimiento de tareas adicionales es trasladado en adiciones para la asignación de los días de trabajo proyecto de los Días de trabajo. Cuando tareas adicionales son descubiertas en un nuevo proyecto, ellas no necesariamente provocan un ajuste a los días de trabajo estimado del proyecto . Sólo si las tareas adicionales son percibidas como requisitos relativamente “importantes” cantidades de esfuerzos para manejar miembros aspirantes a proyectos sin necesidad de ir a través de problemas de desarrollo formal de estimaciones de costos e incorporándolos en el plan de trabajo de proyecto.
