La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

PLAN DEL PROYECTO UNIDAD 4 Ing. Francisco Mauro Salgado.

Presentaciones similares


Presentación del tema: "PLAN DEL PROYECTO UNIDAD 4 Ing. Francisco Mauro Salgado."— Transcripción de la presentación:

1 PLAN DEL PROYECTO UNIDAD 4 Ing. Francisco Mauro Salgado

2 Contenido Plan del Proyecto Plan del Proyecto –4.1 Objetivo de la planeación –4.2 Programa de actividades. –4.3 Factores de costos de software. –4.4 Métricas de procesos de desarrollo de software. –4.5 Estimación de los costos –4.6 Evaluación de riesgos. –4.7 Plan de aseguramiento de la calidad de software. –4.8 Plan del control de la configuración.

3 4.1 Objetivo de la planeación

4 Planeación de Proyectos de Software El objetivo principal de la planeación del proyecto es establecer una estrategia pragmática para controlar, rastrear y monitorear un proyecto técnico complejo ¿Por qué? ¡Para que los resultados finales se obtengan a tiempo y con calidad!

5 Alcance – entender el problema y el trabajo que debe ser realizado Alcance – entender el problema y el trabajo que debe ser realizado Estimación – ¿qué tanto esfuerzo? ¿cuánto tiempo? Estimación – ¿qué tanto esfuerzo? ¿cuánto tiempo? Riesgo – ¿qué puede salir mal? ¿cómo evitarlo? ¿qué podemos hacer? Riesgo – ¿qué puede salir mal? ¿cómo evitarlo? ¿qué podemos hacer? Calendarización – ¿cómo ubicamos los recursos a través del tiempo? ¿cuáles son los hitos? Calendarización – ¿cómo ubicamos los recursos a través del tiempo? ¿cuáles son los hitos? Estrategia de Control – ¿cómo controlar la calidad?¿cómo controlar el cambio? Estrategia de Control – ¿cómo controlar la calidad?¿cómo controlar el cambio? Pasos

6 ¡Escríbalo! PlandeProyectodeSoftware Alcance del Proyecto ProyectoEstimacionesRiesgosCalendario Estrategia de Control Control

7 4.2 Programa de actividades

8 Definir conjuntos de tareas Datos de métricas que indican un área problema no deben ser considerados negativos. Estos datos son meramente un inidicador en la mejora del proceso Datos de métricas que indican un área problema no deben ser considerados negativos. Estos datos son meramente un inidicador en la mejora del proceso No obsesionarse una simple métrica para exluicr otras métricas importantes No obsesionarse una simple métrica para exluicr otras métricas importantes

9 Definir una Red de Tareas I.1 Alcance del Concepto Las 3 tareas I3 son aplicadas en paralelo a 3 diferentes funciones del concepto I.2 Planeación del Concepto I.3a Valuación de Riesgos Técnicos I.3b Valuación de Riesgos Técnicos I.3c Valuación de Riesgos Técnicos Las 3 tareas I5 son aplicadas en paralelo a 3 diferentes funciones del concepto I.5a Implement. del Concepto I.4. Prueba del Concepto I.5b Implement. del Concepto I.5c Implement. del Concepto Integrar a,b,c I.6 Reacción del Cliente

