PROCESO DE GESTIÓN DE FORMACIÓN PROFESIONAL INTEGRAL

FORMATO GUÍA DE APRENDIZAJE

IDENTIFICACIÓN DE LA GUIA DE APRENDIZAJE

 Denominación del Programa de Formación: Análisis y Desarrollo de Sistemas de Informacion

 Código del Programa de Formación: 228106
 Nombre del Proyecto : Diseño e implementación de sistemas de información acorde a las
necesidades del sector empresarial de la ciudad de Bogotá
 Fase del Proyecto : Planeación
 Actividad de Proyecto: Codificar los módulos del sistema de información
 Competencia: 220501035 Aplicar buenas prácticas de calidad en el proceso de desarrollo de
software, de acuerdo con el referente adoptado en la empresa.

Resultados de Aprendizaje Alcanzar:

436561 Elaborar instrumentos e instructivos requeridos para el Aseguramiento de la calidad para

documentar y evaluar los procesos de desarrollo de software, de acuerdo con las normas y
procedimientos establecidos por la empresa.

Duración de la Guía: 30 horas ( (22 presenciales) (8 autónomas)

2. PRESENTACIÓN

La calidad busca que el cliente quede satisfecho y conforme con su producto. La calidad en ingeniería
del software es el cumplimiento de los requerimientos contractuales por parte del producto software
desarrollado, así como durante el proceso de desarrollo. La calidad se obtiene mejorando día a día el
proceso de producción, mantenimiento y gestión del software 1. Para optimizar la calidad de los
productos y/o servicios es preciso conocer al cliente y sus necesidades, conocer la competencia y
poseer un modelo de calidad. Esto último permitirá incrementar la fiabilidad, reducir el mantenimiento,
aumentar la satisfacción del cliente, mejorar la dirección del proyecto, detectar errores lo más temprano
posible e incrementar el beneficio para el desarrollador.

La calidad es importante en el desarrollo de un producto o servicio y, más aún, en la creación de un

producto de software, no solo porque busca cumplir con las expectativas del cliente, sino también por
mejorar los procesos internos en la elaboración de un producto, tarea fundamental en el crecimiento y
posicionamiento de una empresa.

2.1. DEDICACION HORARIA

30 horas ( (22 presenciales) (8 autónomas)

2.2. ORIENTACION DEL INSTRUCTOR

El desarrollo del proceso académico para lograr el objetivo de este resultado de aprendizaje, GFPI-F-135
se realizará
V01

mediante asesorías , material de ayuda y utilizando los diferentes medios correspondientes a las
tecnologías de la Información y la comunicación. El Instructor orientará y hará seguimiento a las actividades
de aprendizaje, las cuales serán subidas por el aprendiz a la plataforma territorio.

OBJETOS DE
APRENDIZAJE

MT01 - Aseguramiento de la calidad del software

MT02 - Desarrollo del Sistema de Gestión de la Calidad
MT03 – Manual de calidad .
MT04 - Pasos basicos para realizar un informe de gestion de calidad
MT05 - Actividades de control de calidad del software.
MT06 - Métricas para la calidad del software
MT= Marco Teórico

2.3 ENCUENTROS SINCRONICOS

Los encuentros sincrónicos para cumplir con la planeación pedagógica del trimestre serán programados de
acuerdo con los horarios establecidos a cada ficha.

3. FORMULACIÓN DE LAS ACTIVIDADES DE APRENDIZAJE

3.1. Descripción de las actividades:

3.2 Actividad de Reflexión inicial:

Objetivo : Adquirir conocimiento sobre los conceptos básicos de aseguramiento de la calidad.

Actividad: Definir cada una de las respuestas de las siguientes preguntas. Presentar el archivo en un
documento de Word.
En el siguiente encuentro sincrónico se socializarán los diferentes conceptos.

1.Qué se entiende por calidad

2 .Qué busca un sistema de gestión de la calidad
3 . Implementación de un sistema de gestión de la calidad
4. Evaluación de la situación actual
5. Análisis de los procesos de la empresa
6. Documentación necesaria para la certificación
7. Comunicación y capacitación del personal
8.  Implantación del sistema de gestión de calidad
9. Auditoría interna y Revisión
10. Aplicación de medidas correctoras
11. Pre-auditoría y Auditoría de certificación
12.  Curso de  sistemas de gestión de calidad
13.  Certificado del sistema de gestión de calidad GFPI-F-135 V01
14. Norma ISO 9000 Y 10012
15. Definir que es sistema de gestión de la medición
16. Proceso de medición
17. Describir que es un equipo de medición

3.3 Actividad de Apropiación: - desempeño AP06-AA2- EV02-

Objetivo: Medir la calidad del diseño de un software.

Actividad: (Ver formato de evidencia AP06-AA2-Desempeño)-( DESCRIPCIÓN DE LA EVIDENCIA.

desempeño AP06-AA2)
.

3.4 Documentos asociados a la evidencia de desempeño:

 Archivo del documento diseñado como encuesta en Google forms.

 Archivo tabulado de las respuestas de las encuestas.
 Norma ISO 9000 Y 10012

3.5 Forma de entrega de la evidencia de desempeño

El archivo con la encuesta diseñada en Google forms

El archivo de tabulación

Subir estos dos archivos en la plataforma territorio, de acuerdo con el link enviado por el instructor.

3.6 Evidencia de conocimiento-AP06-AA1-EV01- Conocimiento

Objetivo: Afianzar conocimientos sobre aseguramiento de la calidad.

Actividad: (Ver formato evidencia AP06-AA1-Conocimiento- Evidencia de conocimiento-AP06-AA1-)

.

3.7 Documentos asociados a la evidencia de conocimiento.

Archivo de las diapositivas diseñadas en power point.

3.8 Forma de entrega de la evidencia de Conocimiento: 

Exposición en sesión sincrónica acordada con el Instructor

3.9 Evidencia de producto - AP06-AA3-EV03-Informe final de gestión

Objetivo: Elaborar el informe final del proceso de gestión de validación de la calidad en el desarrollo del
software.

Actividad: (Ver formato evidencia AP06-AA3-Producto. ( DESCRIPCIÓN DE LA EVIDENCIA. Evidencia

de producto - AP06-AA3)

3.10 Forma de entrega de la evidencia de producto

GFPI-F-135 V01
Sustentación en el encuentro sincrónico con el Instructor. Una vez aprobada la sustentación , el aprendiz
debe subir los archivos a la plataforma territorio.
 MT01 - ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

El aseguramiento de la calidad (ACS), es una actividad que se aplica a todo el proceso del software. El ACS
incluye procedimientos para la aplicación eficaz de métodos y herramientas, supervisa las actividades de
control de calidad, tales como revisiones técnicas y las pruebas del software, procedimientos para la
administración de cambio y elaboración de reportes. Para llevar a cabo el aseguramiento de la calidad del
software de manera adecuada, deben recabarse, evaluarse y divulgase datos sobre el proceso de ingeniería
de software. Los métodos estadísticos aplicados al ACS ayudan a mejorar la calidad del producto y del
proceso de software mismo .

El sistema de gestión de calidad

El aseguramiento de la calidad consiste en el seguimiento de unas líneas de actuación planificadas y

sistemáticas, implantadas dentro del Sistema de Gestión de Calidad de la empresa. Estas acciones deben
ser demostrables con el objeto de proporcionar la confianza adecuada, tanto a la propia empresa como a los
clientes y proveedores.

MT02 -Desarrollo del Sistema de Gestión de la Calidad

Los sistemas de aseguramiento de la calidad tienen una gran carga documental puesto que requieren de
una planificación exhaustiva, definición de tareas y responsabilidades, registro de resultados obtenidos y
pautas de inspecciones internas continuas, teniendo que ser todo ello soportado en documentos para
su consulta, guía y verificación. Por norma general, está documentación está compuesta por:

Un manual de calidad que debe incluir:

 Presentación de la empresa, política y objetivos sobre calidad, organigrama y funciones.

 Procedimientos de aseguramiento de la calidad y operativos:Sirven para dar respuesta y desarrollar
las pautas fundamentales del manual de calidad.
 Instrucciones de trabajo y especificaciones.
 Registro de las actividades realizadas.

MT03 MANUAL DE CALIDAD

Para llevar a cabo un eficaz sistema de gestión, las empresas necesitan reflexionar y describir cómo va a
ser ese proceso, en qué políticas se van a basar, cuál va a ser su alcance, qué procedimientos se van a
lleva a cabo o qué medidas de control se van a establecer. Todas estas cuestiones encuentran su respuesta
GFPI-F-135 V01
en el manual de calidad, un documento que en la nueva versión de la norma no es obligatorio, pero
que servirá de guía para la implementación, mantenimiento y mejora del Sistema de Gestión de Calidad.
 En este manual se expresan tanto los requerimientos internos, los del cliente y los requisitos necesarios
para la certificación, si se desea obtener.

 Funciones, uso y beneficios de su empleo:

Se trata de un documento de la empresa que expone los aspectos principales del sistema de calidad
implantado por la empresa. Si así lo desea la organización, puede adoptar la forma de documento público
que se puede presentar a clientes reales o potenciales, proveedores y otros agentes interesados.

Sus finalidades principales son comunicar los logros y objetivos en el ámbito de la calidad de la organización
para que se conozcan sus intenciones y compartir conocimientos y experiencias en el ámbito tanto interno
como externo.

Por otro lado, el manual de calidad permite a la empresa realizar un ejercicio de transparencia, conformidad
e implicación con la consecución de altos niveles de calidad y mejora continua de acuerdo a una serie de
parámetros previamente establecidos. Es el documento más auditado, pues se encuentra en el vértice más
alto de la documentación de las compañías.

Alcance del manual de calidad:

Este aspecto es bastante flexible y depende en gran medida del tamaño y complejidad de cada empresa y
de los fines del documento, ya que algunas organizaciones deciden ampliar su utilidad más allá de
documentar sus sistemas de gestión de la calidad.

Cada organización, por lo tanto, puede decidir libremente el alcance y ambición de su manual, lo que
lógicamente influirá en su estructura, aspectos recogidos y extensión. Eso sí, se trata de un texto que debe
ser elaborado por integrantes que tengan un buen conocimiento de la organización.

Dado que el Manual de Calidad es un documento que constituye la base de todo sistema de calidad, es
importante que vaya un paso por delante y que no se límite únicamente satisfacer los requisitos de la
norma, incluyendo aspectos relativos a las necesidades de los clientes y de la propia organización.

Todo manual de calidad ha de reflejar unos elementos mínimos que ayuden a visualizar los procedimientos
que se van a llevar a cabo para el control de la calidad del producto o servicio ofertado por la compañía.

Este documento debe incluir tres elementos mínimos, que son:

 El alcance del sistema de gestión. GFPI-F-135 V01

 Los procedimientos establecidos para el sistema
 Una descripción de la interacción entre los procesos.
 El Manual de Calidad según la norma ISO 9001

1. Título y alcance: ...

2. Tabla de contenido: ...
3. Documentos: ...
4. Política y objetivos: ...
5. Estructura: ...
6. Referencias: ...
7. Descripción del sistema: ...
8. Anexos:

Título y alcance:
Es una especie de preámbulo del documento. En esta parte se presenta el trabajo y se relaciona con la norma
que se toma como referencia, en este caso la ISO 9001. A veces también es posible enlazarla con los
estándares de mejora continua, como por ejemplo la norma ISO 9004 o la norma ISO 14001.
2. Tabla de contenido:
En ella se indican las secciones que integran el documento en su totalidad y todo lo que la empresa considere
necesario para avalar su Gestión de Calidad.
3. Documentos:
Para que el texto tenga validez, deben incluirse los documentos de ISO que acrediten la certificación de la
norma ISO 9001.
4. Política y objetivos:
Toda política de calidad requiere de unos objetivos. En esta parte del documento deben mencionarse, aunque
sin proporcionar demasiados detalles.
5. Estructura:
¿Cómo está estructurada la empresa en la Gestión de Calidad? En esta parte es preciso incluir cargos,
responsabilidades, niveles directivos e interrelaciones derivadas de la estructura de calidad. Pueden incluirse
diagramas u otros recursos visuales.
6. Referencias:
El documento debe establecer relación con otros textos o fuentes de información que le sirvan de marco para
definir su Manual de Calidad.
7. Descripción del sistema:
Es la parte central del manual. Todos los aspectos que anteriormente se han enunciado confluyen en este
apartado. La descripción pone el foco en cada uno de los métodos que emplea la organización para satisfacer
sus necesidades en el área de Gestión de Calidad. Lo ideal es puntualizar cada elemento y no dejar cabos
sueltos.
8. Anexos:
Finalmente, los redactores del manual pueden incluir en esta sección cualquier texto, informe, valoración o
diagrama que sirva de apoyo al tema central. No hay que olvidar que, además de estar dirigido a los integrantes
de la propia organización, el documento también tiene como destinatarios los auditores y los clientes.
GFPI-F-135 V01
 

ISOTools, instrumento para la gestión de documentos

La herramienta ISOTools te ofrece diversas funcionalidades con las que podrás automatizar el Sistema de
Gestión de Calidad y simplificar todo el proceso.

Sin embargo, no es la única ventaja que te ofrece este instrumento. ISOTools te permite gestionar todos los
documentos relacionados con la norma, como el manual de calidad, revisarlos, controlar los cambios,
registrarlo, incluso distribuirlo.

 
MT04- PASOS BASICOS PARA REALIZAR UN INFORME DE GESTION DE CALIDAD

Un informe de gestión es un documento que recopila un conjunto de datos que se han efectuado
durante un período de tiempo en una empresa

A)Encabezado:

Para empezar la redacción del documento propiamente dicho, el autor del mismo debe tener en cuenta
información básica en relación a ciertos aspectos que son, en últimas, el marco o contexto del informe.
Dichos aspectos son:

B)Tipo de documento.

 Período correspondiente de la gestión.

 Departamento que lo elabora.
 Empresa u organismo.
 A quién o a quiénes va dirigido.

C)Introducción:

