Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

ESTIMACIÓN PARA PROYECTOS DE SOFTWARE

No description
by

yineth torres

on 24 April 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of ESTIMACIÓN PARA PROYECTOS DE SOFTWARE

EL PROCESO DE PLANIFICACIÓN DEL PROYECTO
OBSERVACIONES ACERCA DE LAS ESTIMACIONES

ESTIMACIÓN DE PROYECTOS DE SOFTWARE
1. Retrase la estimación hasta avanzado el proyecto (obviamente, ¡puede lograr estimaciones 100 por ciento precisas después de que el proyecto esté completo).
2. Base las estimaciones en proyectos similares que ya estén completos.
3. Use técnicas de descomposición relativamente simples para generar estimaciones de costo y esfuerzo de proyecto.
4. Use uno o más modelos empíricos para estimación de costo y esfuerzo de software.

d =f (v)
d= es uno de los valores estimados (por ejemplo, esfuerzo, costo, duración del proyecto)
v= es uno de los valores estimados (por ejemplo, esfuerzo, costo, duración del proyecto)

“divide y vencerás"
ESTIMACIÓN PARA PROYECTOS ORIENTADOS A OBJETOS

El objetivo de la planificación del proyecto de software es proporcionar un marco conceptual que permita al gerente hacer estimaciones razonables de recursos, costo y calendario. Además, las estimaciones deben intentar definir los escenarios de mejor caso y peor caso, de modo que los resultados del proyecto puedan acotarse
1. Desarrollar estimaciones usando descomposición de esfuerzo, análisis PF y cualquier otro método que sea aplicable para aplicaciones convencionales.
2. Usar el modelo de requisitos , desarrollar casos de uso y determinar un conteo. Reconocer que el número de casos de uso puede cambiar conforme avance el proyecto.
3. A partir del modelo de requisitos, determinar el número de clases clave .
4. Categorizar el tipo de interfaz para la aplicación y desarrollar un multiplicador para clases de apoyo
TÉCNICAS DE DESCOMPOSICIÓN

desarrollar una estimación de costo y esfuerzo para un proyecto de software es muy complejo como para considerarse en una sola pieza. Por esta razón, debe descomponerse el problema y volver a caracterizarlo como un conjunto de problemas más pequeños (y, esperanzadoramente, más manejables).
ESTIMACIÓN PARA PROYECTOS DE SOFTWARE

QUE ES?
es un conjunto de actividades que de manera colectiva se llaman planificación de proyecto.
estimación
calendarización
análisis de riesgos
planificación de gestión de la calidad
planificación de gestión del cambio.

La planificación requiere adoptar un compromiso inicial, aun cuando es probable que este “compromiso” resulte erróneo. Siempre que se hacen estimaciones se mira hacia el futuro y se acepta cierto grado de incertidumbre habitual. En palabras de Frederick Brooks .
La estimación porta un riesgo inherente, éste conduce a incertidumbre.
La complejidad del proyecto
Tiene un fuerte efecto sobre la incertidumbre inherente a la planificación
Es una medida relativa que es afectada por la familiaridad con el esfuerzo pasado. El profesional que por primera vez desarrolla una sofisticada aplicación de comercio electrónico puede considerarla excesivamente compleja.
grado de incertidumbre estructural
Al grado en el cual se solidificaron los requisitos, la facilidad con la que se dividieron las funciones y la naturaleza jerárquica de la información que debe procesarse.
El riesgo de estimación se mide por el grado de incertidumbre en las estimaciones cuantitativas establecidas para recursos, costo y calendario.
tamaño del proyecto
Otro factor importante que puede afectar la precisión y la eficacia de las estimaciones. Conforme aumenta el tamaño, la interdependencia entre varios elementos del software crece rápidamente.
Para parafrasear la ley de Murphy: “lo que puede salir mal, saldrá mal”, y si hay más cosas que pueden fallar, más cosas fallarán.
CONJUNTO DE TAREAS PARA PLANIFICAR UN PROYECTO
Establecer ámbito del proyecto
Determinar la factibilidad.
Analizar los riesgos
Definir recursos requeridos
a) Determinar recursos humanos requeridos.
b) Definir recursos de software reutilizables.
c) Identificar recursos ambientales.
Estimar costo y esfuerzo.
a) Descomponer el problema.
b) desarrollar dos o más estimaciones usando tamaño, puntos de función, tareas de proceso o casos de uso.
c) Reconciliar las estimaciones.
Desarrollar un calendario del proyecto
a) Establecer un conjunto de tareas significativas.
b) Definir una red de tareas.
c) U sar herramientas de calendarización para desarrollar un cronograma.
d) Definir mecanismos de seguimiento de calendario.

ÁMBITO Y FACTIBILIDAD DEL SOFTWARE
Describe las funciones y características que se entregan a los usuarios finales; los datos que son entrada y salida; el “contenido” que se presenta a los usuarios como consecuencia de usar el software y el desempeño, las restricciones, las interfaces y la confiabilidad que se ligan al sistema.

