Actividad 6

Universidad del Sur
Doctorado en Sistemas Computacionales
Presenta:
Alejandro Jarillo Silva
Materia:
Seminario de Ingeniería de Software
Asesor
Dr. Jorge Humberto Ruiz Ovalle.
Número de actividad
Actividad 6. Investigar y realizar un análisis
Julio 2019
Introducción
Pressman plasma las métricas convenientes para el proceso de software, las cuales se
pueden emplear dependiendo del objetivo del estudio. Para ello están las métricas
directas por ejemplo, líneas de código, rapidez de memoria, costo y esfuerzo, defectos
reportados, etc y por otra parte están las métricas indirectas que se relacionan con la
calidad, confiabilidad, complejidad, capacidad de mantenimiento y eficiencia. Es un
hecho que desarrollar instrumentos para métricas indirectas resulta más complejo que
para las directas, además, de que se debe tener mucho cuidado de lo que se quiere
evaluar y lo que realmente se está evaluando. Por ningún motivo se debe valorar al
individuo del equipo, y en caso de hacerlo entonces los resultados del instrumento
deben ser privados.
Durante el desarrollo del software existen diversas etapas, por consiguiente

existen diferentes momentos para evaluar que son: proceso, proyecto y producto. No
obstante, resulta difícil determinar cuando los resultados de las métricas son favorables,
al menos que se cuente con información de un proyecto similar y se pueda hacer una
comparación siempre y cuando las medidas sean normalizadas.
A continuación se presentan las diferentes métricas de software.
Métricas orientadas a tamaño: Durante el proceso de codificación de un software es

posible obtener información básica, por ejemplo el número de líneas de código (LOC)
la cual al pasar por un proceso de normalización se derivan las medidas de calidad y/o
productividad. A partir de la normalización de LOC se tienen métricas simples, por
ejemplo, páginas de documentación por KLOC (miles de líneas de código), $ por
KLOC, defectos por KLOC, errores por KLOC, KLOC por persona-mes, errores por
persona-mes, etc. Se entiende que esta métrica no sea aceptada como la mejor manera
de medir un proceso de software, la variedad de lenguajes de programación de hoy en
día está creciendo, y esto de alguna manera impacta en el número de las líneas de
código. Se puede tener en cuenta esta métrica siempre y cuando la comparación se haga
con proyectos desarrollados bajo los mismos lenguajes de programación. Otro
problema para aplicar esta métrica radica en la existencia de proyectos muy semejantes,
de lo contrario se carece de una referencia sólida que pueda respaldar si los resultados
de la métrica son mejores o no tan mejores.
Métricas orientadas a función: Una manera de no involucrar las líneas de código

como una medida de productividad en el desarrollo del software es emplear la
funcionalidad entregada por aplicación como un valor de normalización. Si bien la
función de mayor uso que se entiende como el PF (punto de función), el cual tiene
características de dominio y de la complejidad de información del software es
independiente del lenguaje de programación carece de significado propio y su
interpretación se basa en algo subjetivo. No obstante, aunque esta métrica mide hasta
cierto punto la productividad se debe pensar en que la calidad es un factor importante
dentro de la evaluación del desarrollo de software.
Métricas orientadas a objeto: Las métricas basadas en LOC y PF carecen de detalle

para los ajustes de calendario y esfuerzos a través de un proceso evolutivo, lo cual las
hace insuficientes para ser candidatas a medidas orientadas a objeto. Lorentz y Kidd
sugieren contemplar las siguientes métricas: 1.- número de guiones de escenarios que se
relacionan directamente con el tamaño de la aplicación, 2.-número de clases clave que
se definen como componentes enormemente independientes, número de clase de apoyo
que se requieren para implementar el sistema (clases de GUI, clases de acceso, de
manipulación, etc), 3.- promedio de clases de apoyo por clases clave esto se ve reflejado
en la optimización de los procesos y de los recursos y 4.- número de subsistemas que es
un agregado de clases que apoyan a una función que es visible para el proyecto. Además
de las métricas mencionadas se pueden emplear como complementarias métricas de
esfuerzo empleado, errores y defectos descubiertos, y modelos o páginas de
documentación.
Métricas orientadas a caso de uso: Al igual que el PF el caso de uso se define al

