Clase 8, 12/9/2007
-
Upload
christian-sifaqui -
Category
Business
-
view
1.586 -
download
0
Transcript of Clase 8, 12/9/2007
Metodologías de Análisis
Clase 8 – 12/9/2007
Christian Sifaqui
Halstead
Halstead’77 “Elements of Software Science”
n1 = número de operadores únicos o distintos
n2 = número de operandos únicos o distintos
N1 = número total de ocurrencias de operadores
N2 = número total de ocurrencias de operandos
Halstead
Vocabulario (n)
n = n1 + n2
Largo (N)
N = N1 + N2
= n1 × log2(n1) + n2 × log2(n2)Volumen (V)
V = N × log2(n1)
= N × log2(n1 + n2)
Halstead
Nivel (L)L = V* / V
= (2 / n1) × (n2 / N2)Dificultad (D)
D = V / V*
= (n1 / 2) × (N2 / n2)Esfuerzo (E)
= V / L
Halstead
Fallas (B)
B = V / S*
V* = mínimo volumen para desarrollar la misma tarea
S* = media de decisiones mentales entre decisiones (3000)
Halstead
Depende del código terminado
No sirve como modelo predictivo
Planificación
SPMP: – El trabajo a realizar– Recursos: personas, hardware, software de
soporte (sistema operativo, editor, software de control de revisión, etc.)
– Dinero
Planificación
El uso de recursos está de acuerdo a la distribución Rayleigh, según Norden’58
0 ≤ t ≤ ∞
2
2
22cR K
t
ek
t
Planificación
El plan de desarrollo de software debe ser función del tiempo
El trabajo a desarrollar:– durante el proyecto y no tiene relación con las
fases (workflow) como administración del proyecto y control de calidad
– relativo a cada fase (workflow)
Planificación
Actividad– Trabajo que se relaciona a una fase
específica– Es una unidad mayor de trabajo– Con fechas precisas de inicio y término– Consume recursos– Resulta en productos de trabajo como
presupuesto, diseño, cronogramas, código fuente o manual de usuario
Planificación
Tareauna actividad incluye un conjunto de tareas (la unidad más pequeña de trabajo sujeta a ser considerada para la administración)
Planificación
Hitola fecha en la que el producto de trabajo debe estar completo
Debe pasar revisiones ejecutadas por:– miembros del equipo de trabajo– administración– cliente
Planificación
SPMP: plan de administración del proyecto de software
Un estándar es el IEEE Standard 1058.1
Planificación
1.- Visión general1.1.- Resumen del proyecto
1.1.1.- Propósito, alcance y objetivos
1.1.2.- Suposiciones y restricciones
1.1.3.- Entregables del proyecto
1.1.4.- Resumen del cronograma y de presupuesto
1.2.- Evaluación del plan de administración de proyecto
Planificación
2.- Materiales de referencia
3.- Definiciones y acrónimos
4.- Organización del proyecto4.1.- Interfaces externas
4.2.- Estructura interna
4.3.- Roles y responsabilidades
Planificación
5.- Planes de proceso directivo5.1.- Plan de inicio
5.1.1.- Plan de estimación
5.1.2.- Plan de personal
5.1.3.- Plan de adquisición de recursos
5.1.4.- Plan de entrenamiento de personal del proyecto
Planificación
5.2.- Plan de trabajo5.2.1.- Actividades de trabajo
5.2.2.- Distribución de cronograma
5.2.3.- Asignación de recursos
5.2.4.- Distribución de presupuesto
5.3.- Plan de control5.3.1.- Plan de control de requerimientos
5.3.2.- Plan de control de cronograma
5.3.3.- Plan de control de recursos
5.3.4.- Plan de control de calidad
5.3.5.- Plan de reportes
5.3.6.- Plan de recolección de métricas
Planificación
5.4.- Plan de administración del riesgo
5.5.- Plan de cierre del proyecto
6.- Planes de procesos técnicos6.1.- Modelo del proceso
6.2.- Métodos, herramientas y técnicas
6.3.- Plan de infraestructura
6.4.- Plan de aceptación del producto
Planificación
7.- Planes de soporte de proceso7.1.- Plan de administración de la configuración
7.2.- Plan de testing
7.3.- Plan de documentación
7.4.- Plan de aseguramiento de la calidad
7.5.- Plan de revisiones y auditoría
7.6.- Plan de resolución de problemas
7.7-. Plan de administración de subcontratistas
Planificación
7.8.- Plan de mejoras al proceso
8.- Planes adicionales
Planificación
• Dividir el proyecto en tareas y estimar tiempo y recursos requeridos para completar cada tarea
• Organizar tareas concurrentemente para hacer uso óptimo del workplace
• Mimizar dependencias entre tareas para evitar demoras causadas por una tarea esperando que otro la finalice
• Depende de la intuición y experiencia de los administradores de proyecto
Planificación
Identificaractividades
Identificaractividades
Identificardependenciasen actividades
Identificardependenciasen actividades
Estimar recursospara actividades
Estimar recursospara actividades
Asignar personasa actividades
Asignar personasa actividades
Crear cartasde proyecto
Crear cartasde proyecto
Requerimientosde
sofware
Cartas deactividades y gráficos
Planificación
• Estimar la dificultad de los problemas y de ahí el costo de desarrollo es difícil
• La productividad no es proporcional al número de gente trabajando en una tarea
• Incorporar gente a un proyecto atrasado lo atrasa aún más, debido a la sobrecarga en la comunicaciones
• Lo inesperado siempre ocurre: permita siempre contingencias en la planificación
Planificación
“Si meto más indios a la canoa…
¿avanzamos más rápido o nos hundimos?”
Planificación
• Mostrar la descomposición del proyecto en tareas. Las tareas no debieran tomar más de 1 ó 2 semanas
• Los gráficos de actividad muestran dependencias entre las tareas y el camino crítico
Planificación
Actividad Duración (días) Dependencias
T1 8
T2 15
T3 15 T1 (M1)
T4 10
T5 10 T2, T4 (M2)
T6 5 T1, T2 (M3)
T7 20 T1 (M1)
T8 25 T4 (M5)
T9 15 T3, T6 (M4)
T10 15 T5, T7 (M7)
T11 7 T9 (M6)
T12 10 T11 (M8) M: milestone (hito)
Planificación
start
T2
M3T6
Finish
T10
M7T5
T7
M2T4
M5
T8
4/7/03
8 days
14/7/03 15 days
4/8/03
15 days
25/8/03
7 days
5/9/03
10 days
19/9/03
15 days
11/8/03
25 days
10 days
20 days
5 days25/7/03
15 days
25/7/03
18/7/03
10 days
T1
M1 T3T9
M6
T11
M8
T12
M4
Planificación
4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T1T2
M1
T7T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T11M8
T12
Start
Finish
Planificación
4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T8 T11
T12
T1
T3
T9
T2
T6 T10
T7
T5
Fred
Jane
Anne
Mary
Jim
Administración del riesgo
• Administración del riesgo trata de identificar los riesgos y esbozar planes para minimizar sus efectos en el proyecto
• Un riesgo es una probabilidad de que ocurra alguna circunstancia adversa– Los riesgos del proyecto afectan al cronograma o a los recursos– Los riesgos de producto afectan la calidad o rendimiento del
software que se está desarrollando– Los riesgos de negocios afectan a la organización en desarrollar
el software
Riesgo
Riesgo Afecta Descripción
Rotación de personal
Proyecto Personal experimentado dejará el proyecto antes que éste finalice
Cambio en la administración
Proyecto Habrá cambio en la administración organizacional con diferentes prioridades
No disponibilidad de hardware
Proyecto Hardware que es esencial para el proyecto no será entregado a tiempo
Cambio en los requerimientos
Proyecto y producto
Habrá un gran número de cambios a los requerimientos imposibles de anticipar
Demoras en la especificación
Proyecto y producto
Las especificaciones en interfaces esenciales no estarán disponibles a tiempo
Baja estimación del tamaño
Proyecto y producto
El tamaño del sistema se subestimó
Mal rendimiento del CASE
Producto Las herramientas CASE que sustentan el proyecto no funcionan como lo predicho
Cambio en la tecnología
Negocio La tecnología base con la que se construye el sistema ha sido superada por tecnología nueva
Competencia para el producto
Negocio Un producto de la competencia salió al mercado antes que el sistema esté listo
Proceso de administración del riesgo
• Identificación del riesgo– Identificar riesgos del proyecto, producto y negocio
• Análisis de riesgo– Estimar la probabilidad y consecuencias de estos
riesgos
• Planificar riesgos– Diseñar planes para evitar o minimizar los efectos del
riesgo
• Monitorear el riesgo– Monitorear los riesgos durante el proyecto
Proceso de administración del riesgo
Identificacióndel riesgo
Identificacióndel riesgo
Análisisdel riesgo
Análisisdel riesgo
Planificacióndel riesgo
Planificacióndel riesgo
Monitoreodel riesgo
Monitoreodel riesgo
Lista de riesgos
potenciales
Lista de riesgos
potencialesLista de riesgos
priorizados
Lista de riesgos
priorizados
Planes para
evitar riesgos y
de contingencia
Planes para
evitar riesgos y
de contingencia
Evaluación
de riesgo
Evaluación
de riesgo
Identificación de riesgos
• Riesgos tecnológicos
• Riesgos del personal
• Riesgos organizacionales
• Riesgos de los requerimientos
• Riesgos en la estimación
Riesgos y tipos de riesgos
Tipo de riesgo Riesgos posibles
Tecnología La BD usada en el sistema no puede procesar la cantidad de transacciones por segundo esperada Las componentes de software que deberían ser reusadas contienen defectos que limitan su funcionalidad
Personal Es imposible de contratar personal con las habilidades requeridas Personal clave está enfermo o no disponible en tiempos críticos No hay disponibilidad de entrenamiento requerido para el equipo de trabajo
Organizacional La organización se ha reestructurado de tal manera que ahora una administración distinta es responsable del proyecto Problemas financieros de la organización fuerzan a reducciones en el presupuesto del proyecto
Herramientas El código generado por el CASE es ineficiente Las herramientas CASE no pueden ser integradas
Requerimientos Se proponen cambios a los requerimientos que requieren mayor diseño Los clientes no entienden el impacto en los cambios de los requerimientos
Estimación El tiempo requerido para desarrollar el software fue subestimado La tasa de reparación de defectos fue subestimada El tamaño del software fue subestimado
Análisis de riesgos
• Estimar probabilidad y seriedad de cada riesgo
• La probabilidad puede ser muy baja, baja, moderada, alta o muy alta
• Los efectos de los riesgos pueden ser catastróficos, serios, tolerables o insignificantes
Análisis de riesgos
Riesgo Probabilidad Efectos
Problemas financieros organizacionales fuerzan a reducciones en el presupuesto del proyecto
Baja Catastróficos
Es imposible conseguir personal con las habilidades requeridas para el proyecto
Alta Catastróficos
Personal clave está enfermo en tiempos críticos del proyecto
Moderada Serios
Componentes de software que deberían ser reusadas contienen defectos que limitan su funcionalidad
Moderada Serios
Se proponen cambios a los requerimientos que requieren un gran rediseño
Moderada Serios
La organización se reestructura de tal manera que ahora hay una administración distinta responsable del proyecto
Alta Serios
Análisis de riesgos
Riesgo Probabilidad Efectos
La BD usada en el sistema no puede procesar la cantidad de transacciones por segundo esperadas
Moderada Serios
El tiempo requerido para desarrollar el software fue subestimado
Alta Serios
Las herramientas CASE no pueden ser integradas
Alta Tolerables
Los clientes no entienden los impactos de los cambios en los requerimientos
Moderada Tolerables
No hay entrenamiento requerido para el personal
Moderada Tolerables
La tasa de reparación de defectos fue subestimada
Moderada Tolerables
El tamaño del software fue subestimada Alta Tolerables
El código generado por el CASE es ineficiente Moderada Insignificantes
Planificación de riesgos
• Considerar cada riesgo y desarrollar una estrategia para administrarlo
• Estrategias para evitar riesgos– La probabilidad que el riesgo surja se reduce
• Estrategias de minimización– El impacto del riesgo en el proyecto o producto se
reducirá
• Planes de contingencia– Si el riesgo surje, los planes de contingencia son
planes para tratar ese riesgo
Estrategias de administración del riesgo
Riesgo Estrategia
Problemas financieros organizacionales
Preparar un documento ejecutivo para la administración superior mostrando cómo el proyecto está haciendo una contribución muy importante a las metas del negocio
Problemas de contratación de personal
Alertar al cliente de posibles dificultades y la posibilidad de demoras, investigar la adquisición de componentes
Enfermedad del personal
Reorganizar el equipo de tal manera que haya más traslape de trabajos y personal para que así el equipo entienda las tareas de los demás
Componentes defectuosas
Reemplazar la componentes defectuosos mediante la adquisición de componentes de confiabilidad conocida
Estrategias de administración del riesgo
Riesgo Estrategia
Cambios en los requerimientos
Derivar información de seguimiento para estimar el impacto de cambio, maximizar ocultamiento de la información en el diseño
Reestructuración organizacional
Preparar un documento ejecutivo para la administración superior mostrando cómo el proyecto está haciendo una importante contribución a los objetivos del negocio
Rendimiento de la BD
Investigar la posibilidad de adquirir una BD de mayor rendimiento
Tiempo de desarrollo subestimado
Investigar adquirir componentes, investigar uso de un generador de programas
Monitoreo del riesgo
• Estimar cada riesgo en forma regular para decidir si se está haciendo más o menos probable
• También estimar si los efectos del riesgo han cambiado
• Cada riesgo clave debe ser discutido en reuniones de avance (de administración)
Indicadores de riesgo
Tipo de riesgo Indicadores potenciales
Tecnología Entrega tardía de hardware o software de soporte, muchos problemas tecnológicos reportados
Personal Moral del equipo baja, malas relaciones entre miembros del equipo, disponibilidad de trabajo
Organizacional Rumores organizacionales, carencia de acción por la administración superior
Herramientas Reticencia por miembros del equipo de usar herramientas, reclamos acerca de herramientas CASE, demandas por mejores estaciones de trabajo
Requerimientos Muchos pedidos de cambios de requerimientos, quejas de los clientes
Estimación Falla en cumplir el cronograma acordado, falla en eliminar defectos reportados
Resumen
• Buena administración del proyecto es esencial para el éxito del proyecto
• La naturaleza intangible del software causa problemas para su administración
• Administradores tienen diversos roles pero sus actividades más importantes son planificación, estimación y cronograma
• Planificación y estimación son procesos iterativos que se realizan continuamente durante el desarrollo de un proyecto
Resumen
• Un hito del proyecto es un estado predecible con un reporte formal de progreso presentado a la administración
• El cronograma del proyecto involucra preparar diversas representaciones gráficas mostrando actividades del proyecto, sus duraciones y personal
• Administración del riesgo se aboca en– identificar los riesgos que podrían afectar el proyecto y– planificar para asegurar que esos riesgos no se convertirán en
amenazas mayores