Está en la página 1de 7

INGENIERIA EN VIDEOJUEGOS

ESTIMACIÓN DE COSTOS Y ESFUERZO

ASIGNATURA:
Metodología del desarrollo de software

ELABORADO POR:
José Carlos García León

GRADO y GRUPO:
IVI5A

Morelia, Michoacán, 29 de noviembre del 2022


Modelos algorítmicos WALSTON – FELIX
Algo de lo que debemos estar contemplando es que las estimaciones que hagamos nunca
serán del todo exactas ya que esto es en gran parte culpa de la cantidad tan grande que se
maneja al momento de estar realizando los calculos. Pero como bien sabemos, cuanto
mejor sea la estimación con mayor facilidad podremos mejorar la rentabilidad del proyecto.

Estimar conlleva una gran dificultad ya que los requisitos iniciales no están totalmente
delimitados, puede que necesitemos utilizar tecnologías nuevas o las personas que se
encuentran involucradas en el proyecto pueden tener distintos grados de experiencia.

La estimación para un proyecto software necesita:


 Experiencia.
 Buena información histórica.
 Confianza en las métricas y la experiencia.
Entre los factores que afectan a la estimacion son:
 Complejidad del proyecto.
 Facilidad de identificar funciones.
 Disponibilidad de información histórica.
 Tamaño del proyecto.

Estimación de recursos
Los recursos pueden estimarse como personas, componentes software reutilizables y las
herramientas de hardware/softwares necesarios para realizar el proyecto.
Cada recurso se especifica con cuatro características (las dos últimas se denominan ventana
temporal):
 Descripción.
 Informe de disponibilidad.
 Fecha cronológica en la que se requiere.
 Tiempo durante el que será aplicado.
 Respecto al personal hay que especificar su posición en la organización y su
especialidad.
Los componentes software, por su parte, pueden estar:
 Ya desarrollados.
 Ya experimentados.
 Con experiencia parcial.
 Nuevos.
COCOMO
El modelo COCOMO original está compuesto de tres modelos:
 Básico: Calcula el esfuerzo en función del tamaño estimado (KLDC).
 Intermedio: Calcula el esfuerzo en función del tamaño estimado y de “conductores
de coste”. Los conductores de coste evalúan un conjunto de atributos del producto,
del hardware, del personal y del proyecto.
 Avanzado: Modificación del modelo intermedio para considerar el impacto de los
conductores de coste en cada fase del proyecto.

Estos tres modelos se definen para tres tipos de proyectos:


Modo orgánico: proyectos pequeños y medianos, bastante experiencia, con pocas
restricciones, realizado por equipos pequeños, entorno familiar.
Modo semiacoplado: proyectos intermedios en tamaño y complejidad, varios niveles de
experiencia.
Modo empotrado: proyectos complejos y muy restrictivos. Proyectos innovadores.
Desarrollados dentro de un conjunto estricto de hardware, de software y restricciones
operativas.

COCOMO
Barry Boehm en su libro sobre “Economía de la Ingeniería del Software”, menciona una
escala de modelos de estimación de software con el nombre de COCOMO(Construcive Cost
Model). La escala de modelos de Boehm incluye:

Modelo 1. El modelo COCOMO básico calcula el esfuerzo (y el costo) del desarrollo de


software en función del tamaño del programa, expresado en las líneas estimadas de código.

Modelo 2, El modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software en


función del tamaño del programa y de un conjunto de “conductores de costo” que incluyen
la evaluación subjetiva del producto, del hardware, del personal y de los atributos del
proyecto.

Modelo 3, El modelo COCOMO avanzado incorpora todas las características de la versión


intermedia y lleva a cabo una evaluación del impacto de los conductores de costo en cada
fase del transcurso de ingeniería del software.

Los modelos COCOMO están establecidos para tres prototipos de proyectos de software
que empleando la terminología de Boehm son:
Modo orgánico: aquellos proyectos de software que son respectivamente pequeños y
sencillos en donde trabajan pequeños equipos que poseen buena experiencia en la
aplicación, sobre un conjunto de requisitos poco rígidos.

Modo semiacoplado: son los proyectos de software intermedios hablando de tamaño y


complejidad, en donde los equipos tienen diversos niveles de experiencia, y además deben
satisfacer requerimientos poco o medio rígidos.

Modo empotrado: son proyectos de software que deben ser desarrollados en un conjunto
de hardware, software y restricciones operativas muy restringido.

Las ecuaciones del COCOMO básico tienen la siguiente forma:

COCOMO 2
COCOMO II permite realizar estimaciones en función del tamaño del software, y de un
conjunto de factores de coste y de escala.
En los factores de coste se incluyen aspectos relacionados con la naturaleza del sistema,
equipo, y características propias del proyecto.
Los factores de escala incluyen la parte de escala producida a medida que un proyecto de
software incrementa su tamaño.

COCOMO II posee tres modelos:


 Composición de Aplicación
 Diseño Temprano
 Post-Arquitectura.

