Beruflich Dokumente
Kultur Dokumente
ID : 916755
Ciclo : V
Bloque : 72PDSDE502
2019
2
Dedicatoria .
el inspirador y darnos fuerza para continuar en este proceso de obtener uno de los
A mis padres por su amor, a mi hija Nazaret y a mi pareja Naomi por estar a
Agradecimiento .
de debilidad.
sigo adelante, y como dice mi padre “Del Cuero sale las Correas”. Gracias papá.
3
Misión .
Visión .
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 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
interno.
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.
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.
Objetos (0B)
Relaciones (RE)
Estados (ES)
Transiciones (TR)
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).
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.
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.
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
Métricas Públicas:
12
Estimación de Costos y Algoritmos
Fase 2: Mapeo.
Fase 3: Medición.
13
Modelo COCOMO, Niveles y Efectos de Reutilización
Donde:
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
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
MODO a b
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
De Software
16
De Hardware
De Personal
De proyecto
17
18
COCOMO Detallado
Repetitividad.
Reproducibilidad.
Imparcialidad.
Objetividad.
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