jueves, 17 de julio de 2008

Estimación para de Software

Fundamentos de Ingeniería de Software

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 software debe establecer un plan del proyecto que se defina las tareas y fechas claves de la ingeniería del software.

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, 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.

2 Desarrollo del tema

2.1 Observación acerca de la estimación

La estimación de recursos, costo y programa de trabajo para una tarea de ingeniería de software requiere experiencia, acceso a buena información histórica y el valos para comprometerse con predicciones cuantitativas cuando la información cualitativa es todo lo que existe. La estimación implica riesgo inherente, y esto conduce a la incertidumbre.

El riesgo de estimación se mide por el grado de incertidumbre en las estimaciones cuantitativas establecidad para recursos, costos y programa de trabajo, además el cliente debe reconocer que la variabilidad en los requisitos del software significa inestabilidad e costs y programa de trabajo.

Las estimaciones no deben obsecionarse en el plano de planificación, pues un cambio el gestor del proyecto debería reexaminar las estimaciones.

2.2 El proceso de planificación del proyectos

El objetiv de la planificación del proyecto de software es proporcionar un marco de trabajo que permita al gestor estimar recursos, costos y programa de trabajo.

2.3 Ámbito del Software y factibilidad

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:

• Despues de la comunicación con todos los participantes se desarrolla una descropción narrativa del ámbito del software.

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

2.4 Resursos

Los recursos son discutiblemente los pilares dentro del desarrollo del software, estos son: personal, componentes de software y entorno de desarrollo (Hardware y herramientas de desarrollo), se caracteriza el 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

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.

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

1 comentario:

Anónimo dijo...

Disculpa, tendrás un ejemplo explícito acerca de La Estimación Basada En El Proceso. Es que ya me quebré la cabeza y no encuentro nada. De verdad estaré agradecida si es que tuvieses algo al respecto.

Saludos.

Mi e-mail es:lulilani@hotmail.com