Stalin Rojas: Estimación para de Software
BUSCAR BLOG
MARCAR BLOG
Page 1 of 4
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 software debe establecer un plan del proyecto que se defina las tareas y fechas claves de la ingeniería del software.
Personal 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, 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.
http://sagfenix.hi5.com Ver todo mi perfil
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.
Archivo del blog ▼ 2008 (8) ▼ septiembre (1) Combinaciones de Conocimineto tácito y explicito ► agosto (3) ► julio (2) ► abril (2) ► 2007 (2)
Technorati Widget Technorati authority
0 Search recent posts
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 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.
Technorati member » Member profile » Linking blogs Top tags There are no recent tags for this blog.
• Los usuarios finales desarrollan un conjunto de casos de uso. 2.4 Resursos
Blog reactions There are no recent reactions to this blog.
Favorites
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.
No favorite blogs have been selected by sagfenix.
Get this widget
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