Se trata de un texto breve en el que deben quedar claros los motivos por los que se lleva a cabo la
redacción del documento, cuál es su objetivo principal, con qué herramientas o recursos se ha realizado
y quiénes lo han hecho. En últimas, es una ampliación de los puntos enunciados en el encabezado.

D)Desarrollo del informe:

También se le denomina cuerpo del documento. En él, se desarrolla el contenido del texto, cuya extensión,
complejidad y profundidad dependerán de los objetivos con que se haya concebido su redacción y de la
naturaleza de las actividades que se retraten. Por ejemplo, el informe de gestión de una cadena de
supermercados de alcance nacional no tendrá el mismo desarrollo que el de una frutería de barrio. Pese a
estas diferencias, es posible destacar algunos puntos genéricos:
GFPI-F-135 V01

E)Antecedentes:
Fuentes de información

Metodología

Problemas encontrados

Otros datos relevantes

F)Conclusiones y recomendaciones:

Es una exposición concreta en ambos sentidos. Sobre las conclusiones, es necesario mencionar
brevemente aquellos aspectos relevantes que ha dejado la elaboración del informe y que pueden ayudar al
lector a tener una visión sintética de todo el proceso. En cuanto a las recomendaciones, deben ser realistas
y útiles para la empresa de cara a la implementación de mejoras en los procesos descritos o la elaboración
de documentos futuros y similares al que se presenta.

