Moreno Giraldo Carlos Andres Ruiz Zambrano Diego Giovanni 2016 EJEMPLO90003

Universidad Distrital
Francisco José de Caldas
MODELO DE APLICACIÓN DE LA NTC-ISO/IEC 90003 AL

DESARROLLO DE SOFTWARE DE LOS SISTEMAS DE INFORMACIÓN
GEOGRÁFICA
CARLOS ANDRÉS MORENO GIRALDO
DIEGO GIOVANNI RUIZ ZAMBRANO
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD DE INGENIERÍA
PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMAS
BOGOTÁ D.C.
2016
MODELO DE APLICACIÓN DE LA NTC-ISO/IEC 90003 AL DESARROLLO DE

SOFTWARE DE LOS SISTEMAS DE INFORMACIÓN GEOGRÁFICA
CARLOS ANDRÉS MORENO GIRALDO Cód. 20031020091
DIEGO GIOVANNI RUIZ ZAMBRANO Cód. 20031020107
PROYECTO
MSc. JUAN MANUEL HIGUERA

Director externo
MSc. LUIS EMILIO MONTENEGRO

Director interno
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD DE INGENIERÍA
PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMAS
BOGOTÁ
2016
ii
Nota de Aceptación:
Firma del Jurado
Bogotá D.C. 19 de septiembre de 2016
iii
DEDICATORIA
A Dios. Por permitirnos llegar a este momento tan especial en nuestras vidas. Por
los triunfos y los momentos difíciles que nos han enseñado a valorarte cada día
más.
A nuestros padres. Por habernos apoyado en todo momento, por sus consejos,
sus valores, por la motivación constante, por los ejemplos de perseverancia y
constancia que nos ha permitido ser personas de bien, pero más que nada, por su
amor.
A nuestros profesores. Gracias por su tiempo, por su apoyo así como por la
sabiduría que nos transmitieron en el desarrollo de nuestra formación profesional.
A la Universidad Distrital Francisco José de Caldas y en especial al Proyecto

Curricular de Ingeniería de Sistemas por permitirnos ser parte de una generación
de triunfadores y profesionales productivos para el país.
iv
CONTENIDO
INTRODUCCIÓN ..................................................................................................... 1
1. MODELO DE APLICACIÓN DE LA NTC-ISO/IEC 90003 AL DESARROLLO

DE SOFTWARE DE LOS SIG ................................................................................. 3
1.1. FORMULACIÓN DEL PROBLEMA ........................................................... 3
1.2. JUSTIFICACIÓN ....................................................................................... 4
1.3. OBJETIVOS .............................................................................................. 6
1.3.1. Objetivo general ........................................................................................ 6
1.3.2. Objetivos específicos ................................................................................. 6
1.4. ALCANCES Y LIMITACIONES .................................................................. 7
1.5. MARCO TEÓRICO .................................................................................. 10
1.5.1. Marco referencial ..................................................................................... 10
1.5.2. Marco histórico ........................................................................................ 11
1.5.3. Marco conceptual .................................................................................... 13
1.5.3.1. Norma NTC-ISO/IEC 90003 ................................................................. 13
1.5.3.2. Norma ISO/IEC 25000 ......................................................................... 16
1.5.3.3. Auditoría del desarrollo y Auditoría de la calidad ................................. 19
1.6. DISEÑO METODOLÓGICO .................................................................... 20
2. REQUISITOS PARA LA APLICACIÓN DE LA NORMA NTC-ISO/IEC 90003

24
2.1. CARACTERIZACIÓN DEL SGC .............................................................. 24
2.1.1. Identificación de Elementos del SGC ...................................................... 25
2.1.2. Identificación de Procesos de Software ................................................... 26
2.2. VALORACIÓN DE REQUISITOS DE CALIDAD ...................................... 27
2.2.1. Valoración de requisitos de documentación del SGC .............................. 27
2.2.2. Procesos de Software.............................................................................. 28
v
2.2.3. Evaluación del manual de calidad ........................................................... 28

2.2.4. Control de documentos............................................................................ 29
2.2.5. Control de los registros ............................................................................ 30
2.2.6. Evidencia de conformidad con los requisitos ........................................... 30
2.2.7. Evidencia de operación eficaz ................................................................. 31
2.2.8. Retención y disposición ........................................................................... 31
2.3. VALORACIÓN DE RESPONSABILIDAD DE LA DIRECCIÓN ................ 32
2.3.1. Compromiso de la dirección .................................................................... 33
2.3.2. Enfoque al cliente .................................................................................... 34
2.3.3. Política de la calidad ................................................................................ 35
2.3.4. Planificación ............................................................................................ 35
2.3.5. Responsabilidad, autoridad y comunicación ............................................ 37
2.3.6. Representante de la dirección ................................................................. 38
2.3.7. Comunicación interna .............................................................................. 38
2.3.8. Revisión por la dirección.......................................................................... 39
2.3.8.1. Información para la revisión ................................................................. 40
2.3.8.2. Resultados de la revisión ..................................................................... 40
2.4. GESTIÓN DE LOS RECURSOS ............................................................. 41
2.4.1. Recursos humanos .................................................................................. 42
2.4.2. Infraestructura ......................................................................................... 43
2.4.3. Ambiente de trabajo................................................................................. 45
3. ENFOQUE DE LA NTC-ISO/IEC 90003 AL DESARROLLO DE SOFTWARE

SIG 46
3.1. PLANIFICACION DE LA REALIZACIÓN DEL PRODUCTO .................... 46
3.1.1. Ciclo de vida del software ........................................................................ 46
3.1.2. Planificación de la calidad ....................................................................... 47
3.2. PROCESOS RELACIONADOS CON EL CLIENTE ................................ 49
3.2.1. Determinación de los requisitos relacionados con el producto ................ 49
3.2.2. Revisión de los requisitos relacionados con el producto ......................... 55
vi
3.2.3. Comunicación con el cliente .................................................................... 57

3.3. DISEÑO Y DESARROLLO ...................................................................... 58
3.3.1. Planificación del diseño y desarrollo ........................................................ 58
3.3.2. Elementos de entrada para el diseño y desarrollo ................................... 62
3.3.3. Resultados del diseño y desarrollo .......................................................... 63
3.3.4. Revisión del diseño y desarrollo .............................................................. 66
3.3.5. Verificación del diseño y desarrollo ......................................................... 67
3.3.6. Validación del diseño y desarrollo ........................................................... 67
3.4. PRODUCCIÓN Y PRESTACIÓN DEL SERVICIO .................................. 68
3.4.1. Control de la producción y prestación del servicio ................................... 68
3.4.2. Validación de los procesos de producción y de la prestación del servicio
71
3.4.3. Seguimiento y medición........................................................................... 72
3.4.4. Análisis de datos y mejora ....................................................................... 75
4. APLICACIÓN DEL MODELO......................................................................... 78

4.1. PLANIFICACIÓN Y PREPARACIÓN DE LA EVALUACIÓN ................... 80
4.1.1. Análisis de requerimientos....................................................................... 82
4.1.2. Desarrollo del plan de evaluación ............................................................ 85
4.1.3. Selección y preparación del equipo ......................................................... 87
4.1.4. Obtención y análisis de evidencia objetiva inicial .................................... 91
4.1.5. Preparación de la recolección de pruebas objetivas ............................... 94
4.2. EVALUACIÓN DE CONDUCTA .............................................................. 99
4.2.1. Realización de pruebas objetivas ............................................................ 99
4.2.2. Verificación y validación de pruebas objetivas ...................................... 102
4.2.3. Documento de pruebas objetivas .......................................................... 102
4.2.4. Resultados de la evaluación .................................................................. 103
4.3. INFORME DE RESULTADOS DE EVALUACIÓN ................................. 104
CONCLUSIONES ................................................................................................ 105
vii
BIBLIOGRAFÍA ................................................................................................... 107
GLOSARIO .......................................................................................................... 111
ANEXO A: MAPA MENTAL DEL PROYECTO ................................................... 115
ANEXO B: INDICE DE FORMATOS ................................................................... 116
ANEXO C: CARTA DE AUTORIZACIÓN ........................................................... 118
ANEXO D: FORMATOS DE CARACTERIZACIÓN ............................................ 119
ANEXO E: FORMATOS DE SEGUIMIENTO Y MEDICIÓN DE LOS REQUISITOS

PARA LA APLICACIÓN DE LA NORMA NTC-ISO/IEC 90003 .......................... 125
ANEXO F: FORMATOS DE SEGUIMIENTO Y MEDICIÓN PARA EL ENFOQUE

DE LA NTC-ISO/IEC 90003 AL DESARROLLO DE SOFTWARE SIG .............. 137
ANEXO G: CARTA DE CIERRE ......................................................................... 156
viii
LISTA DE TABLAS
Tabla 1. Puntos de la norma NTC-ISO/IEC 90003. ............................................... 14

Tabla 2. Fases y Procesos de SCAMPI ................................................................. 22
Tabla 3. Principales componentes de la definición de productos informativos. ..... 52
Tabla 4. Categorización de requisitos del Sistema de Información Geográfica. .... 54
Tabla 5. Componentes de la MIDL. ....................................................................... 59
Tabla 6. Estándares relevantes para la interoperabilidad. ..................................... 64
Tabla 7. Aspectos importantes para el proceso de instalación del software SIG. .. 70
Tabla 8. Características de calidad del producto de software basadas en ISO
25010. .................................................................................................................... 72
Tabla 9. Formato inicial. ......................................................................................... 79
Tabla 10. Formato de planificación y preparación. ................................................ 81
Tabla 11. Formato de identificación y priorización de requerimientos. .................. 84
Tabla 12. Responsabilidades básicas de los involucrados. ................................... 88
Tabla 13. Formato de selección del equipo. .......................................................... 89
Tabla 14. Formato de entrevista inicial. ................................................................. 91
Tabla 15. Formato de recolección de pruebas objetivas. ....................................... 94
Tabla 16. Niveles de resultado posible para cada registro de la entrevista inicial. 97
Tabla 17. Tipos de campo en los formatos. ......................................................... 101
Tabla 18. Listado y clasificación de formatos. ..................................................... 116
ix
LISTA DE FIGURAS
Figura 1. Diagrama de Alcance................................................................................ 8

Figura 2. Elementos de un SIG y su interacción. ................................................... 11
Figura 3. Organización de la norma ISO 25000. .................................................... 17
Figura 4. Perspectivas de calidad de producto de software. .................................. 17
Figura 5. Diagrama de diseño metodológico del modelo. ...................................... 21
Figura 6. Integración de la aplicación de la norma NTC-ISO/IEC 90003 al
desarrollo de Software SIG con SCAMPI. ............................................................. 23
Figura 7. Principios y habilitadores en los cuales se establece la caracterización
del SGC de la organización. .................................................................................. 24
Figura 8. Principios y habilitadores en los cuales se establece la valoración de los
requisitos de calidad. ............................................................................................. 27
Figura 9. Principios y habilitadores en los cuales se establece la valoración de
responsabilidad de la dirección. ............................................................................. 32
Figura 10. Principios y habilitadores en los cuales se define la gestión de los
recursos. ................................................................................................................ 41
Figura 11. Subsistema “planificación de la realización del producto” con los
aspectos a evaluar para su aplicación en el desarrollo de software SIG. .............. 49
Figura 12. Modelo de calidad del producto de software definido por la ISO/IEC
25010. .................................................................................................................... 50
Figura 13. Subsistema “procesos relacionados con el cliente” con los aspectos a
evaluar para su aplicación en el desarrollo de software SIG. ................................ 57
Figura 14. Ejemplo de arquitectura tecnológica para el software SIG. .................. 65
Figura 15. Subsistema “diseño y desarrollo” con los aspectos a evaluar para su
aplicación. .............................................................................................................. 68
Figura 16. Subsistema “producción y prestación del servicio” con los aspectos a
evaluar. .................................................................................................................. 77
Figura 18. Énfasis de los pilares conceptuales de la NTC-ISO 90003 en cada fase
de desarrollo de SIG. ............................................................................................. 86
Figura 18. Taxonomía de documentos de la metodología. .................................. 100
Figura 19. Mapa mental del proyecto. .................................................................. 115
Figura 20. Modelo para carta de autorización. ..................................................... 118
Figura 21. Formato inicial. ................................................................................... 119
x
Figura 22. Formato de planificación y preparación. ............................................. 120

Figura 23. Formato de identificación y priorización de requerimientos. ............... 121
Figura 24. Formato de selección del equipo. ....................................................... 122
Figura 25. Formato de entrevista inicial (parte 1 de 2). ....................................... 123
Figura 26. Formato de entrevista inicial (parte 2 de 2). ........................................ 124
Figura 27. Formato y calificaciones de la caracterización del SGC. .................... 125
Figura 28. Tabla de recomendaciones para la caracterización el SGC según
calificaciones........................................................................................................ 126
Figura 29. Formato y calificaciones para la valoración de requisitos de calidad. . 127
Figura 30. Tabla de recomendaciones para la valoración de requisitos de calidad,
según calificaciones. ............................................................................................ 128
Figura 32. Formato y calificaciones para la valoración del control de registros. .. 129
Figura 32. Tabla de recomendaciones para la valoración el control de registros,
según calificaciones. ............................................................................................ 130
Figura 33. Formato y calificaciones para la valoración de responsabilidad de la
dirección. ............................................................................................................. 131
Figura 34. Tabla de recomendaciones para la valoración de responsabilidad de la
dirección, según calificaciones............................................................................. 132
Figura 35. Formato y calificaciones para la valoración de gestión de los recursos
(parte 1 de 2). ...................................................................................................... 133
Figura 36. Formato y calificaciones para la valoración de gestión de los recursos
(parte 2 de 2). ...................................................................................................... 134
Figura 37. Tabla de recomendaciones para la valoración gestión de los recursos,
según calificaciones (parte 1 de 2). ..................................................................... 135
Figura 38. Tabla de recomendaciones para la valoración gestión de los recursos,
según calificaciones (parte 2 de 2). ..................................................................... 136
Figura 39. Formato y calificaciones para la valoración de planificación de
realización del producto (parte 1 de 2). ................................................................ 137
Figura 40. Formato y calificaciones para la valoración de planificación de
realización del producto (parte 2 de 2). ................................................................ 138
Figura 41. Tabla de recomendaciones para la valoración de planificación de
realización del producto, según calificaciones. .................................................... 139
Figura 42. Formato y calificaciones para la valoración de procesos relacionados
con el cliente (parte 1 de 2). ................................................................................ 140
Figura 43. Formato y calificaciones para la valoración de procesos relacionados
con el cliente (parte 2 de 2). ................................................................................ 141
xi
Figura 44. Tabla de recomendaciones para la valoración de procesos relacionados

con el cliente (parte 1 de 2), según calificaciones................................................ 142
Figura 45. Tabla de recomendaciones para la valoración de procesos relacionados
con el cliente (parte 2 de 2), según calificaciones................................................ 143
Figura 46. Formato y calificaciones para la valoración de diseño y desarrollo. ... 144
Figura 47. Tabla de recomendaciones para la valoración de diseño y desarrollo.
............................................................................................................................. 145
Figura 48. Formato y calificaciones para la valoración de diseño y desarrollo
(resultado). ........................................................................................................... 146
Figura 49. Tabla de recomendaciones para la valoración de diseño y desarrollo
(desarrollo). .......................................................................................................... 147
Figura 50. Formato y calificaciones para la valoración de producción y prestación
del servicio (parte 1 de 2). ................................................................................... 148
del servicio (parte 2 de 2). ................................................................................... 149
Figura 52. Tabla recomendaciones para valoración de producción y prestación del
servicio. ................................................................................................................ 150
del servicio (resultados). ...................................................................................... 151
Figura 54. Tabla recomendaciones para valoración de producción y prestación del
servicio (resultados). ............................................................................................ 152
Figura 55. Formato y calificaciones para la valoración de medición, análisis y
mejora (parte 1 e 2). ............................................................................................ 153
Figura 56. Formato y calificaciones para la valoración de medición, análisis y
mejora (parte 2 e 2). ............................................................................................ 154
Figura 57. Tabla recomendaciones para valoración de medición, análisis y mejora.
............................................................................................................................. 155
Figura 58. Modelo para carta de cierre. ............................................................... 156
xii
INTRODUCCIÓN
La característica principal de los Sistemas de Información Geográfica (SIG),

es su enfoque a la captura, procesamiento, análisis y despliegue de
información geográficamente referenciada, con el objetivo de resolver
problemas complejos de planificación y gestión. Esto hace conveniente la
implementación de soluciones de software con características de calidad,
permitiendo el ajuste de diferentes elementos que utilizan datos espaciales.
En general es complicado alcanzar completamente estas características de
calidad debido a que los procesos usados en la creación de aplicaciones de
los SIG aunque siguen buenas prácticas, en muchos casos no integran
estándares de calidad específicos de software.
De acuerdo con lo anterior, el Modelo de Aplicación de la NTC-ISO/IEC1

90003 al desarrollo de software de los Sistemas de Información Geográfica
(SIG) establece cómo emplear la norma nacional de calidad en mención en
los procesos de desarrollo de software de los SIG, y además ofrece un
complemento a la norma con una especificación de requerimientos de
calidad2 basada en una categorización internacional de calidad del producto
de software3.
1
ICONTEC. Ingeniería de Software: Directrices para la aplicación de la NTC-ISO 9001:2000
a software de computador. Bogotá: ICONTEC; 2005. 73 p. NTC-ISO/IEC 90003.
2
ISO. Software engineering ─ Software product Quality Requirements and Evaluation
(SQuaRE) ─ Quality requirements. ISO; 2007. 44p. ISO/IEC 25030.
3
(SQuaRE) ─ System and software quality models. ISO; 2011. 34p. ISO/IEC 25010.
El modelo de aplicación ofrece herramientas congruentes y una base común

para la calidad del desarrollo de software basado en un estándar, en las
instituciones nacionales productoras y consumidoras de SIG dentro de todo
el contexto de las estrategias de la Infraestructura Colombiana de Datos
Espaciales4, las políticas de crecimiento económico y social (CONPES) y en
general el enfoque de estandarización mundial que se ha adoptado en el
país desde hace varios años.
Para hacer esto posible, el Modelo se sustenta en tres fases: preparación,

adaptación e implementación. Pero antes, es necesario presentar todo el
contexto teórico justificando la propuesta para la problemática identificada
(capitulo 1).
En la preparación (capítulo 2), se establecen los requisitos necesarios para la

aplicación de la norma en el marco de la calidad de software; en la
adaptación (capitulo 3) se destacan aquellos componentes únicos y
especiales de los SIG resaltando como las normas y estándares que hacen
parte del andamiaje se pueden focalizar al desarrollo o despliegue de cada
uno utilizando los principios y recomendaciones de los estándares y normas
utilizados. En la última fase –de implementación- (capitulo 4) se realiza la
aclaración metodológica para aplicar la norma 90003 a través de formatos y
plantillas guía de casa paso dentro del proceso, en los que los involucrados
mantienen una interacción a través de sus roles y responsabilidades.
4
ICDE. ¿Qué es la ICDE? http://www.icde.org.co/web/guest/que_es_icde [Consulta: 30 de
noviembre de 2015]
2
1. MODELO DE APLICACIÓN DE LA NTC-ISO/IEC 90003 AL

DESARROLLO DE SOFTWARE DE LOS SIG
En este capítulo se hace una descripción de la esencia del proyecto, a qué

apunta y por qué se construyó el modelo. Se identifica una necesidad, se
fijan los objetivos y se establece un marco conceptual, para abstraer la
norma 90003 a manera de modelo, basándose en la estructura de métodos
como Cobit 5.0 y CMMI-DEV y siguiendo SCAMPI5 como método de
evaluación en un entorno real.
1.1. FORMULACIÓN DEL PROBLEMA
Los Sistemas de Información Geográfica poseen características propias que

permiten hacer análisis geográfico de los datos, a través de aplicaciones de
software que a su vez deben ser garantías de respaldo en la toma de
decisiones en una organización. En la actualidad existe un sinnúmero de
procesos para planear, desarrollar, implantar y mejorar aplicaciones de
software SIG, estos sin duda permiten obtener productos con calidad
bastante aceptable.
Un marco de referencia, que integre elementos de calidad ceñidos a un

estándar, permitiría complementar y fortalecer tanto los procesos de
realización de un producto de software SIG, como las unidades gerenciales y
5
SEI, Standard CMMI Appraisal Method for Process Improvement (SCAMPI), Version 1.2. Carneige
Mellon University; 2006.
3
de planeación de una organización. Adicionalmente permitiría tener un

sistema de gestión de calidad de software más riguroso en el área de
desarrollo de software SIG.
Por ende, este proyecto busca dar respuesta a la siguiente pregunta: ¿Cómo
establecer un modelo que permita aplicar los parámetros de calidad de
un estándar a los procesos de desarrollo de software de los Sistemas
de Información Geográfica?
1.2. JUSTIFICACIÓN
En un proyecto de desarrollo de software de los Sistemas de Información

Geográfica se pueden utilizar diferentes metodologías enfocadas al
cumplimiento de requerimientos. Según Ciampagna6, se debe planificar un
sistema de muestreo de todas las etapas del proyecto para asegurar la
calidad; es necesario tener en cuenta la obtención de resultados esperados y
criterios de calidad durante los procesos de desarrollo de software.
Además del punto anterior, los SIG deben responder al llamado de la

estrategia número 4 de la Infraestructura Colombiana de Datos Espaciales7,
impulsada por el Documento CONPES 35858, que tiene como uno de sus
6
Ciampagna J. Administración de proyectos de Sistemas de Información Geográfica.
Córdoba: Ciampagna y Asociados – GDSI; 2000. Pág. 24.
7
ICDE. Estrategia No. 4: Gestión del Conocimiento. [artículo de Internet]
http://www.icde.org.co/web/guest/mejorar_capacidad_institucional [Consulta: 24 de
noviembre de 2015].
8
Consolidación de la Política Nacional de Información Geográfica y la Infraestructura
Colombiana de Datos Espaciales – ICDE.
4
objetivos “Implementar el Sistema de Gestión de Calidad para mejorar la

gestión de la Información Geográfica”. Esto abre el camino a la utilización de
estándares de calidad, como la NTC-ISO/IEC 900039, que ofrecen
lineamientos para procesos de desarrollo de software, y que a su vez
pueden ser orientados al entorno de desarrollo de software SIG.
Por otra parte, en el contexto nacional, según inspecciones previas dentro de

los proyectos implementados en el Centro de Investigación y Desarrollo en
Información Geográfica, del Instituto Geográfico Agustín Codazzi – CIAF10,
no se conoce de la aplicación de la norma NTC-ISO/IEC 90003 de manera
formal en los procesos de desarrollo de software para los SIG. Esta sería la
primera intención de definir un modelo de aplicación de una Norma Técnica
Colombiana a los procesos de desarrollo de software en los SIG, teniendo en
cuenta sus características.
Por estas razones, este trabajo académico busca establecer un mecanismo

de aplicación de esta norma, con la coherencia necesaria para fortalecer
aspectos de calidad enmarcados en los procesos de desarrollo de software
de los SIG.
9
10
El Instituto Geográfico Agustín Codazzi (IGAC) es la entidad oficial encargada producir la
información geográfica de Colombia. “Como Centro de Investigación y Desarrollo en
Información Geográfica del IGAC, el CIAF contribuye, a partir de la interacción de sus grupos
temáticos relacionados con la ciencia Geomática, a generar, actualizar, integrar, difundir,
aplicar y compartir los resultados de sus proyectos.... Su estructura funcional, en torno a la
gestión de la información y el conocimiento sirve como apoyo a los procesos de planificación
y desarrollo integral del país y la región. Tomado de: www.igac.gov.co, Sección Áreas
Estratégicas – CIAF. [Consulta: 30 de noviembre de 2015].
5
1.3. OBJETIVOS
1.3.1. Objetivo general
Diseñar e implementar una guía de aplicación de la norma NTC-ISO/IEC

90003 para los procesos de desarrollo de software de los Sistemas de
Información Geográfica.
1.3.2. Objetivos específicos
 Realizar la recopilación y análisis de las características de software de

los Sistemas de Información Geográfica y los parámetros de calidad de la
norma NTC-ISO/IEC 90003.
 Adoptar el modelo de calidad de producto de software contemplado en el

apartado 2501n del estándar ISO/IEC 25000, en los procesos de
desarrollo de software de los Sistemas de Información geográfica.
 Establecer los requisitos de calidad para construir software,

contemplados en el apartado 2503n del estándar ISO/IEC 25000, en los
procesos de desarrollo de software de los Sistemas de Información
Geográfica.
 Adaptar puntos de SCAMPI C11 como método base para la aplicación del
modelo en entornos reales de los Sistemas de Información Geográfica.
11
SEI. Handbook for Conducting Standard CMMI Appraisal Method for Process Improvement
(SCAMPI) B and C Appraisals, Version 1.1. Carneige Mellon University; 2005.
6
 Delimitar metodologías, técnicas y buenas prácticas utilizadas en el

desarrollo de software de los Sistemas de Información Geográfica para
implementar la guía de aplicación de la norma NTC-ISO/IEC 90003 en un
entorno real.
 Proporcionar un punto de referencia para la implementación del Sistema

de Gestión de Calidad a procesos de desarrollo de software en los
Sistemas de Información Geográfica.
1.4. ALCANCES Y LIMITACIONES
El Modelo de Aplicación de la NTC-ISO/IEC 90003 al desarrollo de software

de los Sistemas de Información Geográfica (SIG) sigue como línea base o
composición estructural a la propia NTC-ISO/IEC 90003, integrando
elementos para la evaluación específica de los procesos de desarrollo de
SIG, de los marcos de trabajo en gobierno IT como patrones de
fortalecimiento en donde los postulados norma llegan a ser muy superficiales
o genéricos (Cobit 5.0 y CMMI-DEV) y SCAMPI C para la evaluación en
entornos reales o casos de estudio.
No pretende ser un resumen que homologa los conceptos de los distintos

estándares articulados en el modelo, sino más bien una guía adaptada al
desarrollo de SIG, contextualizada al presente y futuro del país en la materia
y bajo la concepción de las políticas de desarrollo nacional.
7
El desarrollo del modelo tiene planeado estructurar una metodología acorde

a la aplicación de modelos de calidad, basado en evaluaciones comparativas
con respecto a un patrón internacionalmente establecido, atendiendo una
necesidad identificada en los procesos de desarrollo de software para SIG.
En la Figura 1, se muestra la disposición de los diferentes elementos
conceptuales, herramientas y resultados esperados del proyecto.
Figura 1. Diagrama de Alcance.
Fuente: Los autores.
El modelo de aplicación tendrá los siguientes alcances:
 Será punto de referencia para ejecutar una evaluación de calidad a los

