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

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



ii

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



iii

Nota de Aceptación:

Firma del Jurado

Bogotá D.C. 19 de septiembre de 2016



iv

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.



v

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



vi

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



vii

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



viii

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



ix

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



x

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



xi

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



xii

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



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 ISO. Software engineering ─ Software product Quality Requirements and Evaluation

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



2

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]

http://www.icde.org.co/web/guest/que_es_icde



3

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.



4

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.

http://www.icde.org.co/web/guest/mejorar_capacidad_institucional



5

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 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. 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].

http://www.igac.gov.co/



6

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.



7

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.



8

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.



9

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.



10

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.



11

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.



12

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



13

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

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.



14

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

4.1 REQUISITOS GENERALES Identificación, aplicación de procesos de software

Secuencia de interacción de procesos

4.2 REQUISITOS DE

DOCUMENTACIÓN

Generalidades

Manual de calidad

Control de documentos

Control de registros

5. RESPONSABILIDAD DE LA DIRECCIÓN

5.1 COMPROMISOS

Política de calidad

Establecimiento de los objetivos de calidad

Revisiones

Disponibilidad de recursos

5.2 ENFOQUE AL CLIENTE Cumplimiento de requerimientos del cliente

5.3 POLÍTICA DE CALIDAD La alta dirección debe procurar que la política de

calidad sea adecuada

5.4 PLANIFICACIÓN Objetivos de calidad

Planificación del sistema de gestión de calidad

5.5 RESPONSABILIDAD,

AUTORIDAD Y COMUNICACIÓN

Responsabilidad y autoridad

Representante de la dirección

Comunicación interna



15

5.6 REVISIÓN POR LA DIRECCIÓN Información para revisió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

6.3 INFRAESTRUCTURA

Edificios, espacio de trabajo y servicios asociados

Equipo para los procesos (hardware, software)

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

7.1 PLANIFICACIÓN DELA

REALIZACIÓN DEL PRODUCTO

Ciclo de vida del software

Planificación de la calidad

7.2 PROCESOS RELACIONADOS

CON EL CLIENTE

Determinación de los requisitos relacionados con

el producto

Revisión de los requisitos relacionados con el

producto

Comunicación con el cliente

7.3 DISEÑO Y DESARROLLO

Planificación

Elementos de entrada para el diseño y desarrollo

Resultados del 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

7.4 COMPRAS

Proceso de compras

Información sobre compras

Verificación de los productos comprados



16

7.5 PRODUCCIÓN Y PRESTACIÓN

DEL SERVICIO

Control

Validación de los procesos de producción y

prestación 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

8.2 SEGUIMIENTO Y MEDICIÓN

Satisfacción del cliente

Auditoría interna

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

8.5 MEJORA

Mejora continua

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.



17

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.



18

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

ISO. Software engineering ─ Software product Quality Requirements and Evaluation

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


(SQuaRE) ─ Quality requirements. ISO; 2007. 44p. ISO/IEC 25030.



19

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.



20

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,



21

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.


19

COBIT, Control Objectives for Information and related Technology. ISACA, 2012.

Abstracción

Cobit 5.0

ISO 25000

Modelo

Abstracción

Aplicación

SIG

SMBD y Datos

Procedimientos

Hardware

Personal

Software

CICLO DE VIDA

Planeación

Análisis

Diseño

Pruebas

Implantación

Mantenimiento

NTC-ISO/IEC 90003

Recursos

Seguimiento y Medición

Realización Del

Producto

SGC



22

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

evaluación

1.1 Análisis de Requerimientos

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.



23

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.



24

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.




25

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.



26

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.



27

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



28

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.



29

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.



30

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.



31

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.



32

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.



33

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.



34

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.



35

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



36

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



37

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,



38

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.



39

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



40

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:



41

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.



42

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.



43

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:



44

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



45

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.



46

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.



47

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.



48

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.



49

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



50

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




51

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.



52

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.



53

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.



54

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.

Requ

erim

ien

tos d

el S

IG

Requ

erim

ien

tos d

e s

oftw

are

SIG

Requisitos

del producto

de software

SIG

Requisitos

inherentes

Requisitos funcionales: mapas, imágenes,

esquemas de datos espaciales, demanda de

uso, funcionalidades espaciales.

Requisitos

de calidad de

software

De calidad en uso: Tiempos

de respuesta adecuados

para funcionalidades

espaciales.

De calidad externa (caja

negra): Tolerancia a errores.

De calidad interna (caja

blanca): Metodología de

desarrollo

Requisitos

de

propiedades

del software

Requisitos administrativos al interior de la

organización que desarrolla el SIG.

Requisitos contractuales con el cliente.

Entregables para el cliente: Visor geográfico,

servicios Web de mapas, base de datos

geográfica.



55

Requisitos

de desarrollo

de software

SIG

Requisitos del proceso de desarrollo: Plataforma de

desarrollo alfanumérica, plataforma de visualización

geográfica, arquitectura de los servicios Web geográficos,

modelo y plataforma de base de datos espacial.

Requisitos organizacionales de desarrollo: Manuales de

desarrollo SIG, roles del proceso de desarrollo, revisión,

verificación y validación.

Otr

os

requis

itos

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.



56

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.



57

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.




58

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.



59

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

Identificación de los datos geográficos

Nombre del conjunto de datos

ID del conjunto de datos

Organización de origen

URL del servicio Web geográfico

Metadatos disponibles

Consideraciones acerca de la cantidad de datos

geográficos

Formato de los datos digitales

Volumen de los datos

Características de los datos geográficos

Escala

Tipo

Datum

Texto alfanumérico.

Disponibilidad y costo de los datos geográficos

Derechos

Costo de adquisición

Restricciones de uso

Fuente: Adaptación de los autores. TOMLINSON Roger. Pensando en el SIG. 3 ed. P. 62.



60

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



61

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.



62

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.



63

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.



64

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 ICDE26.

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].



65

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



66

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?



67

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.



68

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



69

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



70

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.




71

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.



72

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




73

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

temporal

Despliegue rápido de mapas (capas) y de servicios Web

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

errores de usuario

Manejo de errores al ejecutar operaciones alfanuméricas y

geográficas. Por ejemplo: escala del mapa no disponible,

datos no encontrados en una consulta espacial, parámetros no



74

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

recuperación

El software SIG puede ser restablecido a un estado previo si

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



75

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

modificado

Sin degradar el desempeño en visualización y análisis, el

software SIG podrá ser modificado (corrección o mejora).

Capacidad de ser

probado

Se pueden establecer criterios de prueba para el software SIG:

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

instalación

El software SIG y sus bases de datos espaciales se despliega

fácilmente en entorno de producción.

Capacidad de ser

reemplazado

Las plataformas de visualización y de análisis geográfico sobre

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



76

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.



77

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.




78

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



79

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:

1.10 ORGANIGRAMA. *Anexe el organigrama de la compañía, identificando 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



80

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á



81

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

PROYECTO: FASE

ACTUAL:

FECHA DE ELABORACIÓN:

DD-MM-AAAA

LIDER:

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



82

4. CRONOGRAMA BASE

FASE EVALUACIÓN FECHA INICIAL FECHA FINAL

PREPARACIÓN (Fecha inicial

estipulada en la carta de autorización)

SGC

DESARROLLO (Fecha final estipulada en la carta

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].

https://www.isotools.org/2015/02/20/en-que-consiste-el-ciclo-phva-de-mejora-continua



83

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.



84

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Ó:




85

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.



86

Figura 17. Énfasis de los pilares conceptuales de la NTC-ISO 90003 en cada fase de

desarrollo de 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.

Análisis de Requerimientos

Diseño Conceptual

Evaluación de los datos disponibles

Evaluación del software y del

hardware

Planificación y diseño de la BD

Construcción de la BD

Integración del SIG

Desarrollo de aplicaciones

Uso y mantenimiento del SIG

SGC y Gestión de recursos

Medición, análisis y mejora

Gestión de recursos

Realización del producto

http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/206



87

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.



88

En la Tabla 12 se recopilan las responsabilidades básicas de los

involucrados.

Tabla 12. Responsabilidades básicas de los involucrados.

ROL RESPONSABILIDADES

EVALUADOR LIDER

Elaboración Formato inicial

Asignación de responsabilidades a los evaluadores de apoyo

Revisión de formatos diligenciados por los evaluadores de apoyo

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

EVALUADOR DE APOYO

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 líder

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

REPRESENTANTE DE LA DIRECCIÓN

Interlocución directa con el evaluador líder

Gestionar los espacios y recursos necesarios al interior de la organización

Dar acceso a las evidencias solicitadas por los evaluadores

Brindar la información pertinente a los evaluadores

Recibir el dictamen final y ponerlo en conocimiento de la dirección



89

Ejecutar las recomendaciones producto de la evaluación que estén a su alcance

COLABORADOR

Dar acceso a las evidencias de su proceso solicitadas por los evaluadores

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 ELABORACIÓN:

DD-MM-AAAA LIDER:

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



90

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].

http://www.isaca.org/



91

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 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?



92

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?



93

3.4 ¿CÓMO SE REGISTRAN LOS CAMBIOS EFECTUADOS AL SIG

DURANTE SUS FASES?


