clase 8, 12/9/2007

45
Metodologías de Análisis Clase 8 – 12/9/2007 Christian Sifaqui

Upload: christian-sifaqui

Post on 27-Jun-2015

1.584 views

Category:

Business


0 download

TRANSCRIPT

Page 1: Clase 8, 12/9/2007

Metodologías de Análisis

Clase 8 – 12/9/2007

Christian Sifaqui

Page 2: Clase 8, 12/9/2007

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

Page 3: Clase 8, 12/9/2007

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)

Page 4: Clase 8, 12/9/2007

Halstead

Nivel (L)L = V* / V

= (2 / n1) × (n2 / N2)Dificultad (D)

D = V / V*

= (n1 / 2) × (N2 / n2)Esfuerzo (E)

= V / L

Page 5: Clase 8, 12/9/2007

Halstead

Fallas (B)

B = V / S*

V* = mínimo volumen para desarrollar la misma tarea

S* = media de decisiones mentales entre decisiones (3000)

Page 6: Clase 8, 12/9/2007

Halstead

Depende del código terminado

No sirve como modelo predictivo

Page 7: Clase 8, 12/9/2007

Planificación

SPMP: – El trabajo a realizar– Recursos: personas, hardware, software de

soporte (sistema operativo, editor, software de control de revisión, etc.)

– Dinero

Page 8: Clase 8, 12/9/2007

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

Page 9: Clase 8, 12/9/2007

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)

Page 10: Clase 8, 12/9/2007

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

Page 11: Clase 8, 12/9/2007

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)

Page 12: Clase 8, 12/9/2007

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

Page 13: Clase 8, 12/9/2007

Planificación

SPMP: plan de administración del proyecto de software

Un estándar es el IEEE Standard 1058.1

Page 14: Clase 8, 12/9/2007

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

Page 15: Clase 8, 12/9/2007

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

Page 16: Clase 8, 12/9/2007

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

Page 17: Clase 8, 12/9/2007

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

Page 18: Clase 8, 12/9/2007

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

Page 19: Clase 8, 12/9/2007

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

Page 20: Clase 8, 12/9/2007

Planificación

7.8.- Plan de mejoras al proceso

8.- Planes adicionales

Page 21: Clase 8, 12/9/2007

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

Page 22: Clase 8, 12/9/2007

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

Page 23: Clase 8, 12/9/2007

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

Page 24: Clase 8, 12/9/2007

Planificación

“Si meto más indios a la canoa…

¿avanzamos más rápido o nos hundimos?”

Page 25: Clase 8, 12/9/2007

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

Page 26: Clase 8, 12/9/2007

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)

Page 27: Clase 8, 12/9/2007

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

Page 28: Clase 8, 12/9/2007

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

Page 29: Clase 8, 12/9/2007

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

Page 30: Clase 8, 12/9/2007

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

Page 31: Clase 8, 12/9/2007

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

Page 32: Clase 8, 12/9/2007

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

Page 33: Clase 8, 12/9/2007

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

Page 34: Clase 8, 12/9/2007

Identificación de riesgos

• Riesgos tecnológicos

• Riesgos del personal

• Riesgos organizacionales

• Riesgos de los requerimientos

• Riesgos en la estimación

Page 35: Clase 8, 12/9/2007

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

Page 36: Clase 8, 12/9/2007

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

Page 37: Clase 8, 12/9/2007

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

Page 38: Clase 8, 12/9/2007

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

Page 39: Clase 8, 12/9/2007

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

Page 40: Clase 8, 12/9/2007

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

Page 41: Clase 8, 12/9/2007

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

Page 42: Clase 8, 12/9/2007

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)

Page 43: Clase 8, 12/9/2007

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

Page 44: Clase 8, 12/9/2007

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

Page 45: Clase 8, 12/9/2007

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