El Modelo Constructivo de Costes (o COCOMO, por su acrónimo del inglés COnstructive COstMOdel) es un modelo matemático de base empírica utilizado para estimación de costes de software. Incluye tres submodelos, cada uno ofrece un nivel de detalle y aproximación, cada vez mayor, a medida que avanza el proceso de desarrollo del software: básico, intermedio y detallado.
Este modelo fue desarrollado por Barry W. Boehm a finales de los años 70 y comienzos de los 80, exponiéndolo detalladamente en su libro "Software Engineering Economics" (Prentice-Hall, 1981).
CARACTERÍSTICAS
Pertenece a la categoría de modelos de subestimaciones basados en estimaciones matemáticas. Está orientado a la magnitud del producto final, midiendo el "tamaño" del proyecto, en líneas de código principalmente.
INCONVENIENTES
- Los resultados no son proporcionales a las tareas de gestión ya que no tiene en cuenta los recursos necesarios para realizarlas.
- Se puede desviar de la realidad si se indica mal el porcentaje de líneas de comentarios en el código fuente.
- Es un tanto subjetivo, puesto que está basado en estimaciones y parámetros que pueden ser "vistos" de distinta manera por distintos analistas que usen el método.
- Se miden los costes del producto, de acuerdo a su tamaño y otras características, pero no la productividad.
- La medición por líneas de código no es válida para orientación a objetos.
- Utilizar este modelo puede resultar un poco complicado, en comparación con otros métodos (que también sólo estiman).
MODELOS DE ESTIMACIÓN
La función básica que utilizan los tres modelos es:
E = a(Kl)b * m(X) donde:
E = a(Kl)b * m(X) donde:
a y b son constantes con valores definidos en cada submodelo
Kl es la cantidad de líneas de código, en miles.
m(X) Es un multiplicador que depende de 15 atributos.
El resultado se da en unidades salario/mes y horas-hombre.
A la vez, cada submodelo también se divide enmodos que representan el tipo de proyecto, y puede ser:
- 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). mientras que en los otros dos modos el tamaño varía de pequeño a muy grandes (varios cientos de miles de líneas). En este modo, al igual que en los otros, el coste se incrementa a medida que el tamaño lo hace, y el tiempo de desarrollo se alarga. Se utilizan dos ecuaciones para determinar el esfuerzo de personal y el tiempo de desarrollo.
- 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.
- 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.
Las estimaciones de tiempo y coste se basan en las mismas ecuaciones que en el modo orgánico, pero con diferentes constantes.
Métricas Orientadas al Tamaño
Las métricas del software orientadas al tamaño provienen
de la normalización de las medidas de calidad y/o
productividad considerando el «tamaño» del software
que se haya producido. Si una organización de software
mantiene registros sencillos, se puede crear una tabla
de datos orientados al tamaño, como la que muestra la
La tabla lista cada proyecto de desarrollo de
software de los últimos años y las medidas correspondientes
de cada proyecto. Refiriéndonos a la entrada de
la tabla del proyecto alfa: se desarrollaron
12.100 líneas de código (LDC) con 24 personas-mes y
con un coste de E168.000. Debe tenerse en cuenta que
el esfuerzo y el coste registrados en la tabla incluyen
todas las actividades de ingeniería del software (análisis,
diseño, codificación y prueba) y no sólo la codificación.
Otra información sobre el proyecto alfa indica
que se desarrollaron 365 páginas de documentación, se
registraron 134 errores antes de que el software se entregara
y se encontraron 29 errores después de entregárselo
al cliente dentro del primer año de utilización.
También sabemos que trabajaron tres personas en el
desarrollo del proyecto alfa.
¿Qué datos deberíamos
reunir para derivar métricas
orientadas al tamaño?
Para desarrollar métricas que se puedan comparar
entre distintos proyectos, se seleccionan las líneas de
código como valor de normalización. Con los rudimentarios
datos contenidos en la tabla se pueden desarrollar
para cada proyecto un conjunto de métricas
simples orientadas al tamaño:
errores por KLDC (miles de líneas de código)
defectos4 por KLDC
E por LDC
páginas de documentación por KLDC
Plontillo de colección de métricos
Además, se pueden calcular otras métricas interesantes:
errores por persona-mes
LDC por persona-mes
E por página de documentación
Métricas Orientadas a la Función
Las métricas del software orientadas a la función utilizan
una medida de la funcionalidad entregada por la
aplicación como un valor de normalización. Ya que la
«funcionalidad>>n o se puede medir directamente, se
debe derivar indirectamente mediante otras medidas
directas. Las métricas orientadas a la función fueron
propuestas por primera vez por Albretch [ALB79], quien
sugirió una medida llamada punto defunción. Los puntos
de función se derivan con una relación empírica
según las medidas contables (directas) del dominio de
información del software y las evaluaciones de la complejidad
del software.
Referencia 3 Web
Se puede obtener información completo sobre los puntos
de funcibn en: www.ifpug.org
Los puntos de función se calculan [IFP94] completando
la tabla de la Se determinan cinco
características de dominios de información y se proporcionan
las cuentas en la posición apropiada de la
tabla. Los valores de los dominios de información se
definen de la forma siguiente?
Número de entradas de usuario. Se cuenta cada
entrada de usuario que proporciona diferentes datos
orientados a la aplicación. Las entradas se deberían
diferenciar de las peticiones, las cuales se cuentan de
forma separada.
los puntos de función se derivan de medidas
directas del dominio de la información.
Número de salidas de usuario. Se cuenta cada salida
que proporciona al usuario información orientada a la
aplicación. En este contexto la salida se refiere a informes,
pantallas, mensajes de error, etc. Los elementos
de datos particulares dentro de un informe no se cuentan
de forma separada.
Número de pcticiones de usuario. Una petición se
define como una entrada interactiva que produce la generación
de alguna respuesta del software inmediata en
forma de salida inleractiva. Se cuenta cada petición por
separado.
Número de archivos. Se cuenta cada archivo maestro
lógico (esto es, un grupo lógico de datos que puede
ser una parte de una gran base de datos o un archivo
independiente).
Número de interfaces externas. Se cuentan todas
las interfaces legibles por la máquina (por ejemplo:
archivos de datos de cinta o disco) que se utilizan
para transmitir información a otro sistema.
Una vez que se han recopilado los datos anteriores,
a la cuenta se asocia un valor de complejidad.
Las organizaciones que utilizan métodos de puntos
de función desarrollan criterios para determinar si
una entrada en particular es simple, media o compleja.
No obstante la determinación de la complejidad
es algo subjetiva.
Parámetros de medición Cuenta Número
x 4 5 7 =a
x 3 4 6 =a
X l 10 15 = a
x 5 7 10 = a
Cuenta total
Cálculo de puntos de función.
Para calcular puntos de función (PF), se utiliza la
(4.1)
relación siguiente:
PF = cuenta-total x [0,65 + 0,Ol x 6(Fi )]
en donde cuenta-total es la suma de todas las entradas
PF obtenidas de la figura 4.5.
Fi (i = 1 a 14) son «valores de ajuste de la compkjidad
» según las respuestas a las siguientes preguntas
.
¿Requiere el sistema copias de seguridad y de recuperación
fiables?
¿Se requiere comunicación de datos?
¿Existen funciones de procesamiento distribuido?
¿Es crítico el rendimiento?
¿Se ejecutarh el sistema en un entorno operativo
existente y fuertemente utilizado?
i,Requiere el sistema entrada de datos interactiva?
¿Requiere la entrada de datos interactiva que las
transacciones de entrada se lleven a cabo sobre múltiples
pantallas u operaciones?
¿Se actualizan los archivos maestros de forma
interactiva?
¿Son complejas las entradas, las salidas, los archivos
o las peticiones?
¿Es complejo el procesamiento interno?
¿Se ha diseñado el código para ser reutilizable?
¿Están incluidas en el diseño la conversión y la instalación'?
¿Se ha diseñado el sistema para soportar múltiples
instalaciones en diferentes organizaciones?
¿Se ha diseñado la aplicación para facilitar los cambios
y para ser fácilmente utilizada por el usuario?
Métricas ampliadas de punto de función
La medida de punto de función se diseñó originalmente
para aplicarse a aplicaciones de sistemas de información
de gestión. Para acomodar estas aplicaciones,
se enfatizó la dimensión de datos (los valores de dominios
de información tratados anteriormente) para la
exclusión de dimensiones (control) funcionales y de
comportamiento. Por esta razón, la medida del punto de
función era inadecuada para muchos sistemas de ingeniería
y sistemas empotrados (que enfatizan función y
control). Para remediar esta situación se ha propuesto
un número de extensiones a la métrica del punto de función
básica.
8%
CLAVE
la extensión de los puntos de función se utiliza
en la ingeniería, en las aplicaciones de tiempo real
y en las aplicaciones orientadas al control.
Una extensión del punto de función es la llamada
puntos de características [JON9 11; es una ampliación
de la medida del punto de función que se puede aplicar
a sistemas y aplicaciones de ingeniería del software. La
medida de punto de característica acomoda a aplicaciones
en donde la complejidad del algoritmo es alta.
Las aplicaciones de software de tiempo real, de control
de procesos, y empotradas tienden a tener alta complejidad
de algoritmos y por lo tanto son adecuadas para
el punto de característica.
Para calcular el punto de característica, los valores
de dominio de información se cuentan otra vez y se pesan
de la forma que se describe en la Sección 4.3.2. Además,
la métrica del punto de característica cuenta una característica
nueva del software -los algoritmos-. Un algoritmo
se define como <<unp roblema de cálculo limitado
que se incluye dentro de un programa de computadora
específico» [JON9 11. Invertir una matriz, decodificar
una cadena de bits o manejar una interrupción son ejemplos
de algoritmos.
Boeing ha desarrollado otra extensión de punto de
función para sistemas en tiempo real y productos de
ingeniería. El enfoque de Boeing integra la dimensión
de datos del software con las dimensiones funcionales
y de control para proporcionar una medida orientada
a la función que es adecuada a aplicaciones que
enfatizan las capacidades de control y función. Las
características de las tres dimensiones del software se
«cuentan, cuantifican y transforman» en una medida
que proporciona una indicación de la funcionalidad
entregada por el software6, llamada Punto de Función
30 [WHI95]
La dimensión de datos se evalúa exactamente igual
a como se describe en la Sección 4.3.2. Las cuentas de
datos retenidos (la estructura interna de datos de programas,
p. ej.: archivos) y los datos externos (entradas,
salidas, peticiones y referencias externas) se utilizan a
lo largo de las medidas de la complejidad para derivar
una cuenta de dimensión de datos.
La dimensión funcional se mide considerando «el
número de operaciones internas requeridas para transformar
datos de entrada en datos de salida» [WHI95].
Para calcular puntos de función 3D, se utiliza la rela-
(4.2)
en donde 1, O, Q, F, E, T y R representan valores con
peso de complejidad en los elementos tratados anteriormente:
entradas, salidas, peticiones, estructuras de
datos internas, archivos externos, transformaciones y
transiciones, respectivamente. Cada valor con peso de
complejidad se calcula con la relación siguiente:
valor con peso de complejidad =
ción siguiente:
índice=I + O + Q + F + E + T+ R
en donde Nil , Ni, y Nih representan el número de apariciones
del elemento i (p. ej.: salidas) para cada nivel
de complejidad (bajo, medio, alto), y Wi, , Wia y W,
son los pesos correspondientes. El cálculo global de los
puntos de función 3D se muestran en la Figura 4.6.
Se debería señalar que los puntos de función, los puntos
de característica y los puntos de función 3D representan
lo mismo -«funcionalidad» o «utilidad»
entregada por el software-. En realidad, cada una de
estas medidas producen el mismo valor si sólo se considera
la dimensión de datos de una aplicación. Para sistemas
de tiempo real más complejos, la cuenta de puntos
de característica a menudo se encuentra entre el 20 y el
35 por 100 más que la cuenta determinada sólo con los
puntos de función.
El punto de función (y sus extensiones), como la
medida LDC, es controvertido. Los partidarios afirman
que PF es independiente del lenguaje de programación,
lo cual es ideal para aplicaciones que utilizan lenguajes
convencionales y no procedimentales; esto se basa en
los datos que probablemente se conocen al principio de
la evolución de un proyecto, y así el PF es más atractivo
como enfoque de estimación.
Sentencias
1-5 6-10 11+
1-10 Bajo Bajo Medio
1 1-20 Bajo Medio Alto
Cálculo de los índices de los puntos
de función 30.
Los detractores afirman que el método requiere algún
«juego de manos» en el que el cálculo se base en datos
subjetivos y no objetivos; y afirman que las cuentas del
dominio de información (y otras dimensiones) pueden
ser difíciles de recopilar después de realizado, y por último
que el PF no tiene un significado físico directo -es
simplemente un número-.
Métricas para la calidad de software
El objetivo primordial de la ingeniería del software es producir
un sistema, aplicación o producto de alta calidad.
Para lograr este objetivo, los ingenieros del software deben
aplicar métodos efectivos junto con herramientas modernas
dentro del contexto de un proceso maduro de desarrollo
de software. Además, un buen ingeniero del software
(y buenos gestores de la ingeniería del software) deben
medir si la alta calidad se va a llevar a cabo.
La calidad de un sistema, aplicación o producto es
tan bueno como los requisitos que describen el problema,
el diseño quc modcla la solución, el código que conduce
a un programa ejecutable, y las pruebas que
ejercitan el software para detectar errores. Un buen ingeniero
del software utiliza mediciones que evalúan la
calidad del análisis y los modelos de diseño, el código
fuente, y los casos de prueba que se han creado al aplicar
la ingeniería del software. Para lograr esta evaluación
de la calidad en tiempo real, el ingeniero debe
utilizar medidas técnicas (Capítulos 19 y 24) que evalúan
la calidad con objetividad, no con subjetividad.
Referencia Web/ ’
Se puede encontrar una excelente fuente de informoción
sobre la calidad del software y ternos relacionados
(incluyendo métricas) en: www.quol¡tyworld.com
El gestor de proyectos también debe evaluar la calidad
objetivamente, y no subjetivamente. A medida que
el proyecto progresa el gestor del proyecto también debe
evaluar la calidad. Las métricas privadas recopiladas por
ingenieros del software particulares se asimilan para proporcionar
resultados en los proyectos. Aunque se pueden
recopilar muchas medidas de calidad, el primer objetivo
en el proyecto es medir errores y defectos. Las métricas
que provienen de estas medidas proporcionan una indicación
de la efectividad de las actividades de control y
de la garantía de calidad en grupos o en particulares.
En el capitulo 8 se presento un estudio detallada sobre
las actividades de garantía de calidad del software.
4.5.1. Visión general de los factores que afectan
Hace 25 años, McCall y Cavano [MCC78] definieron un
juego de factores de calidad como los primeros pasos hacia
el desarrollo de métricas de la calidad del software. Estos
factores evalúan el software desde tres puntos de vista distintos:
(1) operación del producto (utilizándolo), (2) revisión
del producto (cambiándolo), y (3) transición del
producto (modificándolo para que funcione en un entorno
diferente, por ejemplo, «portándolo»). Los autores, en
su trabajo, describen la relación entre estos factores de
calidad (lo que llaman un «marco de trabajo») y otros
aspectos del proceso de ingeniería del software:
En primer lugar, el marco de trabajo proporciona un mecanismo
para que el gestor del proyecto identifique lo que considera
importante. Estas cualidades son atributos del software,
además de su corrección y rendimiento funcional, que tiene
implicaciones en el ciclo de vida. En otros factores, como son
facilidad de mantenimiento y portabilidad, se ha demostrado
que tienen un impacto significativo en el coste del ciclo de vida.. .
En segundo lugar, el marco de trabajo proporciona un medio
de evaluar cuantitativamente lo bien que va progresando el desarrollo
en relación con los objetivos de calidad establecidos.. .
En tercer lugar, el marco de trabajo proporciona más interacción
del personal de QA (garantía de calidad) en el esfuerzo
de desarrollo.. .
Por Último,. . . el personal de garantía de calidad puede utilizar
indicaciones de calidad pobre para ayudar a identificar
estándares [mejores] a enfrentar en el futuro.
Un estudio detallado del marco de trabajo de McCall
y Cavano, así como otros factores de calidad, se presentan
en el Capítulo 19. Es interesante destacar que
casi todos los aspectos del cálculo han sufrido cambios
radicales con el paso de los años desde que McCall y
Cavano hicieron su trabajo, con gran influencia, en 1978.
Pero los atributos que proporcionan una indicación de
la calidad del software siguen siendo los mismos.
a sus usuarios finales-. Cuando la proporción de
desperdicios en el coste global del proyecto (para
muchos proyectos) se representa como una función
del tiempo, el gestor puede determinar si la facilidad
total del software producido por una organización de
desarrollo está mejorando. Se pueden emprender
acciones a partir de las conclusiones obtenidas de
esa información.
Integridad. En esta época de «hackers» y direwalls
», la integridad del software ha llegado a tener
mucha importancia. Este atributo mide la capacidad
%&"E
Sorprendentemente, los factores que definían la calidad
del software en el año 1970 san los mismos factores
que continúan definiendo la calidad del software
en la primera década de este siglo.
¿Qué significa esto? Si una organización de software
adopta un juego de factores de calidad como una «lista
de comprobación» para evaluar la calidad del software,
es probable que el software construido hoy siga exhibiendo
la calidad dentro de las primeras décadas de este
siglo. Incluso, cuando las arquitecturas de cálculo sufren
cambios radicales (como seguramente ocurrirá), el software
que exhibe alta calidad en operación, transición y
revisión continuará sirviendo también a sus usuarios.
Medida de la calidad
Aunque hay muchas medidas de la calidad de software,
la corrección, facilidad de mantenimiento, integridad,
y facilidad de uso proporcionan indicadores Útiles
para el equipo del proyecto. Gilb [GIL881 ha sugerido
definiciones y medidas para cada uno de ellos.
Corrección. Un programa debe operar correctamente
o proporcionará poco valor a sus usuarios. La
corrección es el grado en el que el software lleva a
cabo su función requerida. La medida más común de
corrección es defectos por KLDC, en donde un
defecto se define como una falta verificada de conformidad
con los requisitos.
Facilidad de mantenimiento. El mantenimiento
del software cuenta con más esfuerzo que cualquier
otra actividad de ingeniería del software. La facilidad
de mantenimiento es la facilidad con la que se
puede corregir un programa si se encuentra un error,
se puede adaptar si su entorno cambia, o mejorar si
el cliente desea un cambio de requisitos. No hay
forma de medir directamente la facilidad de mantenimiento;
por consiguiente, se deben utilizar medidas
indirectas. Una simple métrica orientada al
tiempo es el tiempo medio de cambio (TMC), es decir
el tiempo que se tarda en analizar la petición de cambio,
en diseñar una modificación adecuada, en implementar
el cambio, en probarlo y en distribuir el
cambio a todos los usuarios. Como media, los programas
que se pueden mantener tendrán un TMC
más bajo (para tipos equivalentes de cambios) que
los programas que no son más fáciles de mantener.
Hitachi [TAJS 11 ha utilizado una métrica orientada
al coste para la capacidad de mantenimiento llamada
«desperdicios» -e1 coste en corregir defectos
encontrados después de haber distribuido el software
de un sistema para resistir ataques (tanto accidentales
como intencionados) contra su seguridad. El ataque
se puede realizar en cualquiera de los tres componentes
del software: programas, datos y documentos.
Para medir la integridad, se tienen que definir
dos atributos adicionales: amenaza y seguridad.
Amenaza es la probabilidad (que se puede estimar
o deducir de la evidencia empírica) de que un ataque
de un tipo determinado ocurra en un tiempo
determinado. La seguridad es la probabilidad (que
se puede estimar o deducir de la evidencia empírica)
de que se pueda repeler el ataque de un tipo
determinado. La integridad del sistema se puede
definir como:
integridad = C [( 1 - amenaza) x (1 - seguridad)]
donde se suman la amenaza y la seguridad para cada
tipo de ataque.
Facilidad de uso. El calificativo «amigable con el
usuario» se ha convertido en omnipresente en las discusiones
sobre productos de software. Si un programa
no es «amigable con el usuario», frecuentemente está
abocado al fracaso, incluso aunque las funciones que
realice sean valiosas. La facilidad de uso es un intento
de cuantificar «lo amigable que puede ser con el usuario
» y se puede medir en función de cuatro características:
(1) habilidad intelectual y/o física requerida
para aprender el sistema; (2) el tiempo requerido para
llegar a ser moderadamente eficiente en el uso del sistema;
(3) aumento neto en productividad (sobre el
enfoque que el sistema reemplaza) medida cuando
alguien utiliza el sistema moderadamente y eficientemente;
y (4) valoración subjetiva (a veces obtenida
mediante un cuestionario) de la disposición de los
usuarios hacia el sistema. En el Capítulo 15 se estudia
más detalladamente este aspecto.
Los cuatro factores anteriores son sólo un ejemplo
de todos los que se han propuesto como medidas de la
calidad del software. El Capítulo 19 considera este tema
con más detalle.
Eficacia de la Eliminación de Defectos
Una métrica de la calidad que proporciona beneficios
tanto a nivel del proyecto como del proceso, es la eficacia
de la eliminación de defectos (EED). En esen-
Para propósitos de computación de los puntos de función
3D, se observa una «transformación» como una
serie de pasos de proceso que quedan limitados por sentencias
semánticas. La dimensión de control se mide
contando el número de transiciones entre estados7.
Un estado representa 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
(esto es, cambia el estado). Por ejemplo, un teléfono
inalámbrico contiene software que soporta funciones
de marcado automático. Para introducir el estado de
marcado automático desde un estado en descanso, el
usuario pulsa una tecla Auto en el teclado numérico.
Este suceso hace que una pantalla LCD pida un código
que indique la parte que se llama. Con la entrada
del código y pulsando la tecla de Marcado (otro suceso),
el software del teléfono inalámbrico hace una
transición al estado de marcado. Cuando se computan
puntos de función 3D, no se asigna un valor de
complejidad a las transiciones.
Metricas para Organizaciones pequeñas
La amplia mayoría de las organizaciones de desarrollo
de software tienen menos de 20 personas dedicadas al
software. Es poco razonable, y en la mayoría de los casos
no es realista, esperar que organizaciones como éstas
desarrpllen programas métricos de software extensos.
Sin embargo, si que es razonable sugerir que organizaciones
de software de todos los tamaños midan y después
utilicen las métricas resultantes para ayudar a
mejorar sus procesos de software local y la calidad y
oportunidad de los productos que realizan. Kautz
[KAU99] describe un escenario típico que ocurre cuando
se piensa en programas métricos para organizaciones
pequeñas de software:
Onginalmente, los desarrolladores de software acogían nuestras
actividades con un alto grado de escepticismo, pero al final
las aceptaban debido a que nosotros conseguíamos que nuestras
medidas fueran simples de realizar, adaptadas a cada organización
y se aseguraba que dichas medidas producían una
información válida y útil. Al final, los programas proporcionaba
una base para encargarse de los clientes y para la planificación
y desarrollo de su trabajo futuro.
Lo que Kautz sugiere es una aproximación para la
implementación de cualquier actividad relacionada con
el proceso del software: que sea simple; adaptada a satisfacer
las necesidades locales y que se constate que realmente
añada valor. En los párrafos siguientes examinamos
cómo se relacionan estas líneas generales con las métricas
utilizadas para negocios pequeños.
«Para hacerlo fácil», es una línea de acción que
funciona razonablemente bien en muchas actividades.
Pero jcómo deducimos un conjunto sencillo de métricas
de software que proporcionen valor, y cómo podemos
estar seguros de que estas métricas sencillas
lograran satisfacer las necesidades de una organización
de software particular? Comenzamos sin centrarnos
en la medición, pero sí en los resultados
finales. El grupo de software es interrogado para que
defina un objetivo simple que requiera mejora. Por
ejemplo, «reducir el tiempo para evaluar e implementar
las peticiones de cambio». Una organización
pequeña puede seleccionar el siguiente conjunto de
medidas fácilmente recolectables:
Tiempo (horas o días) que transcurren desde el
momento que es realizada una petición hasta que se
complete su evaluación, tcola.
E.s fuerzo (horas-persona) para desarrollar la evalua- ~ _ _ _
ción, WeVa1.
Tiempo (horas o días) transcurridos desde la terminación
de la evaluación a la asignación de una orden
de cambio al personal, teval.
Esfuerzo (horas-persona) requeridas para realizar el
cambio, Wcambio.
Tiempo requerido (horas o días) para realizar el cam-
Errores descubiertos durante el trabajo para realizar
el cambio, Ecambio.
bio, t,-,bio*
¿Cómo puedo derivar
un conjunto «simple»
de métricas del software?
Una vez que estas medidas han sido recogidas para
un cierto número de peticiones de cambio, es posible calcular
el tiempo total transcurrido desde la petición de
cambio hasta la implementación de dicho cambio y el
porcentaje de tiempo consumido por el proceso de colas
iniciales, la asignación de cambio y evaluación, y la imple,-
mentación del cambio propiamente dicho. De forma similar,
el porcentaje de esfuerzo requerido para la evaluación
y la implementación puede también ser determinado.
Estas métricas pueden ser evaluadas en el contexto de los
datos de calidad, Ecambioy DcanIbioL. os porcentajes proporcionan
un análisis interno para buscar el lugar donde
los procesos de petición de cambio se ralentizan y pueden
conducir a unos pasos de mejoras de proceso para
reducir tco!a ' wevgl i.teva[ ; Wcambioy y/o Ecambio* la eficiencia de eliminacion de defectos (EED) puede ser
calculada de la siguiente manera:
EED = Ecambio ' (Ecambio+Dcamhio)
EED puede compararse con el tiempo transcurrido y el
esfuerzo total para determinar el impacto de las actividades
de aseguramiento de la calidad sobre el tiempo y
el esfuerzo requeridos para realizar un cambio.
Para grupos pequeños, el coste de incorporar medidas
y métricas de cálculo oscila entre el 3 y el 8 por 100
del presupuesto del proyecto durante la fase de aprendizaje
y después cae a menos del 1 por 100 del presupuesto
del proyecto una vez que la ingeniería del
software y la gestión de proyectos se hayan familiarizado
con el programa de métricas [GRA99]. Estos costes
pueden representar una mejora de las inversiones
siempre que el análisis derivado a partir de los datos de
la métrica conduzcan a una mejora de procesos significativa
para la organización del software.
Programa de Metricas
El Instituto de Ingeniería del Software (11s) ha desan-ollado
una guía extensa [PAR961 para establecer un programa
de medición de software dirigido hacia objetivos.
La guía sugiere los siguientes pasos para trabajar:
1. Identificar los objetivos del negocio.
2. Identificar lo que se desea saber o aprender.
3. Identificar los subobjetivos.
4. Identificar las entidades y atributos relativos a esos
5. Formalizar los objetivos de la medición.
subobjetivos.
6. Identificar preguntas que puedan cuantificarse y los
indicadores relacionados que se van a usar para
ayudar a conseguir los objetivos de medición.
7. Identificar los elementos de datos que se van a recoger
para construir los indicadores que ayuden a responder
a las preguntas planteadas.
8. Definir las medidas a usar y hacer que estas definiciones
sean operativas.
9. Identificar las acciones que serán tomadas para
mejorar las medidas indicadas.
10. Preparar un plan para implementar estas medidas.
PLANIFICACIÓN DE PROYECTOS
DE SOFTWARE
La gestión de un proyecto de software comienza con un conjunto de actividades que globalmente
se denominan planificación del proyecto. Antes de que el proyecto comience,
el gestor y el equipo de software deben realizar una estimación del trabajo a realizar, de
ursos necesarios y del tiempo que transcurrirá desde el comienzo hasta el final de su realización.
Siempre que estimamos, estamos mirando hacia el futuro y aceptamos resignados
cierto grado de incertidumbre.
Aunque la estimación es más un arte que una ciencia, es una actividad importante que no
debe llevarse a cabo de forma descuidada. Existen técnicas Útiles para la estimación del esfuerzo
y del tiempo. Las métricas del proyecto y del proceso proporcionan una perspectiva histórica
y una potente introducción para generar estimaciones cuantitativas. La experiencia anterior
(de todas las personas involucradas) puede ayudar en gran medida al desarrollo y revisión de
las estimaciones. Y, dado que la estimación es la base de todas las demás actividades de planificación
del proyecto, y que sirve como guía para una buena ingeniería del software, no es en
absoluto aconsejable embarcarse sin ella.
¿Qué es? La planificación de un proyecto
de software realmente comprende
todas las actividades tratadas en los
Capítulos 5 al 9. Sin embargo, en el
contexto de este capítulo, la planificación
implica la estimación -su intento
por determinar cuánto dinero,
esfuerzo, recursos, y tiempo supondrá
construir un sistema o producto específico
de software-.
&Quién lo hace? Los gestores del software
-utilizando la información solicitada
a los clientes y a los ingenieros
de software y los datos de métricas de
software obtenidos de proyectos anteriores-.
por qué es importante? &Podríac onstruir
una casa sin saber cuanto estaría
dispuesto a gastar?. Por supuesto qve
no, y puesto que la mayoría de los sistemas
y productos basados en computadora
cuestan considerablemente más
que construir una casa grande, podría
sBr razonable desurrollar y estima antes
de empezar a construir el software.
¿Cuáles son los pasos? La estimación
comienza con una descripción del
ámbito del producto. Hasta que no se
ndelimitam el ámbito no es posible realizar
una estimación con sentido. El
problema es entonces descompuesto
en un conjunto de problemas de menor
tamaño y cada uno de éstos se estima
guiándose con datos históricos y con
la experiencia. Es aconsejable realizar
las estimaciones utilizando al menos
dos métodos diferentes (como comprobación).
La complejidad y el riesgo del
problema se considera antes de realizar
una estimación
Métricas Orientadas al Tamaño
Las métricas del software orientadas al tamaño provienen
de la normalización de las medidas de calidad y/o
productividad considerando el «tamaño» del software
que se haya producido. Si una organización de software
mantiene registros sencillos, se puede crear una tabla
de datos orientados al tamaño, como la que muestra la
La tabla lista cada proyecto de desarrollo de
software de los últimos años y las medidas correspondientes
de cada proyecto. Refiriéndonos a la entrada de
la tabla del proyecto alfa: se desarrollaron
12.100 líneas de código (LDC) con 24 personas-mes y
con un coste de E168.000. Debe tenerse en cuenta que
el esfuerzo y el coste registrados en la tabla incluyen
todas las actividades de ingeniería del software (análisis,
diseño, codificación y prueba) y no sólo la codificación.
Otra información sobre el proyecto alfa indica
que se desarrollaron 365 páginas de documentación, se
registraron 134 errores antes de que el software se entregara
y se encontraron 29 errores después de entregárselo
al cliente dentro del primer año de utilización.
También sabemos que trabajaron tres personas en el
desarrollo del proyecto alfa.
¿Qué datos deberíamos
reunir para derivar métricas
orientadas al tamaño?
Para desarrollar métricas que se puedan comparar
entre distintos proyectos, se seleccionan las líneas de
código como valor de normalización. Con los rudimentarios
datos contenidos en la tabla se pueden desarrollar
para cada proyecto un conjunto de métricas
simples orientadas al tamaño:
errores por KLDC (miles de líneas de código)
defectos4 por KLDC
E por LDC
páginas de documentación por KLDC
Plontillo de colección de métricos
Además, se pueden calcular otras métricas interesantes:
errores por persona-mes
LDC por persona-mes
E por página de documentación
Métricas Orientadas a la Función
Las métricas del software orientadas a la función utilizan
una medida de la funcionalidad entregada por la
aplicación como un valor de normalización. Ya que la
«funcionalidad>>n o se puede medir directamente, se
debe derivar indirectamente mediante otras medidas
directas. Las métricas orientadas a la función fueron
propuestas por primera vez por Albretch [ALB79], quien
sugirió una medida llamada punto defunción. Los puntos
de función se derivan con una relación empírica
según las medidas contables (directas) del dominio de
información del software y las evaluaciones de la complejidad
del software.
Referencia 3 Web
Se puede obtener información completo sobre los puntos
de funcibn en: www.ifpug.org
Los puntos de función se calculan [IFP94] completando
la tabla de la Se determinan cinco
características de dominios de información y se proporcionan
las cuentas en la posición apropiada de la
tabla. Los valores de los dominios de información se
definen de la forma siguiente?
Número de entradas de usuario. Se cuenta cada
entrada de usuario que proporciona diferentes datos
orientados a la aplicación. Las entradas se deberían
diferenciar de las peticiones, las cuales se cuentan de
forma separada.
los puntos de función se derivan de medidas
directas del dominio de la información.
Número de salidas de usuario. Se cuenta cada salida
que proporciona al usuario información orientada a la
aplicación. En este contexto la salida se refiere a informes,
pantallas, mensajes de error, etc. Los elementos
de datos particulares dentro de un informe no se cuentan
de forma separada.
Número de pcticiones de usuario. Una petición se
define como una entrada interactiva que produce la generación
de alguna respuesta del software inmediata en
forma de salida inleractiva. Se cuenta cada petición por
separado.
Número de archivos. Se cuenta cada archivo maestro
lógico (esto es, un grupo lógico de datos que puede
ser una parte de una gran base de datos o un archivo
independiente).
Número de interfaces externas. Se cuentan todas
las interfaces legibles por la máquina (por ejemplo:
archivos de datos de cinta o disco) que se utilizan
para transmitir información a otro sistema.
Una vez que se han recopilado los datos anteriores,
a la cuenta se asocia un valor de complejidad.
Las organizaciones que utilizan métodos de puntos
de función desarrollan criterios para determinar si
una entrada en particular es simple, media o compleja.
No obstante la determinación de la complejidad
es algo subjetiva.
Parámetros de medición Cuenta Número
de entradas de usuario Número de salidas de usuario
Número de peticiones de usuario
ccll Número
de archivos Número de interfaces
externas Factor de ponderación
Simple Medio Complejo
x 3 4 6 =ax 4 5 7 =a
x 3 4 6 =a
X l 10 15 = a
x 5 7 10 = a
Cuenta total
Cálculo de puntos de función.
Para calcular puntos de función (PF), se utiliza la
(4.1)
relación siguiente:
PF = cuenta-total x [0,65 + 0,Ol x 6(Fi )]
en donde cuenta-total es la suma de todas las entradas
PF obtenidas de la figura 4.5.
Fi (i = 1 a 14) son «valores de ajuste de la compkjidad
» según las respuestas a las siguientes preguntas
.
¿Requiere el sistema copias de seguridad y de recuperación
fiables?
¿Se requiere comunicación de datos?
¿Existen funciones de procesamiento distribuido?
¿Es crítico el rendimiento?
¿Se ejecutarh el sistema en un entorno operativo
existente y fuertemente utilizado?
i,Requiere el sistema entrada de datos interactiva?
¿Requiere la entrada de datos interactiva que las
transacciones de entrada se lleven a cabo sobre múltiples
pantallas u operaciones?
¿Se actualizan los archivos maestros de forma
interactiva?
¿Son complejas las entradas, las salidas, los archivos
o las peticiones?
¿Es complejo el procesamiento interno?
¿Se ha diseñado el código para ser reutilizable?
¿Están incluidas en el diseño la conversión y la instalación'?
¿Se ha diseñado el sistema para soportar múltiples
instalaciones en diferentes organizaciones?
¿Se ha diseñado la aplicación para facilitar los cambios
y para ser fácilmente utilizada por el usuario?
Métricas ampliadas de punto de función
La medida de punto de función se diseñó originalmente
para aplicarse a aplicaciones de sistemas de información
de gestión. Para acomodar estas aplicaciones,
se enfatizó la dimensión de datos (los valores de dominios
de información tratados anteriormente) para la
exclusión de dimensiones (control) funcionales y de
comportamiento. Por esta razón, la medida del punto de
función era inadecuada para muchos sistemas de ingeniería
y sistemas empotrados (que enfatizan función y
control). Para remediar esta situación se ha propuesto
un número de extensiones a la métrica del punto de función
básica.
8%
CLAVE
la extensión de los puntos de función se utiliza
en la ingeniería, en las aplicaciones de tiempo real
y en las aplicaciones orientadas al control.
Una extensión del punto de función es la llamada
puntos de características [JON9 11; es una ampliación
de la medida del punto de función que se puede aplicar
a sistemas y aplicaciones de ingeniería del software. La
medida de punto de característica acomoda a aplicaciones
en donde la complejidad del algoritmo es alta.
Las aplicaciones de software de tiempo real, de control
de procesos, y empotradas tienden a tener alta complejidad
de algoritmos y por lo tanto son adecuadas para
el punto de característica.
Para calcular el punto de característica, los valores
de dominio de información se cuentan otra vez y se pesan
de la forma que se describe en la Sección 4.3.2. Además,
la métrica del punto de característica cuenta una característica
nueva del software -los algoritmos-. Un algoritmo
se define como <<unp roblema de cálculo limitado
que se incluye dentro de un programa de computadora
específico» [JON9 11. Invertir una matriz, decodificar
una cadena de bits o manejar una interrupción son ejemplos
de algoritmos.
Boeing ha desarrollado otra extensión de punto de
función para sistemas en tiempo real y productos de
ingeniería. El enfoque de Boeing integra la dimensión
de datos del software con las dimensiones funcionales
y de control para proporcionar una medida orientada
a la función que es adecuada a aplicaciones que
enfatizan las capacidades de control y función. Las
características de las tres dimensiones del software se
«cuentan, cuantifican y transforman» en una medida
que proporciona una indicación de la funcionalidad
entregada por el software6, llamada Punto de Función
30 [WHI95]
La dimensión de datos se evalúa exactamente igual
a como se describe en la Sección 4.3.2. Las cuentas de
datos retenidos (la estructura interna de datos de programas,
p. ej.: archivos) y los datos externos (entradas,
salidas, peticiones y referencias externas) se utilizan a
lo largo de las medidas de la complejidad para derivar
una cuenta de dimensión de datos.
La dimensión funcional se mide considerando «el
número de operaciones internas requeridas para transformar
datos de entrada en datos de salida» [WHI95].
Para calcular puntos de función 3D, se utiliza la rela-
(4.2)
en donde 1, O, Q, F, E, T y R representan valores con
peso de complejidad en los elementos tratados anteriormente:
entradas, salidas, peticiones, estructuras de
datos internas, archivos externos, transformaciones y
transiciones, respectivamente. Cada valor con peso de
complejidad se calcula con la relación siguiente:
valor con peso de complejidad =
ción siguiente:
índice=I + O + Q + F + E + T+ R
en donde Nil , Ni, y Nih representan el número de apariciones
del elemento i (p. ej.: salidas) para cada nivel
de complejidad (bajo, medio, alto), y Wi, , Wia y W,
son los pesos correspondientes. El cálculo global de los
puntos de función 3D se muestran en la Figura 4.6.
Se debería señalar que los puntos de función, los puntos
de característica y los puntos de función 3D representan
lo mismo -«funcionalidad» o «utilidad»
entregada por el software-. En realidad, cada una de
estas medidas producen el mismo valor si sólo se considera
la dimensión de datos de una aplicación. Para sistemas
de tiempo real más complejos, la cuenta de puntos
de característica a menudo se encuentra entre el 20 y el
35 por 100 más que la cuenta determinada sólo con los
puntos de función.
El punto de función (y sus extensiones), como la
medida LDC, es controvertido. Los partidarios afirman
que PF es independiente del lenguaje de programación,
lo cual es ideal para aplicaciones que utilizan lenguajes
convencionales y no procedimentales; esto se basa en
los datos que probablemente se conocen al principio de
la evolución de un proyecto, y así el PF es más atractivo
como enfoque de estimación.
Sentencias
1-5 6-10 11+
1-10 Bajo Bajo Medio
1 1-20 Bajo Medio Alto
Cálculo de los índices de los puntos
de función 30.
Los detractores afirman que el método requiere algún
«juego de manos» en el que el cálculo se base en datos
subjetivos y no objetivos; y afirman que las cuentas del
dominio de información (y otras dimensiones) pueden
ser difíciles de recopilar después de realizado, y por último
que el PF no tiene un significado físico directo -es
simplemente un número-.
Métricas para la calidad de software
El objetivo primordial de la ingeniería del software es producir
un sistema, aplicación o producto de alta calidad.
Para lograr este objetivo, los ingenieros del software deben
aplicar métodos efectivos junto con herramientas modernas
dentro del contexto de un proceso maduro de desarrollo
de software. Además, un buen ingeniero del software
(y buenos gestores de la ingeniería del software) deben
medir si la alta calidad se va a llevar a cabo.
La calidad de un sistema, aplicación o producto es
tan bueno como los requisitos que describen el problema,
el diseño quc modcla la solución, el código que conduce
a un programa ejecutable, y las pruebas que
ejercitan el software para detectar errores. Un buen ingeniero
del software utiliza mediciones que evalúan la
calidad del análisis y los modelos de diseño, el código
fuente, y los casos de prueba que se han creado al aplicar
la ingeniería del software. Para lograr esta evaluación
de la calidad en tiempo real, el ingeniero debe
utilizar medidas técnicas (Capítulos 19 y 24) que evalúan
la calidad con objetividad, no con subjetividad.
Referencia Web/ ’
Se puede encontrar una excelente fuente de informoción
sobre la calidad del software y ternos relacionados
(incluyendo métricas) en: www.quol¡tyworld.com
El gestor de proyectos también debe evaluar la calidad
objetivamente, y no subjetivamente. A medida que
el proyecto progresa el gestor del proyecto también debe
evaluar la calidad. Las métricas privadas recopiladas por
ingenieros del software particulares se asimilan para proporcionar
resultados en los proyectos. Aunque se pueden
recopilar muchas medidas de calidad, el primer objetivo
en el proyecto es medir errores y defectos. Las métricas
que provienen de estas medidas proporcionan una indicación
de la efectividad de las actividades de control y
de la garantía de calidad en grupos o en particulares.
En el capitulo 8 se presento un estudio detallada sobre
las actividades de garantía de calidad del software.
4.5.1. Visión general de los factores que afectan
Hace 25 años, McCall y Cavano [MCC78] definieron un
juego de factores de calidad como los primeros pasos hacia
el desarrollo de métricas de la calidad del software. Estos
factores evalúan el software desde tres puntos de vista distintos:
(1) operación del producto (utilizándolo), (2) revisión
del producto (cambiándolo), y (3) transición del
producto (modificándolo para que funcione en un entorno
diferente, por ejemplo, «portándolo»). Los autores, en
su trabajo, describen la relación entre estos factores de
calidad (lo que llaman un «marco de trabajo») y otros
aspectos del proceso de ingeniería del software:
En primer lugar, el marco de trabajo proporciona un mecanismo
para que el gestor del proyecto identifique lo que considera
importante. Estas cualidades son atributos del software,
además de su corrección y rendimiento funcional, que tiene
implicaciones en el ciclo de vida. En otros factores, como son
facilidad de mantenimiento y portabilidad, se ha demostrado
que tienen un impacto significativo en el coste del ciclo de vida.. .
En segundo lugar, el marco de trabajo proporciona un medio
de evaluar cuantitativamente lo bien que va progresando el desarrollo
en relación con los objetivos de calidad establecidos.. .
En tercer lugar, el marco de trabajo proporciona más interacción
del personal de QA (garantía de calidad) en el esfuerzo
de desarrollo.. .
Por Último,. . . el personal de garantía de calidad puede utilizar
indicaciones de calidad pobre para ayudar a identificar
estándares [mejores] a enfrentar en el futuro.
Un estudio detallado del marco de trabajo de McCall
y Cavano, así como otros factores de calidad, se presentan
en el Capítulo 19. Es interesante destacar que
casi todos los aspectos del cálculo han sufrido cambios
radicales con el paso de los años desde que McCall y
Cavano hicieron su trabajo, con gran influencia, en 1978.
Pero los atributos que proporcionan una indicación de
la calidad del software siguen siendo los mismos.
a sus usuarios finales-. Cuando la proporción de
desperdicios en el coste global del proyecto (para
muchos proyectos) se representa como una función
del tiempo, el gestor puede determinar si la facilidad
total del software producido por una organización de
desarrollo está mejorando. Se pueden emprender
acciones a partir de las conclusiones obtenidas de
esa información.
Integridad. En esta época de «hackers» y direwalls
», la integridad del software ha llegado a tener
mucha importancia. Este atributo mide la capacidad
%&"E
Sorprendentemente, los factores que definían la calidad
del software en el año 1970 san los mismos factores
que continúan definiendo la calidad del software
en la primera década de este siglo.
¿Qué significa esto? Si una organización de software
adopta un juego de factores de calidad como una «lista
de comprobación» para evaluar la calidad del software,
es probable que el software construido hoy siga exhibiendo
la calidad dentro de las primeras décadas de este
siglo. Incluso, cuando las arquitecturas de cálculo sufren
cambios radicales (como seguramente ocurrirá), el software
que exhibe alta calidad en operación, transición y
revisión continuará sirviendo también a sus usuarios.
Medida de la calidad
Aunque hay muchas medidas de la calidad de software,
la corrección, facilidad de mantenimiento, integridad,
y facilidad de uso proporcionan indicadores Útiles
para el equipo del proyecto. Gilb [GIL881 ha sugerido
definiciones y medidas para cada uno de ellos.
Corrección. Un programa debe operar correctamente
o proporcionará poco valor a sus usuarios. La
corrección es el grado en el que el software lleva a
cabo su función requerida. La medida más común de
corrección es defectos por KLDC, en donde un
defecto se define como una falta verificada de conformidad
con los requisitos.
Facilidad de mantenimiento. El mantenimiento
del software cuenta con más esfuerzo que cualquier
otra actividad de ingeniería del software. La facilidad
de mantenimiento es la facilidad con la que se
puede corregir un programa si se encuentra un error,
se puede adaptar si su entorno cambia, o mejorar si
el cliente desea un cambio de requisitos. No hay
forma de medir directamente la facilidad de mantenimiento;
por consiguiente, se deben utilizar medidas
indirectas. Una simple métrica orientada al
tiempo es el tiempo medio de cambio (TMC), es decir
el tiempo que se tarda en analizar la petición de cambio,
en diseñar una modificación adecuada, en implementar
el cambio, en probarlo y en distribuir el
cambio a todos los usuarios. Como media, los programas
que se pueden mantener tendrán un TMC
más bajo (para tipos equivalentes de cambios) que
los programas que no son más fáciles de mantener.
Hitachi [TAJS 11 ha utilizado una métrica orientada
al coste para la capacidad de mantenimiento llamada
«desperdicios» -e1 coste en corregir defectos
encontrados después de haber distribuido el software
de un sistema para resistir ataques (tanto accidentales
como intencionados) contra su seguridad. El ataque
se puede realizar en cualquiera de los tres componentes
del software: programas, datos y documentos.
Para medir la integridad, se tienen que definir
dos atributos adicionales: amenaza y seguridad.
Amenaza es la probabilidad (que se puede estimar
o deducir de la evidencia empírica) de que un ataque
de un tipo determinado ocurra en un tiempo
determinado. La seguridad es la probabilidad (que
se puede estimar o deducir de la evidencia empírica)
de que se pueda repeler el ataque de un tipo
determinado. La integridad del sistema se puede
definir como:
integridad = C [( 1 - amenaza) x (1 - seguridad)]
donde se suman la amenaza y la seguridad para cada
tipo de ataque.
Facilidad de uso. El calificativo «amigable con el
usuario» se ha convertido en omnipresente en las discusiones
sobre productos de software. Si un programa
no es «amigable con el usuario», frecuentemente está
abocado al fracaso, incluso aunque las funciones que
realice sean valiosas. La facilidad de uso es un intento
de cuantificar «lo amigable que puede ser con el usuario
» y se puede medir en función de cuatro características:
(1) habilidad intelectual y/o física requerida
para aprender el sistema; (2) el tiempo requerido para
llegar a ser moderadamente eficiente en el uso del sistema;
(3) aumento neto en productividad (sobre el
enfoque que el sistema reemplaza) medida cuando
alguien utiliza el sistema moderadamente y eficientemente;
y (4) valoración subjetiva (a veces obtenida
mediante un cuestionario) de la disposición de los
usuarios hacia el sistema. En el Capítulo 15 se estudia
más detalladamente este aspecto.
Los cuatro factores anteriores son sólo un ejemplo
de todos los que se han propuesto como medidas de la
calidad del software. El Capítulo 19 considera este tema
con más detalle.
Eficacia de la Eliminación de Defectos
Una métrica de la calidad que proporciona beneficios
tanto a nivel del proyecto como del proceso, es la eficacia
de la eliminación de defectos (EED). En esen-
Para propósitos de computación de los puntos de función
3D, se observa una «transformación» como una
serie de pasos de proceso que quedan limitados por sentencias
semánticas. La dimensión de control se mide
contando el número de transiciones entre estados7.
Un estado representa 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
(esto es, cambia el estado). Por ejemplo, un teléfono
inalámbrico contiene software que soporta funciones
de marcado automático. Para introducir el estado de
marcado automático desde un estado en descanso, el
usuario pulsa una tecla Auto en el teclado numérico.
Este suceso hace que una pantalla LCD pida un código
que indique la parte que se llama. Con la entrada
del código y pulsando la tecla de Marcado (otro suceso),
el software del teléfono inalámbrico hace una
transición al estado de marcado. Cuando se computan
puntos de función 3D, no se asigna un valor de
complejidad a las transiciones.
Metricas para Organizaciones pequeñas
La amplia mayoría de las organizaciones de desarrollo
de software tienen menos de 20 personas dedicadas al
software. Es poco razonable, y en la mayoría de los casos
no es realista, esperar que organizaciones como éstas
desarrpllen programas métricos de software extensos.
Sin embargo, si que es razonable sugerir que organizaciones
de software de todos los tamaños midan y después
utilicen las métricas resultantes para ayudar a
mejorar sus procesos de software local y la calidad y
oportunidad de los productos que realizan. Kautz
[KAU99] describe un escenario típico que ocurre cuando
se piensa en programas métricos para organizaciones
pequeñas de software:
Onginalmente, los desarrolladores de software acogían nuestras
actividades con un alto grado de escepticismo, pero al final
las aceptaban debido a que nosotros conseguíamos que nuestras
medidas fueran simples de realizar, adaptadas a cada organización
y se aseguraba que dichas medidas producían una
información válida y útil. Al final, los programas proporcionaba
una base para encargarse de los clientes y para la planificación
y desarrollo de su trabajo futuro.
Lo que Kautz sugiere es una aproximación para la
implementación de cualquier actividad relacionada con
el proceso del software: que sea simple; adaptada a satisfacer
las necesidades locales y que se constate que realmente
añada valor. En los párrafos siguientes examinamos
cómo se relacionan estas líneas generales con las métricas
utilizadas para negocios pequeños.
«Para hacerlo fácil», es una línea de acción que
funciona razonablemente bien en muchas actividades.
Pero jcómo deducimos un conjunto sencillo de métricas
de software que proporcionen valor, y cómo podemos
estar seguros de que estas métricas sencillas
lograran satisfacer las necesidades de una organización
de software particular? Comenzamos sin centrarnos
en la medición, pero sí en los resultados
finales. El grupo de software es interrogado para que
defina un objetivo simple que requiera mejora. Por
ejemplo, «reducir el tiempo para evaluar e implementar
las peticiones de cambio». Una organización
pequeña puede seleccionar el siguiente conjunto de
medidas fácilmente recolectables:
Tiempo (horas o días) que transcurren desde el
momento que es realizada una petición hasta que se
complete su evaluación, tcola.
E.s fuerzo (horas-persona) para desarrollar la evalua- ~ _ _ _
ción, WeVa1.
Tiempo (horas o días) transcurridos desde la terminación
de la evaluación a la asignación de una orden
de cambio al personal, teval.
Esfuerzo (horas-persona) requeridas para realizar el
cambio, Wcambio.
Tiempo requerido (horas o días) para realizar el cam-
Errores descubiertos durante el trabajo para realizar
el cambio, Ecambio.
bio, t,-,bio*
¿Cómo puedo derivar
un conjunto «simple»
de métricas del software?
Una vez que estas medidas han sido recogidas para
un cierto número de peticiones de cambio, es posible calcular
el tiempo total transcurrido desde la petición de
cambio hasta la implementación de dicho cambio y el
porcentaje de tiempo consumido por el proceso de colas
iniciales, la asignación de cambio y evaluación, y la imple,-
mentación del cambio propiamente dicho. De forma similar,
el porcentaje de esfuerzo requerido para la evaluación
y la implementación puede también ser determinado.
Estas métricas pueden ser evaluadas en el contexto de los
datos de calidad, Ecambioy DcanIbioL. os porcentajes proporcionan
un análisis interno para buscar el lugar donde
los procesos de petición de cambio se ralentizan y pueden
conducir a unos pasos de mejoras de proceso para
reducir tco!a ' wevgl i.teva[ ; Wcambioy y/o Ecambio* la eficiencia de eliminacion de defectos (EED) puede ser
calculada de la siguiente manera:
EED = Ecambio ' (Ecambio+Dcamhio)
EED puede compararse con el tiempo transcurrido y el
esfuerzo total para determinar el impacto de las actividades
de aseguramiento de la calidad sobre el tiempo y
el esfuerzo requeridos para realizar un cambio.
Para grupos pequeños, el coste de incorporar medidas
y métricas de cálculo oscila entre el 3 y el 8 por 100
del presupuesto del proyecto durante la fase de aprendizaje
y después cae a menos del 1 por 100 del presupuesto
del proyecto una vez que la ingeniería del
software y la gestión de proyectos se hayan familiarizado
con el programa de métricas [GRA99]. Estos costes
pueden representar una mejora de las inversiones
siempre que el análisis derivado a partir de los datos de
la métrica conduzcan a una mejora de procesos significativa
para la organización del software.
Programa de Metricas
El Instituto de Ingeniería del Software (11s) ha desan-ollado
una guía extensa [PAR961 para establecer un programa
de medición de software dirigido hacia objetivos.
La guía sugiere los siguientes pasos para trabajar:
1. Identificar los objetivos del negocio.
2. Identificar lo que se desea saber o aprender.
3. Identificar los subobjetivos.
4. Identificar las entidades y atributos relativos a esos
5. Formalizar los objetivos de la medición.
subobjetivos.
6. Identificar preguntas que puedan cuantificarse y los
indicadores relacionados que se van a usar para
ayudar a conseguir los objetivos de medición.
7. Identificar los elementos de datos que se van a recoger
para construir los indicadores que ayuden a responder
a las preguntas planteadas.
8. Definir las medidas a usar y hacer que estas definiciones
sean operativas.
9. Identificar las acciones que serán tomadas para
mejorar las medidas indicadas.
10. Preparar un plan para implementar estas medidas.
PLANIFICACIÓN DE PROYECTOS
DE SOFTWARE
La gestión de un proyecto de software comienza con un conjunto de actividades que globalmente
se denominan planificación del proyecto. Antes de que el proyecto comience,
el gestor y el equipo de software deben realizar una estimación del trabajo a realizar, de
ursos necesarios y del tiempo que transcurrirá desde el comienzo hasta el final de su realización.
Siempre que estimamos, estamos mirando hacia el futuro y aceptamos resignados
cierto grado de incertidumbre.
Aunque la estimación es más un arte que una ciencia, es una actividad importante que no
debe llevarse a cabo de forma descuidada. Existen técnicas Útiles para la estimación del esfuerzo
y del tiempo. Las métricas del proyecto y del proceso proporcionan una perspectiva histórica
y una potente introducción para generar estimaciones cuantitativas. La experiencia anterior
(de todas las personas involucradas) puede ayudar en gran medida al desarrollo y revisión de
las estimaciones. Y, dado que la estimación es la base de todas las demás actividades de planificación
del proyecto, y que sirve como guía para una buena ingeniería del software, no es en
absoluto aconsejable embarcarse sin ella.
¿Qué es? La planificación de un proyecto
de software realmente comprende
todas las actividades tratadas en los
Capítulos 5 al 9. Sin embargo, en el
contexto de este capítulo, la planificación
implica la estimación -su intento
por determinar cuánto dinero,
esfuerzo, recursos, y tiempo supondrá
construir un sistema o producto específico
de software-.
&Quién lo hace? Los gestores del software
-utilizando la información solicitada
a los clientes y a los ingenieros
de software y los datos de métricas de
software obtenidos de proyectos anteriores-.
por qué es importante? &Podríac onstruir
una casa sin saber cuanto estaría
dispuesto a gastar?. Por supuesto qve
no, y puesto que la mayoría de los sistemas
y productos basados en computadora
cuestan considerablemente más
que construir una casa grande, podría
sBr razonable desurrollar y estima antes
de empezar a construir el software.
¿Cuáles son los pasos? La estimación
comienza con una descripción del
ámbito del producto. Hasta que no se
ndelimitam el ámbito no es posible realizar
una estimación con sentido. El
problema es entonces descompuesto
en un conjunto de problemas de menor
tamaño y cada uno de éstos se estima
guiándose con datos históricos y con
la experiencia. Es aconsejable realizar
las estimaciones utilizando al menos
dos métodos diferentes (como comprobación).
La complejidad y el riesgo del
problema se considera antes de realizar
una estimación
No hay comentarios:
Publicar un comentario