Gestión de Software Conferencia # 2 Niveles de PSP: PSP0.1.

Slides:



Advertisements
Presentaciones similares
Representación de Algoritmos
Advertisements

Modelo de procesos de software
PSP1 Lección 5: Estimaciones de tiempo y tamaño. Objetivos  ¿Qué es PSP? Alcance y necesidad.
UNIDAD III. PSP Objetivo: El alumno identificará el Proceso Personal de Software, para medir su desempeño.
Sistemas de calidad en el desarrollo de software.
Curso de inducción RUBRICA DE EVALUACIÓN Agosto 2016.
Lcda. Ingrid Graü Diseño de Sistemas 1. Lcda. Ingrid Graü Diseño de Sistemas 2.
UNIVERSIDAD REGIONAL AUTÓNOMA DE LOS ANDES UNIANDES IBARRA TEMA: METODOLOGÍA DE LA AUDITORÍA DE GESTIÓN DOCENTE: ING. WILMER ARIAS 1.
Diseño personal del Software. Una medida significativa en la mejora de calidad del software fue tomada con la esencia del proceso personal del software.
Reforzar los conocimientos sobre la planificación, control y mejora de la calidad de acuerdo con los requisitos de la Norma ISO 9001 en su Requisito 8.
InfoMedia Planificación. Resumen de tareas ● PLANIFICACIÓN: – Documentación: Asignación de tareas, recursos y fechas. – Revisión: Verificación de los.
ALCIBIADES VALLEJO BERRIO 2.1 INTRODUCCION 2- Requerimientos  Una de las fases más importantes en el proceso de construcción de software es la de adquisición,
FACULTAD DE INGENIERÍA CIVIL Y MECÀNICA CARRERA DE INGENIERÍA MÈCANICA EMPLEO DE NUEVAS TECNOLOGÍAS DE INFORMACIÓN Y COMUNICACIÓN (NTIC´s II) TEMA: PASOS.
TEMA: PSP (Personal Software Process) ANALISIS DE SISTEMAS I ING. EDGAR RAUL MOLINA INTEGRAMTES: HANNSEL E. CORDON AC JESSICA IDALMY KRESS FREDERIC HESTIB.
TUTORIA 1 Lógica para la Computación TUTORIA 1 Facultad de Ciencias Naturales y Matemáticas.
Pruebas de Funcionalidad de Software: Caja Negra y Caja Blanca Curso: Diseño de Sistemas 9no. Semestre.
Los requisitos para una planificación eficaz ya que es la tarea más importante en cuanto condiciona el hacer y el actuar. Los objetivos deben ser alcanzables.
Evaluación del desempeño
Metodología de Implementación de Sistemas ERP
Gestión de Software Conferencia # 1
Ingeniería de requisitos y
Grupo del Proceso de Cierre
Proceso de Software Personal
Riesgos y Control Informático
Diseño Instructivo: La Guía de aprendizaje Barranquilla 2007.
Grupo del Proceso de Cierre
GERENCIA DE PROYECTOS GERENCIA DEL ALCANCE Marzo 2012.
Gestión de Proyectos Informáticos
Modelo ADDIE Diseño Instruccional del uso de las TIC.
Ciclo de Vida del Software
Ingeniería de Software Conceptos básicos
GESTIÓN DEL TIEMPO PMBOK MSI Nancy Olivares Ruiz.
INSTITUTO TECNOÓGICO SUPERIOR DE LIBRES
SystemStar & Costar Presentado por: Andres Clavijo, Camilo Forero, Jhon Chacón y Brayan Valero.
6.6 Administración de defectos
Metodologías para Gestión de Proyectos
Taller Organización de Procedimientos Administrativos.
Factores que restringen el éxito de un proyecto.
Ciclo de Vida del Software
Planeación y Programación del Mantenimiento.
MODELO ADDIE Profesor: Msc. Juan Martínez Integrantes
resolución de problemas
I N S T R U C O A L D I S E Ñ O MODELO ADDIE.
Metodologías de Desarrollo de Software RUP – Proceso Racional Unificado Gilber BASILIO ROBLES I.E.S.T.P. “DANIEL ALCIDES CARRIÓN” Taller de Modelamiento.
METODOLOGIAS AGILES VS TRADICIONALES SCRUM - RUP FABIO ARNOBY BEJARANO Q. UNIREMINGTON BUGA (V) INGENIERIA DE SOFTWARE II SEPTIEMBRE 2018.
Cover Análisis y diseño de sistemas 7. Métricas en el proceso de software personal.
La planeación y la organización de los procesos técnicos.
PSP (Personal Software Process)
Modelo ADDIE Diseño Instruccional del uso de las TIC.
Taller de Estrategias de Aprendizaje Colaborativo
Identificación y Clasificación de los Componentes Reutilizables.
Identificación y Clasificación de los Componentes Reutilizables.
TSP (Team Software Process)
Proceso Personal para el Desarrollo de Software
Presentación de seguimiento del proyecto Equipo LSI 02
Hoja de recopilación y/o recopilación de datos
Modelo Instruccional Dick & Carey
Zegelipae.edu.pe. Aseguramiento de la Calidad Sesión 6.
Es el proceso de subdividir los entregables y el trabajo del proyecto en componentes más pequeños y más fáciles de manejar Se puede dar una visión estructurada.
Estimación 4 de software Tamaño Costo Duración Personas Mtro. Edgar Cossio Mayo 2016.
Nuestros canales de comunicación Gestión de la Calidad del Software Modelos y Estándares de Calidad en el Software.
IEEE Estándar para documentación de pruebas de software
DOS MANERAS DE OBTENER NUEVOS PRODUCTOS LA ADQUISICION: se refiere a comprar una empresa entera, una patente o una licencia para comercializar el producto.
Proyecto.
COCOMO (1) COCOMO Es un modelo sencillo. Cocomo puede ser aplicado a tres tipos de proyectos software. Esto nos da una impresión general del proyecto.
GC-F-004 V.01 CENTRO DE INDUSTRIA Y LA CONSTRUCCIÓN REGIONAL TOLIMA.
MODELO EN CASCADA Integrantes: Felipe Alemán Lester Blandón.
Luis Fernando Muñoz Pantoja Ingeniero de Sistemas Copyright 2019 Luis Fernando Muñoz Pantoja Ingeniero de Sistemas Derechos reservados UML.
Completa la suma en un minuto!
Transcripción de la presentación:

