1

Nombre : Victor Raul

Apellidos : Huaman Aybar

ID : 916755

Carrera : Desarrollo de Software

Ciclo : V

Bloque : 72PDSDE502

Curso : Calidad de Software

Instructor : Loaiza Clarck, Luis Enrique

Campus : UPC San Juan de Miraflores

Tema : Informe de Análisis de Métrica,

Normas y Estándares de calidad

2019

2
Dedicatoria .

El presente trabajo investigativo lo dedicamos principalmente a Dios, por ser

el inspirador y darnos fuerza para continuar en este proceso de obtener uno de los

anhelos más deseados.

A mis padres por su amor, a mi hija Nazaret y a mi pareja Naomi por estar a

mi lado en cada momento que pase en la vida.

Agradecimiento .

Agradecemos a Dios por bendecirnos la vida, por guiarnos a lo largo de

nuestra existencia, ser el apoyo y fortaleza en aquellos momentos de dificultad y

de debilidad.

Gracias a mi pareja y a mi padres por apoyarme en mis estudios, gracias a ellos

sigo adelante, y como dice mi padre “Del Cuero sale las Correas”. Gracias papá.

3
Misión .

Formar y capacitar a las personas para empleos dignos y de alta

productividad, en apoyo a la industria nacional en el contexto global, y para

contribuir a la mejora de la calidad de vida de la sociedad.

Visión .

En el año 2013, el SENATI ha consolidado su posición de liderazgo

en el Perú y América Latina, en educación para el desarrollo de la empleabilidad y

de la competitividad de las unidades productivas.

Objetivo .
 Contribuir al incremento de la productividad y al desarrollo del sector
industrial manufacturero y de los demás sectores productivos, mediante la
formación y la capacitación profesional.
 Contribuir al desarrollo del potencial humano para mejorar la empleabilidad
a través de la formación y capacitación profesional.
 Responder efectivamente a la demanda de calificación para el trabajo de los
sectores productivos.
 Contribuir a mejorar la educación del personal técnico profesional con los
últimos avances tecnológicos.
 Propiciar la permanente satisfacción de sus clientes en la formación y la
capacitación profesional, así como en los servicios técnicos y empresariales
que brinde.

4
Métrica de diseño y alto nivel
Métricas de diseño. Permiten medir de forma cuantitativa la calidad de los
atributos internos del software. Esto permite al ingeniero evaluar la calidad
durante el desarrollo del sistema.

Atributos de calidad
Las métricas se centran en cuantificar tanto la complejidad, como la
funcionalidad y eficiencia inmersa en el desarrollo de software. Inclina sus
objetivos a mejorar la comprensión de la calidad del producto, a estimar la
efectividad del proceso y mejorar la calidad del trabajo.

Las métricas empleadas están diseñadas para evaluar los siguientes atributos
de calidad:

1. Responsabilidad
a. Consiste en la responsabilidad asignada a una clase en un marco de
modelado de un dominio o concepto, de la problemática propuesta.
2. Complejidad de implementación
a. Consiste en el grado de dificultad que tiene implementado un diseño
de clases determinado.
3. Reutilización
a. Consiste en el grado de reutilización presente en una clase o
estructura de clase, dentro de un diseño de software.
4. Acoplamiento
a. Consiste en el grado de dependencia o interconexión de una clase o
estructura de clase, con otras, está muy ligada a la característica de
Reutilización.
5. Complejidad del mantenimiento
a. Consiste en el grado de esfuerzo necesario a realizar para desarrollar
un arreglo, una mejora o una rectificación de algún error de un diseño
de software. Puede influir indirecta, pero fuertemente en los costes y
la planificación del proyecto.
6. Cantidad de pruebas
a. Consiste en el número o el grado de esfuerzo para realizar las
pruebas de calidad (Unidad) del producto (componente, módulo,
clase, conjunto de clases, etc.) diseñado.

5
La Métrica de Alto Nivel
Las métricas de alto nivel nos ayudan a localizar los módulos más complejos
y, por lo tanto, aquellos en los que debemos poner especial atención. También es
utilizada para saber el número de módulos asignados a cada trabajador:

 PRUEBAS DE CAJA NEGRA

 Pruebas de cubrimiento

Permiten ejecutar al menos una vez cada sentencia, para la cual se

necesitan varios casos de prueba que permitan:

 Pruebas de condiciones

Este tipo de pruebas, permiten cumplir o no, partes de una condición para
ello, se necesitan varios casos de prueba:

 Pruebas de bucles

Se utilizan para conseguir números de repeticiones especiales a través de

