planificacion proyecto software

8/8/2019 Planificacion Proyecto Software

http://slidepdf.com/reader/full/planificacion-proyecto-software 1/103

Planificación de Proyectos de

Software



¿Por qué Planificar?

Boehm, 1975: 45% de los errores tienen su origen en los requisitos y en el diseño preliminar. DeMarco, 1984: 56% de los errores que tienen

lugar en un proyecto software se deben a una mala especificación de requisitos. Chaos Report, 1995: Los factores principales que conducen al fracaso en los proyectos software son:

Falta de comunicación con los usuarios. Requisitos incompletos. Cambios a los requisitos.



¿Es lo Mismo?



Introducción

Antes de comenzar se debe estimar ± Esfuerzo, tiempo, personal y demás recursos..

Luego de estimar se debe planificar

±Establecer un Plan de Proyecto que

defina tareas y fechas clave,

identificar responsables por

tareas y especificar

dependencias entre tareas.



Objetivos

Resolver problemas corriente arriba a bajocosto.

La experiencia dice que el proyecto promediogasta 80 por ciento de su tiempo enreelaboración: corrigiendo errores que secometieron en etapas tempranas del

proyecto.



Objetivos

Proporcionar un Marco de Trabajoque permita al gestor estimar

razonablemente los recursos, costo yprograma de trabajo.

Adaptar y actualizar el plan conformese avance en el proyecto.



Actividades

La planificación del proyecto del softwareabarca 5 grandes actividades:

EstimaciónPrograma de Trabajo

Análisis de Riesgos

Planificación de la Gestión de CalidadPlanificación de la Gestión del Cambio



La Estimación

No necesita realizarse en una formaimprovisada.

La experiencia es una gran ayuda.

La estimación implica riesgo inherente, y esteconduce a la incertidumbre.

El riesgo de la estimación se mide por el grado

de incertidumbre en las estimacionescuantitativas para recursos, costos y programade trabajo.



La Estimación

Variabilidad en requisitos = inestabilidad

Un gestor no debe obsesionarse con las

estimaciones.



Recursos

Divididos en Tres Grandes Categorías:

Personal

Componentes de Software Reutilizables Entorno



La Trinidad

Proyecto

Personal

EntornoSoftware

Reutilizable



Recursos Humanos

El planificador debe especificar:

± Habilidades Requeridas

±

PosiciónO

rganizacional ± Especialidad

E

l personal puede estar Geográficamentedisperso.



Recursos de Software Reutilizables

Ingeniería de Software basada enComponentes.

Énfasis en la reutilización

Componentes ya desarrollados.

Adquirir componentes de Terceros.

Componentes Experimentados

Componentes de Experiencia Parcial No inventar el Agua Tibia



Recursos del Entorno

Hardware

Software (Herramientas de Desarrollo)



Estimación

Un gran error en la estimación puede hacer ladiferencia entre Ganancia o Perdida.

Mala

Estimación

Desastre parael

Desarrollador



Estimación

Nunca es exacta

Mientras más se conozca menos errores seriosse cometerán.

Implica muchas variables ± Humanas

± Técnicas

± Ambientales ± Políticas

± etc



¿Como lograr estimaciones Confiables?

Basarse en proyectos similares

Descomposición Simple

Uso de Modelos Empíricos



Estimación

Usar Datos

Históricos



Técnicas de Descomposición

El problema a resolver es muy complejo paraconsiderarlo una sola pieza

Descomponer el problema en problemas máspequeños

Hacer el problema más MANEJABLE



Tamaño del Software

El grado con elcual se haestimado

adecuadamenteel tamaño

Habilidad para

traducirestimación enesfuerzohumano,

cronograma y

Dinero

Grado en el que

la planificaciónrefleja las

habilidades delequipo de

Software



Estimación Basada en el Problema

Métricas basadas en la Productividad

LDC/pm

PF/pm Combinaciones



Estimación Basada en el Problema



Estimación

OptimistaMas

ProbablePesimista

ValorEsperado



Estimación basada en LDC(Líneas de Código)

Descomposición funcional absolutamenteesencial

considerables niveles de detalle LDC se estima directamente.