10 Utilizar herramientas automatizadas para generar una gráfica de Gantt I.1.1 Identificar necesidades y beneficios Reunión con los clientes Identificar necesidades y restr. del proy. Establecer la declaración del producto Hito: Declaración del Producto Definida I.1.2 Definir la salida/control/entreada (OCI) Alcance de las funciones de teclado Alcance de las funciones por voz Alcance de los modos de interacción Alcance del documento de diagnóstico Alcance de otras funciones Documentar OCI (outpu, control, input) FTR: Revisar OCI con el cliente Revisar OCI como se requiere Hito: OCI definida (output,control,input) I.1.3 Definir la funcionalidad/comportamiento Definir las funciones de teclado Definir las funicones de entrada por voz Describir los modos de interacción Describir el chequeo de ortografía/redacc. Describir otras funciones del WP FTR: Revisar definición OCI con cliente Revisar como se requiere Hito: Definición de OCI completada I.1.4 Aislar los elementos de software Hito: Elementos de Software Definidos I.1.5 Investigar disponibilidad de Sw existente Investigar componentes de edición de texto Investigar componentes de entrada de voz Investigar componentes de adm. de arch. Investigar componentes ortogr./redacción Hito: Identificación de componente reusables I.1.6 Definir características técnicas Evaluar la entrada por voz Evaluar el chequeo de gramática Hito: Características Técnicas Evaluadas I.1.7 Hacer una estimación rápida del tamaño I.1.8 Crear la Definición del Alcance Revisar el alcance de docs con el cliente Revisar el documento como se requiere Hito: Documento de Alcance completado semana 1semana 2semana 3semana 4Tareas del Proyectosemana 5

11 4.3 Factores de costos de desarrollo de software.

12 El Costo del Cambio de Requerimientos Definición Desarrollo Después de liberación 1x 1.5-6x x

13 Utilización vs. Deterioro Curva idealizada cambio curva actual Tasa de Fallos Tiempo Incremento de tasa de fallas debido a efectos colaterales

14 ¿Por qué se pagan las actividades de SQA? costo para encontrar y corregir un defecto escalalogarítmica 1 Req. Diseño código prueba pruebas de sistema uso en campo

15 4.4 Métricas de procesos de desarrollo de software.

16 Medición y Métrica... recolectar métricas es muy difícil... consume mucho tiempo... es muy burocrático... no probarán nada... Cualquier cosas que necesites cuantificar debe ser medido y de alguna forma es superior a no medirlo del todo Tom Gilb

17 ¿Por qué debemos medir? Señalar Señalar Evaluar Evaluar Predecir Predecir Mejorar Mejorar

18 Medidas para el Administrador medición ¿Quéusamos como base? ¿tamaño? ¿tamaño? ¿función? ¿función? métricas de proyecto métricas de proceso proceso producto métricas de producto

19 Métricas de Proceso mayor enfoque sobre la calidad lograda como consecuencia del proceso repetible o administrado mayor enfoque sobre la calidad lograda como consecuencia del proceso repetible o administrado datos de SQA estadísticos datos de SQA estadísticos – análisis y categorización de errores eficiencia en remoción de defectos eficiencia en remoción de defectos – propagación de fase en fase reuso de datos reuso de datos

20 Métricas de Proyecto Esfuerzo/Tiempo por Tarea de IngSw Esfuerzo/Tiempo por Tarea de IngSw Errores no cubiertos por hora de revisión Errores no cubiertos por hora de revisión Fechas de entrega reales vs programadas Fechas de entrega reales vs programadas Cambios (número) y sus características Cambios (número) y sus características Distribución del esfuerzo sobre tareas de IngSw Distribución del esfuerzo sobre tareas de IngSw

21 Métricas sobre Producto enfoque en la calidad de los entregables enfoque en la calidad de los entregables medidas del modelo de análisis medidas del modelo de análisis complejidad del diseño complejidad del diseño – complejidad algorítmica interna – complejidad arquitectónica – complejidad del flujo de datos medidas de código (v.g. Halstead) medidas de código (v.g. Halstead) medidas de la efectividad del proceso medidas de la efectividad del proceso – v.g. eficiencia en remoción de defectos

