TRABAJO FINAL UNIDAD 2

1. UNIVERSIDAD TECNOLÓGICA DEL ESTADO DE ZACATECAS
UNIDAD ACADÉMICA DE PINOS
TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN
Nombre:
 Claudia Muñoz Cárdenas. Grado y Grupo: 7 B Tic
Profesora:
IDS. Lucia González Hernández. Materia: Sistemas de calidad de TI.
Unidad :
II Calidad en Proyectos de TI. Tema : Estándares y normas de calidad

2. Estándar
Es un conjunto de reglas que deben cumplir los productos, procedimientos o investigaciones que afirmen ser compatibles con el mismo producto. Los estándares ofrecen muchos beneficios, reduciendo las diferencias entre los productos y generando un ambiente de estabilidad, madurez y calidad en beneficio de consumidores e inversores. Los esfuerzos que se están realizando y los ya realizados han perseguido distintos objetivos que van desde la definición de API(Interface de Programación de Aplicaciones), los formatos de los ficheros con la información de parámetros biométricos, la encriptación de la información biométrica, la interacción entre dispositivos biométricos diferentes, etc.
Normas
Son reglas de conductas que nos imponen un determinado modo de obrar o de abstenernos. Las normas pueden ser establecidas desde el propio individuo que se las auto impone, y en este caso son llamadas normas autónomas, como sucede con las éticas o morales. Así, una persona ayuda a un necesitado porque se lo ordena su propia conciencia, y cuyo castigo también es personal, y está dado por el remordimiento.
Una norma es una regla que debe ser respetada y que permite ajustar ciertas conductas o actividades. Las normas se enfocan más en los procesos por los que tienen que pasar los productos y los estándares especifican la calidad con la que debe contar los productos.

3. ISO 9011
Indica como auditar los procesos que constituyen al sistema de gestión de la calidad.
Una de las novedades más relevantes de la norma es que, por primera vez, se dispone de una norma conjunta para auditorías de Calidad y medioambientales. Esta norma se enfoca hacia cuatro aspectos relativos a la realización de auditorías:
1. Principios de auditoría
Muy importante es la inclusión de este bloque en la norma en el cual se mencionan los principios éticos y de profesionalidad que deben regir la conducta de auditores. Estos principios son la base de la fiabilidad de cualquier proceso de auditorías, y son los que nos permiten confiar en la veracidad de los resultados de una auditoría.
2. Gestión de un programa de auditoría
La gestión del programa de auditoría se plantea como un proceso de mejora continua con un flujo de operaciones alineado con un planteamiento PDCA (Plan - Do - Check - Act). En este sentido, esta norma ya se alinea con las últimas versiones de las normas de sistemas de gestión (ISO 9001, ISO 14001, etc.) como una norma para la mejora continua. Es importante destacar que en este apartado se realiza un planteamiento totalmente abierto hacia la planificación de las auditorías, mencionando explícitamente la realización de auditorías combinadas de sistemas de gestión de la Calidad y ambiental. 3. Actividades de auditoría
ISO 19011 proporciona directrices muy concretas para cada una las tareas específicas a desarrollar durante la planificación y realización de una auditoría. Inicialmente se consideran las tareas de preparación de las auditorías, de definición de los objetivos y recursos (equipo auditor…) y de comunicación con la organización a auditar. Un aspecto crítico de este proceso de preparación será la revisión de la documentación de la organización a auditar que se considere necesaria para una buena preparación de la auditoria.

4. 4. Competencia y evaluación de los auditores
El último bloque se la norma se dedica a las directrices para el diseño e implementación de un modelo de gestión para la competencia y evaluación de los auditores. Indudablemente, la dedicación de un bloque entero de la norma nos da a entender que la disponibilidad de equipos de auditoría competentes se considera uno de los pilares fundamentales para el correcto funcionamiento de un programa de auditorías.