4.1 ¿CÓMO SE MIDE LA 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.



94

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

ELABORACIÓN:

DD-MM-AAAA LÍDER:

1.FORMATOS CT

2. SGC

2.1 ¿QUÉ ASPECTOS

CONSIDERAN EN LA

PLANIFICACIÓN DE LA CALIDAD

DEL DESARROLLO DE SIG?

Transcriba notas de la evaluación + Revisión del

numeral 3.1 de la metodología

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?





95

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?

Transcriba notas de la evaluación+ Revisión del


3.2 ¿CÓMO SE DETERMINA LA

CORRECTA ASIGNACIÓN DE

RECURSOS?



3.3 ¿CÓMO SE MIDE LA

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

ASPECTOS METODOLÓGICOS

CON LOS QUE SE DESARROLLA

EL SIG?





96

4.3 ¿CÓMO SE DERTERMINAN LOS

REQUISITOS DEL CLIENTE?




REQUISITOS DEL PRODUCTO?


numeral 3.2.2 de la metodología

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 EFECTUADOS AL SIG

DURANTE SUS FASES?




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

IMPLEMENTACIÓN DEL SIG?



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?






97

Tabla 16. Niveles de resultado posible para cada registro de la entrevista inicial.

PRE-NIVEL (1)

NIVEL BÁSICO (2)

NIVEL MEDIO (3)

NIVEL ACEPTABLE

(4)

NIVEL SATISFACTORIO

(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.



98

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.



99

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



100

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 caracterización)

Formatos A, B, C y D (Validación)

Formato E (Dictamen)

Formatos EF (de seguimiento y medición para el enfoque de la NTC-ISO/IEC 90003)

Formatos K, L, M, N, O, P y Q (Dictamen)

Formatos RQ (de seguimiento y medición de los requisitos para la aplicación de la NTC-

ISO/IEC 90003)

Formatos F, G, H, I y J (Dictamen)

Documentos de Apoyo

Carta de autorización Carta de cierre Otros



101

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.




102

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.



103

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.



104

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.



105

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.



106

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.



107

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.



108

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.

http://www.icde.org.co/web/guest/mejorar_capacidad_institucional

http://www.icde.org.co/web/guest/estandares_datos

http://www.igac.gov.co/



109


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].



http://iso25000.com/index.php/normas-iso-25000/iso-25010



110

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.



111

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.



112

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.



113

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.



114

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.



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

Formato RQ Dictamen Formato para la valoración de responsabilidad de la dirección

Formato RQ Dictamen Formato para la valoración de gestión de los recursos

Formato EF Dictamen Formato para la valoración de planificación de realización del producto

Formato EF Dictamen Formato para la valoración de procesos relacionados con el cliente

Formato EF Dictamen Formato para la valoración de diseño y desarrollo

Formato EF Dictamen Formato para la valoración de diseño y desarrollo (resultado)

Formato EF Dictamen Formato para la valoración de



117

producción y prestación del servicio

Formato EF Dictamen Formato para la valoración de producción y prestación del servicio (resultados)

Formato EF Dictamen Formato para la valoración de medición, análisis y mejora

Plantilla Apoyo N/A Carta de cierre Fuente: Los Autores.



118

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.




119

ANEXO D: FORMATOS DE CARACTERIZACIÓN

Figura 21. Formato inicial.


1.1 EMPRESA:


1.4 FECHA DE ELABORACIÓN:

1.6 ENTREVISTADO:

1.10 ORGANIGRAMA.


A. FORMATO INICIAL

1.2 SECTOR:

1. DATOS BÁSICOS DE LA ORGANIZACIÓN

DD-MM-AAAA 1.5 LIDER:

1.8 MISIÓN DE LA ORGANIZACIÓN:

1.7 CARGO:

ELABORÓ: REVISÓ:

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)

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.



120

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


ÁREA JEFE O SUPERIOR JEFE O SUPERIOR HORARIO

TELÉFONO CONTACTO

FECHA DE ELABORACIÓN: DD-MM-AAAA

DESARROLLO

(Fecha inicial estipulada en la carta de

autorización)

(Fecha final estipulada en la carta de

autorización)

ELABORÓ: REVISÓ:

4. CRONOGRAMA BASE

FASE EVALUACIÓN FECHA FINALFECHA INICIAL

PREPARACIÓN

SGC

DESCRIPCIÓN DIRECCIÓN HORARIO

3. DIRECTORIO DE SITIOS CLAVE


B. FORMATO DE PLANIFICACIÓN Y PREPARACIÓN

2. LISTADO DE PERSONAL CLAVE

CARGONOMBRE

1. PROYECTO A EVALUAR

PROYECTO: FASE ACTUAL:

LIDER:



121

Figura 23. Formato de identificación y priorización de requerimientos.



3. OTROS REQUERIMIENTOS

ELABORÓ: REVISÓ:

2. REQUERIMIENTOS PROPIOS DE LA NORMA










C. IDENTIFICACIÓN Y PRIORIZACIÓN DE REQUERIMIENTOS

1. REQUERIMIENTOS PROPIOS DE EVALUACIÓN

LIDER:FECHA DE ELABORACIÓN: DD-MM-AAAA



122

Figura 24. Formato de selección del equipo.


ELABORÓ: REVISÓ:

2.3 COLABORADOR

2.4 COLABORADOR

2.5 COLABORADOR

1. EQUIPO DE COLABORADORES

2.1 REPRESENTANTE DE LA DIRECCIÓN

2.2 COLABORADOR





D. SELECCIÓN DEL EQUIPO

1. EQUIPO DE EVALUADORES

1.1 EVALUADOR LÍDER


LIDER:DD-MM-AAAAFECHA DE ELABORACIÓN:



123

Figura 25. Formato de entrevista inicial (parte 1 de 2).


2.5 ¿CÓMO SE DETERMINA LA COMPETENCIA

DEL PERSONAL QUE PARTICIPA EN EL

DESARROLLO DEL SIG?

2.7 ¿EN QUE ASPECTOS DEL DESARROLLO DE

SIG PARTICIPA LA DIRECCIÓN?

3.3 ¿CÓMO SE MIDE LA EFECTIVIDAD DE LA


3.2 ¿CÓMO SE DETERMINA LA CORRECTA


DD-MM-AAAA

2.4 ¿CÓMO DETERMINAN LAS

INTERACCIONES ENTRE LOS PROCESOS?

2.3 ¿CÓMO MIDEN LA COMPLEJIDAD DE LOS

PROCESOS?

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.6 ¿DE QUE FORMA GESTIONAN LA

DOCUMENTACIÓN ASOCIADA AL

DESARROLLO DE SIG?


3.1 ¿CÓMO SE REALIZA LA ASIGNACIÓN DE

LOS RECURSOS?


E. ENTREVISTA INICIAL

2. SGC

1.3 NOMBRE ENTREVISTADO

1.4 CARGO ENTREVISTADO

1.5 NOMBRE ENTREVISTADOR

1.6 CARGO ENTREVISTADOR

1. GENERALES

1.1 FECHA DE ELABORACIÓN 1.2 LUGAR DE ELABORACIÓN



124

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


5.4 ¿CÓMO SE ASIGNAN LAS

RESPONSABILIDADES DE EJECUCIÓN SOBRE

LAS MEJORAS PARA EL SIG?

4.6 ¿CÓMO SE REGISTRAN LOS CAMBIOS


5.3 ¿QUÉ CRITERIOS PERMITEN LA

PRORIZACIÓN DE MEJORAS SOBRE EL SIG?

5.2 ¿QUÉ MECANISMOS DE COMUNICACIÓN

EXISTEN CON EL CLIENTE LUEGO DE LA

IMPLEMENTACIÓN DEL SIG?

ELABORÓ: REVISÓ:

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 PRODUCTO?

5.1 ¿CÓMO SE MIDE LA SATISFACCIÓN DEL

CLIENTE CON EL SIG UNA VEZ DESPLEGADO?

4.5 ¿CÓMO SE REALIZA EL SEGUIMIENTO A

LAS ACCIONES QUE REALIZAN LOS QUE

INTERVIENEN EN EL DESARROLLO DEL SIG?


REQUISITOS DEL CLIENTE?




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.


1.1 EMPRESA:


1.4 FECHA DE ELABORACIÓN:

3.1.1 EQUIPO RESPONSABLE DEL

PROYECTO:

3.2 MÓDELO DE CICLO DE VIDA APLICADO:SI

(1)

NO

(0)

3.3.1 FASE DEL MODELO ACTUAL:

3.3.2 FASE DEL MODELO SIGUIENTE:

3.4.1 FASE METODOLOGÍA ACTUAL:

3.4.2 FASE METODOLOGÍA SIGUIENTE:


A. FORMATO DE CARACTERIZACIÓN DEL SISTEMA DE GESTIÓN DE CALIDAD

1. DATOS BÁSICOS

1.2 SECTOR:

1.5 ELABORÓ:

1.6 OBJETIVO DEL SIG:

(Marco legal, comercial y/o técnico).

2. SISTEMA DE GESTIÓN DE LA CALIDAD

IDENTIFICACIÓN DE ELEMENTOS DEL

SISTEMA DE GESTIÓN DE LA CALIDAD

ESTRATEGIAS:

PROCESOS:

RECURSOS:

3. IDENTIFICACIÓN DE PROCESOS DE SOFTWARE

3.1.2 NÚMERO DE INTEGRANTES:

3.3 LISTA SECUENCIAL DE PROCESOS

ESTRUCTURA

ORGANIZACIONAL:

DOCUMENTOS:

3.5 DOCUMENTACIÓN DE REFERENCIA:

3.4 METODOLOGÍA DE DESARROLLO:

Niv

el d

e cu

mp

limie

nto

Pes

o p

or

com

po

nen

te

¿Cada ítem está claramente identificado, definido y documentado?

Caracterización del proyecto

(No calificable)

CALIFICACIONES

20%

20%

20%

20%

20%

Parcialmente

(3)

Totalmente

(5)

Parcialmente

(3)

Totalmente

(5)

Totalmente

(5)

Parcialmente

(3)

¿Se identifica?

¿Se identifica?

Calificación obtenida = ∑(Nivel de cumplimiento*Peso por componente)

Totalmente

(5)

Parcialmente

(3)

Totalmente

(5)

No

(1)

No

(1)

No

(1)

No

(1)

No

(1)

Parcialmente

(3)

Calificación obtenida = ∑(Peso por componente)R

equ

isit

os

de

des

arro

llo

¿Se identifica?SI

(1)

NO

(0)

SI

(1)

NO

(0)



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

Inexistente

1 <= X <= 2,6

Insuficiente

2,6 < X <= 3,4

Por mejorar

3,4 < X <= 4,6

Óptimo

x = 5


Recomendación

No existe un SGC claro en la compañía, debe incluirse en los

proyectos de mejoramiento de la compañía desde la alta dirección.

Existe un SGC, pero sin el suficiente arraigo en la organización,

deben mejorarse todos los aspectos de baja puntuación.

La compañía esta cerca de un SGC, confiable se debe reforzar el

aspecto más bajo como prioridad

La compañía cuenta con un SGC autosostenible, con tendencia a la

mejora contínua implementada que debe ser monitoreado.

Rango de Calificación X Recomendación

1Se debe implementar una política de desarrollo de software

urgente.

2Se debe mejorar el aspecto más bajo para incluirlo dentro de la

política de desarrollo de software.

3Se debe garantizar y registrar el cumplimiento de la política de

desarrollo de software.



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


Pro

ceso

s d

e co

ntr

ol d

e d

ocu

men

tos

¿Se identifica?

SI

(1)

NO

(0)

SI

(1)

NO

(0)

SI

(1)

NO

(0)

SI

(1)

NO

(0)

SI

(1)

NO

(0)

SI

(1)

NO

(0)

SI

(1)

NO

(0)

Niv

el d

e

cum

plim

ien

to


No

(1)

Parcialmente

(3)

Totalmente

(5)30%

No

(1)

Parcialmente

(3)

Totalmente

(5)40%

No

(1)

Parcialmente

(3)

Totalmente

(5)30%

Niv

el d

e cu

mp

limie

nto

20%

No

(1)

Parcialmente

(3)

Totalmente

(5)20%

No

(1)

Parcialmente

(3)

Totalmente

(5)20%

Niv

el d

e cu

mp

limie

nto

Totalmente

(5)20%

No

(1)

Parcialmente

(3)

Totalmente

(5)20%

No

(1)

Parcialmente

(3)

Totalmente

(5)20%

No

(1)

Parcialmente

(3)

Totalmente

(5)20%

No

(1)

Parcialmente

(3)

Totalmente

(5)20%

No

(1)

Parcialmente

(3)

Totalmente

(5)

CALIFICACIONES

No

(1)

Parcialmente

(3)

Totalmente

(5)20%


No

(1)

Parcialmente

(3)

Totalmente

(5)20%

No

(1)

Parcialmente

(3)


B. FORMATO DE VALORACIÓN DE REQUISITOS DE CALIDAD

1. VALORACIÓN DE REQUISITOS DE DOCUMENTACIÓN

1.1 DESCRIPCIÓN DOCUMENTACIÓN

DE POLÍTICAS DE CALIDAD

1.1.1 POLÍTICA Y OBJETIVOS DE CALIDAD

1.1.2 MANUAL DE CALIDAD

1.1.3 PROCEDIMIENTOS ISO 9001:2000

DOCUMENTADOS

1.1.4 DOCUMENTOS DE LA ORGANIZACIÓN

1.1.5 REGISTROS REQUERIDOS POR LA NORMA

1.2 PROCESOS DE SOFTWARE

1.2.1 DESCRIPCIONES DE LOS PROCESOS

1.2.2 DESCRIPCIONES SOBRE

PROCEDIMIENTOS Y/O PLANTILLAS

1.2.3 DESCRIPCIONES DE MODELO DE CICLO DE

VIDA USADO

1.2.4 HERRAMIENTAS, TÉCNICAS,

TECNOLOGÍAS Y MÉTODOS

1.2.5 NORMAS O RECURSOS GUÍA PARA

PRUEBAS

2. VALORACIÓN DEL MANUAL DE CALIDAD

2.1 ALCANCE DEL SISTEMA DE GESTIÓN DE LA

CALIDAD

2.2 PROCEDIMIENTOS DOCUMENTADOS

ESTABLECIDOS

2.3 INTERACCIÓN ENTRE PROCESOS DEL SGC

3. CONTROL DE DOCUMENTOS

3.1 APROBACIÓN DE DOCUMENTOS ANTES DE SU

EMISIÓN

3.2 REVISIÓN Y ACTUALIZACIÓN DE DOCUMENTOS

3.3 CONTROL DE CAMBIOS Y ESTADO ACTUAL

3.4 CONTROL DE VERSIONES DE DOCUMENTOS

3.7 CONTROL DE DOCUMENTOS OBSOLETOS

3.5 PRESERVACIÓN DE LOS DOCUMENTOS

3.6 CONTROL DE DOCUMENTOS EXTERNOS



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

calificaciones.




1 <= x < 3 Se debe implementar una política de desarrollo de software urgente.

3 <= x < 5Se debe mejorar el aspecto más bajo para incluirlo dentro de la política

de desarrollo de software.

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

desarrollo de software.

Inexistente

1 <= X <= 3

No existe manual de calidad en la compañía, debe implementarse como

plan demejora desde la alta dirección.

Insuficiente

3 < X <= 4,7

Los componentes no conformes, deben ser mejorados como medida

dese la alta dirección.

Conforme

4,7 < X <= 5

El manual de calidad existente debe ser objeto de monitorización para

garantizar su compatibilidad con las políticas corporativas..

RESULTADOS



Inexistente

1 <= X <= 2,6

No existe documentación que soporte la poítica de calidad, debe

incluirse en los proyectos de mejoramiento de la compañía desde la alta

Insuficiente

2,6 < X <= 3,4

La documentación existente es insuficiente, deben mejorarse los

aspectos con la calificación más baja.

Por mejorar

3,4 < X <= 4,6

La documentación abarca todos los requisitos necesarios de manera

parcial, deben mejorarse los aspectos de calificación más baja.

Óptimo

x = 5

La compañía cuenta con mecanismos que soportan todos los requsitos

documentales de la norma.


Inexistente

1 <= X <= 2,6

No existe documentación que soporte la poítica de calidad, debe

incluirse en los proyectos de mejoramiento de la compañía desde la alta

Insuficiente

2,6 < X <= 3,4

La documentación existente es insuficiente, deben mejorarse los

aspectos con la calificación más baja.

Por mejorar

3,4 < X <= 4,6

La documentación abarca todos los requisitos necesarios de manera

parcial, deben mejorarse los aspectos de calificación más baja.

Óptimo

x = 5

La compañía cuenta con mecanismos que soportan todos los requsitos

documentales de la norma.



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


Calificación obtenida = ∑(Nivel de cumplimiento*Peso por componentes de 1 a 4)

Calificación = Baja si a = No

Calificación = Media/Alta si a = Si

CONDICIONALESa

1

2

3

4 25%

¿Se identifica?No

(1)

¿Se realiza?No

(1)

Si

(5)

Si

(5)

Baja

(1)

Media

(3)

Alta

(5)25%

Baja

(1)

Media

(3)

Alta

(5)25%

Baja

(1)

Media

(3)

Alta

(5)25%

PESOS

¿Se hallaron?SI

(1)

NO

(0)

SI

(1)

NO

(0)

¿Se hallaron?SI

(1)

NO

(0)

¿Se documentan?SI

(1)

NO

(0)

¿Se documentan?SI

(1)

NO

(0)

CALIFICACIONES

Pro

ceso

s d

e co

ntr

ol d

e re

gis

tro

s ¿Se identifican?

¿Se realizan?

¿Se realizan?

¿Se identifica?

¿Se hallaron?

¿Se hallaron?SI

(1)

NO

(0)

SI

(1)

NO

(0)

SI

(1)

NO

(0)

SI

(1)

NO

(0)

SI

(1)

SI

(1)

NO

(0)

NO

(0)

Va

lora

ció

n d

e ev

iden

cia

efi

cáz

¿Se registran?SI

(1)

NO

(0)

¿Se documentan?

3.4 PROTECCIÓN DE LOS MEDIOS DE