procesos de desarrollo de software SIG, en el contexto nacional a
entidades públicas y privadas.
8
 Ofrecerá un mapa de referencia de los elementos necesarios para

realizar una aplicación de estándares de calidad internacionalmente
aceptados al proceso de software en los SIG.
 Servirá como base para la implementación del Sistema de gestión de

Calidad en el área de desarrollo de software de SIG.
 Utilizará procedimientos de evaluación enfocados a su aplicación en un

entorno real de desarrollo de software SIG.
El modelo puede presentar las siguientes limitaciones:
 En primera instancia no deriva en una garantía para apoyar una

certificación del sistema de gestión de calidad de la organización, puesto
que debe ser validado.
 El capítulo de aplicación en un entorno real está guiado por

consideraciones basadas en la experiencia de una entidad colaboradora
para el trabajo académico.
 En un entorno real, el funcionamiento del modelo está sujeto a los

elementos involucrados en el sistema de gestión de la organización y en
el área de desarrollo de SIG.
9
1.5. MARCO TEÓRICO
1.5.1. Marco referencial
Un Sistema de Información Geográfica es una integración organizada de

hardware, software y datos geográficos diseñado para capturar, almacenar,
manipular, analizar y desplegar en todas sus formas la información
geográficamente referenciada con el fin de resolver problemas complejos de
planificación y gestión.
En un sentido más estricto, es cualquier sistema de información capaz de

integrar, almacenar, editar, analizar, compartir y mostrar la información
geográficamente referenciada, permitiéndole a los usuarios crear consultas
interactivas, analizar la información espacial, editar datos, mapas y presentar
los resultados de todas estas operaciones.
La Figura 2 muestra un esquema del SIG donde todos sus elementos

convierten datos en información mediante análisis. Allí cabe destacar para el
propósito del proyecto el componente software, que proporciona las
funciones necesarias para realizar el análisis mencionado y crear información
entendible por el usuario del sistema.
Es en este componente de software en el que es necesario aplicar un

enfoque sistémico de calidad sobre los siguientes procesos: planificación,
diseño y desarrollo, implementación y mejora continua basado en las normas
y estándares internacionales ya establecidos e implementados por
instituciones de toda índole.
10
Figura 2. Elementos de un SIG y su interacción.
Fuente: Tomlinson R. Pensando en el SIG. 3 ed. Redlands CA: ESRI Press; 2008. 257 p.
1.5.2. Marco histórico
Hace casi 40 años, el software en los Sistemas de Información Geográfica

era considerado parte de un conjunto de equipos, programas y datos que
significaba el recurso técnico disponible. Es a partir de su primer uso en los
años 60 que los SIG tuvieron una evolución favorable, pasando de resolver
necesidades de las instituciones que los construían a resolver necesidades
de clientes finales en diversos campos12. Así que era de esperarse una
12
Cassetiari E. SIG y Medio Ambiente: principios básicos. Universidad de Cádiz.; 1993.
11
nueva perspectiva del componente de software dentro de los SIG, ya que

pasó de procesar datos y proporcionarlos a personas que hacían análisis, a
realizar el procesamiento y el análisis de datos para proveer la información
geográfica completa.
En la década de los 70 y principios de los 80, la etapa de desarrollo se

caracterizó, en general, por la disminución de la importancia de las iniciativas
individuales y un aumento de los intereses a nivel corporativo, especialmente
por parte de las instancias gubernamentales y de la administración.
Entre el final de los años 80 y el final de los 90, se vivió el auge de la

comercialización de los SIG, pasando de las grandes corporaciones hasta los
usuarios domésticos de la mano con la evolución de los computadores
personales.
A finales del siglo XX y principios del XXI el rápido crecimiento en los

diferentes sistemas se consolidó, restringiéndose a un número relativamente
reducido de plataformas. Los usuarios comenzaron a exportar el concepto de
visualización de datos SIG a Internet, lo que demandó iniciar una
estandarización de formato de los datos y de normas de transferencia. Más
recientemente, se originó una expansión en el número de desarrollos de
software SIG de código libre, los cuales, a diferencia del software comercial,
suelen abarcar una gama más amplia de sistemas operativos, permitiendo
ser modificados para llevar a cabo tareas específicas.
Actualmente, los SIG se están instalando rápidamente en los organismos

públicos, los laboratorios o institutos de investigación, las instituciones
12
académicas, la industria privada y las instalaciones militares y públicas a

nivel nacional e internacional, requiriendo un lenguaje común para su fácil
intercambio, reutilización e integración.
Ante esta diversificación de iniciativas, usos y fines de los SIG y la estrecha

evolución que tienen con el avance escalonado del software, los esfuerzos
por encontrar guías de buenas prácticas y procedimientos enfocados en la
calidad han aumentado en el ámbito internacional. Dicha búsqueda,
encuentra su respuesta una vez se adopta el conjunto de estándares
pertinentes que sobre la materia se ha desarrollado, obteniendo beneficios
multinivel en todas las áreas que interactúan con los SIG.
1.5.3. Marco conceptual
1.5.3.1. Norma NTC-ISO/IEC 90003
Esta norma ofrece el marco general sobre procesos de ingeniería de

software en software de computador. Suministra explícitamente orientación a
las organizaciones para la aplicación de la NTC-ISO 9001:2000 en la
adquisición, suministro, desarrollo y mantenimiento de software de
computador13.
Indica los aspectos que se deberían tener en cuenta independientemente de

la tecnología usada, las metodologías de desarrollo, la secuencia de
actividades y la estructura de la organización. Aunque no da una visión
13
13
específica de cada aspecto, sí abarca procesos adicionales al desarrollo de

software y sobre todo su relación con el sistema de gestión de calidad de la
organización.
La Tabla 1 muestra los puntos considerados en la norma NTC-ISO/IEC

90003, para cada sección se tienen en cuenta los procedimientos orientados
a la calidad:
Tabla 1. Puntos de la norma NTC-ISO/IEC 90003.
4. SISTEMA DE GESTIÓN DE CALIDAD

Identificación, aplicación de procesos de software
4.1 REQUISITOS GENERALES
Secuencia de interacción de procesos
Generalidades
4.2 REQUISITOS DE Manual de calidad
DOCUMENTACIÓN Control de documentos
Control de registros
5. RESPONSABILIDAD DE LA DIRECCIÓN
Política de calidad
Establecimiento de los objetivos de calidad
5.1 COMPROMISOS
Revisiones
Disponibilidad de recursos
5.2 ENFOQUE AL CLIENTE Cumplimiento de requerimientos del cliente
La alta dirección debe procurar que la política de

5.3 POLÍTICA DE CALIDAD
calidad sea adecuada
Objetivos de calidad
5.4 PLANIFICACIÓN
Planificación del sistema de gestión de calidad
Responsabilidad y autoridad
5.5 RESPONSABILIDAD,
Representante de la dirección
AUTORIDAD Y COMUNICACIÓN
Comunicación interna
14
Información para revisión

5.6 REVISIÓN POR LA DIRECCIÓN
Resultados de la revisión
6. GESTIÓN DE LOS RECURSOS
6.1 PROVISIÓN DE RECURSOS
6.2 RECURSOS HUMANOS Competencia, toma de conciencia y formación
Edificios, espacio de trabajo y servicios asociados

Equipo para los procesos (hardware, software)
6.3 INFRAESTRUCTURA Servicios de apoyo (transporte, comunicación)
Herramientas de software para apoyar el proceso
de diseño y desarrollo
6.4 AMBIENTE DE TRABAJO
7. REALIZACIÓN DEL PRODUCTO

Ciclo de vida del software
7.1 PLANIFICACIÓN DELA
REALIZACIÓN DEL PRODUCTO Planificación de la calidad
Determinación de los requisitos relacionados con

el producto
7.2 PROCESOS RELACIONADOS
Revisión de los requisitos relacionados con el
CON EL CLIENTE
producto
Comunicación con el cliente
Planificación
Elementos de entrada para el diseño y desarrollo
Resultados del diseño y desarrollo
7.3 DISEÑO Y DESARROLLO Revisión del diseño y desarrollo
Verificación del diseño y desarrollo
Validación del diseño y desarrollo
Control de cambios del diseño y desarrollo
Proceso de compras
7.4 COMPRAS Información sobre compras
Verificación de los productos comprados
15
Control
Validación de los procesos de producción y
7.5 PRODUCCIÓN Y PRESTACIÓN prestación del servicio
DEL SERVICIO Identificación y trazabilidad
Propiedad del cliente
Preservación del producto
7.6 CONTROL DE LOS

DISPOSITIVOS DE SEGUIMIENTO
Y MEDICIÓN
8. MEDICIÓN, ANÁLISIS Y MEJORA

Satisfacción del cliente
Auditoría interna
8.2 SEGUIMIENTO Y MEDICIÓN
Seguimiento y medición de los procesos
Seguimiento y medición del producto
8.3 CONTROL DEL PRODUCTO

NO CONFORME
8.4 ANÁLISIS DE DATOS

Mejora continua
8.5 MEJORA Acción correctiva
Acción preventiva
Fuente: Adaptación de los autores. ICONTEC. NTC-ISO/IEC 90003.
1.5.3.2. Norma ISO/IEC 25000
ISO/IEC 25000, conocida como SQuaRE (System and Software Quality

Requirements and Evaluation), es una familia de normas que tiene por
objetivo la creación de un marco de trabajo común para evaluar la calidad del
producto software.
16
Figura 3. Organización de la norma ISO 25000.
Fuente: PIATTINI M. et al. Calidad de Sistemas Informáticos. Alfaomega; 2007. p. 83.
Esta norma sustituye y amplia las normas ISO 9126 (Tecnología de la

Información –Calidad de un producto de software) e ISO 14598 (Tecnología
de la Información –Evaluación de un producto de software). La Figura 4
muestra las perspectivas de calidad para el producto de software.
Figura 4. Perspectivas de calidad de producto de software.
Fuente: Calidad de Sistemas de Información –Calidad de producto [diapositiva]. Universidad

de Castilla-La Mancha; 2008-2009.
17
Los componentes de Modelo de Calidad y Requisitos de Calidad del

producto de software serán la base para complementar la guía de calidad
para los procesos de software; teniendo en cuenta la importancia del
producto de software final y los parámetros de calidad a seguir.
a. ISO/IEC 2501n – División de Modelo de Calidad
Las normas de este apartado presentan modelos de calidad detallados

incluyendo características para calidad interna, externa y en uso del producto
software. La norma ISO/IEC 2501014 - System and software quality models:
describe el modelo de calidad para el producto software y para la calidad en
uso. Esta Norma presenta las características y subcaracterísticas de calidad
frente a las cuales evaluar el producto software.
b. ISO/IEC 2503n – División de Requisitos de Calidad
Las normas que forman este apartado ayudan a especificar requisitos de

calidad que pueden ser utilizados en el proceso de elicitación, es decir, el
proceso de análisis, realización y transmisión de los requisitos de calidad del
producto software a desarrollar como entrada del proceso de evaluación. La
norma ISO/IEC 2503015 - Quality requirements: provee de un conjunto de
recomendaciones para realizar la especificación de los requisitos de calidad
del producto software.
14
15
(SQuaRE) ─ Quality requirements. ISO; 2007. 44p. ISO/IEC 25030.
18
1.5.3.3. Auditoría del desarrollo y Auditoría de la calidad
En lo que respecta al área de auditoría, que sería una fase posterior a la

aplicación de la norma y que no está considerada dentro del presente
proyecto, puede decirse que tendría una abstracción de la Auditoría del
desarrollo y la Auditoría de la calidad16.
“La auditoría del desarrollo tratará de verificar la existencia y aplicación de

procedimientos de control adecuados que permitan garantizar que el
desarrollo de sistemas de información se ha llevado a cabo según estos
principios de ingeniería17”. Dichos principios hacen referencia a aquellos
establecidos en Ingeniería de Software, comprendiendo todo el ciclo de vida
del software sin contar el mantenimiento y la mejora del mismo.
De manera similar, la auditoría de la calidad permitirá verificar que el

software tenga “concordancia con los requisitos funcionales y de rendimiento
explícitamente establecidos, con los estándares de desarrollo explícitamente
documentados y con las características implícitas que se espera de todo
software desarrollado profesionalmente18”.
Pensando a futuro dentro de todo el proceso de calidad, se tienen muy en

cuenta estos enfoques de auditorías, que servirán para ajustar precisamente
los criterios verificables luego que se ejecute la aplicación de la norma, ya
16
Dos enfoques considerados en Auditoría Informática: Un Enfoque práctico, de Piattini M et
al.
17
Rodero J. Auditoría del desarrollo. En: Piattini M. Auditoría Informática: Un enfoque
práctico. 2 ed. Madrid; 2011. p. 261-293.
18
Lucero J. Auditoría de la calidad. En: Piattini M. Auditoría Informática: Un enfoque práctico.
2 ed. Madrid; 2011. p. 361-387.
19
que es incoherente pensar en la auditoría de un proceso, cuando dicho

proceso no está ajustado a un estándar o norma formal ya que previamente
se sabrá que el resultado es una no conformidad. Esto se tratará
directamente a través del estudio (con enfoque sistémico) y disección de la
norma NTC-ISO/IEC 90003 explicada anteriormente en referencia a lo que
las auditorías verifican.
1.6. DISEÑO METODOLÓGICO
La columna vertebral del modelo es la NTC-ISO/IEC 90003, para su

aplicación en el desarrollo de software SIG se procedió a realizar una
disección sistémica de la misma en la que se identificó por cada parte, los
componentes clave que intervienen como entradas, procesos y salidas.
Cada abstracción producida es una ficha dentro de todo el marco del modelo,
encajada según el ciclo de vida del software SIG; fue claro identificar además
la naturaleza propia del software SIG, en el que predomina la importancia en
las fases tempranas de su construcción con un vuelco total hacía la
obtención y organización de los datos y su posterior mantenimiento.
El anterior proceso de interpretación y modelamiento fue posible solo a

través de analizar el comportamiento de los procesos naturales de desarrollo
y cómo adquieren un carácter diferenciador con respecto a la mayoría de
proyectos cuando la información a tratar es geográfica. Este análisis
enriquecido con la experiencia de los autores, se convirtió en la herramienta
fundamental para estructurar un modelo de la norma NTC-ISO/IEC 90003,
20
usando como guía estructural Cobit 5.019 y los estándares de calidad ISO
25000 previamente conceptualizados.
Figura 5. Diagrama de diseño metodológico del modelo.
NTC-ISO/IEC 90003
Recursos
SG
C
Realización Seguimiento
Del y Medición
Producto
Abstracción
Planeación
CICLO DE
Análisis VIDA Cobit 5.0
ISO 25000
Diseño
Abstracción
Pruebas
Modelo
Implantación
Mantenimiento
Aplicación
SMBD y
Datos
Personal Hardware
SIG
Procedimientos Software
19
COBIT, Control Objectives for Information and related Technology. ISACA, 2012.
21
En el momento de aplicar el modelo en un entorno real, o para su aplicación

en casos de estudio, se plantea el uso de SCAMPI. El método SCAMPI
(Standard CMMI Appraisal Method for Process Improvement), es un proceso
para ofrecer evaluaciones (benchmarkings) de calidad con relación a los
modelos CMMI. Concretamente, se propone el uso de SCAMPI C20, una
prueba de enfoque de los procesos definidos.
Una evaluación usando SCAMPI se apoya en las mejores prácticas que

ofrece CMMI para determinar (diagnosticar) la situación de una organización
y sus procesos, definiendo acciones a realizar para introducir nuevas
prácticas de manera que constituyan mejoras duraderas con relación a un
modelo de referencia; incluso acreditando el nivel de madurez o de
definición, adopción o institucionalización de los procesos organizativos con
un reconocimiento de carácter internacional21. SCAMPI consta de tres fases
y once procesos, como se muestra en la siguiente Tabla:
Tabla 2. Fases y Procesos de SCAMPI

Fase Proceso
1. Planear y preparar para la 1.1 Análisis de Requerimientos
evaluación 1.2 Desarrollo del Plan de Evaluación
1.3 Seleccionar y Preparar el Equipo
1.4 Obtención y análisis de evidencia objetiva
inicial
1.5 Preparar para la recolección de pruebas
objetivas
20
SEI. Handbook for Conducting Standard CMMI Appraisal Method for Process Improvement
(SCAMPI) B and C Appraisals, Version 1.1. Carneige Mellon University; 2005.
21
Bello Méndez Y. Detrás de la Máscara (1ª parte): Evaluación y Diagnósticos usando
SCAMPI Appraisals con People CMM; 2014.
22
2. Evaluación de Conducta 2.1 Examinar pruebas objetivas

2.2 Verificar y validar pruebas objetivas
2.3 Documento de pruebas objetivas
2.4 Generar resultados de la evaluación
3: Informe Resultados de Evaluación 3.1 Entregar
3.2 Paquete y Archivo Activo de Evaluación
Fuente: Adaptación de los autores. SEI. Standard CMMI Appraisal Method for Process
Improvement (SCAMPI).
La aplicación de esta herramienta será determinada por la estructura

plasmada en la Figura 6, que considera las 3 fases del Método integrando los
puntos de evaluación SCAMPI más pertinentes:
Figura 6. Integración de la aplicación de la norma NTC-ISO/IEC 90003 al desarrollo de

Software SIG con SCAMPI.
Fuente: Los Autores.
23
2. REQUISITOS PARA LA APLICACIÓN DE LA NORMA NTC-ISO/IEC

90003
En este capítulo se listan y detallan los pasos iniciales para la Aplicación de

la norma NTC-ISO/IEC 90003 en proyectos de desarrollo de software de SIG.
La columna vertebral de la aplicación de la norma se fundamenta en conocer
la coherencia que tiene la organización con respecto a sus objetivos y su
sistema de gestión de la calidad (en adelante SGC), por lo cual se presentan
contenidos genéricos aplicables no sólo a proyectos de desarrollo de
software de SIG, sino a desarrollo de software en general. En el anexo E, se
encuentran los formatos asociados a esta fase.
2.1. CARACTERIZACIÓN DEL SGC
Figura 7. Principios y habilitadores en los cuales se establece la caracterización del SGC de

la organización.
24
La aplicación de la norma NTC-ISO/IEC 90003 es apropiada para Software

de SIG que:
 Es parte de un contrato comercial con otra organización.

 Es un producto disponible para un sector del mercado.
 Se usa para apoyar los procesos de una organización.
 Está embebido en un producto de hardware.
 Está relacionado con servicios de software.
Al establecer a qué campo pertenecerá o pertenece el Software, se obtiene

un punto de partida fundamental para iniciar la caracterización del Sistema
de Gestión de la Calidad identificando el papel que cumple todo el proceso
de desarrollo de software de SIG dentro del mismo.
2.1.1. Identificación de Elementos del SGC
Se debe establecer un contexto de calidad de acuerdo al sistema de gestión

de la calidad de la organización, para el cual se hace imprescindible
identificar:
a. Estrategias: Políticas, objetivos y lineamientos para el logro de la calidad

y satisfacción del cliente.
b. Procesos: Actividades y procedimientos requeridos para la realización del

producto o servicio. También las actividades de seguimiento y control
para la operación eficaz de los procesos.
25
c. Recursos: Asignaciones claras de personal, equipo y/o maquinarias

necesarias para la producción o prestación del servicio, el ambiente de
trabajo y el recurso financiero necesario para apoyar las actividades de la
calidad.
d. Estructura Organizacional: Estructura de responsabilidades, autoridades

y de flujo de la comunicación dentro de la organización.
e. Documentos: Documentos, formularios, registros y cualquier otra

documentación para la operación eficaz y eficiente de los procesos y por
ende de la organización.
2.1.2. Identificación de Procesos de Software
Identificación y aplicación del proceso. La organización debería identificar los

procesos para desarrollo, operación y mantenimiento de software.
Secuencia e interacción de procesos. La organización debería definir la

secuencia e interacción de los procesos en:
 Modelos de ciclo de vida para desarrollo de software y
 Planificación de la calidad y del desarrollo, que se deberían basar en un

ciclo de vida.
26
2.2. VALORACIÓN DE REQUISITOS DE CALIDAD
Figura 8. Principios y habilitadores en los cuales se establece la valoración de los requisitos

de calidad.
La identificación de requerimientos de calidad permite determinar los pesos a

ser asignados en el modelo de calidad y que debe reflejar las necesidades
de calidad del usuario para cada una de las características y
subcaracterísticas. Los pesos representan la valoración comparada entre las
distintas características y subcaracterísticas y para ello se puede utilizar una
calificación relativa de alto / medio / bajo o una calificación basada en valores
que puede ir entre 1 y 9. En la figura 8 se establecen los principios que están
involucrados en primera instancia, en la ejecución de este aspecto.
2.2.1. Valoración de requisitos de documentación del SGC
27
 Declaraciones documentadas de una política de la calidad y de objetivos

de la calidad.
 Manual de calidad.
 Procedimientos documentados establecidos en la Norma 9001:2000.
 Documentos necesitados por la organización para asegurarse de la
eficaz planificación, operación y control de sus procesos, y
 Los registros requeridos por la Norma 9001:2000.
2.2.2. Procesos de Software
 Descripciones de los procesos.

 Descripciones de las instrucciones sobre procedimientos y/o plantillas
usadas.
 Descripciones de los modelos de ciclo de vida usados.
 Descripciones de las herramientas, técnicas, tecnologías y métodos.
 Tópicos técnicos tales como normas o documentos de orientación para la
codificación, diseño y desarrollo y pruebas.
2.2.3. Evaluación del manual de calidad
(ISO 90003 4.2.2) La organización debe establecer y mantener un manual de

la calidad que incluya:
 El alcance del sistema de gestión de la calidad, incluyendo los detalles y

la justificación de cualquier exclusión.
28
 Los procedimientos documentados establecidos para el sistema de

gestión de la calidad o referencia de los mismos.
 Una descripción de la interacción entre los procesos del sistema de
gestión de la calidad.
2.2.4. Control de documentos
Los documentos requeridos por el sistema de gestión de la calidad deben

controlarse. Los registros son un tipo especial de documento y deben
controlarse con los requisitos citados en el numeral 2.2.5 de este capítulo
(Control de registros).
Debe establecerse un procedimiento documentado que defina los controles

necesarios para:
 Aprobar los documentos en cuanto a su adecuación antes de su emisión.

 Revisar y actualizar los documentos cuando sea necesario y aprobarlos
nuevamente.
 Asegurarse de que se identifican los cambios y el estado de revisión
actual de los documentos.
 Asegurarse de que las versiones pertinentes de los documentos
aplicables se encuentran disponibles en los puntos de uso.
 Asegurarse de que los documentos permanecen legibles y fácilmente
identificables.
 Asegurarse de que se identifican los documentos de origen externo y se
controla su distribución.
29
 Prevenir el uso no intencionado de documentos obsoletos, y aplicarles

una identificación adecuada en el caso de que se mantengan por
cualquier razón.
2.2.5. Control de los registros
Los registros deben establecerse y mantenerse para proporcionar evidencia

de la conformidad con los requisitos así como de la operación eficaz del
sistema de gestión de la calidad. Los registros deben permanecer legibles,
fácilmente identificables y recuperables. Debe establecerse un procedimiento
documentado para definir los controles necesarios en la identificación, el
almacenamiento, la protección, la recuperación, el tiempo de retención y la
disposición de los registros.
2.2.6. Evidencia de conformidad con los requisitos
La evidencia de conformidad con los requisitos puede incluir:
 Resultados de pruebas documentadas.

 Informes sobre problemas, incluidos los relacionados con problemas de
herramientas.
 Solicitudes de cambios.
 Documentos marcados con comentarios.
 Informes de auditorías y evaluaciones.
 Registros de revisiones e inspecciones tales como revisiones de diseño,
inspecciones de código y revisiones estructuradas.
30
2.2.7. Evidencia de operación eficaz
Algunos ejemplos de evidencia de la operación eficaz del sistema de gestión

de la calidad pueden ser los siguientes, entre otros:
 Cambios (y su fundamento) hechos a los recursos (personas, software y

equipos).
 Estimados, por ej. Tamaño del proyecto y esfuerzo (personal, costo,
cronograma).
 Por qué y cómo se seleccionaron y calificaron las herramientas,
metodologías y proveedores.
 Acuerdos de licencia de software (tanto para el software suministrado a
clientes, como para el software adquirido para ayudar al desarrollo)
 Actas de las reuniones.
 Registros de liberación de software.
2.2.8. Retención y disposición
Cuando se determinan los periodos de retención para los registros, se

deberían considerar los requisitos estatutarios y reglamentarios. Cuando los
registros, se conservan en medios electrónicos, al considerar los tiempos de
retención y accesibilidad de los registros se debería tener en cuenta la tasa
de degradación de los medios, la disponibilidad de los dispositivos y el
software necesario para acceder a los registros.
31
Los registros pueden incluir la información conservada en los sistemas de

correo electrónico. Es conveniente considerar la protección de los
computadores contra virus, y el acceso no aprobado o ilegal.
Se debería evaluar la naturaleza de la propiedad de la información

almacenada en los registros, al determinar los métodos de eliminación de los
datos de los medios al final del periodo de retención requerido.
2.3. VALORACIÓN DE RESPONSABILIDAD DE LA DIRECCIÓN
Figura 9. Principios y habilitadores en los cuales se establece la valoración de

responsabilidad de la dirección.
El personal a todos los niveles es la esencia de la institución y su total

compromiso posibilita que sus habilidades sean usadas en beneficio de la
organización.
32
Sin embargo se debe diferenciar al gobierno de la administración, el primero

asegura el logro de los objetivos de la organización, al evaluar las
necesidades de las partes interesadas, así como las condiciones y opciones;
fijando directivas al establecer prioridades y tomar decisiones; así como
monitorear el desempeño, cumplimiento y progreso, comparándolos contra
las directivas y objetivos acordados.
La administración planifica, construye, ejecuta y monitorea las actividades

conforme a las directivas fijadas por el ente de Gobierno para lograr los
objetivos de la Organización.
Aplicar este principio permite aceptar la posición y responsabilidad para

resolver problemas, buscar activamente oportunidades de mejora, buscar
activamente oportunidades para aumentar su competencia, conocimientos y
experiencia y ser entusiasta y estar orgullosos de formar parte de la
organización.
2.3.1. Compromiso de la dirección
La alta dirección debe proporcionar evidencia de su compromiso con el

desarrollo e implementación del sistema de gestión de la calidad, así como
con la mejora continua de su eficacia. Las acciones de las que se deben
tomar evidencias mínimas verificables son:
a. Comunicar a la organización de la importancia de satisfacer tanto los

requisitos del cliente como los legales y reglamentarios.
33
b. Establecer las políticas de calidad.
c. Asegurar que se establezcan los objetivos de la calidad.
f. Ejecutar revisiones sobre el cumplimiento de objetivos y la ejecución de