bucles simples:

1. Probar el desempeño del sistema en su entorno.

2. Enfocarse en las entradas y salidas, independiente de su funcionamiento

interno.

3. Enfocarse en asegurar que la comunicación entre módulos o componentes

del sistema sea acorde a lo especificado.

4. Pruebas en que se conoce sólo la interfaz.

5. Se procura ejercitar cada elemento de la interfaz.

6
 Como ya se ha visto por las distintas métricas estudiadas, la complejidad de
un programa crece con su tamaño dependiendo de la estructura, módulos: los
programas largos son más difíciles de escribir y comprender, contienen
habitualmente más errores y son más complejos a la hora de analizar, su
depuración resulta más compleja. Con objeto de reducir esta complejidad, los
diseñadores de software han hecho un uso progresivo de técnicas de
modularización y diseño estructurado

7
Medidas de Complejidad y Métricas de Código Fuente
La métrica de complejidad más ampliamente usada (y debatida) para el
software es la complejidad ciclomática, originalmente desarrollada por Thomas
McCabe. La métrica de McCabe proporciona una medida cuantitativa para probar
la dificultad y una indicación de la fiabilidad última.

Estudios experimentales indican una fuerte

correlación entre la métrica de McCabe y el número
de errores que existen en el código fuente, así como
el tiempo requerido para encontrar y corregir dichos
errores. McCabe [Pressman ´98] también defiende
que la complejidad ciclomática puede emplearse para
proporcionar una indicación cuantitativa del tamaño
máximo del módulo.

Recogiendo datos de varios proyectos de programación reales, ha

averiguado que una complejidad ciclomática de 10 parece ser el límite práctico
superior para el tamaño de un módulo, Cuando la complejidad ciclomática de los
módulos excedía ese valor, resultaba extremadamente difícil probar
adecuadamente el módulo.

8
Métrica para las Pruebas
Aunque se ha escrito mucho sobre métricas del software para pruebas, la
mayoría de las métricas propuestas se concentran en el proceso de pruebas, no
en las características técnicas de las pruebas mismas.

La métrica bang puede proporcionar una indicación del número de casos de prueba
necesarios para examinar las medidas primitivas.

 Primitivas funcionales (Pfu)

 Elementos de Datos (ED)

 Objetos (0B)

 Relaciones (RE)

 Estados (ES)

 Transiciones (TR)

Pueden emplearse para predecir el número y tipos de pruebas de la caja negra y

blanca del software.

9
Métricas para el Mantenimiento
Se han propuesto métricas diseñadas explícitamente para actividades de
mantenimiento. El estándar IEEE 982.1-1988 sugiere un Índice de Madurez del
Software (IMS) que proporciona una indicación de la estabilidad de un 101
producto de software (basada en los cambios que ocurren con cada versión del
producto).

Se determina la siguiente información:

 Mr = número de módulos en la versión actual

 Fc = número de módulos en la versión actual que se han cambiado
 Fa = número de módulos en la versión actual que se han añadido
 Fd = número de módulos de la versión anterior que se han borrado en
la versión actual.

El índice de madurez del software se calcula de la siguiente manera:

[𝑀𝑟 − (𝐹𝑎 + 𝐹𝑐 + 𝐹𝑑)]

𝐼𝑀𝑆 = (4.39)
𝑀𝑟

A medida que el IMS se aproxima a 1.0 el producto se empieza a estabilizar.

El IMS puede emplearse también como métrica para la planificación de las

actividades de mantenimiento del software.

Predecir la Calidad y Métrica del Producto

Cualquier cosa que queramos medir o predecir en un software es un
atributo de cualquier entidad de un producto, proceso o recurso asociado a éste.

Es por eso que se necesita hacer una distinción entre atributos que son internos o externos y
medidas directas e indirectas:

10
Atributos Internos y Atributos Externos

Los atributos internos de un producto, proceso o recurso son aquellos que podemos medir
puramente en términos del producto, proceso o recurso del mismo. Pueden ser medidos
directamente.

Por ejemplo: la longitud de un programa o el tiempo transcurrido de cualquier

documento de software.

Los atributos externos de un producto, proceso o recurso son aquellos que solamente
pueden ser medidos con respecto al cómo el producto, proceso o recurso se relacionan a su
ambiente.

Estos tienden a ser los que el administrador y el usuario del software comúnmente gustan de
medir y predecir.

Por ejemplo el administrador de software le gustaría saber el costo de eficacia de

