SCOPE AND SCHEDULE MANAGEMENT Carlos Mario Zapata J. 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software 5.1 PLAN SCOPE MANAGEMENT 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software 4/15/2017 Gestión de Proyectos de Software

ESTRUCTURA DEL PLAN DE GESTIÓN DEL ALCANCE Nombre del proyecto Autor y fecha Sección 1: Describa cómo se gestionará el alcance del proyecto Sección 2: Evalúe la estabilidad esperada del alcance del proyecto (qué tan probable es el cambio, cuán frecuentemente y por cuánto) Sección 3: ¿Cómo se identificarán y clasificarán los cambios de alcance? Sección 4: Describa cómo los cambios de alcance del proyecto se integrarán al proyecto. Sección 5: Consideraciones finales 4/15/2017 Gestión de Proyectos de Software

ESTRUCTURA DEL PLAN DE GESTIÓN DE LOS REQUISITOS Nombre del proyecto Autor y fecha Sección 1: Introducción: Propósito Alcance Definiciones, acrónimos y abreviaturas Referencias Generalidades Sección 2: Gestión de Requisitos Organización, responsabilidades e interfaces Herramientas, entorno e infraestructura 4/15/2017 Gestión de Proyectos de Software

ESTRUCTURA DEL PLAN DE GESTIÓN DE LOS REQUISITOS Sección 3: Programa de gestión de requisitos Identificación de requisitos Rastreabilidad (Criterios por ítem de rastreabilidad) Atributos (Criterios por ítem de rastreabilidad) Reportes y medidas Gestión de cambios de requisitos Proceso y aprobación de solicitudes de cambio Tablero de control de cambios Bases del proyecto Flujos de trabajo y actividades Sección 4: Hitos Sección 5: Entrenamiento y Recursos 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software 5.2 COLLECT REQUIREMENTS 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software 5.3 DEFINE SCOPE 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software 4/15/2017 Gestión de Proyectos de Software

DECLARACIÓN DE ALCANCE DEL PROYECTO Descripción del alcance del producto Criterios de aceptación (para los entregables) Entregables Exclusiones del proyecto Restricciones Suposiciones 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software 5.4 CREATE WBS 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software WBS-PAQUETES 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software WBS-FASES 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software WBS-ENTREGABLES 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software 4/15/2017 Gestión de Proyectos de Software

6.1 PLAN SCHEDULE MANAGEMENT 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software 4/15/2017 Gestión de Proyectos de Software

SCHEDULE MANAGEMENT PLAN INTRODUCTION Purpose Scope PARTICIPANTS Roles and responsibilities SCHEDULE DEVELOPMENT PROCESS Create high-level milestone schedule Create work breakdown structure (WBS) Project WBS versus Contract WBS WBS Element Numbering Methodology WBS Dictionary 4/15/2017 Gestión de Proyectos de Software

SCHEDULE MANAGEMENT PLAN SCHEDULE DEVELOPMENT PROCESS Create resource breakdown structure Create responsibility assignment matrix (RAM) Create and integrate schedule Date, Sequence, and Link Activities Estimate duration Duration rules Resource planning rules Validate schedule Integrate schedules Baseline Schedule SCHEDULING DEVELOPMENT TOOL Scheduling development tool description Scheduling tool usage 4/15/2017 Gestión de Proyectos de Software

SCHEDULE MANAGEMENT PLAN SCHEDULE INPUT MONITORING Compare schedule status to time status reports Monitor prime contractor’s schedule SCHEDULE MANAGEMENT AND CONTROL Schedule control techniques Schedule control products Schedule change request process Update schedule Establish new schedule baseline Archive schedule change support materials 4/15/2017 Gestión de Proyectos de Software

SCHEDULE MANAGEMENT PLAN SCHEDULE STATUS REPORTING Monthly project reports Monthly metrics and trend analysis Schedule oversight reports SCHEDULE CLOSING Closing reports Archive schedule data and tools APPENDIX Glossary & Acronyms 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software 6.2 DEFINE ACTIVITIES 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software 6.3 SEQUENCE ACTIVITIES 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software 4/15/2017 Gestión de Proyectos de Software

DIAGRAMA EN RED: PERT-CPM 4/15/2017 Gestión de Proyectos de Software

6.4 ESTIMATE ACTIVITY RESOURCES 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software 4/15/2017 Gestión de Proyectos de Software