los planes.
g. Asegurar la disponibilidad de recursos.
2.3.2. Enfoque al cliente
La alta dirección debe asegurarse de que los requisitos del cliente se

determinan y se cumplen con el propósito de aumentar la satisfacción del
cliente.
Las organizaciones dependen de sus clientes y por lo tanto deben

comprender sus necesidades actuales y futuras, satisfacer sus requisitos y
esforzarse por exceder sus expectativas.
Aplicar este principio permite comprender toda la gama de necesidades del

cliente y sus expectativas para los servicios educativos, entrega, precios y
calidad, así como comunicar estas necesidades y expectativas en toda la
organización además de medir la satisfacción del cliente y tomar las acciones
apropiadas conforme a los resultados.
34
Es clave evaluar cómo se forman políticas, haciendo que las necesidades de

los clientes y otras partes interesadas sean comprendidas en toda la
organización así como el establecimiento de metas, asegurando que las más
importantes se relacionen directamente a las necesidades y expectativas del
cliente.
También se debe analizar como la organización gestiona las operaciones,

mejorando el desempeño de la organización para cumplir las necesidades
del cliente y finalmente evaluar que la organización se asegura de que el
personal cuente con los conocimientos y habilidades requeridas para
satisfacer a los clientes.
2.3.3. Política de la calidad
La alta dirección debe asegurarse de que la política de la calidad es

adecuada al propósito de la organización, incluye un compromiso de cumplir
con los requisitos y de mejorar continuamente la eficacia del SGC. También
que proporciona un marco de referencia para establecer y revisar los
objetivos de la calidad, que es comunicada y entendida dentro de la
organización y es revisada para su continua adecuación.
2.3.4. Planificación
La alta dirección debe asegurarse de que los objetivos de la calidad,

incluyendo aquellos necesarios para cumplir los requisitos para el producto,
se establecen en las funciones y niveles pertinentes dentro de la
35
organización. Los objetivos de la calidad deben ser medibles y coherentes

con la política de la calidad.
Generalmente, los objetivos de calidad suelen escogerse durante las

revisiones periódicas del sistema de gestión de calidad, tras analizar el grado
de logro de los objetivos del periodo anterior. Para ello deben ser medibles,
coherentes con la política de calidad, deben documentarse, etc.
Aunque la determinación de estos objetivos es responsabilidad de la alta

dirección de la organización, se recomienda tener en cuenta la opinión de los
responsables de los departamentos implicados, pues ante todo, los objetivos
han de poder llegar a alcanzarse, y estas opiniones serán imprescindibles
para conocer los recursos que requerirán los objetivos planteados.
La planificación puede ocurrir a nivel organizacional y de proyecto/producto.
A nivel de organización puede incluir lo siguiente:
a. Definición de los modelos apropiados de ciclo de vida del software.
b. Definición de los productos del trabajo de desarrollo de software, por

ejemplo los documentos de requisitos de software, los documentos de
diseño arquitectónico, el código de programa, etc.
c. Definición del contenido de los planes de gestión de software, tales como

los planes de gestión de proyectos de software, planes de gestión de la
configuración de software, planes de verificación y validación del
36
software, planes de aseguramiento de la calidad del software y planes de

formación.
d. Definición de la forma en que los métodos de ingeniería del software se

adaptan a los proyectos de la organización dentro del ciclo de vida de
software.
e. Identificación de las herramientas y ambiente para el desarrollo,

operación o mantenimiento del software.
f. Especificación de las convenciones para el uso de lenguajes de

programación, por ejemplo: reglas de codificación, bibliotecas y
framework.
g. Identificación de cualquier reutilización de software.
El representante de la dirección de la organización debería considerar

cualquier cambio a un modelo de ciclo de vida del software que puede
afectar el sistema de gestión de la calidad, y debería asegurar que estos
cambios no comprometen ninguno de los controles del sistema de gestión de
la calidad.
2.3.5. Responsabilidad, autoridad y comunicación
La alta dirección debe asegurarse de que las responsabilidades y

autoridades están definidas y son comunicadas dentro de la organización.
Además la alta dirección debe designar un miembro de la dirección quien,
37
con independencia de otras responsabilidades, debe tener el compromiso y

autoridad que incluya:
a. Asegurarse de que se establecen, implementan y mantienen los

procesos necesarios para el sistema de gestión de la calidad,
b. Informar a la alta dirección sobre el desempeño del sistema de gestión

de la calidad y de cualquier necesidad de mejora, y
c. Asegurarse de que se promueva la toma de conciencia de los requisitos

del cliente en todos los niveles de la organización.
Para una organización que produce software, es benéfico si el representante

de la dirección ha tenido experiencia en el desarrollo de software.
2.3.6. Representante de la dirección
La alta dirección debe asegurar que se establecen los procesos de

comunicación apropiados dentro de la organización y que la comunicación se
efectúa considerando la eficacia del sistema de gestión de calidad.
2.3.7. Comunicación interna
La especialización del trabajo por departamentos incomunica las partes del

proceso, por eso hoy la comunicación es la herramienta fundamental para la
reducción de tiempo, errores y para la comprensión global del proceso.
38
La comunicación es el pilar de la operación de la calidad, debe ser un agente

innovador al brindar los elementos para el mejoramiento de los procesos y un
canal para generar insumos de más información y nuevas ideas que
permitan que la organización cumpla con sus objetivos de calidad. La
comunicación de una organización comprometida con la calidad debe velar
por:
a. Hacer que la información de los usuarios ascienda en las estructuras

administrativas para lograr un equilibrio entre las obligaciones del cliente
y los requerimientos de éste para cumplirlos.
b. Lograr que la información llegue a todas y cada una de las direcciones

generando mejores procesos de servicio.
c. Generar interacciones innovadoras entre las direcciones para ajustar

procesos y evitar desperdicio de recursos (tiempo, etc.) e incluso
procurando el desarrollo de sinergias entre las direcciones.
d. Procurar que el direccionamiento desde la dirigencia de la organización

llegue a todos y cada uno de los colaboradores generando dinámicas de
gestión apropiadas a los requerimientos de los clientes.
2.3.8. Revisión por la dirección
La alta dirección debe, a intervalos planificados, revisar el SGC de la

organización, para asegurarse de su conveniencia, adecuación y eficacia
continuas. La revisión debe incluir la evaluación de las oportunidades de
39
mejora y la necesidad de efectuar cambios en el sistema de gestión de la

calidad, incluyendo la política y los objetivos de la misma.
2.3.8.1. Información para la revisión
La información de entrada para la revisión por la dirección debe incluir:
 Resultados de auditorías.
 Retroalimentación de los clientes.
 Desempeño de los procesos y conformidad del producto.
 Estado de las acciones correctivas y preventivas.
 Acciones de seguimiento de revisiones por la dirección previas.
 Cambios que podrían afectar al sistema de gestión de la calidad.
 Recomendaciones para la mejora.
Una forma de medir el desempeño del proceso es realizar evaluaciones del

proceso de software. Los resultados de estas evaluaciones se deberían
considerar como entradas para la revisión por la dirección.
Una forma de medir la conformidad del producto de software es realizar la

evaluación del mismo. Los resultados de dicha evaluación se deberían
considerar como elementos de entrada para la revisión por la dirección.
2.3.8.2. Resultados de la revisión
Los resultados de la revisión por la dirección deben incluir todas las

decisiones y acciones relacionadas con:
40
 La mejora de la eficacia del sistema de gestión de la calidad y sus

procesos.
 La mejora del producto en relación con los requisitos del cliente.
 Las necesidades de recursos.
2.4. GESTIÓN DE LOS RECURSOS
Figura 10. Principios y habilitadores en los cuales se define la gestión de los recursos.
Se debe realizar una gestión eficiente y eficaz de los recursos con objeto,
entre otras razones, de minimizar costes y satisfacer tanto a clientes como al
resto de las partes implicadas. La provisión de recursos se refiere a recursos
tales como edificios, trabajadores, materiales, instalaciones, proveedores etc.
41
Los directores, departamentos, etc. solicitaran, preferiblemente por escrito

(según se especifique en el manual de calidad) las necesidades de recursos
para poder cumplir con el SGC.
La Organización debe proporcionar los recursos necesarios para:
a. Implementar y mantener el sistema de gestión de la calidad y mejorar

continuamente su eficacia.
b. Aumentar la satisfacción del cliente mediante el cumplimiento de sus

requisitos.
2.4.1. Recursos humanos
El personal que realice trabajos que afecten a la calidad del producto debe
ser competente con base en la educación, formación, habilidades y
experiencias apropiadas.
La organización debe determinar la competencia necesaria para el personal

que realiza trabajos que afectan la calidad del producto, proporcionar
formación o tomar otras acciones para satisfacer dichas necesidades;
evaluar la eficacia de las acciones tomadas, asegurarse de que su personal
es consciente de la pertinencia e importancia de sus actividades y de cómo
contribuyen al logro de los objetivos de la calidad y mantener los registros
apropiados de la educación, formación, habilidades y experiencia.
42
Las necesidades de formación se deberían determinar considerando la

notación de los requisitos, los métodos de diseño, los lenguajes de
programación específicos, las herramientas, técnicas y recursos informáticos
que se van a usar en el desarrollo y gestión del producto/proyecto de
software. También podría ser útil incluir capacitación en cuanto a habilidades
y conocimientos del campo específico dentro del cual se aplica el software y
en otros tópicos, tales como gestión de proyectos y para el caso de los SIG,
conocimientos de geodesia, geografía, cartografía, etc.
Las tecnologías empleadas en el desarrollo, operación y mantenimiento de

software se deberían someter a seguimiento y evaluación continuos, para
determinar los requisitos de actualización de las habilidades del equipo del
proyecto.
La forma de impartir formación no necesariamente debe ser la tradicional,

sino que podría ser autoestudio, entrenamiento asistido por computador,
tutoría, capacitación en el trabajo y formación por internet. La evaluación de
la eficacia de la formación se puede llevar a cabo usando mediciones de
productos y procesos, e identificando las áreas de mejora en el desempeño
personal (entre otras áreas de mejora).
2.4.2. Infraestructura
La organización debe determinar, proporcionar y mantener la infraestructura

necesaria para lograr la conformidad con los requisitos del producto. La
infraestructura incluye, cuando sea aplicable:
43
 Edificios, espacio de trabajo y servicios asociados.

 Equipo para los procesos (tanto hardware como software).
 Servicios de apoyo tales como transporte o comunicación.
La infraestructura debería incluir el hardware, el software, las herramientas e

instalaciones para el desarrollo, operación o mantenimiento del software. La
infraestructura puede componerse de herramientas de software que apoyen
el proceso de diseño y desarrollo, incluyendo lo siguiente:
 Herramientas, por ejemplo para análisis, diseño y desarrollo, gestión de

la configuración, pruebas, gestión de proyectos, documentación y
creación o generación de código.
 Desarrollo de las aplicaciones y ambientes de soporte.
 Gestión del conocimiento, Intranet, herramientas de extranet.
 Herramientas de la red, incluida la seguridad, copias de respaldo,
protección contra virus, cortafuegos.
 Soporte técnico y herramientas de mantenimiento.
 Controles de acceso.
 Bibliotecas de software.
 Herramientas de control de operaciones, por ejemplo para monitoreo de
redes, gestión de sistemas y gestión de almacenamiento.
Ya sea que estas herramientas se desarrollen internamente o se compren, la

organización debería evaluar si son aptas o no para el propósito. Las
herramientas usadas en la implementación del producto, tales como las
aplicaciones de análisis, diseño y desarrollo, compiladores y ensambladores,
se deberían evaluar, aprobar y colocar en el nivel apropiado de control de la
44
configuración, antes de su uso. El alcance del uso de estas herramientas y

técnicas se puede documentar con la orientación apropiada, y su uso se
puede revisar, según sea apropiado, para determinar si existe necesidad de
mejorarlas o actualizarlas.
2.4.3. Ambiente de trabajo
La organización debe determinar y gestionar el ambiente de trabajo

necesario para lograr la conformidad con los requisitos del producto. Si bien
no es necesario que todos los miembros que pertenecen al grupo de trabajo
tengan una fuerte interacción y armonía entre ellos, lo cierto es que se
destaca la importancia de un agradable ambiente de trabajo para la
búsqueda, planificación y logro de los distintos objetivos laborales que hayan
sido pactados, teniendo para ello un rol jerárquico que es asignado
arbitrariamente por los mandatarios de la compañía.
De este modo, la organización debe propiciar la comodidad del trabajador

buscando aportar elementos que resulten en un trabajo mucho más ameno y
confortante, con la realización de actividades que busquen una mayor pro-
acción al trabajo en Equipo, teniendo así mejores resultados y mayor rédito,
además de lograr los objetivos en menor lapso de tiempo, con eficiencia y
eficacia. Comités de convivencia o de seguridad para la salud en el trabajo
propician una mejora sustancial en el ambiente de trabajo de las compañías.
45
3. ENFOQUE DE LA NTC-ISO/IEC 90003 AL DESARROLLO DE

SOFTWARE SIG
En este capítulo se describen los puntos esenciales para el desarrollo de un

producto de software según la norma NTC-ISO/IEC 90003, como parte
central del modelo orientado a SIG.
Se debe tener en cuenta que para la realización del producto de software

SIG, debe haber coherencia con los requisitos del SGC planteados en el
capítulo 2 de este documento. Los formatos asociados a esta fase del
modelo se encuentran en el anexo F.
3.1. PLANIFICACION DE LA REALIZACIÓN DEL PRODUCTO
La planificación de un producto de software SIG comienza por tener en

cuenta el propósito estratégico de la organización dentro de la cual se
desarrollará el SIG. Se deben definir las metas, objetivos y
responsabilidades. Esta etapa asegura que el proceso de planificación del
SIG y el producto final se ajusten al contexto organizativo y se adhieran
realmente a los objetivos estratégicos de la organización22.
3.1.1. Ciclo de vida del software
Los procesos, actividades y tareas de desarrollo de software SIG deberían

ejecutarse usando modelos de ciclo de vida de software adecuados.
22
TOMLINSON Roger. Pensando en el SIG. 3 ed. Redlands CA: ESRI Press; 2008. P. 8.
46
El modelo de ciclo de vida define el estado de las fases a través de las

cuales se mueve un proyecto de desarrollo de software SIG, aunque en la
NTC-ISO/IEC 90003 no se hace referencia a la aplicación de algún ciclo en
particular, todas sus disposiciones si están enfocadas a un momento
específico del software. Así se visualiza una estrecha relación entre lo que el
modelo abarca y las distintas fases que supone un ciclo de vida.
3.1.2. Planificación de la calidad
La planificación de la calidad se trata de conectar el SGC al proyecto de

desarrollo de software SIG, esto quiere decir, que en el proyecto se cumpla
con los requisitos de calidad tales como: documentación, responsabilidades y
procesos.
La etapa de planificación llega a ser tan compleja que se aborda como un

proyecto en sí misma, en donde se fijan unos objetivos y se esperan unos
resultados.
Como resultado se debe obtener un documento con la propuesta de

planificación de la calidad, debidamente aprobado por la alta gerencia de la
organización. Dicho documento debe contener como mínimo los siguientes
aspectos:
a. Descripción del proyecto del software SIG.

Antecedentes.
Objetivos.
47
Resultados esperados.
Adaptación del SGC.
Definición de actividades de revisión, verificación, validación.
Definición de procedimientos de gestión de la configuración.
Definición de actividades de monitoreo y medición.
Gestión del cambio.
b. Estudio de los requisitos del software SIG.

Evaluación de necesidades.
Ámbito del sistema.
Definición del equipo SIG y sus respectivas necesidades de formación.
Modelo de calidad del producto y requisitos de calidad (sección 3.2.1).
c. Diseño conceptual del software SIG.

Plan para el diseño y desarrollo (sección 3.3.1).
Diseño de la base de datos.
Diseño de la tecnología (hardware y software).
Diseño de pruebas.
d. Planificación de la implementación del software SIG.

Plan para la implementación (sección 3.4).
Mecanismos de seguimiento y mejora.
En la Figura 11 se hace un resumen del subsistema “planificación de la

realización del producto de software SIG”, que hará parte del modelo de
aplicación de la NTC-ISO/IEC 90003 al desarrollo de software SIG.
48
Figura 11. Subsistema “planificación de la realización del producto” con los aspectos a
evaluar para su aplicación en el desarrollo de software SIG.
3.2. PROCESOS RELACIONADOS CON EL CLIENTE
En este punto se deben definir los requisitos del producto de software SIG, a
partir de las necesidades de los Stakeholders, grupo en donde se incluye el
cliente. Aquí también se tiene en cuenta un modelo de calidad como
elemento que acompaña la definición de los productos del SIG, que a la
postre serán los datos alfanuméricos y geográficos transformados en
información útil.
3.2.1. Determinación de los requisitos relacionados con el producto
Para este proceso, el paso inicial por parte de la organización debe ser la
recolección de información a partir de la presentación del proyecto SIG con el
cliente. Esta presentación consiste en dar una descripción general de la
experiencia de la organización, los objetivos del SIG, el modelo de ciclo de
49
vida, entre otros aspectos. En el marco de esta presentación, se debe llegar

a una breve identificación de los productos informativos del software SIG,
que a su vez estén acompañados de un modelo de requisitos de calidad de
software. La definición de requisitos de esta etapa debe tener:
a. Modelo de calidad de software.
La calidad de un producto de software SIG se refiere a la capacidad de

satisfacer necesidades definidas o implícitas; un modelo de calidad debe
ser la piedra angular para la definición de requisitos; características sobre
las cuales se evalúa la calidad del software SIG.
El modelo de calidad del producto definido por la ISO 2501023 se

encuentra compuesto por ocho características de calidad: adecuación
funcional, eficiencia de desempeño, compatibilidad, usabilidad, fiabilidad,
seguridad, mantenibilidad, portabilidad.
Figura 12. Modelo de calidad del producto de software definido por la ISO/IEC 25010.
Fuente: PORTAL ISO 25000. http://iso25000.com/index.php/normas-iso-25000/iso-25010

[Consulta: 29 de febrero de 2016].
23
ISO/IEC. Software engineering ─ Software product Quality Requirements and Evaluation
50
b. Descripción de requisitos según el ciclo de vida el software.
La determinación de requisitos para el software SIG se puede aplicar a

diferentes escenarios como: contrato de realización del desarrollo,
producto para un mercado, software embebido o como proceso de apoyo
a los procesos internos de la organización. En cualquiera de estos
escenarios el software estará enmarcado en la etapa correspondiente del
ciclo de vida.
De esta forma, los requisitos los puede suministrar el cliente como

necesidades iniciales, la organización debe hacer una especificación de
los mismos a través de métodos para el levantamiento, la comprobación,
el registro y la trazabilidad (por ejemplo una matriz de trazabilidad de
requisitos).
Cuando se proporcionan los requisitos se deben tener en cuenta los

elementos de hardware y software (por ejemplo interfaces) que
respondan a la naturaleza del SIG; esto define el ambiente operacional
del software.
Es posible que se deban desarrollar requisitos en un proceso posterior al

levantamiento de los mismos. En este caso, puede existir o no un
acompañamiento del cliente.
Los requisitos deben compilarse en un documento operativo, deben

quedar expresados en términos claros sin ambigüedades, que faciliten la
validación y la aceptación del producto.
51
c. Descripción de productos informativos de software SIG.
Las descripciones de productos informativos de un software SIG son

componentes fundamentales para especificar el resultado que el software
puede generar. Se trata de un ejercicio creativo donde se definen con
claridad lo que el sistema debe producir; los datos y funciones que se
necesitan para crear dichos productos; y el beneficio que traerá su
elaboración.
Al hacer esta especificación, se aclara lo que se debe incluir en el

Sistema de Información Geográfica, por ejemplo los mapas, imágenes,
geoservicios, herramientas, consultas, etc. En la Tabla 3 se muestra una
lista de componentes que debería tener un producto informativo.
Tabla 3. Principales componentes de la definición de productos informativos.

Componente Actividad vinculada
Título Definir el nombre de forma concisa, que indique
para qué se usa la información.
Nombre del solicitante Indicar quién ha solicitado el producto
informativo para que sea involucrado en el
proceso de desarrollo
Sinopsis Explicar o resumir el producto informativo y su
finalidad.
Requisitos de mapas Listar cada mapa o Geoservicio que se
necesitan para mostrar en un resultado final.
Requisitos de imagen Incluir las imágenes o representaciones que se
necesiten para el producto.
Requisitos de esquemas Listar los datos representados geográficamente
que deban estar en el producto informativo.
52
Pasos para llegar al producto Describir el flujo de ejecución que traería el uso
del producto, incluyendo las funciones que se
necesitan, por ejemplo: consulta de atributos,
análisis de redes, cambios de escala.
Frecuencia de uso Definir la demanda general que tendrá el
producto informativo, teniendo en cuenta las
funciones que usa para generarlo.
Asociaciones lógicas Indicar las relaciones entre los datos que se
verán reflejadas en las operaciones de las
bases de datos.
Errores Describir los posibles errores que se pueden
presentar al utilizar el producto informativo.
Espera y respuesta Definir los tiempos de respuesta aceptables
para obtener el producto informativo.
Costo/Beneficios Realizar un análisis de costos y de beneficios
para la aprobación del producto informativo.
Fuente: Adaptación de los autores. TOMLINSON Roger. Pensando en el SIG. 3
ed. P. 34.
d. Categorización de los requisitos.
Los requisitos del software SIG deben ser definidos en un contexto

amplio, los requisitos específicos de funcionalidades o de productos
informativos deben estar “estrechamente relacionados con requisitos de
calidad del software”24.
La categorización de los requisitos permite identificar una relación de los

mismos en el sistema y a su vez, determinar en qué ámbitos del ciclo de
24
(SQuaRE) ─ Quality requirements. ISO; 2007. P. 8. ISO/IEC 25030.
53
vida se encuentran los requisitos de calidad; esto es: requisitos de

calidad en uso (entorno operacional), de calidad externa (caja negra) y
de calidad interna (caja blanca). En la Tabla 4 se aprecia dicha
categorización.
Tabla 4. Categorización de requisitos del Sistema de Información Geográfica.
Requisitos funcionales: mapas, imágenes,

esquemas de datos espaciales, demanda de
uso, funcionalidades espaciales.
De calidad en uso: Tiempos

de respuesta adecuados
para funcionalidades
Requisitos
espaciales.
inherentes
Requerimientos de software SIG
Requisitos
Requerimientos del SIG
de calidad de De calidad externa (caja

software negra): Tolerancia a errores.
Requisitos
del producto
de software De calidad interna (caja
SIG blanca): Metodología de
desarrollo
Requisitos administrativos al interior de la

organización que desarrolla el SIG.
Requisitos
de Requisitos contractuales con el cliente.
propiedades
del software
Entregables para el cliente: Visor geográfico,
servicios Web de mapas, base de datos
geográfica.
54
Requisitos del proceso de desarrollo: Plataforma de

desarrollo alfanumérica, plataforma de visualización
Requisitos geográfica, arquitectura de los servicios Web geográficos,
de desarrollo modelo y plataforma de base de datos espacial.
de software
SIG Requisitos organizacionales de desarrollo: Manuales de
desarrollo SIG, roles del proceso de desarrollo, revisión,
verificación y validación.
requisitos
Otros
Hardware, software, datos adicionales para los productos informativos SIG,

fuerzas de tarea adicionales, costos y soporte.
Fuente: Adaptación de los autores. ISO/IEC 25030. P. 10.
3.2.2. Revisión de los requisitos relacionados con el producto
La revisión de los requisitos se debe realizar antes de que la organización se

comprometa a proporcionar un producto SIG al cliente; de esta forma debe
asegurar que:
 Están definidos los requisitos del producto de software.

 Se han resuelto las diferencias entre los anteriores requisitos y los
plasmados en un contrato.
 La organización está en capacidad de cumplir con los requisitos.
Se pueden establecer revisiones puntuales por parte de la organización:
 Viabilidad de cumplir los requisitos de calidad del software SIG.

 Normas y procedimientos para el diseño y desarrollo.
 Identificación de instalaciones, herramientas, elementos de software y
hardware, y datos de que debe suministrar el cliente.
55
 Requisitos de replicación y distribución.

 Aspectos de gestión como cronograma de avance, revisiones técnicas,
requisitos de instalación y mantenimiento, disponibilidad de recursos
humanos y financieros.
 Aspectos legales como derechos de propiedad intelectual, licencia,
confidencialidad, protección de la información, derechos de autor, nivel
de divulgación, garantía, responsabilidades y sanciones.
De igual forma se pueden incluir los siguientes requisitos para la revisión:
 Criticidad, protección y seguridad,

 Experiencia de la organización.
 Confiabilidad de los recursos y duración de la actividad.
 Diferencias significativas entre los tiempos requeridos y los tiempos
planificados.
 Planes de optimización y costos errados.
 Innovación técnica.
 Baja calidad o disponibilidad del software, herramientas y datos
suministrados.
 Baja precisión o inexactitud de la definición de requisitos y los productos
informativos.
 Cambios en el contrato, alcance y funcionalidades.
Finalmente, se debe tener un registro de la revisión de requisitos en un

formato determinado en el SGC. Si hay cambios en los requisitos, se debe
también cambiar la documentación pertinente.
56
3.2.3. Comunicación con el cliente
La organización debe determinar e implementar disposiciones eficaces para

la comunicación con los clientes. Si el cliente tiene responsabilidades en el
contrato, se debe asignar un representante del cliente que realice
seguimiento al ciclo de vida del software y adicionalmente sea el canal para
garantizar el suministro de la información de manera oportuna.
En la Figura 13 se hace un resumen del subsistema “planificación de la

realización del producto”, que hará parte del modelo de aplicación de la NTC-
ISO/IEC 90003 al desarrollo de software SIG.
Figura 13. Subsistema “procesos relacionados con el cliente” con los aspectos a evaluar
para su aplicación en el desarrollo de software SIG.
57
3.3. DISEÑO Y DESARROLLO
En este punto, la organización debe establecer los procesos necesarios para

conseguir un diseño adecuado del software SIG y un desarrollo consecuente
con dicho diseño. Es importante decir que un insumo primordial para estos
procesos son los requisitos del producto de software. A partir de estos se
puede: definir un ámbito del SIG, realizar una planificación de las etapas del
diseño y del desarrollo, definir los hitos para estos procesos, y realizar una
evaluación de los resultados obtenidos.
3.3.1. Planificación del diseño y desarrollo
Para minimizar la aparición de problemas en los procesos de diseño y

desarrollo, se deben aplicar las prácticas adecuadas de ingeniería de
software. La organización debe asegurarse de que el producto de software
SIG se desarrolla de conformidad con los requisitos especificados, y de
acuerdo con la planificación de la realización del producto (sección 3.1).
La planificación del diseño y desarrollo de software SIG debería abordar los