22 Lineamientos sobre Métricas Utilizar el sentido co´mún y la sensitividad organizacional al interpretar los datos de las métricas Utilizar el sentido co´mún y la sensitividad organizacional al interpretar los datos de las métricas Proveer retroalimentación regular a los individuos y equipos que han trabajado en recolectar medidas y métricas. Proveer retroalimentación regular a los individuos y equipos que han trabajado en recolectar medidas y métricas. No utilizar las métricas para amedrentar a los individuos No utilizar las métricas para amedrentar a los individuos Trabajar con los practicantes y equipos para establecer metas y métricas claras que serán utilizadas para medirlos Trabajar con los practicantes y equipos para establecer metas y métricas claras que serán utilizadas para medirlos Nunca utilizar las métricas para amenazar a los individuos o equipos Nunca utilizar las métricas para amenazar a los individuos o equipos

23 Normalización de las métricas Los datos normalizados son utilizados para evaluar el proceso y el producto (pero nunca a los individuos) normalización orientada al tamaño Por líneas de código normalización orientada a la función Por puntos función

24 Métricas típicas orientadas al tamaño Errores por KLOC (Miles de Líneas de Código) Errores por KLOC (Miles de Líneas de Código) Defectos por KLOC Defectos por KLOC $ por LOC $ por LOC páginas de documentos por KLOC páginas de documentos por KLOC errores / persona-mes errores / persona-mes LOC / persona-mes LOC / persona-mes $ / página de documentación $ / página de documentación

25 Métricas Típicas Orientadas a Función errores por FP (cientos de líneas de código) errores por FP (cientos de líneas de código) defectos por FP defectos por FP $ por FP $ por FP páginas de documentación por FP páginas de documentación por FP determinar el tipo de proyecto determinar el tipo de proyecto valorar el grado de rigor requerido valorar el grado de rigor requerido – identificar el criterio de adapación – calcular el valor de Task Set Selector (TSS) – interpretar el TSS para determinar el grado de rigor seleccionar las tareas de ingeniería de softwre apropiadas seleccionar las tareas de ingeniería de softwre apropiadas FP por persona-mes FP por persona-mes

26 ¿Por qué la preferencia a FP? independencia del lenguaje de programación utiliza inmediatamente características contables del dominio de información del problema no penalizar implementaciones que requieren menos LOCs que otras (vs. mantenimiento) facilitan el reuso y favorecen a las iniciativas orientadas a objetos

27 Calcular Puntos Función Analizar el dominio de la información de la aplicaciòn y desarrollar el conteo Pesar cada conteo por evaluación de la complejidad evaluar la influencia de factores globales que afecten la aplicación Calcular puntos función Establecer el conteo para cada dominio de entrada e interfaces de sistema Asignar el nivel de complejidad o peso para cada conteo Grado de importancia de factores externos F i tales como reuso, concurrencia, SO,... Grado de influencia: N = F i Factor de complejidad: C = ( x N) Puntos función = (conteo x peso) x C donde:

28 Analizar el Dominio de la Información factor de complejidad puntos función # de entradas de usuario # de salidas de usuario # de consultas # de archivos # of interfaces ext. parámetro de medida conteo factor de ponderación simple prom. complejo = = = = = conteo-total X X X X X

29 Considerar la Complejidad Los factores se tasan en una escala 0 (sin importancia) – 5 (muy importante) comunicaciones de datos funciones distribuidas configuración pesada tasa de transacción entrada de datos en lìnea eficiencia para el usuario actualización en línea procesamiento complejo facilidad de instalación facilidad operacional sites múltiples facilidad de cambios

30 Medición de la Calidad Corrección – grado en el cual un programa opera conforme a las especificaciones Corrección – grado en el cual un programa opera conforme a las especificaciones Mantenibilidad – grado en el que un programa es conveniente al cambio Mantenibilidad – grado en el que un programa es conveniente al cambio Integridad – grado en el cual un programa permite el ataque externo Integridad – grado en el cual un programa permite el ataque externo Usabilidad – grado en el cual un programa es fácil de usar Usabilidad – grado en el cual un programa es fácil de usar

31 Eficiencia de Remoción de Errores Defect Removal Efficiency DRE = (errores) / (errores + defectos) donde errores = problemas encontrados antes de la liberación defectos = problemas encontrados después de la liberación