6.5 ESTIMATE ACTIVITY DURATIONS 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software ESTIMACIÓN DEL TAMAÑO Líneas de código fuente (Source Lines of Code – SLOC). Altamente intuitivo. Depende de las preferencias del programador: for (i=0; i<100; ++i) printf(“Hola Mundo!"); /* cien veces la misma frase */ 1 línea física, 2 líneas lógicas, 1 línea de comentarios. for (i=0; i<100; ++i) { printf(“Hola Mundo!") } /* cien veces la misma frase */ 4 líneas físicas, 2 líneas lógicas, 1 línea de comentarios. Cuál de las dos sería más conveniente? Los generadores automáticos afectan los resultados. 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software ESTIMACIÓN DEL TAMAÑO Puntos de Función (Albrecht): Las SLOC pueden ser relativas al programador. La funcionalidad pertenece al programa mismo. Se puede estimar la funcionalidad en etapas tempranas. A partir de FP se pueden estimar SLOC, esfuerzo, costo, calidad, documentación, etc. Se asocia con: Archivos lógicos internos (tablas en bases de datos), Archivos de interfaz externa (archivos de E/S), Entradas externas (pantallas de captura), Salidas externas (reportes) y Consultas externas (funciones y mensajes). 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software ESTIMACIÓN DEL TAMAÑO 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software ESTIMACIÓN DEL TAMAÑO 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software ESTIMACIÓN DEL TAMAÑO Características de Complejidad Puntos Función Requiere copias de Seguridad y recuperación fiables? Se requiere comunicación de datos? Existen funciones de procesamiento distribuido? Es crítico el rendimiento? Se ejecutará el sistema en un entorno operativo existente y fuertemente utilizado? Requiere el sistema entrada de datos interactiva? Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre múltiples pantallas u operaciones? 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software ESTIMACIÓN DEL TAMAÑO Características de Complejidad Puntos Función Se utilizan los archivos maestros de forma interactiva? Son complejas las entradas, las salidas, los archivos o las peticiones? Es complejo el procesamiento interno? Se diseñó el código para ser reutilizable? Se incluyen en el diseño la conversión y la instalación? Se diseñó el sistema para soportar múltiples instalaciones en diferentes organizaciones? Se diseñó para facilitar los cambios y usarlo fácilmente? 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software ESTIMACIÓN DEL TAMAÑO Correlación entre FP y SLOC: Depende del lenguaje de programación. Es un valor también estimado empíricamente. Lenguaje SLOC/FP C++ 53 Cobol 107 Delphi 118 HTML 14 Java 46 VB 24 SQL 13 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software ESTIMACIÓN DEL TAMAÑO Puntos de Objeto (Banker, Kauffman, Wright, Zweig): No se relacionan con POO ni ADOO. Usa conteos de pantallas, reportes y componentes 3GL, clasificados como simples, medianos y difíciles. Toma en cuenta la reutilización. Los puntos de objeto se afectan en el porcentaje de reutilización para obtener NOP. 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software ESTIMACIÓN DEL TAMAÑO Puntos de Objeto: 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software ESTIMACIÓN DEL TAMAÑO Puntos de Casos de Uso (Karner): Los Puntos de función son demasiado “funcionales”. El paradigma orientado a objetos es ahora lo más avanzado en desarrollo de software. Las aplicaciones actuales son difíciles de estimar en términos “funcionales”, puesto que su estructura es diferente. El diagrama de casos de uso es uno de los principales diagramas de UML para expresar la funcionalidad del software futuro. 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software ESTIMACIÓN DEL TAMAÑO Puntos de Casos de Uso Unadjusted Actor Weight Clasificación Test de litmus para reconocer clasificaciones Valor/Factor Actores simples Son aquellos que se comunican con el sistema a través de APIs. 1 Actores Promedio Se reconocen si se rigen por las siguientes propiedades: Actores que están interactuando el sistema a través de algún protocolo (http, Ftp o problablemente algún protocolo definido por el interesado. 2 Actores Complejos Aquellos que interactúan normalmente a través de Interfaces Gráficas de Usuario (Graphic User Interface o GUI). 3 Unadjusted Use Case Weight Tipo de Caso de Uso Test de litmus para decidir la Clasificación Valor/Factor Simple Mayor o igual a tres transacciones 5 Promedio Entre 4 y 7 transacciones 10 Complejo Mayor de 7 transacciones 15 Total UUCP = Total UAW + Total UUCW :Unadjusted Use Case Points 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software ESTIMACIÓN DEL TAMAÑO Puntos de Casos de Uso: Factor de Complejidad Técnica TCF = 0.6 + (0.01 * Tfactor) Cod Factor Técnico Peso Descripción t1 Sistema Distribuido 2 La arquitectura es centralizada o distribuida? t2 Tiempo de Respuesta 1 El tiempo de respuesta es un criterio importante? El interesado necesita que el sistema corra rápido? t3 Eficiencia del usuario final Cómo es la eficiencia del usuario final? t4 Procesamiento interno complejo El proceso de negocios es muy complejo? Por ejemplo: cuentas complicadas, cierres, seguimiento de inventario, cálculo difícil de impuestos, etc. t5 Código reutilizable Se intenta mantener la reusabilidad alta? Esto incrementará la complejidad del diseño. t6 Facilidad de instalación 0.5 El interesado está buscando una facilidad de instalación? Por defecto, se colocan muchos instaladores que crean los paquetes. Sin embargo, el interesado está buscando una instalación que probablemente dependa de módulos inteligentes. Uno de los interesados tiene como requisito una instalación personalizada. Si el requisito es tal que cuando haya una nueva versión deba auto-instalarse. Estos factores contarán cuando se asigne valor a este factor. t7 Uso fácil Es la amigabilidad un factor importante para el usuario? t8 Portabilidad El interesado está buscando implementación en diferentes plataformas? t9 Fácil de cambiar El interesado está buscando personalización en el futuro? Esto también incrementa la complejidad del diseño de la arquitectura y, en consecuencia, este factor. t10 Concurrente El interesado está buscando muchos usuarios simultáneos con apoyo automático? Este valor incrementa la complejidad de la arquitectura y, en consecuencia, este factor. t11 Objetivos de seguridad El interesado quiere alta seguridad o encriptación de la información? t12 Acceso directo a terceras partes El proyecto depende del uso de controles por terceras partes? La comprensión de los controles de terceras partes y el estudio de los pros y contras requiere mucho esfuerzo. Así, este factor se debe asignar en consecuencia. t13 Facilidades de entrenamiento de usuarios. Será tan complejo el software desde la perspectiva del usuario que requiera entrenamiento? Este factor debería variar en consecuencia. 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software ESTIMACIÓN DEL TAMAÑO Puntos de Casos de Uso Cod Factor Ambiental Peso Descripción e1 Familiaridad con el proyecto 1.5 Toda la gente que trabaja en el proyecto se familiarizó con el dominio y factores técnicos del proyecto? Sino, probablemente se gastará mucho tiempo en la explicación de los Know-How. e2 Experiencia en la aplicación. 0.5 Qué tanta experiencia en la aplicación tiene el equipo de desarrollo? e3 Experiencia orientada a objetos 1 Los documentos de los casos de uso son entradas para el diseño orientado a objetos. Es importante que el equipo humano del proyecto tenga conocimientos básicos de orientación a objetos. e4 Capacidad del analista líder. Cómo está conduciendo el proyecto el analista? Tiene suficiente conocimiento del dominio? e5 Motivación Están los programadores motivados de trabajar en el proyecto? La inestabilidad en el proyecto puede conducir a la gente a dejar el código fuente a medio camino. Este factor se puede hacer acorde a la realidad de la industria del software; por ejemplo, si el mercado del software es bueno se puede colocar el máximo puntaje. A mejor mercado hay más trabajos y más programadores aparecerán. e6 Requisitos estables 2 Tiene claridad el interesado en lo que quiere? Las expectativas del interesado son el factor más importante en la estabilidad de los requisitos. Si la naturaleza del interesado es altamente cambiante, coloque este valor al máximo. e7 Personal de tiempo parcial -1 Existe personal de tiempo parcial en el proyecto como consultores, etc.? e8 Lenguaje de programación difícil Qué tan complejo es el lenguaje? Vb6, c++, c, etc. EF = 1.4 + (-0.03 * Efactor) : Environmental Factor AUCP = UUCP * TCF * EF: Adjusted Use Case Points ESFUERZO = AUCP * Hombre/hora/AUCP 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software ESTIMACIÓN DEL TAMAÑO Puntos de Clases (Costagliola, Ferrucci, Tortora, Vitiello): Otra técnica de orientación objetual. Similar a FP y UCP. Utiliza el número de operaciones externas, el número de operaciones locales y el número de servicios solicitados para evaluar la complejidad de las clases. Toma también en cuenta la complejidad técnica. 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software ESTIMACIÓN DEL TAMAÑO Puntos de Clases: 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software ESTIMACIÓN DEL TAMAÑO Puntos de Clases: 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software ESTIMACIÓN DEL TAMAÑO Puntos de Clases: 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software ESTIMACIÓN DEL TAMAÑO Puntos de Clases: TCF=0,55 + (0,01*TDI); CP=TUCP*TCF 4/15/2017 Gestión de Proyectos de Software

ESTIMACIÓN DEL ESFUERZO No es suficiente con conocer de manera anticipada el tamaño de una aplicación. Para asignar los recursos al proyecto, se requiere conocer de antemano qué esfuerzo requerirá el desarrollo. Se pueden emplear los resultados de la estimación del esfuerzo, siempre que se cuente con la correlación respectiva. Se llevan los FP, OP, UCP o CP a SLOC 4/15/2017 Gestión de Proyectos de Software

ESTIMACIÓN DEL ESFUERZO La unidad de medida se suele denominar “persona-mes” (Brooks). Se debe tomar en consideración la complejidad del proyecto, así: Proyectos pequeños: ESFUERZO=(SLOC/1000)*PF Proyectos grandes: ESFUERZO=(SLOC/1000)^CF*PF CF es el factor de complejidad y PF el factor de productividad o esfuerzo por cada punto de función. 4/15/2017 Gestión de Proyectos de Software

ESTIMACIÓN DEL ESFUERZO 4/15/2017 Gestión de Proyectos de Software

ESTIMACIÓN DEL ESFUERZO De dónde salen los factores? Modelos empíricos de estimación: E=A+B(ev)C E: esfuerzo en personas-mes, A, B, C constantes empíricas, ev variable de estimación (SLOC o FP). En general, se deben calibrar para las necesidades locales. Los más famosos: COCOMO y la Ecuación del Software. 4/15/2017 Gestión de Proyectos de Software

ESTIMACIÓN DEL ESFUERZO Constructive Cost Model – CoCoMo (Boehm): Se usa de tres formas: Básica: Se calcula el esfuerzo con base en el tamaño y el modo de desarrollo. Intermedia: Se afecta el esfuerzo calculado de forma básica con factores de costo. Avanzada: Se separa el proyecto en etapas y se hace el cálculo de forma intermedia para cada etapa. 4/15/2017 Gestión de Proyectos de Software

ESTIMACIÓN DEL ESFUERZO CoCoMo: Modos de desarrollo: Organic: pequeños equipos de desarrollo, software a la medida, software pequeño y requisitos flexibles. E=2.4 (SLOC/1000)^1.05 Embedded: Productos que deben operar con grandes restricciones y con cambios costosos para el sistema. E=3.0 (SLOC/1000)^1.12 Semi-detached: Combina elementos o tiene características de ambos. E=3.6 (SLOC/1000)^1.20 4/15/2017 Gestión de Proyectos de Software

ESTIMACIÓN DEL ESFUERZO CoCoMo: Factores de Costo 4/15/2017 Gestión de Proyectos de Software

ESTIMACIÓN DEL ESFUERZO CoCoMo: E=Enom*(P Factores de Costo) Cálculo del tiempo: Organic: 2.5*E^2.38 Embedded: 2.5*E^2.32 Semi-detached: 2.5*E^2.35 Existen otras versiones: CoCoMo81, CoCoMoII y están en constante desarrollo. 4/15/2017 Gestión de Proyectos de Software

ESTIMACIÓN DEL ESFUERZO La ecuación del software E=[(SLOC/1000)xB0.333/P]3x(1/T4) E: esfuerzo en personas-mes o personas-año T: duración del proyecto en meses o años. B: “Factor especial de destrezas” P: “Parámetro de productividad” 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software 6.6 DEVELOP SCHEDULE 4/15/2017 Gestión de Proyectos de Software

Gestión de Proyectos de Software 4/15/2017 Gestión de Proyectos de Software