ALMACENAMIENTO

2.6 REGISTROS DE LIBERACIÓN DE SOFTWARE

3. RETENCIÓN Y DISPOSICIÓN DE REGISTROS

3.1 MÉTODO DE ALMACENAMIENTO

2.4 ACUERDOS DE LICENCIA DE SOFTWARE

2.5 ACTAS DE REUNIONES

2.2 ESTIMACIONES V.S. AVANCES

3.4 EVALUACIÓN DE LA NATURALEZA DE LA

PROPIEDAD DE LA INFORMACIÓN

3.2 CONFIABILIDAD DEL MÉTODO DE

ALMACENAMIENTO

3.3 DISPONIBILIDAD DE LA INFORMACIÓN

2.3 SELECCIÓN DE HERRAMIENTAS,

METODOLOGÍAS Y PROVEEDORES

1.6 REGISTROS DE REVISIONES E INSPECCIONES

2. VALORACIÓN DE EVIDENCIA DE OPERACIÓN EFICÁZ

2.1 CAMBIOS HECHOS A LOS RECURSOS

1.5 INFORMES DE AUDITORÍAS Y EVALUACIONES

1.2 INFORMES SOBRE PROBLEMAS

1.3 SOLICITUDES DE CAMBIOS


C. FORMATO DE VALORACIÓN DE CONTROL DE REGISTROS

1. PROCESO DE CONTROL DE REGISTROS

1.1 RESULTADOS DE PRUEBAS DOCUMENTADAS

1.4 DOCUMENTACIÓN MARCADA CON

COMENTARIOS



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

calificaciones.




Inexistente

1 <= X < 2,25

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

incluido en el plan de mejoramiento desde la alta irección.

Insuficiente

2,25 <= X < 3,75

La seguridad de la información puede verse comprometida si no

se mejoran los aspectos de más baja calificación.

Por mejorar

3,75 <= X < 5

La compañía debe fortalecer el aspecto de más baja calificación,

para garantizar un correcto proceso de retención y disposición.

Óptimo

x = 5

La compañía cuenta con un poroceso de retención y disposición

con tendencia a la mejora contínua que debe ser monitoreado.

EL proceso de control de resgistros tiene falencias que ponen en

riesgo su confiabilidad

5 <= x <= 6El proceso de control de registros se realiza de forma adecuada,

debe monitorearse.

3 <= x < 5

0 <= x < 3El proceso de control de registros no se realiza adecuadamente,

debe implmentarse



RESULTADOS

3 <= x < 5EL proceso de control de resgistros tiene falencias que ponen en

riesgo su confiabilidad

5 <= x <= 6El proceso de control de registros se realiza de forma adecuada,

debe monitorearse.



0 <= x < 3El proceso de control de registros no se realiza adecuadamente,

debe implmentarse



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


¿Se aplican?SI

(1)

NO

(0)

¿Acorde con la

responsabilidad?

SI

(1)

NO

(0)

SI

(1)

NO

(0)

Enfo

qu

e a

l clie

nte

¿Se aplican?SI

(1)

NO

(0)

¿Se aplican?SI

(1)

NO

(0)

Co

mp

on

ente

s d

e re

spo

nsa

bili

da

d,

au

tori

da

d y

co

mu

nic

aci

ón

Calificación obtenida = ∑(Valor por componente)

¿Se aplican?SI

(1)

NO

(0)


Enfo

qu

e a

l clie

nte

¿Se aplican?SI

(1)

NO

(0)

¿Se aplican?SI

(1)

NO

(0)

¿Se aplican?SI

(1)

NO

(0)

¿Se aplican?

¿Se aplican?SI

(1)

NO

(0)

¿Se aplican?SI

(1)

NO

(0)


¿Se registra?SI

(1)

NO

(0)

Enfo

qu

e a

l clie

nte

¿Se tienen?SI

(1)

NO

(0)

¿Se realiza?SI

(1)

NO

(0)


CALIFICACIONES

¿Se conocen?

Co

mp

on

ente

s d

e

resp

on

sab

ilid

ad

¿Se conocen?SI

(1)

NO

(0)

SI

(1)

NO

(0)

¿Se realiza?SI

(1)

NO

(0)

¿Se realizan?SI

(1)

NO

(0)

¿Se comunicó?SI

(1)

NO

(0)

¿Se conocen?SI

(1)

NO

(0)

5.6 ESTRATEGIA DE COMUNICACIÓN

6. REVISIÓN POR LA DIRECCIÓN

6.1 MECANISMOS DE REGISTRO DE REVISIONES

5.3 CARGO 5.4 EXPERIENCIA

RELACIONADA (AÑOS)

5.5 PERFIL

5. RESPONSABILIDAD, AUTORIDAD Y COMUNICACIÓN

5.1 MECANISMOS DE DIFUSIÓN DE LAS

RESPONSABILIDADES

5.2 REPRESENTANTE DE LA

ORGANIZACIÓN PARA EL SGC

Nombre:

4.3 MECANISMOS DE CONTROL DE CAMBIOS DE

LOS OBJETIVOS DE LA CALIDAD

4.4 MECANISMOS DE EVALUACIÓN DE LOS

OBJETIVOS DE LA CALIDAD

4. PLANIFICACIÓN

4.1 MECANISMOS DE DIFUSIÓN DE LOS OBJETIVOS

DE LA CALIDAD

4.2 MECANISMOS DE MEDICIÓN DE

CUMPLIMIENTO DE LOS OBJETIVOS DE LA CALIDAD

3.3 MECANISMOS DE CONTROL DE CAMBIOS DE LA

POLÍTICA DE CALIDAD

3.4 MECANISMOS DE EVALUACIÓN DE LA POLÍTICA

DE CALIDAD

3. VALORACIÓN DE LA POLÍTICA DE CALIDAD

3.1 MECANISMOS DE DIFUSIÓN DE LA POLÍTICA DE

CALIDAD

3.2 MECANISMOS DE MEDICIÓN DE

CUMPLIMIENTO DE LA POLÍTICA DE CALIDAD

2.3 GESTIÓN DE OPERACIONES DE SERVICIO AL

CLIENTE

2.4 CAPACITACIÒN DE PERSONAL PARA SERVICIO

AL CLIENTE

2. VALORACIÓN DEL ENFOQUE AL CLIENTE

2.1 POLÍTICAS DE SERVICIO AL CLIENTE

2.2 METAS DEL SERVICIO AL CLIENTE

1.4 ESTABLECIMIENTO DE REVISIONES

1.5 GESTIÓN PARA LA DISPONIBILIDAD DE

RECURSOS

1.2 ESTABLECIMIENTO DE POLÍTICA DE CALIDAD

1.3 ESTABLECIMIENTO DE OBJETIVOS DE CALIDAD


D. FORMATO DE VALORACIÓN DE RESPONSABILIDAD DE LA DIRECCIÓN

1. COMPROMISO DE LA DIRECCIÓN

1.1 COMUNICADO OFICIAL A LA ORGANIZACIÒN



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

según calificaciones.


0 = x

1 = x

Se recomienda fortalecer la formación del representante o en su ausencia contratar uno capacitado

Se recomienda mantener un plan de capacitación para el representante

Se recomienda crear y/o implementar los mecanismos de revisión de la dirección

Se recomienda monitorear los mecanismos de difusión de revisión de la dirección

Se recomienda crear y/o implementar los mecanismos de difusión de las responsabilidades

Se recomienda monitorear los mecanismos de difusión de las responsabilidades




0 = x

1 = x

0 = x

1 = x


0 <= x < 2La estrategias de cumplimiento de la política de calidad deben ser

replanteadas o mejoradas (difusión, medición, alcance)

2 <= x < 4Se deben mejorar los aspectos de calificación más baja dentro de la

política de calidad.

4 = xLa política de calidad debe monitorearse dentro de los controles

corporativos establecidos par su mejora continua.



0 <= x < 2La estrategias de cumplimiento de las objetivos de calidad deben ser

replanteadas o mejoradas (difusión, medición, alcance)

2 <= x < 4Se deben mejorar los aspectos de calificación más baja dentro de los

objetivos de calidad.

4 = xLos objetivos de calidad deben monitorearse dentro de los controles

corporativos establecidos par su mejora continua.



0 <= x < 2El enfoque de servicio al cliente debe replantearse y difundirse,

como estrategia de mejoramiento desde la alta dirección.

2 <= x < 4Deben mejorarse los puntos de menor calificación en el enfoque al

cliente.

4 = xEl enfoque al cliente se tiene claro en la compañía, debe ser

monitoreado para garantizar su mejora continua.

3 <= x < 5La dirección debe garantizar que hace extensivo el conocimiento de

sus responsabilidades a todos los niveles corporativos.

5 = xEs clara la responsabilidad de la dirección; deben monitorearse los

canales de comunicación y difusión de la misma.

RESULTADOS



0 <= x < 3La dirección debe establecer, asumir y dar a conocer su

responsabilidad, de lo contrario se ponen en riesgo los resultados




Figura 35. Formato y calificaciones para la valoración de gestión de los recursos (parte 1 de 2).


¿Acorde? Si (1) No (1)










B M A

B M A

B M A

B M A

B M A

B M A

B M A

B M A

B M A

B M A

CALIFICACIONES