siguientes elementos:
a. Datos de entrada requeridos y funciones de entrada.
El software SIG requiere datos para generar los productos informativos.

En la Lista Maestra de Datos de Entrada25 (MIDL) se debe identificar
cada conjunto de datos, evaluar su volumen y formato, y la disponibilidad
25
TOMLINSON Roger. Pensando en el SIG. 3 ed. Redlands CA: ESRI Press; 2008. P. 59.
58
y costo. Esta lista guiará la creación de la base de datos (secciones 3.3.2

y 3.3.3) posteriormente, de modo que con ella se debería estimar con
mucha precisión cuánto trabajo se necesitará (digitalización, introducción
de datos alfanuméricos).
Un conjunto de datos puede ser incluido en la MIDL, siempre que se

necesite para al menos un producto informativo. En la Tabla 5 se
muestran los componentes de una lista maestra de datos de entrada y
los detalles de cada uno.
Tabla 5. Componentes de la MIDL.

Componente Detalles necesarios
Nombre del conjunto de datos

ID del conjunto de datos
Identificación de los datos geográficos Organización de origen
URL del servicio Web geográfico
Metadatos disponibles
Consideraciones acerca de la cantidad de datos Formato de los datos digitales

geográficos Volumen de los datos
Escala
Tipo
Características de los datos geográficos
Datum
Texto alfanumérico.
Derechos
Disponibilidad y costo de los datos geográficos Costo de adquisición
Restricciones de uso
Fuente: Adaptación de los autores. TOMLINSON Roger. Pensando en el SIG. 3 ed. P. 62.
59
Adicional a esto, se pueden evaluar las operaciones básicas para

trasladar el conjunto de funciones de la MIDL al software SIG
(reformatear, crear la base de datos, transferir archivos).
b. Prioridades y alcance del sistema.
Los productos informativos deberían tener una calificación (puntuación

consenso) de importancia relativa sobre la contribución a los objetivos del
SIG. Esto permitirá darles una clasificación adicional para ser tenidos en
cuenta en los procesos de diseño y desarrollo del software.
Así mismo, el alcance del sistema se debe determinar teniendo en

cuenta los productos informativos y la Lista Maestra de Datos de
Entrada; a su vez, hacer una evaluación sobre las necesidades que
conllevan tanto la manipulación de estos datos, como su transformación
a través del software SIG, por ejemplo: necesidades de carga de datos,
hosting, desarrollo, seguridad y almacenamiento (hardware).
c. Cronograma y planificación de actividades.
Para crear los productos informativos del software SIG se debe realizar
una cuidadosa planificación de tiempos y recursos. Es necesario
comprender factores como: la disponibilidad de los datos (vectoriales,
raster) y las bases de datos espaciales; la programación de aplicaciones
(partiendo de las descripciones de productos informativos); y la
adquisición de hardware y software
60
Adicionalmente, se debe incluir la capacitación del personal involucrado

en el diseño y desarrollo: profesionales que contribuyen a los estudios
del SIG, a la producción de mapas y al mantenimiento de datos y
servicios Web geográficos; profesionales dedicados al análisis espacial;
usuarios finales que no necesitan conocimientos geográficos; y
finalmente usuarios que necesitan principalmente mapas estáticos del
SIG.
Esta planificación debe estar representada en un cronograma en el que

se puedan identificar las etapas de proyecto, las estructuras de
descomposición del trabajo, recursos asociados, hitos y eventos
importantes, y las actividades de verificación y validación. Los puntos
siguientes de esta sección (d, e, y f) deben ser tenidos en cuenta en el
cronograma.
d. Control del producto y la prestación del servicio. Esto incluye el control de

documentación o registros y el análisis de posibles riesgos como
limitaciones en el levantamiento de datos geográficos e indisponibilidad
de servicios Web geográficos.
e. Identificación de normas geográficas y estándares de publicación de

servicios Web geográficos, herramientas, hardware, seguridad.
Organización de los recursos de proyectos, incluida estructura del equipo
de desarrollo y sus responsabilidades.
f. Actividades de diseño y desarrollo, codificación, integración, pruebas,

instalación y soporte para la aceptación del producto de software SIG,
incluyendo la identificación de actividades de gestión.
61
Se debe prestar especial atención para los productos informativos que

requieren desarrollo a la medida. Se debe estimar el tiempo de
programación necesario para cada producto informativo sin que este
tiempo supere el ciclo de vida del software SIG.
3.3.2. Elementos de entrada para el diseño y desarrollo
Los elementos de entrada para los procesos de diseño y desarrollo están

directamente relacionados con los requisitos del sistema (sección 3.2), pero
también pueden surgir de otras técnicas como la elaboración de prototipos o
reingeniería.
Modelos de ciclo de vida, los requisitos funcionales, los productos

informativos, aspectos legales, herramientas de programación como
frameworks, lenguajes de programación, bibliotecas, estructuras y la
información reutilizable de otros proyectos (cuando aplique); deben contarse
como elementos de entrada para el diseño y el desarrollo del SIG.
De igual forma, para un Sistema de Información Geográfica se debería tener

como elemento de entrada primordial el diseño conceptual de los datos, ya
que las características de los datos definirán en gran parte el diseño de la
arquitectura del sistema. A continuación se muestra lo que se necesita saber
sobre los datos geográficos de un software SIG.
 Escala.
 Resolución.
62
 Proyección.
 Tolerancia al error.
Adicionalmente, se debe dar especial importancia a actividades sobre estos

elementos de entrada pensando en el proceso de desarrollo:
 Examinar los datos que satisfacen los requisitos y conocer las fuentes
dónde se pueden encontrar.
 Aplicar estándares de interoperabilidad.
 Establecer una topología.
 Determinar la cartografía base.
 Especificar las funciones espaciales y de análisis de red y otras
funciones que requieran conversión de datos.
 Informar y corregir oportunamente ambigüedades, inconsistencias o
contradicciones en los requisitos y productos informativos.
3.3.3. Resultados del diseño y desarrollo
Para el software SIG es ideal llegar a comprender los hitos o criterios para
comenzar y terminar cada etapa del proyecto. En los procesos de diseño y
desarrollo, es necesario comprender los elementos de datos e infraestructura
necesarios para crear los productos informativos; de esta forma, como
resultados principales del diseño y desarrollo se obtienen: especificaciones
de diseño, el modelo lógico de datos, el código fuente, la arquitectura del
sistema tecnológico del SIG, el producto de software SIG desarrollado y los
documentos operativos o de mantenimiento.
63
Para las especificaciones de diseño se debe prestar atención especial a los

diseños de las clases y las secuencias del software. Adicionalmente, al
momento de crear el modelo lógico de la base de datos hay que tener en
cuenta factores determinantes:
 Agrupaciones lógicas de los elementos geográficos.

 Un sólo tipo de proyección y un sólo tipo de unidades de los mapas.
 Elección de la precisión de las coordenadas.
 Definición de entidades, relaciones y atributos.
Además de lo anterior se debe dar garantía de que el software SIG seguirá

estándares de interoperabilidad; como referencia se pueden seguir los
estándares de datos y estándares tecnológicos definidos por la ICDE 26.
Tabla 6. Estándares relevantes para la interoperabilidad.
Estándares de los SIG
Metadatos Estándares FGDC, ISO 19115
Formatos de datos espaciales SDTS, GML, KML, shapefile
Servicios Web WMS, WFS, WCS, CSW
Estándares de TI
Servicios Web XML, WSDL, SOAP, REST
Protocolos de red HTTP, TCP/IP, FTP
Lenguaje de programación JAVA, .NET, SQL

Fuente: Adaptación de los autores. TOMLINSON Roger. Pensando en el SIG. 3 ed. P. 110.
26
PORTAL ICDE. http://www.icde.org.co /web/guest/estandares_icde [Consulta: 1 DE ABRIL
de 2016].
64
Figura 14. Ejemplo de arquitectura tecnológica para el software SIG.
Fuente: TOMLINSON Roger. Pensando en el SIG. 3 ed. P. 122.
En la Figura 14 se muestra un ejemplo propicio de la arquitectura del sistema

tecnológico del SIG. En dicha arquitectura se implementará el producto de
software y básicamente se muestran los roles de los equipos de computación
para el funcionamiento correcto del software SIG.
Los elementos descritos anteriormente y otros resultados estarán definidos y

documentados más adelante de acuerdo a un modelo de ciclo de vida del
software y a formatos establecidos en el Sistema de Gestión Integrado. La
información plasmada en estos registros debe ser consecuente con los
elementos de entrada descritos en la sección 3.3.2.
Estos resultados de los procesos de diseño y desarrollo también estarán

acompañados de criterios de aceptación para demostrar que los requisitos
funcionales y productos informativos se vean reflejados en el producto de
65
software SIG. En las secciones 3.3.4, 3.3.5 y 3.3.6 se hace una explicación
de las etapas de revisión, verificación y validación de diseño y desarrollo.
3.3.4. Revisión del diseño y desarrollo
Al ritmo el ciclo de vida del software SIG, se deben realizar revisiones del
diseño y del desarrollo. De acuerdo a la complejidad que tenga el software
SIG, se establecerán procedimientos con diferentes criterios para abordar las
revisiones, considerando los elementos siguientes:
 ¿Qué se revisará y qué tipo de revisión se hará, por ejemplo:

demostraciones, correcciones o inspecciones?
 ¿Qué grupos de funcionalidades o productos informativos están

involucrados en cada tipo de revisión?
 ¿Cómo se organiza la revisión, quiénes participan y qué registros se

generarán?
 ¿Qué elementos se requieren para realizar la revisión, como por ejemplo

objetivos y alcance del software, actas de reuniones y documentos del
ciclo de vida del software?
 ¿Cuáles son los criterios de éxito o aceptación para las actividades

específicas en la revisión?
 ¿Qué actividades de seguimiento se realizarán sobre la resolución de

incidentes encontrados en la revisión?
66
3.3.5. Verificación del diseño y desarrollo
La verificación del diseño y desarrollo del software SIG debe realizarse de

acuerdo con lo planificado (sección 3.3.1), los resultados de la verificación y
las acciones correctivas deben mantenerse en registros (sección 2.2.5).
La verificación en el software SIG está orientada a asegurar que el resultado

de las actividades de diseño y desarrollo cumplen con los requisitos del
sistema (sección 3.2.1). Dada la complejidad que demanda el software SIG,
se sugiere realizar la verificación con pares técnicos –de Ingeniería de
Software y de SIG–, y así tener certeza en decisiones sobre la resolución de
hallazgos.
3.3.6. Validación del diseño y desarrollo
La validación del diseño y desarrollo del software SIG también se realiza con
respecto a la planificación (sección 3.3.1), antes de ofrecer el producto de
software SIG para aceptación por parte del cliente. Con frecuencia la
validación se hace mediante diferentes tipos de pruebas:
 Pruebas unitarias.
 Pruebas de integración.
 Pruebas de calificación y de aceptación del software SIG completo.
La figura muestra el subsistema “diseño y desarrollo”. Hará parte del modelo

de aplicación de la NTC-ISO/IEC 90003 al desarrollo de software SIG.
67
Figura 15. Subsistema “diseño y desarrollo” con los aspectos a evaluar para su aplicación.
3.4. PRODUCCIÓN Y PRESTACIÓN DEL SERVICIO
La etapa final en el desarrollo de software SIG debería ser la implementación

del producto en un entorno de producción del cliente. Es en este escenario
dónde se debe plantear ordenadamente cuál va a ser el cronograma a
seguir, cuáles roles estarán involucrados, cómo se realizará la gestión de la
configuración y cuáles son los acuerdos de mantenimiento del software.
3.4.1. Control de la producción y prestación del servicio
Para llevar a cabo la implementación del software SIG, la organización debe

planificar la producción y prestación del servicio, teniendo en cuenta que los
requisitos y productos informativos han sido transformados en un producto
68
de software SIG (sección 3.3). Se debe asociar la producción y prestación

del servicio con las siguientes actividades en la implementación del software
SIG:
a. Compilación (build), liberación y reproducción.
Considerar la identificación de las correcciones necesarias y en qué

momento deben incorporarse al software SIG. Adicional a esto, el impacto de
la liberación en las operaciones del cliente.
Considerar la reproducción del software según las necesidades de cargas en

el ambiente de producción, o según las necesidades de replicación del SIG.
Junto a esto, estipular la documentación requerida para la reproducción
como licencias, manuales, guías, etc.
b. Puesta en producción, referente a la instalación.
La entrega y puesta en producción del software SIG se puede hacer a través

del desplazamiento del personal idóneo al ambiente de producción, o a
través de medios electrónicos con el uso de manuales y el acompañamiento
en el proceso por parte de la organización responsable del producto y los
servicios del software SIG desarrollado.
En este punto es importante una apropiada gestión de la configuración, que

permita suministrar una visión del estado del ambiente de producción
incluyendo las versiones apropiadas de los elementos de instalación el
69
software. En la Tabla 7 se muestra una lista de los aspectos a tener en

cuenta en este proceso.
Tabla 7. Aspectos importantes para el proceso de instalación del software SIG.

Aspectos organizacionales y de gestión
Requisitos de interacción interinstitucional, basados en estándares de información

geográfica.
Responsabilidades, funciones y obligaciones de los profesionales de software SIG:

cartógrafos, geógrafos, líder de desarrollo, analistas de base de datos espaciales,
desarrolladores de servicios Web geográficos.
Acuerdos de uso de datos para el software SIG
Acuerdos de acceso a las instalaciones del cliente y disponibilidad del personal
Revisión de aspectos legales y contractuales
Análisis de riesgos, especialmente en el levantamiento de datos espaciales y la

disponibilidad de servicios Web geográficos.
Aspectos de gestión de la configuración
Plan de instalación
Datos y requisitos de infraestructura del SIG en ambiente de producción
Requisitos de acceso a equipos (usuarios, contraseñas, red)
Revisión de seguridad
Integración el sistema (geoportales, visores geográficos, sistema de metadatos).
Migración de datos geográficos y alfanuméricos previos
Captura de datos geográficos y alfanuméricos, y población de la base de datos espacial
Copias de seguridad y su integridad
Guías o instructivos de instalación, teniendo en cuenta el almacenamiento de datos

espaciales y la conexión con servicios Web geográficos.
Entrenamiento relacionado con el uso el software SIG durante la instalación, dirigido a

profesionales SIG, analistas de información espacial y usuarios que no tienen experticia
en el manejo de SIG.
70
c. Actividades post producción, como mantenimiento, y soporte al cliente

durante la vida del software SIG.
Las actividades posteriores a la instalación del software SIG deben

planificarse estipulando el mantenimiento del producto en entorno de
producción, estableciendo un servicio de soporte técnico y las disposiciones
para garantizar el funcionamiento sistema. De esta forma el mantenimiento
debería incluir:
 Alcance del mantenimiento.

 Identificación del estado inicial del software SIG.
 Actividades de resolución de problemas, soporte de hardware y software.
 Modificaciones al sistema y adicionales en interfaces o componentes de
hardware (si aplican).
 Actualización de la gestión de configuración, pruebas y aseguramiento de
la calidad.
 Registros y reportes de mantenimiento.
3.4.2. Validación de los procesos de producción y de la prestación del

servicio
Para los procedimientos anteriormente descritos, la organización debe

validar los resultados para demostrar la calidad de la implementación y el
mantenimiento del software SIG, en la validación se incluye:
 Criterios de validación de la implementación.

 Aprobación de los equipos y el personal.
71
 Verificación de los requisitos y productos informativos en producción.

 Requisitos de documentación y registros.
 Revalidación del software SIG, según procedimientos de mantenimiento.
3.4.3. Seguimiento y medición
La organización generalmente mide varios aspectos de los procesos en el

ciclo de vida del software SIG, para hacer seguimiento y control de los
mismos. Es así como se definen los registros o documentos claves para la
calidad del proceso de desarrollo, junto con el costo y la duración real de una
actividad dentro del proceso de desarrollo.
Además de esto, ya que los esfuerzos del proceso de desarrollo se centran

en lograr un producto de software SIG de calidad, la organización debería
hacer seguimiento y medir la conformidad del software por medio de la
revisión, verificación y validación; dicho seguimiento debe estar ligado a las
características de calidad mencionadas en la sección 3.2, y referenciadas de
ISO 2501027 (ver Tabla 8).
Tabla 8. Características de calidad del producto de software basadas en ISO 25010.
Adecuación funcional
Completitud funcional Ofrece todas las funcionalidades plasmadas en la descripción

de los productos informativos del SIG.
Corrección funcional En el software SIG es posible realizar ajustes sobre las

funcionalidades. Por ejemplo: ajustes de escala de los mapas,
27
ISO/IEC. Software engineering ─ Software product Quality Requirements and Evaluation
72
corrección de los datos geográficos o actualización de URL de

los servicios Web geográficos.
Pertinencia funcional Cumple los requisitos provenientes de los productos

informativos.
Eficiencia de desempeño
Comportamiento Despliegue rápido de mapas (capas) y de servicios Web

temporal geográficos, respuesta rápida de las funcionalidades de
análisis espacial, despliegue rápido de atributos de los datos
geográficos.
Utilización de recursos Eficiencia al ejecutar las funcionalidades alfanuméricas y

espaciales.
Capacidad Soporta la cantidad de datos alfanuméricos y geográficos

solicitada por el cliente.
Compatibilidad
Coexistencia No interfiere con recursos de red de otros sistemas y utiliza

adecuadamente los servicios Web geográficos.
Interoperabilidad Incluye estándares de información geográfica.
Usabilidad
Inteligibilidad: Las funcionalidades del software SIG obedecen a patrones de

uso con respecto a la visualización de información geográfica
y análisis espacial. Por ejemplo: paneo, zoom, búsquedas,
consultas de datos espaciales.
Aprendizaje El software SIG puede ser enseñado en capacitaciones

sencillas, o entendido fácilmente a través de manuales de uso.
Operabilidad Las funcionalidades de visualización de información geográfica

y alfanumérica y las funcionalidades de análisis espacial
pueden ser ejecutadas de forma efectiva.
Protección frente a Manejo de errores al ejecutar operaciones alfanuméricas y

errores de usuario geográficas. Por ejemplo: escala del mapa no disponible,
datos no encontrados en una consulta espacial, parámetros no
73
admitidos en de búsquedas.
Estética La visualización del SIG en entornos de escritorio o Web, es

agradable y sigue patrones de diseño gráfico: mapas limpios,
simbología clara, tablas de datos ordenadas.
Accesibilidad El SIG se puede visualizar en múltiples dispositivos y

entornos, orientado a diferentes tipos de usuarios teniendo en
cuenta limitaciones físicas o cognitivas.
Fiabilidad
Madurez: El software SIG tiene un ciclo de vida que permite la mejora

continua de sus capacidades. Por ejemplo: mayor capacidad
de análisis espacial.
Disponibilidad Se implementan técnicas de carga que permitan que el

software SIG siempre esté disponible.
Tolerancia a fallos El software SIG no deja de funcionar aun cuando no haya

disponibilidad de datos geográficos o servicios Web
geográficos.
Capacidad de El software SIG puede ser restablecido a un estado previo si

recuperación hay fallas eléctricas o de red, conservando los datos
alfanuméricos y geográficos asociados a los mapas y
funcionalidades.
Seguridad
Confidencialidad Los datos alfanuméricos y geográficos podrán tener

restricciones de manipulación a solicitud del cliente.
Integridad Los datos geográficos y los servicios Web geográficos no

tendrán modificaciones no autorizadas.
Autenticidad EL software SIG puede demostrar la identidad de los usuarios,

en el caso del uso de funcionalidades de análisis espacial y
consulta de datos geográficos que requieran autenticación.
Responsabilidad A petición del cliente y dados el registro de usuario y la

confidencialidad de los datos, el software SIG puede
demostrar las acciones realizadas con la información
74
geográfica.
Mantenibilidad
Modularidad Los componentes o funcionalidades (alfanuméricas o

geográficas) cambiadas en el SIG tienen impacto mínimo en
las demás funcionalidades.
Reusabilidad Los módulos pueden ser usados (en su lógica) para las
nuevas versiones del software SIG.
Analizabilidad Dentro de la mejora continua, se puede medir el impacto

causado por cambios realizados en el software SIG.
Capacidad de ser Sin degradar el desempeño en visualización y análisis, el

modificado software SIG podrá ser modificado (corrección o mejora).
Capacidad de ser Se pueden establecer criterios de prueba para el software SIG:

probado despliegue de mapas, consulta espacial exitosa, asociación
correcta de servicios Web geográficos, entre otros.
Portabilidad
Adaptabilidad El software SIG puede ser desplegado en ambientes que no

coinciden con el ambiente estipulado en desarrollo.
Facilidad de El software SIG y sus bases de datos espaciales se despliega

instalación fácilmente en entorno de producción.
Capacidad de ser Las plataformas de visualización y de análisis geográfico sobre

reemplazado las que se desarrolló el software SIG pueden ser actualizadas
a nuevas versiones.
Fuente: Adaptación de los autores. http://iso25000.com/index.php/normas-iso-25000/iso-
25010 [Consulta: 28 de abril de 2016].
3.4.4. Análisis de datos y mejora
Los datos recopilados con las herramientas de seguimiento y medición

estarán orientados a evaluar la idoneidad tanto del proceso de desarrollo
75
como del producto de software SIG, identificando los momentos del ciclo de
vida y los procesos del SGC en donde puede realizarse la mejora continua.
Este proceso de mejora continua incluye los siguientes procedimientos para

llegar a acciones correctivas cuyo objetivo es eliminar las causas de no
conformidades:
a. Revisar las no conformidades (incluyendo quejas de los clientes).

b. Determinar las causas de las no conformidades.
c. Evaluar la necesidad de adoptar acciones para asegurarse de que las no
conformidades no vuelvan a ocurrir (puede involucrar cambios en el ciclo
de vida del software SIG y sobre el mismo producto).
d. Determinar e implementar las acciones necesarias.
e. Registrar los resultados de las acciones tomadas.
f. Revisar las acciones correctivas tomadas.
De igual forma, para el proceso de mejora continua incluye los siguientes

procedimientos para eliminar las acusas de no conformidades potenciales
con acciones preventivas:
a. Determinar las no conformidades potenciales y sus causas.

b. Evaluar la necesidad de actuar para prevenir la ocurrencia de no
conformidades (cambios en procesos previos a la producción y
prestación el servicio o software SIG).
c. Determinar e implementar las acciones necesarias.
d. Registrar los resultados de las acciones tomadas.
e. Revisar las acciones preventivas adoptadas.
76
La valoración mostrada en la sección 3.4.3 con respecto al modelo de

calidad, puede ser útil para pronosticar los problemas de conformidad.
La Figura 16 muestra el subsistema “producción y presentación del servicio”,

parte del modelo de aplicación de la NTC-ISO/IEC 90003 al desarrollo de
software SIG.
Figura 16. Subsistema “producción y prestación del servicio” con los aspectos a evaluar.
77
4. APLICACIÓN DEL MODELO
Se debe comprender que al escudriñar dentro de una organización acerca de

sus procesos naturales, sus políticas y planes estratégicos puede
encontrarse ante cierta resistencia de parte de los involucrados que posibilita
truncar la información obtenida o entorpecer la ejecución del plan de
aplicación de la norma, por lo cual es crítico e imperativo tener completa
autorización de la alta gerencia para efectuar el levantamiento de la
información que se requiere y que dicha autorización sea debidamente
comunicada a toda la organización. En el Anexo C, se incluye un modelo de
carta de autorización para el equipo de evaluación en donde se deja
constancia del poder que se le otorga al mismo por parte de la dirección y las
responsabilidades que deberían asumir al recibir dicho poder. Si la
organización tiene su propio formato de comunicado para este caso, se
recomienda darle prelación al mismo.
Una vez comunicado y oficializado el proceso de aplicación de la NTC-

ISO/IEC 90003 al desarrollo de software de SIG al interior de la organización,
se debe tener en cuenta que para iniciar con el levantamiento de información
básica, es importante recopilar aquellos datos que van a permitir identificar
aspectos relevantes como usuarios clave, flujos de autoridad y desde ya
aspectos específicos como la adopción de metodologías de desarrollo y/o la
aplicación de estándares relacionados.
Lo anterior permitirá identificar a los Stakeholders de proceso con los que se

debe contar en el desarrollo de la evaluación como proveedores de datos y
78
como “aprobadores” para acceder a información crítica. Mediante el “Formato

Inicial” (Tabla 9) se obtendrá el insumo para lo anteriormente descrito.
Tabla 9. Formato inicial.

MODELO DE APLICACIÓN NTC-ISO/IEC 90003 PARA SOFTWARE SIG
A. FORMATO INICIAL
1. DATOS BÁSICOS DE LA ORGANIZACIÓN
1.1 EMPRESA: 1.2 SECTOR:
1.3 NOMBRE PROYECTO/SIG:
1.4 FECHA DE ELABORACIÓN: DD-MM-AAAA 1.5 LÍDER:
1.6 ENTREVISTADO: 1.7 CARGO:
1.8 MISIÓN DE LA
ORGANIZACIÓN:
1.9 VISIÓN DE LA
ORGANIZACIÓN:
*Anexe el organigrama de la compañía, identificando

1.10 ORGANIGRAMA. la ubicación exacta del (las) área(s) responsable(s)
del desarrollo.
1.11 DESCRIPCIÓN GENERAL DEL EQUIPO DE DESARROLLO SIG
Liste los integrantes del equipo, señalando cada uno de los roles existentes.
1.12 DESCRIPCIÓN GENERAL DE PROCESOS ASOCIADOS AL DESARROLLO SIG

Realice una descripción general de los procesos asociados al desarrollo: Recepción de
79
requerimientos, gestión del cambio, documentación, autoridades, responsabilidades, tipos

de pruebas, metodología, etc.
ELABORÓ: REVISÓ:
4.1. PLANIFICACIÓN Y PREPARACIÓN DE LA EVALUACIÓN
Una vez diligenciado el formato inicial, se tendrán los datos básicos

necesarios para diseñar un plan concreto de evaluación: Qué proyecto será
evaluado, en qué fase se aplicará la evaluación, qué personas se deberán
entrevistar, los permisos que se deberán adquirir y qué disponibilidad de
horarios y espacios se tiene para desarrollar estas actividades, en qué
tiempo se hará todo lo anterior. Muy importante también, es identificar los
lugares y sus horarios en donde desarrollará la evaluación, por ejemplo para
proyectos que sean desarrollados en conjunto por parte de diferentes
organizaciones, se debe tener en cuenta el contacto con el que se coordinará
el ingreso y la autorización respectiva en caso de necesitarse.
El formato de planificación y preparación (Tabla 10), le permitirá recopilar los