Gestión de Software Conferencia # 2 Niveles de PSP: PSP0.1

Contenido PSP0.1

Estructura incremental del PSP Registrar Tiempo Registrar Defectos Estándares de Defectos PSP 3 Desarrollo Cíclico PSP 0.1 Estándares de Codificación Métricas de Tamaños Propuesta de Mejora de Proceso PSP 1 Estimar Tamaños Reportar Pruebas PSP 1.1 Planificación de Tareas Planificación de Horarios PSP 2 Revisar Código Revisar Diseño PSP 2.1 Plantillas de Diseño

PSP0.1: Introducción al Tamaño del Software ¿Cómo medir tamaño? Líneas de Código (LOC) Medida concreta y simple de contar No incluyen comentarios ni líneas en blanco Hay que adoptar un estándar para contar LOC pues no existe ninguno en la industria

PSP0.1: Elementos nuevos Métricas de tamaño: LOC totales del programa LOC nuevas y modificadas Estándar de codificación Propuesta de Mejora del Proceso

PSP0.1: Nuevos elementos Formulario PIP: Process Improvement Proposal (Propuestas de Mejoras del Proceso) Es usado para registrar: cualquier problema, sugerencia de mejora lecciones aprendidas

PSP0.1: Nuevos elementos Estándar de Codificación: Ventajas de usar un Reduce los errores. Garantiza obtener un código claro y comprensible. Garantiza buena comunicación del equipo Facilita mantenimiento, reuso y revisión.

PSP0.1: Guiones y Formularios Proceso, Planificación, Desarrollo y Postmortem Formularios (6): Resumen Plan Proyecto PSP0.1, LOGT, LOGD, Estándar de Tipos de Defectos, Estándar de Codificación, PIP-Propuesta de Mejora de Proceso