Va

lora

ció

n d

e co

mp

eten

cia

SI

(1)

SI

(1)

¿Se tiene?NO

(0)

¿Se identifican?NO

(0)

Rec

urs

os

ROL 10

2.1 NIVEL DE IMPACTO POR ROLES QUE AFECTAN

LA CALIDAD DEL PRODUCTO O DEL PROCESO

ROL 1

ROL 2

ROL 3

ROL 4

ROL 5

ROL 6

ROL 7

ROL 8

ROL 9

2.2 COMPETENCIAS REQUERIDAS POR ROLES QUE

AFECTAN LA CALIDAD DEL PRODUCTO O DEL

PROCESO

ROL 1

ROL 2

ROL 3

ROL 4

ROL 8

ROL 9

ROL 10

ROL 5

ROL 6

ROL 7

2. RECURSOS HUMANOS

2.1 IDENTIFICACIÓN DE ROLES QUE AFECTAN LA

CALIDAD DEL PRODUCTO O DEL PROCESO

ROL 1

ROL 2

ROL 3

ROL 7

ROL 8

ROL 9

ROL 4

ROL 5

ROL 6

ROL 10


E. FORMATO DE VALORACIÓN GESTIÓN DE LOS RECURSOS

1. PROVISIÓN DE LOS RECURSOS

1.1 IDENTIFICACIÓN DE LOS RECURSOS

1.2 RESPONSABLES DE LA ASIGNACIÓN DE

RECURSOS



134

Figura 36. Formato y calificaciones para la valoración de gestión de los recursos (parte 2 de 2).


4.3.3 OTROS

4.3.2 COMITÉ DE

CONVIVENCIA

¿EQUIPO CONFORMADO? TIEMPO DE EXISTENCIA PRESIDENTE

4.3.1 COPASST¿EQUIPO CONFORMADO? TIEMPO DE EXISTENCIA PRESIDENTE

4.2 RESULTADOS DE EVALUACIONES DE AMBIENTE LABORAL ANTERIORES

4.3 GRUPOS DE ACCIÓN

4. AMBIENTE DE TRABAJO

4.1 POLÍTICAS DE CONVIVENCIA Y AMBIENTE LABORAL DE LA ORGANIZACIÓN

3.2.5 OTROS RECURSOS

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.1.4 COMUNICACIONES 3.1.5 SISTEMA DE IMPRESIÓN

3. INFRAESTRUCTURA

3.1 ESPACIO DE TRABAJO

3.1.1 PUESTOS DE TRABAJO 3.1.2 CABLEADO ESTRUCTURADO 3.1.3 CONECTIVIDAD



Figura 37. Tabla de recomendaciones para la valoración gestión de los recursos, según

calificaciones (parte 1 de 2).


Según el impacto se debe priorizar aquellos de mayor incidencia con respecto a las

recomendaciones del apartado anterior.


0 = x

1 = x

Se recomienda realizar la identificación de recursos con su respectiva documentación

Se recomienda mantener monitoreada la lista de identificación de recursos

0 = x

1 = x

Se recomienda realizar la identificación de los responsables de asignar los recursos

Se recomienda mantener monitoreada la lista de los responsables de asignar los recursos


0 = x

1 = x

Se recomienda fortalecer la formación del responsable o en su ausencia contratar uno capacitado

Se recomienda mantener un plan de capacitación para el responsable



136

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.



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).


PESO

SI

(1)

NO

(0)12,50%

SI

(1)

NO

(0)12,50%

SI

(1)

NO

(0)12,50%

SI

(1)

NO

(0)12,50%

SI

(1)

NO

(0)12,50%

SI

(1)

NO

(0)12,50%

SI

(1)

NO

(0)12,50%

SI

(1)

NO

(0)12,50%

1.2.1 DESCRIPCIÓN DEL PROYECTO DE SOFTWARE SIG

1.2.1.1 ANTECEDENTES.

1. PLANIFICACION DE LA REALIZACIÓN DEL PRODUCTO

1.1 CICLO DE VIDA DEL SOFTWARE

1.2. PLANIFICACIÓN DE LA CALIDAD


K. FORMATO DE VALORACIÓN DE PLANIFICACIÓN DE REALIZACIÓN DEL PRODUCTO

FECHA DE ELABORACIÓN: DD-MM-AAAA LIDER:

1.2.1.5 DEFINICIÓN DE ACTIVIDADES DE REVISIÓN, VERIFICACIÓN,

VALIDACIÓN.

1.2.1.6 DEFINICIÓN DE PROCEDIMIENTOS DE GESTIÓN DE LA

CONFIGURACIÓN.

1.2.1.7 DEFINICIÓN DE ACTIVIDADES DE MONITOREO Y MEDICIÓN.

1.2.1.2 OBJETIVOS.

1.2.1.3 RESULTADOS ESPERADOS.

1.2.1.4 ADAPTACIÓN DEL SGC.

CALIFICACIONES

¿Se identifica?

1.2.1.8 GESTIÓN DEL CAMBIO.

¿Se identifica?

¿Se identifica?

¿Se identifica?

SI

(1)

NO

(0)


(No calificable)

CVSW

¿Se identifica?

¿Se identifica?

Estr

uct

ura

inic

ial d

el p

roye

cto

SIG

¿Se identifica?

¿Se identifica?

¿Se identifica?



138

Figura 40. Formato y calificaciones para la valoración de planificación de realización del producto (parte 2 de 2).


SI

(1)

NO

(0)25%

SI

(1)

NO

(0)25%

SI

(1)

NO

(0)25%

SI

(1)

NO

(0)25%

SI

(1)

NO

(0)25%

SI

(1)

NO

(0)25%

SI

(1)

NO

(0)25%

SI

(1)

NO

(0)25%

SI

(1)

NO

(0)

1.2.4 IMPLEMENTACIÓN DE SOFTWARE SIG

1.2.4.1 PLAN PARA LA IMPLEMENTACIÓN

DISEÑO DE LA BASE DE DATOS.

1.2.3.2 DISEÑO DE LA TECNOLOGÍA (HARDWARE Y SOFTWARE).

1.2.3.3 DISEÑO DE PRUEBAS.

1.2.2.3 DEFINICIÓN DEL EQUIPO SIG Y SUS RESPECTIVAS NECESIDADES DE

FORMACIÓN.

1.2.2.4 MODELO DE CALIDAD DEL PRODUCTO Y REQUISITOS DE CALIDAD

1.2.3 DISEÑO CONCEPTUAL DE SOFTWARE SIG

1.2.3.1 PLAN PARA EL DISEÑO Y DESARROLLO

1.2.2 ESTUDIO DE LOS REQUISITOS DE SOFTWARE SIG

1.2.2.1 EVALUACIÓN DE NECESIDADES.

1.2.2.2 ÁMBITO DEL SISTEMA.

¿Se identifica?

¿Se identifica?

¿Se identifica?

Estu

dio

de

los

req

uis

ito

s

¿Se identifica?

¿Se identifica?

¿Se identifica?

¿Se identifica?

¿Se identifica?

¿Se identifica?



Figura 41. Tabla de recomendaciones para la valoración de planificación de realización del

producto, según calificaciones.


Plan

La organización debe mejorar el componente

de requsitos con más baja calificación

RESULTADOS

Deficiente

0%<= X <= 50%

La organización debe asegurar que planifica y

desarrolla los procesos necesarios para la

realización del producto en coherencia con el

SGC.


(No calificable)

Lista de relaciones calificación obtenida/recomendación por aspecto.

X =S (de cada ítem* Peso)


Insuficiente

50% < X < 7 5%

La organización debe asegurar que planifica y

desarrolla todos los procesos necesarios para la

realización del producto en coherencia con el

SGC.

Aceptable

75%<= X <= 100%

La organización debe reforzar los procesos

necesarios para la realización del producto en

coherencia con el SGC.

La organización debe adoptar un

ciclo de vida para el proyecto, o

pone en riesgo su correcta

realización.

La organización debe asegurar

que el ciclo de vida

selecionado permita la

realización del proyecto.

CVSW

La organización debe adoptar un

plan de implementación para el

La organización debe asegurar

que el ciclo de vida

Deficiente

0%<= X <= 50%

La organización debe implementar un proceso

de diseño más rigurosoInsuficiente

50% < X < 7 5%

La organización debe mejorar su proceso de

diseñoAceptable

75%<= X <= 100%

La organización debe mejorar el componente

de desarrollo con más baja calificación

Deficiente

0%<= X <= 50%

Insuficiente

50% < X < 7 5%

Aceptable

75%<= X <= 100%

La organización debe implementar un proceso

de ingeniería de requerimientos

La organización debe mejorar su proceso de

ingeniería de requerimientos



Figura 42. Formato y calificaciones para la valoración de procesos relacionados con el cliente (parte 1 de 2).


PESO


L. FORMATO DE VALORACIÓN DE PROCESOS RELACIONADOS CON EL CLIENTE

FECHA DE ELABORACIÓN: DD-MM-AAAA LÍDER:

Realice una breve descripción de como se aborda este punto

1.5 FIABILIDAD Realice una breve descripción de como se aborda este punto

1.6 SEGURIDAD Realice una breve descripción de como se aborda este punto

