SCOPE AND SCHEDULE MANAGEMENT - PowerPoint PPT Presentation

Loading...

PPT – SCOPE AND SCHEDULE MANAGEMENT PowerPoint presentation | free to download - id: 7fda59-NTJjZ



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

SCOPE AND SCHEDULE MANAGEMENT

Description:

SCOPE AND SCHEDULE MANAGEMENT Carlos Mario Zapata J. * Gesti n de Proyectos de Software * – PowerPoint PPT presentation

Number of Views:17
Avg rating:3.0/5.0
Slides: 63
Provided by: CarlosM193
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: SCOPE AND SCHEDULE MANAGEMENT


1
SCOPE AND SCHEDULE MANAGEMENT
  • Carlos Mario Zapata J.

2
5.1 PLAN SCOPE MANAGEMENT
3
(No Transcript)
4
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

5
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

6
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

7
5.2 COLLECT REQUIREMENTS
8
(No Transcript)
9
(No Transcript)
10
5.3 DEFINE SCOPE
11
(No Transcript)
12
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

13
5.4 CREATE WBS
14
(No Transcript)
15
WBS-PAQUETES
16
WBS-FASES
17
WBS-ENTREGABLES
18
(No Transcript)
19
6.1 PLAN SCHEDULE MANAGEMENT
20
(No Transcript)
21
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

22
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

23
SCHEDULE MANAGEMENT PLAN
  • SCHEDULE INPUT MONITORING
  • Compare schedule status to time status reports
  • Monitor prime contractors 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

24
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

25
6.2 DEFINE ACTIVITIES
26
(No Transcript)
27
6.3 SEQUENCE ACTIVITIES
28
(No Transcript)
29
DIAGRAMA EN RED PERT-CPM
30
6.4 ESTIMATE ACTIVITY RESOURCES
31
(No Transcript)
32
6.5 ESTIMATE ACTIVITY DURATIONS
33
(No Transcript)
34
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 (i0 ilt100 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 (i0 ilt100 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.

35
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).

36
ESTIMACIÓN DEL TAMAÑO
37
ESTIMACIÓN DEL TAMAÑO
38
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?

39
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?

40
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
41
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.

42
ESTIMACIÓN DEL TAMAÑO
  • Puntos de Objeto

43
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.

44
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
45
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 1 Cómo es la eficiencia del usuario final?
t4 Procesamiento interno complejo 1 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 1 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 0.5 Es la amigabilidad un factor importante para el usuario?
t8 Portabilidad 2 El interesado está buscando implementación en diferentes plataformas?
t9 Fácil de cambiar 1 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 1 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 1 El interesado quiere alta seguridad o encriptación de la información?
t12 Acceso directo a terceras partes 1 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. 1 Será tan complejo el software desde la perspectiva del usuario que requiera entrenamiento? Este factor debería variar en consecuencia.
46
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. 0.5 Cómo está conduciendo el proyecto el analista? Tiene suficiente conocimiento del dominio?
e5 Motivación 1 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 -1 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
47
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.

48
ESTIMACIÓN DEL TAMAÑO
  • Puntos de Clases

49
ESTIMACIÓN DEL TAMAÑO
  • Puntos de Clases

50
ESTIMACIÓN DEL TAMAÑO
  • Puntos de Clases

51
ESTIMACIÓN DEL TAMAÑO
  • Puntos de Clases
  • TCF0,55 (0,01TDI) CPTUCPTCF

52
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

53
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)CFPF
  • CF es el factor de complejidad y PF el factor de
    productividad o esfuerzo por cada punto de
    función.

54
ESTIMACIÓN DEL ESFUERZO
55
ESTIMACIÓN DEL ESFUERZO
  • De dónde salen los factores?
  • Modelos empíricos de estimación
  • EAB(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.

56
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.

57
ESTIMACIÓN DEL ESFUERZO
  • CoCoMo
  • Modos de desarrollo
  • Organic pequeños equipos de desarrollo, software
    a la medida, software pequeño y requisitos
    flexibles. E2.4 (SLOC/1000)1.05
  • Embedded Productos que deben operar con grandes
    restricciones y con cambios costosos para el
    sistema. E3.0 (SLOC/1000)1.12
  • Semi-detached Combina elementos o tiene
    características de ambos. E3.6 (SLOC/1000)1.20

58
ESTIMACIÓN DEL ESFUERZO
  • CoCoMo Factores de Costo

59
ESTIMACIÓN DEL ESFUERZO
  • CoCoMo
  • EEnom(P Factores de Costo)
  • Cálculo del tiempo
  • Organic 2.5E2.38
  • Embedded 2.5E2.32
  • Semi-detached 2.5E2.35
  • Existen otras versiones CoCoMo81, CoCoMoII y
    están en constante desarrollo.

60
ESTIMACIÓN DEL ESFUERZO
  • La ecuación del software
  • E(SLOC/1000)xB0.333/P3x(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

61
6.6 DEVELOP SCHEDULE
62
(No Transcript)
About PowerShow.com