MT05- ACTIVIDADES DE CONTROL DE CALIDAD DEL SOFTWARE

Las actividades de Control de Calidad tienen como objetivo comprobar si un producto posee o no posee
una determinada característica de calidad en el grado requerido. Cuando un producto no posee una
determinada característica de calidad se dice que tiene un DEFECTO. Por lo tanto, se puede decir también
que el objetivo del Control de Calidad es identificar defectos en el producto y corregirlos. Se pueden
clasificar las actividades de control de calidad en dos categorías:

Controles estáticos.

Controles dinámicos.

Los controles estáticos analizan el objeto sin necesidad de ejecutarlo mientras que los dinámicos requieren
la ejecución del objeto que está siendo probado. La barrera entre controles estáticos y dinámicos no es
totalmente estricta. Cualquier forma de control dinámico requiere un cierto grado de análisis estático.
Además hay algunas técnicas, como la verificación formal y la ejecución simbólica, consideradas como
estáticas, que “ejecutan” el código, aunque en un entorno no real.

Controles estáticos manuales informales. Estas actividades las realizan los propios autores de los
objetos a comprobar, o personas de su misma categoría y ocupación.

Comprobación de escritorio (desk checking): Consiste en examinar a mano e individualmente el

objeto que se acaba de desarrollar. Es el método más tradicional para analizar un programa. Se debe
GFPI-F-135 V01
aplicar a los requisitos, especificaciones de diseño y código según se van desarrollando. Debe ser
cuidadoso y concienzudo para que sea efectivo. Es más efectivo si se hace intercambiando el objeto
a examinar con otro compañero.