5. ISO 9126
Es estándar internacional para evaluación de calidad del software. El estándar se divide en cuatro porciones, que tratan, respectivamente, los temas siguientes: modelo de la calidad; métrica externa; métrica interna; y métrica funcionando de la calidad. El modelo de la calidad establecido en la primera parte del estándar, ISO 9126-1, clasifica calidad del software en un sistema estructurado de características y de secundario-características como sigue:
• Funcionalidad - Un sistema de las cualidades que refieren la existencia de un sistema de funciones y de sus características especificadas. Las funciones son las que satisfacen necesidades indicadas o implicadas.
*Conveniencia *Exactitud *Interoperabilidad *Conformidad *Seguridad • Confiabilidad - Un sistema de las cualidades que refieren la capacidad del software para mantener su nivel del funcionamiento bajo condiciones indicadas por un período del tiempo indicado.
* Madurez *Recuperabilidad *Tolerancia de avería
• Utilidad - Un sistema de las cualidades que refieren el esfuerzo necesitó para el uso, y en el gravamen individual de tal uso, por un sistema indicado o implicado de usuarios.
*Learnability *Understandability *Operability

6. • Eficacia - Un sistema de las cualidades que refieren la relación entre el nivel del funcionamiento del software y la cantidad de recursos usados, bajo condiciones indicadas.
*Comportamiento de Tiempo *Comportamiento del recurso
• Capacidad de mantenimiento - Un sistema de las cualidades que refieren el esfuerzo necesitó hacer modificaciones especificadas.
*Estabilidad *Analyzability *Changeability *Testability • Portabilidad - Un sistema de las cualidades que refieren la capacidad del software de ser transferido a partir de un ambiente a otro.
*Installability *Reemplazabilidad *Adaptabilidad Este estándar proviene modelo establecido en 1977 de McCall y de sus colegas, que propusieron un modelo para especificar calidad del software. El modelo de la calidad de McCall se organiza alrededor de tres tipos de características de la calidad:
Factores (especificar): Describen la vista externa del software, según lo visto por los usuarios. Criterios (construir): Describen la vista interna del software, según lo visto por el revelador. Métrica (al control): Se definen y se utilizan para proporcionar una escala y un método para la medida.

7. ISO 10006
Sistemas de gerencia de la calidad - pautas para la gerencia de la calidad en proyectos, es un estándar internacional convertido por International Organization for Standardization. La ISO 10006 da la dirección en el uso de la gerencia de la calidad en proyectos. Es aplicable a los proyectos de la complejidad que varía, pequeño o grande, de la duración corta o larga, en diversos ambientes, y con independencia de la clase de producto o de proceso implicado.
Características:
*Directrices para la calidad en la gestión de proyectos *Aplicable a proyectos pequeños o grandes, de larga o pequeña duración *No es una guía de administración de proyectos en sí *Es un documento guía, y no utilizado para una certificación o registro *Hace recomendaciones sobre la gestión de la información generada por la realización del proyecto.
Ventajas
* Reduce la variedad y tipos de productos * Reduce inventarios y costos de producción * Mejora la gestión y el diseño de productos * Mejora la comercialización de los productos * Agiliza los procesos pedidos
Desventajas
* No entra en las fases del proyecto ni describe los procesos necesarios para su ejecución * No incluye los procesos de gestión de la calidad y, por lo tanto, da a entender que estos procesos no forman parte de la gestión del proyecto.

8. ISO/IEC 27000
ISO/IEC 27000 es un conjunto de estándares desarrollados -o en fase de desarrollo- por ISO (International Organization for Standardization) e IEC (International Electrotechnical Commission), que proporcionan un marco de gestión de la seguridad de la información utilizable por cualquier tipo de organización, pública o privada, grande o pequeña.
La serie 27000
A semejanza de otras normas ISO, la 27000 es realmente una serie de estándares. Los rangos de numeración reservados por ISO van de 27000 a 27019 y de 27030 a 27044.
• ISO 27000: En fase de desarrollo; su fecha prevista de publicación es Noviembre de 2008. Contendrá términos y definiciones que se emplean en toda la serie 27000. La aplicación de cualquier estándar necesita de un vocabulario claramente definido, que evite distintas interpretaciones de conceptos técnicos y de gestión. Esta norma está previsto que sea gratuita, a diferencia de las demás de la serie, que tendrán un coste.
• ISO 27001: Publicada el 15 de Octubre de 2005. Es la norma principal de la serie y contiene los requisitos del sistema de gestión de seguridad de la información. Tiene su origen en la BS 7799-2:2002 y es la norma con arreglo a la cual se certifican por auditores externos los SGSI de las organizaciones. Sustituye a la BS 7799-2, habiéndose establecido unas condiciones de transición para aquellas empresas certificadas en esta última.
• ISO 27002: Desde el 1 de Julio de 2007, es el nuevo nombre de ISO 17799:2005, manteniendo 2005 como año de edición. Es una guía de buenas prácticas que describe los objetivos de control y controles recomendables en cuanto a seguridad de la información. No es certificable. Contiene 39 objetivos de control y 133 controles, agrupados en 11 dominios.
• ISO 27003: En fase de desarrollo; su fecha prevista de publicación es Mayo de 2009. Consistirá en una guía de implementación de SGSI e información acerca del uso del modelo PDCA y de los requerimientos de sus diferentes fases. Tiene su origen en el anexo B de la norma BS7799-2 y en la serie de documentos publicados por BSI a lo largo de los años con recomendaciones y guías de implantación.
• ISO 27004: En fase de desarrollo; su fecha prevista de publicación es Noviembre de 2008. Especificará las métricas y las técnicas de medida aplicables para determinar la eficacia de un SGSI y de los controles relacionados. Estas métricas se usan fundamentalmente para la medición de los componentes de la fase “Do” (Implementar y Utilizar) del ciclo PDCA.

