Stalin Rojas: Estimación para de Software Page 1 of 4

BUSCAR BLOG MARCAR BLOG Siguiente blog» Crear un blog | Acceder

Stalin Rojas
Creado a para compartir informacion

JUEVES 17 DE JULIO DE 2008

Estimación para de Software

Fundamentos de Ingeniería de Software Blogalaxia

Informe Ejecutivo

Stalin Rojas Morocho

Estimación para de Software

1 Introducción

El gestor de proyectos y el equipo del software deben estimar el trabajo

que se realizará, luego de realizarce estas actividades, el equipo de Personal
software debe establecer un plan del proyecto que se defina las tareas y
fechas claves de la ingeniería del software. sagfenix

Estas estimaciones se basab en datos de las métricas de software

recopiladas en proyectos previos.

La descripción del ámbito del producto da pie inicio, la complegidad y el

riesgo del problema se consideran antes de realizar una estimación final, http://sagfenix.hi5.com
es difícil asegurar si la estimación a sido correcta, pero se puede llegar a
cierto nivel de eficacia se se tiene experiencia y se sigue un enfoque
sistemático, que las estimaciones se basen en datos históricos sólidos. Ver todo mi perfil

2 Desarrollo del tema

2.1 Observación acerca de la estimación Archivo del blog

La estimación de recursos, costo y programa de trabajo para una tarea ▼ 2008 (8)
de ingeniería de software requiere experiencia, acceso a buena ▼ septiembre (1)
información histórica y el valos para comprometerse con predicciones
cuantitativas cuando la información cualitativa es todo lo que existe. La Combinaciones de Conocimineto
tácito y explicito
estimación implica riesgo inherente, y esto conduce a la incertidumbre.
► agosto (3)
El riesgo de estimación se mide por el grado de incertidumbre en las
estimaciones cuantitativas establecidad para recursos, costos y ► julio (2)
programa de trabajo, además el cliente debe reconocer que la
► abril (2)
variabilidad en los requisitos del software significa inestabilidad e costs y
programa de trabajo. ► 2007 (2)

Las estimaciones no deben obsecionarse en el plano de planificación,

pues un cambio el gestor del proyecto debería reexaminar las
estimaciones.
Technorati Widget

2.2 El proceso de planificación del proyectos Technorati authority

El objetiv de la planificación del proyecto de software es proporcionar un 0

marco de trabajo que permita al gestor estimar recursos, costos y
Search recent posts
programa de trabajo.

http://sagfenix.blogspot.com/2008/07/fundamentos-de-ingeniera-de-software.html 27/02/2009
Stalin Rojas: Estimación para de Software Page 2 of 4

2.3 Ámbito del Software y factibilidad

Technorati member
El ámbito del software describe las funciones y características que se
entregarán a los usuarios finales, se define al usar las dos técnicas: » Member profile
» Linking blogs
• Despues de la comunicación con todos los participantes se desarrolla Top tags
una descropción narrativa del ámbito del software.
There are no recent tags for this blog.

• Los usuarios finales desarrollan un conjunto de casos de uso. Blog reactions

There are no recent reactions to this blog.
2.4 Resursos
Favorites
Los recursos son discutiblemente los pilares dentro del desarrollo del No favorite blogs have been selected by
software, estos son: personal, componentes de software y entorno de sagfenix.
desarrollo (Hardware y herramientas de desarrollo), se caracteriza el Get this widget
recurso por descripción, informe de disponibilidad, urgencia del recurso,
tiempo de uso.

Recurso humano se describe como las personas involucradas en el

desarrollo del proyecto, en proyectos pequeños se usa una persona,
pero en el caso contrario de debe describir la ubicación de cada recurso
humano, los mismos que serán requeridos dependiendo de las
habilidades y el ámbito del producto, y su numero es determinado
después de la estimación.

Recursos de Software reutilizables se enfocan en que se deben

catalogarse, estandarizarse, y validarse, debido a su reutilización
inherente, pero se debe evaluar los requerimientos para optar por las
diversas alternativas de componentes existentes o realizar su creación.

Bennatan categoriza el recurso en:

• Componentes ya desarrollados, provienen de terceros o producidos

previamente, sin riesgo.

• Componentes experimentados, desarrollados en proyectos previos, los

miembros del equipo tienen la experiencia en la aplicación y modificaran
los componentes requeridos, bajo riesgo.

• Componentes de experiencia parcial, proviene de previos desarrollos,

pero el equipo es parcialmente experimentado en la aplicación y los
componentes deben ser modificados sustancialmente, riesgo alto.