Revisión por pares o iguales: Consiste en la revisión del código de un programador por otros
programadores (sus pares). Se puede poner en práctica creando un panel que se encarga de revisar
periódicamente muestras de código.

Controles estáticos manuales disciplinados. Las revisiones y auditorías son la evolución natural
de la Comprobación de Escritorio, pero a diferencia de aquélla pasan a ser técnicas de grupo. Su
misión principal es conseguir que la responsabilidad del control de calidad no recaiga sólo sobre el
propio desarrollador.

MT06-MÉTRICAS PARA LA CALIDAD DEL SOFTWARE

El objetivo de la ingeniería del software es desarrollar y producir software de alta calidad. Para lograr este
objetivo, es fundamental aplicar métodos y herramientas efectivos dentro del contexto de un proceso
maduro de desarrollo de software. Para las evaluaciones que se quieran obtener es necesario la utilización
de medidas técnicas, que evalúan la calidad de manera objetiva. Métricas que definen la calidad del
software: exactitud, estructuración o modularidad, pruebas, mantenimiento.

Métricas de calidad de software:

Medida: Indicación cuantitativa de la extensión, la cantidad o la dimensión del tamaño de

algún producto o proceso. (Tomado en un punto: Tiempo o lugar)

Métrica: Medida cuantitatvia del grado en que un sistema, componente o proceso posee un
atributo determinado. (Reune y relaciona medidas en varios puntos.Promedio, mediana, taza,
razón)

