Antología de normas e iso by Instituto Tecnologico de Colima

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

Í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 2

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 3

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

Gestión de Configuración del Software (SCM) ................................................................ 109 2.1.

Organización de SCM ...................................................................................... 109 4

2.2. 3.

Responsabilidades de SCM............................................................................. 109

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

Recursos de SCM ................................................................................................................ 115

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., CondoriFerná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

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

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

ISO/IEC 9126

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.

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

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

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

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

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., CondoriFernández, N., & Pastor O., 2007),

Tabla 3: Relación entre métricas de Li y Henry, (Marín, B., CondoriFernández, N., & Pastor O., 2007).

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

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.



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

ISO/IEC 12207

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.

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

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

Principales. de apoyo. 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 21

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.

Ilustración 6: Vista de los procesos Recuperado de(http://www.kybele.etsii.urjc.es/docencia/IS_LADE/2010-2011/Material/%5BIS-LADE-201011%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). 23

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.

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



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.

ISO/IEC 15504

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.

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

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.

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.

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). PARTES DE LA NORMA ISO/IEC 15504 1. Conceptos y Vocabulario

2. Realización de la Evaluación 3. Guía para la Realización de la Evaluación

4. Guía sobre el Uso para la Mejora del proceso y la Determinación de la Capacidad del Proceso

5. Un Ejemplo de Modelo de Evaluación de Procesos (en preparación)

CONTENIDO Proporciona una introducción general a los conceptos de la evaluación de los procesos y un glosario de términos relacionados. 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. Proporciona una guía para interpretar los requisitos a la hora de realizar una evaluación. 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. 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.

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.

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



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

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

En su favor

Más consensuado y

El de mayor prestigio

probado. En su contra

Procesos

Difícil en capacidad,

Difícil en entender, mayor

complejo de evaluar.

inversión, prescriptivo.

Delegado en ISO 12207,

Estructura propia.

por mayor aplicabilidad. Validación

‘Trials’ y esfuerzo empírico.

Encuesta satisfacción y casos de estudio.

Objetivo

Valoración de procesos y

Mejora de proceso,

guía para la mejora.

determinación capacidad contratista.

Representación

Contínua (por etapas a nivel

Contínua y por etapas.

de proceso). 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 Método para mejora de

CMMI

SPICE 4° parte.

IDEAL, mapa guíado.

Norma poco conocida por lo

Mucha más información y

tanto la documentación

gratuita.

procesos Documentación

escasa aún en inglés y de pago. Evaluación

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.

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

ISO/IEC 14764

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

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



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. 2. 3. 4. 5. 6. 7.

Identificación y Clasificación del Problema o de la Modificación. Análisis. Diseño Implementación. Pruebas del Sistema. Pruebas de Aceptación. 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, 41

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

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.

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



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

ISO/IEC 14598

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.

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

“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

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)

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

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.

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)

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 91261, 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. 54

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. 2. 3. 4.

Establecimiento de los Requerimientos Especificación de la Evaluación Diseño de la Evaluación Ejecución de la Evaluación 55

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

ISO 25000

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.

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.

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

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

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

 

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.

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



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

ISO/IEC 20000

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

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:

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 69

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

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

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

PHI IT S.A. DE C.V.

MAINBIT SA DE C.V

COMISIÓN FEDERAL DE ELECTRICIDAD –CENACE

SHARP CORPORATION MÉXICO, S.A. DE C.V.

Alcance 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. 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. SERVICIO DE ADQUISICIÓN DE DATOS EN TIEMPO REAL PARA LA OPERACIÓN DEL SISTEMA ELÉCTRICO NACIONAL SERVICIOS ADMINISTRADOS DE IMPRESIÓN Y SOPORTE TÉCNICO DE EQUIPOS MULTIFUNCIONALES, BRINDADO A TODOS LOS CLIENTES 72

DISTRIBUIDORA TECNO OFICE S.A DE C.V.

REDES Y SOPORTE EN MICROCOMPUTACIÓN, S.A.

OPERBES S.A. DE C.V.

TECNOLOGÍA EN SERVICE DESK, S.A. DE C.V.