1.7 MANTENIBILIDAD Realice una breve descripción de como se aborda este punto

1. DETERMINACIÓN DE REQUISITOS RELACIONADOS CON EL PRODUCTO (MODELO DE CALIDAD)

1.1 ADECUACIÓN FUNCIONAL Realice una breve descripción de como se aborda este punto

1.2 EFICIENCIA DE DESEMPEÑO Realice una breve descripción de como se aborda este punto

1.3 COMPATIBILIDAD Realice una breve descripción de como se aborda este punto

1.4 USABILIDAD

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)

2.1 DOCUMENTO DE REQUISITOS ¿Se realiza?

CALIFICACIONES


(No calificable)

¿Se identifica?NO

(0)

NO

(0)

SI

(1)

SI

(1)

SI

(1)

SI

(1)

SI

(1)

SI

(1)

¿Se identifica?

¿Se identifica?

¿Se identifica?

¿Se identifica?

¿Se identifica?

¿Se identifica?

¿Se identifica? 12,50%

12,50%NO

(0)

NO

(0)12,50%

SI

(1)

NO

(0)

NO

(0)

SI

(1)

Det

erin

ació

n d

e re

qu

isit

os

del

pro

yect

o S

IGD

R ¿Se realiza?SI

(1)

NO

(0)

12,50%

NO

(0)12,50%

NO

(0)12,50%

12,50%

12,50%



141

Figura 43. Formato y calificaciones para la valoración de procesos relacionados con el cliente (parte 2 de 2).


PESO

SI

(1)

NO

(0)8,33%

SI

(1)

NO

(0)8,33%

SI

(1)

NO

(0)8,37%

SI

(1)

NO

(0)8,33%

SI

(1)

NO

(0)8,33%

SI

(1)

NO

(0)8,33%

SI

(1)

NO

(0)8,33%

SI

(1)

NO

(0)8,33%

SI

(1)

NO

(0)8,33%

SI

(1)

NO

(0)8,33%

SI

(1)

NO

(0)8,33%

SI

(1)

NO

(0)8,33%

SI

(1)

NO

(0)40,00%

SI

(1)

NO

(0)30,00%

SI

(1)

NO

(0)30,00%

3.5 REQUISITOS DE IMAGEN ¿Se identifica?

3.6 REQUISITOS DE ESQUEMAS ¿Se identifica?

¿Se identifica?

3.8 FRECUENCIA DE USO ¿Se identifica?

3.9 ASOCIACIONES LÓGICAS ¿Se identifica?

3. PRODUCTOS INFORMATIVOS

3.1 TITULO ¿Se identifica?

3.2 NOMBRE DEL SOLICITANTE ¿Se identifica?

3.3 SINOPSIS ¿Se identifica?

3.4 REQUISITOS DE MAPAS ¿Se identifica?

5. REVISIÓN DE LOS REQUISITOS

5.1 DOCUMENTO DE REVISIÓN REQUISITOS ¿Se realiza?

6. COMUNICACIÓN CON EL CLIENTE

6.1 REPRESENTANTE DEL CLIENTE ¿Se tiene?

4. CATEGORIZACIÓN DE REQUISITOS

4.1 DE CALIDAD EN USO ¿Se identifica?

4.2 DE CALIDAD EXTERNA ¿Se identifica?

4.3 DE CALIDAD INTERNA ¿Se identifica?

3.10 ERRORES ¿Se identifica?

3.11 ESPERA Y RESPUESTA ¿Se identifica?

3.12 COSTO/BENEFICIOS ¿Se identifica?

3.7 PASOS PARA LLEGAR AL PRODUCTO

Pro

du

cto

s In

form

ativ

os

¿Se identifica?

¿Se identifica?

¿Se identifica?

¿Se identifica?

¿Se identifica?

¿Se identifica?

¿Se identifica?

¿Se identifica?

¿Se identifica?

¿Se identifica?

¿Se identifica?

¿Se identifica?

RC ¿Se tiene?

SI

(1)

NO

(0)C

ateg

ori

zaci

ón

de

req

uis

ito

sD

RR

¿Se realiza?SI

(1)

NO

(0)

¿Se identifica?

¿Se identifica?

¿Se identifica?



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)

Aceptable

75%<= X <= 100%

La organización debe reforzar los procesos con falencias

del modelo de calidad.

DRLa organización debe

implementar un documento de

La organización debe garantizar que

se diligencia el documento de




Deficiente

0%<= X <= 50%

La organización debe adoptar un modelo de calidad

para la realización del producto

Insuficiente

50% < X < 7 5%

La organización debe mejorar su modelo de calidad

para la realización del producto



143

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

cliente (parte 2 de 2), según calificaciones.





Deficiente

0%<= X <= 50,02%

La organización debe implementar un modelo de diseño

basado en productos informativos

Insuficiente

50.2 < X < 7 4.97%

La organización debe mejorar un modelo de diseño

basado en productos informativos

Aceptable

74.97%<= X <= 100%

La organización debe reforzar las falencias de su

modelo de diseño basado en productos informativos


se diligencia el documento de RC

La organización debe


La organización debe mejorar la categorización a sus

requisitos una vez los encuentre.

DRR



revisión de requisitos para

asegurar sus procesos de

desarrollo.


se diligencia el documento de

revisión de requisitos para asegurar

sus procesos de desarrollo.


Insuficiente

0%<= X <= 60%

La organización debe categorizar sus requisitos una vez

los encuentre.

Aceptable

60% < X <=1005%



Figura 46. Formato y calificaciones para la valoración de diseño y desarrollo.


PESO

SI

(1)

NO

(0)25%

SI

(1)

NO

(0)25%

SI

(1)

NO

(0)25%

SI

(1)

NO

(0)25%

PP

I SI

(1)

NO

(0)

CP

I SI

(1)

NO

(0)

CD

R SI

(1)

NO

(0)

SI

(1)

NO

(0)25%

SI

(1)

NO

(0)25%

SI

(1)

NO

(0)25%

SI

(1)

NO

(0)25%

SI

(1)

NO

(0)16%

SI

(1)

NO

(0)18%

SI

(1)

NO

(0)16%

SI

(1)

NO

(0)16%

SI

(1)

NO

(0)16%

SI

(1)

NO

(0)18%


M. FORMATO DE VALORACIÓN DE DISEÑO Y DESARROLLO


¿Se realiza?

1.1.4 DISPONIBILIDAD Y COSTO DE LOS DATOS ¿Se realiza?

1.2 PRIORIZACIÓN DE LOS PRODUCTOS INFORMATIVOS ¿Se realiza?

1.3 CRONOGRAMA PARA PRODUCTOS INFORMATIVOS ¿Se realiza?

1. PLANIFICACIÓN DEL DISEÑO Y DESARROLLO

1.1 LISTA MAESTRA DE DATOS DE ENTRADA (MIDL) ¿Se realiza?

1.1.1 IDENTIFICACIÓN DE DATOS ¿Se realiza?

1.1.2 CONSIDERACIONES ACERCA DE LA CANTIDAD DE DATOS ¿Se realiza?

1.1.3 CARACTERÍSTICAS DE LOS DATOS

2.1.3 PROYECCIÓN ¿Se define?

2.1.4 TOLERANCIA AL ERROR ¿Se define?

2.2 ACTIVIDADES SOBRE LOS DATOS

2.2.1 IDENTIFICACIÓN DE DATOS QUE CUMPLEN

LOS REQUISITOS Y SUS FUENTES ¿Se define?

1.4 CONTROL DE DOCUMENTACIÓN Y REGISTROS ¿Se realiza?

2. ELEMENTOS DE ENTRADA PARA DISEÑO Y DESARROLLO

2.1 DATOS

2.1.1 ESCALA DE LOS DATOS ¿Se define?

2.1.2 RESOLUCIÓN ¿Se define?

2.2.5 FUNCIONES ESPACIALES Y ANÁLISIS DE RED ¿Se define?

2.2.6 CORRECCIÓN DE AMBIGUEDADES,

CONTRADICCIONES ¿Se define?

2.2.2 ESTÁNDARES DE INTEROPERABILIDAD ¿Se define?

2.2.3 TOPOLOGÍA ¿Se define?

2.2.4 CARTOGRAFÍA BASE ¿Se define?

¿Se realiza?

¿Se realiza?

CALIFICACIONES


(No calificable)

¿Se realiza?

¿Se define?

¿Se define?

¿Se define?

¿Se define?

SI

(1)

NO

(0)

MID

L

¿Se realiza?

¿Se realiza?

¿Se realiza?

¿Se realiza?

¿Se realiza?

Cu

alid

ades

so

bre

los

dat

os

Act

ivid

ades

so

bre

los

dat

os

¿Se define?

¿Se define?

¿Se define?

¿Se define?

¿Se define?

¿Se define?



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


PP

IC

PI

CD

R

MIDL


implementar una MIDL para


desarrollo.

La organización debe garantizar

que se diligencia la MIDL para


desarrollo.


(No calificable)






desarrollo.




desarrollo.




desarrollo.




desarrollo.




desarrollo.




desarrollo.

Deficiente

0%<= X <= 50%

La organización debe adoptar un modelo de

calidad para la realización del producto

Deficiente

50%< X < 75%



Deficiente