Las métricas técnicas ayudan a la evaluación de los modelos de análisis y diseño, proporcionan una
indicación de la complejidad de los diseños procedimentales y el código fuente y ayudan en el diseño de
pruebas más efectivas.


Dentro de las medidas de calidad del software tenemos:
Existen algunas métricas de calidad de software imprescindibles, como las que tienen que ver con los cinco
siguientes criterios: GFPI-F-135 V01
A/ Métricas de exactitud: intentan aportar información sobre la validez y precisión del software y su
estructura, incluyendo la etapa de despliegue, pero también la de pruebas y la función de mantenimiento.
B/ Métricas de rendimiento: a través de ellas se consigue medir el desempeño del software, tanto de cada
uno de sus módulos, como del sistema al completo.
C/ Métricas de usabilidad: hay que descartar la complejidad y buscar una solución intuitiva y user-friendly.
este tipo de métricas de calidad de software ayudan a determinar si la solución cumple con dichos
requisitos.
D/ Métricas de configuración: las limitaciones, el estilo de código y todos los datos relativos al desarrollo y
cualidades del producto se verán evaluados en base a estas métricas.
E/ Métricas de eficiencia: minimización de latencias, velocidad de respuesta, capacidad, es un enfoque
similar al de la productividad pero con un matiz un poco distinto, que añadido a aquél, aporta una visión
mucho más completa de la solución

Corrección: Es el grado en que el software cumple su función.

La medida más común es: Defectos por KDLC (miles de líneas de código)
Facilidad de mantenimiento: Es la facilidad con la que se puede corregir un programa si se encuentra un
error.
Se utilizan medidas indirectas como: Tiempo Medio de cambio (TMC) Es decir, el tiempo que se tarda en:
Analizar una petición.
Diseñar un modificación.
Implementar el cambio.
Probar y realizar el cambio.
Integridad: Mide la capacidad del software para resistir ataques. Se debe tener en cuenta los siguientes
atributos:

Amenaza: Es la probabilidad de que un ataque ocurra en un tiempo determinado.

Seguridad: Es la probabilidad de que se pueda repeler el ataque de un tipo determinado.

Se define como: Integridad = Σ [(1-amenaza) x (1-seguridad)]

Facilidad de uso: Mide la "amigabilidad " del software con el usuario final.

Se mide en función de:

 Habilidad intelectual o física para aprender el sistema.

 El tiempo requerido para hacer uso eficiente del sistema.
 Aumento de la productividad.
 Valoración subjetiva de la disposición de los usuarios hacia el sistema.
GFPI-F-135 V01

Eficacia de la eliminación de defectos

La eficacia de la eliminación de defectos (EED), es una métrica que permite medir la habilidad de filtrar las
actividades de la garantía de calidad y de control, ya que es aplicable a todas las actividades del marco de
trabajo del proceso.

Se define de la siguiente forma: EED = E / (E + D)

E = Número de errores encontrados antes de la entrega del software

D = Número de defectos encontrados después de la entrega

El valor ideal de EED es 1. No se han encontrado defectos en el software.

Integración de las métricas dentro del proceso de Ingeniería del Software

Estableciendo una línea base de métricas se obtienen beneficios a nivel de:

 Proceso
 Proyecto
 Producto

Esta línea base, comprende los siguientes pasos:

1. Recopilación de datos. (Medidas): Requiere una investigación histórica de los proyectos

para reconstruir los datos requeridos

2. Cálculo de métricas (Métricas): Se hace el cálculo de métricas una vez se han

determinado las medidas. Pueden abarcar una gran cantidad de métricas:

 LDC y PF
 De calidad
 Del proyecto

3. Evaluación de métricas. (Indicadores): Se deben evaluar las métricas y aplicar durante:

la estimación, el control de proyectos y la mejora del proceso.

Alcance de las metricas:

1.¿En cuánto podría ser mejorada la productividad si no tuviese que gastar tiempo en mantenimiento?

2. ¿Cuánto tiempo le costó el último año adaptar su presupuesto en trabajar con nuevas versiones de
compiladores, bases de datos o sistemas operativos?

GFPI-F-135 V01
3. ¿Cuáles de las aplicaciones que desarrolla su empresa demanda el mayor tiempo de soporte al usuario?