9. • ISO 27005: Publicada el 4 de Junio de 2008. Establece las directrices para la gestión del riesgo en la seguridad de la información. Apoya los conceptos generales especificados en la norma ISO/IEC 27001 y está diseñada para ayudar a la aplicación satisfactoria de la seguridad de la información basada en un enfoque de gestión de riesgos.
• ISO 27006: Publicada el 13 de Febrero de 2007. Especifica los requisitos para la acreditación de entidades de auditoría y certificación de sistemas de gestión de seguridad de la información. Es una versión revisada de EA-7/03 (Requisitos para la acreditación de entidades que operan certificación/registro de SGSIs) que añade a ISO/IEC 17021 (Requisitos para las entidades de auditoría y certificación de sistemas de gestión) los requisitos específicos relacionados con ISO 27001 y los SGSIs.
• ISO 27007: En fase de desarrollo; su fecha prevista de publicación es Mayo de 2010. Consistirá en una guía de auditoría de un SGSI.
• ISO 27011: En fase de desarrollo; su fecha prevista de publicación es finales de 2008. Consistirá en una guía de gestión de seguridad de la información específica para telecomunicaciones, elaborada conjuntamente con la ITU (Unión Internacional de Telecomunicaciones).
• ISO 27031: En fase de desarrollo; su fecha prevista de publicación es Mayo de 2010. Consistirá en una guía de continuidad de negocio en cuanto a tecnologías de la información y comunicaciones.
• ISO 27032: En fase de desarrollo; su fecha prevista de publicación es Febrero de 2009. Consistirá en una guía relativa a la ciberseguridad.
• ISO 27033: En fase de desarrollo; su fecha prevista de publicación es entre 2010 y 2011. Es una norma consistente en 7 partes: gestión de seguridad de redes, arquitectura de seguridad de redes, escenarios de redes de referencia, aseguramiento de las comunicaciones entre redes mediante gateways, acceso remoto, aseguramiento de comunicaciones en redes mediante VPNs y diseño e implementación de seguridad en redes. Provendrá de la revisión, ampliación y remuneración de ISO 18028.
• ISO 27034: En fase de desarrollo; su fecha prevista de publicación es Febrero de 2009. Consistirá en una guía de seguridad en aplicaciones.
• ISO 27799: Publicada el 12 de Junio de 2008. Es un estándar de gestión de seguridad de la información en el sector sanitario aplicando ISO 17799 (actual ISO 27002). Esta norma, al contrario que las anteriores, no la desarrolla el subcomité JTC1/SC27, sino el comité técnico TC 215. ISO 27799:2008 define directrices para apoyar la interpretación y aplicación en la salud informática de la norma ISO / IEC 27002 y es un complemento de esa norma.

10. ISO/IEC 20000
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).
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.
El estándar se compone de 5 partes, de las cuales cuatro están ya publicadas y una en proceso de publicación:
Parte 1: ISO/IEC 20000-1:2011 - Requisitos de los sistemas de gestión de servicios
Parte 2: ISO/IEC 20000-2:2012 - Guía de implementación de los sistemas de gestión de servicios
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:2010 - Modelo de referencia de procesos (informe técnico)
Parte 5: ISO/IEC TR 20000-5:2010 - Ejemplo de implementación (informe técnico)

11. Rasgos y beneficios
La ISO/IEC 20000 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.