algunos procesos o de la productividad de su personal, mientras los usuarios les gustarían
saber la usabilidad, fiabilidad, o portabilidad de un sistema que ellos observan 16 para
comprar. Desgraciadamente los atributos externos son los más difíciles de medir, porque
estos no pueden ser medidos directamente .En la tabla 3.1 se describe la estructura, y se dan
ejemplos de varios tipos de atributos.

Medidas Directas y Medidas Indirectas

La medida directa de un atributo es aquella, en donde no depende de cualquier otro

atributo.

La medida Indirecta de un atributo es aquella en la que se involucra la medición de

uno o más atributos.

11
Métricas de Proceso y Costos

Métricas Privadas:

Solo es conocido por el equipo de proyecto, pero públicas por todos los miembro del equipo

 Índice de defecto por individuo o modulo.

 Líneas de códigos o puntos de función por modulo y función.
 Errores encontrados durante la versión de técnicas formales.

Métricas Públicas:

Asimilan información que originalmente era privada de particulares y equipos permitiendo a

las organizaciones hacer los cambios estratégicos para mejorar el proceso del software.

 Índice de defecto nivel de proyecto

12
Estimación de Costos y Algoritmos

Para determinar la estimación del software a desarrollar, primero debemos seleccionar

un método para medir su tamaño. Para el ejemplo de estimación de costos de un proyecto de
software utilizaremos el análisis de puntos de función por medio del método COSMIC.

COSMIC es un método de análisis de puntos de función de segunda generación, en el cual

se determina el tamaño funcional del software a partir del número de interacciones entre los
procesos funcionales.

Los pasos para realizar esta medición son los siguientes:

Fase 1: Estrategia de medición.

Fase 2: Mapeo.

Fase 3: Medición.

El tamaño de un software es la principal variable necesaria para determinar el esfuerzo de

desarrollo que deberá invertirse para implementarlo. La medición y estimación de software
utilizando COSMIC, es un método de segunda generación que determina el tamaño del
software a partir del número de interacciones entre los componentes de los requerimientos
funcionales.
Estandarizado bajo la ISO 19761, el método COSMIC puede aplicarse a diversos tipos de
software, incluyendo aplicaciones de negocios, sistemas de información gerencial, software
en tiempo real, infraestructura, e inclusive software científico y de ingeniería.

13
Modelo COCOMO, Niveles y Efectos de Reutilización

El Modelo Constructivo de Costos (COCOMO) es una jerarquía de modelos de

estimación de costes software que incluye
submodelos básico, intermedio y detallado.

Las ecuaciones que se utilizan en los tres modelos son:

Donde:

 E es el esfuerzo requerido por el proyecto, en persona-mes

 Tdev es el tiempo requerido por el proyecto, en meses
 P es el número de personas requerido por el proyecto
 a, b, c y d son constantes con valores definidos, según cada submodelos
 Kl es la cantidad de líneas de código, en miles.
 m(X) es un multiplicador que depende de 15 atributos.

COCOMO 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.40 1.05 2.50 0.38

Semi - Orgánico 3.00 1.12 2.50 0.35

Empotrado 3.60 1.20 2.50 0.33

14
Estos valores son para las fórmulas:

 Personas necesarias por mes para llevar adelante el proyecto (MM) = a*(Klb)
 Tiempo de desarrollo del proyecto (TDEV) = c*(MMd)
 Personas necesarias para realizar el proyecto (CosteH) = MM/TDEV
 Costo total del proyecto (CosteM) = CosteH * Salario medio entre los programadores y
analistas.

Se puede observar que a medida que aumenta la complejidad del proyecto (modo),
las constantes aumentan de 2.4 a 3.6, que corresponde a un incremento del
esfuerzo del personal. Hay que utilizar con mucho cuidado el modelo básico puesto
que se obvian muchas características del entorno.

COCOMO Intermedio

Este añade al modelo básico quince modificadores opcionales para tener en

cuenta en el entorno de trabajo, incrementando así la precisión de la estimación.

Para este ajuste, al resultado de la fórmula general se lo multiplica por el

coeficiente surgido de aplicar los atributos que se decidan utilizar.

Los valores de las constantes a reemplazar en la fórmula son:

MODO a b

Orgánico 3.20 1.05

Semi - Orgánico 3.00 1.12

Empotrado 2.80 1.20

15
Se puede observar que los exponentes son los mismos que los del modelo básico,
confirmando el papel que representa el tamaño; mientras que los coeficientes de
los modos orgánico y rígido han cambiado, para mantener el equilibrio alrededor
del semilibre con respecto al efecto multiplicador de los atributos de coste.

