Gestión de Software Conferencia # 1 Mejoras al Proceso de Desarrollo de Software. Introducción al PSP

Contenido Crisis del Software Proceso de Desarrollo Mejoras al Proceso de Desarrollo de Software Introducción al PSP PSP0

? ¿ Cuál es la situación de la industria de software? Pobre desempeño de las organizaciones de software 1 2 Incremento de la presión por mejorar su desempeño 3 Dificultades con las mejoras de los procesos de software

Crisis del Software Insuficiente Calidad del producto final Estimaciones de duración de proyectos y asignación de recursos inexactas Retrasos en la entrega de productos terminados Están fuera de control los costos de desarrollo y mantenimiento de productos Escasez de personal calificado en un mercado laboral de alta demanda Tendencia al crecimiento del volumen y complejidad de los productos

? ¿Cómo enfrentarla? Las organizaciones requieren: Desarrollar o adquirir una disciplina en el desarrollo del software. 1 2 Controlar que los ingenieros usen de forma consistente los nuevos métodos.

¿ Por qué fallan los Proyectos de Software? NO ¿Software? ¿ Tecnología?

¿ Por qué fallan los Proyectos de Software? Planificación Irreal 1 2 Mala Calidad del Trabajo 3 Personal Inapropiado 4 No Controlar los Cambios

“Es para hoy y con costo 0” 1 Planificación Irreal Los ingenieros no son capaces de enfrentar un plan porque: • NO están entrenados para usar métodos de planificación. • Frecuentemente, las estimaciones NO se basan en datos reales. “Es para hoy y con costo 0”

Planificación Irreal Sin un plan creíble, ¿Qué hacer? 1 Planificación Irreal CONSECUENCIAS Los equipos no incluyen su trabajo en el plan. Los planes no reflejan el trabajo a desarrollar. Se torna difícil o subjetivo, seguir el progreso. Bajo presión, los equipos realizan un trabajo de pobre calidad. Sin un plan creíble, ¿Qué hacer? los Directivos establecen un Plan Arbitrario

Pobre Calidad del Trabajo 2 Pobre Calidad del Trabajo CAUSAS Prácticas pobres de ingeniería Carencia de métricas de calidad Inadecuado entrenamiento en calidad Decisiones de los directivos guiadas por una planificación irreal

Pobre Calidad del Trabajo 2 Pobre Calidad del Trabajo CONSECUENCIAS Tiempos de pruebas impredecibles Productos con muchos defectos Demoras en la aceptación de los usuarios Extensa garantía del servicio y reparaciones “Una pobre calidad afecta la planificación y torna ineficente el proceso de prueba”

Personal Inapropiado 3 Demora del personal Escaso personal Miembros del equipo a tiempo parcial Personal con conocimientos inapropiados El trabajo se demora o descuida Trabajo ineficiente Sufre la moral del equipo Con independencia del plan, los proyectos deben comenzar en tiempo y con todo el personal. PROBLEMAS COMUNES CONSECUENCIAS

Cambios NO controlados 4 Cambios NO controlados Siempre ocurren cambios en los requerimientos. Los planes se basan en el alcance del trabajo conocido. Los cambios siempre requieren más trabajo. Sin planes detallados, los equipos no pueden estimar el efecto o magnitud de los cambios. Si los equipos no controlan cada cambio, se pierde gradualmente el control del plan del proyecto HECHOS a RECORDAR:

Requerimientos Críticos Crear planes realistas basados en datos Usar prácticas de calidad de software Lograr equipos comprometidos Alcanzar equipos efectivos en el manejo de su trabajo

Planes Realistas Deben reflejar: cuál es el trabajo cómo se hace (cuándo y quién) 1 2 Deben desarrollarlos: quienes ejecutan el trabajo basados en Datos Históricos

Equipos Comprometidos su trabajo es importante el plan es factible poseen los conocimientos y los recursos necesarios Para comprometer un equipo, este debe convencerse que: “Solo los equipos que elaboran su propio plan, se comprometen con este”

Prácticas de Calidad planificarla medirla seguirla La calidad hay que: Los equipos requieren un proceso que: planificarla medirla seguirla “Hablar de calidad sin números es sólo hablar” promueva la eliminación temprana de defectos dirija la calidad a lo largo del proceso La calidad hay que:

Dirección efectiva de los equipos Enfatizar: la importancia del trabajo en equipo propiciarle los recursos necesarios 1 Asegurar que los equipos conozcan cómo: hacer planes con datos dirigir y dar seguimiento al trabajo planificar, medir y dirigir la calidad 2 Seguir y monitorear los equipos para: dar a conocer y reconocer el buen trabajo estimular el uso proactivo de los datos 3