EN TODA LA REPÚBLICA MEXICANA, A TRAVÉS DE MESAS DE SERVICIO SERVICIO DE MANTENIMIENTO CORRECTIVO DE MULTIFUNCIONALES SHARP A CLIENTES EN LA ZONA METROPOLITANA DE GUADAJALARA, JALISCO. SERVICIO DE MANTENIMIENTO CORRECTIVO SIN REFACCIONES DE SOFTWARE, HARDWARE, CABLEADO ESTRUCTURADO Y TELEFONÍA EN EL ÁREA METROPOLITANA DEL D.F. 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. 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). 73

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 74

conformidad, la eficacia y la eficiencia del individuo objetivos de control de gesti贸n de servicios de TI (ISO 20000, 2013)".

ISO/IEC 38500

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)

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.

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.

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

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

que han sido recientemente reconocidos con el sello de Excelencia EFQM +500. (Antonio Fernández Martínez y Faraón Llorens Largo, 2011)

ISO/IEC 27000

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



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

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



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

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.



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

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

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

      

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 92



 



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 93

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

NYSE NMX-1-059-/02 Moprosoft y Evalsoft

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.

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

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

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)

Ilustración 31: Categorías de la operación (uvmnet.omargaona.com, 2013, pag 26)

Niveles o etapas Descripción 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

Ilustración 32: Niveles por proceso de Moprosoft (uvmnet.omargaona.com, 2013, pag 8) En cada nivel hay actividades para realizar

100

Ilustraci贸n 33: Actividades de una fase (uvmnet.omargaona.com, 2013, pag 33)

101

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 102

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

103

IEEE 828

104

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.

105

IEEE 828 Definición: IEEE estándar para el software: Planes de Gestión de la Configuración IEEE Std 8281998 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

106

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.

107

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.

108

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.

109

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

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 111

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 112

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

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

114

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

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

116

IEEE 830

117

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.

118

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.

119

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.

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

120



En caso de que el SRS tenga diagramas o tablas informativas, hay que darles número o identificación.

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.

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.

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.

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.

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



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.

122

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

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

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

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.

Visión o descripción general del documento Describir lo que contienen las secciones restantes del documento y explicar cómo está organizado.

123

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

124



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.

Funciones del producto Sumario de las funciones principales

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.

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

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.

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 125

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.

Funciones Esta subsección (quizá la más larga del documento) deberá especificar todas aquellas acciones (funciones) que deberá llevar a cabo el software.

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.

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.

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.

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”: 126

   



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 127

      

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.

128

BIBLIOGRAFÍA 



 

ADMIN. (24/06/2011). Especificación de Requisitos IEEE830. Consultado el 9/11/2013. Disponible en: http://www.ingenierosistemas.com/especificacion-derequisitos-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-calidadsoftware 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/cuadrocomparativo-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%3Anuevaiso-270002013-cambios-a-tener-encuenta&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-15504calidad-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-lasTIC-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/

129



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/wpcontent/uploads/2011/03/Evaluaci%C3%B3n-de-la-calidad-del-software-educativobajo-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). 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/wpcontent/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/.

 

NORMA

ISO

9126.

Obtenido

International Organization for Standardization. (2006). ISO. Recuperado el 7 de Noviembre de 2013, de http://www.iso.org/iso/catalogue_detail.htm?csnumber=39064

130



ISO/IEC. (1 de febrero de 2000). Obtenido de ISO.org: http://webstore.iec.ch/ppreview/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-cobitiso20000mapping/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-primerosproductos-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-productosoftware



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 131

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=IO9Uv_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.infcr.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-ieee830.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-deusabilidad-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-decalidad-de.html. 132



Ramos, C. A. (2010). Calidad 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.revistaays.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/mrodrigueziso25000-update.pdf.



total.

Recuperado



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/20102011/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-8281998_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/0903incidencia/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=es419&sl=en&u=http://www.gobookee.org/ieee-1042-software-configurationmanagement/&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/PublicSector/Quality-Health-Safety-and-Environment/Risk-Assessment-andManagement/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 http://admoncalto.wordpress.com/g-iso-15504-12207/

133



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

 



134