Planificacin de Proyectos de Software

Ivn Snchez Ronald Senz Gissellor Karen Navarro Muoz Andrea Estrella Katichula Megan Fox

El Comienzo
En el principio se pidieron los proyectos de Software. Los proyectos estaban desordenados y vacos, y las tinieblas estaban sobre la haz del abismo, y el Espritu de Dios se mova sobre este mar de Caos. Y dijo Dios: Sea la Planificacin: y fue la Planificacin. Y vio Dios que la Planificacin era buena: y apart Dios la Planificacin del desorden

Introduccin
Antes de comenzar se debe estimar
Esfuerzo, tiempo, personal y dems 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 bajo costo. La experiencia dice que el proyecto promedio gasta 80 por ciento de su tiempo en reelaboracin: corrigiendo errores que se cometieron en etapas tempranas del proyecto.

Objetivos
Proporcionar un Marco de Trabajo que permita al gestor estimar razonablemente los recursos, costo y programa de trabajo. Adaptar y actualizar el plan conforme se avance en el proyecto.

Actividades
La planificacin del proyecto del software abarca 5 grandes actividades: Estimacin Programa de Trabajo Anlisis de Riesgos Planificacin de la Gestin de Calidad Planificacin de la Gestin del Cambio

Los expertos dicen

Nuestras tcnicas de estimacin estn pobremente desarrolladas. Mas seriamente, reflejan una suposicin no expresada que es bastante incierta, es decir: que todo ira bien
Frederick Brooks, 1975

La Estimacin
No necesita realizarse en una forma improvisada. La experiencia es una gran ayuda. La estimacin implica riesgo inherente, y este conduce a la incertidumbre. El riesgo de la estimacin se mide por el grado de incertidumbre en las estimaciones cuantitativas para recursos, costos y programa de trabajo.

La Estimacin
Variabilidad en requisitos = inestabilidad Un gestor no debe obsesionarse con las estimaciones.

Conjunto de Tareas para la Planificacin de un Proyecto

Establecer el mbito del proyecto. Determinar Factibilidad Analizar Riesgos. Definir los recursos requeridos (humanos, software, etc). Estimar costo y Esfuerzo
Descomponer el problema Desarrollar 2 o mas estimaciones (Ej: puntos de funcin, casos de uso, etc)

Desarrollar un Plan de Proyecto

Establecer un conjunto de tareas significativo. Definir una red de tareas. Desarrollar un cronograma con Herramientas de Planificacin Definir mecanismos de seguimiento del programa de trabajo.

Ambito del Software

Describe:
Funciones Caractersticas Entradas Salidas Contenido a Presentar Desempeo Restricciones Interfaces

Confiabilidad a entregar al Usuario final.

Ambito del Software

Divide y Vencers
Muchas veces es bueno refinar. Las estimaciones de costo y el programa de trabajo estn funcionalmente orientadas, por eso es til cierto grado de descomposicin.

Factibilidad
Cuatro elementos esenciales: Tecnologa Finanzas Tiempo Recursos

Recursos
Divididos en Tres Grandes Categoras: Personal Componentes de Software Reutilizables Entorno

La Trinidad
Personal

Proyecto
Software Reutilizable Entorno

Recursos Humanos
El planificador debe especificar:
Habilidades Requeridas Posicin Organizacional Especialidad

El personal puede estar Geogrficamente disperso.

Recursos de Software Reutilizables

Ingeniera de Software basada en Componentes. nfasis en la reutilizacin 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)

Estimacin
Un gran error en la estimacin puede hacer la diferencia entre Ganancia o Perdida.

Mala Estimacin

Desastre para el Desarrollador

Estimacin
Nunca es exacta Mientras mas se conozca menos errores serios se cometern. Implica muchas variables
Humanas Tcnicas Ambientales Polticas etc

Como lograr estimaciones Confiables?

Basarse en proyectos similares

Descomposicin Simple

Uso de Modelos Empricos

Estimacin
Usar Datos Histricos

Tcnicas de Descomposicin
El problema a resolver es muy complejo para considerarlo una sola pieza Descomponer el problema en problemas mas pequeos Hacer el problema mas MANEJABLE