anteriores aspectos, para marcar claramente el camino que se deberá
80
recorrer para una correcta evaluación del proceso de desarrollo de SIG

acorde a la NTC-ISO/IEC 90003.
Tabla 10. Formato de planificación y preparación.

B. FORMATO DE PLANIFICACIÓN Y PREPARACIÓN
1. PROYECTO A EVALUAR
FASE
PROYECTO:
ACTUAL:
FECHA DE DD-MM- LIDER:
ELABORACIÓN: AAAA
2. LISTADO DE PERSONAL CLAVE
JEFE O JEFE O
NOMBRE CARGO ÁREA HORARIO
SUPERIOR SUPERIOR
3. DIRECTORIO DE SITIOS CLAVE

DESCRIPCIÓN DIRECCIÓN TELÉFONO HORARIO CONTACTO
81
4. CRONOGRAMA BASE
FASE EVALUACIÓN FECHA INICIAL FECHA FINAL
(Fecha inicial
PREPARACIÓN estipulada en la carta
de autorización)
SGC
(Fecha final estipulada en la carta

DESARROLLO
de autorización)
ELABORÓ: REVISÓ:
4.1.1. Análisis de requerimientos
Principalmente la aplicación de una norma de calidad como la NTC-ISO

90003 al desarrollo de SIG, busca incrementar la satisfacción del cliente a
través del aseguramiento de los procesos que se encuentran inmersos en el
ciclo de vida del SIG. Las conexiones naturales entre personas, técnicas,
metodologías, recursos y líneas de responsabilidad se fortalecen de forma
sistémica al abordar en forma cíclica todos sus aspectos: Planificación,
Ejecución, Verificación y Actuación28.
28
Ciclo PHVA de mejora continua, definición y análisis.
https://www.isotools.org/2015/02/20/en-que-consiste-el-ciclo-phva-de-mejora-continua
[Consulta: 20 de abril de 2016].
82
En la actualidad, las organizaciones productoras y consumidoras de SIG

tienen que enfrentarse a un nivel tan alto de competencia que para poder
crecer y desarrollarse, y a veces incluso para lograr su propia supervivencia,
han de mejorar continuamente, evolucionar y renovarse de forma fluida y
constante. El ciclo PHVA de mejora continua es una herramienta de gestión
presentada en los años 50 por el estadístico estadounidense Edward
Deming. Tras varias décadas de uso, este sistema o método de gestión de
calidad se encuentra plenamente vigente (ha sido adoptado recientemente
por la familia de normas ISO) por su comprobada eficacia para: reducir
costos, optimizar la productividad, ganar cuota de mercado e incrementar la
rentabilidad de las organizaciones. Logrando, además, el mantenimiento de
todos estos beneficios de una manera continua, progresiva y constante.
Aquellos requerimientos puntuales, expresamente declarados por la empresa

obedecen al resultado del auto diagnóstico según la madurez y enfoque a la
mejora continua propia de cada organización; los requerimientos a ser
evaluados que plantea la norma por sí misma, son aquellos que guardan
clara correspondencia con su alcance: SGC, gestión de los recursos,
realización del producto, y la medición, análisis y mejora.
En la Tabla 11, se encuentra el formato que permitirá identificar claramente

los requerimientos o criterios de evaluación; aquellos puntos en donde se
deberá enfatizar y posiblemente generar una recomendación de aplicar la
norma de la manera más fiel posible a uno o más procesos específicos.
83
Tabla 11. Formato de identificación y priorización de requerimientos.

C. IDENTIFICACIÓN Y PRIORIZACIÓN DE REQUERIMIENTOS
FECHA DE ELABORACIÓN: DD-MM-AAAA LIDER:
1. REQUERIMIENTOS PROPIOS DE EVALUACIÓN
1.1 REQUERIMIENTO DE EVALUACIÓN 1:
2. REQUERIMIENTOS PROPIOS DE LA NORMA

1.1 REQUERIMIENTO DE NORMA 1:
3. OTROS REQUERIMIENTOS
ELABORÓ: REVISÓ:
84
El anterior formato cumplirá función de lista de verificación durante la

ejecución de la evaluación. Los requerimientos de evaluación autoimpuestos
por la organización son opcionales, caso contrario a los requerimientos de
norma que son la columna vertebral del modelo sobre los que se generará un
dictamen o informe final.
El apartado para “Otros requerimientos” está reservado para aquellos

interrogantes acerca de los resultados o la ejecución por parte de la
empresa, que estén asociados de alguna forma con el desarrollo de SIG y
que puedan impactar al cliente, por ejemplo un mapa con una capa
defectuosa que impide el correcto uso de una herramienta adquirida por una
entidad pública.
Estos requerimientos son opcionales, pero no menos importantes ya que se

pueden alinear las directrices pensadas desde lo funcional con estrategias de
mejoramiento de tipo técnico.
4.1.2. Desarrollo del plan de evaluación
Una vez identificada la fase en la cual se encuentra el proyecto SIG a evaluar

(Anexo D: Formato inicial y Formato de planificación y preparación), se
deben definir desde la perspectiva de la Norma NTC-ISO 90003 los pilares
conceptuales aplicables a dicha fase. En la Figura 18, se tiene un marco de
referencia para seleccionar adecuadamente los criterios según la fase.
85
Figura 17. Énfasis de los pilares conceptuales de la NTC-ISO 90003 en cada fase de
desarrollo de SIG.
Análisis de SGC y
Requerimientos Gestión de
recursos
Evaluación del
Diseño Evaluación de los software y del
Conceptual datos disponibles hardware
Planificación y diseño de la
BD
Gestión de Realización
recursos del producto
Construcción de la BD
Integración del SIG
Medición, Desarrollo de aplicaciones

análisis y
mejora
Uso y mantenimiento del
SIG
Fuente: Adaptación de los autores de imagen tomada de

http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/206
Es importante resaltar que aunque cada pilar conceptual de la norma se

representa con más énfasis en alguna fase o grupo de fases del desarrollo
de SIG, no significa que estos sean exclusivos; esto es clave para la
planificación de la evaluación porque claramente se debe cumplir con un
ciclo PHVA en toda la ejecución, a través de la selección de los formatos
guía apropiados.
86
4.1.3. Selección y preparación del equipo
En este punto se debe definir del grupo de evaluadores quien asumirá el rol
de liderazgo dentro del equipo y quienes harán parte del equipo de ejecución
de las evaluaciones específicas. El evaluador líder será quien tenga la
responsabilidad de revisar el correcto diligenciamiento de los formatos
aplicados, será el interlocutor con los representantes de la empresa y deberá
participar activamente en la resolución de conflictos y superar cualquier
inconveniente que pueda comprometer la eficacia de la evaluación. Además
será el encargado de dirigir el trabajo del equipo de evaluación y entregar el
dictamen final.
Con respecto al equipo de evaluación, ejecutarán el levantamiento de

información a través de los formatos seleccionados y apoyarán al líder en la
recopilación y análisis de las evidencias y en la revisión de los formatos que
el líder elabore.
En cuanto a los roles desempeñados por parte del personal de la

organización, es clave la representación por parte de la dirección que tenga
la suficiente autoridad y comunicación para garantizar que la evaluación se
adelante sin contratiempos y bajo los lineamientos del equipo evaluador.
Este representante será el interlocutor directo con el evaluador líder. Otro rol
compartido es el de los colaboradores, personas dueños de procesos claves
dentro de la organización o que pueden ser poseedores de evidencias que
deben ser recolectadas.
87
En la Tabla 12 se recopilan las responsabilidades básicas de los

involucrados.
Tabla 12. Responsabilidades básicas de los involucrados.

ROL RESPONSABILIDADES
Elaboración Formato inicial
Asignación de responsabilidades a los evaluadores de apoyo
Revisión de formatos diligenciados por los evaluadores de
apoyo
EVALUADOR LIDER Interlocución directa con el representante de la dirección

Diligenciamiento de formatos en caso de contingencia
Elaboración dictamen final
Entrega de resultados/recomendaciones a la organización
Orientar al grupo de evaluadores de apoyo en la ejecución
Solicitar los espacios y recursos al representante de la
dirección
Orientar a los participantes de la organización en la ejecución
Diligenciamiento de formatos asignados por el líder
Asumir responsabilidades del líder en caso de contingencia
Revisión de formatos diligenciados por el evaluador líder
Comunicar cualquier irregularidad detectada en el proceso al
EVALUADOR DE
líder
APOYO
Recopilar y analizar las evidencias asignadas por el líder
Interactuar con los colaboradores para la recolección de
evidencias
Documentar los análisis realizados
Interlocución directa con el evaluador líder
Gestionar los espacios y recursos necesarios al interior de la
organización
REPRESENTANTE DE
Dar acceso a las evidencias solicitadas por los evaluadores
LA DIRECCIÓN
Brindar la información pertinente a los evaluadores
Recibir el dictamen final y ponerlo en conocimiento de la
dirección
88
Ejecutar las recomendaciones producto de la evaluación que

estén a su alcance
Dar acceso a las evidencias de su proceso solicitadas por los
evaluadores
COLABORADOR Brindar la información pertinente a los evaluadores
Ejecutar las recomendaciones producto de la evaluación que
estén a su alcance
El formato de la Tabla 13, permitirá establecer cómo se asignarán los roles

necesarios entre los participantes de la evaluación.
Tabla 13. Formato de selección del equipo.

D. SELECCIÓN DEL EQUIPO
FECHA DE DD-MM-AAAA LIDER:
ELABORACIÓN:
1. EQUIPO DE EVALUADORES
1.1 EVALUADOR LÍDER
1.2 EVALUADOR DE
APOYO
1.3 EVALUADOR DE
APOYO
1.4 EVALUADOR DE
APOYO
1.5 EVALUADOR DE
APOYO
1. EQUIPO DE COLABORADORES
2.1 REPRESENTANTE DE
LA DIRECCIÓN
2.2 COLABORADOR
89
2.3 COLABORADOR
2.4 COLABORADOR
2.5 COLABORADOR
ELABORÓ: REVISÓ:
Es necesario precisar que el equipo de evaluadores puede ser conformado

por una pareja, con lo cual se obtendría un par de evaluadores en el que uno
cumplirá con la labor de líder y el otro de apoyo y deberán alternarse la
elaboración y revisión de los formatos. Para el equipo de colaboradores,
también puede conformarse una pareja en la que el representante de la
dirección puede tomar roles de colaborador y puede tener injerencia en uno o
más procesos clave de acuerdo a sus responsabilidades dentro de la
organización.
Tanto para el equipo de evaluadores como para el de colaboradores no es

recomendable que la evaluación se asuma por una sola persona, al tener
mínimo dos personas por equipo se busca la mayor objetividad posible y
ante todo habilitar un enfoque holístico como lo promueve uno de los
principios de Cobit 529.
29
Presentación COBIT5-Introduction, tomada de www.isaca.org en consulta realizada en
[Consulta: 20 de febrero de 2016].
90
4.1.4. Obtención y análisis de evidencia objetiva inicial
A partir de un panorama general se podrá determinar qué formatos serán

aplicables a lo largo de la evaluación. Este panorama se obtiene a través del
formato de entrevista inicial en el que se abarcan los cuatro pilares
conceptuales de la NTC-ISO/IEC 90003.
Tabla 14. Formato de entrevista inicial.

E. ENTREVISTA INICIAL
1. GENERALES
1.1 FECHA DE 1.2 LUGAR DE

ELABORACIÓN DD-MM-AAAA ELABORACIÓN
1.3 NOMBRE
ENTREVISTADO
1.4 CARGO ENTREVISTADO
1.5 NOMBRE
ENTREVISTADOR
1.6 CARGO
ENTREVISTADOR
2. SGC
2.1 ¿QUÉ ASPECTOS

CONSIDERAN EN LA
PLANIFICACIÓN DE LA CALIDAD
DEL DESARROLLO DE SIG?
2.2 ¿QUE DOCUMENTACIÓN

COMPRENDE EL SGC DE LA
ORGANIZACIÓN?
2.3 ¿CÓMO MIDEN LA

COMPLEJIDAD DE LOS
PROCESOS?
91
2.4 ¿CÓMO DETERMINAN LAS

INTERACCIONES ENTRE LOS
PROCESOS?
2.5 ¿CÓMO SE DETERMINA LA
COMPETENCIA DEL PERSONAL
QUE PARTICIPA EN EL
DESARROLLO DEL SIG?
2.6 ¿DE QUE FORMA GESTIONAN

LA DOCUMENTACIÓN ASOCIADA
AL DESARROLLO DE SIG?
2.7 ¿EN QUE ASPECTOS DEL

DESARROLLO DE SIG PARTICIPA
LA DIRECCIÓN?

2.1 ¿CÓMO SE REALIZA LA
ASIGNACIÓN DE LOS
RECURSOS?
2.2 ¿CÓMO SE DETERMINA LA
CORRECTA ASIGNACIÓN DE
RECURSOS?
2.3 ¿CÓMO SE MIDE LA
EFECTIVIDAD DE LA
ASIGNACIÓN DE RECURSOS?
3.1 ¿QUÉ ASPECTOS SON

INCLUIDOS EN LA
PLANIFICACIÓN DE LA
REALIZACIÓN DEL SIG?
3.2 ¿CÓMO SE SELECCIONAN

LOS ASPECTOS
METODOLÓGICOS CON LOS QUE
SE DESARROLLA EL SIG?
3.3 ¿CÓMO SE REALIZA EL

SEGUIMIENTO A LAS ACCIONES
QUE REALIZAN LOS QUE
INTERVIENEN EN EL
DESARROLLO DEL SIG?
92
3.4 ¿CÓMO SE REGISTRAN LOS

CAMBIOS EFECTUADOS AL SIG
DURANTE SUS FASES?

SATISFACCIÓN DEL CLIENTE
CON EL SIG UNA VEZ
DESPLEGADO?
4.2 ¿QUÉ MECANISMOS DE

COMUNICACIÓN EXISTEN CON
EL CLIENTE LUEGO DE LA
IMPLEMENTACIÓN DEL SIG?
4.3 ¿QUÉ CRITERIOS PERMITEN

LA PRORIZACIÓN DE MEJORAS
SOBRE EL SIG?
4.4 ¿CÓMO SE ASIGNAN LAS

RESPONSABILIDADES
DE EJECUCIÓN SOBRE LAS
MEJORAS PARA EL SIG?
ELABORÓ: REVISÓ:
Es clave que el entrevistado tenga una panorámica completa de la

organización para poder contestar acertadamente la entrevista inicial,
aunque no debe ser el representante de la dirección el que encabece el
equipo de colaboradores si debe cumplir con dicho requisito.
93
4.1.5. Preparación de la recolección de pruebas objetivas
Gracias al formato de entrevista inicial, se podrá tener un panorama previo a

la aplicación de los formatos; para esto en la Tabla 15 se representa la forma
de establecer los patrones que se podrán aplicar.
Tabla 15. Formato de recolección de pruebas objetivas.

FORMATO DE RECOLECCION DE PRUEBAS OBJETIVAS
FECHA DE DD-MM-AAAA LÍDER:
ELABORACIÓN:
1.FORMATOS CT
2. SGC
Transcriba notas de la evaluación + Revisión del
2.1 ¿QUÉ ASPECTOS
numeral 3.1 de la metodología
CONSIDERAN EN LA
PLANIFICACIÓN DE LA CALIDAD
DEL DESARROLLO DE SIG?

2.2 ¿QUE DOCUMENTACIÓN
COMPRENDE EL SGC DE LA
ORGANIZACIÓN?

2.3 ¿CÓMO MIDEN LA
COMPLEJIDAD DE LOS
PROCESOS?
2.4 ¿CÓMO DETERMINAN LAS Transcriba notas de la evaluación + Revisión del

INTERACCIONES ENTRE LOS numeral 2.1 de la metodología
PROCESOS?
94
2.5 ¿CÓMO SE DETERMINA LA Transcriba notas de la evaluación + Revisión del

COMPETENCIA DEL PERSONAL numeral 2.4 de la metodología
QUE PARTICIPA EN EL
DESARROLLO DEL SIG?
2.6 ¿DE QUE FORMA GESTIONAN Transcriba notas de la evaluación + Revisión del
LA DOCUMENTACIÓN ASOCIADA numeral 2.2 de la metodología
AL DESARROLLO DE SIG?
2.7 ¿EN QUE ASPECTOS DEL Transcriba notas de la evaluación + Revisión del
DESARROLLO DE SIG PARTICIPA numeral 2.3 de la metodología
LA DIRECCIÓN?
Transcriba notas de la evaluación+ Revisión del
3.1 ¿CÓMO SE REALIZA LA
ASIGNACIÓN DE LOS RECURSOS?
3.2 ¿CÓMO SE DETERMINA LA Transcriba notas de la evaluación+ Revisión del
CORRECTA ASIGNACIÓN DE numeral 2.4 de la metodología
RECURSOS?

EFECTIVIDAD DE LA ASIGNACIÓN
DE RECURSOS?

4.1 ¿QUÉ ASPECTOS SON
INCLUIDOS EN LA PLANIFICACIÓN
DE LA REALIZACIÓN DEL SIG?
4.2 ¿CÓMO SE SELECCIONAN LOS Transcriba notas de la evaluación+ Revisión del
ASPECTOS METODOLÓGICOS numeral 3.1 de la metodología
CON LOS QUE SE DESARROLLA

EL SIG?
95

4.3 ¿CÓMO SE DERTERMINAN LOS
REQUISITOS DEL CLIENTE?

numeral 3.2.2 de la metodología
REQUISITOS DEL PRODUCTO?
4.5 ¿CÓMO SE REALIZA EL Transcriba notas de la evaluación+ Revisión del
SEGUIMIENTO A LAS ACCIONES numeral 3.3 de la metodología
QUE REALIZAN LOS QUE

INTERVIENEN EN EL
DESARROLLO DEL SIG?
4.6 ¿CÓMO SE REGISTRAN LOS Transcriba notas de la evaluación+ Revisión del

CAMBIOS EFECTUADOS AL SIG numeral 3.4.3 de la metodología
DURANTE SUS FASES?
5.1 ¿CÓMO SE MIDE LA Transcriba notas de la evaluación+ Revisión del

SATISFACCIÓN DEL CLIENTE CON numeral 3.4 de la metodología
EL SIG UNA VEZ DESPLEGADO?
5.2 ¿QUÉ MECANISMOS DE Transcriba notas de la evaluación+ Revisión del
COMUNICACIÓN EXISTEN CON EL numeral 3.4.1 de la metodología
CLIENTE LUEGO DE LA
5.3 ¿QUÉ CRITERIOS PERMITEN Transcriba notas de la evaluación+ Revisión del

LA PRORIZACIÓN DE MEJORAS numeral 3.4.3 de la metodología
SOBRE EL SIG?
5.4 ¿CÓMO SE ASIGNAN LAS Transcriba notas de la evaluación+ Revisión del
RESPONSABILIDADES DE numeral 3.4.4 de la metodología
EJECUCIÓN SOBRE LAS

MEJORAS PARA EL SIG?
96
Tabla 16. Niveles de resultado posible para cada registro de la entrevista inicial.
NIVEL NIVEL
PRE-NIVEL NIVEL BÁSICO NIVEL MEDIO
ACEPTABLE SATISFACTORIO
(1) (2) (3)
(4) (5)
En la Tabla 16, se representan en escala de colores (tipo semáforo), los

posibles niveles obtenidos en cada aspecto tras la evaluación. Cada uno es
explicado a continuación:
Pre-nivel: Se entiende que la organización no tiene implementado el aspecto

correspondiente, por lo cual deben consultar el parágrafo asociado en la
norma y crear un plan de implementación del mismo.
Nivel básico: Aunque la organización tiene nociones en el aspecto

correspondiente, no es lo suficientemente clara su implementación por lo
cual deben adelantarse pruebas específicas del aspecto para constatar que
no son inconformidades sino una aplicación sin rigor.
Nivel medio: Se tienen pocos indicios de que el aspecto es correctamente

aplicado, aunque se valida que la organización tiene clara consciencia del
mismo. Se deben adelantar pruebas específicas del aspecto para determinar
que otros formatos serán aplicables.
97
Nivel aceptable: Se encuentran indicios claros de la aplicación del aspecto,

sin embargo existen características del aspecto que pueden ser objeto de
mejora. La estrategia debería ser la creación de una lista de chequeo que
permita realizar la identificación, priorización y revisión de aquellas
características no satisfactorias.
Nivel satisfactorio: La organización aplica conforme a la norma el aspecto

analizado; en este punto se debe pensar en mecanismos de revisión en
tiempos adecuados y sobre todo enfocados a detectar características
objetivo de mejora continua.
Para todos aquellos aspectos que caigan en la “zona roja” de la tabla,

implican recomendaciones desde lo básico, enfocadas hacia planificar su
implementación de forma independiente pero bajo los principios de la NTC-
ISO/IEC 90003.
A los aspectos que caigan en la “zona amarilla”, se les debe identificar los
posibles puntos de mejora, para preparar su respectiva planificación. Esto se
debe constatar con el diligenciamiento de los formatos respectivos. Cuando
se obtiene un nivel medio, lo recomendable es fortalecer los aspectos
positivos y asegurarlos, las falencias se deben abordar una vez se tengan
cimientos sólidos en los aspectos previamente asegurados a la vez que esto
debería aumentar la conciencia y la comunicación del colectivo de
involucrados.
98
Finalmente para los aspectos que caigan en la “zona verde”, deben ser
reseñados e identificar si se correlacionan directamente con otros que sean
insatisfactorios para canalizarlos como insumo de mejora y nivelar su estado.
4.2. EVALUACIÓN DE CONDUCTA
Teniendo el plan completo de los formatos que se van a diligenciar, es

importante determinar cuáles de ellos requieren ser sustentados con la
recolección de evidencia ya sea de forma directa, a través de registros
escritos o por verificación documental. La evaluación se debe desarrollar de
forma dinámica (no se reduce solo a diligenciar los formatos), ágil (sin tomar
más tiempo de lo planeado y sin interrumpir las labores normales de la
organización) y objetiva (contando con el acompañamiento y
retroalimentación de los participantes líderes).
4.2.1. Realización de pruebas objetivas
El hilo conductor de la metodología de aplicación de la NTC-ISO/IEC 90003

al desarrollo de SIG se compone de los documentos de apoyo y los formatos
de evaluación y un orden lógico en el que se deben diligenciar.
Los formatos se dividen en tres dimensiones: 1) de caracterización, 2) de

“seguimiento y medición de los requisitos para la aplicación de la NTC-
ISO/IEC 90003” y 3) de “seguimiento y medición para el enfoque de la NTC-
ISO/IEC 90003”. A su vez se encuentran dos tipos de formatos, de validación
y de dictamen. Los formatos de validación contienen información de
99
contexto, es decir en qué organización se enmarca la evaluación, en que

proyecto, en qué fase de ese proyecto, quienes participan y qué objetivos se
buscan lograr; estos formatos son registros documentados de la ejecución
sistemática de la evaluación y en momentos específicos, eslabones
necesarios para cohesionar otros formatos.
Los formatos de dictamen generan recomendaciones específicas sobre el

proceso al que son aplicables, son los que tienen tablas de calificación
asociadas de acuerdo a los hallazgos realizados y conforman el dictamen
final. Los documentos de apoyo permiten documentar el proceso bajo un
proceso formal y riguroso, en el que se involucran las partes de manera
sinérgica. La anterior taxonomía es representada en la Figura 18.
Figura 18. Taxonomía de documentos de la metodología.
Documentación de la Metodología
Formatos CT (de Formatos RQ (de Formatos EF (de

caracterización) seguimiento y medición seguimiento y medición
de los requisitos para la para el enfoque de la
aplicación de la NTC- NTC-ISO/IEC 90003)
ISO/IEC 90003)
Formatos A, B, C y D Formatos F, G, H, I y J Formatos K, L, M, N, O,

(Validación) (Dictamen) P y Q (Dictamen)
Formato E
(Dictamen)
Documentos de Apoyo
Fuente: Los autores. Carta de autorización

Carta de cierre
Otros
100
En los formatos la parte oscura corresponde a las etiquetas de campo (ver

Tabla 17) que indican qué dato debe diligenciarse en su correspondiente
casilla (zonas blancas). Las regiones grises no deben diligenciarse, solo las
regiones en blanco que tengan su correspondiente etiqueta. Los formatos de
dictamen son los únicos que poseen una guía de calificación por ítem y de
acuerdo a la calificación obtenida la respectiva recomendación a generar.
Estas guías se presentan como copias de los formatos originales en donde

se reseña campo a campo las posibilidades de calificación y la respectiva
recomendación a generar. Existen campos o respuestas opcionales y
algunos datos que requieren un contexto, estas aclaraciones se encontrarán
en letra cursiva.
Cuando se espera un formato de dato en especial (por ejemplo: una fecha),

se señalará en negrilla con color gris claro. Los tipos de campo se listan en la
Tabla 17.
Tabla 17. Tipos de campo en los formatos.
TIPO DE CAMPO DESCRIPCIÓN
Texto Sugerencia o explicación para diligenciar. Se debe borrar

para establecer el dato solicitado.
TEXTO Formato en el que se debe establecer el dato.
Campo para diligenciar en impresión física o versión digital

del formato.
TEXTO Etiqueta de campo, no debe cambiarse el valor por defecto.
101
4.2.2. Verificación y validación de pruebas objetivas
Cada formato sin importar su dimensión o su tipo, poseen un campo

“REVISÓ” acompañando siempre al campo de “ELABORÓ”; significa que
todo formato diligenciado debe pasar por la revisión de otro integrante del
equipo de evaluadores diferente al que lo realizó; esto se realiza como
refuerzo a la objetividad de la evaluación. Sin la firma o visto bueno del
revisor en cada formato, se considera inválido para ser tenido en cuenta en
el dictamen final.
Los formatos CT (de Caracterización) tienen un orden estricto así como los
de seguimiento y medición de los requisitos. Por su parte los de seguimiento
y medición para el enfoque requieren la programación previa según el plan
de evaluación, para ser ejecutados en cierto orden.
Los formatos tanto de validación como de dictamen no tienen campos

opcionales; los campos que no debe diligenciarse son aquellos que por las
características propias de la organización o proyecto no apliquen como es el
caso de los integrantes de un equipo que no alcancen a ser más de dos (los
formatos traen espacios hasta para 5 integrantes).
4.2.3. Documento de pruebas objetivas
Una vez diligenciados todos los formatos aplicables; se procede a consolidar

el paquete generado para ser revisado y comenzar con la asignación de
recomendaciones por cada evidencia encontrada.
102
4.2.4. Resultados de la evaluación
Los resultados de la evaluación se presentan mediante el dictamen final. El

dictamen final es un informe, que debe tener la siguiente estructura:
Encabezado: Presentación del equipo evaluador, Ciudad, Fecha, Nombre de

