Calidad en TI

Universidad Tecnológica de Puebla

Antología:

Sistemas de Calidad en Tecnologías de la Información

Versión 1. 0.0 Cuatrimestre: Septiembre Diciembre 2009

Sistemas de Calidad en Tecnologías de la Información Versión: 1.0.0 Página 2 de 59

Ingeniería en Tecnologías de la Información y Comunicación

Introducción

Desde el enfoque tradicional de calidad que había sido centrarse únicamente en tratar de evitar que se produjesen fallos durante la fabricación, se evolucionó según tres etapas: Control de calidad, Aseguramiento de la calidad, Gestión de la calidad total I. Control de Calidad El control de calidad apareció en los años 30 y adquirió gran importancia en los 50 y 60. Se centra en inspeccionar el producto y separar aquel que es aceptable (de acuerdo a unos determinados estándares) del que no lo es.

Se tiende a considerar como una actividad a posteriori, es decir, que sirve para detectar si se han alcanzado los niveles de calidad y tomar las medidas oportunas si no ha sido así, pero sin embargo se pueden realizar controles antes, durante y después de haber obtenido los resultados instalando sensores en aquellas fases que se quieren controlar. Lógicamente, cuantos más controles se instalen más se incrementaran en los costes derivados de dicho control.

Figura “Representación esquemática del proceso de control de calidad”

El departamento de control de calidad era el encargado de la de realizar esta tarea, de modo que los demás miembros de la organización no se consideraban directamente responsables de la calidad.

II. Gestión de la calidad total

En esta etapa el objetivo es proporcionar productos o servicios capaces de satisfacer al cliente, algo que depende de la diferencia entre sus percepciones y sus expectativas. Esta nueva concepción de la calidad presenta importantes implicaciones.

1. Está relacionada con las percepciones del cliente, que en gran medida son subjetivas. 2. Es un concepto dinámico, ya que es preciso adaptarse constantemente a las cambiantes

necesidades de los clientes. 3. Al considerar el valor percibido, el precio se incorpora también al concepto de calidad ya que es

un factor que influye tanto en las expectativas que se formará el comprador (se tiende a asociar instintivamente alto precio y alta calidad) como en su posterior juicio del producto o servicio (¿mereció la pena pagar ese precio?)

En esta etapa aparece la necesidad de implicar a todos los miembros de la organización en el compromiso con la calidad, es decir, la calidad debe impregnar a todas las áreas de la organización.



Los objetivos que se persiguen con las políticas de gestión de la calidad son:

1. Satisfacción del cliente. Constituye el objetivo prioritario. 2. Conseguir hacer las cosas bien a la primera. 3. Eliminar todo aquello que no añada valor. Evitar despilfarros. 4. Mejorar la capacidad de reacción del sistema mediante:

• Productos y servicios personalizados. • Desarrollo rápido de nuevos productos y servicios. • Anticipación a las necesidades del cliente.

Como definición de Gestión de la Calidad Total (GCT) puede por tanto darse la siguiente: es el conjunto de actividades extendidas a todas las áreas, operaciones, procesos y departamentos de una organización (es decir, extendidas a toda la organización) que tiene como objetivo enviar productos o servicios libres de defectos, en el plazo requerido y que satisfagan plenamente a los clientes, así como elevar el nivel de calidad de todas las operaciones de la empresa, y que se consigue con un claro compromiso de la dirección y a través de una completa participación de todos los empleados.

Principios de la gestión de la calidad Existe abundante documentación que trata sobre los principios que rigen a la gestión de la calidad, aunque la esencia es la misma en casi todos los autores. Quizá la enumeración más conocida sea la de los catorce puntos de Deming. Se puede decir que la GCT se sustenta en cuatro pilares fundamentales, que son los siguientes:

1. Énfasis en el cliente 2. Participación de todo el personal. Es el operario quien identifica las fuentes de variación y

propone mejoras; se hace responsable de su trabajo. 3. Mejora de los procesos. Se identifican y corrigen sistemáticamente las fuentes de variación. Se

ve en la calidad una oportunidad para reducir los costes y, adicionalmente, aumentar la flexibilidad y disminuir los plazos.

4. Mejora continua. Debe incorporarse a todas las áreas de la organización Los dos primeros aspectos estaban ya presentes en la etapa de aseguramiento de la calidad, pero los dos últimos son exclusivos de la GCT.

III. Aseguramiento de la calidad

El aseguramiento de la calidad son todas aquellas acciones, llevadas cabo sistemáticamente, que están destinadas a obtener un proceso productivo que asegure que el producto o servicio satisfará los requerimientos de calidad. En definitiva, la filosofía que sustenta esta etapa es que la calidad se construye en los procesos: si cada proceso se realiza correctamente, no existe ningún motivo para que aparezcan defectos y, en consecuencia, no será necesario controlar la calidad del producto obtenido. La cultura de la empresa incorpora la idea de hacer las cosas bien a la primera. Un elemento característico del aseguramiento de la calidad es el Manual de Calidad, en el que se recogen los procedimientos adecuados para realizar cada proceso, y se incluyen todas las actividades en todas las etapas hasta la obtención del producto final. Podríamos decir que el este manual es “la Biblia del sistema de aseguramiento de la calidad”.



Para que el sistema pueda ser certificado por terceros ha de estar elaborado de acuerdo a normas establecidas, como la serie ISO 9000. Una vez desarrollado el sistema de acuerdo a alguna de estas normas, existen autoridades de certificación que evalúan dicho sistema y en caso de cumplir los requerimientos de calidad necesarios, certifican a la organización. El objetivo de la certificación es doble:

1. Alcanzar y mantener la calidad del producto o servicio para satisfacer al cliente. 2. Proporcionar garantías al cliente de que el producto o servicio que se le ofrece cumple unos

determinados estándares de calidad. La vigilancia de que el proceso se realice de acuerdo al procedimiento establecido es responsabilidad de los auditores de calidad. Pueden distinguirse tres pasos fundamentales que en el aseguramiento de la calidad.

1. Establecer un sistema y evaluar su adecuación. De esta manera se obtiene el Manual de Calidad.

2. Auditar el sistema para verificar que las disposiciones se están implementando. 3. Revisar el sistema de manera continua, de forma que se compruebe que se sigue trabajando del

modo adecuado y que el producto tiene las características prescritas. El papel de los especialistas del departamento de calidad se centra en realizar auditorías de calidad para comprobar que el personal actúa de la manera prevista. Aunque el aseguramiento de la calidad supone algunas mejoras respecto al control de calidad tradicional, siguen existiendo problemas:

1. Sigue sin desarrollarse una actividad de mejora. Dado que existen unos procedimientos claramente definidos, cualquier cambio supone un riesgo.

2. El tener unos procedimientos formales tan definidos limita de manera considerable la creatividad del personal.

3. Se da por sentado que el cliente se siente satisfecho por recibir su pedido de acuerdo a lo que especificó, cuando realmente el realizar la entrega conforme a lo pactado es algo que el cliente suele dar por supuesto, por lo que no contribuye significativamente a su satisfacción y fidelización.

Control de calidad Aseguramiento de la

calidad GCT

Concepto de calidad Conformidad con las especificaciones

Aptitud para el uso Satisfacción del cliente

Orientación de la empresa

Producción Producción Cliente

Responsabilidad de la calidad

Depto. de calidad Depto. de calidad + operarios

Todos los miembros

Se actúa porque... Se detecta un error Se intenta evitar el error Hay objetivos Aplicación de la calidad Al producto Al proceso productivo A todos los procesos de la

empresa Actuación

Corregir el error Modificar el procedimiento Mejora continua

Actitud

Reactiva Reactiva Proactiva

Participación del personal

Sólo Depto. de calidad Depto. de calidad + operarios

Toda la empresa

Importancia de la participación

No se espera participación Importante Imprescindible

Generación de valor añadido

No está claro Si Si

Materialización

Plan de inspección Manual de calidad Sistema de gestión

Filosofía

Arreglo Prevención Mejora



Existen entidades internacionales reconocidas, que se preocupan por realizar metodologías, normas, estándares, modelos y/o directrices, enfocados a los desarrolladores como a los adquisidores de software. Entre las principales se puede mencionar a: SEI (Software Engineering Institute - Instituto de Ingeniería de Software), IEEE (Institute of Electrical and Electronics Engineers - Instituto de Ingenieros Eléctricos y Electrónicos), ISO (International Organization for Standarization - Organización Internacional de Estandarización) y también SPICE (Software Process Improvement and Capability dEtermination – Mejoramiento de procesos de Software y determinación de capacidad). La ISO presenta una colección de estándares enfocados a la calidad, siendo la ISO 9001 la que esta orientada al software en lo que se refiere al desarrollo y manutención, y adicionalmente forma parte de la serie ISO 9000. La ISO 9000-3 (IBNORCA 1998) del año 1997 es una guía al aplicar ISO 9001 del año 1994 para el desarrollo, provisión y mantenimiento de software. Esta experimento nuevas versiones como es el caso de ISO 90003 del año 2004 (ISO/IEC 2004) que es la guía de aplicación de la ISO 9001 del año 2000 para software de computadora. Otro estándar relacionado al software es la ISO/IEC 12207:1995 (ISO/IEC 1995) que establece un marco de referencia común para los procesos del ciclo de vida del software. Dentro de los desarrollos del SEI podemos describir a SW-CMM (SEI 1993) (Software Capability Maturity Model - Modelo de Madurez de Capacidad de Software), SA-CMM (SEI 2002a)(Software Acquisition Capability Maturity Model - Modelo de Madurez de Capacidad para la Adquisición de Software), CMMI (SEI 2002b, SEI 2002c) (Capability Maturity Model Integrated - Modelo de Capacidad de Madurez Integrado) y CMMI – AM (SEI 2005) (CMMI Adquisition Module -l Modulo de Adquisición para CMMI). El IEEE presenta muchos estándares relacionados o involucrados con la calidad de software como son: 610.12-1990 que es el glosario estándar de terminología de ingeniería de software, 730-1998 que es el estándar para planes de seguridad de calidad de software, 829-1998 estándares para documentar la evaluación de software, 830-1998 practicas recomendadas para especificación de requerimientos de software, 1012-1998 estándar para la verificación y validación de software, 1016-1998 practicas recomendadas para la descripción de diseño de software, 1062a-1998 practicas recomendadas para la adquisición de software y muchas otras más. Otro estándar importante es SPICE (Software Process Improvement and Capability dEtermination) que también es conocido como ISO/IEC 15504 es un modelo de madurez de procesos internacional que proporciona un marco de trabajo para la evaluación de procesos de software.



Unidad I

Normas y estándares en proyectos de T.I.

1.1 ISO

1.1.1 ISO 9001 ISO 9001 es un conjunto estándares internacionales para sistemas de calidad. Diseñado para la gestión y aseguramiento de la calidad, especifica los requisitos básicos para el desarrollo, producción, instalación y servicio a nivel de sistema y a nivel de producto. Su primera publicación fue en 1987, revisado en 1994 y actualizado en el año 2000 (con el compromiso de hacer una revisión cada 5 años). La primera versión de 1994 establecía un conjunto básico de requisitos para el establecimiento y mantenimiento de la gestión del sistema y aseguramiento de la calidad de la ingeniería de software. Se concibe como una metodología de procesos basada en una lista de comprobaciones o requisitos a cumplir, umbral de calidad, valorado apto o no apto. Y esta simplicidad es lo que lo ha hecho mundialmente extendido. La retroalimentación de los usuarios, el desarrollo de los modelos de evaluación y mejora continua y las críticas especializadas hacen que se requiera un estándar que:

• Emplee una aproximación de gestión basada en el proceso. • Sea compatible con otros sistemas de gestión. • Incluya requisitos papa la mejora continua del sistema de calidad. • Coincida con las necesidades de los participantes externos. • Sea amigable al usuario y al cliente.

La nueva familia de estándares es la siguiente:

• ISO 9000, Normas para la gestión y garantía de la calidad. • ISO 9001, Modelo para la garantía de la calidad en diseño/desarrollo, producción, instalación y

servicio. • ISO 9002, Modelado para garantizar la calidad en producción y servicios. • ISO 9003, Modelos para garantizar la calidad en inspección final y pruebas. • ISO 9004, Elementos y gestión del sistema de calidad, Directrices para la mejora del

rendimiento. • ISO 9011, Directrices para la auditoria de los sistemas de gestión de la calidad y/o ambiental.

ISO 9001 e ISO 9004 se han desarrollado como un par coherente de normas, complementándose. Mientras ISO 9001 se centra en la eficacia del sistema de gestión de la calidad para dar cumplimiento a los requisitos del cliente, ISO 9004 se recomienda para organizaciones que persiguen la mejora continua, sin afán certificador. El estándar se basa en un conjunto de Principios de Gestión de la Calidad: Enfoque al cliente, Liderazgo, Implicación de todo el personal, Enfoque a procesos, Enfoque del sistema hacia la gestión, Mejora continua, Enfoque objetivo hacia la toma de decisiones y Relaciones mutuamente beneficiosas con los proveedores.



Las cinco secciones en que se divide ISO 9001:2000 son:

1. QMS Sistema de Gestión de la Calidad (Requisitos generales y Requisitos de la documentación) 2. Responsabilidad de la Gestión (Compromiso de la dirección, Enfoque al cliente, Política de la

calidad, Planificación,…). 3. Gestión de los Recursos (Provisión de recursos, Recursos humanos, Infraestructura, Ambiente

de trabajo). 4. Realización del Producto (Planificación de la realización del producto, Procesos relacionados con

los clientes, Diseño y desarrollo, Compras, Prestación del servicio). 5. Medición Análisis y Mejora (Generalidades, Supervisión y Medición, Control de servicio no-

conforme, Análisis de datos, Mejora). Cabe mencionar que el enfoque de ISO 9000 está en los procesos de “producción”, o sea de desarrollo en el caso de software. El fin de este tipo de estándar es un mejor proceso, y no un mejor producto, excepto como consecuencia de mejores procesos.

