PLAN DEL PROYECTO

1
PLAN DEL PROYECTO

• UNIDAD 4
• Ing. Francisco Mauro Salgado

2
Contenido

• 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
Pasos

• Alcance entender el problema y el trabajo que
  debe ser realizado
• Estimación qué tanto esfuerzo? cuánto tiempo?
• 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?
• Estrategia de Control cómo controlar la
  calidad?cómo controlar el cambio?

6
Escríbalo!
Alcance del Proyecto Estimaciones Riesgos Calen
dario Estrategia de Control
Plan de Proyecto de Software
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
• No obsesionarse una simple métrica para exluicr
  otras métricas importantes

9
Definir una Red de Tareas
I.5a Implement. del Concepto
I.3a Valuación de Riesgos Técnicos
I.5b Implement. del Concepto
I.6 Reacción del Cliente
I.3b Valuación de Riesgos Técnicos
I
.
1
I
.
2
I.4. Prueba del Concepto
Alcance del Concepto
Planeación del Concepto
Integrar a,b,c
I.3c Valuación de Riesgos Técnicos
I.5c Implement. del Concepto
Las 3 tareas I5 son aplicadas en paralelo a 3
diferentes funciones del concepto
Las 3 tareas I3 son aplicadas en paralelo a 3
diferentes funciones del concepto
10
Utilizar herramientas automatizadaspara generar
una gráfica de Gantt
semana 1
semana 2
semana 3
semana 4
Tareas del Proyecto
semana 5
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
11
4.3 Factores de costos de desarrollo de software.
12
El Costo del Cambio de Requerimientos
60-100x
1.5-6x
1x
Después de liberación
Desarrollo
Definición
13
Utilización vs. Deterioro
Incremento de tasa de fallas
debido a efectos colaterales
Tasa de Fallos
cambio
curva actual
Curva idealizada
Tiempo
14
Por qué se pagan las actividades de SQA?
costo para encontrar y corregir un defecto
100
60.00-100.00
escala logarítmica
10.00
10
3.00
1.50
1.00
0.75
1
prueba
Diseño
uso en campo
Req.
código
pruebas de sistema
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
• Evaluar
• Predecir
• Mejorar

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

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

20
Métricas de Proyecto

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

21
Métricas sobre Producto

• enfoque en la calidad de los entregables
• medidas del modelo de análisis
• 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 la efectividad del proceso
• v.g. eficiencia en remoción de defectos

22
Lineamientos sobre Métricas

• Utilizar el sentido comú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.
• 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
• 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)
• Defectos por KLOC
• por LOC
• páginas de documentos por KLOC
• errores / persona-mes
• LOC / persona-mes
• / página de documentación

25
Métricas Típicas Orientadas a Función

• errores por FP (cientos de líneas de código)
• defectos por FP
• por FP
• páginas de documentación por FP
• determinar el tipo de proyecto
• 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
• 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
Establecer el conteo para cada dominio de
entrada e interfaces de sistema
Pesar cada conteo por evaluación de la complejidad
Asignar el nivel de complejidad o peso para cada
conteo

evaluar la influencia de factores globales
que afecten la aplicación
Grado de importancia de factores externos Fi
tales como reuso, concurrencia, SO,...
Puntos función ? (conteo x peso) x C
Calcular puntos función
donde
Factor de complejidad C (0.65 0.01 x N)
Grado de influencia N ? Fi
28
Analizar el Dominio de la Información
factor de ponderación
conteo
simple prom. complejo
parámetro de medida
de entradas de usuario
3
4
6

X






de salidas de usuario
4
5
7

X






de consultas
3
4
6

X






de archivos
7
10
15

X






of interfaces ext.
5
7
10

X
conteo-total
factor de complejidad
puntos función
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
• Mantenibilidad grado en el que un programa es
  conveniente al cambio
• Integridad grado en el cual un programa permite
  el ataque externo
• Usabilidad grado en el cual un programa es
  fácil de usar