principio del proceso de software y permite establecer una estimación de tiempos y
esfuerzo. Los casos de uso describen de manera directa las funciones y características
visibles con las que el usuario va interactuar, además, de que no dependen del lenguaje
de programación el número de casos de uso es directamente proporcional al tamaño de
la aplicación en LOC. Sin embargo, debido a que los casos de uso pueden crearse en
diferentes niveles de abstracción no existe un tamaño estándar, lo que causa
controversia al contemplarla como medida de normalización. A partir de este hecho se
propone emplear puntos de casos de uso PCU que involucra a los actores y
transacciones provenientes de los modelos de caso de uso.
Métricas de proyecto webapp: cuando el sistema o el software se basa en entregar al

usuario final una combinación de contenido y funcionalidad entonces es posible
emplear métricas de proyecto webapp. A partir del desarrollo de una base de datos se
puede obtener información relacionada con medidas productivas y de calidad como por
ejemplo:
a) Número de páginas web estáticas: las cuales en teoría deben ser de una
complejidad baja y en consecuencia de un esfuerzo de desarrollo menor debido a

que son solo interfaces informativas para el usuario.
b) Número de páginas dinámicas: debido a que en ellas el usuario tiene el control
parcial o total su complejidad de desarrollo aumenta al igual que el esfuerzo en

comparación con las estáticas.
c) Número de vínculos de páginas internas; están relacionadas con los punteros que
proporcionan un enlace. Esta métrica da un indicio del grado de acoplamiento

arquitectónico. En consecuencia entre mayor punteros mayor esfuerzo.
d) Número de objetos de datos persistentes: sin duda alguna cuando la interfaz
además de ser dinámica y de contar con punteros está conectada a una base de
datos, el grado de complejidad y esfuerzo aumenta gradualmente.
e) Número de sistemas expertos puestos en la interfaz: se refiere a las interfaces con
aplicaciones de tipo empresarial, conforma aumenta los requerimientos por GUI

aumenta la complejidad.
f) Número de objetos estáticos: se relacionan con la parte de contenido de la GUI
por ejemplo, texto, gráficas, video, animación, etc. Su complejidad es baja y en

consecuencia su esfuerzo también.
g) Número de objetos dinámicos: se basan en las acciones del usuario final y
contemplan información relacionada con texto, video, gráficas, etc. Si aumentan

el número de objetos dinámicos aumenta la complejidad y el esfuerzo.
h) Número de funciones ejecutables: proporcionan servicio computacional al
usuario final.
A partir de estas medidas es posible al hacer una comparación con proyectos semejantes
obtener una estimación de tiempo y esfuerzo. No obstante, hoy en día se cuentan con
una gran variedad de herramientas tecnológicas para las webapps esto puede originar
una ambigüedad al hablar de grado de complejidad.
Conclusiones
A partir de las diferentes métricas de software es posible determinar desde los

inicios del desarrollo de un software y en cada etapa una estimación de esfuerzo y
tiempo. Para ello el equipo de trabajo debe plasmar desde el inicio las métricas que va
emplear durante el proceso de desarrollo no perdiendo el objetivo de optimizar los
tiempos y recursos durante cada tarea asignada. En función del tipo de proyecto y sus
alcances se requieren diferentes parámetros de medición, los cuales deben estar a la
medida.
Bibliografía
Roger, S. P. (2010). Ingeniería de Software: Un enfoque práctico. McGraw Hill.

Actividad 6

Cargado por

Copyright:

Formatos disponibles

Actividad 6

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Actividad 6

Cargado por

Copyright:

Formatos disponibles

Universidad del Sur

Doctorado en Sistemas Computacionales

Alejandro Jarillo Silva

Seminario de Ingeniería de Software

Dr. Jorge Humberto Ruiz Ovalle.

Actividad 6. Investigar y realizar un análisis

Durante el desarrollo del software existen diversas etapas, por consiguiente

A continuación se presentan las diferentes métricas de software.

Métricas orientadas a tamaño: Durante el proceso de codificación de un software es

Métricas orientadas a función: Una manera de no involucrar las líneas de código

Métricas orientadas a objeto: Las métricas basadas en LOC y PF carecen de detalle

Métricas orientadas a caso de uso: Al igual que el PF el caso de uso se define al

Métricas de proyecto webapp: cuando el sistema o el software se basa en entregar al

complejidad baja y en consecuencia de un esfuerzo de desarrollo menor debido a

parcial o total su complejidad de desarrollo aumenta al igual que el esfuerzo en

proporcionan un enlace. Esta métrica da un indicio del grado de acoplamiento

aplicaciones de tipo empresarial, conforma aumenta los requerimientos por GUI

por ejemplo, texto, gráficas, video, animación, etc. Su complejidad es baja y en

contemplan información relacionada con texto, video, gráficas, etc. Si aumentan

A partir de las diferentes métricas de software es posible determinar desde los

También podría gustarte