32 4.5 Estimación de costos

33 Estimación de Costos el alcance del proyecto debe ser explícitamente definido la descomposición de tareas y/o funciones es necesaria las mediciones(métricas) históricas son de gran ayuda Por lo menos 2 diferentes técnicas debieran utilizarse recordar la falta de certidumbre inherente

34 Técnicas de Estimación experiencia de proyectos pasados (similares) experiencia de proyectos pasados (similares) técnicas de estimación convencional técnicas de estimación convencional – división de tareas y estimación de esfuerzo – estimación de tamaño (v.g. FP) herramientas (v.g., Checkpoint) herramientas (v.g., Checkpoint)

35 Descomposición Funcional Declaración del Alcance realizar un análisis gramatical" descomposiciónfuncional

36 Métodos Convencionales: LOC/FP calcular LOC/FP utilizando estimaciones de valores del dominio de información calcular LOC/FP utilizando estimaciones de valores del dominio de información recurrir al esfuerzo histórico de proyectos recurrir al esfuerzo histórico de proyectos

37 Ejemplo de LOC Funciones UICF 2DGA 3DGA DSM CGDF PCF DAM Totals LOC estim.$/LOC Costo Effort (months)LOC/pm , , , ,000 60, ,000 60, , ,

38 Ejemplo FP # entradas de usuario # salidas de usuario # de consultas # de archivos # interfaces externas algoritmos parámetro de medida counteo x x x x x x conteo total = = = = = = peso factor de complejidad puntos función 0.25 p-m / FP = 120 p-m

39 Estimación basada en herramientas características del proyecto factores de calibración datos de LOC/FP

40 Empirical Estimation Models Forma general: esfuerzo = coefte_afinación * tamaño exponente usualmente referido como personas-mes de esfuerzo requerido constante o número derivado basado en la complejidad del proyecto usualmente LOC pero pueden ser FPs derivado empíricamente

41 Lineamientos de Estimación estimar utilizando por lo menos 2 técnicas obtener estimaciones de fuentes independientes evitar el sobre-optimismo, asumir las dificultades si se ha llegado a una estimación, trabajar sobre ella ajustarse al personal que hará el trabajo – tienen el mayor impacto

42 Decisión de compra sistema X difícil (0.70) $380,000 $450,000 $275,000 $310,000 $490,000 $210,000 $400,000 $350,000 $500,000 construir Outsourcing reusar comprar simple (0.30) cambios menores (0.40) cambios mayores (0.60) simple (0.20) complejo (0.80) cambios menores (0.70) cambios mayores (0.30) sin cambios (0.80) con cambios (0.40)

43 Cálculo del Costo Esperado (RutaProbabilidad) i x (CostoRutaEstim) i (RutaProbabilidad) i x (CostoRutaEstim) i Por ejemplo, el costo esperado para construir costo esperado construir = 0.30($380K)+0.70($450K) en forma similar, costo esperado= = $429 K costo esperado reuso = $382K costo esperado comprar = $267K costo esperado outsrc = $410K

44 4.6 Evaluación de Riesgos

45 Construir una Tabla de Riesgos RiesgoProbabilidadImpactoRMMM (RiskMitigationMonitoring&Management) (Admón. y Monitoreo de la Mitigación de Riesgos)

46 Construir la Tabla de Riesgos Estimar la probabilidad de ocurrencia Estimar la probabilidad de ocurrencia Estimar el impact sobre el proyecto en una escala del 1 al 5, donde Estimar el impact sobre el proyecto en una escala del 1 al 5, donde – 1 = bajo impacto sobre el éxito del proyecto – 5 = impacto catastrófico sobre el éxito del proyecto ordenar la tabla por probabilidad e impacto ordenar la tabla por probabilidad e impacto