PSP0.1 - Guión del Proceso Objetivo Guiar desarrollo de programas a nivel de módulo Criterio de Entrada Descripción del problema Formularios: LOGT, LOGD, Resumen Plan Proyecto PSP0.1 # Fase Descripción 1 Plan Obtener o producir requerimientos *Estimar LOC nuevas y cambiadas requeridas Estimar el tiempo de desarrollo requerido Entrar los datos de plan en Resumen Plan Proyecto Completar LOGT

PSP0.1 - Guión del Proceso 2 Des Diseñar el programa Implementar el diseño Compilar, ajustar y registrar defectos en LOGD Probar, ajustar y registrar defectos en LOGD Completar LOGT 3 Pos Completar Resumen Plan Proyecto con datos reales de tiempo, tamaño y defecto Criterio Salida Programa probado exhaustivamente Formulario Plan de Resumen Proyecto lleno con datos estimados y reales *Formulario PIP completo LOGD y LOGT completos

PSP0.1 - Guión de Planificación Objetivo Guiar la fase de planificación Criterio de entrada Descripción del problema Formularios: LOGT, Resumen Plan Proyecto PSP0.1 # Tarea Descripción 1 Requerimientos Obtener o producir requerimientos Asegurarse que son claros y no ambiguos Resolver cualquier interrogante

PSP0.1 - Guión de Planificación 2 Estimar Tiempo *Asegurar la mejor estimación de LOC nuevas y modificadas para el programa 3 Estimar recursos Asegurarse que se estimó el mejor tiempo para terminar el programa *Usar % A la Fecha para la mejora planificación de la fase siguiente Criterio Salida Requerimientos documentados Formulario Plan de Resumen Proyecto con tamaño del programa y tiempo de desarrollo estimados LOGT completo

PSP0.1 - Guión de Desarrollo Objetivo Guiar desarrollo de pequeños programas Criterio de entrada Requerimientos definidos Resumen Plan con tiempo de desarrollo y tamaño del programa estimado LOGT y LOGD Estándares Tipos Defectos, Codificación y Contar LOC # Fase Descripción 1 Diseño Revisar los requerimientos y elaborar un diseño acorde a ellos Registrar tiempo en LOGT

PSP0.1 - Guión de Desarrollo 2 Codificación Implementar el diseño siguiendo el estándar de codificación Registrar en LOGD cualquier defecto de requerimientos y diseño Registrar tiempo en LOGT 3 Compilación Compilar hasta eliminar errores Corregir todos los defectos encontrados Registrar defectos en LOGD

PSP0.1 - Guión de Desarrollo 4 Prueba Probar hasta que todo corra sin error Corregir todos los defectos encontrados Registrar defectos en LOGD Registrar tiempo en LOGT Criterio Salida Programa probado exhaustivamente y conforme al estándar de codificación LOGD completo LOGT completo

PSP0.1 - Guión del Postmortem Objetivo Guiar el Postmortem Criterio de entrada Requerimientos definidos y descripción de problemas Resumen Plan con tiempo de desarrollo y tamaño del programa planificado LOGT y LOGD completos Programa corrido y probado, conforme al estándar de codificación

PSP0.1 - Guión de Postmortem # Tarea Descripción 1 Defectos Inyectados Determine de los LOGD el # defectos inyectados en cada fase Registrar en Defectos inyectados en la columna Real del Resumen Plan Proyecto 2 Defectos Eliminados Determine de los LOGD el # defectos eliminados en cada fase Registrar en Defectos Eliminados en la columna Real del Resumen Plan Proyecto

PSP0.1 - Guión de Postmortem 3 Tamaño *Contar LOC del programa entero *Determinar LOC base, reusado, eliminado, modificado, adicionado, total y total de nuevos y modificados y nuevos reusados. *Registrarlos en Resumen Plan Proyecto 4 Tiempo Revisar si LOGT está completo Entrar el tiempo total gastado en cada fase del proyecto en Real de Resumen Plan Proyecto

PSP0.1 - Guión de Postmortem Criterio Salida Programa probado completamente conforme al estándar de codificación Resumen Plan Proyecto completo *Completar PIP describiendo problemas, sugerencias de mejoras y lecciones aprendidas LOGD y LOGT completos