12. Moprosoft
Modelo de Procesos para la Industria del Software. Modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software. Desarrollado por la Asociación Mexicana para la Calidad en Ingeniería de Software a través de la Facultad de Ciencias de la Universidad Nacional Autónoma de México (UNAM) y a solicitud de la Secretaría de Economía para obtener una norma mexicana que resulte apropiada a las características de tamaño de la gran mayoría de empresas mexicanas de desarrollo y mantenimiento de software. Moprosoft es el nombre del modelo en la comunidad universitaria y profesional, y la norma técnica a la que da contenido es la NMX-059/02-NYCE-2005 que fue declarada Norma Mexicana el 15 de agosto de 2005 con la publicación de su declaratoria en el Diario oficial de la Federación.
Moprosoft considera que los modelos de evaluación y mejora CMMI e ISO/IEC 15504 no resultan apropiados para empresas pequeñas y medianas de desarrollo y mantenimiento de software. Sobre las áreas de procesos de los niveles 2 y 3 del modelo SW-CMM e inspirándose en el marco de ISO/IEC 15504 se ha desarrollado este modelo.
Criterios empleados
 Se han aplicado los siguientes criterios para la elaboración de este modelo de procesos:
 La estructura de procesos resultante debe ser acorde a la estructura generalmente empleada por las organizaciones de la industria del software (alta dirección, gestión y operación)
 La alta dirección tiene un papel importante a través de la planificación estratégica. Debe actuar como promotor del buen funcionamiento de la organización a través de su implicación en la revisión y mejora continua del modelo.
 El modelo considera a la gestión como proveedora de recursos, procesos y proyectos; así como responsable de la vigilancia del cumplimiento de los objetivos estratégicos de la organización.
 El modelo considera a la operación como ejecutora de los proyectos de desarrollo y mantenimiento de software.
 El modelo integra con claridad y consistencia los elementos indispensables para la definición de los procesos y las relaciones entre ellos.
 El modelo integra los elementos para realizar la administración de proyectos desde un sólo proceso.
 El modelo integra los elementos para realizar la ingeniería de productos de software en un único marco que incluya los procesos precisos de soporte (verificación, validación, documentación y control de la documentación).

13.  El modelo destaca la importancia de la gestión de recursos, con especial relevancia en aquellos que componen el conocimiento de la organización: productos generados por proyectos, datos de los proyectos, mediciones, documentación de procesos y datos cosechados a partir del uso y de las lecciones aprendidas.
Procesos
 Categoría alta dirección (DIR)
Gestión de Negocio
Gestión de negociación
 Categoría Gerencia (GER)
Gestión de Procesos
Gestión de Proyectos
Gestión de Recursos
Recursos Humanos y Ambiente de Trabajo
Bienes Servicios e Infraestructura
Conocimiento de la Organización.
 Categoría Operación (OPE)
Administración de Proyectos Específicos
Desarrollo y Mantenimiento de Software

14. ESTANDARES PARA LA DOCUMENTACION DE PROYECTOS
IEEE 830-1998
(PRACTICA RECOMENDADA PARA LAS ESPECIFICACIONES DE REQUISITOS DEL SOFTWARE). La especificación de requisitos de software (ERS) es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de uso que describe todas las interacciones que tendrán los usuarios con el software. Los casos de uso también son conocidos como requisitos funcionales. Además de los casos de uso, la ERS también contiene requisitos no funcionales (o complementarios). Los requisitos no funcionales son requisitos que imponen restricciones en el diseño o la implementación, como, por ejemplo, restricciones en el diseño o estándares de calidad. Está dirigida tanto al cliente como al equipo de desarrollo. El lenguaje utilizado para su redacción debe ser informal, de forma que sea fácilmente comprensible para todas las partes involucradas en el desarrollo.
Prácticas recomendadas para una buena ERS
Las características de una buena ERS son definidas por el estándar IEEE 830- 1998. Una buena ERS debe ser:
Completa. Todos los requerimientos deben estar reflejados en ella y todas las referencias deben estar definidas.
Consistente. Debe ser coherente con los propios requerimientos y también con otros documentos de especificación.
Inequívoca. La redacción debe ser clara de modo que no se pueda mal interpretar.
Correcta. El software debe cumplir con los requisitos de la especificación.
Trazable. Se refiere a la posibilidad de verificar la historia, ubicación o aplicación de un ítem a través de su identificación almacenada y documentada.
Priorizable. Los requisitos deben poder organizarse jerárquicamente según su relevancia para el negocio y clasificándolos en esenciales, condicionales y opcionales.

