Unidad III gestion de proyecto
-
Upload
jose-martinez -
Category
Documents
-
view
237 -
download
4
description
Transcript of Unidad III gestion de proyecto
![Page 1: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/1.jpg)
República Bolivariana de VenezuelaMinisterio del Poder Popular para la Educación Universitaria
Universidad Politécnica Territorial del Oeste de Sucre “Clodosbaldo Russián”Cumaná – Estado Sucre
Programa Nacional de Formación en Informática
Unidad Curricular Gestión de Proyectos Informáticos
Unidad III: Administración de la CalidadUnidad III: Administración de la Calidad
Facilitador:Ing Leonardo J. Malavé Q. MSc.
Cumaná, Agosto - Septiembre de 2014
![Page 2: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/2.jpg)
Contenido de la Unidad III
1. Factores de calidad del software
2. Métricas de calidad del software
3. Aseguramiento de la calidad
4. Evaluación de la calidad del producto: documentación, pruebas deaceptación, operación y mantenimiento.
5. Modelos de calidad (CMMI, MOPROSOFT, SW-CMM, ISO )
![Page 3: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/3.jpg)
Unidad III
1.- Definiciones
a.- Calidad: Calidad significa que un producto debe cumplir con sus
especificaciones
b.- En un nivel algo pragmático, sugiere que “la calidad es un concepto
complejo y de facetas múltiples” que puede describirse desde cinco
diferentes puntos de vista. El punto de vista trascendental dice (como
Persig) que la calidad es algo que se reconoce de inmediato, pero que
no es posible definir explícitamente. El punto de vista del usuario
concibe la calidad en términos de las metas específicas del usuario final.
![Page 4: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/4.jpg)
Unidad III
Si un producto las satisface, tiene calidad. El punto de vista del
fabricante la define en términos de las especificaciones originales del
producto. Si éste las cumple, tiene calidad. El punto de vista del
producto sugiere que la calidad tiene que ver con las características
inherentes (funciones y características) de un producto. Por último, elinherentes (funciones y características) de un producto. Por último, el
punto de vista basado en el valor la mide de acuerdo con lo que un
cliente está dispuesto a pagar por un producto. En realidad, la calidad
incluye todo esto y más.
![Page 5: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/5.jpg)
2.- Factores de Calidad de Software
![Page 6: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/6.jpg)
3.- Métricas de Calidad de Software
En función de los factores existen algunos modelos para medir las
métricas de calidad
•Modelo de McCall
•SQA Estadística•SQA Estadística
![Page 7: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/7.jpg)
Modelo de McCall
Facilidad de auditoría (FA). Instrumentación (INS)Exactitud (EX) Modularidad (MO)Normalización de comunicaciones (NO) Facilidad de operación (FAO)Completitud (COT). Seguridad (SE).Complejidad (COJ). Autodocumentación (AU).Concisión (COC). Simplicidad (SI).Consistencia (COS). Independencia del entorno Consistencia (COS). Independencia del entorno
software (INS).Estructuración de datos (ES). Trazabilidad (FAT).Tolerancia al error (TO). Formación (FO).Eficiencia en la ejecución (EF).Facilidad de expansión (FAE).Generalidad (GE).Independencia del hardware (INH).
![Page 8: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/8.jpg)
Modelo de McCall
![Page 9: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/9.jpg)
Modelo de McCall
• Para cada métrica se estima en la escala de 0 a 10
• Para cada factor de calidad se calcula:
∑ == n
imi iCFc
1.
Fc = valor cuantitativo del factor de calidad.
Ci = peso (tanto por uno) de la métrica en el factor de calidad.mi = valor asignado a la métrica (de 0 a 10).
∑ = 1iC
![Page 10: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/10.jpg)
SQA Estadística
• Se clasifica la información sobre los defectos del software durante un
tiempo determinado.
• Se intenta encontrar la causa subyacente de cada defecto.
• Se aplica el principio de Pareto: el 80% de los defectos se pueden
encontrar en el 20% de las posibles causas. Se aíslan el 20% de los
defectos no vitales.
• Una vez identificados los defectos vitales, se actúa para corregir los
problemas que los han originado.
![Page 11: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/11.jpg)
SQA Estadística – Objetivos
• Detectar los errores que más se producen y analizar sus causas.
• Medir la calidad de los proyectos.
Causas de Error
• Especificación incompleta o errónea (EIE).
• Mala interpretación de la comunicación con el cliente/usuario (MCC).
• Desviación deliberada de la especificación (DDE).
• Incumplimiento de los estándares de programación (IEP).
• Error en la representación de los datos (ERD).
• Interfaz de módulo inconsistente (IMI).
![Page 12: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/12.jpg)
Causas de Error
• Error en la lógica de diseño (ELD).
• Prueba incompleta o errónea (PIE).
• Documentación imprecisa o incompleta (DII).
• Error en la traducción del diseño al lenguaje deprogramación (TLP).
• Interfaz hombre-máquina ambigua o inconsistente (IHM).
• Varios (VAR).
![Page 13: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/13.jpg)
La distribución por errores es:
![Page 14: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/14.jpg)
SQA Estadística
Además de la recopilación de información de los defectos, los equipos
de desarrollo pueden calcular un Índice de Errores (IE) para cada etapa
principal (análisis, diseño, codificación, prueba y entrega) del ciclo de
vida.
Para cada etapa se recopila:Para cada etapa se recopila:
• Ei : nº total de defectos descubiertos en la etapa i.
• Si : nº de defectos graves.
• Mi : nº de defectos moderados.
• Ti : nº de defectos leves.
![Page 15: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/15.jpg)
SQA Estadística
• PS : tamaño del producto (LDC, sentencias de diseño, páginas de
documentación, etc.).
• Sean Ws, Wm, Wt los factores de peso de errores graves, moderados y
leves (10, 3 y 1 como valores recomendados).
• Para cada etapa se calcula el índice de fase (IFi):
IFi = Ws (Si/Ei) + Wm (Mi/Ei) + Wt (Ti/Ei)
• Los factores de peso de cada fase deberían aumentar a medida que el
desarrollo evoluciona.
• Para calcular el índice de errores:
PS
IFiiIE
n
i∑ == 1*
![Page 16: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/16.jpg)
4.- Aseguramiento de la Calidad de Software
Es una actividad de protección que se aplica a lo largo de todo el ciclo de
vida. Se refiere a lograr un nivel de calidad requerido en el producto de
software. Involucra la definición de estándares de calidad apropiados y
procedimientos que permitan asegurar que estos se cumplan. Debe
llevar a desarrollar una cultura de calidad en donde la calidad es
responsabilidad de todos.
![Page 17: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/17.jpg)
Quienes aplican la Calidad de Software?
Los administradores de la calidad en una organización tienen la
responsabilidad de asegurar que se cumpla el nivel requerido de calidad
de un producto. Inicialmente, comprende simplemente definir
procedimientos y estándares a utilizar en el desarrollo de software y
comprobar que todos los ingenieros los sigan. En la práctica, los buenos
administradores de la calidad su propósito es desarrollar una “cultura
de calidad”. Cada integrante del equipo de desarrollo es motivado para
que logre un alto nivel de la calidad del producto y sobre todo con
responsabilidad.
![Page 18: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/18.jpg)
Equipo de Aseguramiento de la Calidad de Software?
Es el encargado de realizar el aseguramiento de la calidad del software.
Sus miembros deben tener como características:
• Titulación informática y experiencia en desarrollo de software.
• Conocimiento de la organización.
• Conocimiento de las metodologías de desarrollo y de los métodos y
técnicas de control de calidad.
• Capacidad de comunicación oral y escrita.
• Capacidad de interrelación personal.
• Capacidad de hacer frente a problemas.
• Capacidad de diálogo.
![Page 19: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/19.jpg)
Sus funciones son:
• Establecer el plan SQA del proyecto.
• Participar en la definición del proceso de software del proyecto.
• Revisar las actividades de ingeniería de software aplicadas en el
proyecto.
• Auditar los productos software obtenidos.
• Garantizar la documentación de las desviaciones detectadas.
• Registrar las diferencias respecto a los requisitos.
• Decidir las acciones correctoras necesarias.
• Desarrollar herramientas de prueba.
• Coordinar el control y la gestión de cambios.
• Recopilar y analizar las métricas del software.
![Page 20: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/20.jpg)
Ámbito del Aseguramiento de la Calidad de Software
• El aseguramiento de la calidad a nivel de empresa u organización
consiste en la creación de una estructura organizativa apropiada
para fomentar el trabajo por la calidad de todas las personas y
departamentos de la empresa.
• En cada proyecto de desarrollo se deben aplicar las directrices de
calidad fijadas a nivel de la organización. Para ello es imprescindible
la adaptación de las mismas a las condiciones de cada proyecto.
![Page 21: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/21.jpg)
Ámbito del Aseguramiento de la Calidad de Software
![Page 22: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/22.jpg)
Métodos para lograr el nivel de Calidad de Software
Inspección
• Proceso orientado a equipos para asegurar la calidad
• Aplicada a todas las etapas del proceso
Métodos formales
• Técnicas matemáticas para convencernos de que los programas
hacen lo que deben
• Se aplica en forma selectiva
![Page 23: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/23.jpg)
Métodos para lograr el nivel de Calidad de Software
Pruebas
• A nivel de la unidad
• A nivel de toda la aplicación
• Técnicas de control de proyectos
• Predecir los costos y la programación
• Control de artefactos (versiones, alcances, etc.)
Técnicas de control de proyectos
• Predecir los costos y la programación
• Control de artefactos (versiones, alcances, etc.)
![Page 24: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/24.jpg)
Proceso de Aseguramiento de la Calidad
![Page 25: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/25.jpg)
Actividades del Proceso de Administración de la Calidad
1.1 Aseguramiento de la calidad
• Establecer procedimientos organizacionales y estándares para la
calidad
1.2 Planeación de la calidad
• Seleccionar procedimientos aplicables y estándares para un proyecto
en particular y modificar estos como sean requeridos
1.3 Control de la calidad
• Garantizar que, procedimientos y estándares son seguidos por el
equipo de desarrollo de software
![Page 26: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/26.jpg)
Aseguramiento de la Calidad
Dos tipos de estándares que se establecen como de la Administración
de la Calidad
• Estándares del producto
� Estándares de documentos de requerimientos
� Estándares de documentación como encabezado, estándar de
comentarios, de codificación, etc
• Estándares del proceso
� Estándares que incluyen definiciones de los procesos de
especificación, de diseño, de validación, y una descripción de los
doc’s., a generar en el transcurso de estos procesos.
![Page 27: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/27.jpg)
Evaluación de la calidad del producto: documentación, pruebas de
aceptación, operación y mantenimiento.
Procedimientos de Control
• Revisiones: aplicables a productos documentales en las fases iniciales
e intermedias del proyecto.
� Revisión mínima: intensidad 0. (DIR, EDS, USR).
� Revisiones técnicas formales: intensidad 1. (DIR, EGC, EDS, USR).
� Inspecciones detalladas: intensidad 2. (DIR, EGC, EDS, USR).
• Pruebas: aplicables a productos software ejecutables.
� Validación de módulos: (DIR, EDS, EGC).
� Integración: (DIR, EDS, EGC).
� Aceptación: (DIR, EDS, EGC, USR).
![Page 28: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/28.jpg)
Procedimientos de Control
• Auditorías: pretende garantizar la tarea del EDS y del EGC. (DIR, AUD,
EDS, EGC, USR).
• Evaluación de prototipos: (USR, EGC, EDS).
Revisiones e Inspecciones
Pretenden detectar manualmente defectos, mediante la lectura, en
productos de desarrollo impresos en papel.
• Fases:
� Inicio.
� Planificación: selección de participantes y definición de roles.
� Lanzamiento: explicación del producto.
![Page 29: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/29.jpg)
Revisiones e Inspecciones
� Detección de defectos.
� Búsqueda de defectos.
� Actividad individual o de grupo.
� Colección de defectos.
� Evaluación de los defectos.
� Documentación de defectos.
� Corrección y seguimiento.
� Los autores corrigen el producto.
� El equipo de revisión/inspección hace el seguimiento de la
corrección y de la finalización de la inspección.
![Page 30: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/30.jpg)
Revisiones e Inspecciones
![Page 31: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/31.jpg)
Características de una Buena Prueba
• Una buena prueba ha de tener una alta probabilidad de encontrar
un fallo.
• Una buena prueba no debe ser redundante.
• Una buena prueba debería ser la “mejor de la cosecha”.
• Una buena prueba no debería ser ni demasiado sencilla ni
demasiado compleja.
Fases de la Prueba
• Diseño de las pruebas (¿técnicas?)
• Generación de casos de prueba (¿datos de prueba?)
• Definición del procedimiento de la prueba (¿cómo, donde?
• Ejecución de la prueba
![Page 32: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/32.jpg)
Fases de la Prueba
• Informe de la prueba (¿resultados?)
Técnicas de Prueba
• Pruebas estructurales o de Caja Blanca.
• Pruebas funcionales o de caja negra.
Estrategias de Prueba
• Pruebas unitarias.
• Pruebas de integración.
• Pruebas de sistema.
• Pruebas de aceptación.
• Pruebas de regresión.
![Page 33: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/33.jpg)
Pruebas Estructurales o de Caja Blanca
• Atienden al comportamiento interno y la estructura del programa,
examinando la lógica interna.
• Diseñar casos de prueba para que se ejecuten:• Diseñar casos de prueba para que se ejecuten:
� Todas las sentencias al menos una vez
� Todas las condiciones con valor verdadero y falso.
• Información de entrada: diseño y código.
![Page 34: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/34.jpg)
Pruebas Estructurales o de Caja Blanca
• Hay distintos criterios de cobertura:
� Cobertura de sentencias
� Cobertura de decisiones� Cobertura de decisiones
� Cobertura de condiciones
� Cobertura de decisión/condición
� Cobertura de condición múltiple
� Cobertura de caminos
![Page 35: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/35.jpg)
Pruebas Funcionales o de Caja Negra
•Se utiliza la especificación del componente
• El componente se ve como una Caja Negra.
• Se estudia el comportamiento a partir de entradas y salidas.
• Técnicas:• Técnicas:
� Partición de Equivalencia
� Análisis de Valores Límite
![Page 36: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/36.jpg)
Partición de Equivalencia
•Se basa en dos consideraciones:
� Se debe dividir el dominio de entrada en clases de datos (clases
de equivalencia).
� Se deben crear casos de prueba que descubran clases de errores.� Se deben crear casos de prueba que descubran clases de errores.
� Se debe minimizar el número total de casos de prueba.
• Dos pasos
� Identificar las clases de equivalencia.
� Identificar los casos de prueba.
![Page 37: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/37.jpg)
Identificar Clases de Equivalencia
• Una clase de equivalencia representa un conjunto de estados válidos o
no válidos para las condiciones de entrada de un programa.
• Se examina cada condición de entrada y se divide en dos o más grupos.
• Se identifican dos tipos de clases:
� Clases de equivalencia válidas.� Clases de equivalencia válidas.
� Clases de equivalencia no válidas.
• Pautas de identificación:
� Rango de valores: una clase válida y dos inválidas.
� Rango de valores: una clase válida y dos no válidas.
� Número de valores: una clase válida y dos no válidas
![Page 38: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/38.jpg)
Identificar Clases de Equivalencia
� Conjunto de valores de entrada: una clase válida y otra no
válida, o también, antas clases válidas como valores y una no
válida.
� Situación (lógica) que debe ocurrir: Una clase válida y una no� Situación (lógica) que debe ocurrir: Una clase válida y una no
válidas.
� Se cree que no todos los elementos de la case se tratan igual:
dividir en subclases.
![Page 39: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/39.jpg)
Identificar Clases de Equivalencia
Condición de
Entrada
Tipo Clases de
Equivalencia
Válidas
Clases de
Equivalencia No
Válidas
Código Blanco Lógica (puede 1: en blanco 3: un valor no
estar o
no).
Si está es rango
2: 100<= código
banco
<= 999
numérico
4: código banco
< 100
5: código banco
> 999
![Page 40: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/40.jpg)
Identificar de los Casos de Prueba
• El objetivo es minimizar el número de casos de prueba.
• Asignar un número único a cada clase de equivalencia.
• Escribir un caso que cubra tantas clases válidas no cubiertas como sea
posible hasta que se cubran todas las clases de equivalencia válidas.posible hasta que se cubran todas las clases de equivalencia válidas.
• Escribir un caso que cubra una sola clase no válida no cubierta hasta
que se cubran todas las clases de equivalencia no válidas.
![Page 41: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/41.jpg)
Análisis de Valores Límites
• Condiciones límite: aquellas que se hallan en los márgenes de las
clases de equivalencia, tanto de entrada como de salida.
• Complementan la técnica anterior:
� Se seleccionan uno o más elementos tal que los márgenes de la
clase se sometan a prueba.clase se sometan a prueba.
� Se considerará también el dominio de salida.
• Selección de casos de prueba:
� Rango de valores: dos casos de prueba para los dos límites del
rango y dos casos para situaciones justo más allá de los extremos.
� Número de valores: casos de prueba para los valores mínimo y
máximo, otros dos casos para valores justo por encima del máximo y
![Page 42: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/42.jpg)
Análisis de Valores Límites
justo por debajo del mínimo.
� Aplicar las reglas anteriores para datos de salida
� Si la entrada o la salida es un conjunto ordenado, atención al
primero y último.primero y último.
![Page 43: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/43.jpg)
Estrategia de Pruebas
• Pruebas Unitarias: (caja blanca y caja negra)
� Cada módulo es probado por separado y por la persona que lo
creó:
� Módulo: pieza de código que cumple:� Módulo: pieza de código que cumple:
� Bloque básico de programa
� Implementa función independiente simple
� Puede probarse por separado
� Normalmente menor de 500 líneas de código.
![Page 44: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/44.jpg)
Estrategia de Pruebas
•Pruebas de Integración: (caja negra)
� Incremental:
� Incremental Ascendente: se combinan los módulos de más
bajo nivel, utilizando controladores para los de más alto nivel.
� Incremental Descendente: se comienza en el módulo de� Incremental Descendente: se comienza en el módulo de
mayor nivel y se incorporan los módulos subordinados bien en
profundidad o anchura
� No incremental
![Page 45: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/45.jpg)
Estrategia de Pruebas
• Pruebas del Sistema: (caja negra)
� Se cumplen los requisitos funcionales establecidos durante el
análisis.
� El funcionamiento y rendimiento en las interfaces hardware,
software y de usuario.software y de usuario.
� La adecuación de la documentación de usuario.
� Rendimiento y respuesta en condiciones límite y de sobrecarga.
� Pruebas Alfa y pruebas Beta.
![Page 46: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/46.jpg)
Estrategia de Pruebas
• Pruebas de Aceptación:
� Participación activa del usuario, que deberá ejecutar casos de
prueba ayudado por miembros del equipo de pruebas.
� Están enfocadas para probar los requisitos de usuario.
� Corresponden a la fase final del proceso de desarrollo software.� Corresponden a la fase final del proceso de desarrollo software.
• Pruebas de Regresión:
� Regresión: Repetición selectiva de pruebas para detectar fallos
introducidos durante la modificación de un sistema o componente.
� En ellas habrá que:
![Page 47: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/47.jpg)
Estrategia de Pruebas
� Probar los módulos cambiados
� Decidir las pruebas a efectuar en los módulos no cambiados.
� Deberán efectuarse:� Deberán efectuarse:
�Cuando existe riesgo de que los cambios afecten a otras áreas
no modificadas directamente.
�Durante el desarrollo, después de ciertos cambios.
�Durante el mantenimiento.
![Page 48: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/48.jpg)
Instrumentos de Control
• Listas de control: definen de forma explícita los puntos concretos que
deben ser controlados al aplicar el procedimiento de control de calidad
• Guiones de recomendaciones: contienen criterios, ideas y• Guiones de recomendaciones: contienen criterios, ideas y
recomendaciones aplicables al realizar las tareas correspondientes a los
procedimientos de control de calidad.
.
![Page 49: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/49.jpg)
Elementos Auxiliares
Hacen referencia a formatos o plantillas que se pueden aplicar a los
distintos documentos auxiliares que se han de ir generando al realizar
las actividades de aseguramiento de la calidad:
• Hojas de comentarios de usuarios.
• Hojas de comentarios de revisión.
• Lista de acciones correctivas.
• Hoja de aprobación provisional.
• Plan de pruebas.
• Informe de pruebas de validación de módulos.
• Informe de pruebas de integración.
• Informe de monitorización de las pruebas de aceptación.
![Page 50: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/50.jpg)
Elementos Auxiliares
• Informe de análisis e interpretación de resultados.
• Plan de auditoría del proyecto.
• Informe de auditoría del proyecto.
• Informe de evaluación del prototipo.
• Informe final de verificación y validación de la aplicación.
![Page 51: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/51.jpg)
Elementos Auxiliares
![Page 52: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/52.jpg)
Elementos Auxiliares
![Page 53: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/53.jpg)
Elementos Auxiliares
![Page 54: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/54.jpg)
Dossier del Aseguramiento de Calidad
• Documentos generados por el EDS:
� DBP: documento base y de planificación.
� DED: documento de especificaciones de diseño.
� DDD: documento de descripción del diseño.
� DDF: documento de diseño funcional.
� DDT: documento de diseño técnico.
� DTP: documentación técnica de programación.
� DOP: documentación de operación.
� DRU: documento de referencia para usuarios.
![Page 55: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/55.jpg)
Dossier del Aseguramiento de Calidad
• Documentos auxiliares generados por el EDS:
� IAIR: informe de análisis e interpretación de resultados de las
pruebas de aceptación.
• Documentos generados por el USR:
�HCU: hojas de comentarios de usuario.
• Documentos generados por el EGC:
� PGC: plan de garantía de calidad del proyecto.
� HCR: hojas de comentarios de revisión.
� LAC: listas de acciones correctivas.
![Page 56: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/56.jpg)
Dossier del Aseguramiento de Calidad
• Documentos generados por el EGC:
� HAP: hojas de aprobación provisional.
� PPRB: plan de pruebas.
� IPVM: informe de pruebas de validación de módulos.
� IPI: informe de pruebas de integración.
� IPAA: informe de monitorización de pruebas de aceptación de la
aplicación.
� IEP: informes de evaluación de prototipos.
� IVVA: informe final de verificación y validación de la aplicación.
![Page 57: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/57.jpg)
Dossier del Aseguramiento de Calidad
• Documentos generados por AUD:
� PAUD: plan de auditoría del proyecto.
� IAUD: informes de auditoría del proyecto.
![Page 58: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/58.jpg)
Plan General de Aseguramiento de Calidad
• Marco homogéneo de referencia para diseñar y aplicar los planes
específicos de calidad a los proyectos.
![Page 59: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/59.jpg)
Objetivos:
• Ofrecer una metodología para elaborar los planes específicos.
• Ofrecer una metodología para evaluar preliminarmente a los
proyectos.
• Elaborar procedimientos e instrumentos de control.
Se estructura en:
• Guía metodológica para elaborar Planes Específicos de
Aseguramiento de la Calidad.
• Esquema formal para la clasificación de proyectos.
• Procedimientos de Control de Calidad.
• Instrumentos de control y elementos auxiliares de aseguramiento
de la calidad.
![Page 60: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/60.jpg)
• Es independiente de las metodologías de desarrollo.
• Se basa en estándares: ISO 8402, 9000, 9001, 9002, 9003, 10011-1,
-2, -3, y diferentes normas ANSI/IEEE.
Características de los planes específicos de calidad
• Adaptación al proyecto y a las circunstancias.
• Respeto de los estándares de aseguramiento de calidad
reconocidos.
![Page 61: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/61.jpg)
Agentes participantes de un proyecto
Relación de los Agentes con el PGAC
![Page 62: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/62.jpg)
Metodología para la elaboración de planes específicos de calidad:
![Page 63: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/63.jpg)
Metodología para la elaboración de planes específicos de calidad:
• Actuaciones preliminares
� Designar al representante de los usuarios
� Designar al director del proyecto
� Elaborar las especificaciones de usuario para
desarrollo/contratación
• Caracterización del proyecto a efectos de calidad
� Designar al responsable de calidad
� Obtener el Diagrama Característico
� Aplicar el esquema Formal de Clasificación
� Modelo de referencia
![Page 64: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/64.jpg)
Metodología para la elaboración de planes específicos de calidad:
� Perfil de riesgo
� Foco de interés
• Selección y adaptación de procedimientos de control calidad
• Selección y adaptación de instrumentos de control de calidad y
elementos auxiliares
• Redacción y aprobación del plan
• Ejecución del plan (y del proyecto)
![Page 65: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/65.jpg)
Selección de Procedimientos de Control – Modelo Secuencial Básico
![Page 66: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/66.jpg)
Selección de Procedimientos de Control
Modelo Secuencial Intermedio
![Page 67: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/67.jpg)
Selección de Procedimientos de Control
Modelo Secuencial Detallado
![Page 68: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/68.jpg)
Selección de Procedimientos de Control
Desarrollo por Evolución de Prototipos
![Page 69: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/69.jpg)
Selección de Procedimientos de Control
Desarrollo Modular
![Page 70: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/70.jpg)
Estructura y contenido del PAC específico del proyecto
• Objetivos y alcance.
• Fases, productos y componentes del proyecto.
• Procedimientos de control.
• Instrumentos de control y elementos auxiliares.
• Organización y gestión del aseguramiento de la calidad del proyecto.
• Registro de actuaciones: el Dossier de Aseguramiento de la Calidad.
• Estándares y normas.
• Documentos de referencia.
• Revisión del Plan.
![Page 71: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/71.jpg)
Esquema formal para la clasificación de proyectos (EFC)
![Page 72: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/72.jpg)
Esquema formal para la clasificación de proyectos (EFC)
![Page 73: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/73.jpg)
Estimación de factores críticos y obtención del diagrama característico
Atributos significativos del proyecto
• Intrínsecos de la aplicación:
� Dimensión (DIM).
� Complejidad (COMP).
� Requisitos de fiabilidad (FIAB).
� Requisitos de seguridad (SEC).
� Requisitos de comportamiento externo (CEX).
� Requisitos de comportamiento interno (CIN).
� Grado de definición y estructura de las especificaciones (DESP).
![Page 74: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/74.jpg)
• Relativos al entorno de implantación:
� Característica de la máquina:
� Tipología (TPMV).
� Funcionalidad (FCMV).
� Grado de distribución y heterogeneidad (DHMV).
� Carga de trabajo (CTR).
� Nivel de interacción con otras aplicaciones o datos del entorno.
� Diferencias entre los entornos de desarrollo y de implementación.
![Page 75: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/75.jpg)
Estimación de factores críticos y obtención del diagrama característico
Atributos significativos del proyecto
• Relativos al proyecto o proceso de desarrollo.
� Coste estimado del proyecto (COST).
� Plazo estimado de ejecución (PLZ).
� Estabilidad del proyecto (EPRY).
� Evaluación previa del contratista (ECON).
� Disponibilidad de recursos para el aseguramiento de la calidad.
![Page 76: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/76.jpg)
Estimación de factores críticos y obtención del diagrama característico
Atributos significativos del proyecto
• El rango de todos ellos es 1..5.
• Dimensión (DIM).
� 1: pequeño. 1 a 6 meses hombre.
� 2: moderado. 6 a 24 meses hombre.
� 3: mediano. 24 a 60 meses hombre.
� 4: grande. 60 a 120 meses hombre.
� 5: muy grande. >= 120 meses hombre.
• Complejidad (COMP).
� Los factores a considerar son:
![Page 77: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/77.jpg)
Estimación de factores críticos y obtención del diagrama característico
� Nº de módulos y nivel de interrelación.
� Nº y tipo de interfaces con otros sistemas.
� Distribución y heterogeneidad del entorno de implantación.
� Grado de satisfacción de las herramientas de desarrollo.
� Naturaleza de los algoritmos que hay que diseñar e
implementar.
� Otros factores.
� A cada factor se le asigna un valor de 1 a 5 y se promedia el valor
final.
![Page 78: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/78.jpg)
Estimación de factores críticos y obtención del diagrama característico
• Requisitos de fiabilidad (FIAB).
� 1: el efecto de un fallo no causa perjuicio significativo para el
usuario.
� 2: el efecto de un defecto causa perjuicios que el usuario puede
asumir.
� 3: el efecto del defecto lo puede asumir el usuario a un elevado
coste.
� 4: el defecto causa grandes pérdidas al usuario o perjuicios a un
número considerable de personas.
� 5: el defecto puede poner en peligro vidas humanas o causar
pérdidas irrecuperables.
![Page 79: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/79.jpg)
Estimación de factores críticos y obtención del diagrama característico
• Requisitos de seguridad (SEC).
� 1 a 3: sistemas administrativos.
� 4 a 5: sistemas críticos.
• Requisitos de comportamiento externo (CEX).
� 1: inexistencia de requisitos de comportamiento externo en el
documento de especificaciones.
� . . .
� 5: condicionantes muy severos de requisitos de comportamiento
externo.
• Requisitos de comportamiento interno (CIN).
W 1: inexistencia de requisitos de comportamiento interno en el
documento de especificaciones.
![Page 80: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/80.jpg)
Estimación de factores críticos y obtención del diagrama característico
� 1: inexistencia de requisitos de comportamiento interno en el
documento de especificaciones.
� . . .
� 5: condicionantes muy severos de requisitos de comportamiento
interno.
• Grado de definición, estructura y modularidad de las especificaciones
(DESP).
� 1 a 4: en función de la claridad, facilidad de comprensión,
verificabilidad, trazabilidad, . . .
� 5: las especificaciones, además de un buen nivel de detalle
poseen un notable grado de modularidad.
![Page 81: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/81.jpg)
Estimación de factores críticos y obtención del diagrama característico
• Tipología de la máquina virtual (TPMV).
� 1: bajo nivel de sofisticación.
� 2: moderado nivel de sofisticación.
� 3: nivel intermedio de sofisticación.
� 4: Nivel alto de sofisticación.
� 5: Nivel muy alto de sofisticación.
• Funcionalidad de la máquina virtual (FCMV).
� 1 a 3: rica.
� 4 a 5: pobre.
![Page 82: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/82.jpg)
• Grado de destribución y heterogeneidad de la máquina virtual
(DHMV).
� 1: sistema monolítico.
� 2: varias plataformas hardware idénticas con el mismo sistema
operativo y el mismo software intermedio.
� 3: varias plataformas hardware con la misma familia de
ordenadores con el mismo sistema operativo y el mismo software
intermedio.
� 4: varias plataformas hradware diferentes, con diferentes
sistemas operativos y con el mismo software intermedio.
� 5: varias plataformas hardware diferentes, con diferentes
sistemas operativos y con diferentes software intermedio.
![Page 83: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/83.jpg)
•Carga de trabajo (CTR).
� 1: mínima severidad de las condiciones de carga de trabajo.
� . . .
� 5: máxima severidad de las condiciones de carga de trabajo.
•Nivel de interacción con otros sistemas o datos (INT).
� 1: no existe interacción.
� 2: el sistema usa datos o procedimientos compartidos.
� 3: el sistema actúa como post-procesador de otros sistemas.
� 4: el sistema actúa en modo cliente-servidor con otros sistemas.
� 5: el sistema intercambia mensajes y datos con otros sistemas en
un entorno distribuido y heterogéneo.
![Page 84: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/84.jpg)
• Diferencias entre los entornos de desarrollo y de implementación
(DIFE).
� 1: total coincidencia.
� 2: coincidencia en la máquina pero existen diferencias
organizativas y de recursos humanos.
� 3: diferencias moderadas en la máquina y en las organizaciones.
� Diferencias significativas en la máquina y en las organizaciones.
� Diferencias acusadas en la máquina y en las organizaciones.
![Page 85: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/85.jpg)
•Costo total estimado del proyecto (COST).
� 1: pequeño (<= 18.000 unidades monetarias).
� 2: moderado (18000 <= costo <= 60000).
� 3: medio (60000 <= costo <= 150000).
� 4: grande (150000 <= costo <= 600000).
� 5: muy grande (>= 600000).
• Plazo estimado de desarrollo (PLZ).
� 1: pequeño (<= 3 meses).
� 2: moderado (3 meses <= plazo <= 6 meses).
� 3: medio (6 meses <= plazo <= 1 año).
� 4: grande (1 año <= plazo <= 2 años).
� 5: muy grande (>= 2 años).
![Page 86: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/86.jpg)
• Estabilidad del proyecto (EPRY).
� Se puede contemplar:
� Definición, exhaustividad y precisión de las especificaciones.
� Neutralidad del dominio del problema frente a disposiciones
normativas de probable aparición.
� Independencia de las especificaciones respecto al entorno de
implantación.
� Permanencia de los usuario s o promotores.
� Número de interlocutores o centros de decisión afectados por el
proyecto.
� Grado de homogeneidad y de comunidad de intereses entre los
distintos interlocutores.
![Page 87: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/87.jpg)
Diagrama característico de un Proyecto Informático (modelo parrilla)
![Page 88: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/88.jpg)
Diagrama característico de un Proyecto Informático (ejemplo hipotético)
![Page 89: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/89.jpg)
Selección del Modelo de Referencia
El PGAC contempla cinco (5) modelos de referencia:
� Secuencial básico.
� Secuencial intermedio.
� Secuencial detallado.
� Desarrollo evolutivo por prototipo.
� Desarrollo modular.
![Page 90: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/90.jpg)
Modelo Secuencial Básico
![Page 91: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/91.jpg)
Secuencial Básico
Productos a obtener:
• Diseño: documento de especificaciones de diseño (DED); documento
de descripción del diseño (DDD).
• Programación: código fuente; documentación técnica de programación
(DTP).
• Implantación y pruebas de aceptación: aplicación software ejecutable
(APL); documento de operación (DOP); documento de referencia para
usuarios (DRU).
![Page 92: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/92.jpg)
Modelo Secuencial Básico
![Page 93: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/93.jpg)
Modelo Secuencial Intermedio
![Page 94: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/94.jpg)
Secuencial Intermedio
Productos a obtener:
• Elaboración especificaciones de diseño: documento de
especificaciones de diseño (DED).
• Diseño funcional: documento de diseño funcional (DDF).
• Diseño técnico detallado: documento de diseño técnico (DDT).
• Programación: código fuente; documentación técnica de programación
(DTP).
• Implantación y pruebas de aceptación: aplicación software ejecutable
(APL); documento de operación (DOP); documento de referencia para
usuarios (DRU).
![Page 95: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/95.jpg)
Modelo Secuencial Intermedio
![Page 96: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/96.jpg)
Modelo Secuencial Detallado
![Page 97: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/97.jpg)
Secuencial Detallado
Productos a obtener:
•Planificación del desarrollo: Documento base de planificación del desarrollo (DBP)
• Elaboración especificaciones de diseño: documento de especificaciones de diseño
(DED).
• Diseño funcional: documento de diseño funcional (DDF).• Diseño funcional: documento de diseño funcional (DDF).
• Diseño técnico detallado: documento de diseño técnico (DDT).
• Programación: código fuente; documentación técnica de programación (DTP).
• Integración: software ejecutable de partes constituyentes de la aplicación (APL).
• Implantación y pruebas de aceptación: aplicación software ejecutable (APL);
documento de operación (DOP); documento de referencia para usuarios (DRU).
![Page 98: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/98.jpg)
Modelo Secuencial Detallado
![Page 99: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/99.jpg)
Modelo Desarrollo Evolución de Prototipos
![Page 100: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/100.jpg)
Productos a obtener:
•Procesos de experimentación: por cada iteración se realiza el Informe de Evaluación
del Prototipo (IEP).
• Especificaciones finales y diseño:
� documento de especificaciones de diseño (DED) y documento de descripción
Modelo Desarrollo Evolución de Prototipos
� documento de especificaciones de diseño (DED) y documento de descripción
del diseño (DDD), si se sigue el modelo secuencial básico.
� documento de diseño funcional (DDF) y documento de diseño técnico (DDT), si
se sigue el modelo secuencial intermedio.
• Programación: código fuente; documentación técnica de programación (DTP).
• Implantación y pruebas de aceptación: aplicación software ejecutable (APL);
documento de operación (DOP); documento de referencia para usuarios (DRU).
![Page 101: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/101.jpg)
Modelo Desarrollo Evolución de Prototipos
![Page 102: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/102.jpg)
Modelo Desarrollo Modular
![Page 103: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/103.jpg)
Productos a obtener:
•Estudio preliminar y planificación del desarrollo: Documento base de
planificación del desarrollo (DBP).
• Desarrollo de módulos en paralelo: los correspondientes a cada fase
del modelo secuencial que se siga y aplicados a cada uno de los
Modelo Desarrollo Modular
módulos.
• Integración de módulos: software ejecutable e integrado de todos los
módulos.
• Implantación y pruebas de aceptación: aplicación software ejecutable
(APL); documento de operación (DOP); documento de referencia para
usuarios (DRU).
![Page 104: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/104.jpg)
Modelo Desarrollo Modular
![Page 105: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/105.jpg)
Pasos a seguir:
•Evaluar los factores de discriminación del proyecto (FDPi) en relación
con cada uno de los modelos de referencia. Para ello, para cada modelo:
�Se contrasta el diagrama característico del proyecto con la plantilla
de comparación correspondiente.
Selección del Modelo de Referencia
�Para cada fila de la parrilla (atributo Aj) se obtiene el valor del
factor de discriminación parcial fj:
n
dtf
kjkj
)*(∑=
![Page 106: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/106.jpg)
tjk= valor de cada uno de los cuadros de la trama del diagrama
característico del proyecto no cubierto por la trama de la plantilla de
comparación que se está utilizando.
Selección del Modelo de Referencia
dk= distancia medida entre ese cuadro y el que resulte más próximo en
la plantilla (valor absoluto de la diferencia entre los valores
correspondientes).
n= número total de cuadros del diagrama característico no cubiertos
por la plantilla del modelo, en la fila de que se trate.
![Page 107: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/107.jpg)
� El valor del FDPi correspondiente es la media aritmética simple de
los valores fj:
Selección del Modelo de Referencia
18∑=
jfFDPi
• Se seleccionará el modelo que presente el FDPi menor.
18=FDPi
![Page 108: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/108.jpg)
Selección del Modelo de Referencia – Plantillas de Comparación
![Page 109: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/109.jpg)
Selección del Modelo de Referencia – Plantillas de Comparación
![Page 110: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/110.jpg)
Selección del Modelo de Referencia – Plantillas de Comparación
![Page 111: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/111.jpg)
Selección del Modelo de Referencia – Comparación con la Plantilla
![Page 112: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/112.jpg)
Selección del Modelo de Referencia – Comparación con la Plantilla
![Page 113: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/113.jpg)
Selección del Modelo de Referencia – Comparación con la Plantilla
![Page 114: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/114.jpg)
•Dos umbrales de riesgos: ordinario y extraordinario.
• Siete tipos de riesgos:
� R1: defectos graves y recurrentes en el comportamiento externo
de la aplicación.
� R2: baja calidad de los productos obtenidos en las fases del
Obtención del Perfil de Riesgos
desarrollo.
� R3: dificultades graves de implantación por mala adecuación de la
aplicación a su entorno real de operación.
� R4: imposibilidad de mantener los costes de desarrollo en
consonancia con lo establecido en la contratación.
� R5: incumplimiento grave de los plazos de ejecución.
![Page 115: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/115.jpg)
� R6: imposibilidad de gestionar y controlar adecuadamente el
desarrollo del proyecto.
� R7: no finalización del proyecto.
• Se ha de obtener el coeficiente de divergencia Cdi para cada tipo de
Obtención del Perfil de Riesgos
riesgo:
mn
aCD
m
kbik
n
jij
j∑∑ == −= 11
![Page 116: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/116.jpg)
Los atributos de los grupos A y B para cada tipo de riesgo son:
• Para R1.
� Grupo A: [FIAB], [SEC], [CEX],[CTR], [ECON]
� Grupo B: [DESP], [PLZ], [REC]
• Para R2.
Obtención del Perfil de Riesgos
� Grupo A: [DIM], [COMP], [FIAB], [SEC], [CEX], [ECON]
� Grupo B: [DESP], [COST], [PLZ], [EPRY], [REC]
• Para R3.
� Grupo A: [CIN], [FCMV], [DHMV], [INT], [DIFE], [ECON]
� Grupo B: [COST], [PLZ], [REC]
![Page 117: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/117.jpg)
•Para R4.
� Grupo A: [DIM], [COMP], [FIAB], [FCMV], [ECON]
� Grupo B: [DESP], [COST], [EPRY]
• Para R5.
Obtención del Perfil de Riesgos
� Grupo A: [DIM], [COMP], [FIAB], [FCMV], [ECON]
� Grupo B: [DESP], [PLZ], [EPRY]
• Para R6.
� Grupo A: [DIM], [COMP]
� Grupo B: [REC]
![Page 118: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/118.jpg)
• Para R7.
� Grupo A: [DIM], [COMP], [FIAB], [SEC], [CEX], [CIN], [TPMV],
[FCMV], [DHMV], [CTR], [INT], [DIFE], [ECON]
� Grupo B: [DESP], [COST], [PLZ], [EPRY], [REC]
Obtención del Perfil de Riesgos
• La interpretación de los valores obtenidos para cada Cdi es:
� 0 <= Cdi < 3 : nivel ordinario de riesgos.
� 3 <= Cdi <= 5 : nivel de riesgos extraordinarios.
� -3 < Cdi <= 0 : proyecto satisfactorio.
� -5 <= Cdi <= -3 : planteamiento inicial del proyecto desajustado.
![Page 119: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/119.jpg)
• Se obtiene el perfil de riesgos del proyecto:
Obtención del Perfil de Riesgos
![Page 120: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/120.jpg)
• Permite diseñar el plan específico de garantía de calidad del proyecto.
• Se asigna a cada fase y producto del proyecto el nivel de intensidad
correspondiente.
• Los dos niveles de intensidad son: normal (1) y especial (2).
• El procedimiento a seguir:
Determinación del foco de interés
� Se contrasta el diagrama característico del proyetco con la
plantilla correspondiente.
� Se elabora la matriz de intensidades.
� Se deduce el grado de intensidad más adecuado para el control
de las fases y productos a partir de la matriz de intensidades y de la
criticidad de los atributos del proyecto.
![Page 121: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/121.jpg)
• A partir del foco de interés se diseña el plan específico de garantía de
calidad del proyecto.
• Existe un nivel mínimo de intensidad (0) aplicable a las situaciones en
las que no se disponga de recursos adecuados para la gestión de la
garantía de calidad.
Determinación del foco de interés
![Page 122: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/122.jpg)
Determinación del foco de interés – Modelo Secuencial Básico
![Page 123: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/123.jpg)
Determinación del foco de interés – Modelo Secuencial Intermedio
![Page 124: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/124.jpg)
Determinación del foco de interés – Modelo Secuencial Detallado
![Page 125: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/125.jpg)
Determinación del foco de interés – Modelo Desarrollo Prototipos
![Page 126: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/126.jpg)
Determinación del foco de interés – Modelo Desarrollo Modular
![Page 127: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/127.jpg)
Determinación del foco de interés – Ejemplo
![Page 128: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/128.jpg)
Determinación del foco de interés – Ejemplo
![Page 129: Unidad III gestion de proyecto](https://reader031.fdocuments.ec/reader031/viewer/2022020102/55cf913a550346f57b8bc5a5/html5/thumbnails/129.jpg)
• Según la matriz anterior, el foco de interés del proyecto ejemplo sería:
� Fase 1( Análisis ): nivel 1
� Fase 2(Desarrollo):
� 21.(Especificaciones): nivel 2.
� 2.2.1 (Diseño funcional): nivel 1.
Determinación del foco de interés
� 2.2.2. (Diseño técnico): nivel 1.
� 2.3 (Programación): nivel 1.
� 2.4 (Pruebas del módulo): nivel 2.
� Fase 3 (Integración de módulos): nivel 2.
� Fase 4: Pruebas de aceptación): nivel 2.