Tamao del Software

El grado con el cual se ha estimado adecuadamente el tamao

Habilidad para traducir estimacin en esfuerzo humano, cronograma y Dinero

Grado en el que la planificacin refleja las habilidades del equipo de Software

Estimacin Basada en el Problema

Mtricas basadas en la Productividad LDC/pm PF/pm Combinaciones

Estimacin Basada en el Problema

Estimacin
Mas Probable Valor Esperado

Optimista

Pesimista

Estimacin basada en LDC

Descomposicin funcional absolutamente esencial considerables niveles de detalle LDC se estima directamente.

Ejemplo

Estimacin basada en PF
Los datos requeridos para estimar los Puntos de Funcin son ms macroscpicos que en LDC. Nivel de descomposicin considerablemente menos detallado que en LDC. PF se determina indirectamente mediante la estimacin del nmero de entradas, salidas, archivos de datos, peticiones e interfaces externas, entre otras.

Ejemplo

LDC o PF Esperados
A partir de los datos histricos o (cuando todo lo dems falla) usando su intuicin, el planificador estima los valores optimista, ms probable y pesimista de LDC o de PF para cada funcin. Cuando lo que se especifica es un rango de valores, implcitamente se proporciona una indicacin del grado de incertidumbre. Entonces, se calcula el valor esperado de LDC o de PF. El valor esperado para la variable de estimacin, E, se obtiene como una medida ponderada de las estimaciones LDC o PF ptima (a), ms probable (m) y pesimista (b).

Estimacin basada en el Proceso

Tcnica ms habitual El proceso se descompone en actividades o tareas y el esfuerzo requerido para llevar a cabo cada tarea Se presentan las tareas en forma de tabla

Pasos de la Estimacin basada en el Proceso

delimitar las funciones obtenidas a partir del mbito del software actividades del proceso para cada funcin estimacin de esfuerzo (persona-mes) para cada actividad en cada funcin aplicacin de ndices de trabajo medios (esfuerzo coste/unidad) al esfuerzo estimado para cada actividad clculo de costes y esfuerzo de cada funcin y de la actividad

Ejemplo

Estimacin basada en Casos de Uso

Permiten que el equipo de software comprenda mejor el mbito y los requisitos. El uso de casos de uso es a veces problemtico porque:
no existe un formato estndar. Representan una visin externa con diferentes grados de abstraccin No abordan la complejidad de las funciones ni de las caractersticas

Los expertos recomiendan no usar mas de 10 casos de Uso con no mas de 30 escenarios

Metodologa General a Usar con Estimacin de Casos de Uso

Cmo Estimar usando Casos de Uso?

Reconciliacin de Estimaciones
La estimacion por LDC, PF y basadas en el proceso se realizan independientemente. Cuando se tienen algunas estimaciones de costo y esfuerzo se pueden comparar y armonizar. Si tienen un buen grado de concordancia son confiables las estimaciones. Si son poco concordantes los resultados de las estimaciones, entonces se debe investigar y analizar mejor

Tcnicas Delfi
Desarrolladas con el fin de obtener el consenso de un grupo de expertos sin contar con los efectos negativos de las reuniones de grupos. La tcnica puede adaptarse a la estimacin de costos de la siguiente manera: Un coordinador proporciona a cada experto la documentacin con la definicin del sistema y una papeleta para que escriba su estimacin. Cada experto estudia la definicin y determina su estimacin en forma annima; 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 extrao efectuado por alguno de los expertos. Los expertos realizan una segunda ronda de estimaciones, otra vez annimamente, utilizando los resultados de la estimacin anterior. En los casos que una estimacin difiera mucho de las dems, se podr solicitar que tambin en forma annima el experto justifique su estimacin. El proceso se repite varias veces como se juzgue necesario, impidiendo una discusin grupal durante el proceso.

Modelos Empricos de Estimacin

Modelos empricos de estimacin: Utilizan frmulas derivadas empricamente para predecir el esfuerzo como una funcin de LDC o PF. Datos empricos obtenidos de una muestra de proyectos:
difciles de usar para todas las clases de software y todos los entornos de desarrollo se deben calibrar para las condiciones especficas de una organizacin