15. Modificable. Aunque todo requerimiento es modificable, se refiere a que debe ser fácilmente modificable.
Verificable. Debe existir un método finito sin costo para poder probarlo.
Tipos de requisitos
Existen varios tipos de requisitos como lo son:
Requisitos de Usuarios: Necesidades que los usuarios expresan verbalmente
Requisitos del Sistema: Son los componentes que el sistema debe tener para realizar determinadas tareas
Requisitos Funcionales: Servicios que el sistema debe proporcionar
Requisitos no funcionales: Restricciones que afectan al sistema

16. Nueva Norma ISO/IEC 26514:2008 Documentación Software.
La Nueva Norma ISO/IEC 26514:2008 pretende cubrir las necesidades que cualquier persona que utiliza aplicaciones de software tiene. La documentación puede ser el primer elemento tangible que el usuario ve y por lo tanto, las influencias del esas primeras impresiones del nuevo usuario de software son importantes
La Norma Internacional ISO / IEC 26514:2008 sobre documentación ayudará a los diseñadores y desarrolladores, ya que define el proceso de catalogación de la documentación del desarrollador. El informe abarca las etapas implicadas en el diseño, especificando, y la producción de documentación para el usuario. Se aplica tanto a la documentación impresa como en pantalla.
La norma (ISO / IEC 26514:2008 – Sistemas y software de ingeniería) recomienda que el desarrollo de la documentación del usuario debe ser parte del desarrollo del producto de software y sigue los mismos procesos como el ciclo de vida del producto.
ISO / IEC 26514:2008 - Sistemas y software de ingeniería - Requisitos para los diseñadores y desarrolladores de documentación de usuario, abarca las fases implicadas en el diseño, especificando, y la elaboración de la documentación de usuario. Se divide en dos partes:
La primera parte abarca el proceso de documentación de usuario para los diseñadores y desarrolladores de la documentación. En él se describe cómo establecer lo que necesitan los usuarios de la información, la forma de determinar la forma en que esa información debe ser presentada a los usuarios, y la forma de preparar la información y ponerla a disposición. No se limita a la fase de diseño y desarrollo del ciclo de vida, sino que incluye actividades en toda la gestión de la información y documentación de procesos.
La segunda parte establece los requisitos mínimos para la estructura, el contenido de la información, y el formato de la documentación de usuario, incluidos los impresos y en la pantalla los documentos utilizados en el entorno de trabajo por parte de los usuarios de los sistemas que contienen software. Se aplica a los impresos de manuales de usuario, ayuda en línea, tutoriales, y documentación de referencia del usuario.
La norma recomienda que el desarrollo de la documentación del usuario debería ser parte del desarrollo del producto de software y sigue los mismos procesos como el producto de software de ciclo de vida y no un ejercicio separado. La documentación de usuario sigue siendo un componente esencial de utilizar los productos de software y de ISO / IEC 26514:2008 puede ser útil para el desarrollo de los siguientes tipos de documentación:

17.  Documentación de productos distintos de software
 Multimedia utilizando sistemas de animación, vídeo y sonido
 Basados en computadoras y programas de capacitación especializados de los materiales del curso destinado principalmente para su uso en los programas de formación
 La documentación producida por los instaladores, operadores de equipo, o los administradores de sistemas que no son usuarios finales
 Mantenimiento de la documentación que describe el funcionamiento interno de los sistemas de software
 Documentación incorporada en la interfaz de usuario propia.