la Organización, reseña del equipo de colaboradores, proyecto evaluado y
fase del mismo.
Resumen: Objetivos de realizar la evaluación, marco normativo utilizado y

metodología implementada. Tiempo de ejecución, lugares en los que se llevó
a cabo.
Cuerpo: Basado en las anotaciones y resultados de la entrevista inicial se

puede brindar un contexto de lo encontrado y en qué aspectos se centraron
las dificultades y fortalezas.
Recomendaciones: De acuerdo a lo arrojado por cada formato, se deben

listar cada una de las recomendaciones generadas citando el numeral de la
NTC-ISO/IEC 90003 que está relacionado o si lo prefiere con el numeral de
la presente metodología.
Notas finales: Este espacio está reservado para que el equipo evaluador
exprese temas que le llamó la atención, como las dificultades presentadas y
el camino tomado para solucionarlas. También es muy importante reseñar las
fortalezas detectadas para balancear el dictamen entregado.
103
4.3. INFORME DE RESULTADOS DE EVALUACIÓN
Para el cierre de toda la evaluación, junto con el dictamen final se hace

entrega de una carta de cierre, en donde se manifiesta oficialmente la
culminación y se da fe que se entrega toda la documentación de soporte,
pero más importante aún aquella que le permitirá a la organización organizar
los planes de acción ante cada recomendación brindada por el equipo
evaluador. En el anexo G, se dispone de una plantilla modelo para este
documento.
Sería ideal que posterior a la entrega de los resultados, se pudiera asesorar

a la dirección en cuanto a la priorización de acciones a ejecutar, teniendo en
cuenta por supuesto lo establecido a lo largo de esta metodología.
104
CONCLUSIONES
1. Durante la realización del proyecto fue posible recopilar y analizar

múltiples características que deben involucrar la calidad en el proceso de
desarrollo de software SIG, de esta forma se logró enfocar la norma
NTC-ISO/IEC 90003 como modelo y punto de referencia para evaluar la
gestión de calidad del SIG en un entorno real.
2. Al adoptar el modelo de calidad de la ISO 25010 en los procesos de

desarrollo de software SIG, se pueden establecer de forma práctica los
requisitos de calidad para el producto que ofrece la organización.
3. La categorización de requisitos ofrecidos por la ISO 25030 permite

determinar los ámbitos del ciclo de vida del software SIG en donde deben
estar involucrados los requisitos de calidad.
4. Sin los requisitos de calidad (SGC, recursos, documentación,

compromiso de la dirección), se obtiene un enfoque incompatible hacia la
satisfacción del cliente; el encadenamiento de estos aspectos es muy
fuerte tanto o más como el que existe entre la calidad del proceso y su
impacto en la calidad del producto.
5. Los subsistemas que hacen parte del modelo de aplicación la norma

NTC-ISO/IEC 90003 se diseñaron involucrando las principales
actividades y elementos del ciclo de vida el software SIG; esto ofrece una
perspectiva de planificación de calidad que puede adoptar una
organización antes de crear un SIG.
105
6. El Ciclo PHVA es un mecanismo eficaz para hablar de procesos y

productos software de calidad; sigue vigente en nuestros días y es un
marco implícito no sólo para las normas ISO sino también para marcos
de Gobierno IT como Cobit 5.
7. Adoptando SCAMPI C como método base para la aplicación del modelo

en un entorno real, se asegura el uso de una herramienta ordenada en
los procesos de medición y evaluación de calidad del software SIG.
8. Los procesos de seguimiento y medición de este proyecto están

enfocados a recolectar, analizar y reportar los datos relacionados con el
producto de software SIG desarrollado, junto con los procesos que están
detrás de dicho desarrollo; esto permitirá demostrar objetivamente la
calidad del producto.
9. Este trabajo puede ofrecer un enfoque práctico para aplicar aspectos de

calidad al desarrollo de software SIG, una iniciativa que no es
suficientemente conocida en el contexto nacional; por tanto tiene un
amplio campo de aplicación entre las organizaciones que desarrollan
Sistemas de Información Geográfica.
10. Este trabajo nos permitió conocer los procesos involucrados en el

desarrollo de software SIG. De esta forma, podremos realizar aportes
importantes a la calidad de estos productos desde una perspectiva
empresarial y profesional.
106
BIBLIOGRAFÍA
BELLO MÉNDEZ Y. Detrás de la Máscara (1ª parte): Evaluación y

Diagnósticos usando SCAMPI Appraisals con People CMM; 2014.
Calidad de Sistemas de Información –Calidad de producto [diapositiva].

Universidad de Castilla-La Mancha; 2008-2009. [28 diapositivas del curso
cuyos profesores son Mario Piattini Velthuis e Ignacio García Rodríguez].
CASSETIARI E. SIG y Medio Ambiente: principios básicos. Universidad de

Cádiz.; 1993.
DEPARTAMENTO NACIONAL DE PLANEACIÓN, Consejo Nacional de

Política Económica y Social. Documento Conpes 3585. En: Análisis
Geográficos 2009; (41): 13-43.
Colombia. DEPARTAMENTO NACIONAL DE PLANEACIÓN, Consejo

Nacional de Política Económica y Social. Documento Conpes 3585,
Consolidación de la Política Nacional de Información Geográfica y la
Infraestructura Colombiana de Datos Espaciales – ICDE. Bogotá: DNP; 2009
GARCÍA M., H. Implementación de Sistemas de Gestión de la Calidad en

Entidades Públicas Colombianas y su articulación con el Sistema de Control
Interno: Aspectos Conceptuales y el ejemplo del DANE. [Trabajo de grado].
Bogotá. Universidad de los Andes. Facultad de Administración; 2004.
107
HERNÁNDEZ C, Iliana, FUENTES V., MORENO M. Metodología para

Implementar la Gestión de la Calidad y la Reingeniería de procesos. En: XV
FORUM NACIONAL DE CIENCIA Y TÉCNICA; 2007. Holguín, Cuba.
ICDE. Estrategia 4: Gestión del Conocimiento. [Artículo de Internet]

http://www.icde.org.co/web/guest/mejorar_capacidad_institucional [Consulta:
24 de noviembre de 2015].
ICDE. Estándares: de datos y tecnológicos [Artículo de Internet]

http://www.icde.org.co/web/guest/estandares_datos [Consulta: 1 de abril de
2016].
INSTITUTO COLOMBIANO DE NORMAS TÉCNICAS. Ingeniería de

Software: Directrices para la aplicación de la NTC-ISO 9001:2000 a software
de computador. Bogotá: ICONTEC; 2005. 73 p. NTC-ISO/IEC 90003.
INSTITUTO GEOGRÁFICO AGUSTÍN CODAZZI. Áreas estratégicas – CIAF.

[Artículo de Internet] www.igac.gov.co [Consulta: 30 de noviembre de 2015].
ISACA. Control Objectives for Information and Related Technology - COBIT

5. ISACA; 2012. 94 p.
ISO. Software engineering ─ Guidelines for the application of ISO 9001:2008

to computer software. ISO; 2014. 54 p. ISO/IEC 90003.
ISO. Software engineering ─ Software product Quality Requirements and

Evaluation (SQuaRE) ─ Guide to SQuaRE. ISO; 2014. 27 p. ISO/IEC 25000.
108

Evaluation (SQuaRE) ─ System and software quality models. ISO; 2011. 34p.
ISO/IEC 25010.

Evaluation (SQuaRE) ─ Quality requirements. ISO; 2007. 44p. ISO/IEC
25030.
ISOTOOLS. Ciclo PHVA de mejora continua, definición y análisis. [Artículo de

Internet] https://www.isotools.org/2015/02/20/en-que-consiste-el-ciclo-phva-
de-mejora-continua [Consulta: 20 DE ABRIL de 2016].
LUCERO J. Auditoría de la calidad. En: Piattini M. Auditoría Informática: Un

enfoque práctico. 2 ed. Madrid: RA-MA; 2011. p. 361-387.
PIATTINI M. et al. Auditoría Informática: Un enfoque práctico. 2 ed. Madrid:
RA-MA; 2011. p. 655.
PIATTINI M., GARCÍA F., CABALLERO I. Calidad de Sistemas Informáticos.

México: Alfaomega; 2007. p. 386.
PORTAL ISO 25000. Norma ISO 25010 [Artículo de Internet]

http://iso25000.com/index.php/normas-iso-25000/iso-25010 [Consulta: 29 de
febrero de 2016].
109
SÁNCHEZ, D. Metodología para realizar Auditoría a aplicaciones

informáticas en funcionamiento. [Trabajo de grado]. Bogotá. Universidad
Distrital Francisco José de Caldas. Facultad de Ingeniería; 2007.
SEI. CMMI for Development: Improving processes for better products,

Version1.2. Carneige Mellon University; 2006.
SEI. Handbook for Conducting Standard CMMI Appraisal Method for Process
Improvement (SCAMPI) B and C Appraisals, Version 1.1. Carneige Mellon
University; 2005.
TOMLINSON Roger. Pensando en el SIG. 3 ed. Redlands CA: ESRI Press;

2008. 257 p.
110
GLOSARIO
CALIDAD: Condición de productos o servicios que da cuenta del

funcionamiento tal y como se espera por parte del cliente y la organización.
CASO DE ESTUDIO: Método de investigación cualitativa en donde se

escoge para análisis un fenómeno individual en un entorno real.
CMMI: Capability Maturity Model Integration. Modelo para la mejora y

evaluación de procesos de desarrollo, utilización y mantenimiento de
software.
COBIT: Control Objectives for Information and Related Technology, o

Objetivos de Control para Información y Tecnologías Relacionadas en
español, es un marco de gobierno y administración de TI utilizado para
optimizar la inversión en tecnología e información, así como el uso de ellas
en beneficio de las partes interesadas.
CONPES: Consejo Nacional de Política Económica y Social. Máxima

autoridad nacional de planeación y se desempeña como organismo asesor
del Gobierno en todos los aspectos relacionados con el desarrollo económico
y social del país.
CONTROL: Etapa de la administración de los procesos de una organización

donde se puede verificar si los informes y los hechos sobre los procesos son
acordes con los objetivos.
111
HABILITADOR: Los habilitadores son todos esos elementos tangibles e

intangibles que permiten que exista la gobernabilidad y la
gestión de TI. Dentro de COBIT 5 los habilitadores se establecen para
responder a las metas definidas en la compañía; éstos requieren de las
salidas de otros habilitadores como entradas y tienen salidas que pueden
ayudar a otros a realizar su función.
ICDE: Infraestructura Colombiana de Datos Espaciales. Conjunto de

estrategias, políticas, estándares, entidades y recursos que facilita el acceso
a la Información Geográfica en Colombia.
ISACA: Information Systems Audit and Control Asociation. Es una

organización internacional que apoya y patrocina el desarrollo de
metodologías y certificaciones para la realización de actividades de auditoría
y control en sistemas de información.
ISO: International Organization for Standardization. Organismo encargado de

promover el desarrollo de normas internacionales de fabricación, comercio y
comunicación para todas las ramas industriales a excepción de la eléctrica y
la electrónica.
MODELO: En el contexto de auditoría de Sistemas, se refiere a un conjunto

coherente de estrategias y procedimientos para realizar una evaluación a los
procesos de un Sistema de Información.
112
NTC: Norma Técnica Colombiana. Documento normativo de aplicación

voluntaria, establecido por consenso, que suministra, para uso común y
repetido, reglas, directrices y características para actividades o resultados
encaminados al logro del grado óptimo de orden, en un contexto dado.
PHVA: las siglas del ciclo forman un acrónimo compuesto por las iniciales de
las palabras Planificar, Hacer Verificar y Actuar. Cada uno de estos 4
conceptos corresponde a una fase o etapa del ciclo de mejora continua.
PRINCIPIO: En el marco descriptivo del Sistema de Gestión de Calidad de

una organización, un principio es la herramienta de trabajo de directivos para
llevar a su organización hacia la mejora en el desempeño.
REQUISITO: Descripción documentada de una necesidad planteada por

diferentes actores que intervienen en la creación del software.
SCAMPI: (Standard CMMI Appraisal Method for Process Improvement) es un

proceso diseñado y desarrollado por el Carnegie Mellon-SEI para ofrecer
evaluaciones (benchmarkings) de calidad con relación a los modelos
Capability Maturity Model Integration (CMMI) y People Capability Maturity
Model (People CMM).
SIG: Sistema de Información Geográfica. Asociación de datos, software,

hardware y talento humano, que permite realizar análisis espacial y ofrecer
herramientas de apoyo a decisiones dentro de una organización.
113
STAKEHOLDERS: Nombre dado a los interesados en el proceso de

desarrollo de software SIG.
SISTEMA DE GESTIÓN DE CALIDAD: Conjunto de normas y buenas

prácticas dentro de una organización que interrelacionadas permiten
administrar la calidad en la misma.
114
ANEXO A: MAPA MENTAL DEL PROYECTO
Figura 19. Mapa mental del proyecto.

ANEXO B: INDICE DE FORMATOS
A continuación se presenta un listado completo de los formatos y plantillas,

organizado en escala cronológica con el ánimo de facilitar su ubicación.
Tabla 18. Listado y clasificación de formatos.

CLASE DIMENSIÓN TIPO NOMBRE
Plantilla Apoyo N/A Carta de autorización
Formato CT Validación Formato inicial
Formato CT Validación Formato de planificación y
preparación
Formato CT Validación Formato de identificación y
priorización de requerimientos
Formato CT Validación Formato de selección del equipo
Formato CT Dictamen Formato de entrevista inicial
Formato RQ Dictamen Formato de recolección de pruebas
objetivas
Formato RQ Dictamen Formato de la caracterización del
SGC
Formato RQ Dictamen Formato para la valoración de
requisitos de calidad
Formato RQ Dictamen Formato para la valoración del
control de registros
responsabilidad de la dirección
gestión de los recursos
Formato EF Dictamen Formato para la valoración de
planificación de realización del
producto
procesos relacionados con el cliente
diseño y desarrollo
diseño y desarrollo (resultado)
producción y prestación del servicio

producción y prestación del servicio
(resultados)
medición, análisis y mejora
Plantilla Apoyo N/A Carta de cierre
117
ANEXO C: CARTA DE AUTORIZACIÓN
Modelo de carta de autorización por parte de la alta dirección empoderando

al(los) evaluador(es) para que pueda(n) acceder a toda la información que
sea necesaria y se deja establecen sus responsabilidades.
Figura 20. Modelo para carta de autorización.
118
ANEXO D: FORMATOS DE CARACTERIZACIÓN
Figura 21. Formato inicial.

A. FORMATO INICIAL
1. DATOS BÁSICOS DE LA ORGANIZACIÓN
1.4 FECHA DE ELABORACIÓN: DD-MM-AAAA 1.5 LIDER:
1.6 ENTREVISTADO: 1.7 CARGO:
1.8 MISIÓN DE LA ORGANIZACIÓN:
1.9 VISIÓN DE LA ORGANIZACIÓN:
*Anexe el organigrama de la compañía, identificando la ubicación exacta del(las) área(s) responsable(s)

1.10 ORGANIGRAMA.
del desarrollo.
1.11 DESCRIPCIÓN GENERAL DEL EQUIPO DE DESARROLLO SIG
Liste los integrantes del equipo, señalando cada uno de los roles existentes.
1.12 DESCRIPCIÓN GENERAL DE PROCESOS ASOCIADOS AL DESARROLLO SIG

Realice una descripción general de los porcesos asociados al desarrollo: Recepción de requerimientos, gestión del cambio, documentación,
autoridades, responsabilidades, tipos de pruebas, metodología, etc.
ELABORÓ: REVISÓ:
119
Figura 22. Formato de planificación y preparación.

B. FORMATO DE PLANIFICACIÓN Y PREPARACIÓN
1. PROYECTO A EVALUAR
PROYECTO: FASE ACTUAL:

2. LISTADO DE PERSONAL CLAVE
NOMBRE CARGO ÁREA JEFE O SUPERIOR JEFE O SUPERIOR HORARIO
3. DIRECTORIO DE SITIOS CLAVE

DESCRIPCIÓN DIRECCIÓN TELÉFONO HORARIO CONTACTO
4. CRONOGRAMA BASE
FASE EVALUACIÓN FECHA INICIAL FECHA FINAL
(Fecha inicial estipulada en la carta de

PREPARACIÓN
autorización)
SGC
(Fecha final estipulada en la carta de

DESARROLLO
autorización)
ELABORÓ: REVISÓ:
120
Figura 23. Formato de identificación y priorización de requerimientos.

C. IDENTIFICACIÓN Y PRIORIZACIÓN DE REQUERIMIENTOS
1. REQUERIMIENTOS PROPIOS DE EVALUACIÓN
2. REQUERIMIENTOS PROPIOS DE LA NORMA

3. OTROS REQUERIMIENTOS
ELABORÓ: REVISÓ:
121
Figura 24. Formato de selección del equipo.

D. SELECCIÓN DEL EQUIPO
1. EQUIPO DE EVALUADORES
1.1 EVALUADOR LÍDER
1.2 EVALUADOR DE APOYO

1. EQUIPO DE COLABORADORES
2.1 REPRESENTANTE DE LA DIRECCIÓN
2.2 COLABORADOR
2.3 COLABORADOR
2.4 COLABORADOR
2.5 COLABORADOR
ELABORÓ: REVISÓ:
122
Figura 25. Formato de entrevista inicial (parte 1 de 2).

E. ENTREVISTA INICIAL
1. GENERALES
1.1 FECHA DE ELABORACIÓN DD-MM-AAAA 1.2 LUGAR DE ELABORACIÓN
1.3 NOMBRE ENTREVISTADO
1.4 CARGO ENTREVISTADO
1.5 NOMBRE ENTREVISTADOR
1.6 CARGO ENTREVISTADOR
2. SGC
2.1 ¿QUÉ ASPECTOS CONSIDERAN EN LA
PLANIFICACIÓN DE LA CALIDAD DEL
DESARROLLO DE SIG?
2.2 ¿QUE DOCUMENTACIÓN COMPRENDE EL
SGC DE LA ORGANIZACIÓN?
2.3 ¿CÓMO MIDEN LA COMPLEJIDAD DE LOS

PROCESOS?
2.4 ¿CÓMO DETERMINAN LAS

INTERACCIONES ENTRE LOS PROCESOS?
2.5 ¿CÓMO SE DETERMINA LA COMPETENCIA
DEL PERSONAL QUE PARTICIPA EN EL
DESARROLLO DEL SIG?
2.6 ¿DE QUE FORMA GESTIONAN LA
DOCUMENTACIÓN ASOCIADA AL
DESARROLLO DE SIG?
2.7 ¿EN QUE ASPECTOS DEL DESARROLLO DE
SIG PARTICIPA LA DIRECCIÓN?
3.1 ¿CÓMO SE REALIZA LA ASIGNACIÓN DE

LOS RECURSOS?
3.2 ¿CÓMO SE DETERMINA LA CORRECTA

3.3 ¿CÓMO SE MIDE LA EFECTIVIDAD DE LA

123
Figura 26. Formato de entrevista inicial (parte 2 de 2).

4.1 ¿QUÉ ASPECTOS SON INCLUIDOS EN LA

PLANIFICACIÓN DE LA REALIZACIÓN DEL SIG?
4.2 ¿CÓMO SE SELECCIONAN LOS ASPECTOS

METODOLÓGICOS CON LOS QUE SE
DESARROLLA EL SIG?

REQUISITOS DEL CLIENTE?

REQUISITOS DEL PRODUCTO?
4.5 ¿CÓMO SE REALIZA EL SEGUIMIENTO A

LAS ACCIONES QUE REALIZAN LOS QUE
INTERVIENEN EN EL DESARROLLO DEL SIG?
4.6 ¿CÓMO SE REGISTRAN LOS CAMBIOS
5.1 ¿CÓMO SE MIDE LA SATISFACCIÓN DEL

CLIENTE CON EL SIG UNA VEZ DESPLEGADO?
5.2 ¿QUÉ MECANISMOS DE COMUNICACIÓN

EXISTEN CON EL CLIENTE LUEGO DE LA
5.3 ¿QUÉ CRITERIOS PERMITEN LA

PRORIZACIÓN DE MEJORAS SOBRE EL SIG?
5.4 ¿CÓMO SE ASIGNAN LAS

RESPONSABILIDADES DE EJECUCIÓN SOBRE
LAS MEJORAS PARA EL SIG?
ELABORÓ: REVISÓ:
124
ANEXO E: FORMATOS DE SEGUIMIENTO Y MEDICIÓN DE LOS REQUISITOS PARA LA

APLICACIÓN DE LA NORMA NTC-ISO/IEC 90003
Figura 27. Formato y calificaciones de la caracterización del SGC.

MODELO DE APLICACIÓN NTC-ISO/IEC 90003 PARA SOFTWARE SIG CALIFICACIONES
A. FORMATO DE CARACTERIZACIÓN DEL SISTEMA DE GESTIÓN DE CALIDAD
1. DATOS BÁSICOS
Caracterización del proyecto
1.4 FECHA DE ELABORACIÓN: 1.5 ELABORÓ:
(No calificable)
1.6 OBJETIVO DEL SIG:
(Marco legal, comercial y/o técnico).
2. SISTEMA DE GESTIÓN DE LA CALIDAD ¿Cada ítem está claramente identificado, definido y documentado?
No Parcialmente Totalmente
20%
ESTRATEGIAS: (1) (3) (5)
Nivel de cumplimiento
Peso por componente

20%
PROCESOS: (1) (3) (5)
IDENTIFICACIÓN DE ELEMENTOS DEL No Parcialmente Totalmente
20%
SISTEMA DE GESTIÓN DE LA CALIDAD RECURSOS: (1) (3) (5)
ESTRUCTURA No Parcialmente Totalmente
20%
ORGANIZACIONAL: (1) (3) (5)
20%
DOCUMENTOS: (1) (3) (5)
3. IDENTIFICACIÓN DE PROCESOS DE SOFTWARE Calificación obtenida = ∑(Nivel de cumplimiento*Peso por componente)
3.1.1 EQUIPO RESPONSABLE DEL 3.1.2 NÚMERO DE INTEGRANTES:
PROYECTO:
SI NO
3.2 MÓDELO DE CICLO DE VIDA APLICADO: ¿Se identifica?
(1) (0)
3.3 LISTA SECUENCIAL DE PROCESOS
Requisitos de desarrollo
3.3.1 FASE DEL MODELO ACTUAL:
3.3.2 FASE DEL MODELO SIGUIENTE:
SI NO
3.4 METODOLOGÍA DE DESARROLLO: ¿Se identifica?
(1) (0)
3.4.1 FASE METODOLOGÍA ACTUAL:

3.4.2 FASE METODOLOGÍA SIGUIENTE:
SI NO
3.5 DOCUMENTACIÓN DE REFERENCIA: ¿Se identifica?
(1) (0)
Calificación obtenida = ∑(Peso por componente)

Figura 28. Tabla de recomendaciones para la caracterización el SGC según calificaciones.

RESULTADOS

(No calificable)
Lista de relaciones calificación obtenida/recomendación por ítem

Rango de Calificación X Recomendación
Inexistente No existe un SGC claro en la compañía, debe incluirse en los

1 <= X <= 2,6 proyectos de mejoramiento de la compañía desde la alta dirección.
Insuficiente Existe un SGC, pero sin el suficiente arraigo en la organización,
2,6 < X <= 3,4 deben mejorarse todos los aspectos de baja puntuación.
Por mejorar La compañía esta cerca de un SGC, confiable se debe reforzar el
3,4 < X <= 4,6 aspecto más bajo como prioridad
Óptimo La compañía cuenta con un SGC autosostenible, con tendencia a la
x =5 mejora contínua implementada que debe ser monitoreado.
Se debe implementar una política de desarrollo de software

1
urgente.
Se debe mejorar el aspecto más bajo para incluirlo dentro de la
2
política de desarrollo de software.
Se debe garantizar y registrar el cumplimiento de la política de
3
desarrollo de software.

Figura 29. Formato y calificaciones para la valoración de requisitos de calidad.

B. FORMATO DE VALORACIÓN DE REQUISITOS DE CALIDAD
1. VALORACIÓN DE REQUISITOS DE DOCUMENTACIÓN ¿Cada ítem está claramente identificado, definido y documentado?
1.1.1 POLÍTICA Y OBJETIVOS DE CALIDAD 20%
(1) (3) (5)
1.1.2 MANUAL DE CALIDAD 20%
(1) (3) (5)
1.1 DESCRIPCIÓN DOCUMENTACIÓN 1.1.3 PROCEDIMIENTOS ISO 9001:2000 No Parcialmente Totalmente
20%
DE POLÍTICAS DE CALIDAD DOCUMENTADOS (1) (3) (5)
1.1.4 DOCUMENTOS DE LA ORGANIZACIÓN 20%
(1) (3) (5)
1.1.5 REGISTROS REQUERIDOS POR LA NORMA No Parcialmente Totalmente
20%
(1) (3) (5)
1.2.1 DESCRIPCIONES DE LOS PROCESOS 20%
(1) (3) (5)
1.2.2 DESCRIPCIONES SOBRE No Parcialmente Totalmente
20%
PROCEDIMIENTOS Y/O PLANTILLAS (1) (3) (5)
1.2.3 DESCRIPCIONES DE MODELO DE CICLO DE No Parcialmente Totalmente
1.2 PROCESOS DE SOFTWARE 20%
VIDA USADO (1) (3) (5)
1.2.4 HERRAMIENTAS, TÉCNICAS, No Parcialmente Totalmente
20%
TECNOLOGÍAS Y MÉTODOS (1) (3) (5)
1.2.5 NORMAS O RECURSOS GUÍA PARA No Parcialmente Totalmente
20%
PRUEBAS (1) (3) (5)
2. VALORACIÓN DEL MANUAL DE CALIDAD ¿Cada ítem está claramente identificado, definido y documentado?
2.1 ALCANCE DEL SISTEMA DE GESTIÓN DE LA No Parcialmente Totalmente
30%
cumplimiento
CALIDAD (1) (3) (5)
Nivel de
2.2 PROCEDIMIENTOS DOCUMENTADOS No Parcialmente Totalmente
40%
ESTABLECIDOS (1) (3) (5)
2.3 INTERACCIÓN ENTRE PROCESOS DEL SGC 30%
(1) (3) (5)
3. CONTROL DE DOCUMENTOS
3.1 APROBACIÓN DE DOCUMENTOS ANTES DE SU SI NO
EMISIÓN (1) (0)
Procesos de control de documentos