E jemplo



Estimación basada en PF(Puntos de Función)

Los datos requeridos para estimar los Puntosde Función son más macroscópicos que enLDC.

Nivel de descomposición considerablementemenos detallado que en LDC.

PF se determina indirectamente mediante la

estimación del número de entradas, salidas,archivos de datos, peticiones e interfacesexternas, entre otras.



E jemplo



LDC o PF Esperados

A partir de los datos históricos o (cuando todo lodemás falla) usando su intuición, el planificador estimalos valores optimista, más probable y pesimista de LDCo de PF para cada función. Cuando lo que se especificaes un rango de valores, implícitamente se proporcionauna indicación del grado de incertidumbre.

Entonces, se calcula el valor esperado de LDC o de PF.El valor esperado para la variable de estimación, E, se

obtiene como una medida ponderada de lasestimaciones LDC o PF óptima (a), más probable (m) ypesimista (b).



Estimación basada en el Proceso

Técnica más habitual

El proceso se descompone en actividades o

tareas y el esfuerzo requerido para llevar acabo cada tarea

Se presentan las tareas en forma de tabla



Pasos de la Estimación basada en elProceso

Delimitar las funciones obtenidas a partir del ámbitodel software

Actividades del proceso para cada función

Estimación de esfuerzo (persona-mes) para cadaactividad

En cada función

Aplicación de índices de trabajo medios (esfuerzo

coste/unidad) al esfuerzo estimado para cada actividad Cálculo de costes y esfuerzo de cada función y de la

actividad



E jemplo



Estimación basada en Casos de Uso

Permiten que el equipo de software comprendamejor el ámbito y los requisitos.

El uso de casos de uso es a veces problemático

porque: ± no existe un formato estándar. ± Representan una visión externa con diferentes grados

de abstracción ± No abordan la complejidad de las funciones ni de las

características Los expertos recomiendan no usar mas de 10 casos

de Uso con no mas de 30 escenarios



Metodología General a Usar conEstimación de Casos de Uso



¿CómoEstimar

usandoCasos de

Uso?



Reconciliación de Estimaciones

La estimacion por LDC, PF y basadas en elproceso se realizan independientemente.

Cuando se tienen algunas estimaciones de costoy esfuerzo se pueden comparar y armonizar.

Si tienen un buen grado de concordancia sonconfiables las estimaciones.

Si son poco concordantes los resultados de lasestimaciones, entonces se debe investigar yanalizar mejor



Técnicas Delfi

Desarrolladas con el fin de obtener el consenso de un grupo de expertos sin contarcon los efectos negativos de las reuniones de grupos. La técnica puede adaptarse a laestimación de costos de la siguiente manera:

Un coordinador proporciona a cada experto la documentación con la definición delsistema y una papeleta para que escriba su estimación.

Cada experto estudia la definición y determina su estimación en forma anónima; los

expertos pueden consultar con el coordinador, pero no entre ellos. El coordinador prepara y distribuye un resumen de las estimaciones efectuadas,

incluyendo cualquier razonamiento extraño efectuado por alguno de los expertos. Los expertos realizan una segunda ronda de estimaciones, otra vez anónimamente,

utilizando los resultados de la estimación anterior. En los casos que una estimacióndifiera mucho de las demás, se podrá solicitar que también en forma anónima elexperto justifique su estimación.

El proceso se repite varias veces como se juzgue necesario, impidiendo una discusióngrupal durante el proceso.



Modelos Empíricos de Estimación

Modelos empíricos de estimación:

Utilizan fórmulas derivadas empíricamente parapredecir el esfuerzo como una función de LDC o PF.

Datos empíricos obtenidos de una muestra deproyectos:

± difíciles de usar para todas las clases de software y todos

los entornos de desarrollo ± se deben calibrar para las condiciones específicas de una

organización



Ecuaciones de los Modelos Empíricos



Observaciones

Se nota claramente que cada uno de losmodelos (ecuaciones) producirá un resultadodiferente para los mismos valores de LDC o PF.

Los modelos deben CALIBRARSE para lasnecesidades locales



Cocomo

El Modelo Constructivo de Costos (COnstructive COst Model) es una jerarquía de modelos de estimación para el software.