18. ITIL (Information Technology Infrastructure Library)
La Biblioteca de Infraestructura de Tecnologías de Información, frecuentemente abreviada ITIL (del inglés Information Technology Infrastructure Library), es un conjunto de conceptos y prácticas para la gestión de servicios de tecnologías de la información, el desarrollo de tecnologías de la información y las operaciones relacionadas con la misma en general. ITIL da descripciones detalladas de un extenso conjunto de procedimientos de gestión ideados para ayudar a las organizaciones a lograr calidad y eficiencia en las operaciones de TI. Estos procedimientos son independientes del proveedor y han sido desarrollados para servir como guía que abarque toda infraestructura, desarrollo y operaciones de TI.
Historia
Aunque se desarrolló durante los años 1980, ITIL no fue ampliamente adoptada hasta mediados de los años 1990. Esta mayor adopción y conocimiento ha llevado a varios estándares, incluyendo ISO/IEC 20000, que es una norma internacional cubriendo los elementos de gestión de servicios de TI de ITIL. ITIL se considera a menudo junto con otros marcos de trabajo de mejores prácticas como la Information Services Procurement Library (ISPL, ‘Biblioteca de adquisición de servicios de información’), la Application Services Library (ASL, ‘Biblioteca de servicios de aplicativos’), el método de desarrollo de sistemas dinámicos (DSDM, Dynamic Systems Development Method), el Modelo de Capacidad y Madurez (CMM/CMMI) y a menudo se relaciona con la gobernanza de tecnologías de la información mediante COBIT (Control OBjectives for Information and related Technology).
ITIL se construye en torno a una vista basada en proceso-modelo del control y gestión de las operaciones a menudo atribuida a W. Edwards Deming. Las recomendaciones de ITIL fueron desarrolladas en los años 1980 por la Central Computer and Telecommunications Agency (CCTA) del gobierno británico como respuesta a la creciente dependencia de las tecnologías de la información y al reconocimiento de que sin prácticas estándar, los contratos de las agencias estatales y del sector privado creaban independientemente sus propias prácticas de gestión de TI y duplicaban esfuerzos dentro de sus proyectos TIC, lo que resultaba en errores comunes y mayores costes.
ITIL fue publicado como un conjunto de libros, cada uno dedicado a un área específica dentro de la Gestión de TI. Los nombres ITIL e IT Infrastructure Library (‘Biblioteca de infraestructura de TI’) son marcas registradas de la Office of Government Commerce (‘Oficina de comercio gubernamental’, OGC), que es una división del Ministerio de Hacienda del Reino Unido.
En abril de 2001 la CCTA fue integrada en la OGC, desapareciendo como organización separada.1

19. En diciembre de 2005, la OGC emitió un aviso de una actualización a ITIL,2 conocida comúnmente como ITIL v3, que estuvo planificada para ser publicada a finales de 2006; habiendo sido realizada en junio de 2007. Se esperaba que la publicación de ITIL versión 3 incluyera cinco libros principales, concretamente: Diseño de Servicios de TI, Introducción de los Servicios de TI, Operación de los Servicios de TI, Mejora de los Servicios de TI y Estrategias de los Servicios de TI, consolidando buena parte de las prácticas actuales de la versión 2 en torno al Ciclo de Vida de los Servicios.
Uno de los principales beneficios propugnado por los defensores de ITIL dentro de la comunidad de TI es que proporciona un vocabulario común, consistente en un glosario de términos precisamente definidos y ampliamente aceptados. Un nuevo glosario ampliado ha sido desarrollado como entregable clave de ITIL versión 3.
Otros modelos: CMMI para el desarrollo de software y s3m,3 para el mantenimiento del software
Certificación
Los particulares pueden conseguir varias certificaciones oficiales ITIL. Los estándares de calificación ITIL son gestionados por la ITIL Certification Management Board (ICMB) que agrupa a la OGC, a itSMF International y a los dos Institutos Examinadores existentes: EXIN (con sede en los Países Bajos) e ISEB (con sede en el Reino Unido).
Existen tres niveles de certificación ITIL para profesionales:
Foundation Certificate (Certificado Básico): acredita un conocimiento básico de ITIL en gestión de servicios de tecnologías de la información y la comprensión de la terminología propia de ITIL. Está destinado a aquellas personas que deseen conocer las buenas prácticas especificadas en ITIL.
Practitioner's Certificate (Certificado de Responsable): destinado a quienes tienen responsabilidad en el diseño de procesos de administración de departamentos de tecnologías de la información y en la planificación de las actividades asociadas a los procesos.
Manager's Certificate (Certificado de Director): garantiza que quien lo posee dispone de profundos conocimientos en todas las materias relacionadas con la administración de departamentos de tecnologías de la información, y lo habilita para dirigir la implantación de soluciones basadas en ITIL.

20. Los ocho libros de ITIL y sus temas son:
Gestión de Servicios de TI,
1. Mejores prácticas para la Provisión de Servicio
2. Mejores prácticas para el Soporte de Servicio
Otras guías operativas
3. Gestión de la infraestructura de TI
4. Gestión de la seguridad
5. Perspectiva de negocio
6. Gestión de aplicaciones
7. Gestión de activos de software
Para asistir en la implementación de prácticas ITIL, se publicó un libro adicional con guías de implementación (principalmente de la Gestión de Servicios):
8. Planeando implementar la Gestión de Servicios
Adicional a los ocho libros originales, más recientemente se añadió una guía con recomendaciones para departamentos de TIC más pequeños:
9. Implementación de ITIL a pequeña escala