Factores de Éxito • Implicar a los Usuarios DESARROLLO de PROYECTOS de SOFTWARE • Implicar a los Usuarios • Ofrecer Soporte a los Ejecutivos • Definir los Requerimientos de forma clara • Realizar una Planificación Adecuada • Crear Expectativas Realistas

Factores de Éxito • Definir Proyectos Pequeños DESARROLLO de PROYECTOS de SOFTWARE • Definir Proyectos Pequeños • Personal Competente y concentrado en su trabajo • Lograr Sentido de Pertenencia • Poseer una Visión y Objetivos claros Trabajar duro

Mejorando su Proceso de Desarrollo de Software ¿Cómo enfrenta la empresa tales necesidades críticas? Mejorando su Proceso de Desarrollo de Software

Proceso de Desarrollo de Software PIEDRAS ANGULARES TECNOLOGÍA PROCESO PERSONAL Proceso de Software

Proceso de Desarrollo de Software PIEDRAS ANGULARES Sin PERSONAL competente y experimentado, imposible crear productos competitivos Las TECNOLOGÍAS que sustentan el producto y las Herramientas utilizadas en su desarrollo PROCESO: utilizar el conocimiento del personal y la tecnología en forma eficiente para lograr productos con calidad, que satisfagan al cliente, con costos y en tiempos aceptables

Importancia del Proceso Demanda de producción de software Crisis en la disponibilidad de ingenieros de software Caros y escasos Recursos Humanos Uso productivo y eficiente PROCESO PERSONAL Costo herramientas para producir software (PC y SW de desarrollo) Complejidad de la tecnología a incorporar en los productos (costo de investigación y desarrollo, etc) TECNOLOGÍA

Mejoramiento continuo ¿Qué significa mejorar el Proceso? ? Reingeniería de procesos (altos costos y riesgos) X Interés genuino de ingenieros y gerentes por crear procesos maduros, que garanticen un buen uso de los talentos y recursos asignados. Metodologías prácticas basadas en la experiencia colectiva de la industria de software internacional. Mejoramiento continuo

Mejoras del Proceso de Software Nivel ORGANIZACIONAL Capacidades de Dirección Nivel del EQUIPO Ejecución del Equipo Nivel del INDIVIDUO Conocimientos y Disciplina Personal

Mejoras del Proceso de Software CMM, ISO Capacidades de Dirección TSP, RUP Ejecución del Equipo PSP Conocimientos y la Disciplina Personal

Proceso de Desarrollo de Software CMM CMMi, TSP, PSP Watts Humphrey, Software Engineering Institute (SEI) in Pittsburgh, Pennsylvania. ISO International Standars Organization, Ginebra, Suiza. RUP Ivar Jacobson, James Rumbaught, Grady Booch

Taller de Sistemas Informáticos Proceso de Software Personal (PSP) Bibliografía Humphrey, W. “A discipline for software engineering”, 1995. Humphrey, W. “Introduction to the Personal Software Process”, 1998.

Contenido Introducción al proceso personal PSP0 – línea base del proceso personal

? ¿Son disciplinados los ingenieros de software?, ¿por qué? 1- La ingeniería de software no tiene tradición de ejecución personal disciplinada 2- El proceso de software no le impone una disciplina natural a los ingenieros, estos deben auto-disciplinarse. Hardware diseña para producir a gran escala. Los ingenieros revisan y aceptan el diseño antes de comprometerse. El diseño de software no implica producción a gran escala por lo que no ha exigido revisión minuciosa.

? ¿Son disciplinados los ingenieros de software?, ¿por qué? 3-Regularmente el trabajo disciplinado en cualquier campo requiere estándares altos y soporte competente. Por ello, los profesionales del deporte y el arte tienen representantes y entrenadores. La industria de software carece de una adecuada formación para el desempeño de los roles y pocos conocen como ser entrenadores efectivos.

¿Qué implica disciplina en el ? ¿Qué implica disciplina en el trabajo individual? Usar un proceso personal definido Planificar cada tarea Registrar tiempos, tamaños y defectos Seguir la ejecución del proceso Medir y manejar la calidad del producto

¿Cómo cambiar esta actitud? Los ingenieros deben: Comprender la necesidad de utilizar métodos disciplinados, Conocer cómo aplicarlos Constatar en la práctica y por ellos mismos que el empleo de los métodos realmente mejora su trabajo.

? PSP: ¿qué, quién, dónde, cuándo? PSP: Personal Software Process Watts Humphrey Software Engineering Institute (SEI), en Pittsburgh, Pennsylvania. 1995

Principios de Diseño Principios de Planificación Principios de Mejora de Procesos PSP Cada ingeniero es diferente y para ser más eficiente, debe planificar su trabajo basándose en datos personales. Para mejorar auténticamente su trabajo, los ingenieros deben usar procesos personales bien definidos y cuantificados.

