Orientadas al Tamaño
El modelo COCOMO se basa en la existencia de tres niveles que ha de aplicarse según el estado en que se encuentre el desarrollo del proyecto.
Estos tres niveles son:
1. Modelo básico
2. Modelo intermedio
3. Modelo detallado
La función básica que utilizan los tres modelos es:
donde:
E= a(Kl)b * m(X)
a y b: Son constantes con valores definidos en cada sub-modelo
Kl o KLOC: Es la cantidad de líneas de código excluyendo comentarios, en miles.
m(X): Es un multiplicador que depende de 15 atributos.
El resultado se da en unidades salario/mes y horas-hombre.
cada sub-modelo también se divide en modos de trabajo que representan el tipo de
proyecto, y puede ser:
1. Modo orgánico: un pequeño grupo de programadores experimentados desarrollan software en un entorno familiar. El tamaño del software varía desde unos pocos miles de líneas (tamaño pequeño) a unas decenas de miles (medio).
2. Modo Semilibre o Semiencajado: corresponde a un esquema intermedio entre el orgánico y el rígido; el grupo de desarrollo puede incluir una mezcla de personas experimentadas y no experimentadas.
3. Modo Rígido o Empotrado: el proyecto tiene fuertes restricciones, que pueden estar relacionadas con la funcionalidad y/o pueden ser técnicas. El problema a resolver es único y es difícil basarse en la experiencia, puesto que puede no haberla.
Nivel Básico
Se utiliza para obtener una primera aproximación rápida del esfuerzo. Y hace uso de la siguiente tabla de constantes para calcular distintos aspectos de costes:
Modo | a | b | c | d |
Orgánico | 2.4 | 1.05 | 2.5 | 0.38 |
Semiacoplado | 3.0 | 1.12 | 2.5 | 0.35 |
Integrado | 3.6 | 1.20 | 2.5 | 0.32 |
Estos valores son para las fórmulas:
1. Personas necesarias por mes para llevar adelante el proyecto (MM) = a*(Klb)
2. Tiempo de desarrollo del proyecto (TDEV) = c*(MMd)
3. Personas necesarias para realizar el proyecto (CosteH) = MM/TDEV
4. Costo total del proyecto (CosteM) = CosteH * Salario medio entre los programadores y analistas.
NOTA: El valor de m(x) en el caso del modelo básico tiene como valor fijo la unidad.
Para calcular el número de meses estimados para el desarrollo, utilizamos la siguiente fórmula:
T= cEd
Donde:
E: Es el valor del esfuerzo calculado en la anterior ecuación.
c y d: Son valores constantes que dependen de la clase o “modo” de proyecto que estemos evaluando.
Nivel Intermedio
En este caso la ecuación de esfuerzo que rige este modelo es:
E= a(KLOC)b m(x)
Donde E, KLOC, a y b tienen el mismo significado que en caso del modelo básico, aunque el valor de a y b es diferente.
La tabla para los valores de las constantes de las ecuaciones de esfuerzo (E) para este “modo” de proyecto es:
Modo | a | b |
Orgánico | 3.2 | 1.05 |
Semiacoplado | 3.0 | 1.12 |
Integrado | 2.8 | 1.20 |
El valor de m(x) es el peso del factor de coste X j , y cuya expresión matemática es:
15
M(x)= П m(x j)
j=1
Cada factor es valorado por separado en una escala ordinal de seis puntos (muy bajo / bajo/ nominal / alta / muy alta / extra alta)
Atributos | Muy Bajo | Bajo | Nominal | Alto | Muy Alto | Extra Alto |
Atributos de Software
Fiabilidad | 0,75 | 0,88 | 1,00 | 1,15 | 1,40 | |
Tamaño BD | 0,94 | 1,00 | 1,08 | 1,16 | ||
Complejidad | 0,70 | 0,85 | 1,00 | 1,15 | 1,30 | 1,65 |
Atributos de Hardware
Restricción tiempo de ejecución | 1,00 | 1,11 | 1,30 | 1,66 | ||
Restricción de Memoria Virtual | 1,00 | 1,06 | 1,21 | 1,56 | ||
Volatilidad de la MV | 0,87 | 1,00 | 1,15 | 1,30 | ||
Tiempo de Respuesta | 0,87 | 1,00 | 1,07 | 1,15 |
Atributos del personal
Capacidad Análisis | 1,96 | 1,19 | 1,00 | 0,86 | 0,71 | |
Experiencia en la Aplicación | 1,29 | 1,13 | 1,00 | 0,91 | 0,82 | |
Calidad de los Programadores | 1,42 | 1,17 | 1,00 | 0,86 | 0,70 | |
Experiencia en la Máquina Virtual | 1,21 | 1,10 | 1,00 | 0,90 | ||
Experiencia en el Lenguaje | 1,14 | 1,07 | 1,00 | 0,95 |
Atributos del Proyecto
Técnicas actualizadas de Programación | 1,24 | 1,10 | 1,00 | 0,91 | 0,82 | |
Utilización de Herramientas de Software | 1,24 | 1,10 | 1,00 | 0,91 | 0,83 | |
Restricciones del tiempo de desarrollo | 1,23 | 1,08 | 1,00 | 1,04 | 1,10 |
COCOMO II
Los objetivos principales que se tuvieron en cuenta para construir el modelo COCOMO II fueron:
· Desarrollar un modelo de estimación de costo y cronograma de proyectos de software que se adaptara tanto a las prácticas de desarrollo de la década del 90 como a las futuras.
· Construir una base de datos de proyectos de software que permitiera la calibración
continua del modelo, y así incrementar la precisión en la estimación.
· Implementar una herramienta de software que soportara el modelo.
· Proveer un marco analítico cuantitativo y un conjunto de herramientas y técnicas que evaluaran el impacto de las mejoras tecnológicas de software sobre los costos y tiempos en las diferentes etapas del ciclo de vida de desarrollo.
COCOMO II está compuesto por tres modelos denominados:
1. Composición de Aplicación.
2. Diseño Temprano.
3. Post-Arquitectura.
Distribución del Mercado de Software Actual y Futuro
Aplicaciones desarrolladas por usuarios finales | ||
Generadores de Aplicaciones | Aplicaciones con Componentes | Sistemas Integrados |
Infraestructura | ||
· Aplicaciones desarrolladas por Usuarios Finales: En este sector se encuentran las aplicaciones de procesamiento de información generadas directamente por usuarios finales, mediante la utilización de generadores de aplicaciones tales como planillas de cálculo, sistemas de consultas. 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 operan firmas como Lotus, Microsoft, Novell, Borland con el objetivo de crear módulos pre-empaquetados que serán usados por usuarios finales y programadores.
· Aplicaciones con Componentes: Sector en el que se encuentran aquellas aplicaciones que son específicas para ser resueltas por soluciones pre-empaquetadas, pero son lo suficientemente simples para ser construidas a partir de componentes interoperables. Componentes típicas son constructores de interfases gráficas, administradores de bases de datos, buscadores inteligentes de datos, componentes de dominio-específico (medicina, finanzas, procesos industriales, etc.). 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. Estos sistemas pueden ser desarrolladas a través de la composición de aplicaciones. Entre las empresas que desarrollan software representativo de este sector, se encuentran grandes firmas que desarrollan software de telecomunicaciones, sistemas de información corporativos, sistemas de control de fabricación, etc.
· Infraestructura: Área que comprende el desarrollo de sistemas operativos, protocolos de redes, sistemas administradores de bases de datos, etc. Incrementalmente este sector direccionará sus soluciones, hacia problemas genéricos de procesamiento distribuido y procesamiento de transacciones, a soluciones middleware. Firmas representativas son: Microsoft, Oracle, SyBase, Novell y NeXT.
·
Los tres modelos de COCOMO II se adaptan tanto a las necesidades de los diferentes
sectores descriptos, como al tipo y cantidad de información disponible en cada etapa del ciclo de vida de desarrollo, lo que se conoce por granularidad de la información.
Se puede afirmar que para las aplicaciones desarrolladas por usuarios finales no se justifica la utilización de un modelo de estimación de costos. Estas aplicaciones normalmente se construyen en poco tiempo, por lo tanto requieren solamente una estimación basada en actividades.
El modelo Composición de Aplicación: Es el modelo de estimación utilizado en los proyectos de software que se construyen a partir de componentes pre-empaquetadas. En este caso, se emplean
Puntos Objeto para estimar el tamaño del software, lo cual está acorde al nivel de información que generalmente se tiene en la etapa de planificación, y el nivel de precisión requerido en la estimación de proyectos de esta naturaleza. Para los demás sectores del mercado se aplica un modelo mixto, combinación de los tres modelos.
El modelo Composición de Aplicación: Se emplea en desarrollos de software durante la etapa de prototipación.
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ón6, para estimar tamaño y el uso de un número reducido de factores de costo.
El modelo Post-Arquitectura: Se aplica en la etapa de desarrollo propiamente dicho, después
que se define la arquitectura del sistema, y en la etapa de mantenimiento. Este modelo utiliza:
· Puntos Función y/o Líneas de Código Fuente7 para estimar tamaño, con modificadores que contemplan el reuso, con y sin traducción automática, y el "desperdicio".
· Un conjunto de 17 atributos, denominados factores de costo9, que permiten considerar características del proyecto referentes al personal, plataforma de desarrollo, etc., que tienen injerencia en los costos.
· Cinco factores que determinan un exponente, que incorpora al modelo el concepto de deseconomía y economía de escala. Estos factores reemplazan los modos Orgánico, Semiacoplado y Empotrado del modelo COCOMO '81.
Estimación del Esfuerzo
El esfuerzo necesario para concretar un proyecto de desarrollo de software, cualquiera sea el modelo empleado, se expresa en meses/persona (PM) y representa los meses de trabajo de una persona fulltime, requeridos para desarrollar el proyecto.
Modelo Composición de Aplicación
La fórmula propuesta en este modelo es la siguiente:
PM = NOP / PROD
Donde:
NOP (Nuevos Puntos Objeto): Tamaño del nuevo software a desarrollar expresado en
Puntos Objeto y se calcula de la siguiente manera:
NOP = OP x (100 - %reuso)/100
OP (Puntos Objeto): Tamaño del software a desarrollar expresado en Puntos Objeto
%reuso: Porcentaje de reuso que se espera lograr en el proyecto
PROD: Es la productividad promedio determinada a partir del análisis de datos de
Proyectos.
Experiencia y capacidad de los desarrolladores | Muy Bajo | Bajo | Normal | Alto | Muy Alto |
Madurez y Capacidad del ICASE | Muy Bajo | Bajo | Normal | Alto | Muy Alto |
PROD | 4 | 7 | 13 | 25 | 50 |
Modelo Diseño Temprano
Este modelo se usa en las etapas tempranas de un proyecto de software, cuando se conoce
muy poco del tamaño del producto a ser desarrollado, de la naturaleza de la plataforma, del
personal a ser incorporado al proyecto o detalles específicos del proceso a utilizar. Este modelo
podría emplearse tanto en productos desarrollados en sectores de Generadores de Aplicación,
Sistemas Integrados o Infraestructura.
El modelo de Diseño Temprano ajusta el esfuerzo nominal usando siete factores de costo. La
fórmula para el cálculo del esfuerzo es la siguiente:
7
PMestimado=PMnominal*П EM i
i=1
PMnominal=A*(KSLOC) B
5
B= 1.01+0.01ΣWj
j=1
Donde:
· PMEstimado es el esfuerzo Nominal ajustado por 7 factores, que reflejan otros aspectos propios del proyecto que afectan al esfuerzo necesario para la ejecución del mismo.
· KSLOC es el tamaño del software a desarrollar expresado en miles de líneas de código fuente.
· A es una constante que captura los efectos lineales sobre el esfuerzo de acuerdo a la variación del tamaño, (A=2.94).
· B es el factor exponencial de escala, toma en cuenta las características relacionadas con las economías y deseconomías de escala producidas cuando un proyecto de software incrementa su tamaño.
· EMi corresponde a los factores de costo que tienen un efecto multiplicativo sobre el esfuerzo, llamados Multiplicadores de Esfuerzo (Effort Multipliers). Cada factor se puede clasificar en seis niveles diferentes que expresan el impacto del multiplicador sobre el esfuerzo de desarrollo. Esta escala varía desde un nivel Extra Bajo hasta un nivel Extra Alto. Cada nivel tiene un peso asociado. El peso promedio o nominal es 1.0. Si el factor provoca un efecto nocivo en el esfuerzo de un proyecto, el valor del multiplicador correspondiente será mayor que 1.0, caso contrario el multiplicador será inferior a 1.0. Clasificados en categorías, los 7 Multiplicadores de Esfuerzo son: Del Producto
· RCPX: Confiabilidad y Complejidad del producto.
· RUSE: Reusabilidad Requerida De la Plataforma.
· PDIF: Dificultad de la Plataforma Del Personal.
· PERS: Aptitud del Personal.
· PREX: Experiencia del Personal Del Proyecto.
· FCIL: Facilidades.
· SCED: Cronograma de Desarrollo Requerido
Modelo Post-Arquitectura
Es el modelo de estimación más detallado y se aplica cuando la arquitectura del proyecto está completamente definida. Este modelo se aplica durante el desarrollo y mantenimiento de productos de software incluidos en las áreas de Sistemas Integrados, Infraestructura y Generadores de Aplicaciones. El esfuerzo nominal se ajusta usando 17 factores multiplicadores de esfuerzo. El mayor número de multiplicadores permite analizar con más exactitud el conocimiento disponible en las últimas etapas de desarrollo, ajustando el modelo de tal forma que refleje fielmente el producto de software bajo desarrollo. La fórmula para el cálculo del esfuerzo es la siguiente:
17
PMestimado= PMnominal*ПEM i
i=1
Métricas de Software COCOMO II
En la estimación del tamaño de software COCOMO II utiliza tres técnicas:
· Puntos Objeto.
· Puntos Función No Ajustados.
· Líneas de Código Fuente.
Además se emplean otros parámetros relativos al tamaño que contemplan aspectos tales como:
· Reuso.
· Reingeniería.
· Conversión.
· Mantenimiento.
Puntos Objeto
A pesar de que la estimación a través de Puntos Objeto es un enfoque de medición de tamaño de software relativamente nuevo, es apropiado para las aplicaciones con componentes y para estimar esfuerzos en las etapas de prototipación.
Puntos Función
El modelo COCOMO II usa Puntos Función y/o Líneas de Código Fuente (SLOC) como base para medir tamaño en los modelos de estimación de Diseño Temprano y Post Arquitectura
Los Puntos Función procuran cuantificar la funcionalidad de un sistema de software. La meta es obtener un número que caracterice completamente al sistema. Son útiles estimadores ya que están basados en información que está disponible en las etapas tempranas del ciclo de vida del desarrollo de software. COCOMO II considera solamente UFP (Puntos Función no ajustados).
FP = UFP x TCF
Donde UFP: Puntos Función no Ajustados
TCF: Factor de Complejidad Técnica
Para calcular los UFP, se deben identificar los siguientes tipos de ítems:
· Entradas Externas (Inputs): Entrada de datos del usuario o de control que ingresan desde el exterior del sistema para agregar y/o cambiar datos a un archivo lógico interno.
· Salidas Externas (Outputs): Salida de datos de usuario o de control que deja el límite del sistema de software.
· Archivo Lógicos Internos (Archivos): Incluye cada archivo lógico, es decir cada grupo lógico de datos que es generado, usado, o mantenido por el sistema de software.
· Archivos Externos de Interfase (Interfases): Archivos transferidos o compartidos entre sistemas de software.
· Solicitudes Externas (Queries): Combinación única de entrada-salida, donde una entrada causa y genera una salida inmediata, como un tipo de solicitud externa.
Una vez identificados los ítems se clasifican de acuerdo al grado de complejidad en: bajo, promedio o alto. Se asigna un peso a cada ítem según el tipo y el grado de complejidad
correspondiente. Finalmente los UFP son calculados mediante la sumatoria de los pesos de todos los ítems identificados.
15
UFP=Σ (cantidad_items_Tipo i )*(Peso i )
i=1
Metricas Orientadas a la Función
Son medidas indirectas del software y del proceso por el cual se desarrolla. En lugar de calcularlas las LDC, las métricas orientadas a la función se centran en la funcionalidad o utilidad del programa. Las métricas orientadas a la función fueron el principio propuestas por Albercht quien sugirió un acercamiento a la medida de la productividad denominado método del punto de función. Los puntos de función que obtienen utilizando una función empírica basando en medidas cuantitativas del dominio de información del software y valoraciones subjetivos de la complejidad.
Parámetro Medición | Cuenta | Simple | Medio | Complejo |
Num entradas usuario | x | 3 | 4 | 6 |
Num salidas usuario | x | 4 | 5 | 7 |
Num Peticiones usuario | x | 3 | 4 | 6 |
Num Archivo | x | 7 | 10 | 15 |
Num Interfaces Externa | x | 5 | 7 | 10 |
Cuenta=Total |
Se determinan 5 características del ámbito de la información y los cálculos aparecen en la
posición apropiada de la tabla. Los valores del ámbito de información están definidos de la
siguiente manera.
1. Números de entrada de usuario: se cuenta cada entrada del usuario que proporcione al
software diferentes datos orientados a la aplicación. Las entradas deben ser distinguidas
de las peticiones que se contabilizan por separado.
2. Número de salida del usuario: se encuentra cada salida que proporciona la usuario
información orientada a la aplicación. En este contexto las salidas se refieren a informes,
pantalla, mensajes de error. Los elementos de datos individuales dentro de un informe
se encuentran por separado.
3. Números de peticiones al usuario: una petición está definida como una entrada
interactiva que resulta de la generación de algún tipo de respuesta en forma de salida
interactiva. Se cuenta cada petición por separado.
4. Numero de archivos: se cuenta cada archivo maestro lógico, o sea una agrupación
lógica de datos que puede ser una parte en una gran base de datos o un archivo
independiente.
5. Numero de interfaces externas: se cuentan todas las interfaces legibles por la maquina.
0 | 1 | 2 | 3 | 4 | 5 |
Sin Influencia | Incidental | Moderado | Medio | Significativo | Esencial |
Fi
1. ¿Requiere el sistema de copia de seguridad fiable?
2. ¿Requiere de comunicación de datos?
3. ¿Existen funciones de procesamientos distribuidos?
4. ¿Es crítico el rendimiento?
5. ¿Será ejecutado el sistema en entorno operativo existente y frecuentemente utilizado?
6. ¿Requiere el sistema de entrada de datos interactiva?
7. ¿Requiere la entrada de datos interactivo que las transiciones de entradas se lleven a cabo sobre múltiples o variadas aplicaciones?
8. ¿Se actualizan los archivos maestros en formas interactivas?
9. ¿Son complejas las entradas, salidas, archivos o peticiones?
10. ¿Es complejo el procesamiento interno?
11. ¿Se ha diseñado el código para ser reutilizable?
12. ¿Están incluidos en el diseño la conversión e instalación?
13. ¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones?
14. ¿Se ha diseñado las aplicaciones para facilitar los cambios y para ser fácilmente utilizada por el usuario?
Los valores constantes de la ecuación anterior y los factores de peso aplicados en las encuestas
de los ámbitos de información han sido determinados empíricamente.
Una vez calculado los puntos de función se usan de forma analógica a las LDC como medida de
la productividad, calidad y otros productos del software.
Productividad = PF / persona-mes
Calidad = Errores / PF
Costo = Dólares / PF
Documentación = Pags. Doc / PF
La medida de puntos de función se diseñó originalmente para ser utilizadas en aplicación de
sistemas de información de gestión. Sin embargo, algunas aplicaciones se les denominan puntos de características.
Punto de Características
Parámetro Medición | Cuenta | Complejo |
Num entradas usuario | x | 4 = |
Num salidas usuario | x | 5 = |
Num Peticiones usuario | x | 4 = |
Num Archivo | x | 7 = |
Num Interfaces Externa | x | 7 = |
Algoritmos | x | 3 = |
Cuenta=Total |
Se usa único valor de peso para cada uno de los parámetros de medida y se calcula el valor del punto característica global mediante la ecuación.
PF = CUENTA_TOTAL * [0.65 + 0.01 * SUM(fi)]
Debe tenerse en cuenta que los puntos de característica y los puntos de función representan lo mismo. "funcionalidad o utilidad" en forma de software.
Métricas Ampliadas de punto de función
Para remediar la medida del punto de función que era inadecuada para muchos sistemas de ingeniería y sistemas empotrados (que enfatizan función y control) se proponen un numero de extensiones básicas a la métrica del punto de función básica:
Punto de característica: se acomoda a aplicaciones dónde la complejidad del algorítmo es alta (software de tiempo real, control de procesos).
Algoritmo: problema de cálculo limitado que se incluye dentro de un programa de computadora específico.
Punto de función 3d: adecuada para aplicaciones que enfatizan capacidades de función y control: sistemas en tiempo real y productos de ingeniería.
Dimensión de datos: las cuentas de datos internos y los datos externos se utilizan a lo largo de las medidas de complejidad para derivar una cuenta de dimensión de datos.
Dimensión funcional: Se mide considerando el número de operaciones internas requeridas para transformar datos de entrada en datos de salida.
Dimensión de control: se mide contando el número de transiciones entre estados. Un estado presenta algún modo de comportamiento externamente observable y una transición ocurre como resultado de algún suceso que cambia el modo de comportamiento del sistema o del software.
Pesos de complejidad
Elemento de Medición | Bajo | Medio | Alto | SubTotal |
Estructura interna de datos | *7+ | *10+ | *15 = | |
Datos Externo | *5+ | *7+ | *10= | |
Num entrada usuario | *3+ | *4+ | *6= | |
Num salida usuario | *4+ | *5+ | *7= | |
Num peticiones usuario | *3+ | *4+ | *6= | |
Transformación | *6+ | *10+ | *15= | |
Transición | + | + | = |
Punto de Función 3D |
Funcionalidad de los lenguajes de programación
La tabla siguiente proporcional estimaciones informales del número de líneas de código que se necesitan para construir un punto de función en varios lenguajes de programación.
Lenguaje | LOC\PF |
Ensamblador | 320 |
C | 128 |
Cobol | 105 |
Fortran | 105 |
Pascal | 90 |
Ada | 70 |
OOL | 30 |
4GL | 20 |
Generador de Código | 15 |
Hojas de Calculo | 6 |
Lenguajes de Iconos | 4 |
Eficacia de la Eliminación de defectos (EED)
.
EED = E / (E + D)
donde:
E es el número de errores (fallas detectadas antes de entregar el sistema al usuario por primera vez)
D es el número de defectos (fallas detectadas después de entregar el sistema al usuario por primera vez)
D es el número de defectos (fallas detectadas después de entregar el sistema al usuario por primera vez)
Medidas de calidad de Gilb.
· Corrección: Es el grado en el que el software lleva a cabo su función requerida. Se mide en defectos por KLOC.
· Facilidad de mantenimiento: Es la facilidad con que se puede corregir un programa si se encuentra un error, adaptar si su medio ambiente cambia o mejorar si el cliente desea un cambio de requisitos. Se mide en Tiempo Medio de Cambios (TMC), que es el tiempo que se lleva desde analizar la petición hasta distribuir el cambio a los usuarios.
· Integridad: Mide la habilidad de un sistema de resistir ataques. Se calcula aplicando la fórmula:
1 - amenaza * (1 - seguridad)
Para cada tipo de ataque, y donde amenaza se define como la probabilidad de que ocurra ese ataque y seguridad como la probabilidad que ese ataque sea rechazado.
· Facilidad de uso: Mide que tan amigable es el sistema con el usuario en función de cuatro características:
· Habilidad intelectual y/o física para aprender a usarlo.
· Tiempo requerido para ser moderadamente eficiente al usarlo.
· Aumento neto de productividad, comparado con el sistema que reemplaza.
· Valoración subjetiva de la disposición de los usuarios hacia el sistema.
Métricas Orientada a la calidad
Muchas de las medidas que maximizan la calidad producen como efecto colateral una diminución en el coste, y viceversa. Tradicionalmente se piensa que aumentar la calidad es aumentar el coste en tiempo. Pero muchas veces el tiempo invertido en aumentar la calidad repercute en el futuro en un menor coste de desarrollo o mantenimiento.
Valores abstractos del software:
Robusto: libre de errores.
Flexible: permite reutilización y adaptación a nuevos requisitos.
Mantenible: permite entender el código tiempo después de haber sido escrito y/o por personas que no lo escribieron (estándares de sintaxis y documentación).
Escalabilidad y rendimiento: al aumentar el número de usuarios, el rendimiento no disminuye exponencialmente.
o
Integridad: Mide la habilidad de un sistema para resistir a ataques ya sea accidentales o intencionales a su seguridad. Se pueden dar en los programas, datos y documentos.
La medición de la integridad define dos atributos:
Amenaza: puede estimarse o deducirse es la probabilidad de que un ataque suceda en un tiempo determinado.
Seguridad: Existen herramientas que enfrentan a tu código a una base de datos de vulnerabilidades conocidas. También es la probabilidad de que se repela la amenaza.
Integridad = 1 – (amenaza x (1 – seguridad ))
Calidad = Errores / PF
Métrica orientada a las organizaciones pequeñas
· Tiempo transcurrido desde el momento en que se hizo la solicitud hasta que la evaluación está completa
· Esfuerzo para realizar la evaluación.
· Tiempo transcurrido desde que se completa la evaluación hasta la asignación del pedido de cambio de personal.
· Esfuerzo requerido para hacer el cambio.
· Tiempo requerido para hacer el cambio.
· Errores descubiertos durante el trabajo para hacer el cambio.
· Defectos descubiertos después de que el cambio es liberado a la base de cliente.
Programa de Métrica y Planificación (MSproject)
1. Objetivos del Negocio
Fundación FES
· Mejorar la gestión de fondos asignados a los diversos programas que ejercen en Nicaragua.
2. Nuevos saberes /Aprendizajes
· Conocer todo acerca del proceso que se lleva a cabo en la fundación FES acerca de la agenda de eventos.
3. Sub Objetivos
· Agenda de Eventos.
4. Entidades y Atributos de los Sub Objetivos
PARTICIPANTES |
Id_Participante |
Id_Exponencia |
Id_Invitados |
Id_Alimentos |
Id_Materiales |
Nombre_participante |
Apellido |
Sexo |
Edad |
Direccion |
Telefono |
E_mail |
Tipo_Participante |
LOCAL |
Id_Local |
Nombre |
Ubicación |
Teléfono |
Costo |
EXPONENCIA |
Id_Exponencia |
Tema |
Expositor |
Duracion |
INVITACIÓN |
Id_Invitacion |
Fecha_Invitacion |
Tipo_Envio |
Fecha_Confirmacion |
Mat y Equipo |
Id_Mat_Eq |
Nombre_Mat |
Canttidad |
Costo |
EVENTOS |
Id_Eventos |
Id_Exponencia |
Id_Local |
Fecha |
Duracion |
5. Objetivos de Medición
La medición determina cuales son los aspectos y proporcionan métodos para medirlo. La medición y estimación atacan los tres problemas claves de la ingeniería del software:
1. Estimar costos y recursos en un proyecto software.
2. Garantizar la calidad del producto final.
3. Mejorar la productividad del ingeniero de software durante el desarrollo.
6. Preguntas cuantitativas e indicadores relacionados
· ¿Cuantas personas desarrollaran el software? P
· ¿En cuánto tiempo se terminara el software? Td
· ¿Cuál va a ser la ganancia esperada del software? Ct
· ¿De cuánto va a ser el esfuerzo del software? E
7. Recolecta de datos y cálculos de indicadores
1. PF= CuT *[0.65 +0.01* Σ14 i=1 fi ]
PF= 800*[0.65+0.01*45]
PF=880
2. P=a*(KL b)
P=3.6*(0.88)1.2
KL= PF/1000
KL=0.8
P=3.08 aproximadamente 3 personas
3. Td=C*P d
Td=2.5*(3.08)0.32
Td=3.58 aproximadamente 3 ½ meses
4. Ct= 3.08/3.58*475
Ct= 408 U$ ganancia esperada
8. Medidas a usar (definición operativa de los resultados)
· El resultado de P significa que este software necesitara de 3 a 4 personas
P=a*(KL b)
P=3.6*(0.88)1.2
P=3.08
· El resultado de Td significa el tiempo de desarrollo de este software que será de 3 ½ meses
Td=C*P d
Td=2.5*(3.08)0.32
Td=3.58
· El resultado de Ct es la ganancia esperada de software desarrollado que es de 408 dólares
Ct= 3.08/3.58*475
Ct= 408 U$ ganancia esperada
9. Acciones a mejoras
Los resultados tantos de la FES y actuales tienen muchas similitudes por lo que no se requiere de mejoras y la única variación está en el coste o ganancia esperada con una diferencia de 363 dólares.
Resultados FES | Resultados Actuales |
P=3.08 | P= 3 a 4 |
Td=3.58 | Td=4 meses |
Ct=408 U$ | Ct=45 U$ |
Hola buen trabajo explicando todo esto pero serias tan amable de indicarme cuales son tus fuentes de información (Bibliografías)
ResponderEliminarGracias