Formulario Resumen Plan Proyecto PSP0.1 Estudiante: ______________________ Fecha: __________ Programa: _____________ # Programa: ___ Profesor: _________________ Lenguaje: _____________ Tamaño Prog (LOC) Plan Real A la fecha % A la fecha Base (B) _________ ________ Eliminadas (E) Modificadas (M) Adicionadas (A) Reusadas (R) Total Nuevas-Mod(N) Total LOC (T) Total Nuevas-Reus

Formulario Resumen Plan Proyecto PSP0.1 Tiempo en fase (min) Plan Real A la fecha % A la fecha Planificación ________ Diseño Codificación Compilación Prueba Postmortem Total _________

Formulario Resumen Plan Proyecto PSP0.1 Defectos inyectados Real A la fecha % A la fecha Planificación ________ Diseño Codificación Compilación Prueba Total Desarrollo Defectos eliminados Después Desarrollo

Instrucciones para Resumen Plan Proyecto Objetivo Contiene los datos estimados y reales del proyecto en un formato conveniente y legible Encabezamiento Entrar nombre, fecha, profesor, lenguaje utilizado, nombre y # programa Tiempo en Fases Bajo Plan, entrar el estimado inicial del total del tiempo de desarrollo Bajo real, entrar el tiempo real en minutos gastado en cada fase del desarrollo Bajo A la Fecha, entrar la suma del tiempo real con A la fecha anterior Bajo % A la Fecha, entrar % A la Fecha en cada fase

Instrucciones para Resumen Plan Proyecto Tamaño del Programa (LOC) Previo al desarrollo: Si está modificando o ampliando un programa existente, cuente LOC y registrarlas bajo Real en Base. Usando el mejor juicio estimar LOC nuevas y modificadas que se esperan en el desarrollo Después del desarrollo: Si LOC Base fue cambiado entrar el nuevo valor Medir el tamaño total del programa y registrarlo bajo Real en LOC Total Revisar el código fuente y con ayuda de A 3 determinar la cantidad real de LOC eliminadas (E), reusadas (R) o modificadas (M) Calcular LOC adicionadas como: A = T – B + E – R Calcular LOC totales nuevas y modificadas como: N = A – M

Instrucciones para Resumen Plan Proyecto Defectos inyectados Bajo Real, # defectos inyectados en cada fase Bajo A la Fecha, suma de # defectos reales inyectados en c/d fase con A la Fecha anterior Bajo % A la Fecha, entrar % defectos A la Fecha inyectados por fase Defectos eliminados Bajo Real, # defectos eliminados en c/d fase Bajo A la Fecha, suma # defectos reales eliminados en c/d fase con A la Fecha anterior Bajo % A la Fecha, % defectos A la Fecha eliminados por fase Después desarrollo, cualquier defecto encontrado en el uso, reuso o mantenimiento

Formulario PIP Estudiante: ______________________ Fecha: __________ Profesor: ___________________ # Programa: ___ Proceso: _________________ Elemento: ___________ # PIP Descripción del problema _________ ________________________________________________ Propuesta # PIP Descripción del problema Notas y comentarios ________________________________________________________________

Instrucciones para PIP Problema Describir el problema tan claro como sea posible Dificultad encontrada Impacto en el producto, proceso o en ti Numerar los problemas en c/d formulario en la columna izquierda Usar un número de secuencia conveniente Comenzar con 1 en cada formulario Propuesta Describir la mejora del proceso propuesta tan explícita como sea posible Cuando se pueda, referenciar el elemento específico del proceso Cuando sea apropiado referenciar # problema Si es importante, describir prioridad y por qué

Instrucciones para PIP Notas y Comentarios Para c/d proyecto, completar al menos un formulario PIP con comentarios sobre el proceso Registrar las lecciones aprendidas Anotar cualquier condición que se requiere para más tarde recordar porque el proceso trabajó mal o bien

Conclusiones LOC es una medida concreta y simple que permite determinar tamaño del programa La industria carece estándares para contar LOC es preciso definirlo para garantizar la calidad de las métricas El uso de estándar de codificación contribuye al reuso, mantenimiento y revisión del código, disminuye los defectos y garantiza un código claro y comprensible