31
Eficiencia de Remoción de ErroresDefect 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)
• 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)

35
Descomposición Funcional
descomposición funcional
Declaración
realizar
un
del Alcance
análisis
gramatical"
36
Métodos ConvencionalesLOC/FP

• calcular LOC/FP utilizando estimaciones de
  valores del dominio de información
• recurrir al esfuerzo histórico de proyectos

37
Ejemplo de LOC
Costo
LOC estim.
/LOC
Effort (months)
LOC/pm
Funciones
315
UICF
2340
14
32,000
7.4
5380
2DGA
220
20
107,000
24.4
220
3DGA
6800
20
136,000
30.9
DSM
3350
240
18
60,000
13.9
CGDF
4950
200
22
109,000
24.7
2140
140
60,000
15.2
PCF
28
18
300
8400
151,000
28.0
DAM
Totals
33,360
655,000
145.0
38
Ejemplo FP
peso
parámetro de medida
counteo
entradas de usuario
160
4
x

40






salidas de usuario
125
5
x

25






de consultas
48
4
x

12






de archivos
28
7
x

4

0.25 p-m / FP 120 p-m





interfaces externas
28
7
x

4






algoritmos
180
3
x

60
569
conteo total
factor de complejidad
.84
478
puntos función
39
Estimación basada en herramientas
características del proyecto
factores de calibración
datos de LOC/FP
40
Empirical Estimation Models
Forma general
exponente
esfuerzo coefte_afinación tamaño
usualmente referido como personas-mes de
esfuerzo requerido
derivado empíricamente
usualmente LOC pero pueden ser FPs
constante o número derivado basado en la
complejidad del proyecto
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
simple (0.30)
construir
difícil (0.70)
cambios menores (0.40)
reusar
sistema X
simple (0.20)
cambios mayores (0.60)
comprar
complejo (0.80)
cambios menores (0.70)
Outsourcing
cambios mayores (0.30)
sin cambios (0.80)
con cambios (0.40)
43
Cálculo del Costo Esperado
costo esperado
? (RutaProbabilidad)i x (CostoRutaEstim) i
Por ejemplo, el costo esperado para construir

costo esperadoconstruir 0.30(380K)0.70(450K)


429 K

en forma similar,


costo esperadoreuso 382K
costo esperadocomprar 267K

costo esperadooutsrc 410K
44
4.6 Evaluación de Riesgos
45
Construir una Tabla de Riesgos
Riesgo
Probabilidad
Impacto
RMMM
(Risk Mitigation Monitoring Management)
(Admón. y Monitoreo de la Mitigación de Riesgos)
46
Construir la Tabla de Riesgos

• Estimar la probabilidad de ocurrencia
• 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

47
Administración, Monitoreoy Mitigación de Riesgos

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

48
Riesgos Asociados al Tamaño del Producto
Atributos que afectan al riesgo
tamaño estimado del proyecto en LOC o FP?

tamaño estimado del proyecto en número de
programas, archivos, transacciones?

porcentaje de desviación en el tamaño del
producto del promedio de los productos anteriores?

tamaño de las bases de datos creadas o
utilizadas por el producto?

número de usuarios del producto?

número de cambios proyectados a los
requerimientos del proyecto?antes de la
entrega? después de la entrega?

cantidad de software reusado?
49
Riesgos Asociados al Impacto del Negocio
Atributos que afectan al riesgo
afectación de este producto en las utilidades
de la empresa?
visibilidad de este producto por la alta
gerencia?
razonabilidad del tiempo de entrega?
número de clientes que utilizarán este
producto?
restricciones de interoperabilidad
sofisticación de los usuarios finales?
cantidad y calidad de documentación del
producto que debe ser producida y enviada al
cliente?