1.1.2 ISO 9126

La ISO, bajo la norma ISO-9126, ha establecido un estándar internacional para la evaluación de la calidad de productos de software el cual fue publicado en 1992 con el nombre de “Information tecnology – Software product evaluation: Quality characteristics and guidelines for their use“, en el cual se establecen las características de calidad para productos de software. El estándar ISO-9126 establece que cualquier componente de la calidad del software puede ser descrito en términos de una o más de seis caracteristicas básicas, las cuales son: funcionalidad, con fiabilidad y portabilidad; cada una de las cuales se detalla a través de un conjunto de subcaracterísticas que permiten profundizar en la evaluación de la calidad de productos de software. La tabla 1.1 muestra la pregunta central de atiende cada una de estas características.

Características Pregunta central

Funcionalidad ¿Las funciones y propiedades satisfacen las necesidades explícitas e implícitas; esto es, el que . . .?

Confiablidad ¿Puede mantener el nivel de rendimiento, bajo ciertas condiciones y por cierto tiempo?

Usabilidad ¿El software es fácil de usar y de aprender? Eficiencia ¿Es rápido y minimalista en cuanto al uso de recursos? Mantenibilidad ¿Es fácil de modificar y verificar? Portabilidad ¿Es fácil de transferir de un ambiente a otro?

Tabla 1.1. Caracteristicas de ISO-9126 y aspecto que atiende cada una. 1.1.3 ISO 15540 (SPICE, Software Process Improvement and Capability Determination) ISO/IEC 15504 es un emergente estándar internacional de evaluación y determinación de la capacidad y mejora continua de procesos de ingeniería del software, con la filosofía de desarrollar un conjunto de medidas de capacidad estructuradas para todos los procesos del ciclo de vida y para todos los participantes. Es el resultado de un esfuerzo internacional de trabajo y colaboración y tiene la innovación, en comparación con otros modelos, del proceso paralelo de evaluación empírica del resultado. En 1991, ISO/IEC JTC1/SC7 aprueba un estudio para investigar la necesidad y los requisitos para un estándar de evaluación del proceso software, llegando a la conclusión (1992) de que había consenso internacional. El proceso de desarrollo y validación empírica (proyecto SPICE) se ha alargado diez años. En 1998 se publica la primera versión del estándar como Informe Técnico (en 1995 se publica como ‘borrador’), evolucionando posteriormente hasta Estándar Internacional, con la realización de tres fases



de pruebas, la Fase 1 (1995) con la idea de validar la decisiones de diseño y usabilidad del borrador, la Fase 2 (1996-1998) que a los objetivos anteriores sumaba proveer de una guía de aplicación y revisar la consistencia, validez, adecuación, usabilidad y portabilidad de SPICE. La Fase 3 (hasta marzo de 2003, en que se cierra el proyecto SPICE) se realiza con la idea de aportar entradas y publicar el estándar ISO. Tras los Trials comienza la fase de Benchmarking (actual fase), con la idea de recolectar datos de los procesos de evaluación y analizarlos y comienza la publicación de partes del estándar. La versión 1.0 inicialmente recogía treinta y cinco procesos agrupados en cinco categorías (Cliente-Proveedor, Ingeniería, Proyecto, Soporte y Organización). Sin embargo, la idea de expandir el ámbito de aplicación del estándar evitando restringirlo a un determinado ciclo de vida, la compatibilidad con ISO/IEC 12207 e ISO/IEC 15288 y con cualquier modelo posterior, permite la evolución del estándar para aceptar Modelos de Referencia de Procesos (PRM’s) eliminando la inicial dimensión de procesos. La medida de capacidad (véase tabla 1.2), es aplicable a cualquier modelo de procesos plasmado en un PRM compatible con ISO 12207. Esto le confiere una infraestructura mucho más abierta, facilitando la compatibilidad. 2 Id. Nivel de Capacidad Atributos de Proceso y Descripción

Id Nivel de Capacidad

Atributos de Proceso y Descripción

CL[0]

Incompleto

El proceso no está implementado o falla en alcanzar su propósito. No es fácil identificar los productos o salidas de los procesos.

CL[1]

Realizado

El propósito del proceso se logra generalmente, aunque no sea rigurosamente planificado ni llevado a cabo. Hay productos identificables que testifican el alcance del propósito.

PA.1.1 Realización del Proceso

CL[2]

Gestionado El proceso es gestionado y los entregables resultado de procedimientos específicos, planificados y seguidos, con requisitos de calidad, tiempo y recursos.

PA.2.1 PA.2.2

Gestión de la Realización Gestión de los Productos del trabajo

CL[3]

Establecido Un proceso realizado y gestionado usado un proceso definido, basado en un principio de buenas prácticas de ingeniería del software.

PA.3.1 PA.3.2

Definición del Proceso. Despliegue del Proceso.

CL[4] Predecible El proceso definido es puesto consistentemente en práctica dentro de límites de control establecidos para alcanzar metas del proceso ya definidas. Entendimiento cuantitativo de la capacidad del proceso y habilidad mejorada de predecir y gestionar el rendimiento

PA.4.1 PA.4.2

Medición del Proceso Control del Proceso

CL[5]

En optimización

Realización del proceso optimizada en la busqueda de las necesidades actuales y futuras del negocio. Objetivos cuantitativos de eficiencia y efectividad se establecen en función de los objetivos de la organización. Optimización puede llevar a estudiar y adoptar ideas innovadoras o productos tecnológicos novedosos que incluyan y modifiquen el proceso definido

PA.5.1 PA.5.2

Innovación del Proceso. Optimización del proceso

Tabla 1.2. Modelo de Capacidad de Procesos.



1.2 CMMI (Modelo de Capacidad de Madurez de Integración)

Anthony Finkelstein describió que hay organizaciones que no han alcanzado siquiera el nivel 1 de CMM (en el que aunque sea de modo heroico se llega a producir software), proponiendo que existen niveles negativos o de inmadurez. Este «Modelo de Incapacidad e Inmadurez», que fue refinado posteriormente por Tom Schorsch, incluye tres niveles de idiotez o Inmadurez: 0 – Tonto o Nulo. Organizaciones negligentes. Impiden cualquier desarrollo de software con éxito. Su

gran preocupación es la reutilización del software.

1 - Estúpido. Organizaciones obstructivas. Imponen procesos contra-productivos para impedir cualquier

avance. Se concentran en desarrollar entornos de desarrollo y repositorios.

2 – Lunático o Despectivo. Organizaciones desdeñosas. Desprecian cualquier institucionalización de

buenas prácticas. Su gran objetivo es la programación automática.

3 – Sabotaje. Negligencia total, descrédito consciente de los esfuerzos de su propia gente en la mejora

de proceso del software. Falta de recompensa y degradación de las prestaciones.

A continuación se presentan algunos puntos clave para poder identificar si una organización se encuentra dentro de un nivel de capacidad de Inmadurez o dentro de un Nivel de Capacidad de Madurez.

Proceso Inmaduro Proceso Maduro

Personal. No está documentado. No es fácil reproducirlo en nuevos proyectos. No hay entrenamiento. No todo el mundo lo conoce. No se mide. Se aplica a veces solamente. Es percibido como poco eficiente. No se cumplen los tiempos de entrega. Se exceden los presupuestos.

Es definido: Sistemático. Es documentado, publicado, aprobado y accesible. El personal ha sido entrenado: Ingenieros y gerencia (conocen el proceso). Es practicado: Se utiliza en forma cotidiana. Es apoyado: Gerencia asigna responsables. Es mantenido: es revisado para que cumpla los requisitos. Es controlado: las actualizaciones son notificadas a la empresa. Se verifica: los proyectos siguen el proceso establecido. Se valida: el proceso mantiene coherencia con los requerimientos y estándares. Se mide: utilización, beneficios y rendimiento se cuantifican. Puede mejorarse: existe el mecanismo para la mejora continua.



1.2.1 Los Cinco Niveles De Madurez En Los Procesos De Creación Del Software

El departamento de defensa de los Estados Unidos tenía muchos problemas con el software que encargaba desarrollar a otras empresas, los presupuestos se disparaban, las fechas alargaban más y más. ¿Quién no se ha encontrado con este tipo de problemas si ha trabajado con una empresa de software? Como esta situación les parecía intolerable convocó un comité de expertos para que solucionase estos problemas, en el año 1983 dicho comité concluyó "Tienen que crear un instituto de la ingeniería del software, dedicado exclusivamente a los problemas del software, y a ayudar al Departamento de Defensa".

Convocaron un concurso público en el que dijeron: "Cualquiera que quiera enviar una solicitud tiene que explicar como van a resolver estos 4 problemas", se presentaron diversos estamentos y la Universidad Carnegie Mellon ganó el concurso en 1985, creando el SEI. El SEI (Software Engineering Institute) es el instituto que creó y mantiene el modelo de calidad CMM. El “nacimiento” de CMM se da en el año de 1986 cuando el Software Engineering Institute (SEI) junto con MITRE Corporation, buscaron mejorar el proceso de software y desarrollaron un marco de trabajo que llamaron proceso de madurez. Este proceso fue desarrollado por Watts S. Humphrey en 1986 y está basado en el concepto de la administración de la calidad total Total Quality Management (TQM) por sus siglas en inglés. El modelo de capacidad de madurez (CMM), provee a las organizaciones de software una guía de cómo aumentar el control de sus procesos de desarrollo y mantenimiento de software. Fue diseñado para guiar a las organizaciones de software en la selección de estrategias para el mejoramiento de procesos mediante la determinación de la madurez de los procesos actuales e identificando los elementos más críticos de la calidad de software y del mejoramiento de procesos.

La arquitectura del modelo está compuesta por niveles que describen la madurez de la organización y por áreas claves de procesos KPAs (Key Process Areas). Los diferentes niveles permiten medir la madurez del proceso y evaluar el potencial de él, como también ayudan a una organización a priorizar sus esfuerzos de mejoramiento. Éste concepto cuenta con cinco etapas evolutivas que se enfocan en la implementación de prácticas de calidad. CMM es, en pocas palabras, una aplicación de TQM para software

Niveles de

madurez

Áreas Claves

Nivel 1

Inicial

Ninguna

Nivel 2

Repetible

Gestión de configuraciones Garantía de calidad Gestión subcontratación del software Seguimiento y supervisión del proyecto Planificación del proyecto Gestión de requisitos

Nivel 3

Definido

Revisiones periódicas Coordinación entre grupos Ingeniería de productos de software Gestión de integración del software Programa de formación Definición de procesos de la organización



Enfoque del proceso de la organización

Nivel 4

Gestionado

Gestión de calidad de software Gestión cualitativa del proceso

Nivel 5

Optimizado

Gestión de cambios del proceso Gestión de cambios de tecnología Prevención de defectos

Para cada área de proceso define un conjunto de buenas prácticas que habrán de ser:

• Definidas en un procedimiento documentado • Provistas (la organización) de los medios y formación necesarios • Ejecutadas de un modo sistemático, universal y uniforme(institucionalizadas) • Medidas • Verificadas

CMM: un modelo para la mejora de Procesos de SoftwareCMM: un modelo para la mejora de Procesos de SoftwareCMM: un modelo para la mejora de Procesos de SoftwareCMM: un modelo para la mejora de Procesos de Software

Objetivo: Mejorar la calidad de los procesos de desarrollo, gestión y mantenimiento de software Para conseguirlo se aplican las bases de la Gestión de la Calidad Total (Total Quality Management) en la Ingeniería del Software.

• Mejora la gestión de la calidad es, en gran medida, responsabilidad de la dirección • La mejora de la calidad debe basarse en mejorar los procesos y no en las

personas • Hay que medir la mejora de la calidad • Se necesitan incentivos para mantener un esfuerzo de mejora • La mejora de la calidad es un proceso continuo

Después de cuatro años de experiencia con la madurez del proceso de software, el SEI evolucionó la madurez y publicó Capability Maturity Model for Software (CMM).En diciembre de 2000, el SEI publicó un nuevo modelo, el CMMI o "Modelo de Capacidad y Madurez - Integración", éste describe un camino de mejoramiento evolutivo para pasar desde un proceso inmaduro a un proceso maduro y disciplinado, basado en conocimientos adquiridos de evaluaciones de los procesos de software y extensos feedback. Por lo tanto, las disposiciones del CMM son definitivamente aplicables a todo aquello que esté directamente relacionado con el desarrollo y mantenimiento de sistemas informáticos.

CMMI define un conjunto de áreas clave del proceso, que describen las funciones de ingeniería del software que deben llevarse a cabo para el desarrollo de una buena práctica, agrupadas en cinco niveles inclusivos. Estos niveles sirven de referencia para el conocimiento del estado de la madurez del proceso del software en la organización. Mediante un amplio conjunto de métricas se determina la calidad de cada una de las áreas clave, obteniéndose una visión precisa del rigor, la eficacia y la eficiencia de la metodología de desarrollo de una organización productora de software.



Cada una de las áreas está organizada en cinco secciones, denominadas características comunes. Todo esto con el objetivo de realizar algunas mejoras respecto al CMMI (SW-CMM)

1.2.2 Características comunes:

• Compromiso de realización

• Capacidad para llevarla a cabo

• Actividades que hay que realizar

• Medición y análisis

• Verificación de la implementación



1.3 IEEE (Instituto de Ingenieros en Electricidad y Electrónica)

Fundado en 1884, el Instituto de Ingenieros en Electricidad y Electrónica, Inc. (IEEE) se ha dedicado a ayudar a que más de 320,000 profesionales y estudiantes de Ingeniería desarrollen su potencial en campos de la ingeniería eléctrica. Es una asociación técnico-profesional mundial dedicada a la estandarización, entre otras cosas. Es la mayor asociación internacional sin fines de lucro formada por profesionales de las nuevas tecnologías.

Objetivos:

Científicos / Educativos: Promover el avance de las teorías y las prácticas de la electro- tecnología. Profesionales: Fomentar el progreso y el desarrollo profesional de su membresía. Con la sociedad: Mejorar la calidad de vida a través de la aplicación de la electro tecnología. Promover el entendimiento de la electro tecnología ante el público.

Mediante sus actividades de publicación técnica, conferencias y estándares basados en consenso, el IEEE produce más del 30% de la literatura publicada en el mundo sobre ingeniería eléctrica, en computación, telecomunicaciones y tecnología de control, organiza más de 350 grandes conferencias al año en todo el mundo, y posee cerca de 900 estándares activos, con otros 700 más bajo desarrollo. Su organización se ha hecho de manera regional dividida de la siguiente manera:

10 Regiones

17 Consejos

311 Secciones

34 Sub-secciones

1,570 Capítulos Técnicos

217 Grupos Afines

1,434 Ramas Estudiantiles

382 Capítulos Técnicos de Ramas Estudiantiles

60 Grupos Afines de Ramas Estudiantiles Dentro de los Capítulos Técnicos más importantes se encuentran los siguientes:

1. Circuitos y Sistemas 2. Comunicaciones 3. Computación 4. Educación 5. Compatibilidad Electromagnética 6. Dispositivos Electrónicos 7. Ingeniería en Medicina y Biología 8. Gerencia de Ingeniería 9. Electrónica Industrial 10. Aplicaciones Industriales



11. Ingeniería de Potencia 12. Comunicación Profesional

El IEEE promueve la creatividad, el desarrollo y la integración, compartir y aplicar los avances en las tecnologías de la información, electrónica y ciencias en general para beneficio de la humanidad y de los mismos profesionales. Como parte de los Capítulos Técnicos están los estándares y en software algunos de estos son:

IEEE Std. 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology IEEE Std. 1016-1998 IEEE Recommended Practice for Software Design Descriptions IEEE Std. 1471-2000 IEEE Recommended Practice for Architectural Description of Software

Systems IEEE Std. 1012-1998 IEEE Standard for Software Verification and Validation IEEE Std. 1008-2002 IEEE Standard for Software Unit Testing IEEE Std. 1058-1998 IEEE Standard for Software Project Management Plans IEEE Std. 730-1998 IEEE Standard for Software Quality Assurance Plans IEEE Std. 830-1998 IEEE Recommended Practice for Software Requirements Specifications

1.3.1 Planificación del aseguramiento de la calidad en un proyecto

Siguiendo el estándar IEEE (Std 1074/ 1991, estándar para el desarrollo de software ciclo de procesos), al iniciar un proyecto software hay que:

1. Seleccionar uno o varios del ciclo de vida, y concretarlo luego en uno determinado para dicho proyecto.

2. Definir los aspectos relacionados con la financiación y viabilidad del proyecto 3. Definir las metodologías, técnicas y herramientas a utilizar 4. Planificar la gestión del proyecto de software

Planificación de Gestión del Proyecto de incluir y describir: • El día a día del proyecto, con los correspondientes controles de auditorías y revisiones. • La planificación del aseguramiento de la calidad del software (SQA) • La planificación de la documentación del proyecto.

A partir del plan de gestión, se genera el plan de Aseguramiento de la calidad del software.

1.3.2 El plan de Aseguramiento de la calidad del software. Este plan es específico para cada proyecto, siguiendo las directrices del MANUAL DE CALIDAD y de sus procedimientos y las normas requeridas por los clientes. Siguiendo el estándar 730/1984 (Estándar para planes de aseguramiento de la calidad del software), el plan debe incluir:

• Objetivos de la calidad del proyecto y enfoque adaptado para alcanzarlos • Documentación referenciada en el plan (manual, procedimiento, etc.) • Gestión del aseguramiento de la calidad (organización, actividades y responsabilidades). • Documentación mínima exigida a los desarrolladores tanto del desarrollo del software

(especificaciones, diseño, manuales de usuario, etc.) como de control (planes validación y verificación).

• Estándares que se deben aplicar obligatoriamente • Actividades de revisión y auditoria. • Gestión de la configuración del software (mediante un plan de gestión específico o describiendo

sus actividades).



• Informes de problemas, especificando la forma de tratar y corregir los problemas y los responsables que han de hacerlo

• Herramientas para apoyar el aseguramiento de la calidad (revisiones, inspecciones, analizadores de código, generadores de entornos de prueba, etc.), especificando sus objetivos y la manera de utilizarlas.

• Control de código (almacenamiento y versiones), control de acceso a equipos y prevenciones de seguridad y control de las características del software de los suministros.

• Recogida, almacenamiento y mantenimiento de datos sobre el aseguramiento de la calidad.

Actividades de aseguramiento de la calidad. Según el estándar IEEE 1074/1991, las técnicas para el aseguramiento de la calidad son, principalmente tres:

1. Métricas del software para controlar el proyecto 2. Verificación y validación del software (incluyendo pruebas y revisiones) en todas las fases del

ciclo de vida 3. Gestión de la configuración del software.

1.4 PSP (Personal Software Process) ¿Cómo se desarrollo el PSP? Después de que Watts S. Humphrey condujera el desarrollo inicial de CMM para software, se decidió a aplicar los principios de CMM a los programas pequeños. Posteriormente, mucha gente preguntaba cómo aplicar CMM a las organizaciones pequeñas o al trabajo de los equipos pequeños de software. Mientras que los principios de CMM se aplicaron a tales grupos, cada vez se volvía más necesaria la asesoría para saber qué hacer. Fue entonces cuando Humphrey decidió personalmente utilizar los principios de CMM para desarrollar programas modulares para ver si dicho enfoque podría funcionar para convencer a los ingenieros de software a que adoptaran tales prácticas. Fue entonces en el desarrollo de estos programas modulares, cuando Humphrey utilizó personalmente todas las prácticas de CMM para que él subiera poco a poco hasta llegar al nivel 5. Poco después él comenzó a trabajar en el proyecto tiempo completo en abril de 1989, el Instituto de la Ingeniería de Software (SEI) hizo a Humphrey un colaborador del SEI, permitiéndole trabajar tiempo completo en la investigación detallada de PSP. Durante los siguientes tres años, él desarrolló un total de 62 programas y definió cerca de 15 versiones de PSP. Utilizó los siguientes lenguajes de programación: PASCAL y C++, para desarrollar cerca de 25.000 líneas de código que ayudarían a darle la forma final a PSP. [SEI; 2002] De esta experiencia, él concluyó que los principios de la administración de procesos que desarrolló Deming y de Juran eran totalmente aplicables tanto al trabajo de los ingenieros de software de manera individual como a ingenieros enfocados al trabajo en equipo, el resultado? Proceso en equipo de software (TSP) Humphrey después escribió un libro que les proporcionó a varios asociados el material necesario para enseñar cursos de PSP. En septiembre de 1993, Howie Dow enseñó el primer curso de PSP a cuatro estudiantes graduados en la Universidad de Massachusetts. Humphrey también enseñó el curso de PSP durante el semestre del invierno de 1993-1994 en la universidad de Carnegie Mellon, al igual que Nazim Madhavji en la Universidad McGill y Soheil Khajanoori lo enseñó en la Universidad Aeronáutica de Embry. De acuerdo con las experiencias y los



datos que proporcionaron estos cursos, Humphrey realizó la revisión del libro de PSP y publicó la versión final a finales de 1994. [HUMPHREY; 95 ] Casi al mismo tiempo, Jim Over y Neil Reizer del SEI y Robert Powels de la compañía de Servicios Informativos Avanzados (AIS por sus siglas en inglés) desarrollaron el primer curso para entrenar a los instructores a enseñar el curso de PSP en la industria. Humphrey junto con el SEI han continuado trabajando en el desarrollo de PSP y así mismo han aplicado los mismos principios al Proceso en Equipo de Software o TSP. ¿Qué es el PSP?

• Un PSP es un proceso personal desarrollar software que tiene:

1. pasos definidos

2. formularios

3. estándares

• Un PSP es un marco de trabajo de medición y análisis que te ayuda a caracterizar tu proceso.

• Es también un procedimiento definido para ayudarte a mejorar tu rendimiento.

1.4.1 Principios PSP

• La calidad de un sistema software está condicionada por la calidad del peor de sus componentes.

• La calidad de un componente software está condicionada por el individuo que lo desarrolló.

• Está condicionada por tu:

1. conocimiento

2. disciplina

3. compromiso

• Como todo profesional software deberías conocer tu propio rendimiento.

• Deberías medir, seguir y analizar tu trabajo.

• Deberías aprender de tus variaciones de tu rendimiento.

• Deberías incorporar esas lecciones a tu manera personal de hacer.

El diseño de PSP se basa en los siguientes principios de planeación y de calidad [HUMPHREY; 95]

• Cada ingeniero es esencialmente diferente; para ser más precisos, los ingenieros deben planear su trabajo y basar sus planes en sus propios datos personales.

• Para desarrollar productos de calidad, los ingenieros deben sentirse personalmente comprometidos con la calidad de sus productos.



• Para hacer un trabajo de ingeniería de software de la manera correcta, los ingenieros deben planear de la mejor manera su trabajo antes de comenzarlo y deben utilizar un proceso bien definido para realizar de la mejor manera la planeación del trabajo.

• Para que los desarrolladores lleguen a entender su funcionamiento de manera personal, deben medir el tiempo que pasan en cada proceso, los defectos que inyectan y remueven de cada proyecto y finalmente medir los diferentes tamaños de los productos que llegan a producir.

• Finalmente, deben analizar los resultados de cada trabajo y utilizar estos resultados para mejorar sus procesos personales

1.4.2 Estructura del PSP

• El PSP se aplica en tareas personales estructuradas:

1. Desarrollo de módulos de programas.

2. Definición de requisitos o procesos.

3. Realización de revisiones o pruebas.

4. Escritura de documentación, etc.

5. El PSP se puede extender al desarrollo de sistemas software de gran tamaño.

6. Es un proceso de Nivel 5 para los individuos y es un prerrequisito para el TSP

• PSP se introduce con siete pasos compatibles.

• Escribes uno o dos pequeños programas en cada paso.

• Recoges y analizas los datos de tu trabajo.

• Los usas y analizas para mejorar tu trabajo.

• Comenzando con los requerimientos, el primer paso en el proceso de PSP es la planificación.

Existe un script de planificación que sirve de guía y un resumen del plan para registrar todos los datos del mismo. Mientras los desarrolladores van siguiendo el lineamiento de trabajo sugerido por los scripts, deben ir registrando los tiempos dedicados y los datos de defectos en los logs de tiempos y defectos. Al final de la tarea, durante la fase de postmortem (PM), deben resumir los datos de tiempo y defectos, medir el tamaño del programa, e ingresar esos datos en el formulario de sumario del plan. Al finalizar, deben entregar el producto finalizado y el formulario de sumario del plan completado.



Debido a que generalmente ciertos métodos de PSP no son utilizados por los desarrolladores, los métodos de PSP son presentados en una serie de siete versiones de procesos. Estas versiones son denominadas como PSP0 a PSP3. Cada versión tiene un mismo conjunto de logs, formularios, scripts, y standards.

• Los scripts de proceso definen los pasos de cada parte del proceso, los logs y formularios proveen templates para registrar y almacenar datos, y los standards guían a los desarrolladores a mientras hacen el trabajo.

1.4.3 Elementos del proceso

Está construido en un formato simple de utilizar con instrucciones simples y precisas. Si bien los scripts describen qué hacer, en realidad se parecen más a checklists que a tutoriales. Estos no incluyen los materiales instructivos que serían necesarios para usuarios no entrenados. El propósito de los scripts es el de guiar a los desarrolladores en el uso consistente de los procesos, los cuales ellos conocen (mediante la asistencia a cursos de capacitación en PSP o a través de bibliografía introductoria en el uso de PSP).



PSP O. Proceso (punto de partida)

• PSP0 es un proceso sencillo, definido y personal.

• Utiliza tus métodos actuales de diseño y desarrollo.

• Recoge datos sobre tu trabajo:

1. tiempo gastado por fase

2. defectos encontrados en compilación y pruebas

• Proporciona un informe resumen

El paso inicial en PSP consiste en establecer una base que incluya mediciones y un formato de reportes. Esto permite medir el progreso y define los cimientos para mejorar. Esencialmente, PSP0 es el proceso habitual con el que los desarrolladores escriben software, mejorado para proveer mediciones PSP 0.1

• Se pasa a PSP0.1 agregando un estándar de código, mediciones de tamaño y el denominado PIP (Process Improvement Proposal).

• El PIP provee una manera estructurada de registrar problemas, experiencias y sugerencias para mejorar.

• PSP0.1 también mejora las mediciones para contar separadamente métodos y procedimientos.

PSP1 Planeación personal • PSP1 le agrega pasos de planeamiento a PSP0. El primer paso agrega estimaciones de

tamaño y recursos y un reporte de prueba. • En PSP1.1 se introduce planeamiento de cronograma y seguimiento del proyecto. Los

desarrolladores son enseñados a: • Entender la relación entre el tamaño de los programas que escriben y el tiempo que les toma

desarrollarlos. • Aprender a realizar compromisos que puedan cumplir. • Preparar un plan ordenado para realizar su trabajo • Establecer una base para realizar un seguimiento de su trabajo.