Principios de Diseño Para obtener productos de calidad, el ingeniero debe asumir la responsabilidad personal de la calidad de sus productos. Cuanto antes se detecten y corrijan los defectos menos esfuerzo será necesario. Es más efectivo evitar los defectos que detectarlos y corregirlos. Trabajar bien es siempre la forma más rápida y económica de trabajar.

Paradigma del PSP Está basado en estos principios: Los estudiantes establecen metas de mejora de proceso personal Definen los métodos que usarán Planifican su trabajo Miden su trabajo Analizan los resultados A partir del análisis ajustan sus métodos y mejoran las métricas

? ¿Cuál es la estrategia de PSP para cambiar la actitud de los ingenieros? Comenzar con el proceso actual Gradualmente introducir nuevos métodos Practicar estos métodos en programas de tamaño de módulos Los ingenieros comprueban por ellos mismo como estos métodos los ayudan

? ¿Cómo enseñar PSP, cuáles son los prerrequisitos? En formato de curso Prerrequisitos: Dominar un lenguaje de programación Comprensión básica del diseño de programación Dominio de la matemática Conocimientos adicionales : Estadísticas Gestión de proyecto Métodos formales

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

Reporte resumen de datos del Proceso y Proyecto Flujo del Proceso Proceso PSP Desarrollo Planificación Diseño Revisión del diseño Codificación Revisión del código Compilación Prueba Requerimientos Guiones del proceso Producto terminado PostMortem Logs de Defectos y Tiempos Resumen Plan Proyecto Reporte resumen de datos del Proceso y Proyecto Desarrollo

Elementos Claves: Formularios y Guiones Guiones: guían a los ingenieros a lo largo del proceso. Existen guiones para: procesos y fases de cada nivel incremental. Cada guión consta de 4 partes: Objetivo Entradas requeridas Fases del proceso Criterio de salida Formularios: se llenan a medida que transcurre el proceso. Los más importantes son: LOGT y LOGD.

Estructura incremental PSP0: proceso línea base PSP1: proceso de planificación personal PSP2: proceso personal de administración de la calidad PSP3: proceso cíclico personal

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: Línea base del proceso personal Toma el proceso de software existente Lo mide y registra tiempos y defectos. Sus resultados son referencias para la mejora del proceso Establece una línea base que incluye métricas y reportes, lo que provee bases consistentes para medir el progreso y definir qué mejorar.

PSP0: Guiones - Formularios Proceso, Planificación, Desarrollo y Postmortem Formularios (4): Resumen Plan Proyecto, LOGT-Registro de Tiempo, LOGD-Registro de Defectos, Estándar de Tipos de Defectos

PSP0 - Guión del Proceso Objetivo Guiar en el desarrollo de programas a nivel de módulo Criterio de Entrada Descripción del problema Formularios: LOGT, LOGD, Resumen Plan Proyecto # Fase Descripción 1 Plan Obtener requerimientos Estimar el tiempo de desarrollo Entrar los datos en el plan usando el formulario Resumen Plan Proyecto

PSP0 - Guión del Proceso 2 Des Diseñar el programa Implementar el diseño Compilar, ajustar y registrar defectos en LOGD Completar LOGT 3 Pos Completar el formulario 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 LOGD y LOGT completos

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

PSP0 - Guión de Planificación 2 Estimar recursos Asegurarse que se estimó el mejor tiempo para terminar el programa Criterio Salida Requerimientos documentados Formulario Plan de Resumen Proyecto con tiempo de desarrollo estimado LOGT completo

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

PSP0 - Guión de Desarrollo 2 Codificación Implementar el diseño Registrar en LOGD cualquier defecto de requerimientos y diseño Registrar tiempo en LOGT 3 Compilación Compilar hasta que no existan errores Corregir todos los defectos encontrados Registrar defectos en LOGD

PSP0 - 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 LOGD completo LOGT completo

PSP0 - Guión del Postmortem Objetivo Guiar el postmortem Criterio de entrada Requerimientos definidos y descripción de problemas Resumen Plan con tiempo planificado LOGT y LOGD completos Programa corrido y probado # 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

PSP0 - Guión de Postmortem 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 3 Tiempo Revisar si LOGT está completo Entrar el tiempo total gastado en cada fase del proyecto en Real de Resumen Plan Proyecto Criterio Salida Programa probado completamente Resumen Plan Proyecto completo LOGD y LOGT completos

Formulario LOGT Estudiante: _____________________________ Fecha: __________ Profesor: _____________ # Programa: ____ Fecha Hora Inicio Fin Tiempo Interrupción Delta Tiempo Fase Comentarios