75%<= X <= 100%




Deficiente

0%<= X <= 50%

La organización debe definir las cualidades

requeridas sobre los datos en la fase de diseño.

Deficiente

50%< X < 75%

La organización debe mejorar la definición de

las cualidades requeridas sobre los datos en la

fase de diseño.

Deficiente

75%<= X <= 100%

La organización debe garantizar que las

cualidades definidas son las requeridas sobre

los datos en la fase de diseño.


Deficiente

0%<= X <= 48%

La organización debe definir las cualidades

requeridas sobre los datos en la fase de diseño.

Deficiente

48%< X < 84%

La organización debe mejorar la definición de

las cualidades requeridas sobre los datos en la

fase de diseño.

Deficiente

84%<= X <= 100%

La organización debe garantizar que las

cualidades definidas son las requeridas sobre

los datos en la fase de diseño.



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


SI

(1)

NO

(0)14%

SI

(1)

NO

(0)15%

SI

(1)

NO

(0)15%

SI

(1)

NO

(0)14%

SI

(1)

NO

(0)14%

SI

(1)

NO

(0)14%

SI

(1)

NO

(0)14%

SI

(1)

NO

(0)16%

SI

(1)

NO

(0)16%

SI

(1)

NO

(0)18%

SI

(1)

NO

(0)16%

SI

(1)

NO

(0)16%

SI

(1)

NO

(0)18%

SI

(1)

NO

(0)40,00%

SI

(1)

NO

(0)30,00%

SI

(1)

NO

(0)30,00%


N. FORMATO DE VALORACIÓN DE DISEÑO Y DESARROLLO (RESULTADOS)


1.7 DOCUMENTOS DE MANTENIMIENTO ¿Se identifica?

1. RESULTADOS DE DISEÑO Y DESARROLLO

1.1 ESPECIFICACIONES DE DISEÑO ¿Se identifica?

1.2 MODELO LÓGICO DE DATOS ¿Se identifica?

1.3 CÓDIGO FUENTE ¿Se identifica?

1.4 ARQUITECTURA DEL SIG ¿Se identifica?

1.5 PRODUCTO SIG DESARROLLADO ¿Se identifica?

1.6 DOCUMENTOS OPERATIVOS ¿Se identifica?

¿Se identifica?

2.6 ACTIVIDADES DE SEGUMIENTO OBRE RESOLUCIÓN

DE PROBLEMAS ¿Se identifica?

3. VERIFICACIÓN DEL DISEÑO Y DESARROLLO

2. REVISIÓN DEL DISEÑO Y DESARROLLO

2.1 FRECUENCIA DE REVISIÓN ¿Se identifica?

2.2 QUE PRODUCTOS INFORMATIVOS SE REVISAN ¿Se identifica?

2.3 COMO SE PLANIFICA LA REVISIÓN ¿Se identifica?

2.4 QUE ELEMENTOS SE REQUIEREN PARA LA REVISIÓN

4.3 PRUEBAS DE CALIFICACIÓN Y ACEPTACIÓN DEL SIG ¿Se realizan?

Act

ivid

ades

so

bre

los

dat

os

¿Se identifica?

¿Se identifica?

3.1 SE VERIFICA EL DISEÑO Y DESARROLLO

Val

idac

ión

del

dis

eño

y

des

arro

llo

¿Se realizan?

4. VALIDACIÓN DEL DISEÑO Y DESARROLLO

4.1 PRUEBAS UNITARIAS ¿Se realizan?

4.2 PRUEBAS DE INTEGRACIÓN ¿Se realizan?

¿Se identifica?

2.5 CRITERIOS DE ÉXITO O ACEPTACIÓN

¿Se identifica?

¿Se identifica?

¿Se identifica?

¿Se identifica?

CALIFICACIONES


(No calificable)

¿Se identifica?

¿Se identifica?

¿Se realizan?

¿Se realizan?

¿Se identifica?

Act

ivid

ades

so

bre

los

dat

os ¿Se identifica?

¿Se identifica?

¿Se identifica?

¿Se identifica?



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


Deficiente

48%< X < 84%

La organización debe mejorar el proceso de revisión de

los resultados de diseño y desarrollo.


Deficiente

0%<= X <= 48%

La organización debe definir un proceso de revisión de

los resultados de diseño y desarrollo.


(No calificable)


Deficiente

84%<= X <= 100%

La organización debe garantizar que la revisión de los

resultados de diseño y desarrollo se cumple bajo los

Aceptable

60% < X <=1005%

La organización debe ejecutar mejores pruebas de SW

que le permitan medir los resultados de diseño y


Insuficiente

0%<= X <= 60%

La organización debe ejecutar pruebas de SW que le

permitan medir los resultados de diseño y desarrollo


Deficiente

0%<= X <= 42%

La organización debe controlar los resultados de la fase

de diseño y desarrollo.

Deficiente

42%< X < 71%

La organización debe mejorar el control de los

resultados de la fase de diseño y desarrollo.

Deficiente

71%<= X <= 100%

La organización debe garantizar que los resultados de

diseño y desarrollo son controlados siempre.



Figura 50. Formato y calificaciones para la valoración de producción y prestación del servicio (parte 1 de 2).


CLR

SI

(1)

NO

(0)

PP

R SI

(1)

NO

(0)

SI

(1)

NO

(0)16%

SI

(1)

NO

(0)16%

SI

(1)

NO

(0)18%

SI

(1)

NO

(0)16%

SI

(1)

NO

(0)16%

SI

(1)

NO

(0)18%

1.2.1 ASPECTOS ORGANIZACIONALES Y DE GESTIÓN

1.2.1.1 REQUISITOS DE INTERACCIÓN

INTERINSTITUCIONAL


O. FORMATO DE VALORACIÓN DE PRODUCCIÓN Y PRESTACIÓN DEL SERVICIO A



1.1 CONTROL DE LA PRODUCCIÓN Y PRESTACIÓN DEL SERVICIO

1.1 COMPILACIÓN, LIBERACIÓN Y REPRODUCCIÓN ¿Se controla?

1.2 PUESTA EN PRODUCCIÓN ¿Se controla?

¿Se controla?

1.2.1.2 RESPONSABILIDADES, FUNCIONES Y

OBLIGACIONES ¿Se controla?

1.2.1.3 ACUERDOS DE USO DE DATOS PARA EL

SOFTWARE SIG ¿Se controla?

1.2.1.4 ACUERDOS DE ACCESO A LAS

INSTALACIONES DEL CLIENTE Y DISPONIBILIDAD DEL

PERSONAL ¿Se controla?

1.2.1.5 REVISIÓN DE ASPECTOS LEGALES Y

CONTRACTUALES ¿Se controla?

1.2.1.6 ANÁLISIS DE RIESGOS ¿Se controla?

CALIFICACIONES


(No calificable)

¿Se controla?

¿Se controla?

Act

ivid

ades

so

bre

los

dat

os

¿Se controla?

¿Se controla?

¿Se controla?

¿Se controla?

¿Se controla?

¿Se controla?



149

Figura 51. Formato y calificaciones para la valoración de producción y prestación del servicio (parte 2 de 2).


SI

(1)

NO

(0)10%

SI

(1)

NO

(0)9%

SI

(1)

NO

(0)9%

SI

(1)

NO

(0)9%

SI

(1)

NO

(0)9%

SI

(1)

NO

(0)9%

SI

(1)

NO

(0)9%

SI

(1)

NO

(0)9%

SI

(1)

NO

(0)9%

SI

(1)

NO

(0)9%

SI

(1)

NO

(0)9%

1.2.2.1 PLAN DE INSTALACIÓN ¿Se controla?

1.2.2 ASPECTOS DE GESTIÓN DE LA CONFIGURACIÓN

1.2.2.6 MIGRACIÓN DE DATOS PREVIOS ¿Se controla?

1.2.2.7 CAPTURA DE DATOS Y POBLACIÓN DE LA

BASE DE DATOS ¿Se controla?

1.2.2.2 DATOS Y REQUISITOS DE INFRAESTRUCTURA

DEL SIG EN AMBIENTE DE PRODUCCIÓN ¿Se controla?

1.2.2.3 REQUISITOS DE ACCESO A EQUIPOS

(USUARIOS, CONTRASEÑAS, RED) ¿Se controla?

1.2.2.4 REVISIÓN DE SEGURIDAD ¿Se controla?

1.2.2.11 PUESTA EN PRODUCCIÓN ¿Se controla?

1.2.2.8 COPIAS DE SEGURIDAD Y SU INTEGRIDAD ¿Se controla?

1.2.2.9 GUÍAS O INSTRUCTIVOS DE INSTALACIÓN ¿Se controla?

1.2.2.10 ENTRENAMIENTO RELACIONADO CON EL

USO EL SOFTWARE SIG DURANTE LA INSTALACIÓN ¿Se controla?

1.2.2.5 INTEGRACIÓN EL SISTEMA ¿Se controla?

¿Se controla?

¿Se controla?

¿Se controla?

¿Se controla?

¿Se controla?

Ges

tió

n d

e la

co

nfi

gura

ció

n

¿Se controla?

¿Se controla?

¿Se controla?

¿Se controla?

¿Se controla?

¿Se controla?