RECURSOS

Es la estimación de los recursos requeridos para lograr el esfuerzo de desarrollo del software
TECNICAS
1. Una descripción narrativa del ámbito del software se desarrolla después
de la comunicación con todos los participantes.
2. Los usuarios finales desarrollan un conjunto de casos de uso.

Recursos humanos

Número
Habilidades
Ubicación.
Recursos de software reutilizables
Componentes COTS Componentes comerciales.
Componentes nuevos: Son componentes de software que el equipo de software debe construir específicamente para las necesidades del proyecto en cuestión.
Componentes de experiencia completa : Son especificaciones, diseños, código o datos de prueba existentes, desarrollados para proyectos anteriores que se relacionan con el software que se va a construir para el proyecto en cuestión, pero que requerirán modificación sustancial.
Componentes de experiencia parcial:Son especificaciones, diseños, código o datos de prueba existentes, desarrollados para proyectos anteriores que son similares al software que se va a construir para el proyecto en cuestión
entorno de ingeniería de software
(EIS)
Herramientas de software
Ubicación Recursos de red
Hardware: proporciona una plataforma que soporta las herramientas (software) requeridas para producir los productos operativos
Dimensionamiento del software
Estimación con casos de uso
Los casos de uso se describen usando muchos formatos y estilos diferentes; no existe una forma estándar.
Los casos de uso representan una visión externa (la visión del usuario) del software y, por tanto, pueden escribirse en muchos niveles de abstracción diferentes.
Los casos de uso no abordan la complejidad de las funciones y de las características que se describen.
Los casos de uso pueden describir comportamiento complejo (por ejemplo, interacciones) que involucran muchas funciones y características.
Smith [Smi99] sugiere que los casos de uso pueden usarse para estimación, pero sólo si se consideran dentro del contexto de la “jerarquía estructural” donde se usan para describir.
se establece el nivel dentro de la jerarquía estructural, se determina la longitud promedio (en páginas) de cada caso de uso, se define el tipo de software (por ejemplo, tiempo real, empresarial, ingeniería/científico, webapp, incrustado) y se considera una arquitectura burda para el sistema.

Estimación basada en problema
Las estimaciones LOC y PF son técnicas de estimación distintas, aunque ambas tienen algunas características en común
Cuando se usa LOC como la variable de estimación, la descomposición es absolutamente esencial y con frecuencia lleva a considerables niveles de detalle. Mientras mayor sea el grado de partición, es más probable que puedan desarrollarse estimaciones de LOC razonablemente precisas.
la descomposición funciona de modo diferente. En lugar de enfocarse en la función, se estima cada una de las características del dominio de información (entradas, salidas, archivos de datos, consultas e interfaces externas)
Estimación basada en proceso
El proceso se descompone en un conjunto relativamente pequeño de tareas y se estima el esfuerzo requerido para lograr cada tarea.o comienza con un delineado de las funciones para cada función debe realizarse una serie de actividades de marco conceptual.
Una vez fusionadas las funciones del problema y las actividades de proceso, se estima el esfuerzo (por ejemplo, persona-mes) que se requerirá para lograr cada actividad, Las tarifas de mano de obra promedio (es decir, esfuerzo costo/unidad


MODELOS DE ESTIMACIÓN EMPÍRICOS

Un modelo de estimación para software de computadora usa fórmulas empíricamente inferidas para predecir el esfuerzo como una función de LOC o PF.
Reconciliación de estimaciones
El esfuerzo total estimado para el software varía de uno bajo de 46 persona-meses (inferido con el enfoque de estimación basado en proceso) a uno alto de 68 persona-meses (inferido con estimación de caso de uso). La estimación promedio (usando los cuatro enfoques) es de 56 persona-meses. La variación de la estimación promedio es aproximadamente 18 por ciento en el lado bajo y 21 por ciento en el alto.
La precisión de una estimación de proyecto de software se basa en algunas cosas:
1) el grado en el que se estimó adecuadamente el tamaño del producto que se va a construir
2) la habilidad para traducir la estimación de tamaño en esfuerzo humano, tiempo calendario y dinero.
3) el grado en el que el plan del proyecto refleja las habilidades del equipo de software
4) la estabilidad de los requisitos del producto y el entorno que soporta el esfuerzo de ingeniería de software.
dimensionamiento del software
En el contexto de la planificación del software, el tamaño se refiere a un resultado cuantificable del proyecto de software. Si se toma un enfoque directo, el tamaño puede medirse en líneas de código (LOC). Si se elige un enfoque indirecto, el tamaño se representa como puntos de función (PF).
cuatro enfoques diferentes para el problema
de dimensionamiento:






Dimensionamiento de “lógica difusa”
: Para aplicar este enfoque, el planificador debe identificar el tipo de aplicación, establecer su magnitud en una escala cualitativa y luego refinar la magnitud dentro del rango original.
Dimensionamiento del punto de función:
El planificador desarrolla estimaciones de las características del dominio de información.
Dimensionamiento de componente estándar:
los componentes estándares para un sistema de información son subsistemas, módulos, pantallas, reportes, programas interactivos, programas en lote, archivos, LOC e instrucciones en el nivel objeto. El planificador del proyecto estima el número de ocurrencias de cada componente estándar y luego usa datos de proyecto históricos para estimar el tamaño entregado por componente estándar.
Dimensionamiento del cambio:
Este enfoque se usa cuando un proyecto abarca el uso de software existente que debe modificarse en alguna forma como parte de un proyecto. El planificador estima el número y tipo (por ejemplo, reuso, código agregado, cambio de código, código borrado) de las modificaciones que deben lograrse.


La estructura de los modelos de estimación
Un modelo de estimación típico se infiere usando análisis de regresión sobre los datos recopilados de proyectos de software anteriores. La estructura global de tales modelos toma la forma
E = A + B * (ev)C
donde A, B y C son constantes derivadas empíricamente, E es esfuerzo en persona-meses y ev es la variable de estimación (LOC o PF)
El modelo COCOMO II
COnstructive COst MOdel: modelo constructivo de costos.
Modelo de composición de aplicación:Se usa durante las primeras etapas de la ingeniería de software, en nterfaces de usuario, en la interacción del software y el sistema, la valoración del rendimiento y la evaluación de la madurez de la tecnología.
• Modelo de etapa temprana de diseño: Se usa una vez estabilizados los requisitos y establecida la arquitectura básica del software.
• Modelo de etapa postarquitectónica. Se usa durante la construcción del software.
La ecuación del software
es un modelo dinámico multivariable que supone una distribución de esfuerzo específica durante la vida de un proyecto de desarrollo de software
E =LOC * B0.333 = 1 t4
P3
E =esfuerzo en persona-meses o persona-años
t = duración del proyecto en meses o años
B =“factor de habilidades especiales”13
P = “parámetro de productividad”

TÉCNICAS DE ESTIMACIÓN ESPECIALIZADAS
Cuando un equipo de software encuentra una duración de proyecto extremadamente corta (semanas en lugar de meses).
Enfoque de descomposición que abarca los siguientes pasos:
1. Un minicaso de uso creado al comienzo mismo de un proyecto por los usuarios finales . se considera por separado con propósitos de estimación.
2. El escenario se descompone en el conjunto de tareas de ingeniería de software que será necesario desarrollar.
*El esfuerzo requerido por cada tarea se estima por separado
*De manera alternativa, el “volumen” del escenario puede estimarse en LOC, PF o alguna otra medida orientada a volumen (por ejemplo, conteo de casos de uso).
*Las estimaciones para cada tarea se suman a fin de crear una estimación para el escenario.
*De manera alternativa, la estimación de volumen para el escenario se traduce en esfuerzo, usando datos históricos.
Las estimaciones de esfuerzo para todos los escenarios que se implementan para un incremento de software determinado se suman a fin de desarrollar la estimación del esfuerzo para el incremento.


Estimación para webapp
Entradas son cada pantalla o formulario de entrada (por ejemplo, CGI o Java).
Salidas son cada página web estática, cada guión de página web dinámica (por ejemplo, ASP, ISAPI u otro guión DHTML).
Tablas son cada tabla lógica en la base de datos más, si usa XML para almacenar datos en un archivo, cada objeto XML.
Las interfaces conservan su definición como archivos lógicos (por ejemplo, formatos de registro único).
Consultas son cada una de las publicaciones externas o el uso de una interfaz orientada a mensaje.

Desicion hacer?
comprar?
1) el software puede comprarse (o licenciarse) de manera comercial.
2) los componentes de software de “experiencia completa” o “experiencia parcial” pueden adquirirse y luego modificarse e integrarse para satisfacer necesidades específicas
3) el software puede construirse a la medida por parte de un contratista externo para satisfacer las especificaciones del comprador.
1) ¿La fecha de entrega del producto de software será más próxima que la del software que se desarrolle internamente?
2) ¿El costo de adquisición más el costo de personalización será menor que el costo que implica desarrollar el software internamente?
3) ¿El costo del apoyo exterior (por ejemplo, un contrato de mantenimiento) será menor que el costo del apoyo interno? Estas condiciones se aplican para cada una de las opciones de adquisición.

Creación de un árbol de decisión
aumentar usando técnicas estadísticas como el análisis de árbol de decisión.
Siguiendo otras rutas del árbol de decisión, también se muestran los costos proyectos para reúso, compra y contrato, bajo varias circunstancias.
Outsourcing
Es la ( subcontratación) extremadamente simple. Las actividades de ingeniería de software se contratan a una tercera parte, que hace el trabajo a un costo más bajo y, con un poco de suerte, con mayor calidad.
Puede ser estratégica o táctica
En el lado positivo, el ahorro en costo usualmente puede lograrse reduciendo el número de personal de software y las instalaciones.
GRACIAS .....
condiciones
Full transcript