Mientras que la importancia de estas técnicas en proyectos grandes es comprendida, pocos desarrolladores las aplican a su trabajo personal. PSP demuestra el valor de estos métodos en el nivel personal. PSP 2. CALIDAD PERSONAL Un objetivo de PSP es ayudar a los desarrolladores a lidiar de manera realista y objetiva con los defectos que introducen. Los programadores por lo general se avergüenzan de sus errores. El hecho de que la mayoría de los errores sean tipográficos o errores tontos hace que los desarrolladores sientan que pueden mejorar haciendo más esfuerzo. PSP2 agrega diseño personal y revisiones de código a PSP1. Estas revisiones ayudan a encontrar defectos de manera temprana y a ver los beneficios que esto proporciona. Los desarrolladores analizan los defectos que encuentran en los primeros programas y usan estos datos para establecer checklists de revisión que estén hechos a medida de su experiencia de defectos personales. El proceso de diseño es contemplado en PSP2.1. El objetivo no es decirle a los desarrolladores como diseñar sino orientar el criterio para la finalización del diseño, es decir, cuando han terminado que es lo que deben haber obtenido. Se establece un criterio de completitud de diseño y se examinan varias técnicas de verificación y consistencia de diseño. PSP3. Proceso cíclico personal Hasta este punto PSP se concentró en el proceso lineal para construcción de pequeños programas. PSP3 presenta métodos para ser usados por individuos en la realización de programas de gran escala. De todas formas sigue enfocado en el individuo y no trata los problemas de comunicación y coordinación que son una parte importante del desarrollo de sistemas de gran escala. Para escalar PSP2 a proyectos más grandes la estrategia consiste en subdividir el proceso personal de desarrollo de grandes programas en elementos en la escala de PSP2. Estos programas son entonces diseñados para ser desarrollados en pasos incrementales. La primera construcción consiste en un módulo base o kernel que es ampliado en ciclos iterativos. En cada iteración se utiliza un PSP2 completo, incluyendo diseño, codificación, compilación y pruebas.



• El proceso cíclico PSP3 puede ser un elemento efectivo en un proceso de desarrollo de gran escala solo si cada incremento sucesivo de software es de alta calidad.

• De esta manera los desarrolladores pueden concentrarse en la verificación de la calidad del último incremento sin preocuparse por defectos en ciclos anteriores.

• Si un incremento anterior tiene muchos defectos, la prueba será más compleja y los beneficios de escalar PSP se pierden. Esta es una razón para enfatizar revisiones de diseño y código en los pasos anteriores de PSP.

1.4.4 Planeación del PSP

• Te permiten llegar a acuerdos que tú puedas cumplir

• Proporcionar las bases para acuerdo en tu trabajo

• Guía tu trabajo

• Te ayuda a seguir tu progreso

La primera tarea consiste en definir los requerimientos, describiendo el trabajo a realizar en el mayor detalle posible. Como la etapa de planificación es demasiado temprana como para hacer un diseño completo del producto, los desarrolladores realizan un diseño conceptual, mediante el cual se obtiene un primer acercamiento de cómo debe basarse el producto a ser construido en la etapa de desarrollo. La siguiente tarea consiste en la estimación de tamaño y de esfuerzo. La correlación entre el tamaño de un programa y tiempo de desarrollo es moderadamente buena para equipos de desarrollo; sin embargo, para un solo desarrollador, la correlación es generalmente un poco mayor. Los desarrolladores realizan las estimaciones utilizando datos históricos personales de tamaño y productividad. En PSP, las estimaciones se efectúan mediante el método PROBE (PROxy Based Estimating).



Una vez que los desarrolladores conocen el tiempo requerido para cada proceso, deben estimar el tiempo que van a dedicar al trabajo cada día de la semana, conformando entonces el calendario. Luego, durante la etapa de desarrollo del producto, los desarrolladores efectúan el diseño detallado, la implementación y las pruebas. Después de completar el trabajo, los desarrolladores realizan un análisis postmortem, en el cual se actualiza el sumario del plan con los datos reales de tiempos invertidos en cada etapa del desarrollo, defectos encontrados y removidos, etc, y se comparan los resultados obtenidos con lo planeado. Finalmente, los desarrolladores registran toda esta información en sus bases de datos históricas de tamaño y productividad. Además se examinan las Propuestas de Mejoras (PIP) para hacer ajustes en los procesos. 1.4.5 Recolección de datos. En PSP, los desarrolladores utilizan información para monitorear su trabajo, la cual los ayuda a hacer mejores planes. Para esto, deben recolectar datos de los tiempos que dedican a cada fase del proceso, de los tamaños de los productos que producen, y de la calidad de esos productos. Las medidas básicas de PSP son el tiempo que el ingeniero utiliza en cada fase del proceso, los defectos introducidos y encontrados en cada fase, y los tamaños de los productos desarrollados en líneas de código (LOC). Estos datos se recopilan en cada fase del proceso y se resumen a la terminación del proyecto. Todos estos datos se utilizan para proporcionar una familia de medidas de calidad de procesos que los ingenieros usan como guía en su trabajo. Las principales medidas son:

• Tamaño tiempo de estimación de errores

• Coste de realización

• Defectos producidos y corregidos por hora

• Producción del proceso

• Valoración y calidad del coste de los fallos (COQ)



• Valoración del rango de fallos (A/FR)

Elementos • un guión de proceso

• un formulario resumen de plan proyecto

• un registro tiempo

• un registro de defectos

• un estándar de tipos defecto

Planificación: Estimar tiempo de desarrollo. Desarrollo: Desarrollar el producto utilizando tus métodos actuales. Post-mortem: Completar el resumen del plan proyecto, con los tiempos gastados y defectos

encontrados e inyectados en cada fase. Diseño: Diseñar el programa, usando tus métodos de diseño actuales. Codificación: Implementa el programa. Compilación: Compila hasta que esté libre defectos. Prueba: Prueba el programa y corrige todos los defectos.

Registra los defectos en el Log de defectos y tiempos por fase en el Log de tiempos.

No de Fase

Propósito Guiarte en el desarrollo de programas a nivel de módulo

Entradas Necesarias

Descripción del problema Formulario de Resumen del plan del Proyecto PSPO Tablas de Registro de Tiempos y Defectos Cronometro (opcional)

1 Planificación Producir u obtener los requisitos Estimar las LOC necesarias Estimar el tiempo de desarrollo necesario Indicar los datos del plan en el Resumen del Plan de Proyecto Completar el Log de Registro de Tiempos

2 Desarrollo Diseñar el programa Implementar el diseño Compilar el programa y corregir todos los defectos encontrados Completar la Tabla de Registro de Tiempos

3 Post-mortem Completar el Resumen del plan del Proyecto con los datos actuales de tiempo, defectos y tamaño

Criterios de salida

Un programa probado Un resumen del Plan de Proyectos con los datos estimados y actuales Las tablas de Registro de Tiempos y Defectos Rellenos



Encabezado: Nombre, fecha, programa, instructor, lenguaje. Tamaño del Programa: Plan. Indica tu mejor estimación del tiempo total que tendrá el desarrollo.

Actual. Indica el tiempo actual en minutos gastado en cada fase. Tiempo: A la fecha: Indica el tiempo total gastado en cada fase hasta hoy. Para programa

1A, es el tiempo gastado en el programa 1A. A la fecha % : Indica el porcentaje del total tiempo hasta hoy que se gasto en cada fase.

Defectos introducidos y removidos: Indicar el número actual de defectos inyectados y eliminados en cada fase. Defectos: A la fecha: Indica el total de defectos inyectados y eliminados en cada fase hasta

hoy. Para el programa 1A, son los defectos inyectados y eliminados en el programa 1A. A la fecha %: Indicar el porcentaje sobre el total defectos inyectados y eliminados hasta hoy en cada fase.

Logs de Registro de tiempo

Encabezado: Indicar nombre, fecha, instructor y número de programa.



Fecha: Indicar la fecha actual. Inicio: Indicar el tiempo en minutos cuando empiezas una fase del proyecto Fin: Indicar el tiempo en minutos cuando tu paraste tu trabajo en una fase del

proyecto, aun cuando tú no has terminado esa fase. Tiempo de interrupción: Indicar el tiempo perdido por interrupciones desde el periodo de arranque a parada. Tiempo Delta time: Indicar el tiempo transcurrido desde el inicio al tiempo de parada descontado el

tiempo de interrupción. Fase: Anotar la fase en la que estás trabajando. / Use el nombre de cada fase. Comentarios: Descripción de la interrupción. La tarea que estás haciendo. Cualquier aspecto

significativo que afecte a tu trabajo

1.4.6 Tamaño El tiempo en desarrollar un producto se encuentra altamente determinado por el tamaño del mismo. En PSP, los desarrolladores primero estiman el tamaño de los productos que planean desarrollar. Luego, al finalizar el producto, se mide el tamaño real obtenido. Esta información permite a los desarrolladores realizar a futuro una estimación de tamaños más precisa. Sin embargo, para que esta información sea útil, el tamaño de las mediciones debe corresponderse con el tiempo de desarrollo del producto. En PSP, el tamaño se mide en Líneas de Código (LOC). Para realizar un seguimiento de la variación del tamaño de un programa durante el desarrollo, se deben considerar varias categorías de LOC. Estas son:

• Base (son los LOC iniciales del producto original)

• Agregadas (es el código agregado a un programa base existente)

• Modificadas (es el código base que es modificado en un programa existente)

• Eliminadas (es el código base que es eliminado de un programa existente)

• Reutilización (es el código tomado de una librería u utilizado, sin realizar ninguna modificación, en un nuevo programa)

Fecha Inicio Fin Tiempo de Interrupción

Tiempo Delta Actividad Comentarios

9/9 9:00 9:50 50 Planeación

12:40 1:18 38 Diseño

2:45 3:53 10 58 Diseño Teléfono

10/9 11:06 12:19 6+5 62 Codificación Baño, tomé café

11/9 9:00 9:50 50 Codificación

1:15 2:35 3+8 69 Compilación Consulta de un libro

4:18 5:11 25 28 Prueba Reunión con mi jefe

13/9 9:00 9:50 50 Prueba

12:33 1:16 38 Postmortem



• Nueva Reutilización (esta medida cuenta los LOC que se agregan a una librería)

• Total (es tamaño total del programa, independientemente del código fuente).

Luego, para medir el tamaño total de un producto, el cálculo es el siguiente: Total LOC = Base – Eliminadas + Agregadas + Reutilización

Las LOC modificadas y de “nueva reutilización” no son incluidas en el total; esto se debe a que las LOC modificadas pueden representarse por LOC eliminadas y agregadas, y las LOC de “nuevo reutilización” ya se encuentran contabilizadas en las LOC agregadas. Logs de Registro de defectos El estándar de tipos de defectos proporciona un conjunto general de categorías de defectos. Aunque tú puedes reemplazar este estándar por el tuyo propio, es deseable que te manejes con estas definiciones simples de tipos hasta que tengas datos que te puedan guiar en las modificaciones. Estos estándares se utilizaron para llenar los logs de Registro de defectos. A continuación se muestra un ejemplo:



Encabezado: Indicar el nombre, fecha, instructor, y numero de programa. Fecha: Indicar la fecha cuando encontraste y corregiste el defecto. Número: Indicar un número único para este defecto. Comienza cada proyecto con 1. Tipo: Indicar el tipo de defecto a partir del estándar de tipos de defectos. Introducido: Indicar la fase donde tu juzgas que el defecto fue inyectado o introducido. Eliminado: Indicar la fase en la que encontraste y eliminaste el defecto. Tiempo de Arreglo: Indicar el tiempo que tomaste para corregir el defecto. Tú puedes dar el tiempo exacto o usar tu mejor estimación. Defecto Arreglado: Si este defecto fue inyectado durante la corrección de otro defecto, indicar el número de ese defecto o una X si lo desconoces. Nota: Un defecto es cualquier cosa en el programa que debe ser cambiado para que sea desarrollado, mejorado o utilizado de manera adecuada. Finalmente, la manera más eficaz de encontrar y arreglar defectos es repasando el código fuente del programa personalmente. Mientras esto puede parecer como una manera difícil de limpiar un programa defectuoso, resulta ser más rápido y más eficaz. Un método para realizar revisiones de código es la utilización de guías en las que se determina cuales son los defectos que más frecuentemente se inyectan. 1.4.7 METRICAS DEL PSP Con datos de tamaño, tiempo y defectos, existen muchas formas de medir, evaluar, y manejar la calidad de un programa. PSP provee una serie de mediciones de calidad que ayudan a los desarrolladores a examinar la calidad de sus programas desde varias perspectivas. Como ninguna medición por sí sola puede indicar adecuadamente la calidad de un programa, el panorama que provee la utilización de todas estas mediciones es generalmente un indicador confiable de calidad. Las principales mediciones de calidad son:

1. Densidad de defectos 2. Índice de revisión 3. Índices de tiempo de desarrollo 4. Índices de defectos 5. Rendimiento 6. Defectos por hora 7. Efectividad de remoción de defectos 8. Evaluación del índice de fallas

Resumen del registro de Métricas Nombre: Fecha: 18/10/96 Programa Programa # 13 Profesor Lenguaje: C++ Resumen Plan Actual a la Fecha Minutos/LOC 5,92 4,87 5,73 LOC/Hora 10,14 12,32 10,47 Defectos/KLOC 94,79 106,4 96,90 Rendimiento A/FR Tamaño Programa (LOC): Total nuevo & Cambiado 58 47 258



Tamaño Máximo 72 Tamaño Mínimo 41 Tiempo en fase (min.) Plan Actual Para Fecha Para Fecha % Planing 18 22 88 6,0 Diseño 35 24 151 10,2 Código 149 93 637 43,1 Revisión código 20 37 111 7,5 Compilación 24 4 92 6,2 Test 64 8 240 16,2 Postmortem 33 41 160 10,8 Total 343 229 1479 100 Tiempo Máximo 426 Tiempo Mínimo 243 Introducción de defectos Plan Actual Para Fecha Para Fecha % Def/Hora Planing Diseño 1 4 16,0 Código 5 5 21 84,0 Revisión código Compilación Test Total 6 5 25 100,0

1.5 TSP (Team Software Process) El resultado final es que incluso aunque un equipo de ingenieros esté entrenado en PSP, todavía les queda combinar sus procesos de trabajo personal dentro de un único proceso de equipo. Esto es para ellos un problema, incluso en los más altos niveles de CMMI. Por esta razón se ha desarrollado Team Software Process SM (TSPSM).