21. PMBOK®
La Guía de los fundamentos de la dirección de proyectos (más conocida como PMBOK®) es el estándar más ampliamente reconocido para manejar y administrar proyectos. Resulta curioso que este texto tenga la fama de ser un manual para dirigir proyectos, o bien que se trata de un texto rigorista y dogmático. En realidad, se trata de una obra realizada por personas con un agudo sentido práctico, y que tiene incorporada la concepción de que un proyecto exitoso va a ser resultado de la colaboración (y los conflictos) entre el Señor Spock, el Capitán Kirk, y la tripulación (tal como ya lo hemos explicado en la sección “Soy gerente de proyecto”). Para citar uno de los párrafos introductorios del PMBOK®: «“Buenas prácticas” no quiere decir que los conocimientos descritos deban aplicarse siempre de manera uniforme en todos los proyectos: el equipo de dirección del proyecto es el responsable de determinar lo que es apropiado para cada proyecto determinado.» Desde su misma Introducción, el PMBOK® deja muy claro su carácter y finalidad: el conjunto de conocimientos (the body of knowledge) para dirigir un proyecto “residen en los practicantes y académicos que los aplican y los desarrollan”; en otras palabras, estos conocimientos representan un conjunto vivo, extraordinariamente amplio, producto tanto de la experiencia como del estudio y del desarrollo sistemáticos. Este conjunto de conocimientos se encuentra distribuido en miles de personas, organizaciones y textos; por ende, el lector no debe esperar tal cosa como un manual que le vaya a explicar los “nueve pasos fáciles para hacer de su proyecto un éxito”. La finalidad del PMBOK®, entonces, no es la de exponer las disciplinas, técnicas y experiencias aplicables a la dirección de proyectos, sino simplemente la de identificar el subconjunto de éstas que es generalmente reconocido como buenas prácticas. Para que estas buenas prácticas sean asequibles, el PMBOK® divide el conjunto de conocimientos para la dirección de proyectos en cuatro grupos de procesos: todo proyecto (así como sus distintas fases e iteraciones) tiene que transitar por una serie de actividades de inicio, de planeación, de ejecución y cierre, bajo el gobierno de un grupo de procesos más general de supervisión y cierre.

22. Estos grupos de procesos no representan fases rígidas ni recetas, sino que, grosso modo, equivalen al modelo “planear, hacer, revisar y actuar”:
El meollo del PMBOK®, sin embargo, lo representan las nueve áreas de conocimiento, y que son propiamente las que contienen las técnicas para poder realizar los proyectos. Las nueve áreas de conocimiento son:
Para cada una de estas áreas de conocimiento, el PMBOK® recomienda la realización de una serie de procesos. Por ejemplo, la Gestión del alcance comprende los procesos Planificar alcance, Definición del alcance, Crear estructura de desglose de tareas, Verificación de alcance y Control de alcance. Podemos apreciar los primeros tres de éstos en el siguiente diagrama:

23. Actualmente existen 05 versiones del PMBOK, siendo la quinta recientemente publicada por el PMI a mediados del 2012. Esta última edición comprende la documentación y explicación de 47 procesos de gestión y se caracteriza por presentar la noción de que cada área debe presentar su propio “Plan Maestro” con el fin de maximizar la eficiencia de cada una de éstas y liberar al proceso de cuellos de botella (por ejemplo: desarrollar un plan maestro para la Gestión de Recursos Humanos, un plan maestro para la Gestión de Calidad y así sucesivamente). Cabe destacar que el PMBOK ha sido redactado en un lenguaje común, utlilizando conceptos que han sido universalizados en el campo de la gestión de proyectos, lo cual significa que cualquier profesional que recién se encuentre introduciendo en ésta área de especialización podrá comprender fácilmente un concepto presentado y relacionar su aplicabilidad en distintos tipos de proyectos por más disímiles que parezcan. ALCANCE DEL PMBOK:
El PMBOK documenta nueve áreas de conocimiento los cuales considera universales para casi todo tipo de proyectos así como cinco grupos de procesos. Las áreas de conocimiento comprendidas en el PMBOK son: Integración, Alcance, Tiempo, Costos, Calidad, Recursos Humanos, Comunicación, Riesgo y Adquisiciones. Los grupos de procesos por su parte son: de Iniciación, Planificación, Ejecución, Seguimiento y Control y Cierre. Éstas áreas de conocimiento y grupos de procesos se encuentran relacionados entre sí, y la relación de los mismos es lo que conduce a una correcta gestión de proyectos y por tanto en esta documentación y sistematización de la documentación de los mismos reside el poder y alcance del PMBOK como la principal herramienta de todo profesional que busque especializarse en la Gerencia de Proyectos.