47 mitigación mitigación – ¿Cómo se puede evitar el riesgo? monitoreo monitoreo – ¿Qué factores podemos vigialar que nos permitan ser capaces de determinar si el riesgo es más o menos probable? administración administración – ¿con qué planes de contigencia contamos si el riesgo se vuelve realidad? Administración, Monitoreo y Mitigación de Riesgos

48 Riesgos Asociados al Tamaño del Producto ¿tamaño estimado del proyecto en LOC o FP? ¿tamaño estimado del proyecto en LOC o FP? ¿tamaño estimado del proyecto en número de ¿tamaño estimado del proyecto en número de programas, archivos, transacciones? programas, archivos, transacciones? ¿porcentaje de desviación en el tamaño del ¿porcentaje de desviación en el tamaño del producto del promedio de los productos anteriores? producto del promedio de los productos anteriores? ¿tamaño de las bases de datos creadas o utilizadas ¿tamaño de las bases de datos creadas o utilizadas por el producto? por el producto? ¿número de usuarios del producto? ¿número de usuarios del producto? ¿número de cambios proyectados a los ¿número de cambios proyectados a los requerimientos del proyecto?¿antes de la entrega? requerimientos del proyecto?¿antes de la entrega? ¿después de la entrega? ¿después de la entrega? ¿cantidad de software reusado? ¿cantidad de software reusado? Atributos que afectan al riesgo:

49 Riesgos Asociados al Impacto del Negocio ¿afectación de este producto en las utilidades de la empresa? ¿afectación de este producto en las utilidades de la empresa? ¿visibilidad de este producto por la alta gerencia? ¿visibilidad de este producto por la alta gerencia? ¿razonabilidad del tiempo de entrega? ¿razonabilidad del tiempo de entrega? ¿número de clientes que utilizarán este producto? ¿número de clientes que utilizarán este producto? restricciones de interoperabilidad restricciones de interoperabilidad ¿sofisticación de los usuarios finales? ¿sofisticación de los usuarios finales? ¿cantidad y calidad de documentación del producto que debe ¿cantidad y calidad de documentación del producto que debe ser producida y enviada al cliente? ser producida y enviada al cliente? restricciones gubernamentales restricciones gubernamentales ¿costos de entregar tarde el producto? ¿costos de entregar tarde el producto? ¿costos asociados con un producto defectuoso? ¿costos asociados con un producto defectuoso? Atributos que afectan al riesgo:

50 Riesgos Asociados al Cliente ¿se ha trabajado con ese cliente en el pasado? ¿se ha trabajado con ese cliente en el pasado? ¿el cliente tiene una idea sólida de lo que requiere? ¿el cliente tiene una idea sólida de lo que requiere? ¿el cliente está de acuerdo en trabajar contigo? ¿el cliente está de acuerdo en trabajar contigo? ¿el cliente participaría en las revisiones? ¿el cliente participaría en las revisiones? ¿el cliente es técnicamente sofisticado? ¿el cliente es técnicamente sofisticado? ¿el cliente permitiría el poder hacer el trabajo – ¿el cliente permitiría el poder hacer el trabajo – esto es, el cliente resistiría observar sobre tus esto es, el cliente resistiría observar sobre tus hombros durante el trabajo técnico detallado? hombros durante el trabajo técnico detallado? ¿el cliente entiende el proceso de ingeniería de ¿el cliente entiende el proceso de ingeniería de software? software? Cuestionamientos que deben ser resueltos:

51 Riesgos Asociados a la Madurez del Proceso ¿has establecido un framework de proceso común? ¿has establecido un framework de proceso común? ¿lo siguen los equipos de proyecto? ¿lo siguen los equipos de proyecto? ¿tienes soporte de administración para la ingeniería ¿tienes soporte de administración para la ingeniería de software? de software? ¿realizas proactivamente el SQA? ¿realizas proactivamente el SQA? ¿realizas las reuniones técnicas formales? ¿realizas las reuniones técnicas formales? ¿se utilizan herramientas CASE para el análisis, ¿se utilizan herramientas CASE para el análisis, diseño y pruebas? diseño y pruebas? ¿están las herramientas integradas con alguna otra? ¿están las herramientas integradas con alguna otra? ¿se han establecido formatos de documentos? ¿se han establecido formatos de documentos? Cuestionamientos que deben ser resueltos:

52 Riesgos de Tecnología ¿la tecnología es nueva en tu organización? ¿la tecnología es nueva en tu organización? ¿se requieren nuevos algoritmos, tecnologías de E/S? ¿se requieren nuevos algoritmos, tecnologías de E/S? ¿se involucra hardware nuevo o sin probar? ¿se involucra hardware nuevo o sin probar? ¿se interfaza la aplicación con un nuevo software? ¿se interfaza la aplicación con un nuevo software? ¿se requiere una interfaz de usuario especializada? ¿se requiere una interfaz de usuario especializada? ¿la aplicación es radicalmente diferente? ¿la aplicación es radicalmente diferente? ¿estás utilizando nuevos métodos de ingeniería de Sw? ¿estás utilizando nuevos métodos de ingeniería de Sw? ¿estás utilizando métodos de desarrollo de software no ¿estás utilizando métodos de desarrollo de software no convencionales, tales como métodos formales, convencionales, tales como métodos formales, inteligencia artificial, redes neuronales, etc? inteligencia artificial, redes neuronales, etc? ¿hay restricciones de desempeño significativo? ¿hay restricciones de desempeño significativo? ¿existe la duda si la funcionalidad requerida es ¿existe la duda si la funcionalidad requerida es realizable? realizable? Cuestiones que deben ser resueltas:

53 Riesgos Asociados a las Personas ¿está disponible el mejor personal? ¿está disponible el mejor personal? ¿el staff tiene las habilidades adecuadas? ¿el staff tiene las habilidades adecuadas? ¿hay suficiente personal disponible? ¿hay suficiente personal disponible? ¿existe el compromiso completo? ¿existe el compromiso completo? ¿habrá gente que trabaje parcialmente? ¿habrá gente que trabaje parcialmente? ¿el staff tiene las expectativas adecuadas? ¿el staff tiene las expectativas adecuadas? ¿el staff tiene el suficiente entrenamiento? ¿el staff tiene el suficiente entrenamiento? ¿podría la respuesta del staff ser baja? ¿podría la respuesta del staff ser baja? Cuestionamientos que deben ser resueltos:

54 Projecto: Software Incrustado para el Sistema XYZ Tipo de Riesgo: Riesgo de Calendarización Prioridad (1 bajo... 5 critico): 4 Factor de Riesgo: El término del proyecto dependerá de las pruebas, las cuales requieren de componentes de hardware que están bajo desarrollo. Los componentes de hardware pueden ser entregados tarde. Probabilidad: 60 % Impacto: El término de proyecto puede retrasarse por cada día que el hardware no esté disponible para uso de las pruebas de software Técnica de monitoreo: Revisiones de hitos calendarizados con el grupo de hardware Revisiones de hitos calendarizados con el grupo de hardware Plan de Contingencia: Modificación de la estrategia de pruebas para soportar el Modificación de la estrategia de pruebas para soportar el retraso usando simulación de software retraso usando simulación de software Recursos Estimados: 6 personas-mes a partir del 7/Mar/2002 Registro de la Información de Riesgo

55 4.7 Plan de Aseguramiento de la Calidad del Software

56 Aseguramiento de la Calidad del Software Software Quality Assurance Revisiones Técnias Formales SQA Planeación y Revisión de Pruebas Métrica Análisis y Reporteo Definición y Estándares de Proceso

57 Plan de Aseguramiento de Calidad El objetivo principal es establecer los lineamientos para implementar el Aseguramiento de Calidad de Software en el ciclo de vida para cada elemento del software. Proporcionar un método para asignar el Nivel de Calidad al software controlado por el plan.