TSP extiende y refina los métodos CMM y PSP, para guiar a los miembros de los equipos en el trabajo de mantenimiento y desarrollo. TSP les muestra cómo construir un equipo autodirigido y como ser un



efectivo miembro del equipo. También les enseña cómo dirigir y soportar estos equipos y como mantener un medio para obtener un alto nivel de desarrollo. En resumen, se puede decir que TSP tiene 4 objetivos principales:

1. Construir equipos autodirigidos que planifiquen y realicen un seguimiento de su trabajo, estableciendo metas además sus propios procesos y planes.

2. Mostrar a los directores como entrenar y motivar a sus equipos y como ayudarles para mantenerles en el más alto nivel de desarrollo.

3. Acelerar la mejora del proceso software haciendo normal la conducta del Nivel 5 de CMMI

4. Mejorar la dirección para obtener organizaciones de un alto nivel de madurez

La principal ventaja de TSP es que muestra a los ingenieros como producir productos de calidad por medio de una planificación de costos. Esto lo hace, enseñándoles cómo planificar su propio trabajo y haciéndoles participes de los planes y procesos que se van a llevar a cabo. TSP proporciona equipos de proyectos con guías explícitas sobre como alcanzar sus objetivos. TSP conduce al equipo a través de cuatro fases dentro de un mismo proyecto. Estos proyectos deben empezar o terminar con alguna fase o pueden ejecutarse desde el principio al final. Antes de cada fase, el equipo planifica y organiza su trabajo mediante una puesta en marcha completa (launch) o relaunch.

1.5.1 Equipos de Trabajo. El Software Engineering Institute (SEI) ha desarrollado el TSP para ayudar a equipos de ingenieros de software a desarrollar productos de software de manera eficiente. Este proceso ataca varios de los problemas actuales en el desarrollo intenso de productos de software y enseña a equipos de trabajo y gerencia como resolverlos. El TSP muestra a grupos de ingenieros como aplicar conceptos integrados en el desarrollo de software, encamina a los ingenieros y a la gerencia en un proceso de 4 días para establecer los objetivos, definir los roles, atacar los riesgos y producir un plan de trabajo comprensivo. Siguiendo el lanzamiento el TSP provee un marco de procesos definidos y medibles para administrar, supervisar y reportar el trabajo en equipo. Cada equipo puede estar conformado por al menos 2 personas y hasta 15 personas como máximo. Los miembros del equipo deben trabajar hacia un objetivo común y tiene roles específicos o responsabilidades dentro del equipo. Existe una interdependencia entre el trabajo de los miembros del



equipo que requiere cooperación para que el equipo sea exitoso y por lo mismo siguen un proceso de trabajo común. Es importante que cada miembro del grupo sepa cuál va a ser su función y sus responsabilidades, y debería comprobar si alguno de los miembros del grupo necesita ayuda. Además cada miembro del grupo debe proporcionar una copia completa del formulario WEEK para que el jefe del proyecto pueda planificar la siguiente fase. Se debe crear un diseño conceptual para cada producto planificado y dividir en ciclos y documentar el trabajo. Además se debe de tener una infraestructura para poder realizar estas funciones como por ejemplo formularios que controlen los errores, el control de la entrada/salida, etc. Los miembros del grupo deben planificar una fase de implementación personal utilizando por ejemplo PSP. Esta planificación y documentación debe ser estándar para todos los miembros del grupo y para ello utilizar los mismos formularios. Se deben especificar los bucles de pruebas, los valores de las variables que se van a usar y los condiciones de error que se vayan a producir, establecer los límites de posibles valores de las variables, los datos más críticos, etc. Además se debe realizar un desarrollo explicito de las pruebas que se vayan a realizar y las revisiones de código que se vayan a hacer. Todas las pruebas se deben planificar con anticipación y establecer una forma estándar de realizarlas y documentarlas para solucionar los posibles problemas y errores que hayan producido. En la documentación debe aparecer quien o quienes de los miembros del grupo son los encargados de realizar las pruebas y quiénes son los encargados de instalar el producto final. Al final de cada ciclo y cada grupo debe realizar una memoria de su trabajo y comparar el resultado con las metas establecidas al principio del ciclo para poder así extraer conclusiones. Esta memoria debería contener:

1. El tamaño del producto 2. Las horas de desarrollo 3. El rango de líneas de código por hora (LOC/Hours) 4. El rendimiento antes de la compilación 5. El rendimiento antes de las pruebas del sistema 6. El nivel de defectos en la compilación 7. El nivel de defectos en todas las fases de pruebas

Además de todo lo anterior expuesto, los grupos deberían aportar la relación de inspecciones y revisiones realizadas y los valores obtenidos en ellas. 1.5.2 Componentes del TSP Los equipos de TSP estiman proyectos con una aproximación arriba-abajo, utilizando todo el tamaño y mediante la productividad del equipo, determinar el programa completo. Como se ha descrito anteriormente, el proyecto se divide en fases y cada una de ellas es estimada y rastreada. En las puestas en marcha de cada fase, se definen las tareas y para cada tarea se realiza una estimación usando métodos rigurosos de Personal Software Process (PSPSM). Estas estimaciones se utilizan para generar un plan detallado de valores-ganados, con el cual se identificara el seguimiento y planificación de las metas del proyecto, criterios de calidad y riesgos de las puestas en marcha. TSP requiere entrevistas periódicas donde se comparan los progresos con la planificación del equipo en términos de valores ganados y calidad. Si hay desviaciones con respecto a la planificación, se pueden determinar las razones y tomar medidas para que se retorne otra vez a dicha planificación. Es también



durante estas entrevistas periódicas, donde se revisan los riesgos que se han producido durante la puesta en marcha. Las puestas en marcha de TSP no concluyen satisfactoriamente hasta que el equipo y la dirección estén de acuerdo sobre los requerimientos y el desarrollo. Una vez que se ha determinado el desarrollo, se usa como base para una medida personal y los valores se rastrean por cada persona y periódicamente por el equipo. El TSP también requiere replanificación de un proyecto, o más tarde actualización, cuando las especificaciones del plan cambian. Esto significa que cuando estas especificaciones cambian a lo largo del proyecto, el equipo renegocia la planificación, delibera la funcionalidad y si es necesario el coste. Finalmente, los problemas con la calidad pueden ser virtualmente eliminados usando TSP, ya que los métodos de calidad usados son los mismos que los usados en PSP y que los ingenieros realizan individualmente cuando llevan a cabo sus revisiones, diseños y codificaciones. 1.5.3 Roles del TSP La puesta en marcha de un proyecto TSP incluye los siguientes pasos:

1. Revisar con la dirección los objetivos del proyecto. 2. Establecer los roles del equipo. 3. Documentar los objetivos del equipo. 4. Producir la totalidad de la estrategia de desarrollo. 5. Definir los procesos de desarrollo del equipo. 6. Planificar los soportes que se necesitan. 7. Realizar una planificación del desarrollo para el proyecto entero. 8. Realizar una planificación de la calidad y el conjunto de objetivos de calidad. 9. Realizar una planificación detallada para cada ingeniero para la siguiente fase. 10. Unir las planificaciones individuales dentro de un plan de equipo 11. Rebalancear el trabajo de equipo para conseguir un mínimo programa. 12. Calcular los riesgos y asignar responsabilidades para cada clase de riesgo. 13. Tener una puesta en marcha de postmortem.

Al final de cada puesta en marcha, el equipo revisa los planes y los riesgos del proyecto con la dirección. Una vez que el proyecto comienza, el equipo realiza semanalmente reuniones y periódicamente informa de ello a la dirección y al cliente. Después de establecer estos pasos, TSP produce los siguientes resultados:

• Se han escrito las metas • Se han definido los roles

Cuadro Comparativo de Modelos de Calidad

Característica PSP Inspecciones CMM ISO900

Propósito Gerenciamiento y mejora de la calidad

Mejora de la calidad Mejora del gerenciamiento Gerenciamiento de la calidad

Metodología Prescriptiva Presciptiva Descriptiva Descriptiva

Definición Exacta Exacta Vaga Vaga

Audiencia Desarrolladores y gerentes Desarrolladores Gerentes Gerentes

Cobertura Ciclo de vida del desarrollo Verificación y validación Gerenciamiento de proyectos

Aseguramiento de la Calidad



Costo Muy bajo Bajo Alto Alto

Calidad Muy alta Alta Baja Baja

Implementación Semanas Días Años Años

Alcance Integral Estrecho Ambiguo Ambiguo

Cuan Mensurable es

Muy Alto Alto Bajo Bajo

¿Por qué PSP nos conduce al CMMI?

El CMMI significa decir que se hace, hacer lo que se dice y medirlo. Adoptando el framework del RUP (Rational Unified Process ), es posible aplicar el proceso que se convirtió en el estándar de ipso de la industria de desarrollo de software, en una forma sencilla de seguir y aplicar, tal como lo es una interfaz web. Es posible agregarle variantes de procesos o prácticas para customizarlo al proceso de la organización, y aun así continuar conformando el acercamiento por RUP. Una vez definido el proceso, se la pone a disposición de todos los miembros del equipo en su desktop. Esto hace que el proceso este accesible para todos, ayudando a asegurar la comunicación y consistencia y evitando gastar el tiempo determinado cual es el próximo paso a seguir. 1.6 Administración de Proyecto Administrar un programa o proyecto complejo requiere una buena comprensión de las actividades que deben ser concretadas, sus relaciones con el problema del negocio y un mecanismo para entender el progreso actual del proyecto comparado contra los milestones del negocio. Combinando el Rational Unified Process con el Rational Project Console, el equipo puede seguir un proceso definido y luego reportar el progreso del proyecto referido a dicho proceso. Ingeniería La ingeniería de procesos es “la base de este largo camino.” Las disciplinas de ingeniería de administración de requerimientos, análisis, diseño, implementación y test son unificadas dentro del proceso e desarrollo de un sistema o producto. Rational provee el sistema y el ambiente de desarrollo de software líder del mercado a través de la familia de productos de las Suites Rational. Esta solución para todo ciclo de vida es un conjunto de herramientas integradas que, cuando son implementadas en un conjunto con las mejores prácticas definidas en el RUP, ayudan a las organizaciones a adherir al CMMI. Ambiente de Soporte El “como hacer ” del Área de Procesos de Configuración Management del CMMI puede ser alcanzada usando Unified Change Management ( UCM ), las mejores prácticas de Rational para encarar la administración del cambio desde la formulación del requerimiento al relase. El UCM en conjunto con el software Rational de configuración management, Rational ClearCase y Rational ClearQuest, ayuda a alcanzar la mayoría de los requerimientos del CMMI para configuración management. PSP (Personal Software Process ) es un marco de procesos propuestos para la disciplina individual del desarrollador de software, y TSP ( Team Software Process ) esta compuesto por procesos para pequeños equipos de desarrollo.



PSP y TSP fueron propuestos por Watts Humphrey, en el SEI/CMU, con el gran objetivo de cambiar la cultura de desarrollo de software, promoviendo la idea de “hacer todo de forma correcta en la primera vez ” y desarrollar el software totalmente libre de errores. PSP y TSP también pueden ser utilizados para ayudar y acelerar la implantación de CMMI, y directamente relacionados al nivel 5 del CMMI. También Tiene el objetivo de presentar un abordaje para la implementación del nivel 4 de CMMI usando PSP y TSP, en muy pequeñas empresas (empresas de una incubadora, con 4 a 10 desarrolladores de software ). Toda la presentación está basada en un caso real, conducido en Brasil, con 7 empresas de incubadoras. El PSP en comunicación con el CMMI hace uso de un gran número de Formatos, los que son útiles para hacer un análisis a fondo del programa a desarrollar. Los Formatos son los siguientes:

• Bitácora de Registro de Tiempo Transcurrido • El tiempo empleado en cada fase y los defectos encontrados en cada fase, se calculan de forma

especifica • Bitácora del Registro de Defectos.- es promover la mejora continua cada vez que se haga un

proyecto • Resumen del Plan de Proyecto.- Reúne las estimaciones y los datos reales que conforman al

proyecto en toda amplitud para que al final realicen las comparaciones necesarias y exista un histórico de todos los proyectos realizados.



Unidad II

C a l i da d e n pr o ye c t o s de T . I .

2.1 ISO y MOPROSOFT

Introducción MoProSoft es un modelo de calidad que permitirá a la pequeña y mediana empresa de desarrollo de software, el acceso a las prácticas de Ingeniería de Software de clase mundial. Moprosoft, tiene por objetivo proporcionar a la industria mexicana, y a las áreas internas dedicadas al desarrollo y mantenimiento de software, un conjunto integrado de las mejores prácticas basadas en los modelos y estándares reconocidos internacionalmente, tales como ISO 9000:2000, CMM-SW, ISO/ IEC 15504, PMBOK, SWEBOK entre otros. En resumen el objetivo es: Fortalecer a la industria de software en México Moprosoft fue desarrollado durante el 2002, como consecuencia de los acuerdos de la mesa de la Estrategia 6 del Programa para el Desarrollo de la Industria de Software (PDIS- ProSoft) dirigido por la Secretaría de Economía, bajo un convenio con la Facultad de Ciencias de la UNAM. 2.1.1 Estrategias

1. Promover exportaciones y la atracción de inversiones 2. Educación y formación de personal competente 3. Contar con un marco legal promotor de la industria 4. Desarrollar el mercado interno 5. Fortalecer a la industria local 6. Alcanzar niveles internacionales en capacidad de procesos

6.1 Formación de instituciones de capacitación y asesoría en mejora de procesos. 6.2 Definición de un modelo de procesos y de evaluación apropiado para la industria de

software mexicana. 6.3 Apoyo financiero para la capacitación y la evaluación de capacidad de procesos.

7. Promover la construcción de infraestructura física y de telecomunicaciones ¿Cuál es el primer paso para implementar MoProSoft ? 1.El primer paso, sin lugar a dudas, es sentir la necesidad de cambio, de la mejora continua, de la competitividad creativa. 2. Expresarlo a la organización. 2.1.2 Ventajas 1 Al tener prácticas integradas, que abarcan desde la gestión de negocio hasta el desarrollo y