SI NO
3.2 REVISIÓN Y ACTUALIZACIÓN DE DOCUMENTOS
(1) (0)
SI NO
3.3 CONTROL DE CAMBIOS Y ESTADO ACTUAL
(1) (0)
SI NO
3.4 CONTROL DE VERSIONES DE DOCUMENTOS ¿Se identifica?
(1) (0)
SI NO
3.5 PRESERVACIÓN DE LOS DOCUMENTOS
(1) (0)
SI NO
3.6 CONTROL DE DOCUMENTOS EXTERNOS
(1) (0)
SI NO
3.7 CONTROL DE DOCUMENTOS OBSOLETOS
(1) (0)

Figura 30. Tabla de recomendaciones para la valoración de requisitos de calidad, según

calificaciones.
RESULTADOS
Inexistente No existe documentación que soporte la poítica de calidad, debe

1 <= X <= 2,6 incluirse en los proyectos de mejoramiento de la compañía desde la alta
Insuficiente La documentación existente es insuficiente, deben mejorarse los
2,6 < X <= 3,4 aspectos con la calificación más baja.
Por mejorar La documentación abarca todos los requisitos necesarios de manera
3,4 < X <= 4,6 parcial, deben mejorarse los aspectos de calificación más baja.
Óptimo La compañía cuenta con mecanismos que soportan todos los requsitos
x =5 documentales de la norma.
Inexistente No existe documentación que soporte la poítica de calidad, debe

1 <= X <= 2,6 incluirse en los proyectos de mejoramiento de la compañía desde la alta
Insuficiente La documentación existente es insuficiente, deben mejorarse los
2,6 < X <= 3,4 aspectos con la calificación más baja.
Por mejorar La documentación abarca todos los requisitos necesarios de manera
3,4 < X <= 4,6 parcial, deben mejorarse los aspectos de calificación más baja.
Óptimo La compañía cuenta con mecanismos que soportan todos los requsitos
x =5 documentales de la norma.
Inexistente No existe manual de calidad en la compañía, debe implementarse como

1 <= X <= 3 plan demejora desde la alta dirección.
Insuficiente Los componentes no conformes, deben ser mejorados como medida
3 < X <= 4,7 dese la alta dirección.
Conforme El manual de calidad existente debe ser objeto de monitorización para
4,7 < X <= 5 garantizar su compatibilidad con las políticas corporativas..

1 <= x < 3 Se debe implementar una política de desarrollo de software urgente.
Se debe mejorar el aspecto más bajo para incluirlo dentro de la política

3 <= x < 5
de desarrollo de software.
Se debe garantizar y registrar el cumplimiento de la política de
5 <= x <= 7
desarrollo de software.

Figura 31. Formato y calificaciones para la valoración del control de registros.

C. FORMATO DE VALORACIÓN DE CONTROL DE REGISTROS
1. PROCESO DE CONTROL DE REGISTROS
SI NO
1.1 RESULTADOS DE PRUEBAS DOCUMENTADAS ¿Se identifican?
(1) (0)
Procesos de control de registros

SI NO
1.2 INFORMES SOBRE PROBLEMAS ¿Se realizan?
(1) (0)
SI NO
1.3 SOLICITUDES DE CAMBIOS ¿Se realizan?
(1) (0)
1.4 DOCUMENTACIÓN MARCADA CON SI NO
¿Se identifica?
COMENTARIOS (1) (0)
SI NO
1.5 INFORMES DE AUDITORÍAS Y EVALUACIONES ¿Se hallaron?
(1) (0)
SI NO
1.6 REGISTROS DE REVISIONES E INSPECCIONES ¿Se hallaron?
(1) (0)
2. VALORACIÓN DE EVIDENCIA DE OPERACIÓN EFICÁZ
SI NO
2.1 CAMBIOS HECHOS A LOS RECURSOS ¿Se registran?
(1) (0)
Valoración de evidencia eficáz

SI NO
2.2 ESTIMACIONES V.S. AVANCES ¿Se documentan?
(1) (0)
2.3 SELECCIÓN DE HERRAMIENTAS, SI NO
¿Se documentan?
METODOLOGÍAS Y PROVEEDORES (1) (0)
SI NO
2.4 ACUERDOS DE LICENCIA DE SOFTWARE ¿Se documentan?
(1) (0)
SI NO
2.5 ACTAS DE REUNIONES ¿Se hallaron?
(1) (0)
SI NO
2.6 REGISTROS DE LIBERACIÓN DE SOFTWARE ¿Se hallaron?
(1) (0)
3. RETENCIÓN Y DISPOSICIÓN DE REGISTROS
No Si
3.1 MÉTODO DE ALMACENAMIENTO a ¿Se identifica? PESOS CONDICIONALES
(1) (5)
3.2 CONFIABILIDAD DEL MÉTODO DE Baja Media Alta Calificación = Baja si a = No
1 25%
ALMACENAMIENTO (1) (3) (5) Calificación = Media/Alta si a = Si
Baja Media Alta
3.3 DISPONIBILIDAD DE LA INFORMACIÓN 2 25%
(1) (3) (5)
3.4 PROTECCIÓN DE LOS MEDIOS DE Baja Media Alta
3 25%
ALMACENAMIENTO (1) (3) (5)
3.4 EVALUACIÓN DE LA NATURALEZA DE LA No Si
4 ¿Se realiza? 25%
PROPIEDAD DE LA INFORMACIÓN (1) (5)
Calificación obtenida = ∑(Nivel de cumplimiento*Peso por componentes de 1 a 4)

Figura 32. Tabla de recomendaciones para la valoración el control de registros, según

calificaciones.
RESULTADOS

El proceso de control de registros no se realiza adecuadamente,

0 <= x < 3
debe implmentarse
EL proceso de control de resgistros tiene falencias que ponen en
3 <= x < 5
riesgo su confiabilidad
El proceso de control de registros se realiza de forma adecuada,
5 <= x <= 6
debe monitorearse.

El proceso de control de registros no se realiza adecuadamente,

0 <= x < 3
debe implmentarse
EL proceso de control de resgistros tiene falencias que ponen en
3 <= x < 5
riesgo su confiabilidad
El proceso de control de registros se realiza de forma adecuada,
5 <= x <= 6
debe monitorearse.

Inexistente El proceso de retención y disposición de los registros debe ser

1 <= X < 2,25 incluido en el plan de mejoramiento desde la alta irección.
Insuficiente La seguridad de la información puede verse comprometida si no
2,25 <= X < 3,75 se mejoran los aspectos de más baja calificación.
Por mejorar La compañía debe fortalecer el aspecto de más baja calificación,
3,75 <= X < 5 para garantizar un correcto proceso de retención y disposición.
Óptimo La compañía cuenta con un poroceso de retención y disposición
x =5 con tendencia a la mejora contínua que debe ser monitoreado.

Figura 33. Formato y calificaciones para la valoración de responsabilidad de la dirección.

D. FORMATO DE VALORACIÓN DE RESPONSABILIDAD DE LA DIRECCIÓN
1. COMPROMISO DE LA DIRECCIÓN
SI NO
1.1 COMUNICADO OFICIAL A LA ORGANIZACIÒN ¿Se realizan?
(1) (0)
SI NO
Componentes de
responsabilidad
1.2 ESTABLECIMIENTO DE POLÍTICA DE CALIDAD ¿Se comunicó?
(1) (0)
SI NO
1.3 ESTABLECIMIENTO DE OBJETIVOS DE CALIDAD ¿Se conocen?
(1) (0)
SI NO
1.4 ESTABLECIMIENTO DE REVISIONES ¿Se conocen?
(1) (0)
1.5 GESTIÓN PARA LA DISPONIBILIDAD DE SI NO
¿Se realiza?
RECURSOS (1) (0)
2. VALORACIÓN DEL ENFOQUE AL CLIENTE Calificación obtenida = ∑(Valor por componente)
SI NO
2.1 POLÍTICAS DE SERVICIO AL CLIENTE ¿Se conocen?
(1) (0)
Enfoque al cliente
SI NO
2.2 METAS DEL SERVICIO AL CLIENTE ¿Se tienen?
(1) (0)
2.3 GESTIÓN DE OPERACIONES DE SERVICIO AL SI NO
¿Se realiza?
CLIENTE (1) (0)
2.4 CAPACITACIÒN DE PERSONAL PARA SERVICIO SI NO
¿Se registra?
AL CLIENTE (1) (0)
3. VALORACIÓN DE LA POLÍTICA DE CALIDAD Calificación obtenida = ∑(Valor por componente)
3.1 MECANISMOS DE DIFUSIÓN DE LA POLÍTICA DE SI NO
¿Se aplican?
CALIDAD (1) (0)
Enfoque al cliente
3.2 MECANISMOS DE MEDICIÓN DE SI NO
¿Se aplican?
CUMPLIMIENTO DE LA POLÍTICA DE CALIDAD (1) (0)
3.3 MECANISMOS DE CONTROL DE CAMBIOS DE LA SI NO
¿Se aplican?
POLÍTICA DE CALIDAD (1) (0)
3.4 MECANISMOS DE EVALUACIÓN DE LA POLÍTICA SI NO
¿Se aplican?
DE CALIDAD (1) (0)
4. PLANIFICACIÓN Calificación obtenida = ∑(Valor por componente)
4.1 MECANISMOS DE DIFUSIÓN DE LOS OBJETIVOS SI NO
¿Se aplican?
DE LA CALIDAD (1) (0)
Enfoque al cliente
4.2 MECANISMOS DE MEDICIÓN DE SI NO
¿Se aplican?
CUMPLIMIENTO DE LOS OBJETIVOS DE LA CALIDAD (1) (0)
4.3 MECANISMOS DE CONTROL DE CAMBIOS DE SI NO
¿Se aplican?
LOS OBJETIVOS DE LA CALIDAD (1) (0)
4.4 MECANISMOS DE EVALUACIÓN DE LOS SI NO
¿Se aplican?
OBJETIVOS DE LA CALIDAD (1) (0)
5. RESPONSABILIDAD, AUTORIDAD Y COMUNICACIÓN Calificación obtenida = ∑(Valor por componente)
5.1 MECANISMOS DE DIFUSIÓN DE LAS SI NO
¿Se aplican?
RESPONSABILIDADES (1) (0)
Componentes de responsabilidad,
5.2 REPRESENTANTE DE LA Nombre:

autoridad y comunicación
ORGANIZACIÓN PARA EL SGC

5.3 CARGO 5.4 EXPERIENCIA
RELACIONADA (AÑOS)
5.5 PERFIL ¿Acorde con la SI NO
responsabilidad? (1) (0)
5.6 ESTRATEGIA DE COMUNICACIÓN
6. REVISIÓN POR LA DIRECCIÓN

6.1 MECANISMOS DE REGISTRO DE REVISIONES SI NO
¿Se aplican?
(1) (0)

Figura 34. Tabla de recomendaciones para la valoración de responsabilidad de la dirección,

según calificaciones.
RESULTADOS

La dirección debe establecer, asumir y dar a conocer su

0 <= x < 3
responsabilidad, de lo contrario se ponen en riesgo los resultados
La dirección debe garantizar que hace extensivo el conocimiento de
3 <= x < 5
sus responsabilidades a todos los niveles corporativos.
Es clara la responsabilidad de la dirección; deben monitorearse los
5=x
canales de comunicación y difusión de la misma.
El enfoque de servicio al cliente debe replantearse y difundirse,

0 <= x < 2
como estrategia de mejoramiento desde la alta dirección.
Deben mejorarse los puntos de menor calificación en el enfoque al
2 <= x < 4
cliente.
El enfoque al cliente se tiene claro en la compañía, debe ser
4=x
monitoreado para garantizar su mejora continua.
La estrategias de cumplimiento de la política de calidad deben ser

0 <= x < 2
replanteadas o mejoradas (difusión, medición, alcance)
Se deben mejorar los aspectos de calificación más baja dentro de la
2 <= x < 4
política de calidad.
La política de calidad debe monitorearse dentro de los controles
4=x
corporativos establecidos par su mejora continua.
La estrategias de cumplimiento de las objetivos de calidad deben ser

0 <= x < 2
replanteadas o mejoradas (difusión, medición, alcance)
Se deben mejorar los aspectos de calificación más baja dentro de los
2 <= x < 4
objetivos de calidad.
Los objetivos de calidad deben monitorearse dentro de los controles
4=x
corporativos establecidos par su mejora continua.
0=x Se recomienda crear y/o implementar los mecanismos de difusión de las responsabilidades
1=x Se recomienda monitorear los mecanismos de difusión de las responsabilidades

0=x Se recomienda fortalecer la formación del representante o en su ausencia contratar uno capacitado
1=x Se recomienda mantener un plan de capacitación para el representante

0=x Se recomienda crear y/o implementar los mecanismos de revisión de la dirección
1=x Se recomienda monitorear los mecanismos de difusión de revisión de la dirección

Figura 35. Formato y calificaciones para la valoración de gestión de los recursos (parte 1 de 2).
E. FORMATO DE VALORACIÓN GESTIÓN DE LOS RECURSOS
1. PROVISIÓN DE LOS RECURSOS
SI NO
1.1 IDENTIFICACIÓN DE LOS RECURSOS ¿Se tiene?
Recursos
(1) (0)
1.2 RESPONSABLES DE LA ASIGNACIÓN DE SI NO
¿Se identifican?
RECURSOS (1) (0)
2. RECURSOS HUMANOS
ROL 1
ROL 2
ROL 3
ROL 4
2.1 IDENTIFICACIÓN DE ROLES QUE AFECTAN LA ROL 5
CALIDAD DEL PRODUCTO O DEL PROCESO ROL 6
ROL 7
ROL 8
ROL 9
ROL 10
ROL 1 ¿Acorde? Si (1) No (1)
Valoración de competencia
2.2 COMPETENCIAS REQUERIDAS POR ROLES QUE
AFECTAN LA CALIDAD DEL PRODUCTO O DEL
PROCESO
ROL 1 B M A
ROL 2 B M A
ROL 3 B M A
ROL 4 B M A
2.1 NIVEL DE IMPACTO POR ROLES QUE AFECTAN ROL 5 B M A
LA CALIDAD DEL PRODUCTO O DEL PROCESO ROL 6 B M A
ROL 7 B M A
ROL 8 B M A
ROL 9 B M A
ROL 10 B M A

Figura 36. Formato y calificaciones para la valoración de gestión de los recursos (parte 2 de 2).
3. INFRAESTRUCTURA
3.1 ESPACIO DE TRABAJO
3.1.1 PUESTOS DE TRABAJO 3.1.2 CABLEADO ESTRUCTURADO 3.1.3 CONECTIVIDAD
3.1.4 COMUNICACIONES 3.1.5 SISTEMA DE IMPRESIÓN
3.2 RECURSOS TÉCNICOS

3.2.1 VALORACIÓN DEL SOFTWARE 3.2.2 VALORACIÓN DEL HARDWARE
3.2.3 POLÍTICAS DE SEGURIDAD 3.2.4 POLÍTICAS DE RESPALDO
3.2.5 OTROS RECURSOS
4. AMBIENTE DE TRABAJO
4.1 POLÍTICAS DE CONVIVENCIA Y AMBIENTE LABORAL DE LA ORGANIZACIÓN
4.2 RESULTADOS DE EVALUACIONES DE AMBIENTE LABORAL ANTERIORES
4.3 GRUPOS DE ACCIÓN

¿EQUIPO CONFORMADO? TIEMPO DE EXISTENCIA PRESIDENTE
4.3.1 COPASST
4.3.2 COMITÉ DE ¿EQUIPO CONFORMADO? TIEMPO DE EXISTENCIA PRESIDENTE

CONVIVENCIA
4.3.3 OTROS
134
Figura 37. Tabla de recomendaciones para la valoración gestión de los recursos, según
calificaciones (parte 1 de 2).
0=x Se recomienda realizar la identificación de recursos con su respectiva documentación
1=x Se recomienda mantener monitoreada la lista de identificación de recursos
0=x Se recomienda realizar la identificación de los responsables de asignar los recursos
1=x Se recomienda mantener monitoreada la lista de los responsables de asignar los recursos

0=x Se recomienda fortalecer la formación del responsable o en su ausencia contratar uno capacitado
1=x Se recomienda mantener un plan de capacitación para el responsable
Según el impacto se debe priorizar aquellos de mayor incidencia con respecto a las
recomendaciones del apartado anterior.

Figura 38. Tabla de recomendaciones para la valoración gestión de los recursos, según
calificaciones (parte 2 de 2).
A criterio del evaluador se deben generar las recomendaciones en aquellos puntos

detectados como negativos, que permitan tomar desiciones encaminadas al
mejoramienteto.
Este apartado es vital dentro del enfoque holístico y como marco general del SGC.
136
ANEXO F: FORMATOS DE SEGUIMIENTO Y MEDICIÓN PARA EL ENFOQUE DE LA NTC-ISO/IEC

90003 AL DESARROLLO DE SOFTWARE SIG
Figura 39. Formato y calificaciones para la valoración de planificación de realización del producto (parte 1 de 2).
K. FORMATO DE VALORACIÓN DE PLANIFICACIÓN DE REALIZACIÓN DEL PRODUCTO
(No calificable)
1. PLANIFICACION DE LA REALIZACIÓN DEL PRODUCTO
SI NO
1.1 CICLO DE VIDA DEL SOFTWARE CVSW ¿Se identifica?
(1) (0)
1.2. PLANIFICACIÓN DE LA CALIDAD

1.2.1 DESCRIPCIÓN DEL PROYECTO DE SOFTWARE SIG PESO
SI NO
¿Se identifica? 12,50%
1.2.1.1 ANTECEDENTES. (1) (0)
SI NO
1.2.1.2 OBJETIVOS. (1) (0)
Estructura inicial del proyecto SIG

SI NO
1.2.1.3 RESULTADOS ESPERADOS. (1) (0)
SI NO
1.2.1.4 ADAPTACIÓN DEL SGC. (1) (0)
1.2.1.5 DEFINICIÓN DE ACTIVIDADES DE REVISIÓN, VERIFICACIÓN, SI NO
VALIDACIÓN. (1) (0)
1.2.1.6 DEFINICIÓN DE PROCEDIMIENTOS DE GESTIÓN DE LA SI NO
CONFIGURACIÓN. (1) (0)
SI NO
1.2.1.7 DEFINICIÓN DE ACTIVIDADES DE MONITOREO Y MEDICIÓN. (1) (0)
SI NO
1.2.1.8 GESTIÓN DEL CAMBIO. (1) (0)

Figura 40. Formato y calificaciones para la valoración de planificación de realización del producto (parte 2 de 2).
1.2.2 ESTUDIO DE LOS REQUISITOS DE SOFTWARE SIG
SI NO
¿Se identifica? 25%
1.2.2.1 EVALUACIÓN DE NECESIDADES. (1) (0)
Estudio de los requisitos

SI NO
1.2.2.2 ÁMBITO DEL SISTEMA. (1) (0)
1.2.2.3 DEFINICIÓN DEL EQUIPO SIG Y SUS RESPECTIVAS NECESIDADES DE SI NO

FORMACIÓN. (1) (0)
SI NO
(1) (0)
1.2.2.4 MODELO DE CALIDAD DEL PRODUCTO Y REQUISITOS DE CALIDAD
1.2.3 DISEÑO CONCEPTUAL DE SOFTWARE SIG
SI NO
1.2.3.1 PLAN PARA EL DISEÑO Y DESARROLLO (1) (0)
SI NO
DISEÑO DE LA BASE DE DATOS. (1) (0)
SI NO
1.2.3.2 DISEÑO DE LA TECNOLOGÍA (HARDWARE Y SOFTWARE). (1) (0)
SI NO
1.2.3.3 DISEÑO DE PRUEBAS. (1) (0)
1.2.4 IMPLEMENTACIÓN DE SOFTWARE SIG
SI NO
¿Se identifica?
1.2.4.1 PLAN PARA LA IMPLEMENTACIÓN (1) (0)
138
Figura 41. Tabla de recomendaciones para la valoración de planificación de realización del

producto, según calificaciones.
RESULTADOS

(No calificable)
La organización debe asegurar

La organización debe adoptar un que el ciclo de vida
CVSW ciclo de vida para el proyecto, o selecionado permita la
pone en riesgo su correcta realización del proyecto.
realización.
Lista de relaciones calificación obtenida/recomendación por aspecto.

X = S (de cada ítem* Peso)
La organización debe asegurar que planifica y

Deficiente desarrolla los procesos necesarios para la
0%<= X <= 50% realización del producto en coherencia con el
SGC.
La organización debe asegurar que planifica y
Insuficiente desarrolla todos los procesos necesarios para la
50% < X < 7 5% realización del producto en coherencia con el
SGC.
La organización debe reforzar los procesos
Aceptable
necesarios para la realización del producto en
75%<= X <= 100%
coherencia con el SGC.
Deficiente La organización debe implementar un proceso

0%<= X <= 50% de ingeniería de requerimientos
Insuficiente La organización debe mejorar su proceso de

50% < X < 7 5% ingeniería de requerimientos
Aceptable La organización debe mejorar el componente

75%<= X <= 100% de requsitos con más baja calificación
Deficiente La organización debe implementar un proceso

0%<= X <= 50% de diseño más riguroso
Insuficiente La organización debe mejorar su proceso de
50% < X < 7 5% diseño
Aceptable La organización debe mejorar el componente
75%<= X <= 100% de desarrollo con más baja calificación
La organización debe adoptar un La organización debe asegurar

Plan
plan de implementación para el que el ciclo de vida

Figura 42. Formato y calificaciones para la valoración de procesos relacionados con el cliente (parte 1 de 2).
L. FORMATO DE VALORACIÓN DE PROCESOS RELACIONADOS CON EL CLIENTE
FECHA DE ELABORACIÓN: DD-MM-AAAA LÍDER:
(No calificable)
1. DETERMINACIÓN DE REQUISITOS RELACIONADOS CON EL PRODUCTO (MODELO DE CALIDAD) PESO
SI NO
(1) (0)
1.1 ADECUACIÓN FUNCIONAL Realice una breve descripción de como se aborda este punto
SI NO
(1) (0)
1.2 EFICIENCIA DE DESEMPEÑO Realice una breve descripción de como se aborda este punto
Deterinación de requisitos del proyecto SIG

SI NO
(1) (0)
1.3 COMPATIBILIDAD Realice una breve descripción de como se aborda este punto
SI NO
(1) (0)
1.4 USABILIDAD Realice una breve descripción de como se aborda este punto
SI NO
(1) (0)
1.5 FIABILIDAD Realice una breve descripción de como se aborda este punto
SI NO
(1) (0)
1.6 SEGURIDAD Realice una breve descripción de como se aborda este punto
SI NO
(1) (0)
1.7 MANTENIBILIDAD Realice una breve descripción de como se aborda este punto
SI NO
(1) (0)
1.8 PORTABILIDAD Realice una breve descripción de como se aborda este punto
2. DETERMINACIÓN DE REQUISITOS RELACIONADOS CON EL PRODUCTO (CICLO DE VIDA DEL SOFTWARE)
SI NO
DR
¿Se realiza?
2.1 DOCUMENTO DE REQUISITOS ¿Se realiza? (1) (0)

Figura 43. Formato y calificaciones para la valoración de procesos relacionados con el cliente (parte 2 de 2).
3. PRODUCTOS INFORMATIVOS PESO
SI NO
3.1 TITULO ¿Se identifica? (1) (0)
SI NO
3.2 NOMBRE DEL SOLICITANTE ¿Se identifica? (1) (0)
SI NO
3.3 SINOPSIS ¿Se identifica? (1) (0)
SI NO
3.4 REQUISITOS DE MAPAS ¿Se identifica? (1) (0)
SI NO
Productos Informativos
3.5 REQUISITOS DE IMAGEN ¿Se identifica? (1) (0)
SI NO
3.6 REQUISITOS DE ESQUEMAS ¿Se identifica? (1) (0)
SI NO
3.7 PASOS PARA LLEGAR AL PRODUCTO ¿Se identifica? (1) (0)
SI NO
3.8 FRECUENCIA DE USO ¿Se identifica? (1) (0)
SI NO
3.9 ASOCIACIONES LÓGICAS ¿Se identifica? (1) (0)
SI NO
3.10 ERRORES ¿Se identifica? (1) (0)
SI NO
3.11 ESPERA Y RESPUESTA ¿Se identifica? (1) (0)
SI NO
3.12 COSTO/BENEFICIOS ¿Se identifica? (1) (0)
4. CATEGORIZACIÓN DE REQUISITOS
SI NO
Categorización de
4.1 DE CALIDAD EN USO ¿Se identifica? (1) (0)
requisitos
SI NO
4.2 DE CALIDAD EXTERNA ¿Se identifica? (1) (0)
SI NO
4.3 DE CALIDAD INTERNA ¿Se identifica? (1) (0)
5. REVISIÓN DE LOS REQUISITOS
SI NO
DRR
¿Se realiza?
(1) (0)
5.1 DOCUMENTO DE REVISIÓN REQUISITOS ¿Se realiza?

6. COMUNICACIÓN CON EL CLIENTE
SI NO
6.1 REPRESENTANTE DEL CLIENTE ¿Se tiene? RC ¿Se tiene?
(1) (0)
141
Figura 44. Tabla de recomendaciones para la valoración de procesos relacionados con el

cliente (parte 1 de 2), según calificaciones.
RESULTADOS
(No calificable)

Deficiente La organización debe adoptar un modelo de calidad

0%<= X <= 50% para la realización del producto
Insuficiente La organización debe mejorar su modelo de calidad

50% < X < 7 5% para la realización del producto
Aceptable La organización debe reforzar los procesos con falencias

75%<= X <= 100% del modelo de calidad.
La organización debe La organización debe garantizar que

DR
implementar un documento de se diligencia el documento de

Figura 45. Tabla de recomendaciones para la valoración de procesos relacionados con el

cliente (parte 2 de 2), según calificaciones.
Deficiente La organización debe implementar un modelo de diseño

0%<= X <= 50,02% basado en productos informativos
Insuficiente La organización debe mejorar un modelo de diseño

50.2 < X < 7 4.97% basado en productos informativos
Aceptable La organización debe reforzar las falencias de su

74.97%<= X <= 100% modelo de diseño basado en productos informativos

Insuficiente La organización debe categorizar sus requisitos una vez
0%<= X <= 60% los encuentre.
Aceptable La organización debe mejorar la categorización a sus
60% < X <=1005% requisitos una vez los encuentre.
La organización debe
La organización debe garantizar que
implementar un documento de
se diligencia el documento de
DRR revisión de requisitos para
revisión de requisitos para asegurar
asegurar sus procesos de
sus procesos de desarrollo.
desarrollo.
La organización debe La organización debe garantizar que

RC
implementar un documento de se diligencia el documento de
143
Figura 46. Formato y calificaciones para la valoración de diseño y desarrollo.