58 Contenido de un Programa de Aseguramiento de Calidad de Software (IEEE Std. 730) 1. Propósito. Esta sección especifica la intención y alcance del Programa de Aseguramiento de Calidad. Establece la porción del Ciclo de Vida de Software cubierto por el programa para cada elemento de software. 2. Documentos de Referencia. Lista completa de documentos referenciados en el texto del Programa. 3. Administración. Describe la organización, tareas y responsabilidades. 4. Documentación. Se identifican los documentos para el desarrollo, verificación y validación, uso y mantenimiento de el software. Esto incluirá los criterios e identificación de las revisiones o auditorias. 5. Normas, prácticas, convenios y medidas. Aquí se identifican los reuqerimientos mandatorios, practicas recomendadasguias aceptadas y sistemas de medida que se emplearán por todos los relacionados con el proyecto, incluyendo a vendedores. 6. Revisiones y Auditorias. Aquí se definirán las revisiones y auditorias técnicas y administrativas que serán llevadas a cabo conforme a los procedimientos existentes. 7. Pruebas.

59 REQUISITOS DOCUMENTALES DE ACUERDO AL NIVEL DE CALIDAD Documentación NIVEL DE CALIDAD ABCD Clasificación del software RRRR Especificación de Requerimientos de Software RRRR Descripción de Diseño de Software RSSS Código Fuente y Documentación del Programa SSSS Plan de Verificación y Validación de Software RRSS Reporte de Verificación y Validación RRSS Documentación para el Usuario RRRR Plan de Administración de la Configuración RRRR R - Requerido S - Sugerido (Justificar sino se proporciona)

60 RETENCIÓN DE REGISTROS LUGARNIVEL DE CALIDAD ABCD Bóveda de Documentos XXXX Archivo Teleinformática y Planeación X TIEMPO Vida de la PlantaXX Vida de uso del software Aplicación XX

61 4.8 Administración de la Configuración del Software

62 ¿Cuáles son estos Cambios? datos otrosdocuementos código Prueba Plan de Proyecto Cambios en los requerimientos de negocio modelos de Sw Cambios en los requerimientos técnicos Cambios en los requerimientos del usuario

63 Configuración de Software programas documentos datos Las piezas

64 Proceso de Control de CambiosI requerimiento del cambio del usuario el desarrollador evalúa reporte de cambio es generado la autoridad de control de cambios decide el requerimiento es encolado para la acción el requerimiento de cambio es denegado. Se informa al Usuario la necesidad del cambios es reconocida Proceso de Control de CambiosII

65 Proceso de Control de Cambios-II asignar personal a los SCIs checar salida a los SCIs realizar los cambios revisar/auditar los cambios establecer una línea de fondo para pruebas Proceso de Control de CambiosIII

66 Proceso de Control de Cambios-III realizar actividades de SQA y pruebas promover SCI para la inclusión en siguientes liberaciones reconstruir la versión apropiada revisar/auditar los cambios incluir todos los cambios en la liberación checar la entrada de los SCIs cambiados

67 1.1. Introducción Propósito del Plan Alcance Definiciones Referencias Administración Organización Responsabilidades Procedimientos, Directivas y Políticas Actividades Identificación de la configuración Identificación de elementos de configuración Asignación de nombres a elementos de configuración Obtención de elementos de configuración Control de Configuración Solicitud de cambios Evaluación de cambios Aprobación/Rechazo de cambios Implementación de cambios Estado de la configuración Auditorias y revisiones Control de interfaces Control de Vendedores/Subcontratistas Planes, Programas Recursos PLAN DE ADMINISTRACION DE LA CONFIGURACION


Descargar ppt "PLAN DEL PROYECTO UNIDAD 4 Ing. Francisco Mauro Salgado."

Presentaciones similares


Anuncios Google