Instrucciones para llenar LOGT Objetivo Registrar el tiempo gastado en cada fase del proyecto Usar estos datos para completar el Resumen Plan Proyecto General Registrar todos los tiempos gastados en el proyecto Registrar el tiempo en minutos Ser lo más exacto posible Si requiere espacio adicional usar otra copia del formulario Encabezamiento Entrar nombre, fecha, profesor y # programa Fecha Fecha en que se registra el tiempo

Instrucciones para llenar LOGT Inicio Tiempo en que comienza a trabajar en la tarea Fin Tiempo en que deja de trabajar en la tarea Tiempo Interrupción Cualquier interrupción que ocurre durante la tarea y la razón de esta. Ej. Teléfono, baño. Si son varias entrar el tiempo total Delta tiempo Tiempo real gastado en la tarea (Fin – Inicio) – Interrupción Fase Entrar el nombre o sigla de la fase o paso en que este trabajando Comentarios Cualquier comentario interesante

Tipos de Defectos Defecto: error que fue cometido en una fase y que puede ser encontrado en esa o en fases siguientes. Tipo Defecto Descripción 10 Documentación Pobres comentarios 20 Sintaxis Errores tipográficos, puntuación, tipos, formato de instrucciones 30 Construcción Inapropiado control de versiones, Manejo de cambios mezcla módulos, bibliotecas

Tipos de Defectos 40 Declaración-Asignación Descripción 40 Declaración-Asignación Variables no declaradas, duplicadas, alcance, fuera de límites 50 Interfaces Llamadas a procedimientos, funciones y referencias, E/S, formatos de usuario 60 Chequeos Chequeos inadecuados que muestran mensajes erróneos 70 Datos Los datos reales deben tener adecuada estructura y contenido 80 Función Defectos de la función por lógica, punteros, lazos, recursión, cálculo

Tipos de Defectos 90 Sistema Descripción 90 Sistema Restricciones en la configuración del sistema (tiempo) y memoria. Son relativas a la máquina 100 Ambiente Problemas con el setup del ambiente de desarrollo: diseño, compilación, prueba y otros problemas de soporte al sistema

Formulario LOGD Tipos Defectos 10 Documentación 60 Chequeo 20 Sintaxis 70 Datos 30 Construcción 80 Función 40 Asignación 90 Sistema 50 Interfaces 100 Ambiente Estudiante: _____________________________ Fecha: __________ Profesor: _____________ # Programa: ____ Fecha Número Tipo Inyectado Eliminado Tiempo Corrección Defecto Corregido Descripción: ___________________________________________________________ Fecha Número Tipo Inyectado Eliminado Tiempo Corrección Defecto Corregido Descripción: ___________________________________________________________

Instrucciones para llenar LOGD Objetivo Registrar cada defecto cuando lo encuentre y lo corrija Usar estos datos para completar el Resumen Plan Proyecto General Registrar en LOGD todos los defectos encontrados en revisión, compilación y prueba Registrar c/d defecto por separado y completo Si requiere espacio adicional usar otro formulario Encabezamiento Entrar nombre, fecha, profesor y # programa Fecha Fecha en que el defecto fue encontrado Número Por cada programa debe ser un consecutivo comenzando por 1 ó 001

Instrucciones para llenar LOGD Tipo seleccione el mejor de los 10 tipos estándares Inyectado fase en la cual el defecto fue inyectado Eliminado fase en la cual el defecto fue eliminado, generalmente donde es encontrado Tiempo corrección tiempo en corregir el defecto Defecto corregido Si se inyectó este defecto mientras se corregía otro, registrar el número del defecto corregido inadecuadamente Sino identifica el número del defecto entrar X Descripción # línea y breve descripción del defecto

Formulario Resumen Plan Proyecto Estudiante: ______________________ Fecha: __________ Programa: _____________ # Programa: ___ Profesor: _________________ Lenguaje: _____________ 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 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 Debajo de 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 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

Trabajo Independiente Ejercicios Estudiar el proceso PSP0 para asimilar en el Laboratorio1 la herramienta PPD

Conclusiones mejor estructurado más predecible uso de estándares y mejores prácticas registro de datos para analizar y evaluar el proceso INGENIERIA SOFTWARE 1 Incremento del interés y la actividad en el desarrollo y mejoramiento del proceso de software

"Una cadena es tan fuerte como su eslabón más débil” Conclusiones 2 El Proceso de Desarrollo de Software debe proveer soporte a todos los niveles: individual, de equipos y organizacional Poseer Procesos Definidos asegura que el trabajo pueda ejecutarse con un grado bastante alto de calidad. "Una cadena es tan fuerte como su eslabón más débil” 3 4 Dar soporte a los individuos que participan en un proyecto, mejora sus rutinas de trabajo.