Las ecuaciones del modelo COCOMO básico tienen la siguienteforma:

E = ab (KLDC) exp (bb) D = cb (E) exp (db) donde E es el esfuerzo aplicado en personas-mes, D es el tiempo de

desarrollo en meses cronológicos y KLDC es el número estimado deLíneas de Código distribuídas (en miles) para el proyecto.

Las ecuaciones del modelo COCOMO intermedio toma la forma: E = ai (KLDC) exp (bi) x FAE donde E es el esfuerzo aplicado en personas-mes, KLDC es el

número estimado de Líneas de Código distribuídas para el proyecto.



Jerarquías de Cocomo

El modelo COCOMO básico es un modelo univariableestático que calcula el esfuerzo (y el costo) del desarrollode software en función del tamaño del programaexpresando en líneas de código (LDC) estimadas.

El modelo CO

CO

MO

intermedio calcula el esfuerzo deldesarrollo de software en función del tamaño del programay de un conjunto de conductores de costo, que incluyen laevaluación subjetiva del producto, del hardware, delpersonal y de los atributos del proyecto.

El modelo COCOMO avanzado incorpora todas lascaracterísticas de la versión intermedia y lleva a cabo unaevaluación de impacto de los conductores de costo en cadafase (análisis, diseño, etc.) del proceso de ingeniería desoftware.



Cocomo Orientado a los Tipos deproyecto de software

Modelo Orgánico. Proyectos de software relativamente pequeños ysencillos en los que trabajan pequeños equipos, con buenaexperiencia en la aplicación, sobre el conjunto de requisitos pocorígidos (por ejemplo, un programa de análisis termal desarrolladopara un grupo calórico).

Modelo Semiacoplado. Proyectos de software intermedios (entamaño y complejidad) en los que los equipos, con variados nivelesde experiencia, deben satisfacer requisitos poco o medio rígidos(por ejemplo, un sistema de procesamiento de transacciones conrequisitos fijos para un hardware de terminal o un software degestión de base de datos).

Modelo Empotrado. Proyectos de software que deben serdesarrollados en un conjunto de hardware, software y restriccionesoperativas muy restringidas (por ejemplo, software de control denavegación para un avión).



COCOMO II

Es una Evolución del COCOMO original propuestopor Boehm

Aborda las siguientes áreas: ±

Modelo de composición de la aplicación ± Modelo de la etapa de diseño temprano ± Modelo de etapa posterior a la arquitectura

Tres opciones de Tamaño: ± Puntos de Funcion PF ± Lineas de Codigo Fuente LDC ± Puntos Objeto PO



Puntos Objeto

Son una manera indirecta de calcular el tamañodel software por medio de conteo de: ± Pantallas de interfaz de usuario ± Reportes ± Componente requeridos para las construcción de la

aplicación.

Las ponderaciones se basan en una tabla Se determina el numero de PO y se multiplica por

la ponderacion Se suman todos los resultados para obtener una

cuenta total de PO.



Puntos Objeto

Estimando el % de reutilizacion se ajusta lacuenta de PO

NPO = (PO) * [(100- %reut)/100]

Para obtener la estimacion de esfuerzo sedebe calcular la tasa de ProductividadPROD = NPO/persona-mes

Una vez obtenida pasamos a estimar elesfuerzoEsfuerzo Estimado = NPO/PROD



La Ecuación del Software

Es un modelo multivariable

Supone una distribución especifica delesfuerzo a lo largo de la vida del proyecto