24. CMMI (INTEGRACIÓN DE MODELOS DE MADUREZ DE CAPACIDADES)
Por sus siglas en inglés CMMI (Capability Maturity Model Integration). Para las compañías un producto o servicio es de calidad cuando satisface las necesidades y expectativas del cliente otorgando a éste seguridad sobre su uso, fiabilidad de sus funciones esperadas y confianza en un producto o servicio sin fallos y duradero según tiempos establecidos y acordados. Debido a la amplitud de temas que engloba el concepto de calidad se ha definido el concepto de Calidad Total, el cual se define como un sistema de gestión organizacional enfocado en la mejora continua del producto o servicio en todo su ciclo de vida, involucrando marketing, compras, diseño, fabricación y entrega.
HISTORIA
CMMI fue desarrollado por el proyecto CMMI, cuyo objetivo es mejorar la usabilidad de modelos de madurez integrando muchos modelos diferentes en un solo marco. El proyecto consistió en miembros de la industria, el gobierno y la Carnegie Mellon Software Engineering Institute. Los principales patrocinadores incluyen a la Oficina del Secretario de Defensa y la Asociación Nacional de Defensa Industrial.
CMMI es el sucesor del modelo de madurez de capacidad o software CMM. El CMM fue desarrollado a partir de 1987 hasta 1997 - En 2002, CMMI versión 1.1 fue lanzado, versión 1.2 siguió en agosto de 2006 y CMMI versión 1.3 en noviembre de 2010 - Algunos de los principales cambios en CMMI V1.3 son el soporte de Desarrollo de Software Ágil, las mejoras en las prácticas de alta madurez y la alineación de la representación.
NIVELES DE CMMI
NIVEL 1 (INICIAL). Este es el nivel en donde están todas las empresas que no tienen procesos. Los presupuestos se disparan, no es posible entregar el proyecto en fechas, te tienes que quedar durante noches y fines de semana para terminar un proyecto. No hay control sobre el estado del proyecto, el desarrollo del proyecto es completamente opaco, no sabes lo que pasa en él.
NIVEL 2 (REPETIBLE). Quiere decir que el éxito de los resultados obtenidos se pueden repetir. La principal diferencia entre este nivel y el anterior es que el proyecto es gestionado y controlado durante el desarrollo del mismo. El desarrollo no es opaco y se puede saber el estado del proyecto en todo momento.
NIVEL 3 (DEFINIDO). Resumiéndolo mucho, este alcanzar este nivel significa que la forma de desarrollar proyectos (gestión e ingeniería) está definida, por definida quiere decir que está establecida, documentada y que existen métricas (obtención de datos objetivos) para la consecución de objetivos concretos.

25. NIVEL 4 (CUANTITATIVAMENTE GESTIONADO). Los proyectos usan objetivos medibles para alcanzar las necesidades de los clientes y la organización. Se usan métricas para gestionar la organización.
NIVEL 5 (OPTIMIZADO). Los procesos de los proyectos y de la organización están orientados a la mejora de las actividades. Mejoras incrementales e innovadoras de los procesos que mediante métricas son identificadas, evaluadas y puestas en práctica.

26. CONCLUSIONES
Gracias a las normas y estándares aplicados a proyectos TI y de calidad para el desarrollo de software hoy en día se nos puede facilitar la realización de los proyectos ya que con las normas podemos seguir ciertos pasos para que los proyectos sean más eficientes y más fáciles de realizarlos paso a paso y los estándares nos especifican que el desarrollo de un proyecto debe ser de calidad, el cual debe satisfacer las necesidades del cliente o de la empresa a la que se le esté desarrollando dicho software. Por otra parte el CMMI nos ayuda a mejorar los procesos de construcción de software y de proyectos de TI, el estándar IEEE nos brinda una serie de documentación el desarrollo de software y proyectos de TI. Por último la aplicación de una norma o estándar los podemos aplicar en nuestros proyectos de acuerdo a la necesidades de dicho proyecto.