restricciones gubernamentales
costos de entregar tarde el producto?
costos asociados con un producto defectuoso?
50
Riesgos Asociados al Cliente
Cuestionamientos que deben ser resueltos
se ha trabajado con ese cliente en el pasado?
el cliente tiene una idea sólida de lo que
requiere?
el cliente está de acuerdo en trabajar
contigo?
el cliente participaría en las revisiones?
el cliente es técnicamente sofisticado?
el cliente permitiría el poder hacer el
trabajo esto es, el cliente resistiría
observar sobre tus hombros durante el trabajo
técnico detallado?
el cliente entiende el proceso de ingeniería
de software?
51
Riesgos Asociados a la Madurezdel Proceso
Cuestionamientos que deben ser resueltos
has establecido un framework de proceso común?
lo siguen los equipos de proyecto?
tienes soporte de administración para la
ingeniería de software?
realizas proactivamente el SQA?
realizas las reuniones técnicas formales?
se utilizan herramientas CASE para el
análisis, diseño y pruebas?
están las herramientas integradas con alguna
otra?
se han establecido formatos de documentos?
52
Riesgos de Tecnología
Cuestiones que deben ser resueltas
la tecnología es nueva en tu organización?
se requieren nuevos algoritmos, tecnologías
de E/S?
se involucra hardware nuevo o sin probar?
se interfaza la aplicación con un nuevo
software?
se requiere una interfaz de usuario
especializada?
la aplicación es radicalmente diferente?
estás utilizando nuevos métodos de ingeniería
de Sw?
estás utilizando métodos de desarrollo de
software no convencionales, tales como métodos
formales, inteligencia artificial, redes
neuronales, etc?
hay restricciones de desempeño significativo?
existe la duda si la funcionalidad requerida
es realizable?
53
Riesgos Asociados a las Personas
Cuestionamientos que deben ser resueltos
está disponible el mejor personal?
el staff tiene las habilidades adecuadas?
hay suficiente personal disponible?
existe el compromiso completo?
habrá gente que trabaje parcialmente?
el staff tiene las expectativas adecuadas?
el staff tiene el suficiente entrenamiento?
podría la respuesta del staff ser baja?
54
Registro de la Información de Riesgo
Projecto Software Incrustado para el Sistema
XYZ Tipo de Riesgo Riesgo de Calendarización Prio
ridad (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 Plan de Contingencia
Modificación de la estrategia de pruebas para
soportar el retraso usando simulación de
software Recursos Estimados 6 personas-mes a
partir del 7/Mar/2002
55
4.7 Plan de Aseguramiento de la Calidad del
Software
56
Aseguramiento de la Calidad del SoftwareSoftware
Quality Assurance
SQA
Definición y Estándares de Proceso
Revisiones Técnias Formales
Análisis y Reporteo
Planeación y Revisión de Pruebas
Métrica
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.     Adm
inistració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
R - Requerido S - Sugerido (Justificar sino se
proporciona)
60
RETENCIÓN DE REGISTROS
61
4.8 Administración de la Configuración del
Software
62
Cuáles son estos Cambios?
Cambios en los requerimientos de negocio
Cambios en los requerimientos técnicos
Cambios en los requerimientos del usuario
otros docuementos
modelos de Sw
Plan de Proyecto
datos
Prueba
código
63
Configuración deSoftware
programas
documentos
Las piezas
datos
64
Proceso de Control de CambiosI
la necesidad del cambios es reconocida
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
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
checar la entrada de los SCIs cambiados
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
67
PLAN DE ADMINISTRACION DE LA CONFIGURACION

•  
•  
• 1.                   Introducción
• 1.1              Propósito del Plan
• 1.2              Alcance
• 1.3              Definiciones
• 1.4              Referencias
•  
• 2.                  Administración
• 2.1              Organización
• 2.2              Responsabilidades
• 2.3              Procedimientos, Directivas y
  Políticas
•  
• 3.                  Actividades
• 3.1              Identificación de la
  configuración
• 3.1.1        Identificación de elementos de
  configuración
• 3.1.2        Asignación de nombres a elementos de
  configuración
• 3.1.3        Obtención de elementos de
  configuración