mantenimiento de software, las empresas tendrían mayor control sobre su desempeño en el mercado.

2 El costo de la incorporación del nuevo personal podría disminuir si se enfocan la educación y la capacitación a un modelo único.

3 Las empresas pequeñas, al seguir procesos similares, podrían asociarse con mayor facilidad para afrontar proyectos de mayor envergadura.



4 La exportación de servicios de software de las empresas mexicanas sería más factible. Incluso se podría disminuir la necesidad de la intermediación de las empresas trasnacionales, gracias a que Moprosoft considera las prácticas reconocidas internacionalmente.

2.1.3 Características: 1 Específico para el desarrollo y mantenimiento de software. 2 Fácil de entender (comprensible). 3 Definido como un conjunto de procesos. 4 Práctico y fácil de aplicar, sobre todo en organizaciones pequeñas. 5 Orientado a mejorar los procesos para contribuir a los objetivos del negocio y no simplemente ser un

marco de referencia de certificación. 6 Debe de tener un mecanismo de evaluación o certificación, que indique un estado real de una

organización durante un periodo de vigencia específico. 7 Aplicable como norma mexicana. 8 No costoso en su adopción. 9 Ser la base para alcanzar evaluaciones exitosas con otros modelos o normas, tales como ISO

9000:2000 [1] o CMMâ1 V1.1[2]. 10 Es un modelo basado en tres categorías de procesos:

10.1 Alta Dirección 10.2 Gestión 10.3 Operación

2.1.4 Arquitectura



Actividades de los directivos de la organización Subprocesos de Gestión de Recursos:

1. Recursos Humanos y ambiente de trabajo 2. Bienes, Servicios e Infraestructura. 3. Conocimiento de la organización.

Proceso de Administración de proyectos específicos • Inicio • Planeación • Realización • Evaluación • Cierre

Proceso de Desarrollo y manto. de software.

• Ciclos de Desarrollo • Fases de un ciclo • Actividades de una fase



2.1.5 Patrón del proceso. Definición del proceso.

• Proceso (Nombre) • Categoría (Nombre) • Propósito • Descripción • Objetivos • Indicadores • Metas cuantitativas • Responsabilidad y autoridad



• Procesos relacionados • Entradas (Nombre, Fuente) • Salidas (Nombre, Descripción, Destino) • Productos internos (Nombre, Descripción) • Referencias bibliográficas (ISO9001:2000, SW-CMM 1.1, ISO 15504, otras)

Prácticas

• Roles involucrados y capacitación • Actividades (Rol, Actividad, Objetivo, Tareas) • Diagrama de flujo de trabajo (actividades de UML) • Verificaciones y validaciones (Actividad, Producto, Rol, Descripción) • Incorporación a la Base de Conocimiento (Producto, Forma de aprobación) • Recursos de Infraestructura (Actividad, Recurso) • Mediciones (Ejemplo de medición por indicador) • Capacitación • Situaciones excepcionales • Lecciones aprendidas

Guías de ajuste

• Sin invalidar el cumplimiento de los objetivos del proceso 2.1.6 Generalidades



2.2 Normas ISO

Las normas de la serie ISO – 9000 son estándares internacionales para los sistemas de gestión de la calidad. Contienen los lineamientos mínimos que debe tener una organización para que pueda ser reconocida mundialmente como gestora del aseguramiento de la calidad.

1. ISO 9000 – 2000: Principios Básicos y Vocabulario 2. ISO 9001 – 2000: Requisitos del Sistema de Gestión de Calidad 3. ISO 9004 – 2000: Guía para la Gestión de Calidad 4. ISO 9011 – 2000: Guía para la Administración y Conducción de Auditorías Ambientales y de

Calidad. Indica como auditar los procesos que constituyen al sistema de gestión de la calidad. Las directrices también abarcan a un sistema de gestión ambiental o según ISO 14001 / 96

2.2.1 ISO 9126. Calidad del software y métricas de evaluación.

ISO 9126 es un estándar internacional para la evaluación del Software. Está supervisado por el proyecto SQuaRE, ISO 25000:2005, el cual sigue los mismos conceptos.

La ISO 9126 [basada en el modelo de Mc Call] plantea un modelo normalizado que permite evaluar y comparar productos sobre la misma base.

Aquí la calidad queda definida a un alto nivel de abstracción por seis características:



• Funcionalidad: Atributos que se relacionan con la existencia de un conjunto de funciones y sus propiedades específicas. Las funciones satisfacen necesidades declaradas o implícitas [ISO 9126: 1991]

• Fiabilidad: Capacidad de un sistema para mantener su nivel de rendimiento • Usabilidad: Esfuerzo necesario para el uso y la valoración individual de tal uso, por parte de un

conjunto de usuarios. [ISO 9126: 1991] • Portabilidad: Es la capacidad de un sistema para ser transferido de un entorno a otro. [ISO

9126: 1991] • Mantenibilidad: Es el esfuerzo necesario para realizar modificaciones específicas. [ISO 9126:

1991] • Eficiencia: Es la relación entre el nivel de prestaciones de un sistema y el volumen de recursos

utilizados en condiciones declaradas. [ISO 9126: 1991]

Este estándar no proporciona métricas ni métodos de medición, por lo que no son prácticas las mediciones directas de las características de calidad.

Para resolver este problema se revisó la ISO 9126 y se incluyó un nuevo modelo de calidad que distingue entre tres aproximaciones a la calidad de producto en ISO 14598, a saber:

• Parte1. Modelo de Calidad ISO/IEC 9126-1 • Parte2. Métricas Externas ISO/IEC 9126-2 • Parte3. Métricas Internas ISO/IEC 9126-3 • Parte4. Métricas de Calidad en el uso ISO/IEC 9126-4

ISO 9126-1

Este estándar define la usabilidad como la capacidad de un producto software de ser comprendido, aprendido, usado y de ser atractivo para el usuario, en condiciones específicas de uso.

Esta definición es pone el énfasis en los atributos internos y externos del producto, los cuales contribuyen a su usabilidad. Se observa que la usabilidad no depende sólo del producto, sino también del usuario. Atributos para poder estudiarla:

• Facilidad de aprendizaje • Eficiencia • Recuerdo en el tiempo • Tasa de errores • Satisfacción

Métodos de evaluación de usabilidad

Se pueden considerar dos grupos de UEM [Usability Evaluation Methods]:

Los UEM empíricos, donde participan:

• Usuarios • Evaluadores • Observadores • Expertos en test



Los UEM analíticos donde no tienen acceso los usuarios, incluyen un equipo de especialistas en usabilidad. Para el proceso de inspección se utilizan directrices o heurísticas para realizar el proceso de inspección.

Métricas de usabilidad

Por medición se entiende el proceso de atribuir números o símbolos a los atributos de las entidades en el mundo real. a través de la medición es posible juzgar lo que se mide.

Una métrica es la correspondencia del mundo real, a un mundo formal. Una métrica es un valor numérico asignado a algún evento del mundo real, software, sitio web, aplicación web, etc.

Un atributo es la característica de una entidad de tipo directo o indirecto, por ejemplo, links no operativos, microcódigo no accesible, etc.

El uso de métricas no limita la intervención humana y ofrece una reducción de la subjetividad en la evaluación de calidad de un sitio o aplicación web, etc.

ISO 9126-2 Capacidad de análisis y de cambio



9123-3 Métricas internas para la evaluación del software.

I S O / I E C T R 9 1 2 6 - 3 : 2 0 0 3

Las métricas internas se pueden son aplicables a:

• A un producto de software no ejecutable. • Aplican durante las etapas de su desarrollo. • Permiten medir la calidad de los entregables intermedios. • Permiten predecir la calidad del producto final. • Permiten al usuario iniciar acciones correctivas temprano en el ciclo de desarrollo.

T a b l a s d e M é t r i c a s

Organizadas por característica y subcaracterística, cada métrica contiene: 1. Nombre 2. Propósito 3. Método de aplicación 4. Medidad, fórmula y cómputo de datos 5. Interpretación del valor medido

6. Tipo de escala 7. Tipo de medida 8. Fuente de medición 9. Referencia a ISO/IEC 12207 SLCP 10. Audiencia

M é t r i c a s d e F u n c i o n a l i d a d

1. Adecuidad 2. Exactidud 3. Interoperabilidad 4. Seguridad 5. Conformidad de la funcionalidad

E j e m p l o d e M é t r i c a d e A d e c u i d a d

Nombre: Completitud de implementación funcional

Propósito: Qué tan completa está la implementación funcional.

Método de

aplicación:

Contar las funciones faltantes detectadas en la evaluación y comparar con el

número de funciones descritas en la especificación de requisitos.

Medición,

fórmula:

X=1-A/B

A=número de funciones faltantes

B = número de funciones descritas en la especificación de requisitos

Interpretación: 0<=X<=1

Entre más cercano a 1, más completa.

Tipo de escala: absoluta

Tipo de medida: X=count/count

A=count

B = count

Fuente de Especificación de requisitos



medición: Diseño

Código fuente

Informe de revisión

ISO/IEC 12207

SLCP:

Validación

Revisión conjunta

Audiencia: Requeridores

Desarrolladores

M é t r i c a s d e F i a b i l i d a d

1. Madurez 2. Tolerancia a fallos 3. Recuperabilidad 4. Conformidad de la fiabilidad

M é t r i c a s d e U s a b i l i d a d

1. Entendibilidad 2. Aprendibilidad 3. Operatibilidad 4. Atractivo 5. Conformidad de la usabilidad

M é t r i c a s d e E f i c i e n c i a

1. Comportamiento en el tiempo 2. Utilización de recursos 3. Conformidad de la eficiencia

M é t r i c a s d e M a n t e n i b i l i d a d

1. Analizabilidad 2. Cambiabilidad 3. Estabilidad 4. Examinabilidad 5. Conformidad de la mantenibilidad

M é t r i c a s d e P o r t a b i l i d a d

1. Adaptabilidad 2. Instalabilidad 3. Coexistencia 4. Remplazabilidad 5. Conformidad de la transportabilidad



C o n s i d e r a c i o n e s a l U t i l i z a r l a s M é t r i c a s

1. Interpretación de las mediciones o Diferencia entre conextos de pruebas y de uso. o Validez de resultados: procedimientos, fuentes de evaluación, validación de datos. o Equilibrio de recursos de medición. o Especificación correcta.

2. Validación de las métricas o Propiedades deseables: confiable, repetible, reproducible, disponible, indicable, correcta,

con significado. o Demostración de validez: correlación, rastreo, consistencia, predictibilidad,

discriminación. o 7 propiedades deseables en las métricas o 7 propiedades deseables en las métricas

3. Uso de métricas para estimación y predicción 4. Detección de desviaciones y anomalías 5. Presentación de resultados de medición

o Gráficas de barras, matriz de desempeño, gráficas de Pareto, gráficas de correlación, etc.

M o d e l o d e M e d i c i ó n d e l a C a l i d a d

Actividad 1 Actividad 2 Actividad

3

Actividad 4 Actividad 5 Actividad 6 Actividad

7

Actividad 8

Fase Análisis de

requisitos

Diseño de

arquitectura

Diseño

detallado

de

software

Codificación

y pruebas de

software

Integración

y pruebas

de software

Integración

y pruebas

de sistema

Instalación Aceptación

y apoyo

Referencia

modelo

9126

Calidad requerida

por el usuario

Calidad interna

requerida

Calidad externa

requerida

Calidad en

uso

predicha

Calidad

externa

predicha

Calidad

interna

medida

Calidad en

uso

predicha

Calidad

externa

predicha

Calidad

interna

medida

Calidad en

uso predicha

Calidad

externa

medida

Calidad

externa

predicha

Calidad

interna

medida

Calidad en

uso

predicha

Calidad

externa

medida

Calidad

externa

predicha

Calidad

interna

medida

Calidad en

uso

predicha

Calidad

externa

medida

Calidad

interna

medida

Calidad en

uso

predicha

Calidad

externa

medida

Calidad

interna

medida

Calidad en

uso medida

Calidad

externa

medida

Calidad

interna

medida

Entregables

clave

Requisitos de

calidad del usuario

Requisitos de

calidad externa

Requisitos de

calidad interna

Diseño de

arquitectura

Diseño

detallado

de

software

Código y

resultados

de pruebas

Producto y

resultados

de pruebas

Sistema

integrado y

resultados

de pruebas

Sistema

instalado

Producto

entregado



Métricas

utilizadas

Internas (externas

pueden validar

especificaciones)

Internas Internas Internas y

externas

Internas y

externas

Internas y

externas

Internas y

externas

Calidad en

el uso,

internas y

externas

P a s o s S u g e r i d o s

1. Identificación de requisitos de calidad 2. Especificación de la evaluación 3. Diseño de la evaluación 4. Ejecución de la evaluación 5. Retroalimentación a la organización

M é t r i c a s I n t e r n a s P u r a s

• Trazabilidad • Número ciclomático • Complejidad del flujo de

información • Modularidad • Tamaño del programa • Enunciados condicionales

• Referencia unificada de datos • Adecuidad de nombre de variables • Proporción de acomplamiento entre módulos por

datos • Enunciados del programa • Tamaño promedio de módulo • Proporción de acomplamiento entre módulos por

funciones

9126 -4 Métricas de evaluación de calidad

Estas son las métricas propuestas en el estándar:

• Métricas relacionadas con la efectividad • Métricas relacionadas con la productividad • Métricas relacionadas con la seguridad • Métricas relacionadas con la satisfacción

2.2.2 ISO 10006