Atributos

Cada atributo se cuantifica para un entorno de proyecto. La escala es muy

bajo - bajo - nominal - alto - muy alto - extremadamente alto. Dependiendo de la
calificación de cada atributo, se asigna un valor para usar de multiplicador en la
fórmula (por ejemplo, si para un proyecto el atributo DATA es calificado como muy
alto, el resultado de la fórmula debe ser multiplicado por 1000).

El significado de los atributos es el siguiente, según su tipo:

De Software

- RELY: garantía de funcionamiento requerida al software. Indica las posibles

consecuencias para el usuario en el caso que existan defectos en el producto. Va
desde la sola inconveniencia de corregir un fallo (muy bajo) hasta la posible pérdida
de vidas humanas (extremadamente alto, software de alta criticidad).
- DATA: tamaño de la base de datos en relación con el tamaño del programa. El
valor del modificador se define por la relación: D/K, donde D corresponde al
tamaño de la base de datos en bytes y K es el tamaño del programa en cantidad
de líneas de código.
- CPLX: representa la complejidad del producto.

16
De Hardware

- TIME: limitaciones en el porcentaje del uso de la CPU.

- STOR: limitaciones en el porcentaje del uso de la memoria.
- VIRT: volatilidad de la máquina virtual.
- TURN: tiempo de respuesta requerido.

De Personal

- ACAP: calificación de los analistas.

- AEXP: experiencia del personal en aplicaciones similares.
- PCAP: calificación de los programadores.
- VEXP: experiencia del personal en la máquina virtual.
- LEXP: experiencia en el lenguaje de programación a usar.

De proyecto

- MODP: uso de prácticas modernas de programación.

- TOOL: uso de herramientas de desarrollo de software.
- SCED: limitaciones en el cumplimiento de la planificación.

17
18
COCOMO Detallado

Presenta principalmente dos mejoras respecto al anterior:

1. Los factores correspondientes a los atributos son sensibles o dependientes

de la fase sobre la que se realizan las estimaciones. Aspectos tales como la
experiencia en la aplicación, utilización de herramientas de software, etc.,
tienen mayor influencia en unas fases que en otras, y además van variando
de una etapa a otra.
2. Establece una jerarquía de tres niveles de productos, de forma que los
aspectos que representan gran variación a bajo nivel, se consideran a nivel
módulo, los que representan pocas variaciones, a nivel de subsistema; y los
restantes son considerados a nivel sistema.

Normas y Estándares de Calidad

La norma define las principales características del proceso de evaluación.

 Repetitividad.
 Reproducibilidad.
 Imparcialidad.
 Objetividad.

El estándar ISO/IEC 14598 define el proceso para evaluar un producto de

software, el mismo consta de seis partes:

1. ISO/IEC 14598-1 Visión General: provee una visión general de las otras
cinco partes y explica la relación entre la evaluación del producto software
y el modelo de calidad definido en la ISO/IEC 9126.
2. ISO/IEC 14598-2 Planeamiento y Gestión: contiene requisitos y guías para
las funciones de soporte tales como la planificación y gestión de la
evaluación del producto del software.

19
3. ISO/IEC 14598-3 Proceso para desenvolvedores: provee los requisitos y
guías para la evaluación del producto software cuando la evaluación es
llevada a cabo en paralelo con el desarrollo por parte del desarrollador.
4. ISO/IEC 14598-4 Proceso para adquirentes: provee los requisitos y guías
para que la evaluación del producto software sea llevada a cabo en función
a los compradores que planean adquirir o reutilizar un producto de software
existente o pre-desarrollado.
5. ISO/IEC 14598-5 Proceso para avaladores: provee los requisitos y guías
para la evaluación del producto software cuando la evaluación es llevada a
cabo por evaluadores independientes.
6. ISO/IEC 14598-6 Documentación de Módulos: provee las guías para la
documentación del módulo de evaluación.

20
Bibliografía

http://www.pmoinformatica.com/2018/03/ejemplos-de-estimacion-de-costos-de-un-proyecto-
de-software-COSMIC.html
http://www.pmoinformatica.com/2018/02/medicion-estimacion-metodo-cosmic.html
http://www.sc.ehu.es/jiwdocoj/mmis/cocomo.htm

http://evaluaciondesoftware2013.blogspot.mx/
https://es.slideshare.net/eduardo89/estndares-de-calidad-aplicadas-al-software
https://karron10.wordpress.com/2013/04/14/normas-y-estandares-en-
proyectos-de-ti-2/

21