4. ¿Cuánto tiempo se gasta realmente en testing?

5. ¿Crée que sus desarrolladores dedican suficiente tiempo a actividades de diseño?

6. ¿Su proceso de desarrollo ha madurado en los últimos años?

7. ¿El esfuerzo dedicado a mejorar la calidad del software está reduciendo el tiempo que se dedica a
corregir errores ?

8. ¿Con qué precisión es usted capaz de estimar proyectos futuros?

9. ¿En cuántos proyectos han trabajado cada uno de sus desarrolladores en el último año?

10. ¿Cuál es el número medio de horas por semana que sus desarrolladores dedican a un proyecto?

Fuente: https://www.google.com/search?q=clasificacion+de+las+metricas+de+software&hl=es-
419&tbm=isch&source=iu&ictx=1&fir=cZyAU2hIfYzlCM%252C4qI8nu6RAd4wcM%252C_&vet=1&usg=AI4_-
kTnR3O2k9eWWpsGw4p_YuBL8dNSDQ&sa=X&ved=2ahUKEwjp-
ruwrYfrAhUIiqwKHeTDAisQ9QEwAHoECAcQAw&biw=1366&bih=657#imgrc=vFbdbYbD9fkTAM

PASOS PARA LA MEDICIÓN:

El primer paso de la medición es :

1.identificar los atributos o entidades a medir. Estos pueden ser de tres tipos:

 Productos: componentes, entregas o documentos resultantes de una actividad de proceso.

GFPI-F-135 V01
 Procesos: atributos de actividades relacionadas con el software.
 Recursos: entidades requeridas por una actividad de proceso
 Dentro de cada clase anterior se puede distinguir:

 Atributos internos: Son aquellos que pueden ser medidos examinando el proceso, producto o
recurso mismo.
 Atributos externos: se miden con respecto a como el proceso, producto o recurso se relaciona
con su entorno.

Atributos internos del producto:

 Medidas de tamaño (longitud del código, funcionalidad...)

 Medidas de diseño  Acoplamiento: grado de interdependencia entre módulos
 Cohesión: grado en el los componentes locales de un módulo colaboran para realizar una tarea
concreta
 Modularidad

Medidas de complejidad (estructuras de datos, estructura lógica...)

Atributos externos, que dependen del comportamiento del producto en un entorno determinado:

Portabilidad
Fiabilidad
Usabilidad
Facilidad de mantenimiento  Escalabilidad

PROCESO DE MEDICION:

GFPI-F-135 V01
Medidas de fiabilidad y de disponibilidad.

La mayoría de los modelos de fiabilidad relativos al hardware van más orientados a los fallos debidos al
desajuste, que a los fallos debidos a defectos de diseño, ya que son más probables debido al desgaste físico
(p. ej.: el efecto de la temperatura, del deterioro, y los golpes) que los fallos relativos al diseño.
Desgraciadamente, para el software lo que ocurre es lo contrario. De hecho, todos los fallos del software,
se producen por problemas de diseño o de implementación.

Considerando un sistema basado en computadora, una medida sencilla de la fiabilidad es el tiempo medio
entre fallos (TMEF) [Mayrhauser´91], donde:

TMEF = TMDF+TMDR (4.2) (TMDF (tiempo medio de fallo) y TMDR (tiempo medio de reparación)).

Argumentan que el TMDF es con mucho, una medida más útil que los defectos/KLDC, simplemente porque
el usuario final se enfrenta a los fallos, no al número total de errores.

Muchos de los errores del programa pueden pasar desapercibidos durante décadas antes de que se 67
detecten. El TMEF de esos errores puede ser de 50 e incluso de 100 años. Otros errores, aunque no se
hayan descubierto aún, pueden tener una tasa de fallo de 18 ó 24 meses, incluso aunque se eliminen todos
los errores de la primera categoría (los que tienen un gran TMEF), el impacto sobre la fiabilidad del
software será muy escaso. GFPI-F-135 V01
Además de una medida de la fiabilidad debemos obtener una medida de la disponibilidad. La disponibilidad
del software es la probabilidad de que un programa funcione de acuerdo con los requisitos en un momento
dado, y se define como: Disponibilidad = TMDF/(TMDF + TMDR) x 100 % (4.3) La medida de fiabilidad TMEF
es igualmente sensible al TMDF que al TMDR. La medida de disponibilidad es algo más sensible al TMDR ya
que es una medida indirecta de la facilidad de mantenimiento del software.

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 particular el EED es una medida de la habilidad de filtrar las
actividades de la 68 garantía de calidad y de control al aplicarse a todas las actividades del marco de trabajo
del proceso. Cuando se toma en consideración globalmente para un proyecto, EED se define de la forma
siguiente:

EED = E / (E + D)

donde E= es el número de errores encontrados antes de la entrega del software al usuario final y D= es el
número de defectos encontrados después de la entrega. El valor ideal de EED es 1, donde simbolizando que
no se han encontrado defectos en el software. De forma realista, D será mayor que cero, pero el valor de
EED todavía se puede aproximar a 1 cuando E aumenta. En consecuencia cuando E aumenta es probable
que el valor final de D disminuya (los errores se filtran antes de que se conviertan en defectos) Si se utiliza
como una métrica que suministra un indicador de la destreza de filtrar las actividades de la garantía de la
calidad y el control, el EED alienta a que el equipo del proyecto de software instituya técnicas para
encontrar los errores posibles antes de su entrega. Del mismo modo el EED se puede manipular dentro del
proyecto, para evaluar la habilidad de un equipo en encontrar errores antes de que pasen a la siguiente
actividad, estructura o tarea de ingeniería del software. Por ejemplo, la tarea de análisis de requerimientos
produce un modelo de análisis qué se puede inspeccionar para encontrar y corregir errores. Esos errores
que no se encuentren durante la revisión del modelo de análisis se pasan a la tareas de diseño (en 69
donde se puede encontrar o no) Cuando se utilizan en este contexto, el EED se vuelve a definir como: EED =
Ei / ( Ei + Ei+1) (4.5) Donde Ei = es el número de errores encontrados durante la actividad iesima de:
ingeniería del software i, el Ei + 1 = es el número de errores encontrado durante la actividad de ingeniería
del software (i + 1) que se puede seguir para llegar a errores que no se detectaron en la actividad i. Un
objetivo de calidad de un equipo de ingeniería de software es alcanzar un EED que se aproxime a 1, esto es,
los errores se deberían filtrar antes de pasarse a la actividad siguiente. Esto también puede ser utilizado
dentro del proyecto para evaluar la habilidad de un equipo, esto con el objetivo de encontrar deficiencias
que harán que se atrase el proyecto. Existen varias métricas de calidad, pero las más importantes y que
engloban a las demás, son sólo cuatro: corrección, facilidad de mantenimiento, integridad y facilidad de
uso, se explican en la siguiente sección.

Los principales productos que resulta útil medir son la especificación, el diseño y el código. GFPI-F-135 V01
Código

El numero de líneas de código (LOC) es la medida más usada para medir la longitud del código fuente.

Se han realizado muchas propuestas para contarlas. La más extendida es la de HP que no contabiliza las
líneas comentadas ni en blanco. La abreviatura que se usa para estas líneas es NCLOC o ELOC (effective
lines of code).

Es útil medir por separado las líneas comentadas (CLOC) para calcular esfuerzo, productividad, etc. La
longitud total será: LOC = NCLOC + CLOC  También puede se útil calcular la densidad de comentarios:
CLOC/LOC

Para propósitos tales como la prueba es importante conocer cuanto código ejecutable se produce, para ello
se mide el número de sentencias ejecutables (ES), ignorando los comentarios, declaraciones de datos y
cabeceras.

Otra propuesta consiste en contabilizar únicamente el código entregado al cliente. Se cuenta el número de
DSI (delivered source instruction) que incluye las declaraciones de datos, las cabeceras y las instrucciones
fuente.

Puntos de función (PF)

Medida de la funcionalidad propuesta por Albrecht. Es una medida del producto y del proceso que se sigue
para desarrollarlo. Está centrado en la “funcionalidad” o “utilidad” del producto.

Los PF se obtienen utilizando una relación empírica basada en items del producto y valoraciones subjetivas
de la complejidad del mismo.

El paso previo al cálculo de los PF, es el cálculo de PFS (unadjusted function point count), puntos de función
sin ajustar:

Se determinan los siguientes elementos de alguna representación del software:

Entradas externas: entradas de usuario que proporcionan datos a la aplicación.

Salidas externas: Salidas que proporcionan información al usuario.

Consultas externas: peticiones interactivas que requieren una respuesta.

ficheros externos: interfaces con otros sistemas legibles por la máquina.

Ficheros internos: ficheros maestros lógicos del sistema. GFPI-F-135 V01

A cada elemento se le asigna un índice de complejidad entre tres: simple, media o complejo. A cada índice
le corresponde un factor de ponderación.

Ambiente

 Ambiente Requerido