ISO 10006 es una norma para la gestión de proyectos, su equivalente es llamado UNE-66916 (Octubre del 2003). La norma ISO 10006:2003, los sistemas de gestión de la calidad - Directrices para la gestión de la calidad en los proyectos, es una norma internacional elaborada por la Organización Internacional de Normalización. ISO 10006:2003 sirve de guía sobre la aplicación de gestión de la calidad en los proyectos. Es aplicable a proyectos de distinta complejidad, la duración de grandes o pequeños, de corto o largo, en diferentes ambientes, y con independencia del tipo de producto o proceso en cuestión. Esto puede requerir cierta adaptación de la orientación para adaptarse a un proyecto particular.



ISO 10006:2003 no es una guía para la "gestión de proyectos" en sí. Orientación sobre la calidad en los procesos de gestión del proyecto se discute en esta Norma Internacional. Orientación sobre la calidad en el producto de un proyecto relacionado con los procesos, y en el "enfoque de proceso", está cubierto en la norma ISO 9004. Un nuevo "Gestión de proyectos - Guía para la Gestión de Proyectos" es la norma ISO 21500 en preparación (2008). Dado que la norma ISO 10006:2003 es un documento de orientación, no está destinado a ser utilizado para propósitos de certificación / registro. 2.2.3 ISO/IEC 27000

La serie de normas ISO/IEC 27000 son estándares de seguridad publicados por la Organización Internacional para la Estandarización (ISO) y la Comisión Electrotécnica Internacional (IEC). La serie contiene las mejores prácticas recomendadas en Seguridad de la información para desarrollar, implementar y mantener Especificaciones para los Sistemas de Gestión de la Seguridad de la Información (SGSI). La mayoría de estas normas se encuentran en preparación e incluyen:

• ISO/IEC 27000 - es un vocabulario estándar para el SGSI. Se encuentra en desarrollo actualmente.

• ISO/IEC 27001 - es la certificación que deben obtener las organizaciones. Norma que especifica los requisitos para la implantación del SGSI. Es la norma más importante de la familia. Adopta un enfoque de gestión de riesgos y promueve la mejora continua de los procesos. Fue publicada como estandar internacional en octubre 2005. ISO/IEC 27002 - Information technology - Security techniques - Code of practice for information security management. Previamente BS 7799 Parte 1 y la norma ISO/IEC 17799. Es código de buenas prácticas para la gestión de seguridad de la información. Fue publicada en julio de 2005 como ISO 17799:2005 y recibió su nombre oficial ISO/IEC 27002:2005 el 01 de julio de 2007.

• ISO/IEC 27003 - son directrices para la implementación de un SGSI. Es el soporte de la norma ISO/IEC 27001. Se encuentra preparación y probablemente sea publicada en 2009.

• ISO/IEC 27004 - son métricas para la gestión de seguridad de la información. Es la que proporciona recomendaciones de quién, cuándo y cómo realizar mediciones de seguridad de la información. Se encuentra preparación y probablemente sea publicada en 2009.

• ISO/IEC 27005 - trata la gestión de riesgos en seguridad de la información. Es la que proporciona recomendaciones y lineamientos de métodos y técnicas de evaluación de riesgos de Seguridad en la Información, en soporte del proceso de gestión de riesgos de la norma ISO/IEC 27001. Es la más relacionada a la actual British Standard BS 7799 parte 3. Publicada en Junio de 2008.

• ISO/IEC 27006:2007 - Requisitos para la acreditación de las organizaciones que proporcionan la certificación de los sistemas de gestión de la seguridad de la información. Esta norma específica requisitos específicos para la certificación de SGSI y es usada en conjunto con la norma 17021-1, la norma genérica de acreditación. * ISO/IEC 27007 - Es una guía para auditar al SGSI. Se encuentra en preparación.

• ISO/IEC 27799:2008 - Es una guía para implementar ISO/IEC 27002 en la industria de la salud.



2.2 Estándares para documentación de proyectos.

2.2.1 ISO/IEC,26514:2008

La documentación puede ser la primera cosa concreta que el usuario ve y por lo tanto influye en las primeras impresiones de los usuarios del producto de software. Si la información se suministra en forma práctica y es fácil de encontrar y entender, el usuario rápidamente puede ser competente para utilizar el producto. Por lo tanto, una buena documentación no sólo ayuda al usuario a reducir el costo de formación y apoyo, sino que también mejora la reputación del producto, su fabricante y sus proveedores. La documentación a menudo es considerada como algo que se hace después de que el software ha sido implementado. Sin embargo, para documentación de alta calidad del software, su desarrollo debe ser considerado como una parte integral del software (ciclo de vida). Las normas desarrolladas para ayudar a los usuarios con esta situación son: ISO / IEC 15288:2008, sistemas y software de ingeniería - procesos del ciclo de vida del sistema. ISO / IEC 12207:2008, Sistemas y de ingeniería de software -- Procesos del ciclo de vida del software, el diseño y desarrollo de documentación como parte del ciclo de vida del software procesos. Se define el proceso de documentación desde el punto de vista del desarrollador de Documentación. NOTA: otras normas internacionales en la familia ISO / IEC 265NN están en preparación o en proyecto para abordar la documentación y los procesos de gestión de la información de los puntos de vista de los directivos, asesores y evaluadores, y de compradores y proveedores. Además de definir un proceso estándar, esta norma Internacional también incluye la documentación del producto. Esta norma internacional especifica la estructura, contenido y formato de la documentación, y también proporciona informativas de orientación para el estilo de documentación del usuario. Sistemas e ingeniería de software - Requisitos para los diseñadores y desarrolladores de documentación de usuario Ámbito de aplicación. Se define el alcance, propósito, la organización, utilizando candidatos de esta norma internacional. Esta Norma Internacional apoya el interés de los usuarios de software realizar documentación coherente, completa, exacta, y útil. La primera parte de esta norma internacional abarca el proceso de documentación del usuario para los diseñadores y los desarrolladores de la documentación. En él se describe la forma de establecer la información que los usuarios necesitan, determina cómo preparar, presentar y asegurarse que la información esté disponible a los usuarios. No se limita al diseño y desarrollo de la fase del ciclo de vida, sino que incluye actividades de toda la gestión de información y los procesos de documentación. La segunda parte de esta norma internacional establece los requisitos mínimos para la estructura, el contenido y formato de la documentación de usuario. Se aplica a los manuales de usuario impreso, ayuda en línea, tutoriales y documentación de referencia del usuario, estos pueden ser electrónicos o impresos. Esta Norma Internacional puede ser útil para el desarrollo de los siguientes tipos de documentación, aunque no cubre todos los aspectos de ellos:

1. Documentación de otros productos de software; 2. Sistemas multimedia con animaciones de video y sonido; 3. Capacitación basada en computadora (CBT) y los paquetes de materiales de los cursos

especializados destinados principalmente para uso en programas de capacitación formal;



4. Documentación producida para los instaladores, operadores de computadoras, o el sistema de administradores. Documentación de mantenimiento.

5. Describir el funcionamiento interno de sistemas de software. 6. Documentación incorporada en la interfaz del usuario.

Esta Norma Internacional también es aplicable a una variedad de especialistas:

1. Especialistas en usabilidad y analistas de negocio que se identifican las tareas que los usuarios previstos llevará a cabo con el software.

2. Personas que desarrollan y editar el contenido escrito de la documentación del usuario. 3. Diseñadores gráficos con experiencia en medios de comunicación electrónicos. 4. Diseñadores de la interfaz de usuario y la ergonomía, expertos que trabajan juntos para diseñar

la presentación de la documentación sobre la pantalla. El orden de las cláusulas en esta norma no implica que la documentación debe ser desarrollada o presentada al usuario en este orden. En el anexo A podemos observar una plantilla general para cubrir los apartados más importantes de la norma.

2.2.2 IEEE 830. Un buen Documento de requisitos, pese a no ser obligatorio que siga estrictamente la organización y el formato dados en el estándar 830, sí debería incluir, de una forma o de otra, toda la información presentada en dicho estándar. El estándar de IEEE 830 no está libre de defectos por ello ha sido criticado por múltiples autores, llegándose a cuestionar incluso si es realmente un estándar en el sentido habitual que tiene el término en otras ingenierías. Con propósitos fundamentalmente docentes, se presenta cómo se organizaría un Documento de Requisitos según el estándar IEEE 830. Plantilla para IEEE 830 1. Introducción

En esta sección se proporcionará una introducción a todo el documento de Especificación de Requisitos Software (ERS). Consta de varias subsecciones que se revisan a continuación.

1.1 Propósito. Se define el propósito del documento ERS y se especificará a quién va dirigido el documento.

1.2 Ámbito del Sistema. Se determinan los siguientes datos:

• Nombre al futuro sistema (p.ej. MiSistema) • Explicar lo que el sistema hará y lo que no hará. • Se describirán los beneficios, objetivos y metas que se espera alcanzar con el futuro

sistema. • Se referencian todos aquellos documentos de nivel superior (p.ej. Ingeniería de

Sistemas, que incluyen Hardware y Software, se debe mantener la consistencia con el documento de especificación de requisitos globales del sistema, si existe).

1.3 Definiciones, Acrónimos y Abreviaturas: En esta subsección se definen todos los términos, acrónimos y abreviaturas utilizadas en la ERS.

1.4 Referencias. Mostrá una lista completa de todos los documentos referenciados en la ERS.



2. Descripción General

En esta sección se describen todos aquellos factores que afectan al producto y a sus requisitos. No se describen los requisitos, sino su contexto. Esto permite definir con detalle los requisitos en la sección 3, haciendo que sean más fáciles de entender.

2.1 Perspectiva del Producto. Se debe relacionar el futuro sistema (producto software) con otros productos. Si el producto es totalmente independiente de otros productos, también debe especificarse aquí. Si la ERS define un producto que es parte de un sistema mayor, esta subsección relaciona los requisitos del sistema mayor con la funcionalidad del producto descrito en la ERS, y se identifican las interfaces entre el producto mayor y el producto aquí descrito. Se recomienda utilizar diagramas de bloques.

2.2 Funciones del Producto. Se muestra un resumen a grandes rasgos, de las funciones del futuro sistema. Por ejemplo, en una ERS para un programa de contabilidad, esta subsección mostrara que el sistema soportará el mantenimiento de cuentas, el estado de las cuentas y facilitará la facturación, sin mencionar el enorme detalle que cada una de estas funciones requiere. Las funciones deben mostrarse de forma organizada, y pueden utilizarse gráficos, siempre y cuando dichos gráficos reflejen las relaciones entre funciones y el diseño del sistema.

2.3 Características de los Usuarios. Se deben describir las características generales de los usuarios del producto, incluyendo nivel educacional, experiencia y experiencia técnica.

2.4 Restricciones. Describir las limitaciones que se imponen sobre los desarrolladores del producto. Políticas de la empresa

Limitaciones del hardware.

Interfaces con otras aplicaciones.

Operaciones paralelas.

Funciones de auditoría.

Funciones de control Lenguaje(s) de programación.

Protocolos de comunicación.

Requisitos de habilidad

Criticalidad de la aplicación.

Consideraciones acerca de la seguridad

2.5 Suposiciones y Dependencias. Describirá aquellos factores que, si cambian, pueden afectar a los requisitos. Por ejemplo, los requisitos pueden presuponer una cierta organización de ciertas unidades de la empresa, o pueden presuponer que el sistema correrá sobre cierto sistema operativo. Si cambian dichos detalles en la organización de la empresa, o si cambian ciertos detalles técnicos, como el sistema operativo, puede ser necesario revisar y cambiar los requisitos.

2.6 Requisitos Futuros. Esta subsección esboza futuras mejoras al sistema, que podrán analizarse e implementarse en un futuro.



3. Requisitos específicos.

Contiene los requisitos a un nivel de detalle; permitirá planificar y realizar las pruebas que demuestren si el sistema satisface, o no, los requisitos. Todo requisito aquí especificado describirá comportamientos externos del sistema, perceptibles por parte de los usuarios, operadores y otros sistemas. Esta es la sección más larga e importante de la ERS. Se deberán aplicar los siguientes principios:

El documento deberá ser perfectamente entendible por personas de muy distintas formaciones e intereses. Se referencian aquellos documentos relevantes que poseen alguna relación sobre los requisitos. Todo requisito deber ser unívocamente identificable mediante un código o sistema de numeración. Lo ideal, aunque en la práctica no siempre realizable, es que los requisitos posean las siguientes características:

• No ambiguos: Cada requisito tiene una sola interpretación. Para eliminar la ambigüedad

inherente a los requisitos expresados en lenguaje natural, se deberán utilizar gráficos o notaciones formales. En el caso de utilizar términos que, habitualmente, poseen más de una interpretación, se definirán con precisión en el glosario.

• Completos: Todos los requisitos relevantes han sido incluidos en la ERS. Conviene incluir todas las posibles respuestas del sistema a los datos de entrada, tanto valido como no valido.

• Consistentes: Los requisitos no pueden ser contradictorios. • Clasificados: Los requisitos pueden clasificarse por importancias (esenciales,

condicionales u opcionales) o por estabilidad (cambios que se espera que afecten al requisito). Esto sirve, ante todo, para no emplear excesivos recursos en implementar requisitos no esenciales.

• Verificables: La ERS es verificable si todos sus requisitos son verificables. Un requisito es verificable (testeable) si existe un proceso finito y no costoso para demostrar que el sistema cumple con el requisito. Un requisito ambiguo no es, en general, verificable. Expresiones como a veces, bien, adecuado, etc. introducen ambigüedad en los requisitos.

• Modificables: La ERS es modificable si se encuentra estructurada de forma que los cambios a los requisitos pueden realizarse de forma fácil, completa y consistente.

• Trazables: La trazabilidad hacia atrás indica el origen (documento, persona, etc.) de cada requisito. La trazabilidad hacia delante de un requisito R indica qué componentes del sistema son los que realizan el requisito R.

3.1 Interfaces Externas. Se describen los requisitos que afecten a la interfaz de usuario, interfaz

con otros sistemas (hardware y software) e interfaces de comunicaciones.