Cada uno de estos modelos está orientado a sectores específicos del mercado de desarrollo
de software y a las distintas etapas del desarrollo de software.
La sectorización de aplicaciones en COCOMO II es esta:
 Aplicaciones desarrolladas por Usuarios Finales: En este sector se encuentran las
aplicaciones generadas directamente por usuarios finales, mediante la utilización
de generadores de aplicaciones tales como hojas de cálculo, sistemas de consultas,
etc. Estas aplicaciones surgen debido al uso masivo de estas herramientas,
conjuntamente con la presión actual para obtener soluciones rápidas y flexibles.
 Generadores de Aplicaciones: En este sector están los módulos pre-empaquetados
que serán usados por usuarios finales y programadores.
 Aplicaciones con Componentes: Sector en el que se están aquellas aplicaciones que
se resuelven por soluciones preempaquetadas, pero son lo suficientemente simples
para ser construidas a partir de componentes interoperables. Por ejemplo:
interfaces gráficos, administradores de bases de datos, buscadores inteligentes de
datos. Estas aplicaciones son generadas por un equipo reducido de personas, en
pocas semanas o meses.
 Sistemas Integrados: Sistemas de gran escala, con un alto grado de integración entre
sus componentes, sin antecedentes en el mercado que se puedan tomar como base.
Partes de estos sistemas pueden ser desarrolladas a través de la composición de
aplicaciones.

Los modelos de COCOMO II se adaptan tanto a los sectores descritos como al tipo y cantidad
de información disponible.
 El modelo Composición de Aplicación se emplea en desarrollos de software durante
la etapa de prototipado.
 El modelo Diseño Temprano se utiliza en las primeras etapas del desarrollo en las
cuales se evalúan las alternativas de hardware y software de un proyecto. En estas
etapas se tiene poca información, lo que concuerda con el uso de Puntos Función,
para estimar tamaño y el uso de un número reducido de factores de coste.
 El modelo Post-Arquitectura se aplica en la etapa de desarrollo, después de definir
la arquitectura del sistema, y en la etapa de mantenimiento

Modelos de estimación
En la estimación del tamaño de software COCOMO II utiliza tres técnicas:
 Puntos Objeto,
 Puntos Función No Ajustados y
 Líneas de Código Fuente.

Análisis de puntos de función


El Análisis de Puntos de Función es una técnica de medición de las funciones ofrecidas por
el software desde el punto de vista de sus usuarios.
El punto de Funciónes su unidad de medida. Por lo tanto, pretende representar una
cantidad; en este caso, medición independiente de la tecnología utilizada para construir el
software.

El Análisis de puntos de función mide lo que el software hace, independiente como fue
construido. Por lo tanto, el proceso de medición o de conteo de puntos de función es basado
en la evaluación de los requerimientos funcionales del usuario, como se describe en los
artefactos de desarrollo.
Es importante destacas que los puntos de función no miden directamente el esfuerzo,
productividad y costo, porque ella produce una medida de tamaño funcional de software.
Sin embargo, a partir del tamaño funcional correlacionado con otras variables, se torna
posible identificar productividad, estimar esfuerzo y/o costo de proyectos de software.

PUTNAM
Creado por Lawrence Putnam, Sr., el modelo de Putnam describe el tiempo y el esfuerzo
necesarios para finalizar un proyecto de software de tamaño específico. SLIM (Software
Lifecycle Management) es el nombre que Putnam le da al conjunto de herramientas
propietario que su empresa QSM, Inc. ha desarrollado en base a su modelo. Es uno de los
primeros de este tipo de modelos desarrollados y se encuentra entre los más utilizados.

Mientras administraba proyectos de R&D para el ejército y más tarde en GE, Putnam notó
que los perfiles de personal de software seguían la conocida distribución de Rayleigh.
Putnam usó sus observaciones sobre los niveles de productividad para derivar la ecuación
del software:

Dónde:
El tamaño es el tamaño del producto (cualquiera que sea la estimación de tamaño utilizada
por su organización es adecuada). Putnam utiliza ESLOC (Líneas de código fuente efectivas)
en todos sus libros.
 B es un factor de escala y es una función del tamaño del proyecto.
 La productividad es la productividad del proceso, la capacidad de una organización
de software particular para producir software de un tamaño dado a una tasa de
defectos particular.
 El esfuerzo es el esfuerzo total aplicado al proyecto en años-persona.
 El tiempo es el cronograma total del proyecto en años.
En el uso práctico, cuando se hace una estimación para una tarea de software, la ecuación
del software se resuelve para el esfuerzo:
Bibliografía
Gracia, L. (2012, 7 febrero). Modelos de estimación: un poco sobre COCOMO II. Un poco de
Java. https://unpocodejava.com/2012/02/07/modelos-de-estimacion-un-poco-sobre-
cocomo-ii/
Wikipedia contributors. (2021, 29 julio). Putnam model. Wikipedia.
https://en.wikipedia.org/wiki/Putnam_model
Estimación de proyectos software - Wikiversidad. (s. f.).
https://es.wikiversity.org/wiki/Estimaci%C3%B3n_de_proyectos_software

También podría gustarte