Ecuaciones de los Modelos Empiricos

Observaciones
Se nota claramente que cada uno de los modelos (ecuaciones) producira un resultado diferente para los mismos valores de LDC o PF. Los modelos deben CALIBRARSE para las necesidades locales

Cocomo
El Modelo Constructivo de Costos (COnstructive COst Model) es una jerarqua de modelos de estimacin para el software. Las ecuaciones del modelo COCOMO bsico tienen la siguiente forma: 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 cronolgicos y KLDC es el nmero estimado de Lneas de Cdigo distribudas (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 nmero estimado de Lneas de Cdigo distribudas para el proyecto.

Jerarquas de Cocomo
El modelo COCOMO bsico es un modelo univariable esttico que calcula el esfuerzo (y el costo) del desarrollo de software en funcin del tamao del programa expresando en lneas de cdigo (LDC) estimadas. El modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software en funcin del tamao del programa y de un conjunto de conductores de costo, que incluyen la evaluacin subjetiva del producto, del hardware, del personal y de los atributos del proyecto. El modelo COCOMO avanzado incorpora todas las caractersticas de la versin intermedia y lleva a cabo una evaluacin de impacto de los conductores de costo en cada fase (anlisis, diseo, etc.) del proceso de ingeniera de software.

Cocomo Orientado a los Tipos de proyecto de software

Modelo Orgnico. Proyectos de software relativamente pequeos y sencillos en los que trabajan pequeos equipos, con buena experiencia en la aplicacin, sobre el conjunto de requisitos poco rgidos (por ejemplo, un programa de anlisis termal desarrollado para un grupo calrico). Modelo Semiacoplado. Proyectos de software intermedios (en tamao y complejidad) en los que los equipos, con variados niveles de experiencia, deben satisfacer requisitos poco o medio rgidos (por ejemplo, un sistema de procesamiento de transacciones con requisitos fijos para un hardware de terminal o un software de gestin de base de datos). Modelo Empotrado. Proyectos de software que deben ser desarrollados en un conjunto de hardware, software y restricciones operativas muy restringidas (por ejemplo, software de control de navegacin para un avin).

Cocomo Ejemplo
El chino lo pondra en esta diapo

COCOMO II
Es una Evolucin del COCOMO original propuesto por Boehm Aborda las siguientes reas:
Modelo de composicin de la aplicacin Modelo de la etapa de diseo temprano Modelo de etapa posterior a la arquitectura

Tres opciones de Tamao:

Puntos de Funcion PF Lineas de Codigo Fuente LDC Puntos Objeto PO

Puntos Objeto
Son una manera indirecta de calcular el tamao del software por medio de conteo de:
Pantallas de interfaz de usuario Reportes Componente requeridos para las construccin de la aplicacin.

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 la cuenta de PO
NPO = (PO) * [(100- %reut)/100]

Para obtener la estimacion de esfuerzo se debe calcular la tasa de Productividad

PROD = NPO/persona-mes

Una vez obtenida pasamos a estimar el esfuerzo

Esfuerzo Estimado = NPO/PROD

La Ecuacin del Software

Es un modelo multivariable Supone una distribucin especifica del esfuerzo a lo largo de la vida del proyecto E = [LDC * B0.333/P]3 * (1/t4)
E = Esfuerzo en Personas-mes o Personas-ao T = duracin del proyecto en meses o aos B = Factor especial de habilidades P = Parmetro de productividad

TCNICAS DE ESTIMACIN ESPECIALIZADAS

Estimacin Orientada a Objetos

Estimaciones en PF o LDC Aplicar el modelado de anlisis OO. Determinar el numero de Clases Clave Categorizar el tipo de interfaz para la aplicacin y desarrollar un multiplicador Multiplicar el numero total de clases por el numero promedio de unidades de trabajo por clase.

Tipo de Interfaz Sin GUI Interfaz basada en texto GUI GUI Compleja

Multiplicador 2.0 2.25 2.25 3.0

Estimacin para Desarrollo gil

Los requerimiento en este tipo de proyectos se presentan como un conjunto de escenarios de usuario. Se puede estimar de manera mas informal. Se usan los enfoques de LDC o PF orientados a escenarios

Los Expertos Dicen

Es mejor Comprender el trasfondo de una estimacin antes de utilizarla.

Estimacin para Ingeniera Web

Los proyectos WEB adoptan el modelo de desarrollo gil Se usa un enfoque de puntos de funcin modificado
Entradas: Cada pantalla o formato de entrada incluidas las de mantenimiento (CGI o JAVA) Salidas: Cada pagina Web esttica, cada guion de pagina Web dinmica y cada reporte (ASP, DHTML) Tablas: Cada tabla lgica 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 Decisin
La organizacin tiene estas opciones: 1. Construir el Sistema desde 0 2. Reutilizar Componentes existentes de experiencia parcial 3. Comprar un Producto disponible y modificarlo. 4. Contratar una empresa externa para el desarrollo.

rbol de Decisin
Simple (0.30)

$ 380000 $ 450000 $ 275000

Simple (0.2)

Construir
Difcil (0.70) Cambios Menores (0.40) Reutilizar Cambios Mayores (0.6) Sistema X Cambios Menores (0.70) Comprar Cambios Mayores (0.30) Sin Cambios (0.60) Contratar Con Cambios (0.40) Complejo (0.8)

$ 310000 $ 490000

$ 210000 $ 400000 $ 350000 $ 500000

Subcontratacin
Es extremadamente simple. Las actividades de ingeniera del software se contratan con una tercera parte que realiza el trabajo a un costo mas bajo Efecto negativo que la compaa pierde cierto control sobre el software Corre el riesgo de poner el destino de su competitividad en manos de una tercera parte

Cules 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?
PRCTICAS EN PLANIFICACIN GESTIN DE PROYECTOS Automated estimation tools (1973) Evolutionary delivery (1988) Measurement (1977) Productivity environments (1984) Risk management planning (1981) PRCTICAS EN INGENIERA DE REQUISITOS Change board (1979) Throwaway user interface prototyping (1975) JAD sessions (1985) Requirements (1989)

CALENDARIZACIN

En que consiste la Calendarizacin

En crear una rede de tareas de ingeniera que le permitirn tener el trabajo listo a tiempo. Una vez creada la red debe asignar responsabilidades a cada tarea Asegurarse que las tareas se realicen Adaptar la red conforme los riesgos se vuelvan realidad

Por qu es importante?
Construccin de un sistema complejo Tareas de ingeniera ocurren en paralelo Resultado de trabajo realizado durante una tarea pude tener un profundo efecto en el trabajo llevado a cabo en otra tarea. Interdependencia difciles de entender sin calendarizacin

Calendarizacin 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 poder seguir el progreso

Por qu se entregan el software con retraso?

Fecha limite irrealizable establecida por externo e impuesta Cambio en los requisitos no reflejados en modificaciones en la calendarizacin Subestimacin de la cantidad de esfuerzo y recursos Riesgos no considerados (Predecibles y no Predecibles) Dificultades humanas imprevisibles Dificultades tcnicas no previstas Falta de Comunicacin entre el personal Falla en la Gestin del Proyecto

Los Expertos dicen

Cualquier comandante en jefe que pretenda lleva a cabo un plan que considera defectuoso comete un error; debe exponer sus razones, insistir en que el plan debe cambiarse y finalmente presentar su renuncia en lugar de ser el instrumento de la destruccin de su ejercito
Napolen

Adoro las Fechas limite. Me gusta cuando pasan como una exhalacin cuando se alejan.
Douglas Adams

Lo que no se debe hacer

Presentarse ante el cliente y demandarle que cambie la fecha de entrega impuesta por el mercado. Rechazar el trabajo Que hacer? Estimacin Detallada Aplicar un Modelo de proceso Incremental Explicar al cliente por que la fecha es irrealizable con la estimacin 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 calendarizacin evoluciona a lo largo del tiempo. Una calendarizacin Macroscpica se realiza durante las primeras etapas de la planificacin

Generalidades
Cientos de tareas deben realizarse para completar la meta mayor Algunas tareas se pueden completar sin preocuparse de su impacto sobre la fecha de terminacin del proyecto

Principios Bsicos de Calendarizacin

Compartimentacin Interdependencia Asignacin de Tiempo Validacin del Esfuerzo Definicin de Responsabilidades Definicin de Resultados Definicin de Hitos

Interdependencia
Algunas tareas deben ocurrir en secuencia Otras pueden ocurrir en paralelo Algunas tareas no pueden comenzar mientras el producto de trabajo producido por otras tareas no este disponible

Asignacin de Tiempo
A cada tarea se debe asignar cierto numero de unidades de trabajo (personas das de esfuerzo) Asignar fecha de inicio y terminacin en funcin de las interdependencias

Relacin entre Personal y Esfuerzo

Mito: Si nos retrasamos en la calendarizacin siempre podemos incorporar mas programadores y recuperarnos mas adelante en el proyecto. Esto tiene un efecto perturbador en el equipo de trabajo Provoca mas desfases Las personas agregadas recientemente deben aprender el sistema y la gente que les ensea es la misma que estaba trabajando

Relacin entre Personal y Esfuerzo

Las calendarizaciones de proyecto son elsticas. Es posible comprimir en cierta medida la fecha de terminacin deseada del proyecto (al aadir recursos adicionales).

Curva Putnam-Norden-Rayleigh (PNR)

Curva Putnam-Norden-Rayleigh (PNR)

Indica que un proyecto no se puede comprimir mas all de 0.75 td Si se intenta mayor compresin el proyecto cae en la regin imposible y el riesgo de fracaso se eleva mucho La opcion de entrega de menor costo es
to = 2td

Esto implica que la demora en la entrega puede reducir los costos significativamente

Curva Putnam-Norden-Rayleigh (PNR)

La ecuacin del software se obtiene de la curva PNR Relacin enormemente lineal entre el tiempo cronolgico para completar un proyecto y el esfuerzo humano aplicado a este. L = P * E1/3t4/3 E = L3/(P3t4) es el esfuerzo humano en personas ao durante el ciclo de vida para el desarrollo T es el tiempo en aos

Conclusiones de PNR
Se pueden obtener beneficios al emplear menos personal durante un periodo un poco mas largo para lograr el mismo objetivo

Distribucin del Esfuerzo

Regla 40-20-40 40% de todos los esfuerzos se asignan al anlisis y el diseo de sistemas de entrada. 40% en poner a prueba los sistemas de salida 20% en codificacin Esta distribucin de esfuerzo es solo una gua. Las caractersticas del proyecto deben dictar la distribucin del esfuerzo. Planeacin = 2% 3%

10 CLAVES DE UN PROYECTO CON XITO

Evitar los errores clsicos No ignorar las bases del desarrollo Gestin activa del riesgo Mtodos de Planificacin

PLANIFICACIN

Visin Clara del Proyecto

Sin una clara visin un proyecto puede terminar en cualquier punto. Los equipos trabajan para lograr las metas que se les fijan. Muchos Objetivos = no Objetivos Una buena visin establece prioridades Qu tipo de desarrollo rpido quiere? Speed oriented Schedule-risk oriented Visibility oriented

Requisitos estables, completos y escritos

Los cambios en los requisitos

Riesgo ms comn en un proyecto Requisitos estables al 100% es casi imposible La mayora de los cambios en los requisitos vienen de requisitos que definidos de forma incompleta la primera vez, y no por cambios de mercado u otras razones similares.

Tcnicas para definir Requisitos estables

Requirements workshop User interface prototyping User interview Use cases User manual Usability studies Incremental delivery Requirements reviews/inspections

Prototipos de Interfaz de Ususario

Tcnica Orientada al riesgo ms comn en un proyecto... El cambio en los requisitos Implican a los usuarios de forma amigable Bajo coste, corta planificacin y alta satisfaccin del usuario Es necesario tener habilidad para desarrollar prototipos exitosos

Gestin de Proyectos Efectiva

La pobre gestin planificacin es el segundo riesgo ms comn.

Responsabilidades de un Jefe de Proyecto

Una buena gestin software requiere (NECESITA) significativas habilidades. Estimacin del Alcance Anlisis de Tiempo, Esfuerzo y Coste Seleccin del Ciclo de Vida Planificacin de la Calidad Personal Tcnico Gestin de Riesgos

Estimaciones Precisas
Las expectativas Injustificadas o no realistas son la mayor causa de los problemas El estado del arte es dramticamente mejor que el estado de la prctica

Exactitud de la Estimacin y mejora

Resultados Reales como Porcentaje de Resultados Estimados

Efecto de la Estimacin

Estimacin Precisa
La estimacin es una habilidad tcnica especializada Tratar la estimacin como un mini proyecto Tener un plan de reestimacin peridica

No morir por la planificacin

Evitar las dos causas de sobre planificacin... Planes inamovibles Planes excesivamente detallados

Ajuste en la Planificacin

Tiempo

Enfoque en la Calidad

Por qu centrarse en la calidad?

En la mayora de los proyectos, el trabajo de corregir defectos no previstos es el mayor coste (40 80 % del total) Centrarnos en la calidad tiene un impacto econmico positivo La calidad debe ser planificada durante el proyecto, no puede aadirse al final

No olvidar las bases del desarrollo software

Los fundamentos de Gestin Siempre antes que los de Ingeniera Estimacin, Planificacin, Seguimiento y Medicin Las Bases Tcnicas Requisitos, Diseo, Construccin, Gest. Configuracin, etc. Las Bases del Control de Calidad Pruebas, Inspecciones, etc.

Gestin Activa de los Riesgos

Sobre la Gestin de Riesgos

Segn un estudio de KPMG 55% de los proyectos descontrolados no tenan gestin de riesgos 38% tenan algo, pero la mitad de estos no us los riesgos hallados una vez que el proyecto comenz 7% no sabe si utiliz gestin de riesgos sobre un 80% de los proyectos comenzados no mantenan una gestin de riesgos significativa Ms del 50% de los proyectos muestran sus problemas durante el inicio del desarrollo Sobre el 25% muestran sus problemas durante la planificacin inicial

Gestin de Riesgos

Riesgos ms comunes (Best Hits)

Cambio en los Requisitos Meticulosidad en Requisitos o Desarrollo Escatimar en Calidad Planificaciones Demasiado Optimistas Diseo Inadecuado Sndrome de la "Bala de Plata Desarrollo Orientado a la Investigacin Personal Mediocre No definicin de Roles y Responsables Error en la Contratacin Diferencias entre Desarrolladores y Clientes Falta de Sponsor Falta de informacin del Usuario Aadir gente a un proyecto retrasado Sobreestimar de nuevas herramientas o mtodos Cambio de herramientas en mitad del proyecto Falta de control automatizado del cdigo fuente

El Factor Humano
Seguir Desarrollando

IEEE Std 830-1998

Indica como realizar un documento de especificacin de requisitos de software (SRS). Establecer las bases para el acuerdo de lo que el software realizar entre clientes y proveedores. Reducir el esfuerzo de desarrollo. Proveer las bases para estimar el costo y calendarios. Proveer lneas base para validacin y verificacin Sirve de base para realizar mejoras.

De aqu en Adelante son diapos que no se si van a ir en la presentacion final

Por qu Planificar?
Boehm, 1975: 45% de los errores tienen su origen en los requisitos y en el diseo preliminar. DeMarco, 1984: 56% de los errores que tienen lugar en un proyecto software se deben a una mala especificacin de requisitos. Chaos Report, 1995: Los factores principales que conducen al fracaso en los proyectos software son: Falta de comunicacin con los usuarios. Requisitos incompletos. Cambios a los requisitos.

Es lo Mismo?

Estimacin basada en Casos de Uso

La construccin de software es human-intensive. Software es intangible. El software depende del hardware y de otro software. Ms y ms sistemas son actualmente controlados por software. Una de las partes ms crticas de un proyecto informtico es averiguar lo que costara desarrollarlo.