• Componentes nuevos, se debe construir basado en la especificaciones

del proyecto actual.

Recursos del entorno llamado también entorno de ingeniería de software

(EIS), es en el cual se incorpora hardware y software indispensable para
el desarrollo del proyecto, por esta razón se debe planificar la
disponibilidad de los mismos.

2.5 Estimación de proyectos de software

La estimación del coste y el esfuerzo nunca será una ciencia exacta,

debido a demasiadas variables que afectan el costo final y el esfuerzo al
desarrollarlo, para ello se define una estimación con riesgo aceptable, y
se tiene 4 opciones:

• Demorar la estimación en el proyecto hasta tener cierta aceptación, no

es practica.

• Basar estimaciones de proyectos similares.

• Emplear técnicas de descomposición relativamente simples.

• Usar modelos empíricos.

2.6 Técnicas de descomposición

http://sagfenix.blogspot.com/2008/07/fundamentos-de-ingeniera-de-software.html 27/02/2009
Stalin Rojas: Estimación para de Software Page 3 of 4

Tamaño del software, la presión de la estimación en este aspecto se

manifiesta en varios factores: 1) grado de estimación del tamaño del
producto. 2) habilidad de emplear la estimación manifestándola en
esfuerzo humano, programa de trabajo y dinero. 3) grado de habilidad
del equipo de software dentro del proyecto, y 4) la estabilidad de los
requisitos del producto y el entorno que soporta el esfuerzo de ingeniería
de software.

Dependiendo del enfoque de representación del tamaño tenemos, el

directo que se puede medir en líneas de código (LDC), y si es indirecto,
como puntos de función (PF).

Putnam y Myers, sugieren con respecto al enfoque:

• Tamaño de “lógica difusa”, identificación de tipo de aplicación,

magnitud en la escala cualitativa y refine la magnitud dentro del rango
original.

• Tamaño de punto de función, estimación de las características del

dominio.

• Tamaño de componentes estándar, estimar las ocurrencias de cada

componente estándar y contrastar con datos previos de similares
componentes estándar definiendo el tamaño.

• Tamaño del cambio, cuando se reutiliza componentes de previos

proyectos se estima el número y tipo de las modificaciones a realizar.

Estimaciones basadas en el problema, las LDC y PF son utilizados de

dos formas al estimar el proyecto: como una variable de estimación para
el tamaño de cada elemento de software y como métricas de línea base
recolectadas a partir de proyectos previos y utilizados en conjunción con
variables de estimación para desarrollar proyecciones de costo y
esfuerzo.

Se puede dividir el problema para estimar las diversas partes del

proyecto de una mejor forma.

Estimación basada en el proceso, se descompone el proceso en un

conjunto relativamente pequeño de tareas y se estima el esfuerzo para
cada tarea, parte del bosquejo de funcionalidades a partir del ámbito del
proyecto, estas se contraponen con las actividades del proceso.

Estimación con casos de uso, tiene sus complicaciones:

Los casos de uso tienen muchos formatos y estilos.

• Representan la visión externa y difieren en sus grados de abstracción.

• No reflejan la complejidad de las funciones ni sus características.

• No describen el comportamiento complejo de funciones y

características.

2.7 Modelos Empíricos de estimación

La estructura global de tales modelos toma la forma:

E=A+B*(e_{y})^{c}

El modelo COCOMO II

Abordan las áreas siguientes:

Modelo de composición de la aplicación.

Modelo de etapas de diseño temprano.

http://sagfenix.blogspot.com/2008/07/fundamentos-de-ingeniera-de-software.html 27/02/2009
Stalin Rojas: Estimación para de Software Page 4 of 4

Además, hay disponibles tres opciones diferentes de tamaño: puntos

objeto, puntos de función y líneas de código.

2.8 La decisión desarrollar-comprar

Los gestores de ingeniería del software enfrentan una decisión de

desarrollar-comprar, se puede complicar por su licencia, experiencia en
el campo de aplicación sea parcial o completa, o se puede construir de
forma personalizada, todo esta decisión está en torno de los análisis de
costos para un mejor desenvolvimiento de los desarrolladores
Publicado por sagfenix en 13:22
Etiquetas: Informes

0 comentarios:

Publicar un comentario en la entrada

Entrada más reciente Página principal Entradas antiguas

Suscribirse a: Enviar comentarios (Atom)

http://sagfenix.blogspot.com/2008/07/fundamentos-de-ingeniera-de-software.html 27/02/2009