± E = [LDC * B0.333/P]3 * (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 habilidades P = Parámetro de productividad



TÉCNICAS DE

ESTIMACIÓNESPECIALIZADAS



Estimación Orientada a Objetos

Estimaciones en PF o LDC Aplicar el modelado de análisis

OO.

Determinar el numero de Clases

Clave Categorizar el tipo de interfaz para

la aplicación y desarrollar unmultiplicador

Multiplicar el numero total declases por el numero promedio deunidades de trabajo por clase.

Tipo de Interfaz Multiplicador

Sin GUI 2.0

Interfaz basadaen texto

2.25

GUI 2.25

GUI Compleja 3.0



Estimación para Desarrollo Ágil

Los requerimiento en este tipo de proyectosse presentan como un conjunto de escenariosde usuario.

Se puede estimar de manera mas informal.

Se usan los enfoques de LDC o PF orientados aescenarios



Los Expertos Dicen

Es mejor Comprender el trasfondo de unaestimación antes de utilizarla.



Estimación para Ingeniería Web

Los proyectos WEB adoptan el modelo de desarrolloágil

Se usa un enfoque de puntos de función modificado ± Entradas: Cada pantalla o formato de entrada incluidas las

de mantenimiento (CGI o JAVA) ± Salidas: Cada pagina Web estática, cada guion de pagina

Web dinámica y cada reporte (ASP, DHTML) ± Tablas: Cada tabla lógica en la DB y cada objeto XML ± Consultas: Cada interfaz publicada externamente

(referencias externas DCOM o COM) Los PF son un indicador razonable del volumen para

un WebApp



¿DESARROLLAR

O COMPRAR?



Árbol de Decisión

La organización tiene estas opciones:

1. Construir el Sistema desde 0

2. Reutilizar Componentes existentes de

experiencia parcial

3. Comprar un Producto disponible ymodificarlo.

4. Contratar una empresa externa para eldesarrollo.



Árbol de Decisión

Sistema X

Construir

Simple (0.30)

Difícil (0.70)

Reutilizar

CambiosMenores (0.40)

CambiosMayores (0.6)

Simple (0.2)

Complejo (0.8)

Comprar

CambiosMenores (0.70)

CambiosMayores (0.30)

Contratar

Sin Cambios(0.60)

Con Cambios(0.40)

$ 380000

$ 450000

$ 275000

$ 310000

$ 490000

$ 210000

$ 400000

$ 350000

$ 500000



Subcontratación

Es extremadamente simple.

Las actividades de ingeniería del software secontratan con una tercera parte que realiza eltrabajo a un costo mas bajo

Efecto negativo que la compañía pierde ciertocontrol sobre el software

Corre el riesgo de poner el destino de sucompetitividad en manos de una tercera parte



¿Cuáles son las claves del éxito?

Q: What are the most exciting/promising

software engineering ideas or techniques on

the horizon?

A: I dont think that the most promising ideas

are on the horizon. They are already here and

have been here for years but are not being

used properly. David L. Parnas



¿A qué se refiere Parnas?

PRÁCTICAS EN PLANIFICACIÓN GESTIÓN DE PROYECTOS Automated estimation tools (1973) Evolutionary delivery (1988) Measurement (1977) Productivity environments (1984) Risk management planning (1981)PRÁCTICAS EN INGENIERÍA DE REQUISITOS Change board (1979)

Throwaway user interface prototyping (1975) JAD sessions (1985) Requirements (1989)



CALENDARIZACIÓN



En que consiste la Calendarización

En crear una rede de tareas de ingeniería quele permitirán tener el trabajo listo a tiempo.

Una vez creada la red debe asignarresponsabilidades a cada tarea

Asegurarse que las tareas se realicen

Adaptar la red conforme los riesgos se vuelvanrealidad



¿Por qué es importante?

Construcción de un sistema complejo

Tareas de ingeniería ocurren en paralelo

Resultado de trabajo realizado durante unatarea pude tener un profundo efecto en eltrabajo llevado a cabo en otra tarea.

Interdependencia difíciles de entender sincalendarización



Calendarización Adecuada

Requiere:

Que todas las tareas aparezcan en la red

Esfuerzo y tiempo asignados inteligentemente

por tarea Interdependencias entre tareas indicadas

adecuadamente

Recursos asignados para el trabajo

Hitos espaciados de modo cercano para poderseguir el progreso



¿Por qué se entregan el software conretraso?

Fecha limite irrealizable establecida por externo eimpuesta

Cambio en los requisitos no reflejados enmodificaciones en la calendarización

Subestimación de la cantidad de esfuerzo y recursos

Riesgos no considerados (Predecibles y no Predecibles)

Dificultades humanas imprevisibles

Dificultades técnicas no previstas Falta de Comunicación entre el personal

Falla en la Gestión del Proyecto



Los Expertos dicen

Cualquier comandante en jefe que pretendalleva a cabo un plan que considera defectuosocomete un error; debe exponer sus razones,

insistir en que el plan debe cambiarse yfinalmente presentar su renuncia en lugar deser el instrumento de la destrucción de su

ejercito Napoleón



Adoro las Fechas limite. Me gustacuando pasan como una

exhalación cuando se alejan.Douglas Adams



Lo que no se debe hacer

Presentarse ante el cliente y demandarle quecambie la fecha de entrega impuesta por elmercado.

Rechazar el trabajo¿Que hacer? Estimación Detallada Aplicar un Modelo de proceso Incremental

Explicar al cliente por que la fecha es irrealizablecon la estimación detallada Funcionalidad faltante se entregara despues



Generalidades

Objetivo del gestor

± Definir tareas

± Construir la red de tareas

± Bosquejar las interdependencias entre las tareas ± Identificar las tareas cruciales y darles seguimiento

La calendarización evoluciona a lo largo del

tiempo. Una calendarización Macroscópica se realiza

durante las primeras etapas de la planificación



Generalidades

Cientos de tareas deben realizarse paracompletar la meta mayor

Algunas tareas se pueden completar sinpreocuparse de su impacto sobre la fecha determinación del proyecto



Principios Básicos de Calendarización

Compartimentación

Interdependencia

Asignación de Tiempo Validación del Esfuerzo

Definición de Responsabilidades

Definición de Resultados Definición de Hitos



Interdependencia

Algunas tareas deben ocurrir en secuencia

Otras pueden ocurrir en paralelo

Algunas tareas no pueden comenzar mientrasel producto de trabajo producido por otrastareas no este disponible



Asignación de Tiempo

A cada tarea se debe asignar cierto numero deunidades de trabajo (personas días deesfuerzo)

Asignar fecha de inicio y terminación enfunción de las interdependencias



Relación entre Personal y Esfuerzo

Mito: Si nos retrasamos en la calendarizaciónsiempre podemos incorporar mas programadoresy recuperarnos mas adelante en el proyecto.

Esto tiene un efecto perturbador en el equipo detrabajo

Provoca mas desfases

Las personas agregadas recientemente debenaprender el sistema y la gente que les enseña esla misma que estaba trabajando



Relación entre Personal y Esfuerzo

Las calendarizaciones de proyecto sonelásticas.

Es posible comprimir en cierta medida la fechade terminación deseada del proyecto (alañadir recursos adicionales).



Curva Putnam-Norden-Rayleigh (PNR)




Indica que un proyecto no se puedecomprimir mas allá de 0.75 td

Si se intenta mayor compresión el proyecto

cae en la región imposible y el riesgo defracaso se eleva mucho

La opcion de entrega de menor costo es ± t

o= 2t

d Esto implica que la demora en la entrega

puede reducir los costos significativamente




La ecuación del software se obtiene de la curvaPNR

Relación enormemente lineal entre el tiempo

cronológico para completar un proyecto y elesfuerzo humano aplicado a este.

L = P * E1/3t4/3

E = L3/(P3t4) es el esfuerzo humano en personas

año durante el ciclo de vida para el desarrollo T es el tiempo en años



Conclusiones de PNR

Se pueden obtener beneficios al emplearmenos personal durante un periodo un pocomas largo para lograr el mismo objetivo



Distribución del Esfuerzo

Regla 40-20-40

40% de todos los esfuerzos se asignan al análisis yel diseño de sistemas de entrada.

40% en poner a prueba los sistemas de salida 20% en codificación

Esta distribución de esfuerzo es solo una guía.

Las características del proyecto deben dictar ladistribución del esfuerzo.

Planeación = 2% 3%

10 CLAVES



10 CLAVESDE UN PROYECTO CON ÉXITO

Evitar los errores clásicos

No ignorar las bases del desarrollo

Gestión activa del riesgo Métodos de Planificación



PLANIFICACIÓN



Visión Clara del Proyecto

Sin una clara visión un proyecto puede terminar en cualquier punto.

Los equipos trabajan para lograr las metas que seles fijan.

Muchos Objetivos = no Objetivos Una buena visión establece prioridades¿Qué tipo de desarrollo rápido quiere?

Speed oriented Schedule-risk oriented Visibility oriented

Req isitos estables completos



Requisitos estables, completos yescritos



Los cambios en los requisitos

Riesgo más común en un proyecto

Requisitos estables al 100% es casi imposible

La mayoría de los cambios en los requisitosvienen de requisitos que definidos de formaincompleta la primera vez, y no por cambiosde mercado u otras razones similares.

Técnicas para definir Requisitos



Técnicas para definir Requisitosestables

Requirements workshop

User interface prototyping

User interview

Use cases

User manual

Usability studies

Incremental delivery Requirements reviews/inspections



Prototipos de Interfaz de Ususario

Técnica Orientada al riesgo más común en un

proyecto... El cambio en los requisitos

Implican a los usuarios de forma amigable

Bajo coste, corta planificación y altasatisfacción del usuario

Es necesario tener habilidad para desarrollar

prototipos exitosos



Gestión de Proyectos Efectiva

La pobre gestión planificación es el

segundo riesgo más común.

Responsabilidades de un Jefe de



Responsabilidades de un Jefe deProyecto

U na buena gestión software requiere(NECE SITA) significativas habilidades.

Estimación del Alcance

Análisis de Tiempo, Esfuerzo y Coste Selección del Ciclo de Vida

Planificación de la Calidad

Personal Técnico Gestión de Riesgos



Estimaciones Precisas

Las expectativas Injustificadas o no realistasson la mayor causa de los problemas

El estado del arte es dramáticamente mejorque el estado de la práctica



Exactitud de la Estimación y mejora

Resultados Reales como Porcentaje



Resultados Reales como Porcentajede

Resultados Estimados



Efecto de la Estimación



Estimación Precisa

La estimación es una habilidad técnica

especializada

Tratar la estimación como un mini proyecto

Tener un plan de reestimación periódica



No morir por la planificación

Evitar las dos causas de sobre planificación...

Planes inamovibles

Planes excesivamente detallados



Ajuste en la Planificación

Tiempo



Enfoque en la Calidad



¿Por qué centrarse en la calidad?

En la mayoría de los proyectos, el trabajo decorregir defectos no previstos es el mayorcoste (40 80 % del total)

Centrarnos en la calidad tiene un impacto

económico positivo

La calidad debe ser planificada durante el

proyecto, no puede añadirse al final

No olvidar las bases del desarrollo



No olvidar las bases del desarrollosoftware

Los f undamentos de Gestión

Siempre antes que los de Ingeniería

Estimación, Planificación, Seguimiento y

Medición Las Bases Técnicas

Requisitos, Diseño, Construcción, Gest.Configuración, etc.

Las Bases del Control de Calidad

Pruebas, Inspecciones, etc.



Gestión Activa de los Riesgos



Sobre la Gestión de Riesgos

Según un estudio de KPMG 55% de los proyectos descontrolados no tenían gestión de

riesgos

38% tenían algo, pero la mitad de estos no usó los riesgos

hallados una vez que el proyecto comenzó 7 % no sabe si utilizó gestión de riesgos

sobre un 80% de los proyectos comenzados no manteníanuna gestión de riesgos significativa

Más del 50% de los proyectos muestran sus problemas

durante el inicio del desarrollo Sobre el 25% muestran sus problemas durante la

planificación inicial



Gestión de Riesgos



i á ( i )



Riesgos más comunes (Best Hits)

Cambio en los Requisitos Meticulosidad en Requisitos o Desarrollo Escatimar en Calidad Planificaciones Demasiado Optimistas Diseño Inadecuado Síndrome de la "Bala de Plata Desarrollo Orientado a la Investigación

PersonalMediocre No definición de Roles y Responsables Error en la Contratación Diferencias entre Desarrolladores y Clientes Falta de Sponsor Falta de información del Usuario Añadir gente a un proyecto retrasado

Sobreestimar de nuevas herramientas o mé

todos Cambio de herramientas en mitad del proyecto Falta de control automatizado del código f uente

planificacion proyecto software

Documents