antología de normas e iso
DESCRIPTION
ÂTRANSCRIPT
Instituto Tecnológico de Colima Ing. En Sistemas Computacionales
Metodologías De Desarrollo De Software
Integrantes
Salma Yanet Negrete Borjas (10460301)
Armando Saúl Carranza Sánchez (10460256)
Marlene Alejandra Maciel Torres (10460292)
Víctor Manuel Galindo Ramírez (10460269)
David Cuadra Quevedo - 10460260
José Luis Alcaraz Figueroa (10460245)
Juan Salvador García Andrade (10460270)
Luis Manuel Avalos Lara (10460247)
Julio César Salazar González (10460310)
Juan Pablo González Ramírez (10460714)
Lizeth Reyes Carmen (10460736)
Víctor Manuel Romero Larios (10460739)
Temas
ISO/IEC 9126 ISO/IEC 20000
ISO/IEC 15504 ISO/IEC 38500
ISO/IEC 14764 ISO/IEC 38500
ISO/IEC 14598 ISO/IEC 27000
ISO 25000 NYSE NMX-1-059-/02
IEEE 828 IEEE 830
Maestra
Alma Delia Chávez Rojas
Fecha de entrega
Lunes 11 de noviembre de 2013
2
ÍNDICE
ÍNDICE ............................................................................................................................................... 2
ISO/IEC 9126 .................................................................................................................................... 8
INTRODUCCIÓN ........................................................................................................... 9
ISO/IEC 12207 ................................................................................................................................ 18
INTRODUCCION ............................................................................................................................ 19
ISO 12207 ........................................................................................................................................ 20
Cosas Curiosas ............................................................................................................................... 26
ISO/IEC 15504 ................................................................................................................................ 27
INTRODUCCIÓN ............................................................................................................................ 28
HISTORIA ........................................................................................................................................ 29
DESCRIPCIÓN ............................................................................................................................... 29
CARACTERÍSTICAS ..................................................................................................................... 30
ESTRUCTURA ............................................................................................................................... 30
NIVELES .......................................................................................................................................... 32
VENTAJAS ...................................................................................................................................... 33
DESVENTAJAS .............................................................................................................................. 34
CERTIFICACIÓN ............................................................................................................................ 34
ISO/IEC 15504 vs CMMI ............................................................................................................... 35
COSAS CURIOSAS ....................................................................................................................... 36
ISO/IEC 14764 ................................................................................................................................ 38
Introducción ..................................................................................................................................... 39
Definición ......................................................................................................................................... 39
Características ................................................................................................................................ 40
"Mantenibilidad ............................................................................................................. 40
Transición del software ................................................................................................ 40
Documentación ............................................................................................................ 40
Fases ................................................................................................................................................ 41
"Fase 1: Identificación y clasificación del problema o de la modificación ...................... 41
Fase 2: Análisis ............................................................................................................ 41
Fase 3: Diseño ............................................................................................................. 42
3
Fase 4: Implementación ............................................................................................... 42
Fase 5: Pruebas del sistema ........................................................................................ 42
Fase 6: Pruebas de aceptación .................................................................................... 42
Fase 7: Liberación del producto ................................................................................... 43
Estándares que se relacionan con la ISO 14764 ...................................................................... 43
IEEE 1074 .................................................................................................................... 43
ISO 12207 .................................................................................................................... 43
IEEE 1061 .................................................................................................................... 43
ISO 9126 ...................................................................................................................... 43
IEEE 1219 .................................................................................................................... 44
Aplicación......................................................................................................................................... 44
Cosas curiosas ............................................................................................................................... 44
Tipos de mantenimiento ............................................................................................... 44
Otros estándares que tratan el mantenimiento ............................................................. 45
ISO/IEC 14598 ................................................................................................................................ 46
Norma ISO/IEC 14598 e ISO/IEC 9126 ...................................................................................... 48
Norma ISO/IEC 14598 ................................................................................................................... 48
Parte 1 - Descripción General ...................................................................................... 50
Proceso de Evaluación .......................................................................................................... 50
Parte 2 - Planificación y Gerenciamiento ...................................................................... 52
Parte 3 - Proceso para Desarrolladores ....................................................................... 53
Parte 4 - Proceso para Adquirientes ............................................................................. 54
Parte 5 - Proceso para Evaluadores ............................................................................. 55
ISO 25000 ........................................................................................................................................ 57
Introducción ..................................................................................................................................... 58
Definición ..................................................................................................................... 59
Niveles ......................................................................................................................... 59
Certificación ................................................................................................................. 61
AQC Lab: Laboratorio de Evaluación de la Calidad Software ....................................... 62
Basado en la nueva familia ISO/IEC 25000 SQuaRE ................................................... 62
Beneficios de nuestros clientes .................................................................................... 63
Cosas curiosas ............................................................................................................................... 64
Evaluación del producto ............................................................................................... 64
4
Motivos para la evaluación ........................................................................................... 64
ISO/IEC 20000 ................................................................................................................................ 66
Introducción ..................................................................................................................................... 67
Definición ..................................................................................................................... 68
Objetivos de la norma ISO 20000 ................................................................................. 68
Características ............................................................................................................. 68
Atributos ....................................................................................................................... 70
Niveles o Etapas .......................................................................................................... 71
Aplicación ..................................................................................................................... 71
¿Certificable? ............................................................................................................... 71
Casos de éxito ............................................................................................................. 72
Cosas curiosas ............................................................................................................. 73
ISO/IEC 38500 ................................................................................................................................ 76
Introducción.................................................................................................................. 77
Definición ..................................................................................................................... 78
Características ............................................................................................................. 78
Atributos o principios .................................................................................................... 78
Marco de trabajo .......................................................................................................... 81
Casos de éxito ............................................................................................................. 81
ISO/IEC 27000 ................................................................................................................................ 83
NYSE NMX-1-059-/02 Moprosoft y Evalsoft .............................................................................. 95
IEEE 828 ........................................................................................................................................ 104
Introducción ................................................................................................................................... 105
IEEE 828 ........................................................................................................................................ 106
Objetivo .......................................................................................................................................... 106
Etapas y Descripción de lo que el Estándar IEEE 828 Requiere ......................................... 108
1. Introducción ........................................................................................................................... 108
1.1. Propósito ......................................................................................................... 108
1.2. Alcance ............................................................................................................ 108
1.3. Definiciones ..................................................................................................... 108
1.4. Referencias ..................................................................................................... 108
2. Gestión de Configuración del Software (SCM) ................................................................ 109
2.1. Organización de SCM ...................................................................................... 109
5
2.2. Responsabilidades de SCM ............................................................................. 109
3. Actividades de la Gestión de Configuración del Software (SCM) ................................. 109
3.3. Identificación de la configuración ..................................................................... 110
3.3.1. Identificación de los ítems de configuración ................................................. 110
3.3.2. Denominación de los ítems de configuración ............................................... 110
3.3.3. Recuperación de los ítems de configuración ................................................ 112
3.4. Control de configuración .................................................................................. 113
3.4.1. Solicitud de cambios .................................................................................... 113
3.4.2. Evaluación de cambios ................................................................................ 113
3.4.3. Aprobación o desaprobación de cambios ..................................................... 113
3.4.4. Implementación de los cambios ................................................................... 113
3.5. Estado de la configuración ............................................................................... 114
3.6. Auditorías de configuración ............................................................................. 114
3.7. Control de interfaces ........................................................................................ 114
3.8. Control de subcontratos y vendedores ............................................................. 115
4. Recursos de SCM ................................................................................................................ 115
5. Mantenimiento del plan GCS .............................................................................................. 115
Ventajas y Desventajas de IEEE 828 ........................................................................................ 116
IEEE 830 ........................................................................................................................................ 117
Introducción................................................................................................................ 118
Definición, Características, Etapas ............................................................................. 119
BIBLIOGRAFÍA ............................................................................................................................. 129
Tablas
Tabla 1: Familia del estándar ISO/IEC 9126. (Vaca, S., & Libardo, W., 2008) ................ 10
Tabla 2: Relación entre métricas CK, la procedencia (Marín, B., Condori-Fernández, N., &
Pastor O., 2007), ............................................................................................................ 14
Tabla 3: Relación entre métricas de Li y Henry, (Marín, B., Condori-Fernández, N., &
Pastor O., 2007). ............................................................................................................ 14
Tabla 4: Diferencia entre la versión de SQuaRE y la ISO 9126-1 (Marín, B., Condori-
Fernández, N., & Pastor, 2007). ...................................................................................... 17
Tabla 5: Descripción de las partes de la estructura de la ISO/IEC 15504 (Casco, G.,
Trevisa, D., Molinas, A., & Molinas, N., 2008, p.19). ........................................................ 32
6
Tabla 6: Comparativa de la ISO/IEC 15504 contra CMMI Villa, M., Ruíz, M., & Ramos, I.,
(op.Cit, s.f, p. 13). ............................................................................................................ 35
Tabla 7: Estándares que tratan sobre el mantenimiento Tomado de: (Martínez Párraga
Juan Angel, 1999). ........................................................................................................... 45
Tabla 8: Certificación con la norma ISO 20000: .............................................................. 72
Tabla 9: Actividades de SCM definidas en el modelo de proceso. Tomada de Guía de
SCMP (pag7) ................................................................................................................. 115
Ilustraciones
Ilustración 1: Aspectos de la calidad (Figueroa Fermín, 2009). .............................................. 11
Ilustración 2: Características y subcaracterísticas de la calidad del software en el estándar
ISO/IEE 9126 (Figueroa Fermín, 2009). .................................................................................... 11
Ilustración 3: Características de la vista en uso (Morilla, José Joaquín Ruiz, 2008). .......... 15
Ilustración 4: Relación entre ISO 9126 e ISO 14598 (Pérez, M., Díaz-Antón, ..................... 16
Ilustración 5: Vista General de los procesos .............................................................................. 21
Ilustración 6: Vista de los procesos ............................................................................................. 23
Ilustración 7: Vista de los procesos ............................................................................................. 24
Ilustración 8: Vista de las actividades. ........................................................................................ 25
Ilustración 9: Estructura de la ISO/IEC 15504 García, C., & Garzás, J., la certificación por
niveles de madurez de ISO/IEC 15504 (2008, p.2). ................................................................ 31
Ilustración 10: Niveles de la ISO/IEC 15504 (Ávila, M.T., 2010). ........................................... 33
Ilustración 11: Comentarios creación propia. ............................................................................. 37
Ilustración 12 – Relación entre ISO/IEC 14598 y ISO/IEC 9126. Tomada de (Marcelo
Caponi) ............................................................................................................................................. 48
Ilustración 13 – Proceso de evaluación de la ISO 14598 en conjunto con la ISO 9126.
Tomado de (Montoto, 2012) ......................................................................................................... 51
Ilustración 14: Niveles de la ISO 25000 (Rodríguez Monje Moisés, 2010). .......................... 60
Ilustración 15: Cambios de la norma ISO 25000 (Rodríguez Monje Moisés, 2010) ............ 60
Ilustración 16: Herramientas para evaluar calidad del software (Rodríguez Monje Moisés,
2010). ............................................................................................................................................... 61
Ilustración 17: Certificación (ISO 25000.com, 2013). ............................................................... 62
Ilustración 18: Beneficios para evaluar producto de software (ISO 25000.com, 2013). ..... 65
Ilustración 19: Proceso de gestión de servicios de la norma ISO 20000 (Raúl Álvarez,
2007). ............................................................................................................................................... 71
Ilustración 20: Modelo de Gobierno Corporativo de TIC. Certificación. ................................. 80
Ilustración 21: Proceso de certificación de conformidad ISO 38500 (Carlos Manuel
Fernández, 2011). .......................................................................................................................... 80
Ilustración 22: ISO 27000 Tomado de: http://www.grupotreinar.com .................................... 84
Ilustración 23: Historia de ISO 27001 Tomado de: (ISO27000, 2013). ................................. 86
Ilustración 24: Modelo de procesos de una organización a la norma ISO 27000 ................ 91
7
Ilustración 25: Evolución de certificaciones ISO 27001 en México Tomada de: (ISO, 2013).
........................................................................................................................................................... 94
Ilustración 26: Distribución Mundial de certificaciones en ISO/IEC 27001 en 2012 ............ 94
Ilustración 27Modelos de referencia para Moprosoft (uvmnet.omargaona.com, 2013, pag
11) ..................................................................................................................................................... 97
Ilustración 28: Estructura de Procesos (uvmnet.omargaona.com, 2013, pag 15) ............... 98
Ilustración 29: Procesos de la gestión de negocios (uvmnet.omargaona.com, 2013, pag
17) ..................................................................................................................................................... 98
Ilustración 30: Categorías de la gestión (uvmnet.omargaona.com, 2013, pag 18) ............. 99
Ilustración 31: Categorías de la operación (uvmnet.omargaona.com, 2013, pag 26) ....... 100
Ilustración 32: Niveles por proceso de Moprosoft (uvmnet.omargaona.com, 2013, pag 8)
......................................................................................................................................................... 100
Ilustración 33: Actividades de una fase (uvmnet.omargaona.com, 2013, pag 33) ............ 101
Ilustración 34: Proceso de ejecución de Moprosoft (uvmnet.omargaona.com, 2013, pag 5)
......................................................................................................................................................... 102
Ilustración 35: Representación gráfica de Moprosoft (uvmnet.omargaona.com, 2013, pag
14) ................................................................................................................................................... 103
Ilustración 36: Modelo Cascada IEEE Std. Tomada de: La confiabilidad. J. L. Roca ....... 107
Ilustración 38: Procesos de identificación de la configuración. Tomada de: Diseño e
implementación del proceso de gestión de la configuración de software en la empresa de
desarrollo Venture Venti. ............................................................................................................. 110
Ilustración 39: El ciclo de vida del software. Tomada de Ingeniería del software por
Sommerville ................................................................................................................................... 119
8
ISO/IEC 9126
9
INTRODUCCIÓN
En este proyecto se recopila diferentes investigaciones donde se muestra el
estándar ISO 9126, el cual establece un modelo de calidad de cierta multitud de modelos
de calidad, Por tanto, puede servir para validar la completitud de una definición de
requisitos, identificar requisitos de calidad de software, objetivos de diseño y prueba,
criterios de aseguramiento de la calidad, etc. Esta norma posee distintas etapas donde
solo la primera es un estándar aprobado y publicado, tiene ciertas características que
identifica la calidad del producto del software, aplicaciones, atributos y métricas. Además
muestra la evolución que ha tenido esta norma y la relación que tiene con diferentes ISO.
10
“En 1991, la Organización Internacional de Estándares (ISO) en conjunto con la
Comisión Electrotécnica Internacional (IEC) propusieron un estándar para la evaluación
de la calidad del software, denominado ISO 9126” (Marín, B., Condori-Fernández, &
Pastor, 2007, le falta la página).
La ISO/IEC 9126 Software Engineering – Product Quality (Ingeniería en software –
Calidad del productos) es un estándar internacional para la evaluación del Software
dirigido para los desarrolladores, adquirentes, personal que asegure la calidad y
evaluadores independientes, responsables de especificar y evaluar la calidad del producto
software (Figueroa Fermín, 2009).
La norma ISO/IEC 9126 se compone de cuatro etapas, ver tabla 1:
Tabla 1: Familia del estándar ISO/IEC 9126. (Vaca, S., & Libardo, W., 2008)
Estándar ISO/IEC 9126-1
“Describe un modelo de calidad para productos software, dividiéndolo en dos
partes:
Calidad interna y externa
Especifica seis características para la calidad interna y externa, que se
subdividen posteriormente en subcaracterísticas. Estas subcaracterísticas
se manifiestan externamente cuando el software se usa como parte de un
sistema de computación, y son el resultado del análisis de los atributos
internos del software que son los elementos a tener en cuenta para
verificar las funciones del paquete a evaluar.
Calidad en uso
Esta parte del modelo especifica cuatro características de calidad de uso,
pero no elabora el modelo más allá de este nivel. La calidad en uso es el
efecto combinado para el usuario de las seis características de calidad del
software” (Vaca, S., & Libardo, W., 2008).
En la figura 1 se muestra de una forma más simple los diferentes aspectos de la
calidad (Quintero J. B., 2010).
11
Ilustración 1: Aspectos de la calidad (Figueroa Fermín, 2009).
Las características fundamentales de calidad del software para la ISO/IEE 9126 se
establece a partir de diez características, seis categorías de calidad que son comunes a la
vistas internas y externas y cuatro que son propias de la vista en uso, como se muestra
en la figura 2 (Marín, B., Condori-Fernández, & Pastor, 2007).
Ilustración 2: Características y subcaracterísticas de la calidad del software en el estándar
ISO/IEE 9126 (Figueroa Fermín, 2009).
“Como se muestra en la figura 2, cada una de las seis categorías está determinada
por subcategorías que la concretan, y éstas a su vez, por indicadores que permiten
12
detectar las bondades del producto software. A continuación se detalla esta
categorización.
Categoría Funcionalidad: subcategorizada por:
Adecuación: Capacidad del producto software para proporcionar un conjunto
apropiado de funciones para tareas y objetivos de los usuario especificados.
Exactitud: Capacidad del producto software para proporcionar los resultados o
efectos correctos o acordados, con el grado necesario de precisión.
Interoperabilidad: Capacidad del producto software para interactuar con uno o
más sistemas especificados.
Seguridad de acceso: Capacidad del producto software para proteger
información y datos de manera que las personas o sistemas no autorizados no
puedan leerlos o modificarlos, al tiempo que no se deniega el acceso a las
personas o sistemas autorizados.
Cumplimiento funcional: Capacidad del producto software para adherirse a
normas, convenciones o regulaciones en leyes y prescripciones similares
relacionadas con funcionalidad.
Categoría Fiabilidad: subcategorizada por:
Madurez: Capacidad del producto software para evitar fallar como resultado de
fallos en el software.
Tolerancia a fallos: Capacidad del software para mantener un nivel especificado
de prestaciones en caso de fallos del software o de infringir sus interfaces
especificadas.
Capacidad de recuperación: Capacidad del producto software para reestablecer
un nivel de prestaciones especificado y de recuperar los datos directamente
afectados en caso de fallo.
Cumplimiento de la fiabilidad: Capacidad del producto software para adherirse a
normas, convenciones o regulaciones relacionadas con la fiabilidad.
Categoría Usabilidad: subcategorizada por:
Inteligibilidad: Capacidad del producto software que permite al usuario entender
si el software es adecuado y cómo puede ser usado para unas tareas o
condiciones de uso particulares.
Facilidad de Aprendizaje: Capacidad del producto software que permite al
usuario aprender sobre su aplicación.
Operabilidad: Capacidad del producto software que permite al usuario operarlo y
controlarlo.
Atractividad: Capacidad del producto software para ser atractivo al usuario.
Cumplimiento de la usabilidad: Capacidad del producto software para adherirse
a normas, convenciones, guías de estilo o regulaciones relacionadas con la
usabilidad.
13
Categoría Eficiencia: subcategorizada por:
Comportamiento en el tiempo: Capacidad del producto software para
proporcionar tiempos de respuesta, tiempos de proceso y potencia apropiados,
bajo condiciones determinadas.
Utilización de recursos: Capacidad del producto software para usar las
cantidades y tipos de recursos adecuados cuando el software lleva a cabo su
función bajo condiciones determinadas.
Cumplimiento de la eficiencia: Capacidad del producto software para adherirse a
normas o convenciones relacionadas con la eficiencia.
Categoría Mantenibilidad: subcategorizada por:
Analizabilidad: Es la capacidad del producto software para serle diagnosticadas
deficiencias o causas de los fallos en el software, o para identificar las partes que
han de ser modificadas.
Cambiabilidad: Capacidad del producto software que permite que una
determinada modificación sea implementada.
Estabilidad: Capacidad del producto software para evitar efectos inesperados
debidos a modificaciones del software.
Capacidad de ser probado: Capacidad del producto software que permite que el
software modificado sea validado. Cumplimiento de la mantenibilidad: Capacidad del producto software para
adherirse a normas o convenciones relacionadas con la mantenibilidad.
Categoría Portabilidad: subcategorizada por:
Adaptabilidad: Capacidad del producto software para ser adaptado a diferentes
entornos especificados, sin aplicar acciones o mecanismos distintos de aquellos
proporcionados para este propósito por el propio software considerado.
Facilidad de Instalación: Capacidad del producto software para ser instalado en
un entorno especificado.
Coexistencia: Capacidad del producto software para coexistir con otro software
independiente, en un entorno común, compartiendo recursos comunes.
Intercambiabilidad: Capacidad del producto software para ser usado en lugar de
otro producto software, para el mismo propósito, en el mismo entorno.
Cumplimiento de portabilidad: Capacidad del producto software para adherirse a
normas o convenciones relacionadas con la portabilidad” (Cristancho, J. A., 2001).
En la segunda, tercera y cuarta parte de la ISO 9126 se describen métricas y
atributos para evaluar la calidad del software. El atributo corresponde a una propiedad de
calidad a la que puede asignársele una métrica, y ésta, se describe como un
procedimiento que examina un componente y produce un dato simple (Vaca, S., &
Libardo, W., 2008).
14
Para esta situación, ha surgido la relación de métricas con las características y
sub-características de calidad definidas en el estándar ISO 9126, las cuales se presentan
algunos ejemplos en las siguientes tablas 2 y 3 (Marín, B., Condori-Fernández, & Pastor,
2007).
Tabla 2: Relación entre métricas CK, la procedencia (Marín, B., Condori-Fernández, N., & Pastor O., 2007),
Tabla 3: Relación entre métricas de Li y Henry, (Marín, B., Condori-Fernández, N., & Pastor O., 2007).
15
Se han mencionado detalladamente las características de las seis categorías de calidad
que son referente a las vistas internas y externas, mientras que las características propias
de la vista en uso, se muestra en la Figura 3 (Pérez, 2002).
Ilustración 3: Características de la vista en uso (Morilla, José Joaquín Ruiz, 2008).
“Efectividad
Capacidad del software de facilitar al usuario alcanzar objetivos con precisión y
completitud.
Productividad
Capacidad del software de permitir a los usuarios gastar la cantidad apropiada de
recursos en relación a la efectividad obtenida.
Seguridad
Capacidad del software para cumplir con los niveles de riesgo permitidos tanto para
posibles daños físicos como para posibles riesgos de datos.
Satisfacción
16
Capacidad del software de cumplir con las expectativas de los usuarios en un
contexto determinado” (Pérez, M., Díaz-Antón, G., Grimán, A., & Mendoza, L.,
2002).
A causa de estas características, “en el 2001, este estándar fue reemplazado por
dos estándares relacionados: el estándar ISO/IEC 9126, que especifica características y
métricas de la calidad del software; y el estándar ISO/IEC 14598, que especifica la
evaluación de productos de software.” La forma en que se relacionan estos estándares se
muestra en la Figura 4 (Vaca, S., & Libardo, W., 2008).
Ilustración 4: Relación entre ISO 9126 e ISO 14598 (Pérez, M., Díaz-Antón,
G., Grimán,. Mendoza, L., 2002)
“Como comentado anteriormente, la serie ISO/IEC 9126 fue separada en las series
9126 y 14598 porque el modelo de calidad y las métricas son útiles no solo para la
evaluación del producto, sino también para otro objetivo de incluir la especificación de
requisitos de calidad. La evaluación de la calidad es posible y significativa cuando los
requisitos de calidad son claramente especificados. Sin embargo, si el estándar de
requisitos de calidad es propuesto no como una parte de las series pero como un
estándar independiente, entonces esto provocará confusión a los usuarios.
Por lo tanto, SQuaRE nace para solucionar los problemas expuestos
anteriormente por las normas ISO 9126 e ISO 14598.
Los mayores beneficios de la serie SQuaRE sobre sus predecesores estándares
incluyen:
La coordinación de dirección sobre la medida y evaluación de calidad del
producto software.
Dirección para la especificación de requisitos de calidad del producto
software.
17
Armonización con ISO/IEC 15939 en forma de modelo de referencia de
modelo de calidad presentado en el estándar SQuaRE.
Esta norma es para usarse en conjunción con las otras partes de los estándares
de la serie SQuaRE, y con ISO/IEC 14598 hasta ser reemplazado por las series ISO/IEC
25000. A continuación mostraremos las diferencias entre la última versión de SQuaRE y
la ISO 9126-1” (Morilla, José Joaquín Ruiz, 2008).
Tabla 4: Diferencia entre la versión de SQuaRE y la ISO 9126-1 (Marín, B., Condori-Fernández, N., & Pastor, 2007).
18
ISO/IEC 12207
19
INTRODUCCION
“El mercado del software representa uno de los ingresos económicos más significativos
en el mundo, ya que ofrece múltiples fuentes de negocio y es una gran oportunidad para
los países que se encuentran actualmente en vía de desarrollo. Ahora bien enfocándonos
en nuestro país podemos determinar que lastimosamente no hay muchas empresas que
estén preparadas para una competitividad a nivel mundial, ya sea por falta de
procedimientos o certificaciones que fundamenten la calidad de sus productos, por lo cual
es muy importante considerar una variedad de normas, procedimientos, métodos y
entornos para desarrollar y gestionar software” (Yorely Brigeth Ceballos Cardona, L. A.
(11 de Marzo de 2013)).
En este documento usted leerá sobre la ISO 12207 la cual trata sobre el ciclo de vida del
software, esta ISO se creó para establecer una norma de procedimientos, métodos,
herramientas para gestionar el software.
Es una sucesión de etapas por las que pasa el software en su desarrollo, desde que se
concibe la idea hasta que el software deja de utilizarse.
¿Para qué conocer esta ISO? Esta ISO aplica para cualquier software dado que contiene
procesos, actividades y tareas para la explotación y mantenimiento del software.
20
ISO 12207 Descripción general de la norma ISO 12207
Según (Moore, J (22 de junio)) “La ISO 12207 proporciona un marco para los procesos del
ciclo de vida del software, desde el concepto a través de la jubilación. Es especialmente
adecuado para las adquisiciones, ya que reconoce las distintas funciones de adquirente y
el proveedor. De hecho, la norma es para uso de dos partidos en un acuerdo o contrato
define el desarrollo, mantenimiento y operación de un sistema de software. No es
aplicable a la compra de productos de software.
En la mayoría de los casos, la 12207 utiliza lenguaje normas convencionales: "debe" para
indicar disposiciones obligatorias, "debería" para las recomendaciones, y "puede" para las
acciones permisibles. Dado que la norma se aplica tanto a comprador y proveedor, se
podría esperar que para colocar los requisitos obligatorios para ambas partes. Su
lenguaje, sin embargo, hace una sutil distinción: las disposiciones que se aplican a la
entidad adquirente utilice normalmente el verbo "podrá", que denota una "declaración de
propósito o intención de una parte," no es un requisito.
ISO 12207 proporciona una estructura de procesos utilizando la terminología aceptada
mutuamente, en lugar de dictar un modelo de ciclo de vida en particular o método de
desarrollo de software. Dado que es un documento relativamente alto nivel, 12207 no
especifica los detalles de cómo llevar a cabo las actividades y tareas que comprenden los
procesos. Tampoco prescribe el nombre, formato o contenido de la documentación. Por lo
tanto, las organizaciones que buscan aplicar la 12207 desean utilizar las normas o
procedimientos adicionales que especifican los detalles.
ISO 12207 describe cinco "procesos primarios" - la adquisición, suministro, desarrollo,
mantenimiento y operación. Divide a los cinco procesos en "actividades", y las actividades
en "tareas", mientras que la colocación de los requisitos sobre su ejecución. También
especifica ocho "procesos de apoyo" - documentación, gestión de la configuración, control
de calidad, verificación, validación, revisión conjunta, auditoría y resolución de problemas
-, así como cuatro "procesos organizacionales" - la gestión, infraestructura, mejoramiento,
y la formación.
La norma ISO tiene la intención de que las organizaciones adaptar estos diecisiete
procesos para ajustarse al ámbito de sus proyectos en particular mediante la eliminación
de todas las actividades inaplicables, y define 12207 cumplimiento como el desempeño de
los procesos, actividades y tareas seleccionadas mediante la adaptación” (Moore, J.
(s.f.) (22 de junio)).
21
Según (Arroyo, V. S (2011)) “El ISO/IEC 12207 es el estándar para los procesos de ciclo
de vida del software de la organización ISO. Este estándar se concibió para aquellos
interesados en adquisición de software, así como desarrolladores y proveedores. El
estándar indica una serie de procesos desde la recopilación de requisitos hasta la
culminación del software.
El estándar comprende 17 procesos lo cuales son agrupados en tres categorías:
o Principales.
o de apoyo.
o de organización.
Este estándar agrupa las actividades que se pueden llevar a cabo durante el ciclo de vida
del software en cinco procesos principales, ocho procesos de apoyo y cuatro procesos
organizativos. Cada proceso del ciclo de vida está divido en un conjunto de actividades;
cada actividad se sub -divide a su vez en un conjunto de tareas. A continuación se
presenta una imagen representando los procesos.
Ilustración 5: Vista General de los procesos
Recuperado de Arroyo, V. S. (s.f.)
2011)(http://unfviso12207.webcindario.com/index.php?mod=contenido_inicial).
Los procesos principales del ciclo de vida son cinco los cual brindan servicios a las partes
principales durante el ciclo de vida del software. Una parte principal es aquella que inicia o
22
lleva a cabo el desarrollo, operación, o mantenimiento de los productos software. Estas
partes principales son el adquiriente, el proveedor, el desarrollador, el operador y el
responsable de mantenimiento de productos software.
Las actividades y tareas en un proceso de apoyo son responsabilidad de la organización
que lleva a cabo dicho proceso. Esta organización se asegura que el proceso existe y
está operativo.
Los procesos organizativos del ciclo de vida son cuatro. Se emplean por una organización
para establecer e implementar una infraestructura constituida por procesos y personal
asociado al ciclo de vida y para mejorar continuamente esta infraestructura. Se usan
habitualmente fuera del ámbito de proyectos y contratos específicos; sin embargo, la
experiencia adquirida mediante dichos proyectos y contratos contribuye a la mejora de la
organización” (Arroyo, V. S. (s.f.) (2011)).
“¿Qué es el Ciclo de Vida del SW?
Es una sucesión de etapas por las que pasa el software en su desarrollo, desde que se
concibe la idea hasta que el software deja de utilizarse (obsolescencia).
Cada etapa lleva asociada una serie de actividades y tareas que se deben realizar, y una
serie de documentos que serán la salida de cada una de estas fases y que servirán de
entrada a la fase siguiente.
“Es un marco de referencia que contiene los procesos, las actividades y las tareas
involucradas en el desarrollo, explotación y mantenimiento de un producto software,
abarcando la vida del sistema desde la definición de requisitos hasta que se deja de
utilizar”.
¿Qué es un proceso?
Un proceso es un conjunto de actividades que se suceden siguiendo una ordenación
temporal determinada.
¿Qué es una actividad?
Una actividad es un conjunto de tareas.
¿Qué es una tarea?
Una acción que transforma unas entradas en unas salidas.
23
Ilustración 6: Vista de los procesos
Recuperado de(http://www.kybele.etsii.urjc.es/docencia/IS_LADE/2010-2011/Material/%5BIS-LADE-2010-
11%5DTema2.CicloVidaSW.pdf)
Fases genéricas en el ciclo de vida del SW:
Fase de definición. Tareas:
Ingeniería de sistemas.
Planificación del proyecto del SW.
Análisis de los requisitos.
Fase de desarrollo. Tareas:
Diseño del SW.
Generación de código.
Prueba del SW.
Fase de mantenimiento. Cambios:
Corrección.
Adaptación.
Mejora.
Prevención”.
(Sanz, M. L. (17 de Septiembre de 2010)).
“La norma ISO12207 divide la gestión de la Calidad en proyectos de software dividiéndolo
en procesos, dividiendo estos a su vez en Actividades.
Proceso: Un proceso puede ser definido como un conjunto de actividades enlazadas
entre sí que, partiendo de una o más entradas los transforman, generando un output
(resultado).
24
Las entradas por lo general se pueden dividir en 2 tipos, las que se consumen "recursos"
como papel, tinta, formularios, materias primas, etc. Los que no se consumen, como un
algoritmo para realizar un producto, información actual del mercado. Entonces todas las
funciones que se realizan en una empresa pueden ser vistas como procesos. Como por
ejemplo el proceso que debe seguirse para tratar una queja, el proceso de ensamblado de
algún producto, etc.”
Ilustración 7: Vista de los procesos
Recuperado de(http://juanmarcosteoria2.blogspot.mx/2008/01/normas-iso-12207.html)
Actividad, es un conjunto de tareas, que son fruto de subdividir un proceso.
25
Ilustración 8: Vista de las actividades.
Recuperado de (http://juanmarcosteoria2.blogspot.mx/2008/01/normas-iso-12207.html)
Tarea, es la unidad atómica de un proceso, consiste en un paso del algoritmo para
realizar una Actividad, y un proceso puede estar compuesto de varias actividades”
(Chacon, J. M. (15 de abril de 2012)).
CERTIFICACIÓN
Según (Yorely Brigeth Ceballos Cardona, L. A. (2013)) “Sudáfrica constituye el único país
que hasta ahora ofrece certificación oficial ISO 12207:2008.Este servicio eventualmente
se expandirá a otros países. Las empresas, sin embargo, ponen en práctica la filosofía de
la ISO 12207 en previsión de necesidades futuras para cumplir con estas normas.
Además, la certificación de la norma ISO 9001, que representa un conjunto de normas de
gestión de calidad bien adoptadas en el mundo, introduce algunos de los requisitos de
ISO12207.
Para cumplir con la norma ISO 12207, es necesario demostrar que tienes un documento
de requerimientos que captura las expectativas del cliente. Luego, el plan del proyecto
debe demostrar que se inició con una arquitectura de alto nivel, dividiendo el proyecto en
módulos independientes. Siguiendo la escritura y depuración del código, tu equipo debe
participar en pruebas de integración que combinen varios módulos juntos. El último
requisito exige una verificación del sistema que compara el software en su entorno final
para cada elemento del documento de requerimientos.
LIMITACIONES
Esta norma no realiza un detalle completo de los procesos, en términos de
métodos o procedimientos necesarios para el cumplimiento de los requisitos y
resultados de un proceso.
No presenta documentación detallada en términos de nombre, formato, contenido
explícito y medio de grabación, puede requerir de elaboración de diversos
documentos de características semejantes a la norma para su complementación.
Esta norma nos indica que debemos hacer en la empresa para encaminarse a la
calidad, pero no nos indica cómo hay que hacerlo.
RECOMENDACIONES DE LA NORMA ISO/IEC: 2008
La norma recomienda un marco común para los procesos de los ciclos de vida del
software, que nace de una idea o una necesidad, que puede ser satisfecha en
parte o en su totalidad por el software y que culmina con la jubilación del mismo.
Esta norma, no requiere la implementación de un modelo de ciclo de vida de
software, pero recomienda que para cada proyecto se defina el modelo de ciclo de
vida apropiado, de manera preferencial, un modelo que haya sido establecido por
la organización para manejar diversos proyectos.
26
Esta norma, no requiere un conjunto de etapas determinadas, por ejemplo en una
fase de ciclo de un sistema interviene: concepto, desarrollo, producción,
utilización, apoyo y jubilación, o el caso de un ciclo de vida de un productos de
software: desarrollo, operación y mantenimiento” (Yorely Brigeth Ceballos
Cardona, L. A. (11 de Marzo de 2013)).
Cosas Curiosas
El estándar 12207 se relaciona con normas de calidad, especialmente la “ISO
9001: Sistemas de calidad modelos para la garantía de calidad en la concepción,
desarrollo, producción, instalación y prestación de servicios”.
Tiene una gran relación con la segunda parte de la norma “ISO/IEC 15504:
Tecnologías de la información Evaluación de los procesos de software”.
La norma ISO/IEC 12207 realiza evaluaciones al final de cada proceso, tomando
en cuenta aspectos como: viabilidad, seguimiento a los requerimientos del
software y consistencia a todo el diseño, antes de pasar al siguiente proceso, lo
cual reduce las probabilidades de retroceder entre uno y otro proceso para
verificar si hubo errores; esto agilizara el desarrollo y aumentara el control de
errores que se puedan suscitar en los desarrollos de software.
Para el éxito de la implementación del estándar es necesario realizarlo lo más conciso y
claro posible para facilitar al personal de la organización su entendimiento y fácil
aplicación en proyectos de desarrollo tomando en base las necesidades del departamento
de sistemas.
27
ISO/IEC 15504
28
INTRODUCCIÓN
En la siguiente antología se pretende dar una introducción de la ISO/IEC 15504, la
norma para el valuar el nivel de madurez de los procesos de una empresa y que con
ayuda de la ISO 12207 también se encarga de describir el ciclo de vida del software.
Esta antología mostrará las principales características que componen a las
ISO/IEC 15504 así como también contendrá una comparativa entre la ISO/IEC 15504 y el
modelo CMMI con el cual tiene una gran compatibilidad, todo esto con el objetivo principal
de dar a conocer los alcances de cada una de ellas, cuál es la que se está aplicando más
actualmente en las empresas, cuál es la que convendría utilizar dependiendo de sus
capacidades y su costo para poder implantarla.
29
HISTORIA
“En enero de 1993 la comisión ISO/IEC JTC1 aprobó un programa de trabajo para
el desarrollo de un modelo que fuera la base de un futuro estándar internacional para la
evaluación de los procesos del ciclo de vida del software. Este trabajo recibió el nombre
de proyecto SPICE (Software Process Improvement and Capability dEtermination), y en
junio de 1995, con la publicación de su primer borrador, desde ISO fueron invitadas
diferentes organizaciones para aplicarlo y valorar sus resultados” (“International Best
Practice Institute”, s.f.).
“El proyecto SPICE tenía tres objetivos principales:
Desarrollar un borrador de trabajo para un estándar para la evaluación de
procesos de software.
Llevar a cabo los ensayos de la industria de la norma emergente.
Promover la transferencia de tecnología de la evaluación de procesos de software
a la industria del software a nivel mundial” (Ramos C.A., 2010).
“En 1998, pasada la fase de proyecto, y tras las primeras evaluaciones, el trabajo
pasó a la fase de informe técnico con la denominación ISO/IEC TR 15504. La instrucción
técnica consta de 9 apartados, recogidos en volúmenes independientes que se han ido
publicando como redacción definitiva del estándar internacional ISO/IEC 15504 durante el
periodo 2003 – 2005” “International Best Practice Institute” (op.Cit, s.f.).
DESCRIPCIÓN
“La norma ISO 15504 es utilizada para evaluar y mejorar la capacidad y madurez
de los procesos. Junto con la ISO 12207, la norma aplica a la evaluación y mejora de la
calidad de proceso de desarrollo y mantenimiento de software” (“Normaiso15504”, s.f).
“La norma ISO/IEC 15504 define un modelo de evaluación de procesos. Se trata
de una estándar internacional que permite evaluar la capacidad y madurez de los
procesos software de una organización” (“Aud[i]sec”, 2012).
30
CARACTERÍSTICAS
“La norma ISO/IEC 15504 tiene las siguientes características:
Modelo internacional basado en una combinación de estándares (ISO/IEC SPICE
15504, ISO/IEC 12207 que describe el ciclo de vida.
Cubre el ámbito completo de una organización.
Orientado a empresas de software o empresas con departamentos de desarrollo
de software.
Fácil de implantar.
Bajos costos de verificación en comparación con los otros estándares.
Obtención de un dictamen de conformidad de los procesos verificados en términos
de la Ley Federal sobre Metrología y Normalización.
Se implementan y verifican los procesos que la organización elija (previo análisis
de alcances) sin importar el tamaño de la organización (“NYCE”, s.f).
Establece un marco y los requisitos para cualquier proceso de evaluación de
procesos.
Comprende: evaluación de procesos, mejora de procesos, determinación de
capacidad.
Equivalencia y compatibilidad con CMMI. ISO forma parte del panel elaborador del
modelo CMMI y SEI mantiene la compatibilidad y equivalencia de ésta última con
15504” “Normaiso15504” (op.Cit, s.f).
ESTRUCTURA
La norma ISO/IEC 15504 proporciona un marco de trabajo para la evaluación de
los procesos y establece los requisitos mínimos para realizar una evaluación de forma
consistente. Actualmente esta norma está estructurada en siete partes como lo muestra la
Imagen 1.
31
Ilustración 9: Estructura de la ISO/IEC 15504 García, C., & Garzás, J., la certificación por niveles de madurez de ISO/IEC 15504 (2008, p.2).
Para poder comprender de manera más clara la estructura de la norma ISO/IEC
15504 la Tabla 5 muestra la definición de la parte 1 hasta la 5 que conforman la ISO. En
cuanto a la parte 1 y 2 se considera que está orientado a empresas de desarrollo y
mantenimiento de software, la parte 6 se basa principalmente en un ejemplo del modelo
para realizar la evaluación del ciclo de vida, la parte 7 se centra solamente en la
evaluación de la empresa según el nivel de madurez.
32
Tabla 5: Descripción de las partes de la estructura de la ISO/IEC 15504 (Casco, G., Trevisa, D., Molinas, A., & Molinas, N., 2008, p.19).
NIVELES
La imagen 2 ilustra de manera detallada los niveles de madurez de la norma
ISO/IEC 15504, como se puede notar tiene 6 niveles que van del 0 al 5 y el nivel de
madurez se obtiene de una evaluación de la capacidad de los procesos.
PARTES DE LA NORMA
ISO/IEC 15504 CONTENIDO
1. Conceptos y Vocabulario Proporciona una introducción general a los conceptos de la evaluación de
los procesos y un glosario de términos relacionados.
2. Realización de la
Evaluación
Establece los requisitos mínimos necesarios para realizar una evaluación
que garantice la consistencia y repetibilidad de las valoraciones. Los
requisitos ayudan a asegurar que la valoración de salida es consistente y
proporciona la evidencia necesaria para corroborar los resultados y verificar
su conformidad con los requisitos.
3. Guía para la Realización de
la Evaluación
Proporciona una guía para interpretar los requisitos a la hora de realizar una
evaluación.
4. Guía sobre el Uso para la
Mejora del proceso y la
Determinación de la
Capacidad del Proceso
Identifica la Evaluación del proceso como una actividad que puede ser
realizada como parte de una iniciativa de mejora de procesos o como parte
de un enfoque de determinación de la capacidad. El propósito de la mejora
de los procesos es mejorar de forma continua la eficiencia y efectividad de
la organización. El objetivo de la determinación de la capacidad es
identificar las fortalezas, debilidades y riesgos de los procesos
seleccionados respecto a un requisito particular especificado a través de los
procesos utilizados y de su alineamiento con las necesidades de negocio.
5. Un Ejemplo de Modelo de
Evaluación de Procesos (en
preparación)
Contiene un ejemplo de un modelo para realizar la evaluación de los
procesos basados en el modelo de referencia de procesos definido en el
estándar ISO/IEC 12207. Una evaluación se lleva a cabo utilizando un
modelo de evaluación de procesos relacionado con uno o más modelos de
referencia de procesos.
33
Ilustración 10: Niveles de la ISO/IEC 15504 (Ávila, M.T., 2010).
VENTAJAS
“Pueden contar con una norma ISO, internacional y abierta.
En España, la norma cuenta con el respaldo del Ministerio de Industria de España
ya que existen ayudas para la certificación de las PYMES y de AENOR.
34
Integración más fácil con otras normas ISO del sector TIC, como son: ISO 27000
de seguridad, ISO 20000 de servicios de IT e ISO 9000.
Evalúa por niveles de madurez, la evaluación más extendida entre los modelos de
mejora.
Normalmente, tiene un menor coste de certificación que otros modelos similares”
“Normaiso15504” (op.Cit, s.f).
“Reconocimiento en el mercado, siendo un factor diferenciador ante su
competencia.
Aumenta la satisfacción de sus clientes.
Mejora interna de su empresa” “Aud[i]sec” (op.Cit, 2012).
“Determinar las fortalezas y debilidades de los procesos.
Mejorar los procesos de software y medir sus mejoras.
Aquellos que adquieren un sistema para evaluar la capacidad de los proveedores
de sistemas.
Determinar los riesgos de negocio para una empresa que considera desarrollar un
nuevo producto de software o servicio” (“EcuRed”, 2013).
DESVENTAJAS
“Menos difundido internacionalmente.
Utiliza una ISO 12207 muy antigua.
Es muy pesada de implantar, además de requerir muchos procesos por nivel de
madurez.
Requiere excesivos indicadores y evidencias para demostrar que se sigue el
modelo.
La complejidad de la evaluación (y por consiguiente el costo) es significativamente
más alta que en otros modelos” (Villa, M., Ruíz, M., & Ramos, I., s.f, p. 13).
CERTIFICACIÓN “La creación de esquemas de certificación (o sellos de calidad) es respaldado por
agentes y entidades reconocidas por todas las partes es una solución que garantiza la
respuesta ante las empresas y sus clientes, dotando al modelo elegido de un mayor valor
35
añadido, además de la propia mejora que para la empresa supone la implantación del
modelo y por ende, la obtención del sello” Avila, M.T. (op.Cit, 2010).
Hablando de ISO 15504 en función de una evaluación externa realizada por
auditores cualificados por una entidad de certificación se audita y certifica el nivel de
madurez. “El proceso de auditoría está normalizado por ISO/IEC 15504-7:2008. El mismo
se realiza sobre la evaluación de la realización, planificación, definición, despliegue,
medición e innovación de los procesos en función del nivel de madurez al que aspira la
organización. De esta manera una organización que desarrolla e implanta software puede
ser auditada en frente a esta norma para certificar que nivel de madurez disponen de sus
procesos software, y por tanto medir la Calidad TIC en la que se está desarrollando su
trabajo” Avila, M.T. (op.Cit, 2010).
ISO/IEC 15504 vs CMMI
De acuerdo a las características de la ISO/IEC 15504 se puede notar que se
combina con la ISO/IEC 12207 la cual describe su ciclo de vida y que tiene una gran
compatibilidad con CMMI.
La tabla 6 muestra las semejanzas y diferencias que tiene la ISO/IEC 15504 y CMMI.
Tabla 6: Comparativa de la ISO/IEC 15504 contra CMMI Villa, M., Ruíz, M., & Ramos, I., (op.Cit, s.f, p. 13).
ISO/IEC 15504 CMMI
Ámbito de aplicación Software y sistemas Software y sistemas
En su favor Más consensuado y
probado.
El de mayor prestigio
En su contra Difícil en capacidad,
complejo de evaluar.
Difícil en entender, mayor
inversión, prescriptivo.
Procesos Delegado en ISO 12207,
por mayor aplicabilidad.
Estructura propia.
Validación ‘Trials’ y esfuerzo empírico. Encuesta satisfacción y
casos de estudio.
Objetivo Valoración de procesos y Mejora de proceso,
36
guía para la mejora. determinación capacidad
contratista.
Representación Contínua (por etapas a nivel
de proceso).
Contínua y por etapas.
Técnicas análisis Varias. Cuestionario de evaluación.
Para complementar la Tabla 2 se tiene la Tabla 3 la cual muestra otras de las
semejanzas y diferencias de la ISO/IEC 15504 y CMMI.
Tabla 7: Comparativa de la ISO/IEC 15504 contra CMMI creación propia.
ISO/IEC 15504 CMMI
Método para mejora de
procesos
SPICE 4° parte. IDEAL, mapa guíado.
Documentación Norma poco conocida por lo
tanto la documentación
escasa aún en inglés y de
pago.
Mucha más información y
gratuita.
Evaluación Solo se realiza una. Solo se realiza una.
Certificación Costo menor a la CMMI. Costo superior. Requiere
que personal de la empresa
a certificar haga el curso
oficial y la auditoria dura
varios días.
Certificador AENOR. Empresa Partner / Lead
Appraisal.
COSAS CURIOSAS
En la Tabla 3 se presentan algunas de las herramientas más utilizadas en las
empresas para la implantación de modelos de mejora de procesos software, indicando los
procesos a los que esa herramienta da apoyo.
37
Tabla 8: Herramientas más utilizadas para la implantación de modelos de mejoras de proceso (“Universidad de León”, 2011).
Ilustración 11: Comentarios creación propia.
38
ISO/IEC 14764
39
Introducción
Este estándar se encargada de dar a conocer y aclarar los requerimientos para el proceso
de mantenimiento del software y su objetivo es proporcionar una guía sobre la gestión o
como llevar a cabo el proceso de mantenimiento, por lo tanto esta ISO no es certificable.
"Eso da lugar a que dicho estándar proporciona una gran ayuda y facilidad de seguimiento
para tener claras ideas sobre el proceso de mantenimiento y su aplicación de modo que
identifica cómo el proceso de mantenimiento se puede realizar durante la adquisición y
operación" (Martínez, Juan Cesar & Ramírez Andonegui, Mariana E., s.f.).
A continuación se hablará de lo que se encarga esta ISO, así como sus características,
las fases o procesos que debemos de seguir para darle un buen mantenimiento al
software y como se aplica dicho estándar.
Definición
"ISO / IEC 14764 describe con mayor detalle la gestión del Proceso de Mantenimiento
descrito en la norma ISO / IEC 12207, incluyendo enmiendas. También establece las
definiciones de los diversos tipos de mantenimiento. Proporciona una guía que se aplica a
la planificación, ejecución y control, revisión y evaluación, y el cierre del proceso de
mantenimiento. El alcance de esta norma incluye el mantenimiento de múltiples productos
de software con los mismos recursos de mantenimiento. "Mantenimiento" en esta norma
significa el mantenimiento del software a menos que se indique lo contrario.
Proporciona el marco dentro del cual los planes genéricos y específicos de mantenimiento
de software se pueden ejecutar, evaluar y adaptar el alcance y la magnitud de
mantenimiento de productos de software dado. Proporciona el marco, la terminología y
procesos claros para permitir la aplicación coherente de la tecnología (herramientas,
técnicas y métodos) para el mantenimiento del software.
Proporciona una guía para el mantenimiento del software. La base para el proceso de
mantenimiento y sus actividades proviene de las definiciones de la norma ISO / IEC
12207. Define las actividades y las tareas de mantenimiento de software, y proporciona
los requisitos de planificación de mantenimiento. No se refiere a la operación del software
y las funciones operativas, por ejemplo, copias de seguridad, recuperación y
administración del sistema, que normalmente se llevan a cabo por aquellos que operan el
software.
Esta norma está escrita principalmente para los mantenedores de software y, además,
para los responsables del desarrollo y control de calidad. También puede ser utilizado por
los adquirentes y usuarios de sistemas que contengan software que pueden proporcionar
40
insumos para el plan de mantenimiento" (International Organization for Standardization,
2006).
Características
"Mantenibilidad
"La mantenibilidad es una característica de calidad del software (ISO 9126) que afecta a
la velocidad y facilidad con que podrá ser cambiado después de su puesta en operación
(utilización real por los usuarios). La mantenibilidad es una característica del software
importante tanto para el adquiriente, como para el suministrador y el usuario. Las
variaciones en el diseño deben ser supervisadas durante el desarrollo para establecer su
impacto sobre la mantenibilidad. Deben realizarse varios tipos de medidas para poder
estimar la calidad del software. La evaluación podrá ser cualitativa o cuantitativa.
Transición del software
La transición del software consiste en una secuencia controlada y coordinada de acciones
para trasladar un producto software desde la organización que inicialmente ha realizado el
desarrollo a la encargada del mantenimiento. Si la responsabilidad del mantenimiento se
transfiere a una organización distinta, se debería elaborar un plan de transición
incluyendo:
La transferencia de hardware, software, datos y experiencia desde el desarrollador
al mantenedor.
Las tareas necesarias para que el mantenedor pueda implementar una estrategia
de mantenimiento del software.
Documentación
El mantenedor a menudo se encuentra con un producto software con poca o ninguna
documentación. Si no hay documentación, el mantenedor deberá crearla (esto es parte
del mantenimiento perfectivo. Para ello deberá:
Comprender el dominio del problema (tipo de aplicación), leer cualquier
documentación (si la hubiese), discutir sobre el producto con los desarrolladores
(si es posible), y operar con el producto software.
Aprender la estructura y organización del producto software. Inventariarlo, aplicarle
el proceso de Gestión de la Configuración (CM). Reconstruirlo desde las librerías
CM, producir árboles de llamadas y analizar su estructura.
Determinar qué hace el producto software. Revisar las especificaciones (si las
hubiera), revisar la estructura general, analizar los árboles de llamadas, leer el
código y añadirle comentarios.
41
Documentos como especificaciones, manuales de mantenimiento para
programadores, manuales de usuario o guías de instalación deberán ser
modificados o creados, si fuese necesario" (Francisco Ruiz Macario Polo, 2001).
Fases
Este estándar define cambios en un producto software a través de un proceso de
mantenimiento dividido en fases. Este proceso es iterativo y en cascada, con una gran
semejanza al ciclo de vida del desarrollo clásico, tal y como se menciona en (Martínez
Párraga Juan Ángel, 1999). Estas fases son:
1. Identificación y Clasificación del Problema o de la Modificación.
2. Análisis.
3. Diseño
4. Implementación.
5. Pruebas del Sistema.
6. Pruebas de Aceptación.
7. Liberación del Producto.
"Fase 1: Identificación y clasificación del problema o de la modificación
En esta fase se identifican, clasifican y asignan una prioridad inicial a las modificaciones
del software. Cada Solicitud de Modificación será evaluada para determinar su
clasificación y prioridad. Esta contiene diversos cambios a realizar sobre los productos
software que posteriormente se agruparán en bloques de implementación. La clasificación
será identificada según los tipos de mantenimiento: correctivo, adaptativo, perfectivo y de
emergencia.
En esta fase los procedimientos a seguir son:
Asignación de un Número de Identificación.
Clasificación del tipo de mantenimiento.
Análisis de la modificación para determinar si se acepta, se deniega o se evalúa.
Realizar una estimación preliminar de la magnitud de la modificación.
Priorizar la modificación.
Asignar Solicitudes de Modificación a bloques de tareas planificadas para su
implementación.
Fase 2: Análisis
En esta fase se estudia la viabilidad y el alcance de las modificaciones, que ya tenemos
clasificadas y priorizadas, así como la generación de un plan preliminar de diseño,
42
implementación, pruebas y liberación del software. La información que se va a utilizar en
esta fase proviene del repositorio y de la Solicitud de Modificación validada en la fase
anterior, además de la documentación del proyecto y del sistema existente.
Fase 3: Diseño
A partir de toda la documentación existente del proyecto y del sistema que esté en
producción, así como todo el código fuente y las bases de datos de la última versión, se
va a realizar el diseño de las modificaciones del sistema en base a la documentación
generada en la fase de análisis (análisis detallado, informe de requisitos, identificación de
los elementos afectados, estrategia de pruebas y plan de implementación).
Fase 4: Implementación
Para dirigir apropiadamente el esfuerzo en la fase de implementación será necesario
disponer, como en las otras fases, de la documentación actualizada del proyecto y del
sistema, del código fuente actual, y los resultados de la fase de diseño (Martínez Párraga
Juan Ángel, 1999). Otros elementos necesarios para el éxito de esta fase serán:
Documentación de diseño y requisitos aprobados y controlados.
Estándar de codificación acordado para ser utilizado por el grupo de
mantenimiento.
Métricas de diseño que podrían ser aplicables en la fase de implementación
(podrían clarificar la complejidad del código a desarrollar o mantener).
Una planificación de desarrollo detallada, incluyendo todas las revisiones de
código que se harán y a qué nivel.
Un conjunto de respuestas a los riesgos identificados en las fases anteriores y que
serán aplicables en la fase de pruebas.
Fase 5: Pruebas del sistema
Las pruebas de sistema se realizan sobre un sistema modificado. Deberían ser realizadas
por una organización independiente y siempre estar presente el cliente y el usuario final.
La organización responsable de las pruebas del sistema deberá ser independiente de los
desarrolladores y diseñadores del software, pero podrían utilizarse como recursos para el
personal de pruebas.
Fase 6: Pruebas de aceptación
Al igual que las pruebas de sistema, las pruebas de aceptación serán realizadas sobre un
sistema completamente integrado. Estas pruebas se realizan por el cliente, por el usuario
o por un tercero designado por el cliente. Se llevan a cabo para asegurar que el resultado
de las modificaciones es satisfactorio para el cliente, tanto del software como de la
documentación generada.
43
Fase 7: Liberación del producto
Una vez probado completamente el sistema, estamos a punto de pasar a la fase de
liberación de la versión modificada. Para reducir los riesgos asociados con la instalación
de la nueva versión del sistema software, el jefe de proyecto debería planificarlo y
documentar los procedimientos de instalación alternativos, que podrían asegurar el
mínimo impacto sobre los usuarios del sistema debido a fallos del software imprevistos,
no detectados durante las pruebas. El plan deberá incluir factores críticos en tiempo, por
ejemplo, las fechas disponibles para la instalación, así como los procedimientos de
recuperación o vuelta atrás" (Martínez Párraga Juan Ángel, 1999).
Estándares que se relacionan con la ISO 14764
"Existen diversos estándares de otros tantos organismos internacionales de
estandarización que tienen una relación directa o indirecta con el Mantenimiento del
Software:
IEEE 1074
El IEEE 1074-1995, detalla el conjunto de actividades que aparecen obligatoriamente en
el desarrollo y mantenimiento del software. La clasificación se realiza dependiendo de que
los procesos sean de gestión de proyectos, antes del desarrollo, durante el desarrollo,
después del desarrollo o durante todo el ciclo de desarrollo de un producto software.
ISO 12207
En este estándar publicado en 1995, ISO/IEC 12207, se define el proceso de
mantenimiento como una parte principal del ciclo de vida del software. En él se definen los
procesos, actividades y tareas presentes en la adquisición, suministro, desarrollo,
operación y mantenimiento del software.
IEEE 1061
El IEEE 1061 provee una metodología para establecer requerimientos de calidad e
identificar, implementar, analizar y validar métricas de calidad de productos y procesos
software. La metodología es aplicable a todo el software en todas las fases de cualquier
estructura de ciclo de vida. En este estándar se establece la mantenibilidad como uno de
los factores de la calidad del software.
ISO 9126
En la nueva revisión de 1998 del estándar ISO 9126, se abordan las características que
determinan la calidad del software, tanto del producto como de los procesos para
desarrollarlo y mantenerlo.
44
IEEE 1219
Hasta 1998, único estándar que íntegramente se ocupa del proceso de Mantenimiento del
Software. En él se detalla un proceso iterativo para gestionar y realizar las actividades de
mantenimiento" (Martínez Párraga Juan Ángel, 1999).
Aplicación
"Éste estándar internacional intenta proporcionar una guía para situaciones con dos
individuos y se puede aplicar igualmente cuando los dos pertenecen a la misma
organización pero intenta también ser usado por un solo individuo como tareas que se
auto impone.
Éste estándar internacional no está dirigido a usuarios de productos software que no
están a la venta a menos que estén incorporados en producto para entregar (ISO/IEC
12207), ni está orientado a productos software que son soluciones a corto plazo de hecho
la mayoría de las empresas intentan usar un producto a un cierto tiempo pero más bien
largo para ello los productos que desean tener o incorporar deben mantenerse a un
tiempo lo más largo posible eso da lugar al ahorro de costes y por éste último el
mantenimiento de la empresa, ni está orientado para productos software personalizados
por los usuarios ni a productos para el usuario final. Está orientado a la auto-imposición
en los desarrolladores de productos software de procesos para el mantenimiento.
Por ejemplo, organizaciones que puedan desear usar éste estándar internacional cuando
mantengan macros ó plantillas usadas en la organización para el procesamiento de
palabras.
El mantenimiento se aplica a programas de ordenador, código, datos, y documentación.
Se intenta que se aplique a productos software creados durante el desarrollo del producto
software.
Ésta puede incluir cosas como software de pruebas, bases de datos de prueba, el Entorno
de Pruebas del Software (STE) o el Entorno de Ingeniería de Software (SEE).
Éste estándar internacional está pensado para su uso en todos los esfuerzos de
mantenimiento, independientemente del ciclo de vida o del enfoque usado en el
desarrollo" (Lamayzi Yassáa Samira, 1999).
Cosas curiosas
Tipos de mantenimiento
45
"El mantenimiento Correctivo se refiere a los cambios necesarios debidos a algún
error real en el software. Si el software no cumple los requerimientos debe hacerse
éste mantenimiento.
El Preventivo se refiere a los cambios efectuados debido a la detección de
posibles errores en el software. Se lleva a cabo en software que debe efectuar
tareas.
El Adaptativo y Perfectivo son mejoras del software. Estos cambios no estaban en
las especificaciones de diseño del software entregado. Los cambios Adaptativos
son los necesarios para acomodar el producto a un entorno cambiante" (Lamayzi
Yassáa Samira, 1999).
Otros estándares que tratan el mantenimiento
Tabla 9: Estándares que tratan sobre el mantenimiento Tomado de: (Martínez Párraga Juan Angel, 1999).
46
ISO/IEC 14598
47
Introducción
Cada vez se le asignan más tareas a las maquinas, las personas y las empresas se
vuelven más dependientes de la automatización de ciertas tareas usando software hecho
por terceros la mayoría de las veces. Algunas de estas tareas son de gran importancia y
en caso de obtener un resultado erróneo podría representar grandes pérdidas o incluso
ser el fin de la empresa. Por eso es necesario poder validar la calidad tanto del producto
de software como del proceso por el que fue realizado, para esto se usan estándares
como la norma ISO/IEC 14598 que es la explicada a continuación.
48
Norma ISO/IEC 14598 e ISO/IEC 9126
“La norma ISO/IEC 9126 define un modelo de calidad de propósito general, describe un
conjunto de características de calidad y brinda ejemplos de métricas. Mientras que la
norma ISO/IEC 14598 da una descripción general de los procesos para la evaluación de
productos de software así como también guías y requerimientos para la evaluación. Por
esta razón se recomienda su uso conjunto”. (Martínez & Ramírez Andonegui)
“Se entiende por calidad del software al grado en que el producto incorpora un conjunto
de características, definidas por la industria, de tal manera que se garantiza su eficiencia
de uso, respecto a os requerimientos de los clientes. Es decir, calidad de software es el
grado en el que un cliente percibe que el software cumple con sus expectativas”.
(Leonidas Muñoz Sagarvinaga)
La ilustración 1 muestra la relación entre la ISO/IEC 14598 y la ISO/IEC 9126.
Ilustración 12 – Relación entre ISO/IEC 14598 y ISO/IEC 9126. Tomada de (Marcelo Caponi)
Norma ISO/IEC 14598
49
“En el campo de Tecnología de la Información, ISO (International Organization for
Standardization) e IEC (International Electrotechnical Commission) han establecido un
comité técnico conjunto ISO/IEC JTC, el cual preparó el estándar internacional ISO/IEC
14598-1.
Según esta norma, los componentes fundamentales en la evaluación de la calidad del
software son:
Modelo de calidad.
Método de evaluación.
Medidas de software.
Herramientas de soporte.
Para el desarrollo de un producto de software correcto, deben especificarse los
requerimientos de calidad para poder medirlos de alguna forma. Además se debe planear,
implementar, y controlar el proceso para el aseguramiento de la calidad. Se deberán
evaluar tanto los productos intermedios como los finales.
Dependiendo de la etapa en el ciclo de vida que nos encontremos, y el propósito de la
evaluación, se determinarán que productos (intermedios o finales) serán evaluados.
Para la medición de los atributos de calidad que se definen debe cumplir el software, es
necesario utilizar métricas validadas.
Es importante tener claro que se entiende por métrica. En este estándar, se define como:
“Escala cuantitativa y métodos que serán utilizados para medir.”
La palabra “medida” es utilizada para hacer referencia al resultado de una medición.
La serie de estándares ISO/IEC 14598 brinda un conjunto de métodos para la medición y
evaluación de la calidad de un producto de software.
Es importante tener en cuenta que no describe métodos para la evaluación de los
procesos de desarrollo del software ni métodos para la predicción de costos. Para ello se
pueden utilizar las mediciones de la calidad del software”. (Marcelo Caponi)
Esta norma está compuesta de las siguientes partes con el título “Tecnología de la
Información – Evaluación de Productos de Software”
1. Parte 1: Descripción general
Provee una visión general de las otras cinco partes y explica la relación entre la
evaluación del producto software y el modelo de calidad definido en la ISO/IEC
9126
2. Parte 2: Planificación y gerenciamiento
Contiene requisitos y guías para las funciones de soporte tales como la
planificación y gestión de la evaluación del producto del software.
3. Parte 3: Proceso para Desarrolladores
50
Provee los requisitos y guías para la evaluación del producto software cuando la
evaluación es llevada a cabo en paralelo con el desarrollo por parte del
desarrollador.
4. Parte 4: Proceso para Adquirientes
Provee los requisitos y guías para que la evaluación del producto software sea
llevada a cabo en función a los compradores que planean adquirir o reutilizar un
producto de software existente o pre desarrollado.
5. Parte 5: Proceso para Evaluadores
Provee los requisitos y guías para la evaluación del producto software cuando la
evaluación es llevada a cabo por evaluadores independientes.
6. Parte 6: Documentación de los módulos de evaluación
Provee las guías para la documentación del módulo de evaluación (Montoto,
2012).
Parte 1 - Descripción General
“Brinda una idea general sobre las partes que constituyen la norma. Explica la relación
que existe entre las normas ISO/IEC 14598 e ISO/IEC 9126.
Da definiciones de los términos que utiliza y brinda un marco para evaluar la calidad de
todo tipo de producto de software y establece los requerimientos para los métodos de
medición y evaluación de dichos productos.
Esta norma está dirigida a Desarrolladores, Adquirientes y Evaluadores independientes,
sobre todo aquellos que son responsables para la evaluación del producto de software.
Los resultados obtenidos de aplicar esta norma pueden ser utilizados por:
Gerentes y Desarrolladores para medir el cumplimiento de los requerimientos y
realizar mejoras si es necesario.
Analistas para establecer relaciones entre métricas internas y externas.
Personal a cargo de la mejora de procesos para determinar cómo mejorar los
procesos a través del estudio de la información sobre la calidad de los productos
de software del proyecto.” (Marcelo Caponi)
Proceso de Evaluación
“Para evaluar la calidad del software, hay que establecer primero los requerimientos dela
evaluación, luego especificar, diseñar y ejecutar la evaluación.
Cada uno de estos pasos, se describe más en detalle, en las partes 3, 4 y 5 de la norma,
que además explica como el proceso de evaluación es aplicado en diferentes
circunstancias”. (Marcelo Caponi)
51
La ilustración 2 muestra el proceso de evaluación de la ISO/IEC 14598 y donde interviene
la ISO/IEC 9126.
Ilustración 13 – Proceso de evaluación de la ISO 14598 en conjunto con la ISO 9126. Tomado de (Montoto, 2012)
“Cuando se adquiere un producto de software a medida, el comprador debe establecer los
requerimientos de calidad externos, especificar los requerimientos al proveedor, y evaluar
el posible producto que comprará utilizando estos requerimientos antes de realizar la
compra.
Cuando se desarrolla un producto, el objetivo de especificar los requerimientos de calidad
es asegurar que el producto cumple con las necesidades implícitas y explícitas del
usuario. (Ver Parte 3 - Proceso para Desarrolladores).
Cuando se realiza la compra de un producto de software, la evaluación puede utilizarse
para comparar entre productos alternativos y para asegurarse que el producto
seleccionado cumple con los requerimientos de calidad (ver Parte-4 Proceso de
Adquirientes y Parte – 5 Proceso de Evaluadores).
Esta norma puede utilizarse conjuntamente con la norma ISO/IEC 9126, ya que el primer
paso en la evaluación es seleccionar las características de calidad importantes, utilizando
un modelo de calidad, que descompone la calidad de un software en diferentes
características. Precisamente, la norma ISO/IEC 9126 describe un modelo de calidad.
52
Un modelo de calidad para la evaluación de un producto de software representa la
totalidad de los atributos de calidad clasificados en una estructura jerárquica de
características y sub-características. En el nivel más alto se encuentran las características
y en el nivel más bajo los atributos de calidad del software.
Esta norma provee una guía y requerimientos para el proceso de evaluación desde tres
perspectivas:
Desarrollo (14598–3).
Adquisición (14598–4).
Evaluación (14598–5).”
Tal y como se menciona en (Marcelo Caponi).
Parte 2 - Planificación y Gerenciamiento
“Esta parte brinda detalles sobre la planificación y gestión de los requerimientos
asociados con la evaluación del producto de software. Tiene como objetivo explicar los
requerimientos que deben ser brindados por una organización para asegurarse el éxito de
la evaluación. Esta función de soporte puede ser parte de la organización.
En otras palabras, describe los requerimientos, recomendaciones y guías para la función
de soporte que es responsable de la gestión de la evaluación de un producto de software,
así como también de las tecnologías necesarias para llevarla a cabo.
El soporte está relacionado con la planificación y gestión del proceso de evaluación de
software y actividades asociadas.
Esta parte de la norma, está dirigida a las personas que son responsables de:
Administrar el uso de la tecnología para la evaluación
Dar soporte en la Evaluación del Software
Gestionar organizaciones de desarrollo de software
También para las personas que desempeñan tareas de Aseguramiento de la calidad.
El rol principal de la función de soporte es:
Adquirir estándares nacionales e internacionales
Desarrollar estándares apropiados y herramientas basándose en las necesidades
de la organización
Desarrollar criterios para determinar marcos para la evaluación
Colectar los resultados de la evaluación y difundirlos en la empresa
La función de soporte puede ser interna o externa a la organización. A su vez si es
interna, puede estar o no dentro del departamento que realiza la evaluación del producto.
53
La organización debe crear políticas y un plan para desarrollar todas las actividades de
evaluación. Esta norma brinda un template para documentar el Plan de Evaluación”.
(Marcelo Caponi)
Parte 3 - Proceso para Desarrolladores
“Proporciona directrices para aclarar los requisitos de calidad y para la aplicación y
análisis de las medidas de calidad de software. Esta parte de la norma ISO / IEC 14598
se aplica a todo el software en todas las fases de la ciclo de vida del desarrollo. Se centra
en la selección y presentación de los indicadores que son útiles para predecir el final la
calidad del producto mediante la medición de la calidad de los productos intermedios.
También se centra en la medición de la calidad del producto final.
Proporciona requisitos y recomendaciones para la práctica aplicación de la evaluación del
producto de software cuando la evaluación se lleva a cabo en paralelo con la desarrollo y
llevado a cabo por el desarrollador. En particular, puede ser utilizada para aplicar los
conceptos descrito en la norma ISO / IEC 9126-1, 2, 3 e ISO / IEC 14598-1, 2, 6.
El proceso de evaluación está diseñado para ser utilizado simultáneamente con el
desarrollo. El proceso de evaluación necesita ser sincronizado con el proceso de
desarrollo de software y las entidades sean evaluadas conforme se entregan.
Esta parte de la norma ISO / IEC 14598 puede ser utilizada por:
Un gerente de proyecto para aclarar los requisitos de calidad, para supervisar y
controlar la calidad del software durante el desarrollo y para la toma de decisiones
para asegurar que la calidad requerida.
Un diseñador de software para identificar las características específicas que deben
ser incorporados o cambiadas en el software para cumplir con los requisitos de
calidad.
Una garantía de calidad / control / auditoría responsable de evaluar si los
requisitos de calidad son alcanzados.
Un mantenedor de tomar decisiones para la implementación de cambios y
rediseño / reingeniería.
Un adquirente del software como parte de un acuerdo con un desarrollador en la
adquisición de software (por ejemplo, en el caso del desarrollo de software
outsourcing) cuando no se requiere una evaluación independiente. Los
compradores pueden ser personal de una función de compras, los desarrolladores
de subcontratación una parte del software de productos, o los usuarios finales. El
papel del adquirente depende del acuerdo entre la entidad adquirente y el
desarrollador. ISO / IEC 14598-4 describe la evaluación desde el punto de vista de
los adquirentes.”
Tal y como se menciona en (ISO/IEC, 2000)
54
Parte 4 - Proceso para Adquirientes
“Contiene los requisitos, recomendaciones y directrices para la medición sistemática, la
evaluación y la evaluación de la calidad del producto de software durante la adquisición
de productos de software "off-the-shelf" (de la estantería), productos de software a
medida, o modificaciones en los productos de software existentes.
Se utiliza el modelo de calidad del software que se describe en la norma ISO / IEC 9126-
1, se amplía en el proceso general de evaluación de la calidad del software que se define
en la norma ISO / IEC 14598-1, y utiliza el proceso de adquisición que se define en la
norma ISO / IEC 12207. Se puede utilizar en conjunción con la norma ISO / IEC 12119,
ISO / IEC 14598-2 (nuevo), ISO / IEC 14598-3 (nuevo) y la ISO / IEC 14598-6. Los pasos
del proceso de evaluación son similares entre esta parte de la norma ISO / IEC 14598 e
ISO / IEC 14598-5, pero el contexto de uso es muy diferente. En el caso de que los
adquirentes confían segunda o tercera partes con las evaluaciones, se requiere la norma
ISO / IEC 14598-5 para ser aplicado. En el caso de que los adquirentes requieren pruebas
de terceros de los paquetes de software en contra de los requisitos de calidad para el
paquete, ISO / IEC 12119 puede aplicarse.
El proceso de evaluación se describe en esta parte de la norma ISO / IEC 14598 también
ayuda a cumplir con los objetivos de la decisión sobre la aceptación de un solo producto,
o por seleccionar un producto entre productos alternativos. El proceso de evaluación
puede ser adaptado a la naturaleza y el nivel de integridad de la aplicación. También es lo
suficientemente flexible para dar cabida a la amplia gama de formas y usos de los
productos de software de una manera rentable.
Esta parte de la Norma ISO / IEC 14598 está diseñado para, pero no limitado a, los jefes
de proyecto, ingenieros de sistemas, desarrollo y mantenimiento del personal de
ingeniería de software y los usuarios finales que planean adquirir productos de software,
así como los proveedores que ofrecen este tipo de productos.
Los productos de software de destino del proceso de evaluación de esta parte de la
norma ISO / IEC 14598 se puede integrar en un sistema más amplio como componentes
o pueden usarse independiente. Se clasifican en:
1. Productos de software off-the-shelf (de la estantería) comerciales.
2. Los productos de software existentes desarrollados o adquiridos para otras
aplicaciones o para una amplia gama de aplicaciones comunes.
3. Los productos de software personalizado o modificaciones a los productos de
software existentes.
El proceso de evaluación que se define en esta parte también se aplica a las herramientas
de CASE. Debido a la evaluación de las herramientas CASE se aborda específicamente
en la norma ISO / IEC 14102, las herramientas CASE se consideran fuera del ámbito de
aplicación de esta parte de la norma ISO / IEC 14598.
55
ISO / IEC 14598-4 está diseñado para trabajar en colaboración con otras normas. Para
sistemas con requisitos de alta integridad, requisitos adicionales pueden ser incluidos en
el proceso de evaluación descrito en la norma ISO / IEC 14598-4, que se derivan de las
normas sectoriales específicas, por ejemplo, IEC 880, DOA-167A, MOD-55, etc.”
Tomado de (ISO 14598-4: Software Engineering - Product Evaluation - Part 4: Process for
Acquirers, 1999)
Parte 5 - Proceso para Evaluadores
“El estándar define el proceso con sus respectivas actividades y entregables. Este
proceso apunta a ser utilizado por laboratorios evaluadores, los cuales con este proceso
podrían brindar servicios de evaluación a otras empresas. Empresas desarrolladoras de
software, las que podrían tener un laboratorio de evaluación propio, el cual manteniendo
la suficiente independencia, podría lograr los mismos resultados. Adquirientes de software
los cuales conociendo el estándar podrían dado un producto que quieren adquirir, poder
contratar una institución evaluadora que realice una evaluación, y así poder determinar en
base a su calidad si comprarlo o no, o decidir entre varios, cual comprar. Usuarios de un
producto los cuales podrían dado un informe de evaluación, poder determinar si la calidad
del producto satisface sus requerimientos. Y en el caso de entidades certificadoras,
podrían utilizar el estándar para realizar normas de calidad de productos.
Dicho proceso a través de todas sus etapas, promueve las siguientes características de
proceso:
Repetible: Que el proceso bajo las mismas circunstancias, la misma configuración de las
herramientas utilizadas, el mismo producto y el mismo evaluador, la evaluación obtenga el
mismo resultado.
Reproducible: Es muy parecido a repetible pero no es lo mismo, ya que en este caso
deben mantenerse todas las condiciones iguales, salvo que el evaluador sea otro y en
este caso también se debe obtener el mismo resultado.
Imparcial: La evaluación debe resultar de los estudios realizados en esa instancia y no
deben estar influidos por resultados anteriores obtenidos para realizar la misma
evaluación.
Objetivo: El evaluador no debe influenciarse por sentimientos propios o prejuicios sobre el
producto u similares.
El proceso consta de 5 etapas:
1. Establecimiento de los Requerimientos
2. Especificación de la Evaluación
3. Diseño de la Evaluación
4. Ejecución de la Evaluación
56
5. Conclusión de la Evaluación
Si vemos el proceso como una “caja negra” notaremos que hay dos grandes entradas de
información, una es por parte del Cliente, el cual es el que está queriendo evaluar un
producto.
Y otra por parte del Evaluador, quien realizara efectivamente la evaluación. Este por
contraparte tendrá dos salidas, una es la evaluación propiamente dicha (informe) y la otra
son Registros de la Evaluación.” (Marcelo Caponi)
Comentarios y aspectos curiosos
La ISO 14598 solo evalúa si el resultado es de calidad, no específica los procesos
o guías para obtener la calidad.
Depende en gran medida de otras normas.
Casi siempre es necesario implementar la ISO/IEC 14598 con la ISO/IEC 9126,
por lo que se combinaron en la ISO 25000 (Square) para una mayor integración de
las normas.
Es considerada una norma de primera generación (la ISO 25000 es considerada
de segunda generación).
No solo puede aplicarlo una empresa que desarrolle software, también una que
quiera comprar software.
Tiene muy marcadas las partes para los diferentes roles (desarrollador, adquiriente
y evaluador).
57
ISO 25000
58
Introducción En la investigación que presentaremos a continuación tiene como propósito dar a conocer
al lector los conceptos de la norma ISO 25000, los niveles que la conforman, las normas
en que se basaron para crear la norma ISO 25000 y a su vez las primeas empresas que
están certificadas bajo esta norma.
Lo que nos motivó a realizar esta investigación fue la curiosidad de conocer más de esta
norma y no nada más quedarnos con el puro concepto y saber cómo certificar a una
empresa.
59
Definición “La calidad del producto, junto con la calidad del proceso, es uno de los aspectos más
importantes actualmente en el desarrollo de Software. Relacionada con la calidad del
producto, recientemente ha aparecido la familia de normas ISO/IEC 25000, que
proporciona una guía para el uso de la nueva serie de estándares internacionales llamada
Requisitos y Evaluación de Calidad de Productos de Software (SQuaRE - Product Quality
Requirements and Evaluation).
ISO/IEC 25000 constituye una serie de normas basadas en ISO/IEC 9126 y en ISO/IEC
14598 cuyo objetivo principal es guiar el desarrollo de los productos de software mediante
la especificación de requisitos y evaluación de características de calidad” (iso25000.com,
2013).
“La norma ISO 25000 constituye una serie de normas basadas en la ISO 9126 y en la ISO
14598 (Evaluación del Software), y su objetivo principal es guiar el desarrollo de los
productos de software con la especificación y evaluación de requisitos de calidad.
Establece criterios para la especificación de requisitos de calidad de productos software,
sus métricas y su evaluación. SQuaRE está formada por las divisiones siguientes:
ISO/IEC 2500n. División de dirección de calidad.
ISO/IEC 2501n. División del modelo de calidad.
ISO/IEC 2502n. División de medida de calidad.
ISO/IEC 2503n. División de requisitos de calidad.
ISO/IEC 2504n. División de evaluación de calidad.
ISO/IEC 25050-25099. Estándares de extensión SQuaRE.
SQuaRE, se trata de una revisión de la ISO 9126-1, y tiene las mismas características de
calidad de software. Hay dos aspectos importantes en el campo de la calidad del
software, el producto y el proceso. SQuaRE se centra en el lado del producto. SQuaRE
hereda el modelo de calidad de la ISO 9126-1. El modelo de ciclo de vida de la calidad del
producto software se basa en la calidad del producto software en tres fases principales del
ciclo de vida del producto software:
Producto bajo desarrollo: está sujeto a la calidad interna del software.
Producto en operación: está sujeto a la calidad externa del software.
Producto en uso: está sujeto de calidad de uso” (Pérez Yenny, 2012).
En seguida tocaremos el tema de los niveles en que está dividida la norma ISO 25000.
Niveles En la imagen 1 se muestra los niveles de la norma ISO 25000.
60
Ilustración 14: Niveles de la ISO 25000 (Rodríguez Monje Moisés, 2010).
En la imagen 2 se muestras los cambios que se hicieron al unir las normas ISO 9126 y
14598 para formar la norma ISO 25000.
Ilustración 15: Cambios de la norma ISO 25000 (Rodríguez Monje Moisés, 2010)
En la imagen 3 se muestra algunas de las muchas herramientas para evaluar la calidad
del software.
61
Ilustración 16: Herramientas para evaluar calidad del software (Rodríguez Monje Moisés, 2010).
Terminado el tema de los niveles y las herramientas de la norma ISO 25000
continuaremos hablando de la certificación que tiene la norma.
Certificación “En esta parte se muestra las primeras certificaciones de la norma ISO 25000 con ayuda
del laboratorio Analytical quality control (AQC).
El pasado 25 de septiembre de 2013, Asociación Española de Normalización y
Certificación (AENOR) concedió los primeros certificados de Calidad del Producto
conforme a la norma internacional ISO/IEC 25000 de Ingeniería del Software. Requisitos
de calidad y evaluación del producto software, también conocida como SQuaRE ( Product
Quality Requirements and Evaluation).
Así, AENOR ha certificado que las empresas Enxenio, Sicaman y Bitware cumplen con
los requisitos de la norma en la mantenibilidad de sus productos de software, es decir, el
grado en el que un producto facilita su mantenimiento de forma efectiva, eficaz, segura y
satisfactoria, permitiendo actualizaciones.
Para llevar a cabo la certificación de calidad del producto software, AENOR ha contado
con la colaboración del laboratorio AQC Lab, primer centro en España acreditado por
Entidad Nacional de Acreditación (ENAC) para la realización de ensayos de evaluación de
la calidad de aplicaciones software. Este laboratorio emite un informe de evaluación
independiente mediante el cual comprueba el nivel con el que el software puede ser
mantenido para posibles mejoras, correcciones o adaptaciones del mismo a cambios en
los requisitos o en el entorno” (iso25000.com, 2013).
62
En la imagen 4 se muestra la lista de los productos certificados en la norma ISO 25000.
Ilustración 17: Certificación (ISO 25000.com, 2013).
Terminando con el tema de la certificación continuaremos con la empresa que se encarga
de evaluar la calidad del software.
AQC Lab: Laboratorio de Evaluación de la Calidad Software “La calidad del software se ha convertido durante los últimos años en uno de los aspectos
más importantes y de mayor repercusión para los proyectos de desarrollo software. Esta
importancia comenzó centrándose en los procesos de desarrollo software y para su
evaluación surgieron modelos y estándares como CMMI e ISO/IEC 15504.
Sin embargo, es cada día mayor el número de organizaciones y empresas que se
interesan, no solo por la calidad de los procesos que se siguen en el desarrollo de
software, sino también por la calidad de los productos que desarrollan y/o adquieren, ya
que una vez que el producto ha sido implantado en sus instalaciones se encuentran con
graves problemas de calidad. Esta importancia de la calidad del producto ha dado lugar al
Laboratorio de Evaluación AQC Lab, que permite tanto a empresas y fábricas
desarrolladoras de software, como a organizaciones que tengan externalizado el
desarrollo de parte o la totalidad de su software, obtener una evaluación independiente de
la calidad del producto.
Basado en la nueva familia ISO/IEC 25000 SQuaRE Para ello, AQC Lab se apoya en la norma internacional más actual referente a calidad del
producto software, como es ISO/IEC 25000 SQuaRE. La familia de normas ISO/IEC
25000 surge para sustituir a las antiguas ISO/IEC 9126 e ISO/IEC 14598, unificando el
contenido de estas y definiendo a lo largo de sus distintas partes:
Un modelo de calidad con las características y subcaracterísticas de calidad que
se pueden evaluar de un producto software.
63
Métricas y requisitos de calidad que se pueden aplicar al producto software y
Un proceso de evaluación a seguir para determinar la calidad de los productos
software.
Cumpliendo con los requisitos de esta familia de normas, AQC Lab realiza un proceso de
evaluación compuesto por cinco actividades:
Establecer los requisitos de la evaluación: cuyo objetivo es definir el propósito de
la evaluación, los requisitos de calidad que se deben considerar, las partes
involucradas y el rigor de la evaluación.
Especificar la evaluación: cuyo objetivo es determinar las métricas, técnicas y
herramientas que se utilizarán para llevar a cabo la evaluación.
Diseñar la evaluación: cuyo fin es definir el plan con las actividades de evaluación
que se deben llevar a cabo.
Ejecutar la evaluación: cuya meta es obtener las mediciones y aplicar los criterios
de evaluación determinados en las actividades anteriores.
Concluir la evaluación: que finalmente permite analizar los resultados y elaborar un
informe descriptivo para que la organización evaluada conozca la calidad de su
producto software.
Beneficios de nuestros clientes Gracias al servicio de evaluación independiente del producto software ofrecido por AQC
Lab, las organizaciones obtienen entre otros los siguientes beneficios:
Conocer la calidad del producto software que desarrollan o adquieren.
Controlar la evolución de la calidad de sus productos software a lo largo del ciclo
de vida de desarrollo.
Corregir los defectos software desde las primeras fases del ciclo de vida
reduciendo los costes de mantenimiento y mejorando el time to market.
Comparar la calidad de sus productos con otros existentes en el mercado.
Aumentar la satisfacción del cliente y mejorar el retorno de la inversión”
(alarcosqualitycenter.com, 2013).
Terminando de hablar acerca de la norma ISO 25000 nos pasaremos al punto de las
curiosidades que es donde al redactor le pareció interesante esa parte del tema.
64
Cosas curiosas
Evaluación del producto “Cada día son más las organizaciones que muestran interés en asegurar o controlar la
calidad del producto software, y aunque cada una de ellas tiene características que las
diferencian del resto, de manera global se pueden clasificar en alguna de las siguientes
categorías:
Organismos de las Administraciones Públicas, que tanto a nivel estatal como
autonómico o local, cada día externalizan más el desarrollo de software a otras
empresas o factorías de software, y que necesitan disponer de un control de
calidad que les permita verificar que el software que reciben cumple los requisitos
mínimos de calidad exigidos y además poder de esta manera gestionar de forma
adecuada los acuerdos de nivel de servicio pactados con los proveedores.
Empresas de software que externalizan, ya sea bajo el método del nearshoring o
bajo el método del offshoring, parte de sus procesos de desarrollo de software, y
que deben controlar también de forma continua la calidad del software que
reciben.
Factorías y empresas desarrolladoras de software que están interesadas en
disponer de un mecanismo que les permita asegurar la calidad del software que
fabrican.
Factorías y empresas desarrolladoras de software que están interesadas en
asegurar a sus clientes, mediante una verificación y validación independientes, la
calidad de los productos que les están entregando” (iso25000.com, 2013).
Motivos para la evaluación “Independientemente de lo anterior, son muchos los motivos por los que una organización
puede estar interesada en implantar un sistema de control de la calidad del producto bajo
la familia de normas ISO/IEC 25000. Entre los más destacados se pueden incluir:
Diferenciarse de los competidores, asegurando tiempos de entrega y reducción de
fallos en el producto tras su implantación en producción.
Poder establecer acuerdos de nivel de servicio, definiéndose determinados
parámetros de calidad que el producto debe cumplir antes de ser entregado.
Detectar los defectos en el producto software y proceder a su eliminación antes de
la entrega, lo que supone un ahorro de costes en la fase de mantenimiento
posterior.
Evaluar y controlar el rendimiento del producto software desarrollado, asegurando
que podrá generar los resultados teniendo en cuenta las restricciones de tiempo y
recursos establecidas.
Asegurar que el producto software desarrollado respeta los niveles necesarios
para las características de seguridad (confidencialidad, integridad, autenticidad,
no-repudio, etc.).
65
Comprobar que el producto desarrollado podrá ser puesto en producción sin poner
en compromiso el resto de sistemas y manteniendo la compatibilidad con las
interfaces necesarias.
“Resaltando los beneficios de evaluar el producto software en función de la tipología de
organización, podríamos destacar dos: las empresas que desarrollan software y las
organizaciones que adquieren software:” (ISO 25000.com, 2013). En la siguiente figura se
enumeran estos beneficios
Ilustración 18: Beneficios para evaluar producto de software (ISO 25000.com, 2013).
66
ISO/IEC 20000
67
Introducción
“La TI (Tecnología de la Información) es imprescindible en las empresas de hoy en día.
Sin embargo, las preocupaciones en torno a los servicios de TI tanto internos como
subcontratados crecen debido a que estos servicios no se ajustan a las necesidades de
empresas y clientes” (EQA, 2013).
“ISO 20000 describe un conjunto integrado de procesos que permiten prestar en forma
eficaz servicios de TI a las organizaciones y a sus clientes. La esperada publicación de
la ISO 20000 el 15 de diciembre de 2005 representa un gran paso adelante hacia el
reconocimiento internacional y el desarrollo de la certificación de ITSM (IT Service
Management)” (OVERTI, 2011).
“La certificación ISO 20000 demuestra la fiabilidad y calidad de sus servicios de TI a los
empleados, accionistas y clientes” (SGS, 2013).
“La certificación de los Sistemas de Gestión de Tecnología de la Información es, hoy por
hoy, un requisito obligado por el propio mercado. Tener un Sistema de Gestión de
Tecnología de la Información certificado representa una ventaja competitiva en el
esquema de globalización que estamos viviendo, además de ser una herramienta útil para
lograr la eficiencia de toda organización, ya que establece métricas y compromisos
alineado con las necesidades de los clientes y monitorea constantemente su
cumplimiento” (NYCE, 2013).
“Es el primer estándar mundial creado específicamente para la Gestión de Servicios de TI
(ITSM), estableciendo métricas para medir los servicios de Tecnologías de Información”
(NYCE, 2013).
68
Definición
"A partir del 14 de Diciembre de 2005, es reconocido mundialmente como un estándar
para certificar la Gestión de Servicios de TI de las Empresas y Organizaciones, ISO/IEC
20000 (International Organization for Standardization) e IEC (International Electrotechnical
Commission) (ISO20000 MEXICO, 2013)".
"La serie 20000 proviene de la adopción de la serie BS 15000 desarrollada por la entidad
de normalización y certificación británica BSI (British Standard Institute) (ISO20000
MEXICO, 2013)".
"La certificación ISO20000 proporciona a las organizaciones un planteamiento
estructurado para desarrollar servicios de tecnología de la información fiables. Es un reto,
pero también es una oportunidad que tienen las empresas para salvaguardar sus
sistemas de gestión de tecnología de la información (EQA, 2013)".
"La norma ISO20000 se concentra en la gestión de problemas de tecnología de la
información mediante el uso de un planteamiento de servicio de asistencia - los problemas
se clasifican, lo que ayuda a identificar problemas continuados o interrelaciones (SGS,
2013)".
"La norma considera también la capacidad del sistema, los niveles de gestión necesarios
cuando cambia el sistema, la asignación de presupuestos financieros y el control y
distribución del software (EQA, 2013)".
Objetivos de la norma ISO 20000
"Promover la adopción de procesos integrados con el fin de suministrar la gestión de los
servicios para obtener los requisitos tanto de nuestros clientes cómo del mercado en sí
(EQA, 2013)".
"Medir la comprensión de nuestras “buenas prácticas”, objetivos, beneficios y posibles
problemas dentro de nuestro Sistema de Gestión (EQA, 2013)".
"Ayudar a las organizaciones a generar facturación, o bien, generar costes efectivos o
beneficios dentro de la vía profesional del servicio TI que se suministra a los clientes
(EQA, 2013)".
Características
La norma ISO 20000 está formada por dos partes las cuales son:
69
La primera parte (Especificación):
"Define los requerimientos necesarios ( 217 ) que deben cumplirse para realizar la entrega
de servicios de TI alineados con la Visión y Objetivos del Negocio, integrando así las
distintas áreas de la organización con calidad y valor agregado para los clientes,
asegurando una optimización de los costes y garantizando la seguridad de la entrega en
todo momento (ISO20000 MEXICO, 2013)".
"El cumplir con esta especificación es garantía de que la organización cuenta con
un “Ciclo de Mejora Continua” de la Gestión de los servicios de TI que ofrece
(ISO20000 MEXICO, 2013)".
Este Estándar Internacional comprende 13 Procesos Definidos que conforman el SGSTI
Sistema de Gestión de Servicios de TI:
• Grupo de Procesos de Provisión del Servicio:
1. Gestión de Niveles de Servicio. 2. Gestión de Informes de Servicio. 3. Gestión de la Continuidad (ITSCM) y Disponibilidad (Gestión Disponibilidad) del
Servicio. 4. Elaboración de Presupuestos y Manejo Contable de los Servicios de TI (Gestión
Financiera). 5. Gestión de la Capacidad. 6. Gestión de la Seguridad de la Información.
• Grupo de Procesos de Control:
7. Gestión de la Configuración. 8. Gestión de Cambios.
• Grupo de Procesos de Entrega:
9. Gestión de Versiones (Entregas y Despliegues).
• Grupo de Procesos de Resolución:
10. Gestión de Incidentes. 11. Gestión de Problemas.
• Grupo de Procesos de Relaciones:
12. Gestión de las Relaciones con el Negocio (SLM y CSI principalmente). 13. Gestión de Proveedores.
La segunda parte (Código de Prácticas) ITIL :
"Representa el conjunto de Mejores Prácticas “adoptadas” y “aceptadas” por la industria
en materia de Gestión de Servicio de TI. Está basada en el estándar mundial para el área
de IT (ITIL (Biblioteca de Infraestructura de TI) que sirve como guía y base para la
70
definición de nuevas acciones de mejora de los servicios en el servicio o preparación de
auditorías contra el estándar ISO/IEC 20000 - 1:2005 (ISO20000 MEXICO, 2013)".
"La especificación supone un completo sistema de gestión (organizado según ISO 9001)
basado en procesos de gestión de servicios, políticas, objetivos y controles (ISO20000
MEXICO, 2013)".
"¿Qué es ITIL? (Propiedad de la OGC de Inglaterra | Office of Goverment of Commerce)
(ISO20000 MEXICO, 2013)".
"ITIL (Information Technology Infrastructure Library), es el estándar internacional
adoptado por las principales empresas de servicios a nivel mundial, para reducir costos y
optimizar los servicios que ofrecen a través del área de TI, aumentando la disponibilidad y
calidad de los mismos (ISO20000 MEXICO, 2013)".
"ITIL es un Framework, documentado en un conjunto de libros, que conforman la
Biblioteca de Mejores Prácticas que permiten mejorar notablemente la calidad de los
servicios de tecnologías de la información que presta una empresa a sus clientes o un
departamento de su organización (ISO20000 MEXICO, 2013)".
"Adicionalmente, ITIL permite a las Empresas que lo adopten obtener la certificación
exclusiva ISO/IEC 20000, para el área de tecnología de la información. Dicha certificación
es garantía comprobable de la calidad de los servicios que se ofrecen (ISO20000
MEXICO, 2013)".
Atributos
Demuestra que una organización dispone de controles y procedimientos
adecuados para prestar coherentemente un servicio de TI de calidad y rentable
(EQA, 2013).
Ofrece la posibilidad de seleccionar y gestionar a los proveedores de servicios
externos con mayor eficacia (EQA, 2013).
Más oportunidades de mejorar la eficacia, fiabilidad y coherencia de los servicios
de TI que repercuten en los costes y el servicio (EQA, 2013).
El proceso de certificación puede reducir la cantidad de auditorías a proveedores y
disminuir así los costes (EQA, 2013).
Permite demostrar altos niveles de calidad y fiabilidad de los servicios de
tecnología de información, cuando presente ofertas para contratos internacionales
o cuando realice ampliaciones locales para aumentar su volumen de negocio
(EQA, 2013).
71
Niveles o Etapas
Los niveles o procesos que lleva acabo la norma ISO 20000 son los que se muestran en
la figura 1.
Ilustración 19: Proceso de gestión de servicios de la norma ISO 20000 (Raúl Álvarez, 2007).
Aplicación
"ISO 20000 es aplicable a cualquier organización, grande o pequeña, de cualquier sector
o parte del mundo, que se base en servicios de TI (EQA, 2013)".
"La norma es especialmente apropiada para proveedores internos de servicios de TI,
como los departamentos de TI, y para proveedores externos de estos servicios, como las
organizaciones de subcontratación de TI (EQA, 2013)".
¿Certificable?
"UNE-ISO/IEC 20000 es el primer estándar de calidad certificable orientado
específicamente a la Gestión de Servicios TI, que proporciona un planteamiento de
gestión integrado, con un conjunto de procesos para la entrega efectiva de servicios al
cliente de la organización, ya sea interno o externo, con el objetivo final de reducir la
exposición al riesgo derivada de las operaciones, cumplir las obligaciones contractuales y
demostrar la calidad de los servicios que ofrece (Ricardo Cañizares Sales, 2007, pág.
58)".
72
Casos de éxito
Existen compañías que se han certificado bajo la norma ISO 20000 con diferentes
empresas certificadoras avaladas para poder dar la certificación.
A continuación, en la tabla 8 se nombrarán algunas empresas certificadas.
Tabla 10: Certificación con la norma ISO 20000:
Empresa Alcance
PHI IT S.A. DE C.V.
SOLUCIONES DE NEGOCIO
INTEGRALES BASADAS EN
TECNOLOGÍA DE INFORMACIÓN Y
COMUNICACIONES MEDIANTE
PROCESAMIENTO, SEGURIDAD Y
ALMACENAMIENTO DE CÓMPUTO,
INFORMACIÓN, DESARROLLO DE
SOFTWARE, ALTA DISPONIBILIDAD,
ACCESO A INTERNET, PROVEEDURÍA
DE HARDWARE, SOFTWARE Y
MÓVILES, DISEÑO, INGENIERÍA E
IMPLEMENTACIÓN.
MAINBIT SA DE C.V
SERVICIO ADMINISTRADO
ESCRITORIO, QUE CONSISTE EN
PROPORCIONAR EL EQUIPO DE
CÓMPUTO PERSONAL COMPUESTO
POR HARDWARE, SOFTWARE Y
CONFIGURACIÓN BÁSICA
(APLICACIONES Y ACCESOS
DEFINIDOS PARA EL EQUIPO EN BASE
AL PERFIL DEL USUARIO ASIGNADO)
EN STANDALONE A LOS USUARIOS
ADSCRITOS A LAS INSTALACIONES DE
MAINBIT EN GABRIEL MANCERA PARA
EL DESARROLLO DE SUS
ACTIVIDADES.
COMISIÓN FEDERAL DE
ELECTRICIDAD –CENACE
SERVICIO DE ADQUISICIÓN DE DATOS
EN TIEMPO REAL PARA LA
OPERACIÓN DEL SISTEMA ELÉCTRICO
NACIONAL
SHARP CORPORATION MÉXICO,
S.A. DE C.V.
SERVICIOS ADMINISTRADOS DE
IMPRESIÓN Y SOPORTE TÉCNICO DE
EQUIPOS MULTIFUNCIONALES,
BRINDADO A TODOS LOS CLIENTES
73
EN TODA LA REPÚBLICA MEXICANA, A
TRAVÉS DE MESAS DE SERVICIO
DISTRIBUIDORA TECNO OFICE S.A
DE C.V.
SERVICIO DE MANTENIMIENTO
CORRECTIVO DE MULTIFUNCIONALES
SHARP A CLIENTES EN LA ZONA
METROPOLITANA DE GUADAJALARA,
JALISCO.
REDES Y SOPORTE EN
MICROCOMPUTACIÓN, S.A.
SERVICIO DE MANTENIMIENTO
CORRECTIVO SIN REFACCIONES DE
SOFTWARE, HARDWARE, CABLEADO
ESTRUCTURADO Y TELEFONÍA EN EL
ÁREA METROPOLITANA DEL D.F.
OPERBES S.A. DE C.V.
ADMINISTRACIÓN DE CAMBIOS,
RESPALDO DE CONFIGURACIONES,
ADMINISTRACIÓN DE INCIDENTES,
ADMINISTRACIÓN DE PROBLEMAS,
ADMINISTRACIÓN DE
VULNERABILIDADES Y MONITOREO DE
DISPONIBILIDAD, LOS CUALES SON
PROVISTOS POR EL ÁREA DEL
SECURITY OPERATION CENTER (SOC)
DE BESTEL A SUS DIFERENTES
CLIENTES.
TECNOLOGÍA EN SERVICE DESK,
S.A. DE C.V.
SERVICIO DE IMPLEMENTACIÓN Y
OPERACIÓN DE SERVICE DESK, EL
CUAL INCLUYE LA PROVISIÓN DE LOS
RECURSOS TECNOLÓGICOS Y
HUMANOS PRESTADOS DESDE LAS
INSTALACIONES UBICADAS EN JOSÉ
MARÍA OLLOQUI NO. 31, DELEGACIÓN
BENITO JUÁREZ, MÉXICO, D.F., A
TODOS NUESTROS CLIENTES
NACIONALES E INTERNACIONALES
Cosas curiosas
Una de las cosas que más me llamó la atención fue que tiene vínculos con otras normas
ISO como es la norma ISO 15504
Otro motivo para su implantación es que los entornos de desarrollo y de TI están
condenados a entenderse. En desarrollo usan herramientas como ISO 15504 y su
certificación hace exigirle a las empresas de TI ciertas actuaciones, que lograrían
fácilmente usando ISO 20000 (EQA, 2013).
74
También se relaciona con ITIL y COBIT (Control Objetives for Information and related
Technology), la ITIL actúa sobre los procesos y, a través del conjunto de buenas prácticas
que lo conforman, mejorar el servicio que ofrece la empresa y medirlos (para una mejora
continua) y el COBIT sirve para planear, organizar, dirigir y controlar toda la función
informática dentro de una empresa. Actúa sobre la dirigencia y ayuda a estandarizar la
organización (ISO 20000, 2013).
Las tareas de ITIL
"ITIL describe un procedimiento sistemático y profesional para la gestión de servicios de
TI. La biblioteca pone enfáticamente el énfasis en la importancia de satisfacer las
necesidades corporativas del aspecto comercial (ISO 20000, 2013)".
"La condición necesaria para ello es la disposición incondicional para aceptar el cambio
con respecto a un cliente y un enfoque orientado al servicio. En muchas empresas esto
requiere un cambio en la cultura de comportamiento existente (ISO 20000, 2013)".
"El objetivo, con la ayuda de ITIL, es crear también un mundo clara de las definiciones en
el área de gestión de servicios y por consiguiente, para simplificar la comunicación (ISO
20000, 2013)".
Las tareas de COBIT
"El marco COBIT está destinado principalmente a cumplimiento y la seguridad y, como tal,
asegura la gestión de la información para la operación de los servicios de TI (ISO 20000,
2013)".
"La gestión de servicios bajo ITIL está orientada exclusivamente hacia el beneficio y la
eficiencia del cliente. El logro de los objetivos de negocio, mientras que al mismo tiempo
cumplir con los requisitos internos y externos es fundamental para asegurar el medio de
una empresa y el éxito a largo plazo (ISO 20000, 2013)".
Sinergia entre COBIT e ITIL: ISO 20000
"Ya no es lo suficientemente pura para implementar las mejores prácticas. La sinergia
entre las dos redes ahora reside en el hecho de que los objetivos de control más formales
de COBIT están alineados con el marco ITIL, que se orienta hacia la idoneidad y
flexibilidad y éstas deben ser cumplidas de manera que se puede definir (ISO 20000,
2013)".
"Este enlace se sincroniza perfectamente las normas para la orientación estratégica y el
aumento de la eficiencia de la gestión de servicios de TI con las normas de auditoría (ISO
20000, 2013)".
"Los dos marcos continuarán desarrollando y converger cada vez más, con el puente de
este ser creado por la norma internacional ISO 20000. Sobre la base de las dos
organizaciones ITIL ITSMF y BSI (Instituto Británico estándar) han desarrollado esta
norma claramente medible y por lo tanto, creó la oportunidad para la certificación de la
75
conformidad, la eficacia y la eficiencia del individuo objetivos de control de gestión de
servicios de TI (ISO 20000, 2013)".
76
ISO/IEC 38500
77
Introducción
Actualmente, el gobierno de las TI se extiende rápidamente, la mitad de las
organizaciones reconocen haber implantado o estar en proceso de implantación de
elementos propios del gobierno de las TI.
La publicación de la norma ISO 38500 en 2008, ha supuesto un gran respaldo para el
reconocimiento de la importancia de los sistemas de gobierno de las TI y se ha convertido
en un referente y un excelente punto de partida para la implantación de estos sistemas.
(Antonio Fernández Martínez y Faraón Llorens Largo, 2011)
Su objetivo es proporcionar un marco de principios para que la dirección de las
organizaciones lo utilice al evaluar, dirigir y monitorizar el uso de las tecnologías de la
información y comunicaciones (TICs).
Está alineada con los principios de gobierno corporativo recogidos en el “Informe
Cadbury” y en los “Principios de Gobierno Corporativo de la OCDE.” (ISACA, 2010)
78
Definición
ISO/IEC 38500 es un estándar que provee un marco de trabajo con los principios
necesarios para que los directores y gerentes puedan implantar los procesos de
evaluación, dirección y monitoreo del uso efectivo, eficiente y aceptable de la Tecnología
de Información (TI) en sus organizaciones. Es aplicable a todas las organizaciones:
públicas y privadas, de cualquier tamaño. (SISELCA IT Systems, 2013)
La norma se aplica al gobierno de los procesos de gestión de las TICs en todo tipo de
organizaciones que utilicen (hoy todas) las tecnologías de la información, facilitando unas
bases para la evaluación objetiva del gobierno de TIC. (Manuel Ballester, 2010)
Características
A continuación conocernos las características del gobierno de TI (ISO/IEC 38500) que
tienen como objetivo proporcionar beneficios al implementar esta norma:
Establece un modelo para el gobierno de TI, basado en dirigir, monitorizar y
evaluar.
Este estándar establece 6 principios para la eficacia, eficiencia y uso aceptable de
las TI.
Este estándar asegura que las organizaciones realizan un adecuado estudio de
riesgos y evalúan nuevas oportunidades en el uso de las TI.
Este estándar fomenta el uso de otros estándares para apuntalar la gestión de las
TI (CITI – Control Interno Tecnologías Información).
Este estándar es un subconjunto del Gobierno Corporativo de las empresas /
instituciones.
Este estándar deja claro que se debe cumplir con la legislación vigente. (Carlos
Manuel Fernández, 2011)
Atributos o principios
En este apartado haremos referencia a los atributos que posee la ISO/IEC 38500 los
cuales conforman sus características. Esta norma define 6 principios de Gobierno de TI:
1. Responsabilidad: los clientes (usuarios) y el proveedor de servicios (organización
de TI) deben usar un modelo de comunicación efectiva, basado en la asignación
de responsabilidad y rendición de cuentas y avances.
2. Estrategia: la planificación estratégica de TI es compleja y critica, y requiere una
coordinación estrecha a todo lo ancho de la organización: unidades de negocio,
organización y planes estratégicos de TI.
79
3. Adquisición: las soluciones de TI existen para soportar los procesos de negocio.
Estas no deben ser consideradas como proyectos aislados de TI, sino como
aporte de valor que habilita cambio positivo en el negocio.
4. Desempeño: la medición efectiva del desempeño depende de dos aspectos clave:
la clara definición de metas de desempeño y el establecimiento de métricas
efectivas para monitorear el logro de esas metas.
5. Cumplimiento: en el mercado global actual, habilitado por Internet y los avances
tecnológicos, las empresas necesitan cumplir con un amplio número de
requerimientos legales y regulatorios.
6. Comportamiento Humano: la implementación de todo cambio de TI,
regularmente requiere un significante cambio cultural y de comportamiento del
recurso humano dentro de la empresa, como también de las relaciones con los
clientes, proveedores y asociados de negocio. (SISELCA IT Systems, 2013)
Por otro lado la ISO/IEC 38500 tiene un modelo para su dirección el cual se encuentra
basado en tres tareas principales:
1. Evaluar: examinar y juzgar el uso actual y futuro de las TIC, incluyendo
estrategias, propuestas y acuerdos de aprovisionamiento (internos y externos).
2. Dirigir: dirigir la preparación y ejecución de los planes y políticas, asignando las
responsabilidades al efecto. Asegurar la correcta transición de los proyectos a la
producción, considerando los impactos en la operación, el negocio y la
infraestructura. Impulsar una cultura de buen gobierno de TIC en la organización.
3. Monitorizar: mediante sistemas de medición, vigilar el rendimiento de la TIC,
asegurando que se ajusta a lo planificado. (Manuel Ballester, 2010)
En la siguiente figura representa de manera gráfica en donde influyen las tres tareas.
80
Ilustración 20: Modelo de Gobierno Corporativo de TIC. Certificación.
Sabemos que toda norma tiene un proceso de certificación y que es necesario para
establecer que una organización está cumpliendo con todos los requisitos de la ISO y
cumpliendo los objetivos que se establece. En la siguiente figura se muestra el “proceso
de certificación de conformidad ISO 38500”:
Ilustración 21: Proceso de certificación de conformidad ISO 38500 (Carlos Manuel Fernández, 2011).
81
Marco de trabajo
El marco de trabajo de la ISO 38500 se encuentra fundamentado en tres premisas en el
punto de vista del “Desarrollo de Política para el control de TI”, las cuales son:
Políticas estratégicas
Su posición frente a los principios.
Rol de la junta: consulta y aprobación.
Políticas operacionales
Especifican como se conducen los proyectos y las operaciones.
Rol de la junta: conciencia.
Políticas de uso
Reglas para saber cómo las personas utilizan los sistemas de negocio y recursos.
Rol de la junta: parte de la comunidad de usuarios. (Carlos Francavilla, 2012)
Casos de éxito
El gobierno TI en el sistema de dirección estratégica de la “Universidad Jaume I de
Castello” es un gran ejemplo de los reconocimientos y beneficios que ha obtenido al
implementar la norma ISO”IEC 38500, la cual ha llegado a las siguientes conclusiones:
1. Alineación con la planificación estratégica institucional.
2. Responsabilidades de los ejecutivos y el rol del gerente de las TI (CIA).
3. Teoría sobre gobierno y políticas en la práctica.
4. Gobierno institucional interno versus externo.
5. Mecanismos y procesos del Gobierno de las TI.
Con esto se considera que la ISO 38500 ha venido a darnos la razón con el modelo por el
que apostamos en el 1996 y que nos permitió tener una visión corporativa del proceso
TI/SI en la Universidad alineado con el proceso estratégico.
Nuestro principal objetivo es dar una visión a vuelo de pájaro de los pasos tomados desde
1991 hasta la fecha, intentando explicar nuestra experiencia, argumentando las
decisiones tomadas y describiendo los instrumentos finales focalizados desde la
perspectiva TI. Que nos permiten gestionar actualmente la totalidad de la Universidad y
82
que han sido recientemente reconocidos con el sello de Excelencia EFQM +500. (Antonio
Fernández Martínez y Faraón Llorens Largo, 2011)
83
ISO/IEC 27000
84
INTRODUCCIÓN
La información es una parte importante para el éxito y la continuidad en el mercado de
cualquier empresa. La seguridad de esta información y de los sistemas que los procesan
es un objetivo número uno de toda la empresa u organización.
Para una excelente gestión de la seguridad de la información, es necesario implantar un
sistema que aborde esta tarea de una forma metódica, documentada y basada en unos
objetivos claros de seguridad y una evaluación de los riesgos a los que está sometida la
información de la empresa.
Tener garantizado un nivel de protección total es virtualmente imposible, así que el
objetivo de los sistemas de gestión de seguridad de la información es garantizar que los
riesgos de la seguridad sean conocidos, asumidos, gestionados y minimizados por la
organización.
Por esta razón hablare en este apartado sobre la ISO/IEC 27000 que es un estándar
desarrollado específicamente para la gestión de la seguridad de la información, la cual es
utilizable en cualquier tipo de organización.
También presentaré las distintas normas que componen la serie ISO 27000, así como sus
características, atributos, niveles y como puede una organización implantar un sistema de
gestión de seguridad de la información basado en la ISO 27001.
Ilustración 22: ISO 27000 Tomado de: http://www.grupotreinar.com
“La ISO/IEC 27000 es un conjunto de estándares desarrollados -o en fase de desarrollo
por ISO (International Organization for Standardization) e IEC (International
Electrotechnical Commission), que proporcionan un marco de gestión de la seguridad de
la información utilizable por cualquier tipo de organización, pública o privada, grande o
pequeña” (Baldeón Garzón, 2012).
85
“ISO (International Organization for Standardization) – Organización
Internacional para la Estandarización, es un organismo que promueve el
desarrollo de normas voluntarias internacionales de fabricación, comercio y
comunicación para todas las ramas industriales menos las del campo de la
eléctrica y la electrónica. Su sede principal se encuentra en la ciudad de
Ginebra-Suiza y su objetivo principal es la de estandarizar normas,
productos y seguridad para organizaciones y empresas de todo el mundo”
(Baldeón Garzón, 2012).
“IEC (International Electrotechical Commission) – Comisión Electrónica
Internacional, es una organización que se encarga de la normalización en
el campo eléctrico, electrónico y en todas las tecnologías que se
encuentren relacionadas. Desde el año 1906 IEC es la organización líder a
nivel mundial que prepara y publica normas internacionales para todas las
tecnologías eléctricas, electrónicas y relacionadas con el fin de trabajar con
seguridad en todos los niveles” (Baldeón Garzón, 2012).
“El origen de esta norma ISO 27000 se remonta desde 1901, y como primera entidad de
normalización a nivel mundial, BSI (British Standards Institution) es responsable de
importante normas como:
1979: Publicación BS 5750 - ahora ISO 9001
1992: Publicación BS 7750 - ahora ISO 14001
1996: Publicación BS 8800 - ahora OHSAS 18001
La norma BS 7799 de BSI aparece por primera vez en 1995, con objeto de proporcionar a
cualquier empresa -británica o no- un conjunto de buenas prácticas para la gestión de la
seguridad de su información.
La primera parte de la norma (BS 7799-1) es una guía de buenas prácticas, para la que
no se establece un esquema de certificación. Es la segunda parte (BS 7799-2), publicada
por primera vez en 1998, la que establece los requisitos de un sistema de seguridad de la
información (SGSI) para ser certificable por una entidad independiente” (ISO27000, 2013).
“Las dos partes de la norma BS 7799 se revisaron en 1999 y la primera parte se adoptó
por ISO, sin cambios sustanciales, como ISO 17799 en el año 2000.
En 2002, se revisó BS 7799-2 para adecuarse a la filosofía de normas ISO de sistemas de
gestión.
En 2005, con más de 1700 empresas certificadas en BS7799-2, este esquema se publicó
por ISO como estándar ISO 27001, al tiempo que se revisó y actualizó ISO 17799. Esta
última norma se renombra como ISO 27002:2005 el 1 de Julio de 2007, manteniendo el
contenido así como el año de publicación formal de la revisión” (ISO27000, 2013).
86
Ilustración 23: Historia de ISO 27001 Tomado de: (ISO27000, 2013).
En Marzo de 2006, posteriormente a la publicación de la ISO27001:2005, BSI publicó la
BS7799-3:2006, centrada en la gestión del riesgo de los sistemas de información.
Tal como se menciona en (ATTAChile, 2013), “esta ISO 27001:2005 duro bastante tiempo
hasta que se vio necesario actualizarla así que la International Organization for
Standardization ha publicado la última versión de la norma ISO 2700, la ISO 27000:2013.
Entre las diferencias encontramos las siguientes:
El cambio más evidente en la nueva versión de la norma es el de su estructura la
cual se adapta a todas las normas de gestión.
Las partes interesadas cobran gran importancia en esta versión, ya que incluye a
accionistas, clientes, autoridades, socios, etc. La norma posee un listado de
posibles partes interesadas en una organización.
Los conceptos “documentos” y “registros” pasan a llamarse información
documentada, en esta nueva norma.
La evaluación de riesgos ya no se realizará a partir de los activos, las
vulnerabilidades y las amenazas sino que estos sólo se emplearán para establecer
los riesgos consecuencia de la Integridad, la Confidencialidad y la Disponibilidad.
Con este cambio se logra aportar capacidad de decisión a la empresa a la hora de
identificar los riesgos.
En el informe de objetivos propuestos por la empresa, ahora, será necesario
especificar quién será el responsable de comprobar que se realizan, el
responsable de medirlos y además con qué frecuencia lo hace. También será
necesario especificar como se planea hacer posibles los objetivos.
87
Las acciones preventivas también son objeto de cambio en la norma 27001, ya
que la nueva versión no incluye acciones preventivas ya que estas pasarán a
formar parte de la evaluación del riesgo y el tratamiento.
Por otro lado, las acciones correctivas se clasifican en dos tipos, las enfocadas a
hallar solución a no conformidades y las dedicadas a eliminar la causa que
provoca no conformidades.
En la nueva norma también será necesario indicar toda la información relativa a la
comunicación, incluyendo los requisitos a comunicar, cuando, como y a quién se
comunica etc.”.
La ISO 27000:2013 aporta mayor libertad a las empresas, las cuales podrán adaptar el
Sistema de Gestión a sus necesidades, lo cual mal interpretado puede ser una excusa
para que las empresas no se esfuercen y traten de cumplir el mínimo de requisitos.
Tal y como se menciona en (ISO27000, 2013), “los beneficios de esta norma ISO 27000
son muchas pero entre las más importantes tenemos:
Establecimiento de una metodología de gestión de la seguridad clara y
estructurada.
Reducción del riesgo de pérdida, robo o corrupción de información.
Los clientes tienen acceso a la información a través de medidas de seguridad.
Los riesgos y sus controles son continuamente revisados.
Confianza de clientes y socios estratégicos por la garantía de calidad y
confidencialidad comercial.
Las auditorías externas ayudan cíclicamente a identificar las debilidades del
sistema y las áreas a mejorar.
Posibilidad de integrarse con otros sistemas de gestión (ISO 9001, ISO 14001,
OHSAS 18001…).
Continuidad de las operaciones necesarias de negocio tras incidentes de
gravedad.
Conformidad con la legislación vigente sobre información personal, propiedad
intelectual y otras.
Imagen de empresa a nivel internacional y elemento diferenciador de la
competencia.
Confianza y reglas claras para las personas de la organización.
Reducción de costes y mejora de los procesos y servicios.
Aumento de la motivación y satisfacción del personal.
Aumento de la seguridad en base a la gestión de procesos en vez de en la compra
sistemática de productos y tecnologías”.
La ISO 27000 es semejante a otras normas ISO, las cuales son realmente una serie de
estándares.
Como se menciona en (ISO27000, 2013), “los rangos de numeración reservados por ISO
van de 27000 a 27019 y de 27030 a 27044 con 27799 finalizando la serie formalmente en
estos números.
88
La serie de normas con ciertas características se indican a continuación:
ISO 27000: En fase de desarrollo; su fecha prevista de publicación es Noviembre
de 2008. Contendrá términos y definiciones que se emplean en toda la serie
27000. La aplicación de cualquier estándar necesita de un vocabulario claramente
definido, que evite distintas interpretaciones de conceptos técnicos y de gestión.
Esta norma está previsto que sea gratuita, a diferencia de las demás de la serie,
que tendrán un coste.
ISO 27001: Publicada el 15 de Octubre de 2005. Es la norma principal de la serie y
contiene los requisitos del sistema de gestión de seguridad de la información.
Tiene su origen en la BS 7799-2:2002 y es la norma con arreglo a la cual se
certifican por auditores externos los SGSI de las organizaciones. Sustituye a la BS
7799-2, habiéndose establecido unas condiciones de transición para aquellas
empresas certificadas en esta última. En su Anexo A, enumera en forma de
resumen los objetivos de control y controles que desarrolla la ISO 27002:2005
(nueva numeración de ISO 17799:2005 desde el 1 de Julio de 2007), para que
sean seleccionados por las organizaciones en el desarrollo de sus SGSI; a pesar
de no ser obligatoria la implementación de todos los controles enumerados en
dicho anexo, la organización deberá argumentar sólidamente la no aplicabilidad de
los controles no implementados.
ISO 27002: Desde el 1 de Julio de 2007, es el nuevo nombre de ISO 17799:2005,
manteniendo 2005 como año de edición. Es una guía de buenas prácticas que
describe los objetivos de control y controles recomendables en cuanto a seguridad
de la información. No es certificable. Contiene 39 objetivos de control y 133
controles, agrupados en 11 dominios. Como se ha mencionado en su apartado
correspondiente, la norma ISO 27001 contiene un anexo que resume los controles
de ISO 27002:2005.
ISO 27003: En fase de desarrollo; su fecha prevista de publicación es Mayo de
2009. Consistirá en una guía de implementación de SGSI e información acerca del
uso del modelo PDCA y de los requerimientos de sus diferentes fases. Tiene su
origen en el anexo B de la norma BS7799-2 y en la serie de documentos
publicados por BSI a lo largo de los años con recomendaciones y guías de
implantación.
ISO 27004: En fase de desarrollo; su fecha prevista de publicación es Noviembre
de 2008. Especificará las métricas y las técnicas de medida aplicables para
determinar la eficacia de un SGSI y de los controles relacionados. Estas métricas
se usan fundamentalmente para la medición de los componentes de la fase “Do”
(Implementar y Utilizar) del ciclo PDCA.
89
ISO 27005: Publicada el 4 de Junio de 2008. Establece las directrices para la
gestión del riesgo en la seguridad de la información. Apoya los conceptos
generales especificados en la norma ISO/IEC 27001 y está diseñada para ayudar
a la aplicación satisfactoria de la seguridad de la información basada en un
enfoque de gestión de riesgos. El conocimiento de los conceptos, modelos,
procesos y términos descritos en la norma ISO/IEC 27001 e ISO/IEC 27002 es
importante para un completo entendimiento de la norma ISO/IEC 27005:2008, que
es aplicable a todo tipo de organizaciones (por ejemplo, empresas comerciales,
agencias gubernamentales, organizaciones sin fines de lucro) que tienen la
intención de gestionar los riesgos que puedan comprometer la organización de la
seguridad de la información. Su publicación revisa y retira las normas ISO/IEC TR
13335-3:1998 y ISO/IEC TR 13335-4:2000.
ISO 27006: Publicada el 13 de Febrero de 2007. Especifica los requisitos para la
acreditación de entidades de auditoría y certificación de sistemas de gestión de
seguridad de la información. Es una versión revisada de EA-7/03 (Requisitos para
la acreditación de entidades que operan certificación/registro de SGSIs) que añade
a ISO/IEC 17021 (Requisitos para las entidades de auditoría y certificación de
sistemas de gestión) los requisitos específicos relacionados con ISO 27001 y los
SGSIs. Es decir, ayuda a interpretar los criterios de acreditación de ISO/IEC 17021
cuando se aplican a entidades de certificación de ISO 27001, pero no es una
norma de acreditación por sí misma.
ISO 27007: En fase de desarrollo; su fecha prevista de publicación es Mayo de
2010. Consistirá en una guía de auditoría de un SGSI.
ISO 27011: En fase de desarrollo; su fecha prevista de publicación es finales de
2008. Consistirá en una guía de gestión de seguridad de la información específica
para telecomunicaciones, elaborada conjuntamente con la ITU (Unión
Internacional de Telecomunicaciones).
ISO 27031: En fase de desarrollo; su fecha prevista de publicación es Mayo de
2010. Consistirá en una guía de continuidad de negocio en cuanto a tecnologías
de la información y comunicaciones.
ISO 27032: En fase de desarrollo; su fecha prevista de publicación es Febrero de
2009. Consistirá en una guía relativa a la ciberseguridad.
ISO 27033: En fase de desarrollo; su fecha prevista de publicación es entre 2010 y
2011. Es una norma consistente en 7 partes: gestión de seguridad de redes,
arquitectura de seguridad de redes, escenarios de redes de referencia,
aseguramiento de las comunicaciones entre redes mediante Gateway, acceso
remoto, aseguramiento de comunicaciones en redes mediante VPNs y diseño e
90
implementación de seguridad en redes. Provendrá de la revisión, ampliación y
remuneración de ISO 18028.
ISO 27034: En fase de desarrollo; su fecha prevista de publicación es Febrero de
2009. Consistirá en una guía de seguridad en aplicaciones.
ISO 27799: Publicada el 12 de Junio de 2008. Es un estándar de gestión de
seguridad de la información en el sector sanitario aplicando ISO 17799 (actual ISO
27002). Esta norma, al contrario que las anteriores, no la desarrolla el subcomité
JTC1/SC27, sino el comité técnico TC 215. ISO 27799:2008 define directrices para
apoyar la interpretación y aplicación en la salud informática de la norma ISO / IEC
27002 y es un complemento de esa norma. ISO 27799:2008 especifica un
conjunto detallado de controles y directrices de buenas prácticas para la gestión
de la salud y la seguridad de la información por organizaciones sanitarias y otros
custodios de la información sanitaria en base a garantizar un mínimo nivel
necesario de seguridad apropiado para la organización y circunstancias que van a
mantener la confidencialidad, integridad y disponibilidad de información personal
de salud. ISO 27799:2008 se aplica a la información en salud en todos sus
aspectos y en cualquiera de sus formas, toma la información (palabras y números,
grabaciones sonoras, dibujos, vídeos e imágenes médicas), sea cual fuere el
medio utilizado para almacenar (de impresión o de escritura en papel o
electrónicos de almacenamiento) y sea cual fuere el medio utilizado para
transmitirlo (a mano, por fax, por redes informáticas o por correo), ya que la
información siempre debe estar adecuadamente protegida”.
Tal y como se establece en (ISO27000, 2013), “Algunos aspectos clave para que la
empresa obtenga la certificación en la ISO 27000 o la mantenga son:
Compromiso y apoyo de la Dirección de la organización.
Definición clara de un alcance apropiado.
Concienciación y formación del personal.
Evaluación de riesgos exhaustiva y adecuada a la organización.
Compromiso de mejorar continuamente.
Establecimiento de políticas y normas.
Organización y comunicación.
Integración del SGSI (Sistemas de Gestión de Seguridad en la Información) en la
organización, como se muestra en la imagen 3”.
91
Ilustración 24: Modelo de procesos de una organización a la norma ISO 27000
Tomada de: (ISO27000, 2013).
La simbología de las flechas de dirección es:
Plan (planificar): establecer el SGSI.
Do (hacer): implementar y utilizar el SGSI.
Check (verificar): monitorizar y revisar el SGSI.
Act (actuar): mantener y mejorar el SGSI.
Como se muestra en (ISO27000, 2013), “al momento de aplicar esta norma repercuten
varios beneficios entre estos están:
Establecimiento de una metodología de gestión de la seguridad clara y
estructurada.
Reducción del riesgo de pérdida, robo o corrupción de información.
Los clientes tienen acceso a la información a través medidas de seguridad.
Los riesgos y sus controles son continuamente revisados.
Confianza de clientes y socios estratégicos por la garantía de calidad y
confidencialidad comercial.
Las auditorías externas ayudan cíclicamente a identificar las debilidades del
sistema y las áreas a mejorar.
Posibilidad de integrarse con otros sistemas de gestión (ISO 9001, ISO 14001,
OHSAS 18001…).
92
Continuidad de las operaciones necesarias de negocio tras incidentes de
gravedad.
Conformidad con la legislación vigente sobre información personal, propiedad
intelectual y otras.
Imagen de empresa a nivel internacional y elemento diferenciador de la
competencia.
Confianza y reglas claras para las personas de la organización.
Reducción de costes y mejora de los procesos y servicio.
Aumento de la motivación y satisfacción del personal.
Aumento de la seguridad en base a la gestión de procesos en vez de en la compra
sistemática de productos y tecnologías”.
Tal y como se establece en (ISO27000, 2013), “así como hay beneficios con esta ISO
también pueden haber riesgos los cuales son:
Exceso de tiempos de implantación: con los consecuentes costes descontrolados,
desmotivación, alejamiento de los objetivos iniciales, etc.
Temor ante el cambio: resistencia de las personas.
Discrepancias en los comités de dirección.
Delegación de todas las responsabilidades en departamentos técnicos.
No asumir que la seguridad de la información es inherente a los procesos de
negocio.
Planes de formación y concienciación inadecuados.
Calendario de revisiones que no se puedan cumplir.
Definición poco clara del alcance.
Exceso de medidas técnicas en detrimento de la formación, concienciación y
medidas de tipo organizativo.
Falta de comunicación de los progresos al personal de la organización.
Por esta razón hay que tomar en cuenta estos consejos básicos:
Mantener la sencillez y restringirse a un alcance manejable y reducido: un centro
de trabajo, un proceso de negocio clave, un único centro de proceso de datos o un
área sensible concreta; una vez conseguido el éxito y observados los beneficios,
ampliar gradualmente el alcance en sucesivas fases.
Comprender en detalle el proceso de implantación: iniciarlo en base a cuestiones
exclusivamente técnicas es un error frecuente que rápidamente sobrecarga de
problemas la implantación; adquirir experiencia de otras implantaciones, asistir a
cursos de formación o contar con asesoramiento de consultores externos
especializados.
Gestionar el proyecto fijando los diferentes hitos con sus objetivos y resultados.
La autoridad y compromiso decidido de la Dirección de la empresa -incluso si al
inicio el alcance se restringe a un alcance reducido- evitarán un muro de excusas
93
para desarrollar las buenas prácticas, además de ser uno de los puntos
fundamentales de la norma.
La certificación como objetivo: aunque se puede alcanzar la conformidad con la
norma sin certificarse, la certificación por un tercero asegura un mejor enfoque, un
objetivo más claro y tangible y, por lo tanto, mejores opciones de alcanzar el éxito.
Eso sí, la certificación es la "guinda del pastel", no es bueno que sea la meta en sí
misma. El objetivo principal es la gestión de la seguridad de la información
alineada con el negocio.
No reinventar la rueda: apoyarse lo más posible en estándares, métodos y guías
ya establecidos, así como en la experiencia de otras organizaciones.
Servirse de lo ya implementado: otros sistemas de gestión (como ISO 9001 para la
calidad o ISO 14001 para medio ambiente) ya implantados en la organización son
útiles como estructura de trabajo, ahorrando tiempo y esfuerzo y creando
sinergias; es conveniente pedir ayuda e implicar a responsables y auditores
internos de otros sistemas de gestión.
Reservar la dedicación necesaria diaria o semanal: el personal involucrado en el
proyecto debe ser capaz de trabajar con continuidad en el proyecto.
Registrar evidencias: deben recogerse evidencias al menos tres meses antes del
intento de certificación para demostrar que el SGSI funciona adecuadamente. No
precipitarse en conseguir la certificación.
Mantenimiento y mejora continua: tener en consideración que el mantenimiento y
la mejora del SGSI a lo largo de los años posteriores requerirán también esfuerzo
y recursos”.
CURIOSIDADES
Una de las curiosidades más grandes sobre la ISO 27000 y que muchas personas no
entienden, es porque de la serie de normas de la ISO 27000 solo es certificable la ISO
27001, y esto es debido a que es la norma que define el modelo completo de gestión de
seguridad de la información según el ciclo PDCA aunque, para algunos procesos, se
apoya en otras normas relacionadas no certificadas, como la ISO 17799 (que pasaría a
ser ISO 27002 en 2007).
Una organización de certificación acredita, mediante una auditoría. Esta entidad establece
el número de días y auditores necesarios, puede realizar una pre-auditoría (no obligatoria)
y lleva a cabo una auditoría formal. Si el informe es favorable, la empresa recibirá la
certificación.
El número de certificaciones ha aumentado considerablemente en los últimos años como
demostración de la relevancia que tiene la protección de la información para el desarrollo
de las actividades de las organizaciones y para mantener y desarrollar el tejido industrial
de los diferentes países y en todo el mundo. Concluyendo que la ISO/IEC 27000 en
general es muy importante para el crecimiento de una empresa, ya que al obtenerla se
incluyen muchos beneficios que quizás en un principio no se notarán por los compromisos
94
y reglas que la empresa tomará pero que dentro de un tiempo todo ese esfuerzo se
convertirá en éxito para la organización.
Ilustración 25: Evolución de certificaciones ISO 27001 en México Tomada de: (ISO, 2013).
Ilustración 26: Distribución Mundial de certificaciones en ISO/IEC 27001 en 2012
Tomada de: (ISO, 2013).
95
NYSE NMX-1-059-/02 Moprosoft y Evalsoft
96
Introducción
A continuación se presentara como trabaja Moprosoft, así como las características que lo
componen, sus atributos y aplicación. Moprosoft fue fundada por la Dra. Hanna Oktaba
que es profesora en la facultad de ciencias de la UNAM y además es vicepresidenta de la
AMCIS.
97
¿Qué es Moprosoft?
Es un modelo para la industria del software. Un modelo para la mejora y evaluación de los
procesos de desarrollo y mantenimiento de sistemas y productos de software.
Desarrollado por la Asociación Mexicana para la Calidad en Ingeniería de Software.
(Alvarado J, slideshare, 2013)
Características
Las categorías de procesos corresponden a niveles organizacionales de administración
esto significa que tiene capacidad organizacional en gestión de proyectos y cuenta con
procesos integrados y relacionales y fondo en producto de su capitalización, además de
que es muy fácil de entender.
Se creó con la referencia de otros modelos
(Gaona O,uvmnet.com, 2013)
Ilustración 27Modelos de referencia para Moprosoft (uvmnet.omargaona.com, 2013, pag 11)
Atributos
Estructura de procesos:
98
Ilustración 28: Estructura de Procesos (uvmnet.omargaona.com, 2013, pag 15)
Gestión de Negocio
Establecer la razón de ser de la organización, sus objetivos y las condiciones para
lograrlos, para lo cual es necesario considerar las necesidades de los clientes, así como
evaluar los resultados para poder proponer cambios que permitan la mejora continua.
(Gaona O,uvmnet.com, 2013)
Ilustración 29: Procesos de la gestión de negocios (uvmnet.omargaona.com, 2013, pag 17)
99
Gestión
Establecer los procesos de la organización, en función de los procesos requeridos
identificados en el plan estratégico así como asegurar que los proyectos contribuyan al
cumplimiento de los objetivos
(Gaona O,uvmnet.com, 2013)
Ilustración 30: Categorías de la gestión (uvmnet.omargaona.com, 2013, pag 18)
Operación
Establecer y llevar a cabo sistemáticamente las actividades que permitan cumplir con los
objetivos de un proyecto en tiempo y costo esperados.
(Gaona O,uvmnet.com, 2013)
100
Ilustración 31: Categorías de la operación (uvmnet.omargaona.com, 2013, pag 26)
Niveles o etapas
Descripción
Ilustración 32: Niveles por proceso de Moprosoft (uvmnet.omargaona.com, 2013, pag 8)
En cada nivel hay actividades para realizar
El proceso predecible se mejora continuamente
El proceso establecido opera bajo límites definidos y conocidos
El proceso realizado y gestionado se implementa con un proceso
definido
El proceso realizado se administra
El proceso se implementa y alcanza su propósito
101
Ilustración 33: Actividades de una fase (uvmnet.omargaona.com, 2013, pag 33)
102
Aplicación
Ilustración 34: Proceso de ejecución de Moprosoft (uvmnet.omargaona.com, 2013, pag 5)
Moprosoft opera con los siguientes márgenes de trabajo
Definición de conceptos y productos
Requisitos de proceso (Moprosoft).
Guía de implantación de procesos
Directrices para la evaluación de procesos (Evalsoft).
El propósito de Evalsoft es la evaluación de procesos para la industria de software y
otorgar a la organización solicitante un perfil del nivel de capacidad de los procesos
implantados en la organización y un nivel de madurez de capacidades
(Gaona O,uvmnet.com, 2013)
¿Es certificable?
Moprosoft es capaz de certificar empresas que sigan su modelo de trabajo, entre ellas
destacan las siguientes:
Geoware SA de CV
INFOPOWER SA de CV
INFOPOWER SA de CV
Global BestTech Systems SA
TECNOLOGIA EN INFORMATICA MODERNA S.A. DE C.V. (TIMSA)
E-Software & Business Solution, SA de CV
Sierra Tecnologías Regiomontanas SA de CV
103
Vision Systems de México SA de CV
Conclusión
Moprosoft es una norma mexicana para la tecnología de la información dentro de los
modelos de procesos y evaluación para desarrollo y mantenimiento de software, está
adaptada a lo que ocupan las industrias como norma de trabajo para procesos, donde
dice que hacer y cómo hacerlo con ayuda de Evalprosoft que es el método usado en la
norma para evaluar.
Ilustración 35: Representación gráfica de Moprosoft (uvmnet.omargaona.com, 2013, pag 14)
104
IEEE 828
105
Introducción
Dentro de este documento se proporciona un idea de referencia hacia el contenido del
estándar IEEE Std. 828 que habla sobre el “Plan de Gestión de la Configuración
Software” (PGCS).
Que está dirigido hacia la aplicación de reglas de Gestión de la Configuración del
Software en los proyectos de ingeniería, que es la causa de una de las principales
relaciones que tiene con el IEEE Std. 1042 (Guide for Software Configuration
Management).
Dentro de este documento se menciona una descripción de lo que establece el estándar
IEEE 828 referenciando al estándar 1024 puede ayudar a complementarlo mejor.
En general este documento contiene lo que el Plan de Gestión de Configuración de
Software debe incluir, que es:
Descripción del proyecto.
Identificación de los elementos de configuración a los que se aplicará GCS.
Identificación de otro software a incluir en el plan.
Relación de la GCS con el hardware o actividades de configuración del sistema del
proyecto.
Grado de formalidad, profundidad de control y porción del ciclo de vida al que se
aplicará GCS.
Limitaciones, tales como restricciones de tiempo, que se aplican al plan.
Supuestos que deberían tener impacto en el costo, planificación o capacidad para
desarrollar las actividades de GCS definidas (por ejemplo, cliente o disponibilidad
de herramientas).
Términos claves.
Políticas, directivas, procedimientos, estándares, terminología y documentos
relacionados.
El IEEE Std. 828-1998 establece los contenidos mínimos que deben aparecer en el Plan
de Gestión de la Configuración Software.
Dicho plan puede ser un documento aislado o formar parte de otro documento (e.g. el
plan del proyecto o el plan SQA). Así mismo Puede usarse junto al IEEE Std.1042-1987
Guide for Software Configuration Management.
106
IEEE 828 Definición:
IEEE estándar para el software: Planes de Gestión de la Configuración IEEE Std 828-
1998 es una de las más amplias guías usadas y efectivas para la implementación de los
Planes de Gestión.
Objetivo La Gestión Integral del Proyecto marca como objetivo de la gestión de configuración,
garantizar que los cambios no se realicen de forma inapropiada, debe existir una
integridad en el producto obtenido a lo largo del ciclo de vida del software; todos los
interesados en su desarrollo, deben tener la versión correcta de la aplicación y su
documentación.
Esta norma se puede utilizar en conjunción con las siguientes publicaciones:
IEEE Std 610,12 a 1.990, IEEE Glosario estándar de Software Engineering
Terminología.
IEEE Std 730-1998, Norma IEEE sobre los Planes de Aseguramiento de Calidad
de Software.
IEEE Std 1042-1987 (Reaff 1993), Guía de IEEE para la gestión de configuración
de software
107
Ilustración 36: Modelo Cascada IEEE Std. Tomada de: La confiabilidad. J. L. Roca
Las siguientes siglas aparecen en el texto de esta norma:
IEC Informes de Estado de la Configuración
CCB Tablero de Control de Configuración
CI Elemento de Configuración
SCM gestión de configuración de software.
108
Etapas y Descripción de lo que el Estándar IEEE 828 Requiere
1. Introducción
Se debe proveer una introducción al contenido del plan de SCM para utilización tanto
por el resto de los integrantes del grupo como por el Director del Proyecto.
1.1. Propósito
Debe incluir información sobre el propósito específico de las actividades de SCM
que serán definidas en el plan, por ejemplo si el énfasis está dado en un control
riguroso, en una rápida respuesta a los cambios, en la documentación, entre otros.
1.2. Alcance
Debe establecerse brevemente el alcance de las tareas de SCM, identificando
intereses y responsabilidades específicas, lo que se incluye en el plan y lo que no se
incluye, información sobre los ítems en la configuración, tipo de control sobre cada
ítem, etc.
Ver: checklist “Issues to consider in Planning Section 1.2 – Scope”, Std. 1042 pág.
17.
1.3. Definiciones
Incluye las definiciones de los términos necesarios para entender el Plan de SCM
que ayuden a la comunicación entre los integrantes del grupo
Ver: checklist “Issues to consider in Planning Section 1.3–Definitions”, Std. 1042
pág. 18.
1.4. Referencias
Incluye la lista de documentos que son referenciados en el Plan de SCM >
Ver: checklist “Issues to consider in Planning Section 1.4–References”, Std. 1042
pág. 18.
109
2. Gestión de Configuración del Software (SCM)
El tema de esta sección es relacionar los elementos de la disciplina de SCM con las
actividades específicas del proyecto y/o de SCM en la institución. Se especificarán
organización, responsabilidades, agenda y recursos.
El proyecto se divide en 3 fases y cada una en dos iteraciones. Se debe mantener el
control de cada fase e iteración. La herramienta a utilizar para la gestión de
configuración es CVS.
2.1. Organización de SCM
Se especifican las funciones que debe cumplir cada entidad en la organización,
teniendo en cuenta la estructura y como asignar y coordinar de la mejor forma
posible las actividades de SCM que serán desarrolladas.
Ver: checklist “Issues to consider in Planning Section 2.1–Organization”, Std. 1042
pág.19.
2.2. Responsabilidades de SCM
Se especifican las responsabilidades y roles que desempeña el grupo o personas
encargadas de la gestión de configuración.
Determina la asignación de actividades a unidades organizativas:
- Unidad organizativa.
- Propósito y objetivos.
- Miembros y afiliaciones.
- Periodo de efectividad.
- Alcance de la autoridad.
- Procedimientos operativos.
El Responsable de SQA define los procedimientos administrativos para llevar
adelante la gestión de la configuración en conjunto con el Responsable de SCM,
tratando de que toda la tarea de SCM se automatice al máximo.
Ver: checklist “Issues to consider in Planning Section 2.2 – SCM Responsibilities’”,
Std.1042 pág.20.
3. Actividades de la Gestión de Configuración del Software
(SCM)
Se describe como se realizaran las actividades de SCM y la forma en la que se
cumplirán las responsabilidades asignadas en la sección anterior.
110
3.3. Identificación de la configuración
Se describe el esquema de configuración que refleje la estructura de los productos
generados a lo largo del proyecto.
Ver: checklist “Issues to consider in Planning Section 3.1– Configuration
Identification”, Std.1042 pág.23.
Ilustración 38: Procesos de identificación de la configuración.
Tomada de: Diseño e implementación del proceso de gestión de la configuración de software en la empresa de desarrollo Venture Venti.
3.3.1. Identificación de los ítems de configuración
La Gestión de la configuración software nos dice el como se registran los ítems de
configuración que serán controlados, se describen las líneas base que existirán
en el proyecto y su identificación mediante etiquetas
Registra:
- Los elementos que deben ser controlados.
- Cómo van a ser mantenidos a lo largo del proyecto.
- También define líneas base en los puntos dentro del ciclo de vida teniendo en
cuenta:
- El evento que crea la línea base*.
- Los elementos que son controlados en la línea base.
- Los procedimientos utilizados para establecer y cambiar la línea base.
- La autoridad requerida para aprobar cambios en las líneas base.
Ver: checklist “Issues to consider in Defining Baselines”, Std.1042 pág.24.
No todos los entregables marcados tendrán que ser ítems de la configuración, la
elección de que entregables serán objeto del control de versiones es tarea del
Responsable de SCM conjuntamente con el Responsable de SQA.
3.3.2. Denominación de los ítems de configuración
Se indica como se asignarán identificadores únicos a cada ítem de la
configuración, incluyendo métodos y procedimientos para asignarlos.
111
Se indica la siguiente nomenclatura para cada entregable en el modelo de
proceso, según la Línea de Trabajo:
Requerimientos:
RQALS: Alcance del Sistema
RQDRQ: Documento de Requerimientos
RQDVC: Documento de validación con el Cliente
RQGL: Glosario
RQMOD: Modelo de Casos de Uso
RQMD: Modelo de Dominio
RQRRQ: Resumen de las reuniones de requerimientos
Análisis:
ANERQ: Documento de Especificación de Requerimientos
ANMOD: Modelo de Análisis
Diseño:
DSMOD: Modelo de Diseño
DSDIST: Modelo de Distribución
Implementación:
IMDT: Documentación técnica
IMELBA: Ejecutable de la Línea Base de la Arquitectura
IMES: Ejecutable del Sistema
IMESF: Ejecutable Final del Sistema
IMEDT: Estándar de documentación técnica
IMEIM: Estándar de implementación
IMMTP: Manual técnico del prototipo
IMMOD: Modelo de Implementación
IMPINT: Plan de Integración
IMPROT: Prototipo
IMRREP: Reporte de revisión por pares
IMRVEP: Reporte de verificación por pares
Para los nombres de los archivos de código fuente se debe definir el
procedimiento que permita su identificación.
De todas las anteriores:
DESARQ: Descripción de la Arquitectura
112
Verificación:
VRCPRU: Casos de Prueba
VREVRIT: Evaluación de la verificación de la iteración
VRIFVR: Informe final de verificación
VRMOD: Modelo de Testeo
VRPRUP: Plan de Pruebas
VRPRUPPR: Plan de Pruebas del Prototipo
VRPLAN: Plan de Verificación
VRREPU: Reporte de Pruebas unitarias
VRREPIS: Reporte de Pruebas de integración
VRREPUIS: Reporte de Pruebas del Sistema
VRREVDOC: Reporte de verificación de documentos
VRREPRUPR: Reporte de pruebas del Prototipo
Gestión de Configuración (SCM):
SCMIAUD: Informe de la auditoría a la gestión de configuración
SCMPLAN: Plan de SCM
Gestión de Calidad (SQA):
SQADEVP: Documento de evaluación y ajustes al Plan de SQA
SQAENS: Entrega semanal de SQA
SQAINRV: Informe de revisión de SQA
SQAINRTF: Informe de Revision Tecnica Formal (RTF)
SQAINF: Informe final de SQA
SQAPLAN: Plan de SQA
Gestión del Proyecto (GP):
GPACQ: Acta de la Reunión Quincenal
GPDES: Documento de Estimaciones
GPDEVP: Documento de evaluación y ajustes del Plan del Proyecto
GPDRIES: Documento de riesgos
GPICONF: Informe de conclusiones de la Fase
GPISITP: Informe de Situación del Proyecto
GPIFAD: Informe final del Administrador
GPITERP: Plan de la iteración
GPPLAN: Plan del Proyecto
GPREGAC: Registros de Actividad
La Guía de SCMP marca estas especificaciones mencionadas anteriormente, sobre los
ítems de configuración.
3.3.3. Recuperación de los ítems de configuración
Se definen las bibliotecas que se mantendrán para realizar el control de versiones,
en general existen 3 tipos de bibliotecas: dinámica, controlada y estática
113
Ver: Sección 2.3.1 – Using Software Libraries, Std.1042 pág. 13.
3.4. Control de configuración
Se describe cómo será manejado el proceso de control de configuración. Las
modificaciones requieren un proceso de aprobación por lo que en está sección se
identifican los procedimientos que se utilizarán para procesar solicitudes de cambio
a las líneas base, responsabilidades y aprobaciones.
Ver: Sección – Issues to consider in processin changes, Std.1042 pág. 27.
3.4.1. Solicitud de cambios
Se indican los procedimientos que serán seguidos para realizar cambios en las
líneas base, desde la solicitud del cambio hasta su aprobación, describiendo los
documentos que serán generados en las distintas instancias del procedimiento de
cambios y adjuntando el formato que tendrán dichos documentos.
La documentación incluye:
- Nombre y versión del ECSs a cambiar.
- Nombre y organización del peticionario.
- Fecha de petición.
- Indicación de urgencia.
- Necesidad del cambio.
- Descripción del cambio pedido.
- Prioridad.
- Clasificación.
- Estado.
3.4.2. Evaluación de cambios
Se indican los procedimientos para hacer la evaluación de un cambio solicitado,
una vez recibida una solicitud de cambio se debe considerar el impacto que este
producirá en el proyecto.
3.4.3. Aprobación o desaprobación de cambios
Se indican las responsabilidades asignadas en el proceso de control de cambios,
quien o quienes estudiarán y aprobarán las solicitudes de cambio, en general las
responsabilidades están asociadas a los productos afectados.
3.4.4. Implementación de los cambios
Se describe como se implementará un cambio aprobado, incluyendo la información
de la solicitud del cambio.
La documentación a rellenar después de cada cambio incluye:
- La petición de cambio asociada.
- Los nombres y versiones de los elementos afectados.
114
- Fecha de verificación y responsable.
- Fecha de entrega o instalación y responsable.
- Identificador de la nueva versión.
- Métricas de fallos.
- Software de implementación del cambio.
- Además, también se especifican las actividades de planificación de entrega y
control.
3.5. Estado de la configuración
Se describen los reportes de configuración que serán realizados, el tipo,
frecuencia, información que contendrán y control de acceso. Y dentro de la
Gestión de Configuración se menciona lo siguiente:
En particular informa sobre:
- Los ECSs van a ser susceptibles de líneas base e informes.
- Los tipos de informes de contabilidad de estado a generar y su frecuencia.
- La información que va a ser recogida, almacenada, procesada y hecha pública
- La manera de controlar el acceso al estado de los datos.
Cómo mínimo, para cada ECS debemos informar sobre:
- Su versión inicial aprobada.
- El estado de los cambios pedidos.
- Estado de implementación de los cambios aprobados.
3.6. Auditorías de configuración
Se describen las auditorías que serán realizadas sobre los ítems de configuración
para determinar que los mismos son consistentes.
- El plan debe identificar las auditorias de configuración y revisiones del proyecto,
i.e., en que puntos se deben establecer revisiones para obtener líneas bases (en la
acepción de versión).
- Para cada auditoria o revisión planificada se debe definir:
- El objetivo.
- El ECS a auditar o revisar.
- La planificación.
- Los procedimientos.
3.7. Control de interfaces
Se describen las actividades para la coordinación de cambios al proyecto con
cambios a ítems fuera del alcance de este plan.
- Para cada interfaz, se debe identificar:
- Su naturaleza.
- Las organizaciones afectadas.
- La manera de controlar los ECSs del interfaz.
- La manera de documentar e incluir en líneas base, los ECSs de la interfaz.
115
3.8. Control de subcontratos y vendedores
No se aplica a este curso, pero dentro de Gestión de la configuración software menciona
lo siguiente:
Controlan los ECSs (Informes de Estado de la configuración) que provienen del exterior:
- Para cada ECS externo se debe identificar:
- Los requisitos GCS por parte de la empresa externa.
- La forma de controlar a la empresa externa.
- Auditorias y revisiones de configuración a practicar en la empresa externa.
- La forma de probar y verificar los ECSs externos antes de incluirlos en el proyecto.
- Gestión de copyright y royalties.
- Participación de la empresa externa en el proceso de GCS
Agenda de SCM
Se describen en el tiempo las actividades de SCM que serán realizadas, se establecen
la secuencia y coordinación para las actividades GCS y para todos los eventos que
afecten la planificación del proyecto.
Tabla 11: Actividades de SCM definidas en el modelo de proceso. Tomada de Guía de SCMP (pag7)
Actividad Entregable Asociado
Elaboración del Plan de SCM Plan de SCM
Definición de ambientes controlados Plan de SCM
Mantenimiento de la línea base del SW Informe de la auditoría a la gestión
4. Recursos de SCM Se describen los recursos con que se cuenta: las herramientas, técnicas, personas etc.
para la implementación de las actividades de control de configuración.
5. Mantenimiento del plan GCS Dentro del contenido de la Guía de SCMP está Identifica las actividades y
responsabilidades necesarias para garantizar una planificación continúa de la GCS
durante todo el proyecto.
Se debe identificar:
- El responsable de monitorizar el plan.
- La frecuencia de actualización
- La forma de evaluar y aprobar los cambios al plan.
116
- La forma de hacer e informar de los cambios al plan
Ventajas y Desventajas de IEEE 828 Wilson Santiago expresa como más sobresalientes las siguientes ventajas y desventajas
de la norma 828.
Ventajas
La ventaja más favorable de este estándar es su flexibilidad además contiene
instrucciones específicas que ayudan a evitar que el usuario elimine algún
componente del plan sin previamente especificar porque lo desea eliminar.
Es fácil de usar, lo que le permitirá al usuario su entendimiento y poder distinguir
entre aquellos ítems que son obligatorios y los que son opcionales en este plan.
Es un estándar muy completo debido que los componentes del plan están
descritos en su adecuada profundidad.
Desventajas
En la definición de términos hace referencia a otros estándares, en lugar de
definirlos en el mismo documento.
No posee ejemplos suficientes y no trata a detalle el tema de herramientas
automatizadas.
No involucra a todo el proceso de Gestión de la Configuración del Software,
simplemente se enfoca en el plan.
117
IEEE 830
118
Introducción
En la Ingeniería de Software se pueden encontrar metodologías de desarrollo con 4 o
hasta 6 etapas o fases, pero todas inician con la etapa de “Análisis”. Primera etapa donde
se lleva a cabo la comprensión y documentación de las necesidades y problemas del
cliente además de ser la etapa que asienta la base del resto del desarrollo.
119
Definición, Características, Etapas
Sommerville en el modelo cascada propone 5 etapas del ciclo de vida del software, la
primera es “Análisis y definición de requerimientos: Los servicios, restricciones y metas
del sistema se definen a partir de las consultas con los usuarios. Entonces, de definen en
detalle y sirven como una especificación del sistema” (Sommerville, I, Pág. 62, 2005).
Ilustración 39: El ciclo de vida del software. Tomada de Ingeniería del software por
Sommerville
IEEE 830 Recommended Practice for Software Requirements Specifications o en español
“Práctica recomendada para la especificación de requisitos de software” es una norma
que se encarga de guiarnos para obtener éxito en la especificación de requisitos, fue
creada por el IEEE en diciembre de 1993.
La implementación de la norma no se lleva a cabo de una forma rigurosa ni obligatoria
para los grupos desarrolladores en la Ingeniería del Software, pero la documentación
complementa y resalta el proyecto aun punto donde se vuelve indispensable tanto para el
cliente como para el desarrollador.
La norma IEEE 830 consiste en la redacción y elaboración del documento SRS (Software
Requirements Specifications), documento describirá y representara su contenido en varios
esquemas y ayuda en la selección de los productos internos y comerciales del mismo.
120
Laura expresa que el documento de especificación de requisitos de software (SRS por
sus siglas en inglés) tiene una estructura de 4 elementos: introducción, descripción
general, requisitos específicos y apéndices.
Pero para un buen desarrollo del SRS Alex Merino expresa aspectos a tener en cuenta
como:
Naturaleza del SRS
El SRS es una especificación para un producto de software en particular, ya sea
un sólo programa, o un conjunto de programas, que realicen ciertas funciones en
un ambiente específico.
Frecuentemente, el usuario sólo conoce las necesidades pero no el tipo de
solución más conveniente, de forma que el usuario no sabe si necesitará un solo
programa o más de uno.
El SRS puede escribirse por uno o más representantes del proveedor, uno o más
del cliente, o por ambos. Lo más recomendable es que haya representantes de
ambas partes, donde el usuario/cliente puede redactar un borrador inicial y
después revisarlo con el proveedor.
Ambiente del SRS
El SRS es la fuente principal para hacer el plan detallado de un proyecto de
software, en donde el SRS puede referirse a los requerimientos deseados de
todos los componentes de un sistema grande o a módulos.
Cuando es por módulos, tiene que mantenerse la consistencia en los documentos,
es decir la interacción del uno con los otros, definiendo sus funcionalidades y el
nivel de desempeño deseado
Características deseables del SRS
o Correcto: si se tienen los requerimientos que el software deberá cumplir.
o No ambiguo: si cada requerimiento establecido tiene una sola
interpretación posible. En casos donde alguna palabra pudiera tener
múltiples significados, se debe incluir su definición precisa en un glosario
que se adicione al SRS.
o Completo: el SRS es completo si incluye:
- Todos los requerimientos significativos sobre funcionalidades,
desempeño, restricciones de diseño, atributos, o interfaces
externas.
- Las respuestas que debería dar el software a todas las posibles
entradas de datos en todas las situaciones posibles.
- Especificación de unidades de medida (si son aplicables).
121
- En caso de que el SRS tenga diagramas o tablas informativas, hay
que darles número o identificación.
o Consistente: Los diversos requerimientos escritos tienen que ser
compatibles entre sí; no debe haber contradicciones ni conflictos entre
ellos. Para lograr la consistencia deben evitarse los siguientes conflictos:
- En características especificadas de objetos del mundo real.
- De lógica o de tiempo entre dos actividades.
- Referencia a un mismo objeto del mundo real pero usando
diferentes palabras para el mismo objeto.
o Ordenado con base en importancia y/o estabilidad: Cada requerimiento
especificado debe tener alguna identificación (número, letra, secuencia
alfanumérica) para indicar su grado de importancia o de estabilidad.
Algunos requerimientos son más importantes que otros, al “rankearlos” se
puede dar a cada requerimiento la prioridad merecida.
o Verificable: Un requerimiento es verificable si existe algún método rentable
mediante el cual se pueda analizar si el software cumple ese
requerimiento. Si no existe algún método para saber si el software cumple
o no un requerimiento, entonces ese requerimiento debe ser revisado o
eliminado.
o Modificable: Es modificable si la estructura y estilo de redacción permiten la
realización de cambios en forma fácil, completa y consistente. Para esto es
recomendable:
- Incluir índice, tabla de contenido y tabla de referencias cruzadas.
- Cada requerimiento debe aparecer sólo una vez (la redundancia
propicia errores de inconsistencia).
- Poner cada requerimiento separado de los demás.
o Rastreable: Un SRS es rastreable si el origen de cada requerimiento es
claro, y si facilita el seguimiento de cada requerimiento a lo largo del
proyecto de software. Hay 2 tipos de rastreabilidad:
- Hacia atrás: en cada requerimiento se menciona explícitamente su
fuente documental.
- Hacia delante: los documentos que se deriven del SRS deben usar
las identificaciones de requerimientos como fueron dadas en el
SRS. La rastreabilidad hacia delante facilita las actividades de
diseño, codificación, y modificación del software.
Preparación conjunta del SRS
El desarrollo de un software solamente debería iniciar cuando el cliente y el
proveedor estén de acuerdo acerca de lo que el software deberá hacer.
122
Evolución del SRS
Un SRS puede necesitar cambios mientras el software está en etapas de diseño o
de desarrollo. Los cambios pueden estar motivados por: deficiencias, errores,
omisiones o imprecisiones en el documento original.
Cada requerimiento debe documentarse tan completo como sea posible, aún si
pudiera necesitar cambios posteriormente, si hubiera cambios los requerimientos
tienen que documentarse con el propósito de: identificarlos, controlarlos,
rastrearlos, y reportarlos.
Tanto el cliente como el proveedor deben designar a su respectivo responsable de
autorizar (o rechazar) cambios en los requerimientos.
Prototipos
Un prototipo es un pequeño programa parecido al software solicitado que sirve de
ejemplo, muestra o modelo para que el cliente vaya especificando sus
requerimientos en forma progresiva junto con el desarrollador. El prototipo es útil
para:
- Que el cliente/usuario vea y describa más fácilmente las
funcionalidades que desea.
- Prever aspectos de la conducta del sistema, haciendo que el SRS
sea más completo y preciso-
- Reducir la cantidad de cambios durante las etapas de diseño o
desarrollo.
Un prototipo puede ayudar al usuario a definir detalles específicos de la interfaz
humana o de las funcionalidades que requiera, de forma que facilita al
desarrollador el diseño y la programación del software
Diseño “implícito” en el SRS
Aunque el SRS no constituye un documento de diseño, implícitamente está
diciéndole a los desarrolladores lo que se espera que ellos diseñen. Es decir:
establece restricciones. El SRS tiene que especificar las funcionalidades que se
aplicarán sobre ciertos datos para producir resultados en cierto lugar para
determinados usuarios.
Requerimientos de proyecto “implícitos”
El SRS se enfoca en el software como producto, no en su proceso de creación.
Implícitamente establece restricciones sobre la planeación y administración del
proyecto correspondiente.
123
Ya vimos que la norma es para la especificación de requisitos, que como producto
obtenemos el documento SRS, las consideraciones para implementarlo y que el
documento SRS se estructura de 4 elementos. A continuación de muestra la organización
completa del SRS.
Introducción
Muestra e incluye la descripción general del SRS
o Propósito
Aquí se tiene que explicar para qué se usará el documento y especificar a
qué tipo de lectores está destinado (usuarios, clientes, analistas,
programado res, etc.).
o Ámbito o alcance del sistema
Aquí se tiene que identificar por su nombre genérico el producto(s) de
software que se estén requiriendo así como explicar lo que el software
hará, y, si fuera necesario aclararlo, también lo que no se espera que haga.
También se debe describir para qué se aplicará el software, incluyendo sus
beneficios relevantes, objetivos, y metas.
o Definiciones, acrónimos y abreviaturas
Dar las definiciones de todos los términos, acrónimos (siglas) y
abreviaturas que sean pertinentes para el adecuado entendimiento del
SRS. Esta información puede ofrecerse mediante referencias a uno o más
apéndices del SRS o referencias hacia otros documentos (manuales de la
organización, procedimientos de aseguramiento de calidad, hojas de
registro, etc.).
o Referencias
Ofrecer una lista completa de todos los documentos a los que se haga
referencia en el SRS. Se debe identificar cada documento mediante su
título, número de reporte (si es aplicable), fecha, y organización que lo
público. También se deben especificar las fuentes de las cuales pueden
obtenerse los documentos referenciados. Esta información puede ofrecerse
haciendo alusión a un apéndice o hacia otro documento.
o Visión o descripción general del documento
Describir lo que contienen las secciones restantes del documento y explicar
cómo está organizado.
124
Descripción general
Aquí no se establecen los requerimientos específicos, sino que se describe el
fondo general que da lugar a los requerimientos
o Perspectiva del producto
Describir el software en perspectiva con otros programas relacionados:
similitudes y diferencias.
- Si el software es independiente y totalmente auto- contenido, eso
tiene que decirse aquí.
- Si se está requiriendo un software que formará parte de un sistema
más grande, se tiene que describir la relación de los requerimientos
del sistema grande con las funcionalidades del software requerido y
debe identificarse cómo se comunicarán ambos.
- Para describir las relaciones entre el software requerido y el sistema
grande, pueden ser útiles los diagramas de bloques.
- En los diagramas de bloques se pueden mostrar los componentes
principales del sistema grande y su relación jerárquica (y de flujo de
datos) con el software requerido
- Describir las condiciones (restricciones) dentro de las cuales deberá
funcionar el software:
Interfaces de sistema
Lo que hay entre los diversos módulos del sistema
Interfaces de usuario
Lo que estará entre el usuario y el software.
Interfaces de hardware
Qué hardware usará el software para entrada/salida de
información.
Interfaces de software
Qué otros software se necesitarán para que el software
requerido pueda funcionar.
Interfaces de comunicaciones
Qué tecnología de redes se usará para comunicar a las
computadoras en las cuales se usará el software.
Restricciones de memoria
Se debe especificar si existe o no algún límite en cuanto a la
memoria (primaria o secundaria) disponible por el software
para ser ejecutado.
125
Operaciones
Especificar los diferentes modos de operación del software
por parte del usuario.
Requerimientos de adaptación a un lugar
Definir los requerimientos respecto a datos o secuencias de
inicialización del software que sean específicas para un
lugar, una misión o un modo operacional específico.
o Funciones del producto
Sumario de las funciones principales
o Características de los usuarios
Esta descripción ayuda a comprender los motivos que dan origen a los
requerimientos y describir sus características respecto a:
- Nivel educativo
- Experiencia profesional
- Capacidades técnicas.
o Restricciones
Información de posibles limitantes que deberán respetar los diseñadores,
como:
- Políticas regulatorias aplicables.
- Limitaciones en el hardware (p.ej. velocidad del microprocesador).
- Interfaces hacia otras aplicaciones.
- Funcionamiento en paralelo.
- Funciones de auditoría de software.
- Protocolos de comunicaciones de redes.
- Requerimientos de confiabilidad.
- Criticidad de la aplicación.
- Consideraciones sobre seguridad física y lógica
o Suposiciones y dependencias
Cada uno de los factores que afecten a los requerimientos especificados,
pero teniendo en cuenta que estos factores no son restricciones de diseño
para el software.
o Requisitos futuros o posposición de requerimientos
Aquí se dice cuáles son los requerimientos que pueden atenderse hasta
versiones futuras del sistema.
Requisitos específicos
126
Aquí no se establecen los requerimientos específicos, los cuales se definen
detalladamente.
o Interfaces externas
Se describirán los requisitos que afecten a la interfaz de usuario, interfaz
con otros sistemas (hardware y software) e interfaces de comunicaciones.
o Funciones
Esta subsección (quizá la más larga del documento) deberá especificar
todas aquellas acciones (funciones) que deberá llevar a cabo el software.
o Requisitos de rendimiento
Se detallaran los requisitos relacionados con la carga que se espera tenga
que soportar el sistema. También, si es necesario, se pueden especificar
los requisitos de datos.
o Restricciones de diseño
Todo aquello que restrinja las decisiones relativas al diseño de la
aplicación: Restricciones de otros estándares, limitaciones del hardware,
etc.
o Atributos del sistema
Se detallaran los atributos de calidad del sistema, que sea fiable, portable,
y muy seguro. Deberá especificarse que tipos de usuarios están
autorizados, o no, a realizar ciertas tareas, y como se implementaran los
mecanismos de seguridad.
o Otros requisitos
Cualquier otro requisito que no encaje en otra sección.
Apéndices
Pueden contener todo tipo de información relevante para la ERS pero que,
propiamente, no forme parte de la ERS. Por ejemplo:
- Formatos de entrada/salida de datos, por pantalla o en listados.
- Resultados de análisis de costes.
- Restricciones acerca del lenguaje de programación.
Al redactar el documento SRS suceden cosas interesantes, en principio se ven los
requisitos al derecho y al revés. La redacción cuida en cada uno de los puntos la
secuencia y lógica de los requisitos, tiene autoridad y se ve la posibilidad de eliminar
requisitos. Al final se obtiene lo que se busca como parte de la metodología en la etapa
de “Análisis”:
127
Se describe claramente lo que el cliente quiere.
Se entiende las operaciones implementadas.
Se conoce el funcionamiento o proceso, desde la intención de cada pantalla, los
datos a introducir, los flujos de trabajo y productos.
Ayuda al grupo desarrollador en el análisis, diseño y programación al reducir
errores y tiempos de desarrollo, con esto también se reduce la posibilidad de
repetir la fase de análisis por falta de información.
Posibilita que a futuro se le puedan hacer mejoras o innovaciones al proyecto.
Además muchos problemas en los proyectos de software se deben a una inadecuada
especificación de requerimientos, sería ideal practicar el SRS contemplando que puede
adaptarse a las necesidades y por consiguiente puede ser un buen guion cuando no se
tiene experiencia, de ahí la importancia en la especificación de requisitos del software.
Carlos Humberto compartió la implementación del SRS en su empresa ArMaSoft “El
proyecto sobre el cual se va aplicar la norma será el proyecto ArkaGold el cual es un
software multimedia que busca la generación de diversión. Se pretende establecer una
definición completa y global de la operación y funcionamiento del software ArkaGold esto
con el fin de recibir una aceptación por parte de los usuarios a los requerimientos
planteados”. De aquí se rescata que su aplicación será para los videojuegos, pero de
cualquier forma implicara un desarrollo con necesidades y requerimientos y es donde
interviene el SRS como herramienta en la tarea de especificar los requisitos.
Otros aspectos destacables Michael los compartió en su portal, el ahí propone que se
elabore un buen ERS para que las ventajas sean evidentes y pasen a ser oportunidades
como:
Servir como base para el acuerdo entre cliente y proveedor sobre lo que el
software ha de hacer.
Reducir el esfuerzo de desarrollo.
Proporcionar la base para la estimación de costes y plazos.
Proporcionar el punto de partida para las actividades de validación y verificación.
Facilitar la transferencia del software, a nuevos usuarios o nuevas máquinas.
Servir de base para ampliaciones o mejoras.
Cuando se desarrolla un sistema muy grande, las normas que se pueden entrelazar son:
610 IEEE Standard Computer Dictionary
730 IEEE Standard for Software Quality Assurance Plans
828 IEEE Standard for Software Configuration Management Plans
982.1 IEEE Standard Dictionary of Measures to Produce Reliable Software
982.2 IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce
Reliable Software
983 IEEE Guide for Software Quality Assurance Planning
1002 IEEE Standard Taxonomy for Software Engineering Standards
128
1012 IEEE Standard for Software Verification and Validation Plans
1016 IEEE Recommended Practice for Software Design Descriptions
1028 IEEE Standard Software Reviews and Audits
1042 IEEE Guide to Software Configuration Management
1058.1 IEEE Standard for Software Project Management Plans
1074 IEEE Standard for Developing Software Life Cycle Processes
1233 IEEE Guide for Developing System Requirements Specifications.
129
BIBLIOGRAFÍA
ADMIN. (24/06/2011). Especificación de Requisitos IEEE830. Consultado el
9/11/2013. Disponible en: http://www.ingenierosistemas.com/especificacion-de-
requisitos-iee830/2011/06/24/
Alarcosqualitycenter.com, (2013), AQC Lab: Laboratorio de Evaluación de la
Calidad Software, Recuperado de
http://www.alarcosqualitycenter.com/index.php/laboratorio-evaluacion-calidad-
software
Alex Merino. (17/11/2012). NORMA IEEE 830 PARA ESPECIFICACIÓN DE
REQUERIMIENTOS DE SOFTWARE. Consultado el 9/11/2013. Disponible en:
http://www.slideshare.net/amerino2010/ieee-830
Allsoft (2011) Moprosoft, consultado el 10/11/2013, disponible en:
http://www.allsoft.com.mx/recursos/AS-Moprosoft.pdf
Alvarado, J (10/04/2013) Calidad en el desarrollo de software, consultado el
10/11/2013, disponible en: http://www.slideshare.net/JosephAlvarado5B/cuadro-
comparativo-entre-moprosoft-y-cmmi-19007850#btnNext
Arroyo, V. S. (s.f.). ISO 12207. Obtenido de ISO 12207 Ciclo de vida del software:
http://unfviso12207.webcindario.com/index.php?mod=contenido_inicial
ATTAChile S.A. (2013). Nueva ISO 27000:2013. Cambios a tener en cuenta.
Recuperado de
http://www.atta.cl/index.php?option=com_content&view=article&id=144%3Anueva-
iso-270002013-cambios-a-tener-en-
cuenta&catid=4%3Acontenidoarticulos&Itemid=25
Audisec. (2012). La implantación de SPICE permite mejorar paulatinamente la
calidad de los proyectos software. Recuperado de
http://www.audisec.es/es/servicios/spice-iso-15504- calidad-software.html
Ávila, T.M. (2011). Mejora en los procesos del ciclo de la vida del software,
ISO/IEC 15504. Recuperado de http://www.it360.es/iso15504.php
Baldeón Garzón, M. J. (2012). Plan Maestro de Seguridad Informatica para la
UTIC de la Espe con Lineamientos de la Norma ISO/IEC 27002. (Tesis de mestría,
Escuela Politécnica del Ejercito Vicerrectorado de Investigación y Vinculacion con
la Colectividad). Recuperado de http://repositorio.espe.edu.ec/handle/21000/6025
Ballester, M. (22 de Abril de 2010). ISACA Corporation. Obtenido de
http://www.isaca.org/Journal/Past-Issues/2010/Volume-1/Pages/Gobierno-de-las-
TIC-ISO-IEC-385001.aspx
Carlos Humberto Marín Murillo. (23/09/2009). Especificación de Requerimientos
del Sistema -SRS. Consultado el: 10/11/2013. Disponible en:
http://arkagold.googlecode.com/svn-history/trunk/SRS/
130
Canieti (2012) Listado Empresas Certificados Moprosoft, consultado el 10/11/2013,
disponible el: http://www.canieti.org/servicios/fondos/empresasmoprosoft.aspx
Casco, G., Trevisan, D., Molinas, A., & Molinas, N. (2008, p.19). Software Process
Improvement en Capability Determinatio. Recuperado de
tesisgrado.googlecode.com/svn/trunk/.../ISO%2015504/.../ISO15504.ppt
Chacon, J. M. (15 de abril de 2012). Modelos de gestion de la calidad de software
ISO 12207. Obtenido de Modelos de gestion de la calidad de software:
http://juanmarcosteoria2.blogspot.mx/2008/01/normas-iso-12207.html
Cristancho, J. A. (1 de 07 de 2001). Evaluación de la calidad del software
educativo bajo el estándar ISO 9126. Obtenido de http://josecristancho.com/wp-
content/uploads/2011/03/Evaluaci%C3%B3n-de-la-calidad-del-software-educativo-
bajo-el-est%C3%A1ndar-ISO-9126.pdf
EcuRed. (2013). ISO/IEC 15504. Recuperado de
http://www.ecured.cu/index.php/ISO_15504
Euopean Quality Assurance (EQA). (2013). Sistemas de Gestión de Tecnología de
la Información ISO 20000. Recuperado de
http://www.eqa.org/documentos/ISO20000.pdf.
Fermín, F. (25 de 11 de 2009). NORMA ISO 9126. Obtenido de
http://normaiso9126.blogspot.mx/
Fernández, C. M. (1 de Enero de 2011). Dirección de Desarrollo - Aneor. Obtenido
de http://www.clubcalidad.com/V2/html/control/file/ISO%2038500%20AENOR.pdf
Francavilla, C. (27 de Junio de 2012). Slideshare.net Corporation. Obtenido de
http://www.slideshare.net/CarlosFrancavilla/gobierno-corporativo-de-ti
Francisco Ruiz, M. P. (2001). Grupo Alarcos. Recuperado el 7 de Noviembre de
2013, de Universidad de Castilla-La Mancha:
http://alarcos.esi.uclm.es/per/fruiz/curs/mso/trans/s4.pdf
García, C., & Garzás, J. (2008, p.2). La certificación por niveles de madurez de
ISO/IEC 15504. Recuperado de http://www.kybeleconsulting.com/wp-
content/uploads/2011/11/MCGarcia_CertificacionNivelesMadurez_ISO1550
4.pdf
International Best Practice Institute. (s.f.). ISO/IEC 15504. Recuperado de
http://ibpi.org/standard/isoiec-15504/.
International Organization for Standardization. (2006). ISO. Recuperado el 7 de
Noviembre de 2013, de
http://www.iso.org/iso/catalogue_detail.htm?csnumber=39064
131
ISO/IEC. (1 de febrero de 2000). Obtenido de ISO.org: http://webstore.iec.ch/p-
preview/info_isoiec14598-3%7Bed1.0%7Den.pdf
ITIL.org. (2013). ISO 20000. Recuperado de
http://translate.google.com.mx/translate?hl=es&sl=en&u=http://www.iso20000.ch/e
n/vomkennen/cobit/itil-cobit-
iso20000mapping/index.php&prev=/search%3Fq%3Drelacion%2Bentre%2Biso%2
B20000%2By%2Bcobit%26espv%3D210%26es_sm%3D122
ISO 14598-4: Software Engineering - Product Evaluation - Part 4: Process for
Acquirers. (1 de octubre de 1999). Obtenido de Industry Standards & Regulations:
http://engineers.ihs.com/document/abstract/JAFQCAAAAAAAAAAA
ISO 20000 MEXICO. (2013). Introducción ISO 20000 MEXICO. Recuperado de
http://www.iso20000.com.ar/intro_mex.html.
iso25000.com, 2013, Portal ISO 25000, Recuperado de http://iso25000.com/
iso25000.com, 2013, Portal ISO 25000, Recuperado de
http://iso25000.com/index.php/evaluacion-productos.
iso25000.com, (2013), Primeros productos certificados en calidad del producto
software, Recuperado de http://iso25000.com/index.php/noticias/36-primeros-
productos-certificados-calidad-software.
ISO 27000. (2013). Iso2700.es. Recuperado de http://www.iso27000.es/
ISO. (2013). ISO. Recuperado de http://www.iso.org/iso/home.htm
J. L. Roca (s.f) La confiabilidad. Consultado el: 09/11/2013.Disponible en:
http://ieee.eie.fceia.unr .edu.ar/PDF_SOFTWARE.pdf
Lamayzi Yassáa, S. (1999). Grupo Alarcos. Recuperado el 7 de Noviembre de
2013, de http://alarcos.inf-cr.uclm.es/per/fruiz/cur/mso/comple/ISO14764.pdf
Largo, A. F. (1 de Enero de 2011). Universidad de Alicante. Obtenido de
http://rua.ua.es/dspace/bitstream/10045/18817/1/gobierno_de_las_TI_para_univer
sidades_imprimible.pdf
Laura Carolina Arboleda Salazar. (25/01/2011). IEEE 830 SRS. Consultado el
9/11/2013. Disponible en: http://www.slideshare.net/LauC2457/ieee-830-srs
Leonidas Muñoz Sagarvinaga, L. F. (s.f.). Slideshare. Obtenido de Calidad del
producto software: http://www.slideshare.net/albert317/calidad-del-producto-
software
Marcelo Caponi, D. D. (s.f.). Evaluación de Productos. Obtenido de Facultad de
Ingenieria - Universidad de la República - Uruguay:
http://www.fing.edu.uy/inco/cursos/gestsoft/Presentaciones/Evaluacion%20de%20
Productos%20-%20G2/Evaluacion%20de%20Productos.pdf
Marín, B. C.-F. (17 de 04 de 2007). Calidad en Modelos Conceptuales: Un Análisis
Multidimensional de Modelos Cuantitativos basados en la ISO 9126. Revista de
132
Procesos y Métricas de las Tecnologías de la Información. Obtenido de
http://www.aemes.org/documentos/seminarios/Seminarios%20de%20AEMES/revis
taprocesosmetricas/2007/numero12/RPM_v4_04.08.pdf
Martínez, J. C., & Ramírez Andonegui, M. E. (s.f.). webnode. Recuperado el 7 de
Noviembre de 2013, de
https://www.google.com.mx/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0
CC8QFjAB&url=http%3A%2F%2Ffiles.matenimientodepc.webnode.es%2F200000
224-1d06c1e014%2FISO14764.pdf&ei=IO9-
Uv_QHJW3sASpkYGACg&usg=AFQjCNHb_O63W27UN0cKASwx2tXnw3trVw&ca
d=rja
Martínez Párraga, J. A. (Mayo de 1999). Grupo Alarcos. Recuperado el 7 de
Noviembre de 2013, de Universidad de Castilla La-Mancha: http://alarcos.inf-
cr.uclm.es/per/fruiz/cur/mso/comple/IEEE1219.pdf
Michael Mendoza Gómez. (26/02/2011). norma IEEE 830. Consultado el
9/11/2013. Disponible en: http://150754-adsi.blogspot.mx/2011/02/norma-ieee-
830.html
Morilla, J. J. (09 de 01 de 2008). ISO 9126 vs SQuaRE. Obtenido de
http://alarcos.inf-cr.uclm.es/doc/cmsi/trabajos/Joaquin%20Ruiz.pdf
Moore, J. (s.f.). ISO 12207 and Related Software Life-Cycle Standards. Obtenido
de www.acm.org: http://www.acm.org/tsc/lifecycle.html
Montoto, O. C. (15 de marzo de 2012). Usable & accesible. Obtenido de
Estándares formales de usabilidad y su aplicación práctica en una evaluación
heurística: http://olgacarreras.blogspot.mx/2012/03/estandares-formales-de-
usabilidad-y-su.html#cap322
NYCE. (s.f.). ISO/IEC 15504. Rrecuperado de
http://www.nyce.org.mx/index.php/proceso- verif/iso-iec-15504
NYCE. (2013). IEC/ISO 20000 – Servicios de TI. Recuperado de
http://www.nyce.org.mx/index.php/sistemas/iso-20000.
Normaiso15504. (s.f.). NORMA ISO 15504. 8 de noviembre de 2013, recuperado
de http://normaiso15504.blogspot.mx/
Oktaba, H (s.f.) Primeros pasos de moprosoft, consultado el 10/11/2013,disponible
en: http://sg.com.mx/content/view/390
Pérez, M. D.-A. (22 de 05 de 2002). Calidad Sistémica del Software Educativo.
Obtenido de http://lsm.dei.uc.pt/ribie/docfiles/txt200372919958paper-010.pdf
Pérez Yenny, (2012), COMPARACION DEL MODELO DE CALIDAD DE MCCALL,
NORMA ISO/IEC 9126 Y NORMA ISO/IEC 25000, Recuperado de
http://yennyperezcervantes.blogspot.mx/2012/05/comparacion-del-modelo-de-
calidad-de.html.
133
Ramos, C. A. (2010). Calidad total. Recuperado de
http://karlidad.wordpress.com/iso-15504/
Revista – AYS. (2007). ISO 2000: ¿Qué es?. Recuperado el día 07 de Noviembre
del 2013 de http://www.revista-ays.com/DocsNum07/Normas/Alvarez.pdf.
Revista – AYS. (2007). ITIL & ISO 20000. Recuperado el día 07 de Noviembre del
2013 de http://www.revista-
ays.com/DocsNum27/HoyHablamosDe/HoyHablamos27.pdf.
Rodríguez Moje Moisés, (2010), Calidad de procesos y productos de software,
Recuperado de http://alarcos.esi.uclm.es/per/fruiz/curs/santander/mrodriguez-
iso25000-update.pdf.
Sanz, M. L. (17 de Septiembre de 2010). Ciclo de vida del Software. Obtenido de
www.kybele.etsii.urjc.es: http://www.kybele.etsii.urjc.es/docencia/IS_LADE/2010-
2011/Material/%5BIS-LADE-2010-11%5DTema2.CicloVidaSW.pdf
Sin autor. Disponible en:
http://www.fdi.ucm.es/profesor/gmendez/docs/is0809/ieee830.pdf
Sin Autor (s.f).Gestión de la configuración software. Consultado el: 08/11/2013.
Disponible en: http://images.wikia.com/vyv/images/9/9b/IEEE-Std-828-
1998_ESP.pdf
Sin autor, (s.f.) Modelo de Procesos para la Industria del Software, consultado el
10/11/2013, disponible en: http://uvmnet.omargaona.com/archivos/0903-
incidencia/moprosoftcmm.pdf
Sin Autor (s.f).Guía de SCMP. Consultado el: 08/11/2013. Recuperado de:
https://www.google.com.mx/?gws_rd=cr&ei=6jyBUq6ZFbCOiAfVg4CoDQ#q=GU%
C3%8DA+de+SCMP+(Software+Configuration+Management+Plan)
Sin Autor. (s.f)Consultado el: 09/11/2013. Disponible
en:http://translate.google.com.mx/translate?hl=es-
419&sl=en&u=http://www.gobookee.org/ieee-1042-software-configuration-
management/&prev=/search%3Fq%3Ddownload%2BIEEE%2BStandard%2Bfor%
2BSoftware%2BConfiguration%2BManagement%2BPlans
Sin Autor (s.f).Consultado el: 08/11/2013. Disponible en: http://www.academia.edu
/1742459/ IEEE_828_Plan_de_ Gestion_de_la_configuracion_de_Software
Siselca IT Systems. (1 de Enero de 2013). Siselca. Obtenido de
http://www.sicelca.com/iso-38500
SGS. (2013). Sector Publico. Recuperado de http://www.sgs.mx/es-ES/Public-
Sector/Quality-Health-Safety-and-Environment/Risk-Assessment-and-
Management/Security-Management/ISO-20000-IT-Certification.aspx.
Sommerville, I. (2005). Ingeniería del software. Pearson Educación. España.
Universidad de León (2011). ISO 15504, 12207. Recuperado de
http://admoncalto.wordpress.com/g-iso-15504-12207/
134
Vaca, S. &. (13 de 08 de 2008). Métricas aplicadas a los modelos de calidad: caso
de uso en los SIG. Obtenido de
http://oa.upm.es/4371/1/INVE_MEM_2008_60090.pdf
Villa, M., Ruíz, M., & Ramos, I. (s.f, p.13). Modelos de Evaluación y Mejora de
Procesos: Análisis Comparativo. Recuperado de http://ftp.informatik.rwth-
aachen.de/Publications/CEUR-WS/Vol-120/paper4.pdf
www.iso27000.es, (2013). ISO 27000. (Documento PDF, www.iso27000.es).
Recuperado de http://repositorio.espe.edu.ec/handle/21000/6025
Wilson Santiago Paredes R. (2011) Diseño e implementación del proceso de
gestión de la configuración de software en la empresa de desarrollo Venture Venti.
Consultado el: 09/11/2013. Disponible en:
http://repositorio.espe.edu.ec/bitstream/21000/4719/1/T-ESPE-032840.pdf
www.iso27000.es, (2013). Sistema de Gestión de la Seguridad de la Información.
(Docuemento PDF, www.iso27000.es). Recuperado de
http://www.iso27000.es/download/doc_sgsi_all.pdf
Yorely Brigeth Ceballos Cardona, L. A. (11 de Marzo de 2013). ESTÁNDAR PAR
ALOS PROCESOS DE CICLO DE VIDA DELSOFTWARE DE LA
ORGANIZACION ISO. MANIZALES, MANIZALES.