Figura 52. Tabla recomendaciones para valoración de producción y prestación del servicio.


CLR

PP

R


(No calificable)

Lista de relaciones calificación obtenida/recomendación por

aspecto.


implementar un proceso

de compilación,

liberación y reproducción


mejorar el proceso de

compilación, liberación y

reproducción


implementar un proceso

de puesta en producción


mejorar el proceso de

puesta en producción


Deficiente

0%<= X <= 48%

La organización debe definir un

proceso de revisión de los resultados


Deficiente

48%< X < 84%

La organización debe mejorar el

proceso de revisión de los resultados


Deficiente

84%<= X <= 100%


la revisión de los resultados de diseño

y desarrollo se cumple bajo los


Deficiente

0%<= X <= 45%

La organización debe definir un

proceso de gestión de la

configuración.

Deficiente

45%< X <75%

La organización debe mejorar el

proceso de gestión de la

configuración.

Deficiente

75%<= X <= 100%


la gestión de configuación es

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).


SI

(1)

NO

(0)16%

SI

(1)

NO

(0)18%

SI

(1)

NO

(0)16%

SI

(1)

NO

(0)16%

SI

(1)

NO

(0)16%

SI

(1)

NO

(0)18%

SI

(1)

NO

(0)20%

SI

(1)

NO

(0)20%

SI

(1)

NO

(0)20%

SI

(1)

NO

(0)20%

SI

(1)

NO

(0)20%

1.1.3 ACTIVIDADES DE RESOLUCIÓN DE

PROBLEMAS, SOPORTE DE HARDWARE Y

SOFTWARE. ¿Se controla?


P. FORMATO DE VALORACIÓN DE PRODUCCIÓN Y PRESTACIÓN DEL SERVICIO B



1.1 CONTROL DE LA PRODUCCIÓN Y PRESTACIÓN DEL SERVICIO

1.1.1 ALCANCE DEL MANTENIMIENTO ¿Se controla?

1.1.2 IDENTIFICACIÓN DEL ESTADO INICIAL DEL

SOFTWARE SIG. ¿Se controla?

1.1.4 MODIFICACIONES AL SISTEMA Y ADICIONALES

EN INTERFACES O COMPONENTES DE HARDWARE

(SI APLICAN). ¿Se controla?

1.1.5 ACTUALIZACIÓN DE LA GESTIÓN DE

CONFIGURACIÓN, PRUEBAS Y ASEGURAMIENTO

DE LA CALIDAD. ¿Se controla?

1.1.6 REGISTROS Y REPORTES DE MANTENIMIENTO. ¿Se controla?

¿Se controla?

1.2.5 REVALIDACIÓN EL SOFTWARE SIG, DADOS

PROCEDIMIENTOS DE MANTENIMIENTO. ¿Se controla?

CALIFICACIONES

¿Se controla?

¿Se controla?

¿Se controla?

Pro

du

cció

n y

pre

stac

ión

del

ser

vici

o

1.2 VALIDACIÓN DE LOS PROCESOS DE PRODUCCIÓN Y DE LA PRESTACIÓN DEL SERVICIO

1.2.1 CRITERIOS DE VALIDACIÓN DE LA

IMPLEMENTACIÓN. ¿Se controla?

1.2.2 APROBACIÓN DE LOS EQUIPOS Y EL

PERSONAL. ¿Se controla?

1.2.3 VERIFICACIÓN DE LOS REQUISITOS Y

PRODUCTOS INFORMATIVOS EN PRODUCCIÓN. ¿Se controla?

1.2.4 REQUISITOS DE DOCUMENTACIÓN Y

REGISTROS.


(No calificable)

¿Se controla?

Valid

ación

de p

roceso

s de p

rod

ucció

n y p

restación

del servicio

¿Se controla?

¿Se controla?

¿Se controla?

¿Se controla?

¿Se controla?

¿Se controla?

¿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


Deficiente

0%<= X <= 48%

La organización debe controlar y

gestionar la puesta en marcha del

software y la prestación del servicio.

Deficiente

48%< X < 84%

La organización debe mejorar y

gestionar la puesta en marcha del

software y la prestación del servicio.

Deficiente

84%<= X <= 100%

La organización debe mejorar y

corregir las falencias de la puesta en

marcha del software y la prestación

del servicio.

Deficiente

60%<= X <= 100%


las cualidades definidas son las

requeridas sobre los datos en la fase

de diseño.


Deficiente

0%<= X <= 40%

La organización debe definir las

cualidades requeridas sobre los datos

en la fase de diseño.

Deficiente

40%< X < 60%

La organización debe mejorar la

definición de las cualidades 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).


SI

(1)

NO

(0)12,50%

SI

(1)

NO

(0)12,50%

SI

(1)

NO

(0)12,50%

SI

(1)

NO

(0)12,50%

SI

(1)

NO

(0)12,50%

SI

(1)

NO

(0)12,50%

SI

(1)

NO

(0)12,50%

SI

(1)

NO

(0)12,50%


Q. FORMATO DE VALORACIÓN DE MEDICIÓN, ANÁLISIS Y MEJORA


1.7 MANTENIBILIDAD

1. RESULTADOS DE SEGUIMIENTO Y MEDICIÓN

1.1 ADECUACIÓN FUNCIONAL

1.2 EFICIENCIA DE DESEMPEÑO

1.3 COMPATIBILIDAD

1.4 USABILIDAD

1.5 FIABILIDAD

1.6 SEGURIDAD

1.8 PORTABILIDAD¿Se mide?

¿Se mide?

¿Se mide?

CALIFICACIONES


(No calificable)

¿Se mide?

¿Se mide?

¿Se mide?

¿Se mide?

¿Se mide?



154

Figura 56. Formato y calificaciones para la valoración de medición, análisis y mejora (parte 2 e 2).


SI

(1)

NO

(0)16%

SI

(1)

NO

(0)18%

SI

(1)

NO

(0)16%

SI

(1)

NO

(0)16%

SI

(1)

NO

(0)16%

SI

(1)

NO

(0)18%

SI

(1)

NO

(0)20%

SI

(1)

NO

(0)20%

SI

(1)

NO

(0)20%

SI

(1)

NO

(0)20%

SI

(1)

NO

(0)20%

2.6 REVISAR LAS ACCIONES CORRECTIVAS

TOMADAS.

2. RESULTADOS DE ANÁLISIS DE DATOS Y MEJORA (ACCIONES CORRECTIVAS)

2.1 REVISAR LAS NO CONFORMIDADES

(INCLUYENDO QUEJAS DE LOS CLIENTES).

2.2 DETERMINAR LAS CAUSAS DE LAS NO

CONFORMIDADES.

2.3 EVALUAR LA NECESIDAD DE ADOPTAR

ACCIONES PARA ASEGURARSE DE QUE LAS NO

CONFORMIDADES NO VUELVAN A OCURRIR

2.4 DETERMINAR E IMPLEMENTAR LAS ACCIONES

NECESARIAS.

2.5 REGISTRAR LOS RESULTADOS DE LAS ACCIONES

TOMADAS.

3.4 REGISTRAR LOS RESULTADOS DE LAS ACCIONES

TOMADAS.

3.5 REVISAR LAS ACCIONES PREVENTIVAS

ADOPTADAS.

3. RESULTADOS DE ANÁLISIS DE DATOS Y MEJORA (ACCIONES PREVENTIVAS)

3.1 DETERMINAR LAS NO CONFORMIDADES

POTENCIALES Y SUS CAUSAS.

3.2 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).

3.3 DETERMINAR E IMPLEMENTAR LAS ACCIONES

NECESARIAS.

¿Se mide?Act

ivid

ades

so

bre

los

dat

os

¿Se mide?

¿Se mide?

¿Se mide?

¿Se mide?

¿Se mide?

Valid

ación

de p

roceso

s de p

rod

ucció

n y

prestació

n d

el servicio

¿Se mide?

¿Se mide?

¿Se mide?

¿Se mide?

¿Se mide?



Figura 57. Tabla recomendaciones para valoración de medición, análisis y mejora.


RESULTADOS


(No calificable)




Aceptable

75%<= X <= 100%

La organización debe reforzar los procesos de medición y

seguimiento con falencias del modelo de calidad.


Deficiente

0%<= X <= 48%

La organización debe definir la responsabilidad de implementar

acciones corectivas con su respectiva gestión

Deficiente

0%<= X <= 50%

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

seguimiento

Insuficiente

50% < X < 7 5%

La organización debe mejorar el modelo de medición y

seguimiento

Deficiente

48%< X < 84%

La organización debe gestionar que se realicen las acciones

corectivas

Deficiente

84%<= X <= 100%

La organización debe documentar la aplicación delas acciones

correctivas para su posterior análisis


Deficiente

0%<= X <= 40%

La organización debe definir la responsabilidad de implementar

acciones preventivas con su respectiva gestión

Deficiente

40%< X < 60%

La organización debe gestionar que se realicen las acciones

preventivas

Deficiente

60%<= X <= 100%

La organización debe documentar la aplicación delas acciones

preventivas para su posterior análisis



156

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: Espacio para firma: ____________________ NOMBRE EVALUADOR 1 Espacio para firma: ____________________ NOMBRE EVALUADOR 2

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

Documents

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