El ambiente de aprendizaje debe estar conformado por: mínimo 25 Equipos con la siguiente
configuración en cada uno de ellos: Sistema operativo: Windows, Disco Duro de 500 GB, Ram: de 4GB
como mínimo Procesador: Intel Core 2 Duo de 2,66 Mhz, lector de PDFs, antivirus, procesador de
palabra, hoja electrónica y conexión estable a internet.

 Materiales:
 25 Computadores, 25 Lápices, 25 esferos, 2 marcadores y resma de papel cuadriculado.

4. ACTIVIDADES DE EVALUACIÓN

Evidencias de Aprendizaje Criterios de Evaluación Técnicas e Instrumentos de

Evaluación

Evidencia de conocimiento- Evalúa los procesos involucrados en

AP06-AA1-EV01- Exposición
Exposiciones
Evidencia desempeño AP06-
AA2- EV02- Encuesta
el desarrollo de software, aplicando
técnicas de evaluación de procesos, Lista de chequeo
de acuerdo con los referentes de un
modelo de calidad, para determinar
su nivel de capacidad o madurez.

Define o redefine procesos

Encuesta de seguimiento de
calidad
Evidencia de producto AP06-
AA2- EV02- Encuesta
 Manual de calidad
Informe final del proceso de
gestión de validación en el
desarrollo de software.
asignados aplicando principios y
técnicas de definición y
modelamiento de procesos, de
acuerdo con los estándares definidos
y con las prácticas propuestas por el
modelo de calidad.
Define el plan de evaluación de la
calidad de procesos de desarrollo de
software, aplicando principios de
aseguramiento de calidad y de
gestión de proyectos, de acuerdo
con el procedimiento establecido.
GFPI-F-135 V01

1. GLOSARIO DE TÉRMINOS
Gestión: actividades coordinadas para dirigir y controlar una organización

Gestión de la Calidad: actividades coordinadas para dirigir y controlar una organización en lo relativo a la

Calidad: Incluye: política de la calidad, objetivos de la calidad, planificación de la calidad, control de la

calidad,

aseguramiento de la calidad y mejora de la calidad.

Control de la calidad: orientada al cumplimiento de los orientada al cumplimiento de los requisitos de la

calidad requisitos de la calidad.

Aseguramiento de la calidad: orientada a proporcionar orientada a proporcionar confianza en que se

cumplir confianza en que se cumplirán los requisitos de la calidad n los requisitos de la calidad

Mejora de la calidad: orientada a aumentar la capacidad orientada a aumentar la capacidad de cumplir con
los requisitos de la calidad de cumplir con los requisitos de la calidad.

Mejora continua: actividad recurrente para aumentar la actividad recurrente para aumentar la capacidad
para cumplir los requisitos capacidad para cumplir los requisitos.

– Proceso mediante el cual se Proceso mediante el cual se establecen los objetivos y se establecen los
objetivos y se identifican oportunidades para la mejora de un proceso identifican oportunidades para la
mejora de un proceso continuo a trav continuo a través del uso de los hallazgos de la auditoria, el s del uso
de los hallazgos de la auditoria, el análisis de los datos, la revisi lisis de los datos, la revisión por la dirección
por la dirección u otros medios, y generalmente conduce a la acci medios, y generalmente conduce a la
acción correctiva y no correctiva y preventiva. preventiva.

6. REFERENTES BIBLIOGRÁFICOS

https://scielo.conicyt.cl/scielo.php?script=sci_arttext&pid=S0718-33052018000100114#:~:text=En%20t
%C3%A9rminos%20generales%2C%20la%20calidad,durante%20el%20proceso%20de%20desarrollo.

https://www.isotools.org/2015/03/20/que-es-el-aseguramiento-de-la-calidad-y-como-se-consigue/

https://obsbusiness.school/int/blog-project-management/plantillas/pasos-para-elaborar-un-informe-de-
gestion-en-tu-empresa

http://www.cs.uns.edu.ar/~prf/teaching/APS16/downloads/Teoria/Metricas-1x1.pdf

http://scielo.sld.cu/scielo.php?script=sci_arttext&pid=S2227-18992016000100018

http://ocw.uc3m.es/ingenieria-informatica/desarrollo-de-sistemas-de-informacion-corporativos-
1/documentos/metricas-de-software
GFPI-F-135 V01
http://bibing.us.es/proyectos/abreproy/30060/fichero/PROYECTO.pdf

7. CONTROL DEL DOCUMENTO

 Nombre Cargo Dependencia Fecha

Autor (es) Astrid Segura Instructora Julio 2021

8. CONTROL DE CAMBIOS (diligenciar únicamente si realiza ajustes a la guía)

Nombre Cargo Dependencia Fecha Razón del

Cambio

Autor (es)

GFPI-F-135 V01