COMPILACIÓN BIBLIOGRÁFICA: ISO/IEC 20000 ...“N BIBLIOGRÁFICA: ISO/IEC 20000 (ESTÁNDAR...

COMPILACIÓN BIBLIOGRÁFICA: ISO/IEC 20000 (ESTÁNDAR BRITÁNICO 15000), NORMAS IEEE SOBRE SOFTWARE E

INGENIERÍA DE SOFTWARE; NORMAS ISO/IEC 15404: SPICE, ISO/IEC 15408:2005, ISO/IEC 19770:2006, ISO/IEC 12207

JORGE ENRIQUE URREA SERNA CODIGO: 1700613397

AUDITORIA INFORMATICA

UNIVERSIDAD DE CALDAS FACULTAD DE INGENIERÍAS

PROGRAMA DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN MANIZALES, OCTUBRE DE 2010

Tabla de contenido Introducción General .......................................................................................................................... 4

Marco Teórico ..................................................................................................................................... 5

ISO/IEC 20000 .................................................................................................................................. 8

Historia y Evolución ..................................................................................................................... 8

Descripción General .................................................................................................................... 9

Desarrollo de la Temática .......................................................................................................... 10

Comparación con COBIT ............................................................................................................ 15

NORMAS IEEE SOBRE SOFTWARE E INGENIERÍA DE SOFTWARE .................................................. 16

Historia y Evolución ................................................................................................................... 16

Descripción General .................................................................................................................. 18



ISO/IEC 15404:SPICE ...................................................................................................................... 25

Historia y evolución ................................................................................................................... 25


Comparativa con COBIT............................................................................................................. 28

ISO/IEC 15408:2005 ...................................................................................................................... 30


Descripción general ................................................................................................................... 31

Desarrollo de la temática .......................................................................................................... 32

ISO/IEC 19770:2006 ...................................................................................................................... 38





ISO/IEC 12207 ................................................................................................................................ 48





Resumen ........................................................................................................................................ 54

Conclusiones y Observaciones ...................................................................................................... 58

Bibliografía .................................................................................................................................... 59

Introducción General

Anteriormente los procesos de las empresas no tenían ningún soporte en TI, pero

actualmente cada vez más empresas necesitan apoyarse en mejorases practicas

tecnológicas para poder expandir su negocio y utilizar las mejores tecnologías existentes

para sus clientes finales.

Actualmente las TI trascienden las fronteras de la compañía y es un punto clave para el

mejoramiento de la imagen de las empresas y mantener las buenas relaciones con las

demás empresas del entorno. Lo anterior es especialmente cierto para compañías

industriales, financiera, de tratamiento de aguas, entre otras ya que no solo basta con

tener buenos servicios de TI sino demostrar una buena infraestructura tecnológica y

sostenible para ofrecer a sus clientes.

Marco Teórico

La Organización Internacional para la Estandarización o ISO, nacida tras la Segunda

Guerra Mundial (23 de febrero de 1947), es el organismo encargado de promover el

desarrollo de normas internacionales de fabricación, comercio y comunicación para todas

las ramas industriales a excepción de la eléctrica y la electrónica. Su función principal es la

de buscar la estandarización de normas de productos y seguridad para las empresas u

organizaciones a nivel internacional.

La Comisión Electrotécnica Internacional (CEI o IEC) es una organización

de normalización en los campos eléctrico, electrónico y tecnologías relacionadas.

Numerosas normas se desarrollan conjuntamente con la ISO (normas ISO/IEC).

La CEI, fundada en 1904 durante el Congreso Eléctrico Internacional de San Luis (EEUU), y

cuyo primer presidente fue Lord Kelvin, tenía su sede en Londres hasta que en 1948 se

trasladó a Ginebra. Integrada por los organismos nacionales de normalización, en las áreas

indicadas, de los países miembros, en 2003 pertenecían a la CEI más de 60 países.

ISO/IEC 20000 (International Organization for Standardization) e IEC (International

Electrotechnical Commission), es la primera norma de gestión de servicios de TI que

funciona en un entorno totalmente integrado para proveer servicios de TI de calidad del

negocio para los clientes.

La norma proporciona la base para probar que una organización de TI ha implantado

buenas prácticas para la gestión del servicio y que las está usando de forma regular y

consistente. La norma ISO/IEC 20000 está estructurada en dos documentos:

• ISO/IEC 20000-1: este documento incluye el requisito de las “normas obligatorias”

que el proveedor de TI debe cumplir para asegurar la calidad del servicio que

responda a las necesidades de la empresa y los clientes.

• ISO/IEC 20000-2: este documento pretende ayudar a la organización a establecer

los procesos de forma que cumplan con los objetivos de la primera parte.

ISO/IEC 20000 es una norma internacional que proporciona un marco de referencia para

todas las empresas que presten servicios de TI, dando un estándar y una terminología

común para todos los implicados proveedores, suministradores y clientes.

Esta norma solo se otorga a organizaciones que gestionen los servicios de TI y la norma

certifica solamente el buen funcionamiento de las operaciones de la empresa y no entra

en una competencia de certificación de productos o de servicios de consultoría y va

dirigida a organizaciones que busquen mejorar sus servicios de TI, negocios que necesiten

un enfoque consistente en la cadena de suministros, organizaciones de TI que precisen

demostrar su capacidad y proveedores de servicios que requieran medir sus servicios de

TI.

El organismo IEEE posee varios números de estándar para el desarrollo de software, cada

uno con un ámbito diferente. Aunque cabe aclarar que para acceder al contenido de cada

uno de estos documentos se debe poseer una membrecía de la IEEE de tipo Standars y por

esta restricción no se hablara con mucha profundidad sobre estos estándares a excepción

de algunos que si se encuentran de forma libre.

Estas normas son aplicadas en todo ámbito ingenieril pero en el desarrollo del documento

se enfocara en las normativas y estándares impuestos para el desarrollo de sistemas de

información en ingeniería de software y para los ingenieros de software en especial.

El proyecto SPICE (Software Process Improvement and Capability dEtermination) es una

actividad del WG 10 del Subcomité 7 del ISO/IEC JTC1, un estándar internacional para

procesos de desarrollo de software que provea de un marco de trabajo uniforme para

gestión e ingeniería del software.

SPICE es una norma que trata los procesos de ingeniería, gestión, relación cliente-

proveedor, de la organización y del soporte.

Fue creado por la alta competencia del mercado de desarrollo de software, a la difícil

tarea de identificar los riesgos, cumplir con el calendario, controlar los costos y mejorar la

eficiencia y calidad. Este engloba un modelo de referencia para los procesos y sus

potencialidades sobre la base de la experiencia de compañías grandes, medianas y

pequeñas.

El estándar Cobit (Control Objectives for Information and related Technology) ofrece un

conjunto de “mejores prácticas” para la gestión de los Sistemas de Información de las

organizaciones.

El objetivo principal de Cobit consiste en proporcionar una guía a alto nivel sobre puntos

en los que establecer controles internos con tal de:

· Asegurar el buen gobierno, protegiendo los intereses de los stakeholders (clientes,

accionistas, empleados, etc.)

· Garantizar el cumplimiento normativo del sector al que pertenezca la organización

· Mejorar la eficacia de los procesos y actividades de la organización

· Garantizar la confidencialidad, integridad y disponibilidad de la información

El estándar define el término control como: “Políticas, procedimientos, prácticas y

estructuras organizacionales diseñadas para proveer aseguramiento razonable de que se

lograrán los objetivos del negocio y se prevendrán, detectarán y corregirán los eventos no

deseables”

ISO/IEC 20000

Historia y Evolución

La serie ISO/IEC 20000 - Service Management normalizada y publicada por las

organizaciones ISO (International Organization for Standardization) e IEC (International

Electrotechnical Commission) el 14 de diciembre de 2005, es el estándar reconocido

internacionalmente en gestión de servicios de TI (Tecnologías de la Información). La serie

20000 proviene de la adopción de la serie BS 15000 desarrollada por la entidad de

normalización británica, la British Standards Institution (BSI).

Descripción General

La gestión de una entrega efectiva de los servicios de TI es crucial para las empresas. Hay

una percepción de que estos servicios no están alineados con las necesidades y requisitos

del negocio. Esto es especialmente importante tanto si se proporciona servicios

internamente a clientes como si se está subcontratado proveedores. Una manera de

demostrar que los servicios de TI están cumpliendo con las necesidades del negocio es

implantar un Sistema de Gestión de Servicios de TI (SGSTI) basado en los requisitos de la

norma ISO/IEC 20000. La certificación en esta norma internacional permite demostrar de

manera independiente que los servicios ofrecidos cumplen con las mejores prácticas.

ISO/IEC 20000 está basada y reemplaza a la BS 15000, la norma reconocida

internacionalmente como una British Standard (BS), y que está disponible en dos partes:

una especificación auditable y un código de buenas prácticas.

La ISO/IEC 20000 es totalmente compatible con la ITIL (IT Infrastructure Library), o guía de

mejores prácticas para el proceso de GSTI. La diferencia es que el ITIL no es medible y

puede ser implantado de muchas maneras, mientras que en la ISO/IEC 20000, las

organizaciones deben ser auditadas y medidas frente a un conjunto establecido de

requisitos.

La ISO/IEC 20000 es aplicable a cualquier organización, pequeña o grande, en cualquier

sector o parte del mundo donde confían en los servicios de TI. La norma es

particularmente aplicable para proveedores de servicios internos de TI, tales como

departamentos de Información Tecnológica, proveedores externos de TI o incluso

organizaciones subcontratadas. La norma está impactando positivamente en algunos de

los sectores que necesitan TI tales como subcontratación de negocios,

Telecomunicaciones, Finanzas y el Sector Público.

Desarrollo de la Temática

La norma proporciona la base para probar que una organización de TI ha implantado

buenas prácticas para la gestión del servicio y que las está usando de forma regular y

consistente. La norma ISO/IEC 20000 está estructurada en dos documentos:

• ISO/IEC 20000-1: este documento incluye el requisito de las “normas obligatorias”

que el proveedor de TI debe cumplir para asegurar la calidad del servicio que

responda a las necesidades de la empresa y los clientes.

• ISO/IEC 20000-2: este documento pretende ayudar a la organización a establecer

los procesos de forma que cumplan con los objetivos de la primera parte.

ISO/IEC 20000 es una norma internacional que proporciona un marco de referencia para

todas las empresas que presten servicios de TI, dando un estándar y una terminología

común para todos los implicados proveedores, suministradores y clientes.

Contenido de ISO/IEC 20000

Esta norma se basa en la integración de los procesos de TI y en la buena gestión de sus

servicios. Estas especificaciones son un consenso en la industria para la correcta gestión

de los servicios de TI. La norma ISO/IEC 20000 cubre las siguientes secciones:

A. El Sistema de Gestión de Servicios de TI (SGSTI)

Habla de las políticas para realizar la correcta implantación de servicios de TI, SGSTI cubre

los aspectos de responsabilidad de la dirección, requisitos de la documentación,

competencia, concienciación y formación.

B. Planificación e Implantación de la Gestión del Servicio

En la actualidad se hace necesaria que la calidad del servicio de TI mejore continuamente,

por este motivo la norma ISO/IEC 20000 utiliza el modelo de mejora de la calidad de W.

Edward Deming para poder validar este objetivo. Esta parte de la norma cubre los

apartados de planificación de la gestión del servicio, implementar la gestión y provisión

del servicio, monitorizar, medir y verificar y mantener y mejorar continuamente.

C. Planificación e Implementación de Servicios, Nuevos o Modificados

Esta sección tiene como único objetivo hacer que la creación, modificación e incluso la

eliminación de un nuevo servicio sea con los costes, calidad y plazos acordados, para ello

se gestiona todo el ciclo de los servicios todo esto empieza con el cliente y finaliza con la

entrega operativa del servicio o su eliminación, este proceso es inexistente en ITIL tanto

en su versión 2 como en la 3.

D. Proceso de Provisión de Servicio

En esta sección se tratan los requisitos necesarios para cubrir la provisión de los servicios

que el cliente necesita, y todo aquello que es necesario en TI para poder prestar estos

servicios, para ello ISO/IEC 20000 los divide en una serie de procesos con objetivos

específicos:

• Gestión de nivel de servicio

• Generación de informes del servicio

• Gestión de la continuidad y disponibilidad del servicio

• Elaboración de presupuesto y contabilidad de los servicios de TI

• Gestión de la capacidad

• Gestión de seguridad de la información

E. Procesos de Relaciones

Se centran en dos relaciones fundamentalmente, la primera con el negocio y sus clientes y

la otra con los suministradores o proveedores con los cuales sería imposible la evolución y

mejoramiento del servicio. También es importante decir que esta parte de la norma

ISO/IEC 20000 influencio a ITIL v3 en la parte de suministros pero con la diferencia que

esta norma creo su proceso específico para su correcta gestión.

F. Procesos de Resolución

Los procesos de resolución son gestión del incidente y gestión del problema, estos

procesos tienen un alto grado de relación aunque tienen objetivos diferenciados. Gestión

del incidente se encarga de la recuperación de los servicios a los usuarios tan pronto como

sea posible, y gestión del problema tiene la misión de identificar y eliminar las causas de

los incidentes para que no vuelvan a producirse.

G. Procesos de Control

Este proceso permite la gestión y control del cambio así mismo como su configuración y

obtención de información precisa para el manejo de todos los procesos, esta etapa cuenta

con dos subprocesos gestión de la configuración y gestión del cambio.

H. Procesos de Entrega

El objetivo de este proceso es entregar, distribuir y realizar el seguimiento de uno o más

cambios en la entrega en el entorno de producción real, para garantizar este objetivo el

proceso tiene una visión global de todos los servicios y así asegurar la entrega al cliente.

Organización

El estándar se organiza en cinco partes, de las cuales cuatro están ya publicadas y una en

proceso de publicación:

Parte 1: ISO/IEC 20000-1:2005 - Especificación. Preparada por BSI como BS 15000-

1

Parte 2: ISO/IEC 20000-2:2005 - Código de Prácticas. Preparada por BSI como BS

15000-2

Parte 3: ISO/IEC TR 20000-3:2009 - Guía en la definición del alcance y la

aplicabilidad (informe técnico)

Parte 4: ISO/IEC DTR 20000-4:? - Modelo de referencia de procesos (informe

técnico)

Parte 5: ISO/IEC TR 20000-5:2010 - Ejemplo de implementación (informe técnico)

Además, las partes 1 y 2 se encuentran en proceso de revisión y previsiblemente en 2011

se publicarán actualizando su título de la siguiente forma:

Parte 1: ISO/IEC 20000-1:2011 - Requisitos de los sistemas de gestión de servicios

Parte 2: ISO/IEC 20000-2:2011 - Guía de implementación de los sistemas de

gestión de servicios

La primera parte (Especificación) define los requerimientos (217) necesarios para realizar

una entrega de servicios de TI alineados con las necesidades del negocio, con calidad y

valor añadido para los clientes, asegurando una optimización de los costes y garantizando

la seguridad de la entrega en todo momento. El cumplimiento de esta parte, garantiza

además, que se está realizando un ciclo de mejora continuo en la gestión de servicios de

TI. La especificación supone un completo sistema de gestión (organizado según ISO 9001)

basado en procesos de gestión de servicio, políticas, objetivos y controles. El marco de

procesos diseñado se organiza con base en los siguientes bloques:

Grupo de procesos de Provisión del Servicio.

Grupo de procesos de Control.

Grupo de procesos de Entrega.

Grupo de procesos de Resolución.

Grupo de procesos de Relaciones.

La segunda parte (Código de Prácticas) representa el conjunto de buenas prácticas

adoptadas y aceptadas por la industria en materia de Gestión de Servicio de TI. Está

basada en el estándar de facto ITIL (Biblioteca de Infraestructura de TI) y sirve como guía y

soporte en el establecimiento de acciones de mejora en el servicio o preparación de

auditorías contra el estándar ISO/IEC 20000-1:2005.

Rasgos y beneficios

La ISO/IEC 2000 está dividida en las siguientes secciones que definen los requisitos que

debe cumplir una organización, la cual proporciona servicios a sus clientes con un nivel

aceptable de calidad:

- Requisitos para la gestión de un sistema. - Implantación y planificación de Gestión de

Servicios. - Planificación e implantación de servicios nuevos o modificados. - Procesos del

servicio de entrega. - Procesos relacionales. - Procesos de control. - Procesos de emisión.

Demuestra que se tienen procedimientos y controles adecuados in situ para proporcionar

un servicio de calidad de TI coherente y a un coste efectivo.

Los suministradores de servicios de TI se han vuelto cada vez más sensibles y responsables

con los servicios que prestan más que de la tecnología que puedan proporcionar.

Los proveedores externos de servicios pueden usar la certificación como un elemento

diferenciador y acceder a nuevos clientes, ya que esto cada vez más se convierte en una

exigencia contractual.

Permite seleccionar, gestionar y proporcionar un servicio externo más efectivo.

Ofrece oportunidades para mejorar la eficiencia, fiabilidad y consistencia de sus servicios

de TI que impactan positivamente tanto en los costes como en el servicio.

Certificación

La aparición de la serie ISO/IEC 20000, ha supuesto el primer sistema de gestión en

servicio de TI certificable bajo norma reconocida a nivel mundial. Hasta ahora, las

organizaciones podían optar por aplicar el conjunto de mejoras prácticas dictadas

por ITIL (completadas por otros estándares como CMMI o COBIT) o certificar su gestión

contra el estándar local británico BS 15000. La parte 1 de la serie, ISO/IEC 20000-1:2005

representa el estándar certificable. En febrero de 2006, AENOR (organización delegada en

España de ISO/IEC) inició el mecanismo de adopción y conversión de la norma ISO/IEC

20000 a norma UNE. El viernes 23 de junio de 2006, la organización itSMF hace entrega

a AENOR de la versión traducida de la norma. En el BOE del 25 de julio de 2007 ambas

partes se ratificaron como normas españolas con las siguientes referencias:

UNE-ISO/IEC 20000-1:2007 Tecnología de la información. Gestión del servicio.

Parte 1: Especificaciones (ISO/IEC 20000-1:2005).

UNE-ISO/IEC 20000-2:2007 Tecnología de la información. Gestión del servicio.

Parte 2: Código de buenas prácticas (ISO 20000-2:2005).

Estas normas pueden adquirirse a través del portal web de AENOR. Cualquier entidad

puede solicitar la certificación respecto a esas normas.

En México, la adquisición de las Normas Mexicanas (NMX) correspondientes a la serie

ISO/IEC 20000, así como la certificación bajo dicha norma, puede obtenerse a través del

Organismo de Certificación acreditado: NYCE, A.C. (Normalización y Certificación

Electrónica, A.C.)

Referencias

ISO/IEC 20000-1, Information technology - Service management - Part 1:

Specification.

ISO/IEC 20000-2, Information technology - Service management - Part 2: Code of

practice.

ISO/IEC TR 20000-3, Information technology - Service management - Part 3:

Guidance on scope definition and applicability of ISO/IEC 20000-1

ISO/IEC TR 20000-5, Information technology - Service management - Part 5:

Exemplar implementation plan for ISO/IEC 20000-1

ISO/IEC 27001:2005 Information technology - Security techniques - Information

security management systems - Requirements.

ISO 9001:2008, Quality management systems - Requirements.

Comparación con COBIT

El control de los procesos tecnológicos se está convirtiendo en una parte esencial de las

relaciones de negocio prácticamente en toda la industria y son esenciales para

implementar las mejores prácticas ITIL y, de esta forma, obtener la certificación ISO/IEC

20000.

ISO/IEC 20000 como se ha dicho antes su objetivo principal es la mejora continua de los

servicios de TI además las organizaciones pueden utilizar COBIT para materializar las

medidas de los avances en el logro de nuevos niveles de mejora a medida que la gestión

de los servicios gana en madurez.

COBIT es más un mecanismo de medición y control, mientras ISO/IEC 20000 busca la

gestión de los servicios y su integración con una mejora continua, apoyándose

mutuamente en las prácticas de ITIL y otros sistemas de mejora de la calidad de TI.

NORMAS IEEE SOBRE SOFTWARE E INGENIERÍA DE SOFTWARE


El último cuarto del siglo diecinueve fue marcado por un tremendo crecimiento en la

tecnología eléctrica. La Pearl Street Station de Thomas Edison estaba brindando el poder

para abastecer la iluminación incandescente, había numerosas empresas fabricando

equipo eléctrico. Este gran crecimiento en la actividad eléctrica incitó al Franklin Institute

para patrocinar una Exhibición Eléctrica Internacional en Filadelfia en 1884. Esta

exhibición fue el catalizador que produjo la formación del Instituto Americano de

Ingenieros Eléctricos (American Institute of Electrical Engineers, AIEE), el antepasado del

actual Instituto de Ingenieros Electrónicos y Electricistas (IEEE).

Una de las actividades importantes del AIEE era el desarrollo de normas para la profesión

de la ingeniería y la industria eléctrica. Los esfuerzos más tempranos del Instituto se

dirigieron hacia regularizar las unidades, definiciones, y nomenclatura que relacionan a la

ciencia eléctrica básica. Como fue explicado por Arturo E. Kennelly, presidente de AIEE de

1898 a 1900, el propósito de este comité era el "definir y declarar en un lenguaje simple,

la naturaleza, características, conducta, valuación, y métodos para probar maquinarias y

aparatos eléctricos, particularmente con una vista en preparar las normas de prueba de

aceptación para la industria eléctrica."

A inicios del siglo 20, el AIEE había tomado su lugar junto a las sociedades de la ingeniería

más viejas. Como el alcance de ingeniería eléctrica se había extendido, los ingenieros se

volvieron más especializados y se comprometieron a buscar e intercambiar la información

con otros de las mismas especialidades. Así, en 1903, el primer Comité Técnico, el Comité

de Transmisión de Alto Voltaje, se formó. Un grupo de ingenieros eléctricos

especializados, sin embargo, no se sentía totalmente en casa en los establecimientos y

temas en los que el AIEE estaba fuertemente orientado.

Como con el AIEE, uno de las preocupaciones principales de la IRE era la estandarización.

El crecimiento de la IRE reflejó el crecimiento de la industria de la radio en general. Como

pasó en el AIEE, los miembros de la IRE que compartió una especialidad técnica común

buscaron maneras de actuar recíprocamente más directamente. Durante los primeros

treinta años de su existencia, la IRE era una de las más pequeñas sociedades de ingeniería.

Pero los miembros de IRE eran practicantes de la tecnología del futuro. Los años después

de que el Segunda Guerra Mundial trajo los cambios drásticos al campo de ingeniería

eléctrica y un crecimiento continuo en los miembros de esta sociedad.

La fusión era cada vez más lógica. Ninguna sociedad representó la amplitud total de la

ingeniería eléctrica de manera adecuada. Hubo duplicación de personal, publicaciones, y

actividades. Las dificultades se superaron primero en los campus de las universidades; en

1950, las directivas de ambas sociedades autorizaron la creación de Ramas Estudiantiles

Unidas. Representantes de las dos sociedades se encontraron y se pusieron en orden para

la cita que iba a tratar acerca de la unión de un Comité ad hoc que trataría

específicamente de la fusión. El 87 por ciento de los miembros de la votación de cada

sociedad aprobaron la fusión. Donald Fink, un compañero del AIEE y la IRE, fue escogido

como el Gerente General del nuevo Instituto de Ingenieros Eléctricos y Electrónicos. El 1

de enero de 1963, el IEEE nació.

En 1973, el IEEE tomó un paso fuera de las tradiciones de sus predecesores. Con la

adopción de una nueva constitución, el IEEE dejó su papel de "sociedad sabia", que sólo

tenía relación con el avance y diseminación de conocimiento, y tomó el papel de una

"sociedad profesional" interesado tanto en lo técnico como en lo no técnico de sus

miembros. El directorio de Actividades en los Estados Unidos, apoyados por una

valoración anual pagada por los residentes americanos, fue creado para vigilar los

funcionamientos no técnicos del IEEE dentro de los Estados Unidos.

Hoy, con más de un cuarto de millón de miembros, el IEEE es la sociedad profesional más

grande del mundo, y sus actividades se extienden más allá de las visiones iniciales que sus

antepasados pudieron prever. Permanece, sin embargo, como hace un siglo, siendo el

primer portavoz para el campo tecnológico más significante y excitante de su tiempo.

Descripción General

En la actualidad las normas IEEE para la ingeniería del software son amplias y se

encuentran en un grado de madures que les permiten servir como eje de calidad para los

proyectos que se realicen en este campo, a continuación solo se nombraran algunas y más

adelante se describirán las más relevantes y su importancias para la ingeniería actual,

dichas normas son:

• 610 - IEEE Standard Glossary of Software Engineering Terminology

• 1002 - IEEE Standard Taxonomy for Software Engineering Standards

• 1058.1: IEEE Plan para la Gestión de Proyectos Software

• 1348 - IEEE Recommended Practice for the Adoption of Computer-Aided Software

Engineering (CASE) Tools

• 12207 - ISO/IEC/IEEE Standard for Systems and Software Engineering – Software

Life Cycle Processes

• 14764 - International Standard - ISO/IEC 14764 IEEE Std 14764-2006 Software

Engineering -Software Life Cycle Processes - Maintenance

• 15288 - ISO/IEC/IEEE Systems and Software Engineering - System Life Cycle

Processes

• 15939 - IEEE Standard adoption of ISO/IEC 15939:2007 systems and software

engineering measurement process

• 16085 - Systems and Software Engineering - Life Cycle Processes - Risk

Management

• 16326 - Systems and software engineering - Life cycle processes - Project

management

• 90003 - IEEE Guide--Adoption of ISO/IEC 90003:2004 Software Engineering--

Guidelines for the Application of ISO 9001:2000 to Computer Software

• 1471 - ISO/IEC Standard for Systems and Software Engineering - Recommended

Practice for Architectural Description of Software-Intensive Systems

• 1633 - IEEE Recommended Practice on Software Reliability

• 42010 - ISO/IEC Standard for Systems and Software Engineering - Recommended

Practice for Architectural Description of Software-Intensive Systems

• 14471 - IEEE Draft Guide Adoption of ISO/IEC TR14471 Information technology -

Software engineering - Guidelines for the adoption of CASE tools

• 15289 - Draft Standard X Software and systems engineering -- Content of life-cycle

information products (documentation)

• 23026 - IEEE Standard for Software Engineering - Recommended Practice for the

Internet - Web Site Engineering, Web Site Management, and Web Site Life Cycle

• 24748 - ISO/IEC Draft IEEE Guide Systems and software engineering-Guide for life

cycle processes

• 24765 - Draft International Standard -- Systems and Software Engineering --

Vocabulary

• 26512 - IEEE Draft Standard Systems and software engineering - Requirements for

acquirers and suppliers of user documentation

• 26513 - IEEE Draft Standard Adoption of ISO/IEC 26513:2009 -- Systems and

Software Engineering -- Requirements for Testers and Reviewers of User

Documentation

• 26514 - IEEE Draft Standard Adoption of ISO/IEC 26514:2008 - Systems and

Software Engineering - Requirements for Designers and Developers of User

Documentation


610 - IEEE Standard Glossary of Software Engineering Terminology

Glosario de Terminología de Ingeniería de Software Estándar IEEE, que identifica los

términos que se utilizan actualmente en el campo de la ingeniería de software.

Definiciones estándar para los términos establecidos.

El campo de la informática sigue ampliando los términos y significados que se están

utilizando. El estándar IEEE 610 se llevó a cabo para documentar este vocabulario. Su

propósito es identificar los términos que se utilizan actualmente en el campo de la

computación y para establecer definiciones estándar para estos términos. El diccionario

está destinado a servir como referencia útil para aquellos en el campo de la computación

y para los que entran en contacto con los ordenadores a través de su trabajo o en su vida

cotidiana. Este diccionario se desarrollando para varias aéreas que comprenda la

ingeniería del software entre ellas la seguridad informática, las comunicaciones, desarrollo

gráficos, inteligencia artificial entre otros.

Todos los términos se han introducido según los criterios anteriores y se han dejado

términos cuyo significado sea más entendible en el inglés estándar. Las demás normas se

han desarrollado con base a este conocimiento ya que si se presentan confusiones o

equivocaciones se podrán resolver mediante la consulta a esta norma. Este glosario es una

actualización y expansión de la IEEE Std 729-1983 y del anterior glosario de la ANSI cuyos

términos fueron aumentados de 500 a 1300.

1002 - IEEE Standard Taxonomy for Software Engineering Standards

Taxonomía De Las Normas Estándar De Ingeniería Del Software, las aplicaciones no están

restringidas a la ingeniería del software, el tamaño, la complejidad, la criticidad, o entorno

de hardware. Esta taxonomía se aplica a las normas (de las disciplinas relacionadas con la

gestión de la ingeniería, ingeniería de sistemas, ingeniería de hardware, informática y

ciencias de la información) con el que un ingeniero de software estaría familiarizado. Esta

taxonomía es una aplicación independiente. La norma explica los diferentes tipos de

pautas de ingeniería de software, sus relaciones funcionales y externa, y el papel de las

distintas funciones que participan en el ciclo de vida del software.

1058.1: IEEE Plan para la Gestión de Proyectos de Software

Este estándar especifica el formato y contenidos de los planes para la gestión de

proyectos de software. No especifica las técnicas exactas que pueden ser usadas en el

desarrollo de los planes de proyectos, ni ofrece ejemplos de los planes de gestión de

proyectos. Cada organización que usa este estándar debería desarrollar un conjunto de

prácticas y procedimientos para proporcionar una guía detallada para la preparación y

actualización de los planes de gestión de los proyectos software basada en este estándar.

No todos los proyectos de software están afectados con el desarrollo de código fuente

para el desarrollo de un nuevo producto software. Algunos proyectos software consisten

en el estudio de viabilidad y definición de los requisitos del producto software.

Este estándar Contiene tres secciones. La Sección 1 define el alcance de este estándar y

proporciona referencias a otros estándares IEEE que deberían ser seguidos cuando se

aplique este estándar. La Sección 2 proporciona la definición de los términos que son

usados a lo largo de este estándar. La Sección 3 contiene una visión general y una

especificación detallada del estándar, incluyendo los componentes requeridos que deben

ser incluidos, y componentes adicionales que pueden ser incluidos en el plan del proyecto

basado en este estándar. En la mayoría de los casos, los planes de proyecto basados en

este estándar serán desarrollados por la iteración repetida y refinamiento de varios

elementos del plan. Este estándar está destinado a aquellos gestores de proyectos

software y a otro personal que prepare o actualice planes de proyectos y estén adheridos

a esos planes.

12207 - ISO/IEC/IEEE Standard for Systems and Software Engineering – Software Life

Cycle Processes

ISO/IEC/IEEE estándar de Sistemas e Ingeniería de Software – Ciclo de Vida de los Procesos

de Software, esta norma establece un marco común para los procesos del ciclo de vida del

software, con una terminología bien definida, que puede ser referenciado por la industria

del software. Se aplica a la adquisición de sistemas y productos de software y servicios,

empezando por los requerimientos, desarrollo, implementación, mantenimiento y

eliminación de productos de software, ya sea de forma interna o externa a la

organización. Esta revisión integra la norma ISO/IEC 12207:1995, con sus dos enmiendas y

se coordinó con la revisión paralela de la norma ISO/IEC 15288:2002 (procesos del ciclo de

vida del sistema) para alinear la estructura, términos, y los correspondientes procesos de

organización y de proyectos. Esta norma se puede utilizar independiente o conjuntamente

con la norma ISO/IEC 15288, y proporciona un modelo de referencia que apoya el proceso

de evaluación, de conformidad con la norma ISO/IEC 15504-2 (evaluación de procesos). En

un anexo proporciona soporte para los usuarios IEEE y describe las relaciones de esta

norma internacional para los estándares IEEE.

14764 — Standard for Software Engineering — Software Life Cycle Processes —

Maintenance

Esta Norma Internacional describe en mayor detalle la gestión del proceso de

mantenimiento descrito en la norma ISO/IEC 12207, incluidas las enmiendas, también

establece las definiciones de los diversos tipos de mantenimiento. Proporciona

orientación que se aplica a la planificación, ejecución y control, revisión y evaluación, y el

cierre de los procesos de mantenimiento. El ámbito de aplicación de esta norma

internacional incluye el mantenimiento de múltiples productos de software con los

mismos recursos de mantenimiento. Esta norma tiene por objeto proporcionar

orientación para la planificación y el mantenimiento de productos o servicios de software,

ya sea de forma interna o externa a la organización.

15939 - IEEE Standard adoption of ISO/IEC 15939:2007 systems and software

engineering measurement process

Estándar IEEE para la Adopción de la Norma ISO/IES 15939:2007 del Sistema de Ingeniería

del Software para la Medición de Procesos, el proceso se describe a través de un modelo

que define las actividades del proceso de medición que se requieren para especificar la

información adecuada, como las medidas y los resultados de los análisis deben aplicarse, y

cómo determinar si los resultados del análisis son válidos. El proceso de medición es

flexible, modificable, y adaptable a las necesidades de diferentes usuarios. Esta Norma

Internacional identifica un proceso que apoya la definición de un conjunto adecuado de

medidas que aborden las necesidades específicas de información. Iguala las actividades y

tareas que son necesarias para identificar, definir, seleccionar, aplicar y mejorar la

medición dentro de un proyecto global o la estructura de medición de la organización.

También proporciona definiciones de los términos de medición de uso común.

16326 - Systems and software engineering - Life cycle processes - Project management

Sistemas e Ingeniería del Software – Ciclo de Vida de Procesos – Gestión de proyectos,

ISO/IEC/IEEE 16326:2009 proporciona normativo especificaciones del contenido de los

planes de gestión de proyectos que abarcan los proyectos de software. También

proporciona una discusión detallada y asesoramiento sobre la aplicación de un conjunto

de procesos de los proyectos que son comunes al software y el ciclo de vida de los

sistemas regulados por la norma ISO/IEC 12207:2008 (IEEE Std 12207-2008) e ISO/IEC

15288:2008 (IEEE Std. 152882008), respectivamente. La discusión y asesoramiento

destinados a la ayuda en la preparación del contenido normativo de los planes de gestión

de proyectos. La norma ISO/IEC/IEEE 16326:2009 es el resultado de la armonización de la

norma ISO/IEC TR 16326:1999 y la IEEE Std 1058-1998 previamente explicada.

1633 - IEEE Recommended Practice on Software Reliability

Practicas Recomendadas en la Fiabilidad del Software, Los métodos para evaluar y

predecir la fiabilidad del software, basado en un enfoque del ciclo de vida de confiabilidad

del software, se establecen en estas prácticas. Proporciona la información necesaria para

la aplicación de la fiabilidad del software, de medición a un proyecto, establece las bases

para la creación de métodos que sean compatibles, y establece el principio básico para la

recolección de los datos necesarios para evaluar y predecir la fiabilidad del software.

14471 - IEEE Draft Guide Adoption of ISO/IEC TR14471 Information technology -Software

engineering - Guidelines for the adoption of CASE tools

Guía de Adopción para la norma ISO/IEC TR14471 de Tecnologías de la Información –

Ingeniería del Software – Directrices para la Adopción de Herramientas CASE, desde la

aprobación de herramientas CASE es un tema de las tecnologías de transición, el presente

informe técnico se refiere a la adopción de prácticas adecuadas para una amplia gama de

organizaciones de la informática. Este informe técnico ni dicta ni defensores de las normas

especiales de desarrollo, los procesos de software, métodos de diseño, metodologías,

técnicas, lenguajes de programación, o paradigmas de ciclo de vida.

26513 - IEEE Draft Standard Adoption of ISO/IEC 26513:2009 -- Systems and Software

Engineering -- Requirements for Testers and Reviewers of User Documentation

Adopción de la norma ISO/IEC 26513:2009 Sistemas e Ingeniería del Software –

Requerimientos para Probadores y Revisión de la Documentación del Usuario, esta norma

establece los requisitos para el examen y revisión de la documentación del usuario, como

parte de los procesos del ciclo de vida. Se define el proceso de documentación desde el

punto de vista del probador de documentación y revisor. Se especifica el proceso para su

uso en las pruebas y el examen de la documentación del usuario, y proporciona los

requisitos mínimos para estas actividades. Es pertinente a las funciones implicadas en la

evaluación y desarrollo de software y la documentación de usuario, incluidos los

directores de proyecto, expertos en usabilidad y desarrolladores de la información,

además de los examinadores y evaluadores. Se aplica a ambos la documentación impresa

y la documentación en pantalla, y es aplicable a la documentación de usuario para los

sistemas que incluyen hardware.

26514 - IEEE Draft Standard Adoption of ISO/IEC 26514:2008 - Systems and Software

Engineering - Requirements for Designers and Developers of User Documentation

Se define el proceso de documentación desde el punto de vista del desarrollador de

documentación. También cubre la documentación del producto. Se especifica la

estructura, contenido y formato de la documentación del usuario, y también proporciona

orientación informativa para el estilo de la documentación del usuario. Es independiente

de las herramientas de software que pueden ser utilizados para producir la

documentación, y se aplica tanto a la documentación impresa y la documentación en

pantalla.


Dicho estándar se enmarca en un contexto complementario para los indicadores de

adquirir e implementar del COBIT (AI2-AI6-AI7), ya que ayudan a lograr rápidamente un

modelo de madurez, apoyándose en las normas IEEE para lograr la adquisición de 15

soluciones y aplicaciones de software los cuales ayudaran a la organización a llevar

proceso más automatizados para un mejor funcionamiento de la organización. Para el

ítem AI2 (Adquirir y mantener software aplicativo) permite definir un cronograma para el

proceso de adquisición de software (Cabe aclarar que el IEEE 108.1 se encuentra enfocado

al desarrollo) o identificar las prioridades del aplicativo que se posee, entre otros.

El ítem AI6 (Administrar cambios) permite a través del IEEE 1058.1 implementar nuevas TI

enfocadas al desarrollo de software en la cual por medio de una planificación organizada

permite implementar software exitoso.

El ítem AI7 (Instalar y acreditar soluciones de cambio) es un claro ejemplo del buen

acompañamiento que da el IEEE 1058.1, ya que es más fácil acreditar una solución en TI la

cual se halla desarrollado a través de un proceso estricto y una buena planificación.

Este estándar puede ser un claro ejemplo del acompañamiento que debe recibir el COBIT

para realizar procesos exitosos.

ISO/IEC 15404:SPICE

Historia y evolución

En 1991, dado el número creciente de Métodos de evaluación de procesos disponible, y el

uso creciente de estas técnicas en áreas comerciales sensibles, la Organización de

Estandarización internacional ISO aprueba la realización de un estudio al respecto de la

necesidad de crear un estándar internacional para la evaluación de procesos.

Se crea entonces el proyecto SPICE, que es una importante iniciativa internacional que

hasta hace poco existía en apoyo de la Norma Internacional ISO / IEC 15504 para

Evaluación de Procesos (software). Por tanto, el proyecto SPICE fue creado bajo los

auspicios del Comité Internacional de estándares de Ingeniería de Software y Sistemas a

través de su Grupo de Trabajo sobre Evaluación de proceso (WG10).

En 1992, el informe del grupo de estudio dice que: “...la comunidad internacional debería

poner recursos para desarrollar un estándar para la evaluación de procesos software,

incorporando lo mejor de los métodos de evaluación de procesos existentes.”

ISO decide que sea un desarrollo un estándar para la evaluación de procesos, pero por

pasos:

1. Publicación inicial como Informe Técnico ‘Technical Report’ (“borrador de

estándar”) para que después de su uso real pase a

2. Revisión y publicación como estándar internacional IS ISO/IEC 15504 –

Tecnologías de la Información – Evaluación de Procesos (‘ISO/IEC 15504 –

Information Technology – Process Assessment’). Las siglas SPICE significan:

Software Process Improvement and Capability dEtermination, es decir

Determinación de la capacidad y mejora de los procesos de SW.

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

El primer objetivo del proyecto se logró en junio de 1995, con la entrega del borrador de

trabajo de la norma para la evaluación de procesos de software al WG10 para su votación

entre la comunidad de estandarización internacional. El Borrador de Trabajo se

denominaba comúnmente como el conjunto de documentos SPICE (o SPICE Versión 1).

Este primer borrador se basó en otros modelos existentes en aquél momento.

Los ensayos de estos primeros documentos SPICE han sido el foco del proyecto SPICE

durante el período 1994 a 1998. Fue entonces, en 1998 cuando se publicó la primera

familia de estándares ISO TR 15504. Desde entonces ya se comenzó a trabajar en la

versión de Internacional Standard de la norma, y ahora (desde 2006) está completamente

publicado excepto de partes nuevas que aun se están produciendo.

En marzo de 2003, el proyecto SPICE se ha cerrado oficialmente. La Red SPICE se

estableció posteriormente con el mandato de seguir coordinando las actividades dentro

de la comunidad SPICE. La Red de SPICE está formalmente organizada por el ‘The Spice

User Group’ (www.spiceusergroup.org).

Las actividades promocionales están en curso y se realizan a través de la Conferencia

Internacional SPICE Anual y la publicación de artículos y libros. Con el fin de apoyar la

excelencia y la coherencia de la formación de los evaluadores, el proyecto SPICE también

desarrolló y lanzó un Plan de Estudios de formación de los evaluadores SPICE que es

utilizado actualmente por el Esquema de Registro Internacional de Evaluadores (IntRSA) –

www.intrsa.org. En el capítulo de ‘Roles’ se desarrollan más estos detalles de cualificación

y responsabilidades de diferentes roles que se necesitan en los procesos de evaluación y/o

mejora.


La norma ISO/IEC 15504:SPICE es una norma abierta e internacional 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 del proceso de desarrollo y mantenimiento de

software.

Fue creada por la alta competencia del mercado de desarrollo de software, a la difícil




pequeñas.

El principal propósito de esta normativa es proporcionar una base común para los

diferentes modelos y métodos de evaluación de procesos de software, asegurando que los

resultados de la evaluación sean iguales en un contexto común.

El modelo describe los procesos que una organización puede ejecutar, adquirir, suplir,

desarrollar, operar, evolucionar, brindar soporte de software y todas las prácticas

genéricas que caracterizan las potencialidades de estos procesos.

La arquitectura se basa en:

Prácticas base: Son las actividades esenciales de un proceso específico, agrupado por

categorías de procedimientos y procesos de acuerdo al tipo de actividad que direccionan.

Prácticas genéricas: Aplicables a cualquier proceso, que representa las actividades

necesarias para administrar el “proceso” y mejorar su potencialidad.

Comparativa con COBIT

En cuanto a la norma ISO/IEC 15404, COBIT la utiliza para ofrecer mecanismos para la

medición de las capacidades de los procesos con objeto de conseguir una mejora

continua. Para ello, proporciona indicaciones para valorar la madurez en función de la

misma clasificación utilizada por dicha norma.

Nivel 0 – Proceso incompleto: El proceso no existe o no cumple con los objetivos

Nivel 1 – Proceso ejecutado

Nivel 2 – Proceso gestionado: el proceso no solo se encuentra en funcionamiento,

sino que es planificado, monitorizado y ajustado.

Nivel 3 – Proceso definido: el proceso, los recursos, los roles y responsabilidades se

encuentran documentados y formalizado.

Nivel 4 – Proceso predecible: se han definido técnicas de medición de resultados y

controles.

Nivel 5 – Proceso optimizado: todos los cambios son verificados para determinar el

impacto, se han definido mecanismos para la mejora continua.

Dominio: Adquisición e Implementación

Con el objeto de garantizar que las adquisiciones de aplicaciones comerciales, el

desarrollo de herramientas a medida y su posterior mantenimiento se encuentren

alineados con las necesidades del negocio, el estándar COBIT define los siguientes 7

procesos:

AI1 – Identificación de soluciones: análisis funcional y técnico, análisis del riesgo,

estudio de la viabilidad.

AI2 – Adquisición y mantenimiento de aplicaciones: Diseño, controles sobre la

seguridad, desarrollo, configuración, verificación de la calidad, mantenimiento.

AI3 – Adquisición y mantenimiento de la infraestructura tecnológica: Plan de

infraestructuras, controles de protección y disponibilidad, mantenimiento.

AI4 – Facilidad de uso: Formación a gerencia, usuarios, operadores y personal de

soporte.

AI5 – Obtención de recursos tecnológicos: control y asignación los recursos

disponibles, gestión de contratos con proveedores, procedimientos de selección de

proveedores.

AI6 – Gestión de cambios: Procedimientos de solicitud/autorización de cambios,

verificación del impacto y priorización, cambios de emergencia, seguimiento de los

cambios, actualización de documentos.

AI7 – Instalación y acreditación de soluciones y cambios: Formación, pruebas

técnicas y de usuario, conversiones de datos, test de aceptación por el cliente,

traspaso a producción.

ISO/IEC 15408:2005


Common Criteria (o ISO-IEC 15408) es una estándar internacional de certificación de productos TI,

resultado de una intensa y larga negociación entre 14 países entre los que figura España como

firmante del acuerdo a través del Ministerio de Administraciones Públicas.

Este estándar proporciona unos criterios de evaluación unificados para la seguridad de los

productos TI y recoge todos los esfuerzos realizados desde los años 80 en este campo (TCSEC en

Estados Unidos, ITSEC en la Comunidad Europea, CTCPEC en Canadá, Federal Criteria como un

primer intento de acercamiento entre Estados Unidos y Europa, etc.).

Por los años 90 surgió la necesidad de conocer qué requisitos de seguridad satisfacía un

determinado software, hardware o firmware. Mediante la combinación de los criterios aplicados

en Inglaterra, Estados Unidos y Canadá, se constituyó y adoptó por la International Organization

for Standardization los Criterios Comunes de Evaluación de Seguridad para Tecnologías de la

Información.

Gracias a Common Criteria, los usuarios pueden determinar si un producto proporciona el nivel de

seguridad que necesita siguiendo unos criterios estándar y no simples percepciones personales.

Common Criteria exige a los fabricantes de los productos certificados publicar una documentación

exhaustiva sobre la seguridad de sus productos y que los usuarios puedan tener plena confianza

en las evaluaciones de Common Criteria ya que son realizadas por laboratorios independientes. De

hecho, la evaluación de Common Criteria es cada vez más utilizada como condición necesaria para

participar en concursos públicos.

En definitiva, la existencia de un estándar de este tipo proporciona un lenguaje común entre los

fabricantes, los usuarios y las administraciones que todos pueden entender de la misma manera.

Los fabricantes utilizarán este lenguaje para definir las características de sus productos, los

usuarios tendrán una manera única de especificar sus requerimientos, etc.

Descripción general

La norma ISO/IEC 15408 define un criterio estándar a usar como base para la evaluación

de las propiedades y características de seguridad de determinado producto o sistema IT.

Ello permite la equiparación entre los resultados de diferentes e independientes

evaluaciones, al proporcionar un marco común con el que determinar los niveles de

seguridad y confianza que implementa un determinado producto en base al conjunto de

requisitos de seguridad y garantía que satisface respecto a esta norma obteniendo de esa

forma una certificación oficial de nivel de seguridad que satisface.

Por tanto, la norma ISO/IEC 15408 proporciona una guía muy útil a diferentes perfiles

relacionados con las tecnologías de la seguridad

Por un lado, desarrolladores de productos o sistemas de tecnologías de la

información, que pueden ajustar sus diseños.

Por otro lado, consumidores que pueden conocer el nivel de confianza y seguridad

que los productos de tecnologías de la información y sistemas le ofrecen.

En último lugar, los evaluadores de seguridad, que juzgan y certifican en qué

medida se ajusta una especificación de un producto o sistema IT a los requisitos de

seguridad deseados.

Desarrollo de la temática

Muchos sistemas y productos de Tecnologías de la Información están diseñados para

satisfacer y realizar tareas específicas y puede ocurrir, normalmente por razones

económicas, que determinados aspectos de seguridad se encuentren delegados en

funciones de seguridad de otros productos o sistemas de propósito general sobre los

cuales ellos trabajan como pueden ser sistemas operativos, componentes software de

propósito específico o plataformas hardware. Por tanto, las medidas de salvaguarda

dependen del correcto diseño y funcionamiento de los servicios de seguridad que

implementan otros sistemas o servicios de TI más genéricos. Sería deseable por tanto, que

éstos estuvieran sometidos a evaluación para conocer en qué medida nos ofrecen

garantías y podemos depositar confianza en ellos.

También muchos clientes y consumidores de sistemas y servicios de TI carecen de los

conocimientos necesarios o recursos suficientes para juzgar por ellos mismos si la

confianza que depositan en estos sistemas o servicios de TI es adecuada y desearían no

obtener esa certeza solamente en base a la información que proporcionan los fabricantes

o las especificaciones de los desarrolladores.

Organización

Los Criterios Comunes (por no llamarla ISO 15408) establecen unos criterios de evaluación

basados en un análisis riguroso del servicio o sistema de TI a evaluar y los requisitos que

este satisface. Para ello, establece una clasificación jerárquica de los requisitos de

seguridad. Se determinan diferentes tipos de agrupaciones de los requisitos siendo sus

principales tipos los que vemos a continuación:

Clase: Conjunto de familias comparten un mismo objetivo de seguridad.

Familia: un grupo de componentes que comparten objetivos de seguridad pero

con diferente énfasis o rigor.

Componente: un pequeño grupo de requisitos muy específicos y detallados. Es el

menor elemento seleccionable para incluir en los documentos de perfiles de

protección (PP) y especificación de objetivos de seguridad (ST).

La norma ISO/IEC 15408 se presenta como un conjunto de tres partes diferentes pero

relacionadas. A continuación, describimos cada una de ellas:

Parte 1. Introducción y modelo general.

Define los principios y conceptos generales de la evaluación de la seguridad en tecnologías

de la información y presenta el modelo general de evaluación. También establece cómo se

pueden realizar especificaciones formales de sistemas o productos IT atendiendo a los

aspectos de seguridad de la información y su tratamiento.

- Protection Profile (PP): un conjunto de requisitos funcionales y de garantías

independientes de implementación dirigidos a identificar un conjunto determinado de

objetivos de seguridad en un determinado dominio. Especifica de forma general que se

desea y necesita respecto a la seguridad de un determinado dominio de seguridad.

- Security Target (ST): un conjunto de requisitos funcionales y de garantías usado como

especificaciones de seguridad de un producto o sistema concreto. Especifica que

requisitos de seguridad proporciona o satisface un producto o sistema, ya basados en su

implementación. Ejemplos podrían ser ST para Oracle v.7, ST para CheckPoint Firewall-1

etc.

Parte 2. Requisitos Funcionales de Seguridad

Este tipo de requisitos definen un comportamiento deseado en materia de seguridad de

un determinado producto o sistema IT y se agrupa en clases. Contiene las siguientes

clases:

FAU- Auditoria

FCO- Comunicaciones

FCS- Soporte criptográfico

FDP- Protección de datos de usuario

FIA- Identificación y autenticación de usuario

FMT- Gestión de la seguridad

FPR- Privacidad

FPT- Protección de las funciones de seguridad del objetivo a evaluar

FRU- Utilización de recursos

FTA- Acceso al objetivo de evaluación

FTP- Canales seguros

Parte 3. Requisitos de Garantías de Seguridad

Este tipo de requisitos establecen los niveles de confianza que ofrecen funciones de

seguridad del producto o sistema. Trata de evaluar qué garantías proporciona el producto

o sistema en base a los requisitos que se satisfacen a lo largo del ciclo de vida del

producto o sistema. Contiene las siguientes clases:

ACM- Gestión de la configuración

ADO- Operación y entrega

ADV- Desarrollo

AGD- Documentación y guías

ALC- Ciclo de vida

ATE- Prueba

AVA- Evaluación de vulnerabilidades

APE- Evaluación de perfiles de protección (PP)

ASE- Evaluación de objetivos de seguridad (ST)

AMA- Mantenimiento de garantías

Certificación ISO 15408

En este sentido, los Common Criteria o ISO/IEC 15408, proporcionan también unos niveles

de garantía (EAL) como resultado final de la evaluación. Estos consisten en agrupaciones

de requisitos vistos anteriormente en un paquete, de forma que obtener cierto nivel de

garantía equivale a satisfacer por parte del objeto de evaluación ciertos paquetes de

requisitos. Todo proceso de evaluación comienza con la definición del objeto a evaluar,

que definimos a continuación:

Target of Security (TOE): Documento que realiza una descripción del producto o

sistema que se va a evaluar, determinando los recursos y dispositivos que utiliza, la

documentación que proporciona y el entorno en el que trabaja.

El principal objetivo de la norma ISO/IEC 15408, como hemos visto, es establecer de forma

estándar un criterio de evaluación de la seguridad de los productos y sistemas IT. Ya

hemos visto como la medición se realiza en base a un conjunto de requisitos y la

demostración de que éstos son satisfechos. Esta norma nos proporciona dos tipos

diferentes de evaluación.

Evaluación de Perfiles de Protección (PP): El objetivo de tal evaluación es

demostrar que un PP es completo, consistente y técnicamente sólido. Podrá ser

utilizado como base para establecer requisitos destinados a definir un objetivo de

seguridad (ST). Herramienta útil ya que permite definir especificaciones de

seguridad independientes de implementación, que pueden ser utilizadas como

base de especificaciones para productos o sistemas.

Evaluación de Objetivos de Evaluación (TOE)

Utilizando un objetivo de seguridad (ST) previamente evaluado como base, el

objetivo de la evaluación es demostrar que todos los requisitos establecidos en el

ST se encuentran implementados en el producto o sistema IT.

Respecto a los niveles de seguridad que se pueden lograr, voy a tratar resumidamente de

describir cada uno de ellos a continuación.

EAL 1. Functionally tested

Proporciona un nivel básico de seguridad realizado a través del análisis de las funciones de

seguridad usando especificaciones informales de aspectos funcionales, de interfaz y las

guías y documentación del producto o sistema IT para entender el comportamiento de

seguridad.

Es aplicable cuando se requiere confianza en la correcta operación pero las amenazas de

seguridad no se contemplan como un peligro serio. Este tipo de evaluación proporciona

evidencias de que las funciones de seguridad del TOE se encuentran implementadas de

forma consistente con su documentación y proporcionan una protección adecuada contra

las amenazas identificadas.

EAL 2. Structurally tested

Exige, además de los requisitos del nivel anterior, haber realizado una descripción

informal del diseño detallado, haber realizado pruebas en el desarrollo en base a las

especificaciones funcionales, una confirmación independiente de esas pruebas, un análisis

de la fuerza de las funciones de seguridad implementadas y evidencias de que el

desarrollo ha verificado la respuesta del producto o sistema IT a las vulnerabilidades más

comunes. Requiere de la cooperación del equipo de desarrollo que entregue información

sobre el diseño y resultados de pruebas. Este tipo de evaluación es adecuado en

circunstancias en donde desarrolladores o usuarios requieren cierto nivel de garantías de

seguridad cuando no tienen acceso a toda la documentación generada en la fase de

desarrollo.

EAL 3. Methodically tested and checked

Este nivel establece unos requisitos que obligan en la fase de diseño a un desarrollo

metódico determinando. Este nivel añade a los requisitos del nivel anterior, el uso de

controles de seguridad en los procesos de desarrollo que garantizan que el producto no ha

sido manipulado durante su desarrollo. Por tanto, se realiza un análisis de las funciones de

seguridad, en base a las especificaciones funcional de alto nivel, la documentación, guías

del producto y los test obtenidos en la fase de prueba.

EAL 4. Methodically designed, tested and reviewed

Requiere, además de los requisitos del nivel anterior, un análisis de vulnerabilidad

independiente que demuestre resistencia a intrusos con bajo potencial de ataque y una

especificación de bajo nivel del diseño de la implementación.

EAL 5. Semiformally designed and tested

Representa un cambio significativo respecto al nivel anterior puesto que requiere de

descripciones semiformales del diseño y la arquitectura además de completa

documentación de la implementación. Además se realiza un completo análisis de

vulnerabilidad que pruebe la resistencia frente atacantes de potencial medio y mejora los

mecanismos de control para garantizar y demostrar que el producto no es manipulado

con respecto a las especificaciones durante el desarrollo.

EAL 6. Semiformally verified design and tested

Añade respecto a los requisitos del nivel anterior, un detallado análisis de las funciones de

seguridad, una representación estructurada de su implementación y semiformal

demostración de la correspondencia entre las especificaciones de alto y bajo nivel con la

implementación. Además debe demostrarse con un análisis de vulnerabilidades

independiente, que en el desarrollo se ha probado la robustez de las funciones de

seguridad frente a atacantes de alto potencial de daño.

EAL 7. Formally verified design and tested

Es el nivel de certificación más alto. Debe probarse formalmente las fases de desarrollo y

prueba. Además se exige una evaluación independiente de la confirmación de los

resultados obtenidos, de las pruebas para detectar vulnerabilidades durante la fase de

desarrollo así como sobre la robustez de las funciones de evaluación. Además, deberá

realizarse un análisis independiente de vulnerabilidades para demostrar resistencia frente

a un atacante de alto potencial.

Beneficios

La aparición de la norma ISO/IEC 15408 proporciona un criterio internacional que permite

evaluar bajo criterios rigurosos y estrictos que protecciones en materia de seguridad nos

proporciona un determinado servicio o sistema de TI. Los acuerdos firmados por

diferentes países, permiten el reconocimiento mutuo de certificaciones realizadas en los

diferentes organismos de certificación reconocidos internacionalmente. Ello facilita que

los principales fabricantes de software estén evaluando sus productos para proporcionar

“valor añadido” en la confianza y seguridad que en ellos se puede depositar.

Estos niveles de certificación serán mínimos exigibles para la selección y adquisición de

software. Por otro lado, la aparición de diferentes perfiles de protección para diversos

entornos de seguridad proporcionará conjuntos de especificaciones técnicas que se

incorporarán a futuros desarrollos, proporcionando requisitos de seguridad establecidos

ya en las fases de diseño de servicios o sistemas de TI. Todo ello contribuirá, seguramente,

al incremento de la calidad y seguridad de los diferentes servicios o sistemas de TI, y por

tanto, de la confianza que podrá depositarse en ellos.

ISO/IEC 19770:2006


Esta normatividad salió luego del efecto Y2K, en la cual se descubrió que el software no

era capaz de manejar las fechas, otra motivación fue que los constantes cambio en el

licenciamiento del software y el aumento de TI lo que se traduce en un interés común por

un estándar para este entorno. La norma ISO/IEC 19700-1 fue el resultado del esfuerzo de

ISO-IEC, ITIL, Microsoft Snow Software y FAST, Tanto ITIL como FAST fueron un marco de

referencia para realizar este estándar.

La ISO/IEC 19770 es una norma internacional sobre SAM (Gestión de activos de software),

la cual es una herramienta de evaluación (SAE) el 18 de junio de 2007, la cual salió al

mercado con el nombre de ISO/IEC19770-1 SAM.


Esta norma consta de dos partes. La primera explica los procesos de Gestión de Activos de

Software y la segunda, la metodología y procedimiento de identificación de productos,

orientada a facilitar la labor de inventario. La ISO 19770 es un caso especial de norma,

puesto que combina la descripción de procesos y las versiones de software. Una

implementación correcta de esta norma en una organización no obliga a hacerlo de ambas

partes, ya que son independientes.

ISO 19770 establece los procesos de gestión de los activos de software en una

organización y su finalidad es facilitar la auditoría de sus procesos de Gestión de Activos

de Software, homogeneizándolos de manera que satisfagan los criterios de gobierno

corporativo y garanticen su extensión a toda la organización de TI

Como tal, la norma ISO 19770-1 para la gestión de activos de software tiene que ver con el

ciclo de vida de las aplicaciones en uso en su red, desde la compra hasta su eliminación. La

norma establece seis áreas clave de las mejores prácticas destinadas a ayudar a todos los

tipos de las organizaciones a ahorrar dinero, reducir los riesgos de cumplimiento e

incrementar la eficiencia operativa de gestión de software.


ISO / IEC 19770 es un estándar internacional, iniciado en 2006, que fue desarrollado para

ayudar a las organizaciones a poner en práctica procesos y procedimientos para la efectiva

gestión de activos de software (SAM).

La norma está diseñada para ayudar a gestionar el riesgo, conocer los requisitos de

gobernanza de TI dentro de las empresas y mejorar en general la relación coste-eficacia y

la disponibilidad de software de negocios en toda la empresa.

Hay dos partes a la norma:

ISO / IEC 19770-1 se centra en la importancia de la gestión eficaz de los activos de

software (la parte 1 se publicó el 9 de mayo de 2006)

ISO / IEC 19770-2 define los requisitos de datos para apoyar la norma ISO 19770-1

(Parte 2 no ha sido puesto en libertad).

La norma ISO / IEC 19770-1 se trata sólo de auditoría y el cumplimiento de software.

Aunque estos son componentes importantes, el estándar para la SAM ahora abarca todos

los aspectos de un negocio y la forma en que los procesos de TI, el software de gestión y

los procedimientos administrados por la alta dirección son efectivos.

En total, hay 27 procesos distintos que componen la norma ISO 19770-1 los cuales forman

el marco para la gestión eficaz de los actuales activos de software. Aunque algunos de

estos elementos se refieren únicamente a los procedimientos que sólo pueden ser

manejados manualmente, hay una serie de requisitos que pueden ser atendidos con

mucho menos esfuerzo si se utiliza una herramienta adecuada de descubrimiento de

activos.

La capacidad de identificar con precisión el software instalado y en uso en PCs y servidores

a través de la organización es vital para cumplir los requisitos de la norma para el manejo

de software en curso.

Aplicación de la norma ISO 19970

Siguiendo el estándar definido en la norma ISO 19770 los principios de Gestión de Activos

de Software se pueden aplicar a prácticamente cualquier aspecto del entorno de IT en una

organización, pero sobre todo a aquellos que tienen que ver con la gestión de licencias de

software e inventario de activos. Entre sus ventajas destacan su capacidad para gestionar

de manera coherente:

Los documentos de prueba de licencia

Los distintos modelos de licencia

Las distintas plataformas de software

Los medios de instalación y copias de distribución de los productos.

Las versiones y ediciones

Todo el software instalado

Listas detalladas de versiones, parches y actualizaciones

Las licencias

Los contratos

Medios de distribución, tanto físicos como electrónicos

La ISO 19970 además prescribe la elaboración de un inventario donde se incluyen los

registros de licencias, que se componen de un identificador de software, versión, el

nombre y ubicación del usuario y la situación presente del activo gestionado.

Esta norma recomienda implementar políticas y procedimientos concretos para mantener

los registros de inventario (con recomendaciones que van desde la fase de captura de

información a las copias de seguridad de la base de datos o la protección de la

información frente a accesos no autorizados). Son unos procesos bien pensados para

llevar a cabo una implementación correcta de Gestión de Activos de Software, lo que debe

repercutir en distintos beneficios para la organización.

Esta norma se orienta a la gestión del ciclo de vida completo de las aplicaciones que se

utilizan dentro de la red corporativa, desde el momento de su adquisición hasta su

retirada. Establece seis áreas de gestión y en todas ellas aplica el criterio de

homogeneidad, mejora continua y transparencia, así como los objetivos comunes de

reducción de costes y riesgos, y mejora de la eficiencia operativa.

Con la ISO 19770, además, todas las partes involucradas en el proceso de gestión de

activos de software -de manera directa e indirecta, ya sea el usuario final, el fabricante de

software, el distribuidor de licencias o las agencias de defensa de los derechos de

propiedad intelectual- disponen de un marco de trabajo y un lenguaje comunes que

permite colaborar y resolver las posibles disputas e ineficiencias en menos tiempo y de

forma más sencilla.

Aplicación práctica de la norma

Hay en total 27 procesos dentro del marco de trabajo descrito en la ISO 19770-1 para la

gestión de activos de software. De ellos, algunos pueden automatizarse y otros son de

naturaleza manual. La siguiente tabla es un resumen de las actividades y procesos que

cubre y su equivalencia con el marco de trabajo definido dentro de los procesos de

Gestión de Activos de Software:

Norma ISO / IEC 19770 comentarios Marco de procesos SAM

Microsoft

Procesos de Planificación e Implementación SAM

Planificación

Planificación previa. Temas

organizativos, asunción de

responsabilidades,

calendario, etc.

Desarrollo parcial: roles y

responsabilidades, temas de

ROI

Implementación Plan de implementación

Desarrollo en 4 etapas:

inventario, comprobación de

licencias, políticas y

mantenimiento

Monitorización Seguimiento de cambios y

verificación de conformidad

Plan de mantenimiento.

Procedimientos de gestión

del ciclo de vida del SW

Mejora continua Mantenimiento y evolución

de los procedimientos no se desarrolla este asunto

Procesos de inventario para SAM

Identificación de activos de

software

Determina qué tiene que

inventariarse y un sistema

de catalogación

No desarrolla este asunto

Gestión de inventario de

Activos de Software Inventario de SW inventario de SW

Control de los activos de

software

gestión de cambios en el

inventario Políticas

Procesos de verificación y conformidad

Verificación del registro de

activos de software

Revisiones planificadas y

ocasionales para comprobar

la coincidencia entre el

inventario y la realidad

Mantenimiento posterior

Conformidad con las

licencias de software

comprueba si toda la

propiedad intelectual de

software tiene su

correspondiente licencia en

orden

Inventario de Licencias y

Análisis de inventario

Conformidad con la

seguridad de los activos de

software

Protección de accesos y

control de utilización de los

activos de SW

Recomendaciones de

protección de los activos

(soportes, documentos, etc)

Verificación de conformidad

con SAM

Cumplimiento de la

normativa ISO/IEC 19770 No desarrolla este asunto

Procesos de gestión de operaciones e interfaces para SAM

Gestión de contratos y

relaciones para SAM

Gestión financiera para SAM Gestión de la financiación de

la propia actividad SAM

No desarrolla este asunto.

Solamente trata el aspecto

ROI

Gestión a nivel de servicios Definición de los niveles de No desarrolla este asunto

para SAM servicio para la actividad

SAM en la empresa

Gestión de seguridad para

SAM

Definición de las políticas de

seguridad para la

información de SAM en la

empresa


Interfaces de los procesos del ciclo de vida para SAM

Proceso de gestión de

cambios

Políticas de gestión de los

cambios en los

procedimientos SAM

No se desarrolla este asunto

Proceso de adquisición Compras de SW Políticas de adquisición de

SW

Proceso de desarrollo de

software Desarrollo de SW propio No desarrolla este asunto

Proceso de gestión de salida

al mercado del software Comercialización de SW No desarrolla este asunto

Proceso de despliegue del

software

Instalación y uso de SW y

gestión de licencias Políticas de instalación de SW


incidencias

Acciones a adoptar en casos

de incidencias con el SW o

las licencias



problemas

Procedimientos de mejora

continua del plan SAM No desarrolla este asunto

Proceso de retirada Retirada del SW Políticas de retirada de SW

Como sucede con todos los estándares, la ISO 19770 supone un punto de partida para la

creación e implementación de buenas prácticas y procedimientos, identificando el marco

de trabajo, etapas de desarrollo, los resultados a obtener y medios para su verificación y

seguimiento por entidades independientes.

El siguiente nivel de detalle -el "cómo se hace"- no forma parte del articulado de la norma,

ya que depende de las características concretas de cada organización. En las

implementaciones prácticas de la norma ISO 19770 se deben considerar aspectos como la

cultura interna de la organización, el entorno tecnológico que se quiere gestionar, los

procesos que ya existen y las posibilidades de automatización.

Requerimientos ISO/IEC 19770:2006

Entorno de control

Gobierno corporativo

Funciones y responsabilidades

Políticas, procesos y procedimientos

Competencia para la SAM

Planificación e implementación

Planificación e implementación

Monitoreo y revisión

Mejora continua y SAM

Inventario

Identificación de activos de software

Gestión de inventario de activos de software

Control de activos de software

Verificación y cumplimiento

Verificación de registro de activos de software

Cumplimiento de las licencias de software

Cumplimientos de seguridad de los activos de software

Verificación de conformidad de SAM

Administración de operaciones

Relación y gestión de contactos

Gestión financiera

Gestión de nivel de servicios

Gestión de nivel de seguridad

Ciclo de vida

Gestión del cambio y procesos de adquisición

Gestión de lanzamiento y desarrollo de software

Gestión de incidentes y despliegues de software

Gestión de problemas

Procesos de retiro


La normatividad ISO / IEC 19770 planea un marco muy específico de TI para las

organizaciones, es por esto que podría implementarse en compañía del COBIT, pero solo

para servir de guía en el área de la planeación y organización del COBIT. Es un buen marco

de referencia que puede utilizar el COBIT para llegar a las metas planteadas en el modelo

de madurez.

Este estándar es muy adecuado para implementar en los siguientes procesos:

PO1 - Definir el plan estratégico de TI.

PO2 - Definir la arquitectura de la información.

PO4 - Definir los procesos, organización y relaciones TI.

PO8 – Administrar la calidad.

PO10 - Administrar proyectos.

En cada uno de los literales descritos el ISO/IEC 19770 se enmarca en alguno de los

aspectos que manejan en dicho proceso

ISO/IEC 12207


ISO / IEC 12207 fue publicada el 1 de agosto de 1995 y fue la primera norma internacional

para proporcionar un conjunto completo de procesos de ciclo de vida, actividades y tareas

para el software que es parte de un sistema mayor, solo productos de software y

servicios. Esta norma internacional fue seguida en noviembre de 2002 por la ISO / IEC

15288 que abarco los procesos del sistema de ciclo de vida. La ubicuidad del software

significa que el software y sus procesos de diseño no deben considerarse por separado de

esos sistemas, pero pueden considerarlo como parte integrante del sistema y los procesos

de diseño del sistema.

La norma ISO / IEC 12207 en sus enmiendas de 2002 y 2004 agregó a la norma

internacional los propósitos de procesos y los resultados y también estableció un Modelo

de Referencia de Procesos de acuerdo con los requisitos de la norma ISO / IEC 15504-2.

La revisión y de la modificación de la norma ISO / IEC 12207, es un primer paso en la

estrategia de armonización SC7 para lograr un conjunto totalmente integrado de sistemas

y procesos de software de ciclo de vida y la orientación para su aplicación.

Esta revisión integra a la norma ISO / IEC 12207:1995 con sus dos enmiendas y se aplica a

las directrices del SC7 para la definición de los procesos de apoyo, a la coherencia y a la

mejora de la usabilidad. La ejecución del proyecto fue coordinado cuidadosamente con la

revisión paralela de la norma ISO / IEC 15288:2002 para alinear la estructura, términos, y

los correspondientes procesos de organización y proyecto.


Esta Norma Internacional establece un marco común para los procesos de ciclo de vida del

software, con una terminología bien definida, que puede hacer referencia a la industria

del software. Contiene procesos, actividades y tareas que se deben aplicar durante la

adquisición de un software o servicio y durante el suministro, desarrollo, operación,

mantenimiento y eliminación de productos de software.

Se aplica a la adquisición de sistemas, software y servicios, con el suministro, desarrollo,

operación, mantenimiento y eliminación de productos de software y la parte de software

de un sistema, bien sea de manera interna o externa a una organización. Esos aspectos de

la definición del sistema son necesarios para proporcionar el contexto para los productos

de software y servicios que están incluidos.


Estructura

La estructura del estándar ha sido concebida de manera flexible y modular de manera que

pueda ser adaptada a las necesidades de cualquiera que lo use. Para conseguirlo, el

estándar se basa en dos principios fundamentales: Modularidad y responsabilidad. Con la

modularidad se pretende conseguir procesos con un mínimo acoplamiento y una máxima

cohesión. En cuanto a la responsabilidad, se busca establecer un responsable para cada

proceso, facilitando la aplicación del estándar en proyectos en los que pueden existir

distintas personas u organizaciones involucradas.

Procesos

Los procesos se clasifican en tres tipos: Principales, de soporte y de la organización. Los

procesos de soporte y de organización deben existir independientemente de la

organización y del proyecto ejecutado. Los procesos principales se instancian de acuerdo

con la situación particular.

Procesos Principales:

· Adquisición: Este proceso comienza definiendo la necesidad de adquirir un sistema o un

producto de software y continúa con la preparación y publicación de la solicitud de

propuestas, la selección de un proveedor y la gestión de los procesos de adquisición hasta

la aceptación del producto.

· Suministro: Este proceso puede iniciarse bien por una decisión de preparar una

propuesta para responder a una petición de un cliente, bien por la firma de un contrato

con el cliente para proporcionar el software. El proceso continúa con la identificación de

los procedimientos y recursos necesarios para gestionar y asegurar el proyecto,

incluyendo el desarrollo de los planes del proyecto y la ejecución de los planes hasta la

entrega del software.

· Desarrollo: Este proceso contiene las actividades para el análisis de requisitos, diseño,

codificación, integración, pruebas, instalación y aceptación relativos al software. El

desarrollador selecciona y realiza, o presta apoyo, a las siguientes actividades de acuerdo

con el contrato.

Las principales actividades que lo conforman son:

• Análisis de los requisitos

• Diseño de la arquitectura

• Diseño detallado

• Codificación y pruebas

• Integración

• Prueba de cualificación

• Instalación

• Soporte a la aceptación

· Operación: (también llamado explotación): Este proceso abarca la operación del

software y el soporte a usuarios. Debido a que la operación del software se integra en la

operación del sistema, las actividades y tareas del proceso de operación se refieren al

sistema.

· Mantenimiento: Este proceso se activa cuando el software sufre modificaciones de

código o de documentación asociada debido a un error, una deficiencia, un problema o la

necesidad de mejora o adaptación.

Procesos de soporte:

Estos procesos dan soporte a los procesos principales o a otros procesos de soporte. Se

emplean en varios puntos del ciclo de vida y pueden ser realizados por la organización que

los emplea, por una organización independiente (como un servicio), o por un cliente como

elemento planificado o acordado del proyecto.

· Documentación: Registrar la información producida por un proceso o actividad del ciclo

de vida: Diseñar, editar, distribuir y mantener los documentos producidos durante el

desarrollo del software.

· Gestión de la configuración: Actividades que controlan las modificaciones y versiones de

los elementos. Registrar las peticiones de cambios e informar de los estados de éstos.

· Aseguramiento de la calidad: Actividades para asegurar que los productos cumplen los

requisitos especificados y se ajustan a los planes establecidos.

· Verificación: Actividades para determinar el buen funcionamiento del software.

· Validación: Actividades para determinar si el producto cumple los requisitos previstos.

· Revisión conjunta: Actividades que permiten determinar el estado de los productos en

una determinada actividad del ciclo de vida o en una cierta fase del proyecto. Puede ser

una reunión conjunta con el cliente, el grupo de desarrollo y los clientes potenciales para

revisar el trabajo hecho.

· Auditorías: Actividades que permiten determinar en unos momentos determinados si se

han conseguido los objetivos propuestos: requisitos, cumplimiento del contrato etc.

· Resolución de problemas: Actividades que permiten analizar y resolver los problemas o

disconformidades con los requisitos o con el contrato, que hayan surgido durante el

desarrollo, la explotación, el mantenimiento, o en cualquier otro momento.

Procesos de la organización:

Los emplea una organización para llevar a cabo funciones tales como gestión, formación

del personal o mejora del proceso. Estos procesos ayudan a establecer, implementar y

mejorar, consiguiendo una organización más eficiente. Se llevan a cabo normalmente a

nivel organizacional fuera del ámbito de proyectos y contratos específicos.

· Gestión: Actividades de planificación, seguimiento, control, revisión y evaluación.

· Infraestructura: Actividades para determinar la infraestructura necesaria para un

proceso. Incluye HW, SW, instalaciones…

· Mejora: Valorar, medir, controlar, evaluar y mejorar todos los procesos del ciclo de vida.

· Formación: Plan de formación para los empleados.


Es posible identificar relaciones entre los procesos de COBIT con los presentados por el

estándar ISO/IEC 12207:

COBIT ISO 12207

AI1 – Identificación de soluciones 5.1 Adquisición

AI2 – Adquisición y mantenimiento

de aplicaciones

5.1 Adquisición, 5.2 Suministro, 5.3 Desarrollo,

5.5 Mantenimiento, 6.2 Gestión de

configuraciones

AI3 – Adquisición y mantenimiento

de la infraestructura tecnológica

5.1 Adquisición, 5.2 Suministro, 5.5

Mantenimiento, 7.2 Infraestructura

AI4 – Facilidad de uso 6.1 Documentación, 6.8 Resolución de problemas,

7.1 Gerencia, 7.4 Formación

AI5 – Obtención de recursos

tecnológicos 7.2 Infraestructuras

AI6 – Gestión de cambios 5.2 Suministro, 5.5 Mantenimiento, 7.3 Mejoras

AI7 – Instalación y acreditación de

soluciones y cambios

6.3 Verificación de la calidad, 6.4 Verificación, 6.5

Validación, 6.6 Integración, 6.7 Auditoría

Resumen

ISO/IEC 20000

La llegada de ISO/IEC 20000, que deriva de la norma británica BD 15000, es un hito

definitivo para el éxito y la popularidad de las mejores prácticas en la gestión de servicios

de TI por todo el mundo. El reconocimiento como norma oficial supone un empuje

decisivo hacia la cultura de servicios en el sector de las TI, al poner los medios para medir

y certificar la excelencia de este tipo de servicios.

El propósito de ISO/IEC 20000 es “proveer una norma de referencia común para todas las

empresas que ofrezcan servicios de TI tanto a clientes externos como internos”. Uno de

los objetivos más importantes de la norma es crear una terminología común para las

organizaciones proveedoras de servicios TI, sus suministradores y sus clientes. La norma

promueve la adopción de un planteamiento de procesos integrados para la gestión de los

servicios de TI. Esta norma se establece para definir todo aquello que es obligatorio para

la buena gestión de servicios.

ISO/IEC 20000 está alineada con el marco de trabajo de la Biblioteca de Infraestructura de

TI (ITIL), con la diferencia de que ITIL es un conjunto de mejores prácticas, mientras que

ISO/IEC 20000 es un conjunto formal de especificaciones cuyo cumplimiento debería ser

perseguido por los proveedores de servicios. Además de cubrir los procesos explícitos de

ITIL y también algunos procesos adicionales que están parcialmente cubiertos por

publicaciones actuales de ITIL.

La norma ISO/IEC 20000 está compuesta de dos partes:

• Parte 1: especificaciones; esta es la especificación oficial de la norma. Esta parte es la

que se “debe” cumplir para obtener la certificación.

• Parte 2: código de prácticas; esta parte describe las mejores prácticas más

detalladamente. Esta parte es la que se “debería” tener en cuenta por las personas que

desean la certificación.

IEEE

Aunque el inicio de la IEEE fue como una organización encargada de regular las

comunicaciones y los avances en materia de electricidad, hoy en día se puede decir que

este concepto ha cambiado y se ha convertido en un instituto internacional con gran

influencia en muchos campos incluyendo la informática e ingeniería de software. En la

actualidad las normas IEEE para la ingeniería del software son amplias y se encuentran en

un grado de madures que les permiten servir como eje de calidad para los proyectos que

se realicen en este campo, algunas de las normas más relevantes son:

• IEEE Std 982.1-1988 IEEE (Diccionario Básico de Medidas para obtener

datos fiables de Software).

• IEEE Std 730™-2002(Norma para la calidad de los planes del software).

• ISO/IEC 16085:2004 (Tecnología de la información de software del ciclo de

vida los procesos de gestión de riesgos).

• IEEE Std 1540-2001(Norma IEEE sobre los procesos de software del Ciclo de

Vida-Gestión de Riesgos).

• IEEE Std 1490™-2003(Aprobación de PMI Guía estándar para la Dirección

de Proyectos del Conocimiento).

• IEEE Std 828™-2005(IEEE Estándar para el software de configuración de los

planes de gestión).

• IEEE 1058.1 (Plan para la Gestión de Proyectos Software).

Los anteriores estándares regulan las mejores prácticas para enfrentar proyectos de

software y les sirve como herramienta y sistema de apoyo a los ingenieros de software

que las siguen.

ISO/IEC 15404:SPICE

La norma ISO/IEC 15504:SPICE es una norma abierta e internacional 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 del proceso de desarrollo y mantenimiento de

software.

Fue creada por la alta competencia del mercado de desarrollo de software, a la difícil




pequeñas.

El principal propósito de esta normativa es proporcionar una base común para los

diferentes modelos y métodos de evaluación de procesos de software, asegurando que los

resultados de la evaluación sean iguales en un contexto común.

El modelo describe los procesos que una organización puede ejecutar, adquirir, suplir,

desarrollar, operar, evolucionar, brindar soporte de software y todas las prácticas

genéricas que caracterizan las potencialidades de estos procesos.

ISO/IEC 15408:2005

La información en poder de los productos o sistemas de TI es un recurso crítico que

permite a las organizaciones tener éxito en su misión. Además, los individuos tienen una

expectativa razonable de que su información personal contenida en los productos o

sistemas de TI sigue siendo privados, estén a su alcance cuando sea necesario, y que estos

no estén sujeto a modificaciones no autorizadas. Los productos o sistemas de TI deben

ejercer sus funciones en el ejercicio de un control adecuado de la información para

garantizar que esté protegido contra riesgos como la difusión no deseada o injustificada, a

la alteración o pérdida. El término de seguridad de TI se utiliza para incluir la prevención y

mitigación de estos y otros peligros.

Muchos consumidores de TI carecen de los conocimientos, la experiencia o los recursos

necesarios para juzgar si su confianza en la seguridad de sus productos o sistemas de TI es

el adecuado, y no podría confiar únicamente en las afirmaciones de los desarrolladores.

Consiguiente a esto, los consumidores pueden optar por aumentar su confianza en las

medidas de seguridad de un producto o sistema, ordenando un análisis de su seguridad,

es decir, una evaluación de la seguridad.

Para la cual la norma ISO/IEC 15408 puede ser utilizada como estándar para garantizar el

cumplimiento de los niveles de seguridad requeridos en un producto o sistema de TI.

ISO / IEC 15408 define las bases para garantizar los requisitos de seguridad en un sistema

o producto de TI.

ISO/IEC 19770:2006

Muchas organizaciones no han tomado el tiempo para dar un paso atrás y revisar el

aumento en los últimos años en las inversiones en software. Si lo hicieran, muchas se

sorprenderían al saber que ahora gastan más cada año en el software necesario en su

empresa, del que gastan en hardware o incluso objetos de alto precio, como automóviles

o maquinarias.

Sin embargo, aunque ninguna empresa responsable permitiría que sus autos recorran las

carreteras sin asegurarse de que estos están gravados con el seguro y los servicios

correspondientes, es difícil decir lo mismo en el caso del software de una organización.

Como tal, la norma ISO 19770 para la gestión de activos de software tiene que ver con el

ciclo de vida de las aplicaciones en uso en su red, desde la compra hasta su eliminación. La

norma establece seis áreas clave de las mejores prácticas destinadas a ayudar a todos los

tipos de las organizaciones a ahorrar dinero, reducir los riesgos de cumplimiento e

incrementar la eficiencia operativa de gestión de software.

ISO 12207

Esta Norma Internacional establece un marco común para los procesos de ciclo de vida del

software, con una terminología bien definida, que puede hacer referencia a la industria

del software. Contiene procesos, actividades y tareas que se deben aplicar durante la

adquisición de un software o servicio y durante el suministro, desarrollo, operación,

mantenimiento y eliminación de productos de software.

Esta Norma Internacional se aplica a la adquisición de sistemas, software y servicios, con

el suministro, desarrollo, operación, mantenimiento y eliminación de productos de

software y la parte de software de un sistema, bien sea de manera interna o externa a una

organización. Esos aspectos de la definición del sistema son necesarios para proporcionar

el contexto para los productos de software y servicios que están incluidos.

Conclusiones y Observaciones

Se pude ver que el modelo describe los procesos que una organización puede

ejecutar, adquirir, suplir, desarrollar, operar, evolucionar, brindar soporte de

software y todas las prácticas genéricas que caracterizan las potencialidades de

estos procesos.

La calidad del todos los componentes integrados en el proceso de desarrollo del

software no mejora necesariamente por el simple hecho de adoptar un estándar.

Es necesario que el proceso de adopción conlleve una gestión del cambio

adecuada.

Es necesario tener un estándar como objetivo y referencia del proceso de

desarrollo del software.

El modelo seleccionado no es tan importante como el compromiso de mejora.

Bibliografía

ISO/IEC 20000. Welcome to the itSMF ISO/IEC 20000 Certification web site.

Recuperado el 03 de Octubre de 2010, En:

http://www.isoiec20000certification.com/

COBIT. Recuperado el 03 de Octubre de 2010, En:

http://www.isaca.org/Template.cfm?Section=COBIT6&T

IEEE. IEEEXplore Digital Library. Recuperado el 03 de Octubre de 2010, En:

http://ieeexplore.ieee.org/xpl/standards.jsp?psf_t=software+engineering&psf_isie

ee=null&psf_isiet=null&psf_isaip=null&psf_istandj=null&psf_ismag=null&psf_isltr=

null&psf_rpp=10&psf_isatv=0&psf_rngmin=-1&psf_rngmax=-

1&psf_pn=1&psf_scid=&psf_scn=&psf_tarid=&psf_tarn=

IEEE. Historia del IEEE. Recuperado el 03 de Octubre de 2010, En:

http://www.ieeeperu.org/index.php?option=com_content&task=view&id=24&Ite

mid=7

IEEE. IEEE 610.12 Standard Glossary of Software Engineering Terminology.


http://electronics.ihs.com/document/abstract/WCEXCAAAAAAAAAAA

IEEE. Software Engineering — Software Life Cycle Processes — Maintenance.


https://docs.google.com/viewer?url=http://webstore.iec.ch/preview/info_isoiec14

764%257Bed2.0%257Den.pdf

ISO/IEC 20000. Recuperado el 03 de Octubre de 2010, En:

http://iso20000enespanol.com/index.php?option=com_content&task=view&id=26

&Itemid=31

ISO/IEC 19970. Recuperado el 03 de Octubre de 2010, En: http://gestion-activos-

software.wke.es/como-implementar-ISO-19770.htm#amastext1

ISO/IEC 15408:2005. Recuperado el 03 de Octubre de 2010, En: http://seguridad-

de-la-informacion.blogspot.com/2009/04/iso-15408-y-el-dni-e-pp-para-el.html

COMPILACIÓN BIBLIOGRÁFICA: ISO/IEC 20000 ...“N BIBLIOGRÁFICA: ISO/IEC 20000 (ESTÁNDAR...

Documents

Transcript of COMPILACIÓN BIBLIOGRÁFICA: ISO/IEC 20000 ...“N BIBLIOGRÁFICA: ISO/IEC 20000 (ESTÁNDAR...