M. FORMATO DE VALORACIÓN DE DISEÑO Y DESARROLLO
(No calificable)
1. PLANIFICACIÓN DEL DISEÑO Y DESARROLLO
SI NO
¿Se realiza?
1.1 LISTA MAESTRA DE DATOS DE ENTRADA (MIDL) ¿Se realiza? (1) (0) PESO
SI NO
¿Se realiza? 25%
1.1.1 IDENTIFICACIÓN DE DATOS ¿Se realiza? (1) (0)
MIDL
SI NO
¿Se realiza? 25%
1.1.2 CONSIDERACIONES ACERCA DE LA CANTIDAD DE DATOS ¿Se realiza? (1) (0)
SI NO
¿Se realiza? 25%
1.1.3 CARACTERÍSTICAS DE LOS DATOS ¿Se realiza? (1) (0)
SI NO
¿Se realiza? 25%
1.1.4 DISPONIBILIDAD Y COSTO DE LOS DATOS ¿Se realiza? (1) (0)
SI NO
PPI
¿Se realiza?
1.2 PRIORIZACIÓN DE LOS PRODUCTOS INFORMATIVOS ¿Se realiza? (1) (0)
SI NO
CPI
¿Se realiza?
1.3 CRONOGRAMA PARA PRODUCTOS INFORMATIVOS ¿Se realiza? (1) (0)
SI NO
CDR
¿Se realiza?
1.4 CONTROL DE DOCUMENTACIÓN Y REGISTROS ¿Se realiza? (1) (0)
2. ELEMENTOS DE ENTRADA PARA DISEÑO Y DESARROLLO
2.1 DATOS
SI NO
¿Se define? 25%
Cualidades sobre los

2.1.1 ESCALA DE LOS DATOS ¿Se define? (1) (0)
SI NO
¿Se define? 25%
datos
2.1.2 RESOLUCIÓN ¿Se define? (1) (0)
SI NO
¿Se define? 25%
2.1.3 PROYECCIÓN ¿Se define? (1) (0)
SI NO
¿Se define? 25%
2.1.4 TOLERANCIA AL ERROR ¿Se define? (1) (0)
2.2 ACTIVIDADES SOBRE LOS DATOS
2.2.1 IDENTIFICACIÓN DE DATOS QUE CUMPLEN SI NO
¿Se define? 16%
LOS REQUISITOS Y SUS FUENTES ¿Se define? (1) (0)
Actividades sobre los datos

SI NO
¿Se define? 18%
2.2.2 ESTÁNDARES DE INTEROPERABILIDAD ¿Se define? (1) (0)
SI NO
¿Se define? 16%
2.2.3 TOPOLOGÍA ¿Se define? (1) (0)
SI NO
¿Se define? 16%
2.2.4 CARTOGRAFÍA BASE ¿Se define? (1) (0)
SI NO
¿Se define? 16%
2.2.5 FUNCIONES ESPACIALES Y ANÁLISIS DE RED ¿Se define? (1) (0)
2.2.6 CORRECCIÓN DE AMBIGUEDADES, SI NO
¿Se define? 18%
CONTRADICCIONES ¿Se define? (1) (0)

Figura 47. Tabla de recomendaciones para la valoración de diseño y desarrollo.

(No calificable)

La organización debe La organización debe garantizar
implementar una MIDL para que se diligencia la MIDL para
MIDL
asegurar sus procesos de asegurar sus procesos de
desarrollo. desarrollo.
Deficiente La organización debe adoptar un modelo de

0%<= X <= 50% calidad para la realización del producto
50%< X < 75% calidad para la realización del producto
75%<= X <= 100% calidad para la realización del producto
PPI

CPI

CDR

Deficiente La organización debe definir las cualidades

0%<= X <= 50% requeridas sobre los datos en la fase de diseño.
La organización debe mejorar la definición de
Deficiente
las cualidades requeridas sobre los datos en la
50%< X < 75%
fase de diseño.
La organización debe garantizar que las
Deficiente
cualidades definidas son las requeridas sobre
75%<= X <= 100%
los datos en la fase de diseño.
Deficiente La organización debe definir las cualidades

0%<= X <= 48% requeridas sobre los datos en la fase de diseño.
La organización debe mejorar la definición de
Deficiente
las cualidades requeridas sobre los datos en la
48%< X < 84%
fase de diseño.
La organización debe garantizar que las
Deficiente
cualidades definidas son las requeridas sobre
84%<= X <= 100%
los datos en la fase de diseño.

Figura 48. Formato y calificaciones para la valoración de diseño y desarrollo (resultado).

N. FORMATO DE VALORACIÓN DE DISEÑO Y DESARROLLO (RESULTADOS)
(No calificable)
1. RESULTADOS DE DISEÑO Y DESARROLLO
SI NO
1.1 ESPECIFICACIONES DE DISEÑO ¿Se identifica? (1) (0)
SI NO

1.2 MODELO LÓGICO DE DATOS ¿Se identifica? (1) (0)
SI NO
1.3 CÓDIGO FUENTE ¿Se identifica? (1) (0)
SI NO
1.4 ARQUITECTURA DEL SIG ¿Se identifica? (1) (0)
SI NO
1.5 PRODUCTO SIG DESARROLLADO ¿Se identifica? (1) (0)
SI NO
1.6 DOCUMENTOS OPERATIVOS ¿Se identifica? (1) (0)
SI NO
1.7 DOCUMENTOS DE MANTENIMIENTO ¿Se identifica? (1) (0)
2. REVISIÓN DEL DISEÑO Y DESARROLLO
SI NO
2.1 FRECUENCIA DE REVISIÓN ¿Se identifica? (1) (0)
SI NO

2.2 QUE PRODUCTOS INFORMATIVOS SE REVISAN ¿Se identifica? (1) (0)
SI NO
2.3 COMO SE PLANIFICA LA REVISIÓN ¿Se identifica? (1) (0)
SI NO
2.4 QUE ELEMENTOS SE REQUIEREN PARA LA REVISIÓN ¿Se identifica? (1) (0)
SI NO
2.5 CRITERIOS DE ÉXITO O ACEPTACIÓN ¿Se identifica? (1) (0)
2.6 ACTIVIDADES DE SEGUMIENTO OBRE RESOLUCIÓN SI NO

DE PROBLEMAS ¿Se identifica? (1) (0)
3. VERIFICACIÓN DEL DISEÑO Y DESARROLLO
3.1 SE VERIFICA EL DISEÑO Y DESARROLLO

4. VALIDACIÓN DEL DISEÑO Y DESARROLLO
SI NO
¿Se realizan? 40,00%
Validación del
4.1 PRUEBAS UNITARIAS ¿Se realizan? (1) (0)
desarrollo
diseño y
SI NO
4.2 PRUEBAS DE INTEGRACIÓN ¿Se realizan? (1) (0)
SI NO
4.3 PRUEBAS DE CALIFICACIÓN Y ACEPTACIÓN DEL SIG ¿Se realizan? (1) (0)

Figura 49. Tabla de recomendaciones para la valoración de diseño y desarrollo (desarrollo).

(No calificable)

Deficiente La organización debe controlar los resultados de la fase

0%<= X <= 42% de diseño y desarrollo.
Deficiente La organización debe mejorar el control de los
42%< X < 71% resultados de la fase de diseño y desarrollo.
Deficiente La organización debe garantizar que los resultados de
71%<= X <= 100% diseño y desarrollo son controlados siempre.
Deficiente La organización debe definir un proceso de revisión de

0%<= X <= 48% los resultados de diseño y desarrollo.
Deficiente La organización debe mejorar el proceso de revisión de
48%< X < 84% los resultados de diseño y desarrollo.
Deficiente La organización debe garantizar que la revisión de los
84%<= X <= 100% resultados de diseño y desarrollo se cumple bajo los

Insuficiente La organización debe ejecutar pruebas de SW que le
0%<= X <= 60% permitan medir los resultados de diseño y desarrollo
Aceptable La organización debe ejecutar mejores pruebas de SW
60% < X <=1005% que le permitan medir los resultados de diseño y

Figura 50. Formato y calificaciones para la valoración de producción y prestación del servicio (parte 1 de 2).
O. FORMATO DE VALORACIÓN DE PRODUCCIÓN Y PRESTACIÓN DEL SERVICIO A
(No calificable)
1.1 CONTROL DE LA PRODUCCIÓN Y PRESTACIÓN DEL SERVICIO
SI NO
CLR
¿Se controla?
1.1 COMPILACIÓN, LIBERACIÓN Y REPRODUCCIÓN ¿Se controla? (1) (0)
SI NO
PPR
¿Se controla?
1.2 PUESTA EN PRODUCCIÓN ¿Se controla? (1) (0)
1.2.1 ASPECTOS ORGANIZACIONALES Y DE GESTIÓN
1.2.1.1 REQUISITOS DE INTERACCIÓN SI NO

¿Se controla? 16%
INTERINSTITUCIONAL ¿Se controla? (1) (0)
1.2.1.2 RESPONSABILIDADES, FUNCIONES Y SI NO

¿Se controla? 16%
OBLIGACIONES ¿Se controla? (1) (0)
1.2.1.3 ACUERDOS DE USO DE DATOS PARA EL SI NO
¿Se controla? 18%
SOFTWARE SIG ¿Se controla? (1) (0)
1.2.1.4 ACUERDOS DE ACCESO A LAS
SI NO
INSTALACIONES DEL CLIENTE Y DISPONIBILIDAD DEL ¿Se controla? 16%
(1) (0)
PERSONAL ¿Se controla?
1.2.1.5 REVISIÓN DE ASPECTOS LEGALES Y SI NO
¿Se controla? 16%
CONTRACTUALES ¿Se controla? (1) (0)
SI NO
¿Se controla? 18%
1.2.1.6 ANÁLISIS DE RIESGOS ¿Se controla? (1) (0)

Figura 51. Formato y calificaciones para la valoración de producción y prestación del servicio (parte 2 de 2).
1.2.2 ASPECTOS DE GESTIÓN DE LA CONFIGURACIÓN
SI NO
¿Se controla? 10%
(1) (0)
1.2.2.1 PLAN DE INSTALACIÓN ¿Se controla?
SI NO
1.2.2.2 DATOS Y REQUISITOS DE INFRAESTRUCTURA ¿Se controla? 9%
(1) (0)
DEL SIG EN AMBIENTE DE PRODUCCIÓN ¿Se controla?
SI NO
1.2.2.3 REQUISITOS DE ACCESO A EQUIPOS ¿Se controla? 9%
(1) (0)
(USUARIOS, CONTRASEÑAS, RED) ¿Se controla?
SI NO
¿Se controla? 9%
(1) (0)
1.2.2.4 REVISIÓN DE SEGURIDAD ¿Se controla?
Gestión de la configuración
SI NO
¿Se controla? 9%
(1) (0)
1.2.2.5 INTEGRACIÓN EL SISTEMA ¿Se controla?
SI NO
¿Se controla? 9%
(1) (0)
1.2.2.6 MIGRACIÓN DE DATOS PREVIOS ¿Se controla?
SI NO
1.2.2.7 CAPTURA DE DATOS Y POBLACIÓN DE LA ¿Se controla? 9%
(1) (0)
BASE DE DATOS ¿Se controla?
SI NO
¿Se controla? 9%
(1) (0)
1.2.2.8 COPIAS DE SEGURIDAD Y SU INTEGRIDAD ¿Se controla?
SI NO
¿Se controla? 9%
(1) (0)
1.2.2.9 GUÍAS O INSTRUCTIVOS DE INSTALACIÓN ¿Se controla?
SI NO
1.2.2.10 ENTRENAMIENTO RELACIONADO CON EL ¿Se controla? 9%
(1) (0)
USO EL SOFTWARE SIG DURANTE LA INSTALACIÓN ¿Se controla?
SI NO
¿Se controla? 9%
(1) (0)
1.2.2.11 PUESTA EN PRODUCCIÓN ¿Se controla?
149
Figura 52. Tabla recomendaciones para valoración de producción y prestación del servicio.

(No calificable)
Lista de relaciones calificación obtenida/recomendación por

aspecto.
La organización debe La organización debe

implementar un proceso mejorar el proceso de
CLR
de compilación, compilación, liberación y

liberación y reproducción reproducción
La organización debe La organización debe
PPR
implementar un proceso mejorar el proceso de

de puesta en producción puesta en producción
La organización debe definir un

Deficiente
proceso de revisión de los resultados
0%<= X <= 48%
de diseño y desarrollo.
La organización debe mejorar el

Deficiente
proceso de revisión de los resultados
48%< X < 84%
de diseño y desarrollo.

Deficiente
la revisión de los resultados de diseño
84%<= X <= 100%
y desarrollo se cumple bajo los
La organización debe definir un

Deficiente
proceso de gestión de la
0%<= X <= 45%
configuración.
La organización debe mejorar el
Deficiente
proceso de gestión de la
45%< X <75%
configuración.
Deficiente la gestión de configuación es
75%<= X <= 100% apropiada para todos los proyectos
de SIG

Figura 53. Formato y calificaciones para la valoración de producción y prestación del servicio (resultados).
P. FORMATO DE VALORACIÓN DE PRODUCCIÓN Y PRESTACIÓN DEL SERVICIO B
(No calificable)
1.1 CONTROL DE LA PRODUCCIÓN Y PRESTACIÓN DEL SERVICIO
SI NO
¿Se controla? 16%
(1) (0)
1.1.1 ALCANCE DEL MANTENIMIENTO ¿Se controla?
SI NO
Producción y prestación del servicio

1.1.2 IDENTIFICACIÓN DEL ESTADO INICIAL DEL ¿Se controla? 18%
(1) (0)
SOFTWARE SIG. ¿Se controla?
1.1.3 ACTIVIDADES DE RESOLUCIÓN DE
SI NO
PROBLEMAS, SOPORTE DE HARDWARE Y ¿Se controla? 16%
(1) (0)
SOFTWARE. ¿Se controla?
1.1.4 MODIFICACIONES AL SISTEMA Y ADICIONALES
SI NO
EN INTERFACES O COMPONENTES DE HARDWARE ¿Se controla? 16%
(1) (0)
(SI APLICAN). ¿Se controla?
1.1.5 ACTUALIZACIÓN DE LA GESTIÓN DE
SI NO
CONFIGURACIÓN, PRUEBAS Y ASEGURAMIENTO ¿Se controla? 16%
(1) (0)
DE LA CALIDAD. ¿Se controla?
SI NO
¿Se controla? 18%
(1) (0)
1.1.6 REGISTROS Y REPORTES DE MANTENIMIENTO. ¿Se controla?
1.2 VALIDACIÓN DE LOS PROCESOS DE PRODUCCIÓN Y DE LA PRESTACIÓN DEL SERVICIO
Validación de procesos de producción y prestación

SI NO
1.2.1 CRITERIOS DE VALIDACIÓN DE LA ¿Se controla? 20%
(1) (0)
IMPLEMENTACIÓN. ¿Se controla?
SI NO
1.2.2 APROBACIÓN DE LOS EQUIPOS Y EL ¿Se controla? 20%
(1) (0)
PERSONAL. ¿Se controla?
del servicio
SI NO
1.2.3 VERIFICACIÓN DE LOS REQUISITOS Y ¿Se controla? 20%
(1) (0)
PRODUCTOS INFORMATIVOS EN PRODUCCIÓN. ¿Se controla?
SI NO
1.2.4 REQUISITOS DE DOCUMENTACIÓN Y ¿Se controla? 20%
(1) (0)
REGISTROS. ¿Se controla?
SI NO
1.2.5 REVALIDACIÓN EL SOFTWARE SIG, DADOS ¿Se controla? 20%
(1) (0)
PROCEDIMIENTOS DE MANTENIMIENTO. ¿Se controla?

Figura 54. Tabla recomendaciones para valoración de producción y prestación del servicio
(resultados).

(No calificable)
Lista de relaciones calificación obtenida/recomendación por
La organización debe controlar y

Deficiente
gestionar la puesta en marcha del
0%<= X <= 48%
software y la prestación del servicio.
La organización debe mejorar y
Deficiente
gestionar la puesta en marcha del
48%< X < 84%
software y la prestación del servicio.
La organización debe mejorar y
Deficiente corregir las falencias de la puesta en
84%<= X <= 100% marcha del software y la prestación
del servicio.
La organización debe definir las

Deficiente
cualidades requeridas sobre los datos
0%<= X <= 40%
en la fase de diseño.
La organización debe mejorar la
Deficiente
definición de las cualidades requeridas
40%< X < 60%
sobre los datos en la fase de diseño.
Deficiente las cualidades definidas son las
60%<= X <= 100% requeridas sobre los datos en la fase
de diseño.

Figura 55. Formato y calificaciones para la valoración de medición, análisis y mejora (parte 1 e 2).
Q. FORMATO DE VALORACIÓN DE MEDICIÓN, ANÁLISIS Y MEJORA
(No calificable)
1. RESULTADOS DE SEGUIMIENTO Y MEDICIÓN
SI NO
¿Se mide? 12,50%
1.1 ADECUACIÓN FUNCIONAL (1) (0)
SI NO
¿Se mide? 12,50%
1.2 EFICIENCIA DE DESEMPEÑO (1) (0)
SI NO
¿Se mide? 12,50%
1.3 COMPATIBILIDAD (1) (0)
SI NO
¿Se mide? 12,50%
1.4 USABILIDAD (1) (0)
SI NO
¿Se mide? 12,50%
1.5 FIABILIDAD (1) (0)
SI NO
¿Se mide? 12,50%
1.6 SEGURIDAD (1) (0)
SI NO
¿Se mide? 12,50%
1.7 MANTENIBILIDAD (1) (0)
SI NO
¿Se mide? 12,50%
1.8 PORTABILIDAD (1) (0)

Figura 56. Formato y calificaciones para la valoración de medición, análisis y mejora (parte 2 e 2).
2. RESULTADOS DE ANÁLISIS DE DATOS Y MEJORA (ACCIONES CORRECTIVAS)
2.1 REVISAR LAS NO CONFORMIDADES SI NO
¿Se mide? 16%
(INCLUYENDO QUEJAS DE LOS CLIENTES). (1) (0)
2.2 DETERMINAR LAS CAUSAS DE LAS NO SI NO
¿Se mide? 18%

CONFORMIDADES. (1) (0)
2.3 EVALUAR LA NECESIDAD DE ADOPTAR
SI NO
ACCIONES PARA ASEGURARSE DE QUE LAS NO ¿Se mide? 16%
(1) (0)
CONFORMIDADES NO VUELVAN A OCURRIR
2.4 DETERMINAR E IMPLEMENTAR LAS ACCIONES SI NO
¿Se mide? 16%
NECESARIAS. (1) (0)
2.5 REGISTRAR LOS RESULTADOS DE LAS ACCIONES SI NO
¿Se mide? 16%
TOMADAS. (1) (0)
2.6 REVISAR LAS ACCIONES CORRECTIVAS SI NO
¿Se mide? 18%
TOMADAS. (1) (0)
3. RESULTADOS DE ANÁLISIS DE DATOS Y MEJORA (ACCIONES PREVENTIVAS)
3.1 DETERMINAR LAS NO CONFORMIDADES SI NO
Validación de procesos de producción y

¿Se mide? 20%
POTENCIALES Y SUS CAUSAS. (1) (0)
3.2 EVALUAR LA NECESIDAD DE ACTUAR PARA
prestación del servicio

PREVENIR LA OCURRENCIA DE NO
SI NO
CONFORMIDADES (CAMBIOS EN PROCESOS ¿Se mide? 20%
(1) (0)
PREVIOS A LA PRODUCCIÓN Y PRESTACIÓN EL
SERVICIO O SOFTWARE SIG).
3.3 DETERMINAR E IMPLEMENTAR LAS ACCIONES SI NO
¿Se mide? 20%
NECESARIAS. (1) (0)
3.4 REGISTRAR LOS RESULTADOS DE LAS ACCIONES SI NO
¿Se mide? 20%
TOMADAS. (1) (0)
3.5 REVISAR LAS ACCIONES PREVENTIVAS SI NO
¿Se mide? 20%
ADOPTADAS. (1) (0)
154
Figura 57. Tabla recomendaciones para valoración de medición, análisis y mejora.

RESULTADOS
(No calificable)

Deficiente La organización debe adoptar un modelo de medición y

0%<= X <= 50% seguimiento
Insuficiente La organización debe mejorar el modelo de medición y

50% < X < 7 5% seguimiento
Aceptable La organización debe reforzar los procesos de medición y

75%<= X <= 100% seguimiento con falencias del modelo de calidad.
Deficiente La organización debe definir la responsabilidad de implementar

0%<= X <= 48% acciones corectivas con su respectiva gestión
Deficiente La organización debe gestionar que se realicen las acciones

48%< X < 84% corectivas
Deficiente La organización debe documentar la aplicación delas acciones

84%<= X <= 100% correctivas para su posterior análisis
Deficiente La organización debe definir la responsabilidad de implementar

0%<= X <= 40% acciones preventivas con su respectiva gestión
Deficiente La organización debe gestionar que se realicen las acciones

40%< X < 60% preventivas
Deficiente La organización debe documentar la aplicación delas acciones
60%<= X <= 100% preventivas para su posterior análisis

ANEXO G: CARTA DE CIERRE
Modelo de carta de cierre por parte de la alta dirección oficializando el

proceso de evaluación por parte del equipo y permite la comunicación a
todos los interesados.
Figura 58. Modelo para carta de cierre.

Fecha, Ciudad
Saludo, (información completa a quien se dirige la autorización).
Yo, NOMBRE COMPLETO DE QUIEN EMITE LA NOTIFICACIÓN, identificado

con documento (especifique el tipo de documento) No. XXXXXXXXXX de la
Ciudad de ____________________, obrando en mi calidad de CARGO DE
QUIEN EMITE LA NOTIFICACIÓN notifico que las actividades asociadas a la
emisión del concepto técnico enmarcado en el modelo de aplicación la NTC-
ISO/IEC 90003 al desarrollo de software de los SIG, han sido debidamente
terminadas.
Posterior a este cierre de actividades, los evaluadores se comprometen a no filtrar

o divulgar información que atente contra la integridad o buen nombre de nuestra
área u organización.
Atentamente,
Espacio para firma: ____________________

NOMBRE COMPLETO DE QUIEN OTORGA LA AUTOIZACIÓN:
Cargo de quien otorga la autorización:
Nombre de la organización:

NOMBRE EVALUADOR 1

NOMBRE EVALUADOR 2
156

Moreno Giraldo Carlos Andres Ruiz Zambrano Diego Giovanni 2016 EJEMPLO90003

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Moreno Giraldo Carlos Andres Ruiz Zambrano Diego Giovanni 2016 EJEMPLO90003

Uploaded by

Copyright:

Available Formats

Universidad Distrital

Francisco José de Caldas

MODELO DE APLICACIÓN DE LA NTC-ISO/IEC 90003 AL

CARLOS ANDRÉS MORENO GIRALDO

DIEGO GIOVANNI RUIZ ZAMBRANO

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

MODELO DE APLICACIÓN DE LA NTC-ISO/IEC 90003 AL DESARROLLO DE

CARLOS ANDRÉS MORENO GIRALDO Cód. 20031020091

DIEGO GIOVANNI RUIZ ZAMBRANO Cód. 20031020107

MSc. JUAN MANUEL HIGUERA

MSc. LUIS EMILIO MONTENEGRO

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

Firma del Jurado

Bogotá D.C. 19 de septiembre de 2016

A la Universidad Distrital Francisco José de Caldas y en especial al Proyecto

1. MODELO DE APLICACIÓN DE LA NTC-ISO/IEC 90003 AL DESARROLLO

2. REQUISITOS PARA LA APLICACIÓN DE LA NORMA NTC-ISO/IEC 90003

2.2.3. Evaluación del manual de calidad ........................................................... 28

3. ENFOQUE DE LA NTC-ISO/IEC 90003 AL DESARROLLO DE SOFTWARE

3.2.3. Comunicación con el cliente .................................................................... 57

4. APLICACIÓN DEL MODELO......................................................................... 78

CONCLUSIONES ................................................................................................ 105

BIBLIOGRAFÍA ................................................................................................... 107

GLOSARIO .......................................................................................................... 111

ANEXO A: MAPA MENTAL DEL PROYECTO ................................................... 115

ANEXO B: INDICE DE FORMATOS ................................................................... 116

ANEXO C: CARTA DE AUTORIZACIÓN ........................................................... 118

ANEXO D: FORMATOS DE CARACTERIZACIÓN ............................................ 119

ANEXO E: FORMATOS DE SEGUIMIENTO Y MEDICIÓN DE LOS REQUISITOS

ANEXO F: FORMATOS DE SEGUIMIENTO Y MEDICIÓN PARA EL ENFOQUE

ANEXO G: CARTA DE CIERRE ......................................................................... 156

Tabla 1. Puntos de la norma NTC-ISO/IEC 90003. ............................................... 14

Figura 1. Diagrama de Alcance................................................................................ 8

Figura 22. Formato de planificación y preparación. ............................................. 120

Figura 44. Tabla de recomendaciones para la valoración de procesos relacionados

La característica principal de los Sistemas de Información Geográfica (SIG),

De acuerdo con lo anterior, el Modelo de Aplicación de la NTC-ISO/IEC1

El modelo de aplicación ofrece herramientas congruentes y una base común

Para hacer esto posible, el Modelo se sustenta en tres fases: preparación,

En la preparación (capítulo 2), se establecen los requisitos necesarios para la

1. MODELO DE APLICACIÓN DE LA NTC-ISO/IEC 90003 AL

En este capítulo se hace una descripción de la esencia del proyecto, a qué

1.1. FORMULACIÓN DEL PROBLEMA

Los Sistemas de Información Geográfica poseen características propias que

Un marco de referencia, que integre elementos de calidad ceñidos a un

de planeación de una organización. Adicionalmente permitiría tener un

En un proyecto de desarrollo de software de los Sistemas de Información

Además del punto anterior, los SIG deben responder al llamado de la

objetivos “Implementar el Sistema de Gestión de Calidad para mejorar la

Por otra parte, en el contexto nacional, según inspecciones previas dentro de

Por estas razones, este trabajo académico busca establecer un mecanismo

1.3.1. Objetivo general

Diseñar e implementar una guía de aplicación de la norma NTC-ISO/IEC

1.3.2. Objetivos específicos

 Realizar la recopilación y análisis de las características de software de

 Adoptar el modelo de calidad de producto de software contemplado en el

 Establecer los requisitos de calidad para construir software,

 Delimitar metodologías, técnicas y buenas prácticas utilizadas en el

 Proporcionar un punto de referencia para la implementación del Sistema

1.4. ALCANCES Y LIMITACIONES

El Modelo de Aplicación de la NTC-ISO/IEC 90003 al desarrollo de software

No pretende ser un resumen que homologa los conceptos de los distintos

El desarrollo del modelo tiene planeado estructurar una metodología acorde