3.2 Funciones. Se especifican las acciones que deberá llevar a cabo el software (quizá es la sección más larga e importante del documento).

2.2.3 PMBOK. The Project Management Body of Knowledge (PMBOK) es un término que describe la suma de conocimientos dentro de la gestión de proyectos. El PMBOK incluye conocimiento de las prácticas tradicionales que se aplican ampliamente, así como conocimiento de las prácticas innovadoras y avanzadas que han visto un uso más limitado. El PMBOK, cuya referencia en español es Guía de Fundamentos de la Dirección de Proyectos, es una publicación del Instituto de Dirección de Proyectos (PMI) que es una organización sin fines de lucro de origen estadounidense y de presencia actual mundial



Las operaciones y proyectos difieren principalmente en que las operaciones están en curso y repetitivas mientras que los proyectos son temporales y únicos. Un proyecto así puede definirse en términos de sus características distintivas de un proyecto es un esfuerzo temporal emprendido para crear un producto o servicio únicos. Los proyectos son a menudo componentes críticos de la estrategia de negocio de la organización ejecutante. Por ejemplos:

• Desarrollar un nuevo producto o servicio. • Efectuar un cambio en la estructura, la dotación de personal, el estilo de una organización. • La creación o adquisición de un sistema de información nueva o modificada. • La construcción de un edificio o instalación. • Ejecución de una campaña para un cargo político. • Aplicación de un procedimiento nuevo negocio o proceso

PMBOK define proyecto como un esfuerzo temporal tomado para crear un producto, servicio o resultado único. Para enfocar el análisis de la gestión plantea la idea de la restricción desde tres perspectivas:

• Alcance: Describe claramente el objetivo del proyecto. • Tiempo: Enfoca el tiempo asignado al proyecto. • Costo: Observa el costo involucrado.

Las áreas de conocimiento en la gestión de proyectos son:

1. Alcance 2. Tiempos 3. Costos 4. Calidad 5. Recursos Humanos 6. Comunicaciones 7. Riesgos 8. Adquisiciones 9. Integración

Las áreas de dominio requerido por el equipo de proyecto son:

• Habilidades Interpersonales • Conocimiento y Habilidades de Gestión • Entendimiento del Entorno del Proyecto • Conocimiento aplicado en el Área, Estándares y Regulaciones



Fig. Relación entre Grupos de procesos y Áreas del Conocimiento

2.2.3.1 Estructura de la guía del PMBOK La traducción del ésta metodología del inglés al español se realizó como una guía base, dividida en secciones y capítulos. Sección I: Marco contextual de la dirección de Proyectos. Proporcionando una estructura básica para entender la dirección de proyectos.

Capítulo 1, Introducción. Define los términos clave y proporciona una descripción general del resto de la guía. Capítulo 2, Ciclo de vida del proyecto y Organización. Se refiere al entorno en el cual operan los proyectos.

Sección II: Norma para la dirección de proyectos. Especifica todos los procesos de dirección de proyectos que usa l equipo del proyecto para gestionar un proyecto.

Capítulo 3, Procesos de Dirección de proyectos. Describe los 5 grupos de procesos de direcciones de proyectos aplicables a cualquier proyecto y los procesos de dirección de proyectos que componen tales grupos.

Sección III: Áreas de conocimiento de la dirección de proyectos. Organiza los 44 procesos de dirección de proyectos de los grupos de procesos de dirección de proyectos, en 9 áreas de conocimiento.

Capítulo 4, Integración del proyecto. Procesos y actividades que forman parte de los diversos elementos de la dirección de proyectos, que identifican, definen, combinan, unen y coordinan dentro de los grupos de procesos de direcciones de proyectos. Se compone de los proceso de dirección de proyectos. Capítulo 5, Alcance del Proyecto. Describe los procesos necesarios para asegurarse de que el proyecto incluya todo el trabajo requerido para completar el proyecto satisfactoriamente.



Capítulo 6, Tiempo del proyecto. Procesos relativos a la puntualidad en la conclusión del proyecto. Capítulo 7, Costos del proyecto. Procesos involucrados en la planificación, estimación, presupuesto y control de costos de forma que el proyecto se complete dentro del presupuesto asignado. Capítulo 8, Calidad del proyecto. Aseguramiento del cumplimiento de los objetivos para los cuales el proyecto fue emprendido. Capitulo 9, Recursos Humanos. Describe los procesos que organizan y dirigen el equipo del proyecto. Capítulo 10, Comunicaciones del proyecto. Generación, recolección, distribución, almacenamiento y destino de la información en tiempo y forma. Capítulo 11, Riesgos del proyecto. Desarrollo de gestión de riesgos de un proyecto. Capítulo 12, Adquisiciones del proyecto. Procesos para comprar o adquirir productos, servicios o resultados, así como para contratar procesos de dirección.

2.3 CMMI

CMMI propone 5 distintos modelos de madurez de las organizaciones:

1. Inicial - Estado inicial donde el desarrollo se basa en la heroicidad y responsabilidad de los individuos.

o Los procedimientos son inexistentes o localizados a áreas concretas. o No existen plantillas definidas a nivel corporativo.

2. Gestionado - Se normalizan las buenas prácticas en el desarrollo de proyectos (en base a la experiencia y al método).

o En este nivel consolidado, las buenas prácticas se mantienen en los momentos de estrés.

o Están definidos los productos a realizar. o Se definen hitos para la revisión de los productos.

3. Definido - La organización entera participa en el proceso eficiente de proyecto software. o Se conoce de antemano los procesos de construcción de software. o Existen métodos y plantillas bien definidas y documentados. o Los procesos no solo afectan a los equipos de desarrollo sino a toda la organización

relacionada. o Los proyectos se pueden definir cualitativamente.

4. Cuantitativamente Gestionado o Se puede seguir con indicadores numéricos (estadísticos) la evolución de los proyectos. o Las estadísticas son almacenadas para aprovechar su aportación en siguientes

proyectos. o Los proyectos se pueden pedir cuantitativamente.

5. Optimizado o En base a criterios cuantitativos se pueden determinar las desviaciones más comunes y

optimizar procesos.



o En los siguientes proyectos se produce una reducción de costes gracias a la anticipación de problemas y la continua revisión de procesos conflictivos.

Áreas de procesos

Conjunto de prácticas relacionadas que son ejecutadas de forma conjunta para conseguir un conjunto de objetivos

Las áreas de proceso que ayuda a mejorar o evaluar CMMI son 25

Se agrupan en 4 categorías según su finalidad:

� Gestión de proyectos � Ingeniería � Gestión de procesos � Soporte a las otras categorías.

Áreas de proceso de CMMI (Capability Maturity Model Integration)

Área de proceso Categoría Nivel de madurez

Monitorización y control de proyecto Gestión de proyectos 2

Planificación de proyecto Gestión de proyectos 2

Gestión y acuerdo con proveedores Gestión de proyectos 2

Gestión de requisitos Ingeniería 2

Gestión de la configuración Soporte 2

Medición y análisis Soporte 2

Gestión calidad procesos y productos Soporte 2

Definición de procesos Gestión de procesos 3

Procesos orientados a la organización Gestión de procesos 3

Formación Gestión de procesos 3

Gestión integral de proyecto Gestión de proyectos 3

Gestión integral de proveedores Gestión de proyectos 3

Gestión de equipos Gestión de proyectos 3

Gestión de riesgos Gestión de proyectos 3

Integración de producto Ingeniería 3

Desarrollo de requisitos Ingeniería 3



Solución técnica Ingeniería 3

Validación Ingeniería 3

Verificación Ingeniería 3

Análisis y resolución de decisiones Soporte 3

Entorno organizativo para integración Soporte 3

Rendimiento de los procesos de la org. Gestión de procesos 4

Gestión cuantitativa de proyectos Gestión de proyectos 4

Innovación y desarrollo Gestión de procesos 5

Análisis y resolución de problemas Soporte 5

Modelo de Desarrollo de Software

PROPUESTA DE ESTÁNDAR (Proyecto)

El siguiente estándar está basado en los modelos ISO 15504 / SPICE, I SO 9000 – 3 y

CMMI con el objetivo de proveer las especificaciones para el desarrollo de software,

que permitan mostrar los niveles de madurez de los procesos para producir software.

El estándar se basa en la dimensión del proceso (tomada del modelo ISO

15504/SPICE), ajustando dicha dimensión a tres niveles (tomados del modelo CMMI),

los cuales son: Inicial, Definido y Optimizado.



Glosario de términos

Calidad

Si buscamos el significado etimológico de la palabra Calidad, la encontraremos en el Griego Kalos: Bueno, Hermoso, Apto, Favorable y en el Latín Qualitatem: Propiedad. Hablando de calidad podemos resaltar sus características estas pueden ser: Un requisito físico o químico, una dimensión, una temperatura, una presión o cualquier otro requerimiento que se use para establecer la naturaleza de un producto o servicio. La calidad no tiene un significado popular de lo mejor en el sentido absoluto, industrialmente quiere decir, mejor dentro de ciertas condiciones del consumidor, ya que es él, quien en última instancia determina la clase y la calidad del producto que desea. Teniendo en cuenta lo anterior la calidad de un producto puede definirse como:

“La resultante de una combinación de características de ingeniería y fabricación, determinante del grado de satisfacción que el producto proporcione al consumidor, durante su uso”. “Cumplir con las necesidades del cliente y exceder las expectativas en forma constante (siempre).” “Es lo que el cliente dice que necesita más lo que realmente necesita” “Suministrar bienes o servicios que no regresan, a clientes que si lo hacen “

"Es el conjunto de cualidades de una persona o cosa", "Cualidad" es lo que hace que una persona o cosa sea lo que es, por su propiedad, atributo, características, don, virtud, etc. Esta definición nos lleva a pensar en términos como confiable, servicial y durable, términos que en

realidad son características individuales que en conjunto constituyen la calidad del producto. Al

establecer lo que entendemos por calidad se exige un equilibrio entre estas características.

Se establecen para llevar a cabo la gestión de la calidad las siguientes definiciones para llegar comprender los conceptos relacionados a la Calidad en una empresa.

Análisis: Consiste en la interpretación del desempeño de los procesos para su control y mejora. De esta actividad deriva el conocimiento y aprendizaje organizacional. Auditoria de calidad: Consiste en la verificación del cumplimiento de las normas, metodología y procedimientos de los sistemas y procesos de calidad Documentación: Es el registro cotidiano del desempeño de los procesos y sistemas. Constituye el acervo de conocimientos de la organización y permite evaluar y mantener vigente la tecnología operativa. Estándar: Norma, medida de desempeño esperado, utilizado para evaluar o comparar acciones realizadas Efectividad: Se refiere a la capacidad para entregar resultados planeados. Eficiencia: Se refiere al logro de objetivos y al aprovechamiento de los recursos disponibles.



Indicador: Es un signo o medición de un fenómeno. Índice: Es la relación cuantitativa entre dos cantidades relacionadas con un mismo fenómeno. Modelo de calidad: Es una descripción de la interacción de los componentes de los principales elementos del sistema de administración de la organización. Se refiere al esquema predeterminado de referencia que define los sistemas y prácticas de calidad de la organización, congruentes con los Principios y Valores de Calidad. Sistema: Es un conjunto de elementos con un fin común, que se interrelacionan entre sí, formando un todo dinámico. Sistema de medición: Es el medio a través del cual se obtiene información sobre el desempeño de la organización, sus productos y servicios. Se integra por diversos elementos, entre los que se incluyen:

• Indicadores de control, efectividad, eficiencia y adaptabilidad/flexibilidad • Métodos de muestreo, frecuencias y responsables, medición, de calibración.

Política de calidad: Directrices y objetivos generales de una empresa relativos a la calidad, expresados formalmente por la dirección general. (Forma parte de las políticas generales de una organización. Aseguramiento de Calidad: Consiste en tener y seguir un conjunto de acciones planificadas y sistemáticas, implantadas dentro del Sistema de Calidad de la empresa. Estas acciones deben ser demostrables para proporcionar la confianza adecuada (tanto a la propia empresa como a los clientes) de que se cumplen los requisitos del Sistema de la Calidad. Cubre dos aspectos fundamentales y diferenciados, uno es el decidir la combinación de ingredientes que dará gusto apropiado (Ingeniería de la calidad), y otro el asegurar que nuestra producción tenga la combinación de ingredientes que considere apropiados (Control de calidad). La gestión de calidad: Tiene que ver con la organización interna que ejerce la determinación de los procesos productivos y de las características y cualidades de los productos, es decir es la gerencia o el manejo de los proceso productivos enfocada al mejoramiento continuo. Es el aspecto de la función general de la gestión que determina y aplica la política de la calidad, que incluye la planeación estratégica, la asignación de recursos y otras acciones sistemáticas en el campo de la calidad, tales como la planeación de la calidad, el desarrollo de actividades operacionales y de evaluación relativas a la calidad Control de Calidad: Realiza o participa en la caracterización de los nuevos productos en sus diferentes fases de desarrollo y en el establecimiento de las especificaciones de calidad de los mismos. Desarrolla, ejecuta o coordina la ejecución de los métodos de ensayo para determinar las características de calidad de las materias primas, materiales, productos intermedios y productos finales

• Diseña y realiza los estudios de estabilidad de los productos intermedios. • Participa en el desarrollo, ejecución y perfeccionamiento del Sistema de Calidad. • Técnicas y actividades de carácter operativo utilizadas para satisfacer los requisitos relativos a la

calidad.

En la terminología industrial Control, es el acto de delimitar responsabilidad y autoridad con el fin de

liberar la gerencia de detalles innecesarios, conservando los medios para asegurarse de que los

resultados sean satisfactorios.

Sistema de calidad: Es el conjunto de la estructura de organización de responsabilidades, de Procedimientos, de procesos y de recursos que se establecen para llevar a cabo la gestión de calidad.



Corresponde a las necesidades propias de una organización para satisfacer los objetivos de calidad propuesto

Calidad en TI

Documents

Transcript of Calidad en TI