Calidad en TI

Universidad Tecnolgica de Puebla
Antologa: Sistemas de Calidad en Tecnologas de la Informacin Versin 1. 0.0

Cuatrimestre: Septiembre Diciembre 2009
Sistemas de Calidad en Tecnologas de la Informacin
Versin: 1.0.0 Pgina 2 de 59
Introduccin
Desde el enfoque tradicional de calidad que haba sido centrarse nicamente en tratar de evitar que se produjesen fallos durante la fabricacin, se evolucion segn tres etapas: Control de calidad, Aseguramiento de la calidad, Gestin de la calidad total I. Control de Calidad
El control de calidad apareci en los aos 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 estndares) 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 despus de haber obtenido los resultados instalando sensores en aquellas fases que se quieren controlar. Lgicamente, cuantos ms controles se instalen ms se incrementaran en los costes derivados de dicho control.
Figura Representacin esquemtica 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 dems miembros de la organizacin no se consideraban directamente responsables de la calidad. II. Gestin 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 concepcin de la calidad presenta importantes implicaciones. 1. Est relacionada con las percepciones del cliente, que en gran medida son subjetivas. 2. Es un concepto dinmico, ya que es preciso adaptarse constantemente a las cambiantes necesidades de los clientes. 3. Al considerar el valor percibido, el precio se incorpora tambin 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 organizacin en el compromiso con la calidad, es decir, la calidad debe impregnar a todas las reas de la organizacin.
Ingeniera en Tecnologas de la Informacin y Comunicacin
Los objetivos que se persiguen con las polticas de gestin de la calidad son: 1. Satisfaccin del cliente. Constituye el objetivo prioritario. 2. Conseguir hacer las cosas bien a la primera. 3. Eliminar todo aquello que no aada valor. Evitar despilfarros. 4. Mejorar la capacidad de reaccin del sistema mediante: Productos y servicios personalizados. Desarrollo rpido de nuevos productos y servicios. Anticipacin a las necesidades del cliente. Como definicin de Gestin 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 organizacin (es decir, extendidas a toda la organizacin) 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 direccin y a travs de una completa participacin de todos los empleados. Principios de la gestin de la calidad Existe abundante documentacin que trata sobre los principios que rigen a la gestin de la calidad, aunque la esencia es la misma en casi todos los autores. Quiz la enumeracin ms 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. Participacin de todo el personal. Es el operario quien identifica las fuentes de variacin y propone mejoras; se hace responsable de su trabajo. 3. Mejora de los procesos. Se identifican y corrigen sistemticamente las fuentes de variacin. 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 organizacin 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 sistemticamente, que estn destinadas a obtener un proceso productivo que asegure que el producto o servicio satisfar los requerimientos de calidad. En definitiva, la filosofa que sustenta esta etapa es que la calidad se construye en los procesos: si cada proceso se realiza correctamente, no existe ningn 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 caracterstico 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 obtencin del producto final. Podramos 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 certificacin que evalan dicho sistema y en caso de cumplir los requerimientos de calidad necesarios, certifican a la organizacin. El objetivo de la certificacin es doble: 1. Alcanzar y mantener la calidad del producto o servicio para satisfacer al cliente. 2. Proporcionar garantas al cliente de que el producto o servicio que se le ofrece cumple unos determinados estndares 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 adecuacin. De esta manera se obtiene el Manual de Calidad. 2. Auditar el sistema para verificar que las disposiciones se estn 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 caractersticas prescritas. El papel de los especialistas del departamento de calidad se centra en realizar auditoras de calidad para comprobar que el personal acta 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 satisfaccin y fidelizacin.
Control de calidad Concepto de calidad Orientacin de la empresa Responsabilidad de la calidad Se acta porque... Aplicacin de la calidad Actuacin Actitud Participacin del personal Importancia de la participacin Generacin de valor aadido Materializacin Filosofa Conformidad con las especificaciones Produccin Depto. de calidad Se detecta un error Al producto Corregir el error Reactiva Slo Depto. de calidad No se espera participacin No est claro Plan de inspeccin Arreglo Aseguramiento de la calidad Aptitud para el uso Produccin Depto. de calidad + operarios Se intenta evitar el error Al proceso productivo Modificar el procedimiento Reactiva Depto. de calidad + operarios Importante Si Manual de calidad Prevencin GCT Satisfaccin del cliente Cliente Todos los miembros Hay objetivos A todos los procesos de la empresa Mejora continua Proactiva Toda la empresa Imprescindible Si Sistema de gestin Mejora
Existen entidades internacionales reconocidas, que se preocupan por realizar metodologas, normas, estndares, 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 Ingeniera de Software), IEEE (Institute of Electrical and Electronics Engineers - Instituto de Ingenieros Elctricos y Electrnicos), ISO (International Organization for Standarization - Organizacin Internacional de Estandarizacin) y tambin SPICE (Software Process Improvement and Capability dEtermination Mejoramiento de procesos de Software y determinacin de capacidad). La ISO presenta una coleccin de estndares enfocados a la calidad, siendo la ISO 9001 la que esta orientada al software en lo que se refiere al desarrollo y manutencin, y adicionalmente forma parte de la serie ISO 9000. La ISO 9000-3 (IBNORCA 1998) del ao 1997 es una gua al aplicar ISO 9001 del ao 1994 para el desarrollo, provisin y mantenimiento de software. Esta experimento nuevas versiones como es el caso de ISO 90003 del ao 2004 (ISO/IEC 2004) que es la gua de aplicacin de la ISO 9001 del ao 2000 para software de computadora. Otro estndar relacionado al software es la ISO/IEC 12207:1995 (ISO/IEC 1995) que establece un marco de referencia comn 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 Adquisicin 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 Adquisicin para CMMI). El IEEE presenta muchos estndares relacionados o involucrados con la calidad de software como son: 610.12-1990 que es el glosario estndar de terminologa de ingeniera de software, 730-1998 que es el estndar para planes de seguridad de calidad de software, 829-1998 estndares para documentar la evaluacin de software, 830-1998 practicas recomendadas para especificacin de requerimientos de software, 1012-1998 estndar para la verificacin y validacin de software, 1016-1998 practicas recomendadas para la descripcin de diseo de software, 1062a-1998 practicas recomendadas para la adquisicin de software y muchas otras ms. Otro estndar importante es SPICE (Software Process Improvement and Capability dEtermination) que tambin es conocido como ISO/IEC 15504 es un modelo de madurez de procesos internacional que proporciona un marco de trabajo para la evaluacin de procesos de software.
Unidad I Normas y estndares en proyectos de T.I. 1.1 ISO
1.1.1 ISO 9001

ISO 9001 es un conjunto estndares internacionales para sistemas de calidad. Diseado para la gestin y aseguramiento de la calidad, especifica los requisitos bsicos para el desarrollo, produccin, instalacin y servicio a nivel de sistema y a nivel de producto. Su primera publicacin fue en 1987, revisado en 1994 y actualizado en el ao 2000 (con el compromiso de hacer una revisin cada 5 aos). La primera versin de 1994 estableca un conjunto bsico de requisitos para el establecimiento y mantenimiento de la gestin del sistema y aseguramiento de la calidad de la ingeniera de software. Se concibe como una metodologa 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 retroalimentacin de los usuarios, el desarrollo de los modelos de evaluacin y mejora continua y las crticas especializadas hacen que se requiera un estndar que: Emplee una aproximacin de gestin basada en el proceso. Sea compatible con otros sistemas de gestin. 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 estndares es la siguiente: ISO 9000, Normas para la gestin y garanta de la calidad. ISO 9001, Modelo para la garanta de la calidad en diseo/desarrollo, produccin, instalacin y servicio. ISO 9002, Modelado para garantizar la calidad en produccin y servicios. ISO 9003, Modelos para garantizar la calidad en inspeccin final y pruebas. ISO 9004, Elementos y gestin del sistema de calidad, Directrices para la mejora del rendimiento. ISO 9011, Directrices para la auditoria de los sistemas de gestin de la calidad y/o ambiental.
ISO 9001 e ISO 9004 se han desarrollado como un par coherente de normas, complementndose. Mientras ISO 9001 se centra en la eficacia del sistema de gestin de la calidad para dar cumplimiento a los requisitos del cliente, ISO 9004 se recomienda para organizaciones que persiguen la mejora continua, sin afn certificador. El estndar se basa en un conjunto de Principios de Gestin de la Calidad: Enfoque al cliente, Liderazgo, Implicacin de todo el personal, Enfoque a procesos, Enfoque del sistema hacia la gestin, 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 Gestin de la Calidad (Requisitos generales y Requisitos de la documentacin) 2. Responsabilidad de la Gestin (Compromiso de la direccin, Enfoque al cliente, Poltica de la calidad, Planificacin,). 3. Gestin de los Recursos (Provisin de recursos, Recursos humanos, Infraestructura, Ambiente de trabajo). 4. Realizacin del Producto (Planificacin de la realizacin del producto, Procesos relacionados con los clientes, Diseo y desarrollo, Compras, Prestacin del servicio). 5. Medicin Anlisis y Mejora (Generalidades, Supervisin y Medicin, Control de servicio noconforme, Anlisis de datos, Mejora). Cabe mencionar que el enfoque de ISO 9000 est en los procesos de produccin, o sea de desarrollo en el caso de software. El fin de este tipo de estndar 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 estndar internacional para la evaluacin 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 caractersticas de calidad para productos de software. El estndar ISO-9126 establece que cualquier componente de la calidad del software puede ser descrito en trminos de una o ms de seis caracteristicas bsicas, las cuales son: funcionalidad, con fiabilidad y portabilidad; cada una de las cuales se detalla a travs de un conjunto de subcaractersticas que permiten profundizar en la evaluacin de la calidad de productos de software. La tabla 1.1 muestra la pregunta central de atiende cada una de estas caractersticas. Caractersticas Funcionalidad Confiablidad Usabilidad Eficiencia Mantenibilidad Portabilidad Pregunta central Las funciones y propiedades satisfacen las necesidades explcitas e implcitas; esto es, el que . . .? Puede mantener el nivel de rendimiento, bajo ciertas condiciones y por cierto tiempo? El software es fcil de usar y de aprender? Es rpido y minimalista en cuanto al uso de recursos? Es fcil de modificar y verificar? Es fcil 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 estndar internacional de evaluacin y determinacin de la capacidad y mejora continua de procesos de ingeniera del software, con la filosofa 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 colaboracin y tiene la innovacin, en comparacin con otros modelos, del proceso paralelo de evaluacin emprica del resultado. En 1991, ISO/IEC JTC1/SC7 aprueba un estudio para investigar la necesidad y los requisitos para un estndar de evaluacin del proceso software, llegando a la conclusin (1992) de que haba consenso internacional. El proceso de desarrollo y validacin emprica (proyecto SPICE) se ha alargado diez aos. En 1998 se publica la primera versin del estndar como Informe Tcnico (en 1995 se publica como borrador), evolucionando posteriormente hasta Estndar Internacional, con la realizacin de tres fases
de pruebas, la Fase 1 (1995) con la idea de validar la decisiones de diseo y usabilidad del borrador, la Fase 2 (1996-1998) que a los objetivos anteriores sumaba proveer de una gua de aplicacin y revisar la consistencia, validez, adecuacin, 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 estndar ISO. Tras los Trials comienza la fase de Benchmarking (actual fase), con la idea de recolectar datos de los procesos de evaluacin y analizarlos y comienza la publicacin de partes del estndar. La versin 1.0 inicialmente recoga treinta y cinco procesos agrupados en cinco categoras (ClienteProveedor, Ingeniera, Proyecto, Soporte y Organizacin). Sin embargo, la idea de expandir el mbito de aplicacin del estndar 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 evolucin del estndar para aceptar Modelos de Referencia de Procesos (PRMs) eliminando la inicial dimensin de procesos. La medida de capacidad (vase tabla 1.2), es aplicable a cualquier modelo de procesos plasmado en un PRM compatible con ISO 12207. Esto le confiere una infraestructura mucho ms abierta, facilitando la compatibilidad.
2 Id. Nivel de Capacidad Atributos de Proceso y Descripcin
Id
CL[0] CL[1]
Nivel de Capacidad
Incompleto Realizado PA.1.1
Atributos de Proceso y Descripcin

El proceso no est implementado o falla en alcanzar su propsito. No es fcil identificar los productos o salidas de los procesos. El propsito del proceso se logra generalmente, aunque no sea rigurosamente planificado ni llevado a cabo. Hay productos identificables que testifican el alcance del propsito. Realizacin del Proceso El proceso es gestionado y los entregables resultado de procedimientos especficos, planificados y seguidos, con requisitos de calidad, tiempo y recursos. Gestin de la Realizacin Gestin de los Productos del trabajo Un proceso realizado y gestionado usado un proceso definido, basado en un principio de buenas prcticas de ingeniera del software. Definicin del Proceso. Despliegue del Proceso. El proceso definido es puesto consistentemente en prctica dentro de lmites 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 Medicin del Proceso Control del Proceso Realizacin del proceso optimizada en la busqueda de las necesidades actuales y futuras del negocio. Objetivos cuantitativos de eficiencia y efectividad se establecen en funcin de los objetivos de la organizacin. Optimizacin puede llevar a estudiar y adoptar ideas innovadoras o productos tecnolgicos novedosos que incluyan y modifiquen el proceso definido Innovacin del Proceso. Optimizacin del proceso
Tabla 1.2. Modelo de Capacidad de Procesos.
CL[2]
Gestionado PA.2.1 PA.2.2 Establecido
CL[3] PA.3.1 PA.3.2 CL[4]
Predecible
PA.4.1 PA.4.2 CL[5] En optimizacin
PA.5.1 PA.5.2
1.2
CMMI (Modelo de Capacidad de Madurez de Integracin)
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 preocupacin es la reutilizacin del software. 1 - Estpido. Organizaciones obstructivas. Imponen procesos contra-productivos para impedir cualquier avance. Se concentran en desarrollar entornos de desarrollo y repositorios. 2 Luntico o Despectivo. Organizaciones desdeosas. Desprecian cualquier institucionalizacin de buenas prcticas. Su gran objetivo es la programacin automtica. 3 Sabotaje. Negligencia total, descrdito consciente de los esfuerzos de su propia gente en la mejora de proceso del software. Falta de recompensa y degradacin de las prestaciones. A continuacin se presentan algunos puntos clave para poder identificar si una organizacin se encuentra dentro de un nivel de capacidad de Inmadurez o dentro de un Nivel de Capacidad de Madurez. Proceso Inmaduro Personal. No est documentado. No es fcil 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. Proceso Maduro Es definido: Sistemtico. 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 estndares. Se mide: utilizacin, 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 Creacin Del Software
El departamento de defensa de los Estados Unidos tena muchos problemas con el software que encargaba desarrollar a otras empresas, los presupuestos se disparaban, las fechas alargaban ms y ms. Quin no se ha encontrado con este tipo de problemas si ha trabajado con una empresa de software? Como esta situacin les pareca intolerable convoc un comit de expertos para que solucionase estos problemas, en el ao 1983 dicho comit concluy "Tienen que crear un instituto de la ingeniera del software, dedicado exclusivamente a los problemas del software, y a ayudar al Departamento de Defensa". Convocaron un concurso pblico 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 ao 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 administracin de la calidad total Total Quality Management (TQM) por sus siglas en ingls. El modelo de capacidad de madurez (CMM), provee a las organizaciones de software una gua de cmo aumentar el control de sus procesos de desarrollo y mantenimiento de software. Fue diseado para guiar a las organizaciones de software en la seleccin de estrategias para el mejoramiento de procesos mediante la determinacin de la madurez de los procesos actuales e identificando los elementos ms crticos de la calidad de software y del mejoramiento de procesos. La arquitectura del modelo est compuesta por niveles que describen la madurez de la organizacin 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 tambin ayudan a una organizacin a priorizar sus esfuerzos de mejoramiento. ste concepto cuenta con cinco etapas evolutivas que se enfocan en la implementacin de prcticas de calidad. CMM es, en pocas palabras, una aplicacin de TQM para software Niveles de madurez Nivel 1 Inicial Nivel 2 Repetible Gestin de configuraciones Garanta de calidad Gestin subcontratacin del software Seguimiento y supervisin del proyecto Planificacin del proyecto Gestin de requisitos Revisiones peridicas Coordinacin entre grupos Ingeniera de productos de software Gestin de integracin del software Programa de formacin Definicin de procesos de la organizacin Ninguna reas Claves
Nivel 3 Definido
Enfoque del proceso de la organizacin Nivel 4 Gestionado Nivel 5 Optimizado Gestin de calidad de software Gestin cualitativa del proceso Gestin de cambios del proceso Gestin de cambios de tecnologa Prevencin de defectos
Para cada rea de proceso define un conjunto de buenas prcticas que habrn de ser: Definidas en un procedimiento documentado Provistas (la organizacin) de los medios y formacin necesarios Ejecutadas de un modo sistemtico, universal y uniforme(institucionalizadas) Medidas Verificadas
CMM: un modelo para la mejora de Procesos de Software

Objetivo: Mejorar la calidad de los procesos de desarrollo, gestin y mantenimiento de software Para conseguirlo se aplican las bases de la Gestin de la Calidad Total (Total Quality Management) en la Ingeniera del Software. Mejora la gestin de la calidad es, en gran medida, responsabilidad de la direccin 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
Despus de cuatro aos 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 - Integracin", 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 informticos. CMMI define un conjunto de reas clave del proceso, que describen las funciones de ingeniera del software que deben llevarse a cabo para el desarrollo de una buena prctica, agrupadas en cinco niveles inclusivos. Estos niveles sirven de referencia para el conocimiento del estado de la madurez del proceso del software en la organizacin. Mediante un amplio conjunto de mtricas se determina la calidad de cada una de las reas clave, obtenindose una visin precisa del rigor, la eficacia y la eficiencia de la metodologa de desarrollo de una organizacin productora de software.
Cada una de las reas est organizada en cinco secciones, denominadas caractersticas comunes. Todo esto con el objetivo de realizar algunas mejoras respecto al CMMI (SW-CMM) 1.2.2 Caractersticas comunes: Compromiso de realizacin Capacidad para llevarla a cabo Actividades que hay que realizar Medicin y anlisis Verificacin de la implementacin
1.3
IEEE (Instituto de Ingenieros en Electricidad y Electrnica)
Fundado en 1884, el Instituto de Ingenieros en Electricidad y Electrnica, Inc. (IEEE) se ha dedicado a ayudar a que ms de 320,000 profesionales y estudiantes de Ingeniera desarrollen su potencial en campos de la ingeniera elctrica. Es una asociacin tcnico-profesional mundial dedicada a la estandarizacin, entre otras cosas. Es la mayor asociacin internacional sin fines de lucro formada por profesionales de las nuevas tecnologas. Objetivos: Cientficos / Educativos: Promover el avance de las teoras y las prcticas de la electrotecnologa. Profesionales: Fomentar el progreso y el desarrollo profesional de su membresa. Con la sociedad: Mejorar la calidad de vida a travs de la aplicacin de la electro tecnologa. Promover el entendimiento de la electro tecnologa ante el pblico. Mediante sus actividades de publicacin tcnica, conferencias y estndares basados en consenso, el IEEE produce ms del 30% de la literatura publicada en el mundo sobre ingeniera elctrica, en computacin, telecomunicaciones y tecnologa de control, organiza ms de 350 grandes conferencias al ao en todo el mundo, y posee cerca de 900 estndares activos, con otros 700 ms bajo desarrollo. Su organizacin se ha hecho de manera regional dividida de la siguiente manera: 10 17 311 34 1,570 217 1,434 382 60 Regiones Consejos Secciones Sub-secciones Captulos Tcnicos Grupos Afines Ramas Estudiantiles Captulos Tcnicos de Ramas Estudiantiles Grupos Afines de Ramas Estudiantiles
Dentro de los Captulos Tcnicos ms importantes se encuentran los siguientes: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Circuitos y Sistemas Comunicaciones Computacin Educacin Compatibilidad Electromagntica Dispositivos Electrnicos Ingeniera en Medicina y Biologa Gerencia de Ingeniera Electrnica Industrial Aplicaciones Industriales
11. Ingeniera de Potencia 12. Comunicacin Profesional El IEEE promueve la creatividad, el desarrollo y la integracin, compartir y aplicar los avances en las tecnologas de la informacin, electrnica y ciencias en general para beneficio de la humanidad y de los mismos profesionales. Como parte de los Captulos Tcnicos estn los estndares y en software algunos de estos son: IEEE Std. 610.12-1990 IEEE Std. 1016-1998 IEEE Std. 1471-2000 IEEE Std. 1012-1998 IEEE Std. 1008-2002 IEEE Std. 1058-1998 IEEE Std. 730-1998 IEEE Std. 830-1998 IEEE Standard Glossary of Software Engineering Terminology IEEE Recommended Practice for Software Design Descriptions IEEE Recommended Practice for Architectural Description of Software Systems IEEE Standard for Software Verification and Validation IEEE Standard for Software Unit Testing IEEE Standard for Software Project Management Plans IEEE Standard for Software Quality Assurance Plans IEEE Recommended Practice for Software Requirements Specifications
1.3.1 Planificacin del aseguramiento de la calidad en un proyecto

Siguiendo el estndar IEEE (Std 1074/ 1991, estndar 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 financiacin y viabilidad del proyecto 3. Definir las metodologas, tcnicas y herramientas a utilizar 4. Planificar la gestin del proyecto de software Planificacin de Gestin del Proyecto de incluir y describir: El da a da del proyecto, con los correspondientes controles de auditoras y revisiones. La planificacin del aseguramiento de la calidad del software (SQA) La planificacin de la documentacin del proyecto. A partir del plan de gestin, 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 especfico para cada proyecto, siguiendo las directrices del MANUAL DE CALIDAD y de sus procedimientos y las normas requeridas por los clientes. Siguiendo el estndar 730/1984 (Estndar para planes de aseguramiento de la calidad del software), el plan debe incluir: Objetivos de la calidad del proyecto y enfoque adaptado para alcanzarlos Documentacin referenciada en el plan (manual, procedimiento, etc.) Gestin del aseguramiento de la calidad (organizacin, actividades y responsabilidades). Documentacin mnima exigida a los desarrolladores tanto del desarrollo del software (especificaciones, diseo, manuales de usuario, etc.) como de control (planes validacin y verificacin). Estndares que se deben aplicar obligatoriamente Actividades de revisin y auditoria. Gestin de la configuracin del software (mediante un plan de gestin especfico 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 cdigo, generadores de entornos de prueba, etc.), especificando sus objetivos y la manera de utilizarlas. Control de cdigo (almacenamiento y versiones), control de acceso a equipos y prevenciones de seguridad y control de las caractersticas del software de los suministros. Recogida, almacenamiento y mantenimiento de datos sobre el aseguramiento de la calidad.
Actividades de aseguramiento de la calidad. Segn el estndar IEEE 1074/1991, las tcnicas para el aseguramiento de la calidad son, principalmente tres: 1. Mtricas del software para controlar el proyecto 2. Verificacin y validacin del software (incluyendo pruebas y revisiones) en todas las fases del ciclo de vida 3. Gestin de la configuracin del software.
1.4
PSP (Personal Software Process)
Cmo se desarrollo el PSP? Despus de que Watts S. Humphrey condujera el desarrollo inicial de CMM para software, se decidi a aplicar los principios de CMM a los programas pequeos. Posteriormente, mucha gente preguntaba cmo aplicar CMM a las organizaciones pequeas o al trabajo de los equipos pequeos de software. Mientras que los principios de CMM se aplicaron a tales grupos, cada vez se volva ms necesaria la asesora para saber qu hacer. Fue entonces cuando Humphrey decidi personalmente utilizar los principios de CMM para desarrollar programas modulares para ver si dicho enfoque podra funcionar para convencer a los ingenieros de software a que adoptaran tales prcticas. Fue entonces en el desarrollo de estos programas modulares, cuando Humphrey utiliz personalmente todas las prcticas de CMM para que l subiera poco a poco hasta llegar al nivel 5. Poco despus l comenz a trabajar en el proyecto tiempo completo en abril de 1989, el Instituto de la Ingeniera de Software (SEI) hizo a Humphrey un colaborador del SEI, permitindole trabajar tiempo completo en la investigacin detallada de PSP. Durante los siguientes tres aos, l desarroll un total de 62 programas y defini cerca de 15 versiones de PSP. Utiliz los siguientes lenguajes de programacin: PASCAL y C++, para desarrollar cerca de 25.000 lneas de cdigo que ayudaran a darle la forma final a PSP. [SEI; 2002] De esta experiencia, l concluy que los principios de la administracin 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 despus escribi un libro que les proporcion a varios asociados el material necesario para ensear 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 tambin 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 Aeronutica de Embry. De acuerdo con las experiencias y los
datos que proporcionaron estos cursos, Humphrey realiz la revisin del libro de PSP y public la versin final a finales de 1994. [HUMPHREY; 95 ] Casi al mismo tiempo, Jim Over y Neil Reizer del SEI y Robert Powels de la compaa de Servicios Informativos Avanzados (AIS por sus siglas en ingls) desarrollaron el primer curso para entrenar a los instructores a ensear 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. estndares Un PSP es un marco de trabajo de medicin y anlisis que te ayuda a caracterizar tu proceso. Es tambin 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 deberas conocer tu propio rendimiento. Deberas medir, seguir y analizar tu trabajo. Deberas aprender de tus variaciones de tu rendimiento. Deberas incorporar esas lecciones a tu manera personal de hacer.
El diseo de PSP se basa en los siguientes principios de planeacin y de calidad [HUMPHREY; 95] Cada ingeniero es esencialmente diferente; para ser ms 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 ingeniera 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 planeacin 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 tamaos 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 mdulos de programas. 2. Definicin de requisitos o procesos. 3. Realizacin de revisiones o pruebas. 4. Escritura de documentacin, etc. 5. El PSP se puede extender al desarrollo de sistemas software de gran tamao. 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 pequeos 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 planificacin.
Existe un script de planificacin que sirve de gua 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 tamao 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 mtodos de PSP no son utilizados por los desarrolladores, los mtodos de PSP son presentados en una serie de siete versiones de procesos. Estas versiones son denominadas como PSP0 a PSP3. Cada versin 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 guan 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 ms a checklists que a tutoriales. Estos no incluyen los materiales instructivos que seran necesarios para usuarios no entrenados. El propsito 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 capacitacin en PSP o a travs de bibliografa introductoria en el uso de PSP).
PSP O. Proceso (punto de partida) PSP0 es un proceso sencillo, definido y personal. Utiliza tus mtodos actuales de diseo y desarrollo. Recoge datos sobre tu trabajo: 1. tiempo gastado por fase 2. defectos encontrados en compilacin 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 estndar de cdigo, mediciones de tamao y el denominado PIP (Process Improvement Proposal). El PIP provee una manera estructurada de registrar problemas, experiencias y sugerencias para mejorar. PSP0.1 tambin mejora las mediciones para contar separadamente mtodos y procedimientos.
PSP1 Planeacin personal PSP1 le agrega pasos de planeamiento a PSP0. El primer paso agrega estimaciones de tamao y recursos y un reporte de prueba. En PSP1.1 se introduce planeamiento de cronograma y seguimiento del proyecto. Los desarrolladores son enseados a: Entender la relacin entre el tamao 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 tcnicas en proyectos grandes es comprendida, pocos desarrolladores las aplican a su trabajo personal. PSP demuestra el valor de estos mtodos 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 avergenzan de sus errores. El hecho de que la mayora de los errores sean tipogrficos o errores tontos hace que los desarrolladores sientan que pueden mejorar haciendo ms esfuerzo. PSP2 agrega diseo personal y revisiones de cdigo 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 revisin que estn hechos a medida de su experiencia de defectos personales. El proceso de diseo es contemplado en PSP2.1. El objetivo no es decirle a los desarrolladores como disear sino orientar el criterio para la finalizacin del diseo, es decir, cuando han terminado que es lo que deben haber obtenido. Se establece un criterio de completitud de diseo y se examinan varias tcnicas de verificacin y consistencia de diseo. PSP3. Proceso cclico personal Hasta este punto PSP se concentr en el proceso lineal para construccin de pequeos programas. PSP3 presenta mtodos para ser usados por individuos en la realizacin de programas de gran escala. De todas formas sigue enfocado en el individuo y no trata los problemas de comunicacin y coordinacin que son una parte importante del desarrollo de sistemas de gran escala. Para escalar PSP2 a proyectos ms 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 diseados para ser desarrollados en pasos incrementales. La primera construccin consiste en un mdulo base o kernel que es ampliado en ciclos iterativos. En cada iteracin se utiliza un PSP2 completo, incluyendo diseo, codificacin, compilacin y pruebas.
El proceso cclico 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 verificacin de la calidad del ltimo incremento sin preocuparse por defectos en ciclos anteriores. Si un incremento anterior tiene muchos defectos, la prueba ser ms compleja y los beneficios de escalar PSP se pierden. Esta es una razn para enfatizar revisiones de diseo y cdigo en los pasos anteriores de PSP.
1.4.4 Planeacin del PSP

Te permiten llegar a acuerdos que t puedas cumplir Proporcionar las bases para acuerdo en tu trabajo Gua 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 planificacin es demasiado temprana como para hacer un diseo completo del producto, los desarrolladores realizan un diseo conceptual, mediante el cual se obtiene un primer acercamiento de cmo debe basarse el producto a ser construido en la etapa de desarrollo. La siguiente tarea consiste en la estimacin de tamao y de esfuerzo. La correlacin entre el tamao de un programa y tiempo de desarrollo es moderadamente buena para equipos de desarrollo; sin embargo, para un solo desarrollador, la correlacin es generalmente un poco mayor. Los desarrolladores realizan las estimaciones utilizando datos histricos personales de tamao y productividad. En PSP, las estimaciones se efectan mediante el mtodo 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 da de la semana, conformando entonces el calendario. Luego, durante la etapa de desarrollo del producto, los desarrolladores efectan el diseo detallado, la implementacin y las pruebas. Despus de completar el trabajo, los desarrolladores realizan un anlisis 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 informacin en sus bases de datos histricas de tamao y productividad. Adems se examinan las Propuestas de Mejoras (PIP) para hacer ajustes en los procesos.
1.4.5 Recoleccin de datos.

En PSP, los desarrolladores utilizan informacin 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 tamaos de los productos que producen, y de la calidad de esos productos. Las medidas bsicas de PSP son el tiempo que el ingeniero utiliza en cada fase del proceso, los defectos introducidos y encontrados en cada fase, y los tamaos de los productos desarrollados en lneas de cdigo (LOC). Estos datos se recopilan en cada fase del proceso y se resumen a la terminacin del proyecto. Todos estos datos se utilizan para proporcionar una familia de medidas de calidad de procesos que los ingenieros usan como gua en su trabajo. Las principales medidas son: Tamao tiempo de estimacin de errores Coste de realizacin Defectos producidos y corregidos por hora Produccin del proceso Valoracin y calidad del coste de los fallos (COQ)
Valoracin del rango de fallos (A/FR)
Elementos un guin de proceso un formulario resumen de plan proyecto un registro tiempo un registro de defectos un estndar de tipos defecto
No de Fase
Propsito Entradas Necesarias
Guiarte en el desarrollo de programas a nivel de mdulo Descripcin del problema Formulario de Resumen del plan del Proyecto PSPO Tablas de Registro de Tiempos y Defectos Cronometro (opcional) 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 Disear el programa Implementar el diseo Compilar el programa y corregir todos los defectos encontrados Completar la Tabla de Registro de Tiempos Completar el Resumen del plan del Proyecto con los datos actuales de tiempo, defectos y tamao Un programa probado Un resumen del Plan de Proyectos con los datos estimados y actuales Las tablas de Registro de Tiempos y Defectos Rellenos
Planificacin
Desarrollo
Post-mortem Criterios de salida
Planificacin: Desarrollo: Post-mortem: Diseo: Codificacin: Compilacin: Prueba:
Estimar tiempo de desarrollo. Desarrollar el producto utilizando tus mtodos actuales. Completar el resumen del plan proyecto, con los tiempos gastados y defectos encontrados e inyectados en cada fase. Disear el programa, usando tus mtodos de diseo actuales. Implementa el programa. Compila hasta que est libre defectos. 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.
Encabezado: Nombre, fecha, programa, instructor, lenguaje. Tamao del Programa: Plan. Indica tu mejor estimacin 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 nmero 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 nmero de programa.
Fecha: Inicio: Fin:
Indicar la fecha actual. Indicar el tiempo en minutos cuando empiezas una fase del proyecto 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 interrupcin: 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 interrupcin. Fase: Anotar la fase en la que ests trabajando. / Use el nombre de cada fase. Comentarios: Descripcin de la interrupcin. La tarea que ests haciendo. Cualquier aspecto significativo que afecte a tu trabajo
Fecha
Inicio
Fin
Tiempo de Interrupcin
Tiempo Delta
Actividad
Comentarios
9/9
9:00 12:40 2:45
9:50 1:18 3:53 12:19 9:50 2:35 5:11 9:50 1:16 3+8 25 10 6+5
50 38 58 62 50 69 28 50 38
Planeacin Diseo Diseo Codificacin Codificacin Compilacin Prueba Prueba Postmortem Consulta de un libro Reunin con mi jefe Telfono Bao, tom caf
10/9 11/9
11:06 9:00 1:15 4:18
13/9
9:00 12:33
1.4.6 Tamao
El tiempo en desarrollar un producto se encuentra altamente determinado por el tamao del mismo. En PSP, los desarrolladores primero estiman el tamao de los productos que planean desarrollar. Luego, al finalizar el producto, se mide el tamao real obtenido. Esta informacin permite a los desarrolladores realizar a futuro una estimacin de tamaos ms precisa. Sin embargo, para que esta informacin sea til, el tamao de las mediciones debe corresponderse con el tiempo de desarrollo del producto. En PSP, el tamao se mide en Lneas de Cdigo (LOC). Para realizar un seguimiento de la variacin del tamao de un programa durante el desarrollo, se deben considerar varias categoras de LOC. Estas son: Base (son los LOC iniciales del producto original) Agregadas (es el cdigo agregado a un programa base existente) Modificadas (es el cdigo base que es modificado en un programa existente) Eliminadas (es el cdigo base que es eliminado de un programa existente) Reutilizacin (es el cdigo tomado de una librera u utilizado, sin realizar ninguna modificacin, en un nuevo programa)
Nueva Reutilizacin (esta medida cuenta los LOC que se agregan a una librera) Total (es tamao total del programa, independientemente del cdigo fuente).
Luego, para medir el tamao total de un producto, el clculo es el siguiente: Total LOC = Base Eliminadas + Agregadas + Reutilizacin Las LOC modificadas y de nueva reutilizacin 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 reutilizacin ya se encuentran contabilizadas en las LOC agregadas. Logs de Registro de defectos El estndar de tipos de defectos proporciona un conjunto general de categoras de defectos. Aunque t puedes reemplazar este estndar 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 estndares se utilizaron para llenar los logs de Registro de defectos. A continuacin se muestra un ejemplo:
Encabezado: Indicar el nombre, fecha, instructor, y numero de programa. Fecha: Indicar la fecha cuando encontraste y corregiste el defecto. Nmero: Indicar un nmero nico para este defecto. Comienza cada proyecto con 1. Tipo: Indicar el tipo de defecto a partir del estndar 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 estimacin. Defecto Arreglado: Si este defecto fue inyectado durante la correccin de otro defecto, indicar el nmero 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 ms eficaz de encontrar y arreglar defectos es repasando el cdigo fuente del programa personalmente. Mientras esto puede parecer como una manera difcil de limpiar un programa defectuoso, resulta ser ms rpido y ms eficaz. Un mtodo para realizar revisiones de cdigo es la utilizacin de guas en las que se determina cuales son los defectos que ms frecuentemente se inyectan.
1.4.7 METRICAS DEL PSP

Con datos de tamao, 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 medicin por s sola puede indicar adecuadamente la calidad de un programa, el panorama que provee la utilizacin de todas estas mediciones es generalmente un indicador confiable de calidad. Las principales mediciones de calidad son: 1. Densidad de defectos 2. ndice de revisin 3. ndices de tiempo de desarrollo 4. ndices de defectos 5. Rendimiento 6. Defectos por hora 7. Efectividad de remocin de defectos 8. Evaluacin del ndice de fallas Resumen del registro de Mtricas Nombre: Programa Profesor Resumen Minutos/LOC LOC/Hora Defectos/KLOC Rendimiento A/FR Tamao Programa (LOC): Total nuevo & Cambiado Fecha: 18/10/96 Programa # 13 Lenguaje: C++ Actual a la Fecha 4,87 5,73 12,32 10,47 106,4 96,90
Plan 5,92 10,14 94,79
58
47
258
Tamao Mximo Tamao Mnimo Tiempo en fase (min.) Planing Diseo Cdigo Revisin cdigo Compilacin Test Postmortem Total Tiempo Mximo Tiempo Mnimo 243 Introduccin de defectos Planing Diseo Cdigo Revisin cdigo Compilacin Test Total
72 41 Plan 18 35 149 20 24 64 33 343 426 Plan 1 5
Actual 22 24 93 37 4 8 41 229
Para Fecha 88 151 637 111 92 240 160 1479
Para Fecha % 6,0 10,2 43,1 7,5 6,2 16,2 10,8 100
Actual Para Fecha 4 21 16,0 84,0
Para Fecha % Def/Hora
25
100,0
1.5
TSP (Team Software Process)
El resultado final es que incluso aunque un equipo de ingenieros est entrenado en PSP, todava les queda combinar sus procesos de trabajo personal dentro de un nico proceso de equipo. Esto es para ellos un problema, incluso en los ms altos niveles de CMMI. Por esta razn se ha desarrollado Team Software Process SM (TSPSM).
TSP extiende y refina los mtodos CMM y PSP, para guiar a los miembros de los equipos en el trabajo de mantenimiento y desarrollo. TSP les muestra cmo construir un equipo autodirigido y como ser un
efectivo miembro del equipo. Tambin les ensea cmo 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 adems sus propios procesos y planes. 2. Mostrar a los directores como entrenar y motivar a sus equipos mantenerles en el ms alto nivel de desarrollo. y como ayudarles para
3. Acelerar la mejora del proceso software haciendo normal la conducta del Nivel 5 de CMMI 4. Mejorar la direccin 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 planificacin de costos. Esto lo hace, ensendoles cmo planificar su propio trabajo y hacindoles participes de los planes y procesos que se van a llevar a cabo. TSP proporciona equipos de proyectos con guas explcitas sobre como alcanzar sus objetivos. TSP conduce al equipo a travs 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 ensea 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 das 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 mximo. Los miembros del equipo deben trabajar hacia un objetivo comn y tiene roles especficos o responsabilidades dentro del equipo. Existe una interdependencia entre el trabajo de los miembros del
equipo que requiere cooperacin para que el equipo sea exitoso y por lo mismo siguen un proceso de trabajo comn. Es importante que cada miembro del grupo sepa cul va a ser su funcin y sus responsabilidades, y debera comprobar si alguno de los miembros del grupo necesita ayuda. Adems 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 diseo conceptual para cada producto planificado y dividir en ciclos y documentar el trabajo. Adems 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 implementacin personal utilizando por ejemplo PSP. Esta planificacin y documentacin debe ser estndar 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 lmites de posibles valores de las variables, los datos ms crticos, etc. Adems se debe realizar un desarrollo explicito de las pruebas que se vayan a realizar y las revisiones de cdigo que se vayan a hacer. Todas las pruebas se deben planificar con anticipacin y establecer una forma estndar de realizarlas y documentarlas para solucionar los posibles problemas y errores que hayan producido. En la documentacin debe aparecer quien o quienes de los miembros del grupo son los encargados de realizar las pruebas y quines 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 debera contener: 1. 2. 3. 4. 5. 6. 7. El tamao del producto Las horas de desarrollo El rango de lneas de cdigo por hora (LOC/Hours) El rendimiento antes de la compilacin El rendimiento antes de las pruebas del sistema El nivel de defectos en la compilacin El nivel de defectos en todas las fases de pruebas
Adems de todo lo anterior expuesto, los grupos deberan aportar la relacin 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 aproximacin arriba-abajo, utilizando todo el tamao 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 estimacin usando mtodos 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 planificacin de las metas del proyecto, criterios de calidad y riesgos de las puestas en marcha. TSP requiere entrevistas peridicas donde se comparan los progresos con la planificacin del equipo en trminos de valores ganados y calidad. Si hay desviaciones con respecto a la planificacin, se pueden determinar las razones y tomar medidas para que se retorne otra vez a dicha planificacin. Es tambin
durante estas entrevistas peridicas, 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 direccin estn 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 peridicamente por el equipo. El TSP tambin requiere replanificacin de un proyecto, o ms tarde actualizacin, cuando las especificaciones del plan cambian. Esto significa que cuando estas especificaciones cambian a lo largo del proyecto, el equipo renegocia la planificacin, delibera la funcionalidad y si es necesario el coste. Finalmente, los problemas con la calidad pueden ser virtualmente eliminados usando TSP, ya que los mtodos de calidad usados son los mismos que los usados en PSP y que los ingenieros realizan individualmente cuando llevan a cabo sus revisiones, diseos y codificaciones.
1.5.3 Roles del TSP

La puesta en marcha de un proyecto TSP incluye los siguientes pasos: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Revisar con la direccin los objetivos del proyecto. Establecer los roles del equipo. Documentar los objetivos del equipo. Producir la totalidad de la estrategia de desarrollo. Definir los procesos de desarrollo del equipo. Planificar los soportes que se necesitan. Realizar una planificacin del desarrollo para el proyecto entero. Realizar una planificacin de la calidad y el conjunto de objetivos de calidad. Realizar una planificacin detallada para cada ingeniero para la siguiente fase. Unir las planificaciones individuales dentro de un plan de equipo Rebalancear el trabajo de equipo para conseguir un mnimo programa. Calcular los riesgos y asignar responsabilidades para cada clase de riesgo. 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 direccin. Una vez que el proyecto comienza, el equipo realiza semanalmente reuniones y peridicamente informa de ello a la direccin y al cliente. Despus 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
Caracterstica Propsito Metodologa Definicin Audiencia Cobertura
PSP Gerenciamiento y mejora de la calidad Prescriptiva Exacta Desarrolladores y gerentes Ciclo de vida del desarrollo
Inspecciones Mejora de la calidad Presciptiva Exacta Desarrolladores Verificacin y validacin
CMM Mejora del gerenciamiento Descriptiva Vaga Gerentes Gerenciamiento de proyectos
ISO900 Gerenciamiento de la calidad Descriptiva Vaga Gerentes Aseguramiento de la Calidad
Costo Calidad Implementacin Alcance Cuan Mensurable es
Muy bajo Muy alta Semanas Integral Muy Alto
Bajo Alta Das Estrecho Alto
Alto Baja Aos Ambiguo Bajo
Alto Baja Aos Ambiguo 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 estndar 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 prcticas para customizarlo al proceso de la organizacin, y aun as continuar conformando el acercamiento por RUP. Una vez definido el proceso, se la pone a disposicin de todos los miembros del equipo en su desktop. Esto hace que el proceso este accesible para todos, ayudando a asegurar la comunicacin y consistencia y evitando gastar el tiempo determinado cual es el prximo paso a seguir.
1.6 Administracin de Proyecto

Administrar un programa o proyecto complejo requiere una buena comprensin 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. Ingeniera La ingeniera de procesos es la base de este largo camino. Las disciplinas de ingeniera de administracin de requerimientos, anlisis, diseo, implementacin 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 lder del mercado a travs de la familia de productos de las Suites Rational. Esta solucin para todo ciclo de vida es un conjunto de herramientas integradas que, cuando son implementadas en un conjunto con las mejores prcticas definidas en el RUP, ayudan a las organizaciones a adherir al CMMI. Ambiente de Soporte El como hacer del rea de Procesos de Configuracin Management del CMMI puede ser alcanzada usando Unified Change Management ( UCM ), las mejores prcticas de Rational para encarar la administracin del cambio desde la formulacin del requerimiento al relase. El UCM en conjunto con el software Rational de configuracin management, Rational ClearCase y Rational ClearQuest, ayuda a alcanzar la mayora de los requerimientos del CMMI para configuracin 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 pequeos 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 tambin pueden ser utilizados para ayudar y acelerar la implantacin de CMMI, y directamente relacionados al nivel 5 del CMMI. Tambin Tiene el objetivo de presentar un abordaje para la implementacin del nivel 4 de CMMI usando PSP y TSP, en muy pequeas empresas (empresas de una incubadora, con 4 a 10 desarrolladores de software ). Toda la presentacin est basada en un caso real, conducido en Brasil, con 7 empresas de incubadoras. El PSP en comunicacin con el CMMI hace uso de un gran nmero de Formatos, los que son tiles para hacer un anlisis a fondo del programa a desarrollar. Los Formatos son los siguientes: Bitcora de Registro de Tiempo Transcurrido El tiempo empleado en cada fase y los defectos encontrados en cada fase, se calculan de forma especifica Bitcora del Registro de Defectos.- es promover la mejora continua cada vez que se haga un proyecto Resumen del Plan de Proyecto.- Rene las estimaciones y los datos reales que conforman al proyecto en toda amplitud para que al final realicen las comparaciones necesarias y exista un histrico de todos los proyectos realizados.
Unidad II
Calidad en proyectos de T.I. 2.1 ISO y MOPROSOFT
Introduccin MoProSoft es un modelo de calidad que permitir a la pequea y mediana empresa de desarrollo de software, el acceso a las prcticas de Ingeniera 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 prcticas basadas en los modelos y estndares 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 Mxico 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 Secretara de Economa, bajo un convenio con la Facultad de Ciencias de la UNAM. 2.1.1 Estrategias Promover exportaciones y la atraccin de inversiones Educacin y formacin de personal competente Contar con un marco legal promotor de la industria Desarrollar el mercado interno Fortalecer a la industria local Alcanzar niveles internacionales en capacidad de procesos 6.1 Formacin de instituciones de capacitacin y asesora en mejora de procesos. 6.2 Definicin de un modelo de procesos y de evaluacin apropiado para la industria de software mexicana. 6.3 Apoyo financiero para la capacitacin y la evaluacin de capacidad de procesos. 7. Promover la construccin de infraestructura fsica y de telecomunicaciones 1. 2. 3. 4. 5. 6.
Cul 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 organizacin. 2.1.2 Ventajas 1 2 3 Al tener prcticas integradas, que abarcan desde la gestin de negocio hasta el desarrollo y mantenimiento de software, las empresas tendran mayor control sobre su desempeo en el mercado. El costo de la incorporacin del nuevo personal podra disminuir si se enfocan la educacin y la capacitacin a un modelo nico. Las empresas pequeas, al seguir procesos similares, podran asociarse con mayor facilidad para afrontar proyectos de mayor envergadura.
La exportacin de servicios de software de las empresas mexicanas sera ms factible. Incluso se podra disminuir la necesidad de la intermediacin de las empresas trasnacionales, gracias a que Moprosoft considera las prcticas reconocidas internacionalmente.
2.1.3 Caractersticas: 1 2 3 4 5 Especfico para el desarrollo y mantenimiento de software. Fcil de entender (comprensible). Definido como un conjunto de procesos. Prctico y fcil de aplicar, sobre todo en organizaciones pequeas. Orientado a mejorar los procesos para contribuir a los objetivos del negocio y no simplemente ser un marco de referencia de certificacin. 6 Debe de tener un mecanismo de evaluacin o certificacin, que indique un estado real de una organizacin durante un periodo de vigencia especfico. 7 Aplicable como norma mexicana. 8 No costoso en su adopcin. 9 Ser la base para alcanzar evaluaciones exitosas con otros modelos o normas, tales como ISO 9000:2000 [1] o CMM1 V1.1[2]. 10 Es un modelo basado en tres categoras de procesos: 10.1 Alta Direccin 10.2 Gestin 10.3 Operacin
2.1.4 Arquitectura
Actividades de los directivos de la organizacin
Subprocesos de Gestin de Recursos: 1. Recursos Humanos y ambiente de trabajo 2. Bienes, Servicios e Infraestructura. 3. Conocimiento de la organizacin.
Proceso de Administracin de proyectos especficos Inicio Planeacin Realizacin Evaluacin Cierre
Proceso de Desarrollo y manto. de software. Ciclos de Desarrollo Fases de un ciclo Actividades de una fase
2.1.5 Patrn del proceso. Definicin del proceso. Proceso (Nombre) Categora (Nombre) Propsito Descripcin Objetivos Indicadores Metas cuantitativas Responsabilidad y autoridad
Procesos relacionados Entradas (Nombre, Fuente) Salidas (Nombre, Descripcin, Destino) Productos internos (Nombre, Descripcin) Referencias bibliogrficas (ISO9001:2000, SW-CMM 1.1, ISO 15504, otras)
Prcticas Roles involucrados y capacitacin Actividades (Rol, Actividad, Objetivo, Tareas) Diagrama de flujo de trabajo (actividades de UML) Verificaciones y validaciones (Actividad, Producto, Rol, Descripcin) Incorporacin a la Base de Conocimiento (Producto, Forma de aprobacin) Recursos de Infraestructura (Actividad, Recurso) Mediciones (Ejemplo de medicin por indicador) Capacitacin Situaciones excepcionales Lecciones aprendidas
Guas 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 estndares internacionales para los sistemas de gestin de la calidad. Contienen los lineamientos mnimos que debe tener una organizacin para que pueda ser reconocida mundialmente como gestora del aseguramiento de la calidad. 1. 2. 3. 4. ISO 9000 2000: Principios Bsicos y Vocabulario ISO 9001 2000: Requisitos del Sistema de Gestin de Calidad ISO 9004 2000: Gua para la Gestin de Calidad ISO 9011 2000: Gua para la Administracin y Conduccin de Auditoras Ambientales y de Calidad.
Indica como auditar los procesos que constituyen al sistema de gestin de la calidad. Las directrices tambin abarcan a un sistema de gestin ambiental o segn ISO 14001 / 96 2.2.1 ISO 9126. Calidad del software y mtricas de evaluacin. ISO 9126 es un estndar internacional para la evaluacin 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 abstraccin por seis caractersticas:
Funcionalidad: Atributos que se relacionan con la existencia de un conjunto de funciones y sus propiedades especficas. Las funciones satisfacen necesidades declaradas o implcitas [ISO 9126: 1991] Fiabilidad: Capacidad de un sistema para mantener su nivel de rendimiento Usabilidad: Esfuerzo necesario para el uso y la valoracin 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 especficas. [ISO 9126: 1991] Eficiencia: Es la relacin entre el nivel de prestaciones de un sistema y el volumen de recursos utilizados en condiciones declaradas. [ISO 9126: 1991]
Este estndar no proporciona mtricas ni mtodos de medicin, por lo que no son prcticas las mediciones directas de las caractersticas 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. Mtricas Externas ISO/IEC 9126-2 Parte3. Mtricas Internas ISO/IEC 9126-3 Parte4. Mtricas de Calidad en el uso ISO/IEC 9126-4
ISO 9126-1 Este estndar define la usabilidad como la capacidad de un producto software de ser comprendido, aprendido, usado y de ser atractivo para el usuario, en condiciones especficas de uso. Esta definicin 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 slo del producto, sino tambin del usuario. Atributos para poder estudiarla: Facilidad de aprendizaje Eficiencia Recuerdo en el tiempo Tasa de errores Satisfaccin
Mtodos de evaluacin de usabilidad Se pueden considerar dos grupos de UEM [Usability Evaluation Methods]: Los UEM empricos, donde participan: Usuarios Evaluadores Observadores Expertos en test
Los UEM analticos donde no tienen acceso los usuarios, incluyen un equipo de especialistas en usabilidad. Para el proceso de inspeccin se utilizan directrices o heursticas para realizar el proceso de inspeccin. Mtricas de usabilidad Por medicin se entiende el proceso de atribuir nmeros o smbolos a los atributos de las entidades en el mundo real. a travs de la medicin es posible juzgar lo que se mide. Una mtrica es la correspondencia del mundo real, a un mundo formal. Una mtrica es un valor numrico asignado a algn evento del mundo real, software, sitio web, aplicacin web, etc. Un atributo es la caracterstica de una entidad de tipo directo o indirecto, por ejemplo, links no operativos, microcdigo no accesible, etc. El uso de mtricas no limita la intervencin humana y ofrece una reduccin de la subjetividad en la evaluacin de calidad de un sitio o aplicacin web, etc. ISO 9126-2 Capacidad de anlisis y de cambio
9123-3 Mtricas internas para la evaluacin del software. ISO/IEC TR 9126-3:2003 Las mtricas 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.
Tablas de Mtricas Organizadas por caracterstica y subcaracterstica, cada mtrica contiene: 1. Nombre 6. Tipo de escala 2. Propsito 7. Tipo de medida 3. Mtodo de aplicacin 8. Fuente de medicin 4. Medidad, frmula y cmputo de datos 9. Referencia a ISO/IEC 12207 SLCP 5. Interpretacin del valor medido 10. Audiencia
Mtricas de Funcionalidad 1. 2. 3. 4. 5. Adecuidad Exactidud Interoperabilidad Seguridad Conformidad de la funcionalidad
Ejemplo de Mtrica de Adecuidad Nombre: Propsito: Mtodo de aplicacin: Medicin, frmula: Interpretacin: Tipo de escala: Tipo de medida: Completitud de implementacin funcional Qu tan completa est la implementacin funcional. Contar las funciones faltantes detectadas en la evaluacin y comparar con el nmero de funciones descritas en la especificacin de requisitos. X=1-A/B A=nmero de funciones faltantes B = nmero de funciones descritas en la especificacin de requisitos 0<=X<=1 Entre ms cercano a 1, ms completa. absoluta X=count/count A=count B = count Fuente de Especificacin de requisitos
medicin:
Diseo Cdigo fuente Informe de revisin
ISO/IEC 12207 SLCP: Audiencia:
Validacin Revisin conjunta Requeridores Desarrolladores
Mtricas de Fiabilidad 1. 2. 3. 4. Madurez Tolerancia a fallos Recuperabilidad Conformidad de la fiabilidad
Mtricas de Usabilidad 1. 2. 3. 4. 5. Entendibilidad Aprendibilidad Operatibilidad Atractivo Conformidad de la usabilidad
Mtricas de Eficiencia 1. Comportamiento en el tiempo 2. Utilizacin de recursos 3. Conformidad de la eficiencia Mtricas de Mantenibilidad 1. 2. 3. 4. 5. Analizabilidad Cambiabilidad Estabilidad Examinabilidad Conformidad de la mantenibilidad
Mtricas de Portabilidad 1. 2. 3. 4. 5. Adaptabilidad Instalabilidad Coexistencia Remplazabilidad Conformidad de la transportabilidad
Consideraciones al Utilizar las Mtricas 1. Interpretacin de las mediciones o Diferencia entre conextos de pruebas y de uso. o Validez de resultados: procedimientos, fuentes de evaluacin, validacin de datos. o Equilibrio de recursos de medicin. o Especificacin correcta. 2. Validacin de las mtricas o Propiedades deseables: confiable, repetible, reproducible, disponible, indicable, correcta, con significado. o Demostracin de validez: correlacin, rastreo, consistencia, predictibilidad, discriminacin. o 7 propiedades deseables en las mtricas o 7 propiedades deseables en las mtricas 3. Uso de mtricas para estimacin y prediccin 4. Deteccin de desviaciones y anomalas 5. Presentacin de resultados de medicin o Grficas de barras, matriz de desempeo, grficas de Pareto, grficas de correlacin, etc. Modelo de Medicin de la Calidad
Actividad 1 Actividad 2 Actividad 3 Fase Anlisis de requisitos Diseo de arquitectura Diseo detallado de software 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 Calidad en uso predicha Calidad externa predicha Calidad interna medida Calidad externa medida Calidad externa predicha Calidad interna medida Calidad en predicha Calidad externa medida Calidad externa predicha Calidad interna medida Entregables clave Requisitos de Requisitos de calidad externa Requisitos de calidad interna Diseo de Diseo detallado de software Cdigo y resultados de pruebas Producto y resultados de pruebas Sistema integrado y resultados de pruebas Sistema instalado Producto entregado 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 Codificacin software Integracin de software Integracin y pruebas de sistema Actividad 4 Actividad 5 Actividad 6 Actividad 7 Instalacin Aceptacin y apoyo Actividad 8
y pruebas de y pruebas
uso predicha uso
calidad del usuario arquitectura
Mtricas 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
Pasos Sugeridos 1. 2. 3. 4. 5. Identificacin de requisitos de calidad Especificacin de la evaluacin Diseo de la evaluacin Ejecucin de la evaluacin Retroalimentacin a la organizacin
Mtricas Internas Puras Trazabilidad Nmero ciclomtico Complejidad del flujo de informacin Modularidad Tamao del programa Enunciados condicionales Referencia unificada de datos Adecuidad de nombre de variables Proporcin de acomplamiento entre mdulos por datos Enunciados del programa Tamao promedio de mdulo Proporcin de acomplamiento entre mdulos por funciones
9126 -4 Mtricas de evaluacin de calidad Estas son las mtricas propuestas en el estndar: Mtricas relacionadas con la efectividad Mtricas relacionadas con la productividad Mtricas relacionadas con la seguridad Mtricas relacionadas con la satisfaccin
2.2.2 ISO 10006 ISO 10006 es una norma para la gestin de proyectos, su equivalente es llamado UNE-66916 (Octubre del 2003). La norma ISO 10006:2003, los sistemas de gestin de la calidad - Directrices para la gestin de la calidad en los proyectos, es una norma internacional elaborada por la Organizacin Internacional de Normalizacin. ISO 10006:2003 sirve de gua sobre la aplicacin de gestin de la calidad en los proyectos. Es aplicable a proyectos de distinta complejidad, la duracin de grandes o pequeos, de corto o largo, en diferentes ambientes, y con independencia del tipo de producto o proceso en cuestin. Esto puede requerir cierta adaptacin de la orientacin para adaptarse a un proyecto particular.
ISO 10006:2003 no es una gua para la "gestin de proyectos" en s. Orientacin sobre la calidad en los procesos de gestin del proyecto se discute en esta Norma Internacional. Orientacin 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 "Gestin de proyectos - Gua para la Gestin de Proyectos" es la norma ISO 21500 en preparacin (2008). Dado que la norma ISO 10006:2003 es un documento de orientacin, no est destinado a ser utilizado para propsitos de certificacin / registro.
2.2.3 ISO/IEC 27000 La serie de normas ISO/IEC 27000 son estndares de seguridad publicados por la Organizacin Internacional para la Estandarizacin (ISO) y la Comisin Electrotcnica Internacional (IEC). La serie contiene las mejores prcticas recomendadas en Seguridad de la informacin para desarrollar, implementar y mantener Especificaciones para los Sistemas de Gestin de la Seguridad de la Informacin (SGSI). La mayora de estas normas se encuentran en preparacin e incluyen: ISO/IEC 27000 - es un vocabulario estndar para el SGSI. Se encuentra en desarrollo actualmente. ISO/IEC 27001 - es la certificacin que deben obtener las organizaciones. Norma que especifica los requisitos para la implantacin del SGSI. Es la norma ms importante de la familia. Adopta un enfoque de gestin 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 cdigo de buenas prcticas para la gestin de seguridad de la informacin. 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 implementacin de un SGSI. Es el soporte de la norma ISO/IEC 27001. Se encuentra preparacin y probablemente sea publicada en 2009. ISO/IEC 27004 - son mtricas para la gestin de seguridad de la informacin. Es la que proporciona recomendaciones de quin, cundo y cmo realizar mediciones de seguridad de la informacin. Se encuentra preparacin y probablemente sea publicada en 2009. ISO/IEC 27005 - trata la gestin de riesgos en seguridad de la informacin. Es la que proporciona recomendaciones y lineamientos de mtodos y tcnicas de evaluacin de riesgos de Seguridad en la Informacin, en soporte del proceso de gestin de riesgos de la norma ISO/IEC 27001. Es la ms relacionada a la actual British Standard BS 7799 parte 3. Publicada en Junio de 2008. ISO/IEC 27006:2007 - Requisitos para la acreditacin de las organizaciones que proporcionan la certificacin de los sistemas de gestin de la seguridad de la informacin. Esta norma especfica requisitos especficos para la certificacin de SGSI y es usada en conjunto con la norma 170211, la norma genrica de acreditacin. * ISO/IEC 27007 - Es una gua para auditar al SGSI. Se encuentra en preparacin. ISO/IEC 27799:2008 - Es una gua para implementar ISO/IEC 27002 en la industria de la salud.
2.2
Estndares para documentacin de proyectos.
2.2.1 ISO/IEC,26514:2008
La documentacin 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 informacin se suministra en forma prctica y es fcil de encontrar y entender, el usuario rpidamente puede ser competente para utilizar el producto. Por lo tanto, una buena documentacin no slo ayuda al usuario a reducir el costo de formacin y apoyo, sino que tambin mejora la reputacin del producto, su fabricante y sus proveedores. La documentacin a menudo es considerada como algo que se hace despus de que el software ha sido implementado. Sin embargo, para documentacin 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 situacin son: ISO / IEC 15288:2008, sistemas y software de ingeniera - procesos del ciclo de vida del sistema. ISO / IEC 12207:2008, Sistemas y de ingeniera de software -- Procesos del ciclo de vida del software, el diseo y desarrollo de documentacin como parte del ciclo de vida del software procesos. Se define el proceso de documentacin desde el punto de vista del desarrollador de Documentacin. NOTA: otras normas internacionales en la familia ISO / IEC 265NN estn en preparacin o en proyecto para abordar la documentacin y los procesos de gestin de la informacin de los puntos de vista de los directivos, asesores y evaluadores, y de compradores y proveedores. Adems de definir un proceso estndar, esta norma Internacional tambin incluye la documentacin del producto. Esta norma internacional especifica la estructura, contenido y formato de la documentacin, y tambin proporciona informativas de orientacin para el estilo de documentacin del usuario. Sistemas e ingeniera de software - Requisitos para los diseadores y desarrolladores de documentacin de usuario mbito de aplicacin. Se define el alcance, propsito, la organizacin, utilizando candidatos de esta norma internacional. Esta Norma Internacional apoya el inters de los usuarios de software realizar documentacin coherente, completa, exacta, y til. La primera parte de esta norma internacional abarca el proceso de documentacin del usuario para los diseadores y los desarrolladores de la documentacin. En l se describe la forma de establecer la informacin que los usuarios necesitan, determina cmo preparar, presentar y asegurarse que la informacin est disponible a los usuarios. No se limita al diseo y desarrollo de la fase del ciclo de vida, sino que incluye actividades de toda la gestin de informacin y los procesos de documentacin. La segunda parte de esta norma internacional establece los requisitos mnimos para la estructura, el contenido y formato de la documentacin de usuario. Se aplica a los manuales de usuario impreso, ayuda en lnea, tutoriales y documentacin de referencia del usuario, estos pueden ser electrnicos o impresos. Esta Norma Internacional puede ser til para el desarrollo de los siguientes tipos de documentacin, aunque no cubre todos los aspectos de ellos: 1. Documentacin de otros productos de software; 2. Sistemas multimedia con animaciones de video y sonido; 3. Capacitacin basada en computadora (CBT) y los paquetes de materiales de los cursos especializados destinados principalmente para uso en programas de capacitacin formal;
4. Documentacin producida para los instaladores, operadores de computadoras, o el sistema de administradores. Documentacin de mantenimiento. 5. Describir el funcionamiento interno de sistemas de software. 6. Documentacin incorporada en la interfaz del usuario. Esta Norma Internacional tambin 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 documentacin del usuario. 3. Diseadores grficos con experiencia en medios de comunicacin electrnicos. 4. Diseadores de la interfaz de usuario y la ergonoma, expertos que trabajan juntos para disear la presentacin de la documentacin sobre la pantalla. El orden de las clusulas en esta norma no implica que la documentacin debe ser desarrollada o presentada al usuario en este orden. En el anexo A podemos observar una plantilla general para cubrir los apartados ms importantes de la norma.
2.2.2 IEEE 830.

Un buen Documento de requisitos, pese a no ser obligatorio que siga estrictamente la organizacin y el formato dados en el estndar 830, s debera incluir, de una forma o de otra, toda la informacin presentada en dicho estndar. El estndar de IEEE 830 no est libre de defectos por ello ha sido criticado por mltiples autores, llegndose a cuestionar incluso si es realmente un estndar en el sentido habitual que tiene el trmino en otras ingenieras. Con propsitos fundamentalmente docentes, se presenta cmo se organizara un Documento de Requisitos segn el estndar IEEE 830. Plantilla para IEEE 830 1. Introduccin En esta seccin se proporcionar una introduccin a todo el documento de Especicacin de Requisitos Software (ERS). Consta de varias subsecciones que se revisan a continuacin. 1.1 Propsito. Se define el propsito del documento ERS y se especicar a quin 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 describirn los benecios, objetivos y metas que se espera alcanzar con el futuro sistema. Se referencian todos aquellos documentos de nivel superior (p.ej. Ingeniera de Sistemas, que incluyen Hardware y Software, se debe mantener la consistencia con el documento de especicacin de requisitos globales del sistema, si existe).
1.3 Deniciones, Acrnimos y Abreviaturas: En esta subseccin se denen todos los trminos, acrnimos y abreviaturas utilizadas en la ERS. 1.4 Referencias. Mostr una lista completa de todos los documentos referenciados en la ERS.
2. Descripcin General En esta seccin se describen todos aquellos factores que afectan al producto y a sus requisitos. No se describen los requisitos, sino su contexto. Esto permite denir con detalle los requisitos en la seccin 3, haciendo que sean ms fciles 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, tambin debe especicarse aqu. Si la ERS dene un producto que es parte de un sistema mayor, esta subseccin relaciona los requisitos del sistema mayor con la funcionalidad del producto descrito en la ERS, y se identican 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 subseccin mostrara que el sistema soportar el mantenimiento de cuentas, el estado de las cuentas y facilitar la facturacin, sin mencionar el enorme detalle que cada una de estas funciones requiere. Las funciones deben mostrarse de forma organizada, y pueden utilizarse grcos, siempre y cuando dichos grficos reflejen las relaciones entre funciones y el diseo del sistema. 2.3 Caractersticas de los Usuarios. Se deben describir las caractersticas generales de los usuarios del producto, incluyendo nivel educacional, experiencia y experiencia tcnica. 2.4 Restricciones. Describir las limitaciones que se imponen sobre los desarrolladores del producto. Polticas de la empresa Limitaciones del hardware. Interfaces con otras aplicaciones. Operaciones paralelas. Funciones de auditora. Funciones de control Lenguaje(s) de programacin. Protocolos de comunicacin. Requisitos de habilidad Criticalidad de la aplicacin. 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 organizacin de ciertas unidades de la empresa, o pueden presuponer que el sistema correr sobre cierto sistema operativo. Si cambian dichos detalles en la organizacin de la empresa, o si cambian ciertos detalles tcnicos, como el sistema operativo, puede ser necesario revisar y cambiar los requisitos. 2.6 Requisitos Futuros. Esta subseccin esboza futuras mejoras al sistema, que podrn analizarse e implementarse en un futuro.
3. Requisitos especficos. 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 seccin ms larga e importante de la ERS. Se debern 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 relacin sobre los requisitos. Todo requisito deber ser unvocamente identificable mediante un cdigo o sistema de numeracin. Lo ideal, aunque en la prctica no siempre realizable, es que los requisitos posean las siguientes caractersticas: No ambiguos: Cada requisito tiene una sola interpretacin. Para eliminar la ambigedad inherente a los requisitos expresados en lenguaje natural, se debern utilizar grficos o notaciones formales. En el caso de utilizar trminos que, habitualmente, poseen ms de una interpretacin, se definirn con precisin 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 vericable (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, vericable. Expresiones como a veces, bien, adecuado, etc. introducen ambigedad en los requisitos. Modificables: La ERS es modicable si se encuentra estructurada de forma que los cambios a los requisitos pueden realizarse de forma fcil, completa y consistente. Trazables: La trazabilidad hacia atrs 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 seccin ms larga e importante del documento).
2.2.3 PMBOK.
The Project Management Body of Knowledge (PMBOK) es un trmino que describe la suma de conocimientos dentro de la gestin de proyectos. El PMBOK incluye conocimiento de las prcticas tradicionales que se aplican ampliamente, as como conocimiento de las prcticas innovadoras y avanzadas que han visto un uso ms limitado. El PMBOK, cuya referencia en espaol es Gua de Fundamentos de la Direccin de Proyectos, es una publicacin del Instituto de Direccin de Proyectos (PMI) que es una organizacin sin fines de lucro de origen estadounidense y de presencia actual mundial
Las operaciones y proyectos difieren principalmente en que las operaciones estn en curso y repetitivas mientras que los proyectos son temporales y nicos. Un proyecto as puede definirse en trminos de sus caractersticas distintivas de un proyecto es un esfuerzo temporal emprendido para crear un producto o servicio nicos. Los proyectos son a menudo componentes crticos de la estrategia de negocio de la organizacin ejecutante. Por ejemplos: Desarrollar un nuevo producto o servicio. Efectuar un cambio en la estructura, la dotacin de personal, el estilo de una organizacin. La creacin o adquisicin de un sistema de informacin nueva o modificada. La construccin de un edificio o instalacin. Ejecucin de una campaa para un cargo poltico. Aplicacin 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 anlisis de la gestin plantea la idea de la restriccin 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 gestin de proyectos son: 1. 2. 3. 4. 5. 6. 7. 8. 9. Alcance Tiempos Costos Calidad Recursos Humanos Comunicaciones Riesgos Adquisiciones Integracin
Las reas de dominio requerido por el equipo de proyecto son: Habilidades Interpersonales Conocimiento y Habilidades de Gestin Entendimiento del Entorno del Proyecto Conocimiento aplicado en el rea, Estndares y Regulaciones
Fig. Relacin entre Grupos de procesos y reas del Conocimiento
2.2.3.1 Estructura de la gua del PMBOK La traduccin del sta metodologa del ingls al espaol se realiz como una gua base, dividida en secciones y captulos. Seccin I: Marco contextual de la direccin de Proyectos. Proporcionando una estructura bsica para entender la direccin de proyectos. Captulo 1, Introduccin. Define los trminos clave y proporciona una descripcin general del resto de la gua. Captulo 2, Ciclo de vida del proyecto y Organizacin. Se refiere al entorno en el cual operan los proyectos. Seccin II: Norma para la direccin de proyectos. Especifica todos los procesos de direccin de proyectos que usa l equipo del proyecto para gestionar un proyecto. Captulo 3, Procesos de Direccin de proyectos. Describe los 5 grupos de procesos de direcciones de proyectos aplicables a cualquier proyecto y los procesos de direccin de proyectos que componen tales grupos. Seccin III: reas de conocimiento de la direccin de proyectos. Organiza los 44 procesos de direccin de proyectos de los grupos de procesos de direccin de proyectos, en 9 reas de conocimiento. Captulo 4, Integracin del proyecto. Procesos y actividades que forman parte de los diversos elementos de la direccin 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 direccin de proyectos. Captulo 5, Alcance del Proyecto. Describe los procesos necesarios para asegurarse de que el proyecto incluya todo el trabajo requerido para completar el proyecto satisfactoriamente.
Captulo 6, Tiempo del proyecto. Procesos relativos a la puntualidad en la conclusin del proyecto. Captulo 7, Costos del proyecto. Procesos involucrados en la planificacin, estimacin, presupuesto y control de costos de forma que el proyecto se complete dentro del presupuesto asignado. Captulo 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. Captulo 10, Comunicaciones del proyecto. Generacin, almacenamiento y destino de la informacin en tiempo y forma. recoleccin, distribucin,
Captulo 11, Riesgos del proyecto. Desarrollo de gestin de riesgos de un proyecto. Captulo 12, Adquisiciones del proyecto. Procesos para comprar o adquirir productos, servicios o resultados, as como para contratar procesos de direccin.
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 prcticas en el desarrollo de proyectos (en base a la experiencia y al mtodo). o En este nivel consolidado, las buenas prcticas se mantienen en los momentos de estrs. o Estn definidos los productos a realizar. o Se definen hitos para la revisin de los productos. 3. Definido - La organizacin entera participa en el proceso eficiente de proyecto software. o Se conoce de antemano los procesos de construccin de software. o Existen mtodos y plantillas bien definidas y documentados. o Los procesos no solo afectan a los equipos de desarrollo sino a toda la organizacin relacionada. o Los proyectos se pueden definir cualitativamente. 4. Cuantitativamente Gestionado o Se puede seguir con indicadores numricos (estadsticos) la evolucin de los proyectos. o Las estadsticas son almacenadas para aprovechar su aportacin en siguientes proyectos. o Los proyectos se pueden pedir cuantitativamente. 5. Optimizado o En base a criterios cuantitativos se pueden determinar las desviaciones ms comunes y optimizar procesos.
En los siguientes proyectos se produce una reduccin de costes gracias a la anticipacin de problemas y la continua revisin de procesos conflictivos.
reas de procesos Conjunto de prcticas 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 categoras segn su finalidad: Gestin de proyectos Ingeniera Gestin de procesos Soporte a las otras categoras.
reas de proceso de CMMI (Capability Maturity Model Integration) rea de proceso Monitorizacin y control de proyecto Planificacin de proyecto Gestin y acuerdo con proveedores Gestin de requisitos Gestin de la configuracin Medicin y anlisis Gestin calidad procesos y productos Definicin de procesos Procesos orientados a la organizacin Formacin Gestin integral de proyecto Gestin integral de proveedores Gestin de equipos Gestin de riesgos Integracin de producto Desarrollo de requisitos Categora Gestin de proyectos Gestin de proyectos Gestin de proyectos Ingeniera Soporte Soporte Soporte Gestin de procesos Gestin de procesos Gestin de procesos Gestin de proyectos Gestin de proyectos Gestin de proyectos Gestin de proyectos Ingeniera Ingeniera Nivel de madurez 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3
Solucin tcnica Validacin Verificacin Anlisis y resolucin de decisiones Entorno organizativo para integracin Rendimiento de los procesos de la org. Gestin cuantitativa de proyectos Innovacin y desarrollo Anlisis y resolucin de problemas
Ingeniera Ingeniera Ingeniera Soporte Soporte Gestin de procesos Gestin de proyectos Gestin de procesos Soporte
3 3 3 3 3 4 4 5 5
Modelo de Desarrollo de Software

PROPUESTA DE ESTNDAR (Proyecto)
El siguiente estndar 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 estndar se basa en la dimensin del proceso (tomada del modelo ISO 15504/SPICE), ajustando dicha dimensin a tres niveles (tomados del modelo CMMI), los cuales son: Inicial, Definido y Optimizado.
Glosario de trminos Calidad

Si buscamos el significado etimolgico de la palabra Calidad, la encontraremos en el Griego Kalos: Bueno, Hermoso, Apto, Favorable y en el Latn Qualitatem: Propiedad. Hablando de calidad podemos resaltar sus caractersticas estas pueden ser: Un requisito fsico o qumico, una dimensin, una temperatura, una presin 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 combinacin de caractersticas de ingeniera y fabricacin, determinante del grado de satisfaccin 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 ms 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, caractersticas, don, virtud, etc. Esta definicin nos lleva a pensar en trminos como confiable, servicial y durable, trminos que en realidad son caractersticas individuales que en conjunto constituyen la calidad del producto. Al establecer lo que entendemos por calidad se exige un equilibrio entre estas caractersticas.
Se establecen para llevar a cabo la gestin de la calidad las siguientes definiciones para llegar comprender los conceptos relacionados a la Calidad en una empresa. Anlisis: Consiste en la interpretacin del desempeo de los procesos para su control y mejora. De esta actividad deriva el conocimiento y aprendizaje organizacional. Auditoria de calidad: Consiste en la verificacin del cumplimiento de las normas, metodologa y procedimientos de los sistemas y procesos de calidad Documentacin: Es el registro cotidiano del desempeo de los procesos y sistemas. Constituye el acervo de conocimientos de la organizacin y permite evaluar y mantener vigente la tecnologa operativa. Estndar: Norma, medida de desempeo 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 medicin de un fenmeno. ndice: Es la relacin cuantitativa entre dos cantidades relacionadas con un mismo fenmeno. Modelo de calidad: Es una descripcin de la interaccin de los componentes de los principales elementos del sistema de administracin de la organizacin. Se refiere al esquema predeterminado de referencia que define los sistemas y prcticas de calidad de la organizacin, congruentes con los Principios y Valores de Calidad. Sistema: Es un conjunto de elementos con un fin comn, que se interrelacionan entre s, formando un todo dinmico. Sistema de medicin: Es el medio a travs del cual se obtiene informacin sobre el desempeo de la organizacin, sus productos y servicios. Se integra por diversos elementos, entre los que se incluyen: Indicadores de control, efectividad, eficiencia y adaptabilidad/flexibilidad Mtodos de muestreo, frecuencias y responsables, medicin, de calibracin. Poltica de calidad: Directrices y objetivos generales de una empresa relativos a la calidad, expresados formalmente por la direccin general. (Forma parte de las polticas generales de una organizacin. Aseguramiento de Calidad: Consiste en tener y seguir un conjunto de acciones planificadas y sistemticas, 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 combinacin de ingredientes que dar gusto apropiado (Ingeniera de la calidad), y otro el asegurar que nuestra produccin tenga la combinacin de ingredientes que considere apropiados (Control de calidad). La gestin de calidad: Tiene que ver con la organizacin interna que ejerce la determinacin de los procesos productivos y de las caractersticas 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 funcin general de la gestin que determina y aplica la poltica de la calidad, que incluye la planeacin estratgica, la asignacin de recursos y otras acciones sistemticas en el campo de la calidad, tales como la planeacin de la calidad, el desarrollo de actividades operacionales y de evaluacin relativas a la calidad Control de Calidad: Realiza o participa en la caracterizacin 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 ejecucin de los mtodos de ensayo para determinar las caractersticas de calidad de las materias primas, materiales, productos intermedios y productos finales
Disea y realiza los estudios de estabilidad de los productos intermedios. Participa en el desarrollo, ejecucin y perfeccionamiento del Sistema de Calidad. Tcnicas y actividades de carcter operativo utilizadas para satisfacer los requisitos relativos a la calidad.
En la terminologa 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 organizacin de responsabilidades, de Procedimientos, de procesos y de recursos que se establecen para llevar a cabo la gestin de calidad.
Corresponde a las necesidades propias de una organizacin para satisfacer los objetivos de calidad propuesto

Calidad en TI

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Calidad en TI

Transféré par

Droits d'auteur :

Formats disponibles

Universidad Tecnolgica de Puebla

Antologa: Sistemas de Calidad en Tecnologas de la Informacin Versin 1. 0.0

Sistemas de Calidad en Tecnologas de la Informacin

Versin: 1.0.0 Pgina 2 de 59

Figura Representacin esquemtica del proceso de control de calidad

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

Versin: 1.0.0 Pgina 3 de 59

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

Versin: 1.0.0 Pgina 4 de 59

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

Versin: 1.0.0 Pgina 5 de 59

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

Versin: 1.0.0 Pgina 6 de 59

Unidad I Normas y estndares en proyectos de T.I. 1.1 ISO

1.1.1 ISO 9001

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

Versin: 1.0.0 Pgina 7 de 59

1.1.2 ISO 9126

Tabla 1.1. Caracteristicas de ISO-9126 y aspecto que atiende cada una.

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

Versin: 1.0.0 Pgina 8 de 59

Atributos de Proceso y Descripcin

Gestionado PA.2.1 PA.2.2 Establecido

CL[3] PA.3.1 PA.3.2 CL[4]

PA.4.1 PA.4.2 CL[5] En optimizacin

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

Versin: 1.0.0 Pgina 9 de 59

CMMI (Modelo de Capacidad de Madurez de Integracin)

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

Versin: 1.0.0 Pgina 10 de 59

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

Versin: 1.0.0 Pgina 11 de 59

CMM: un modelo para la mejora de Procesos de Software

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

Versin: 1.0.0 Pgina 12 de 59

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

Versin: 1.0.0 Pgina 13 de 59

IEEE (Instituto de Ingenieros en Electricidad y Electrnica)

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

Versin: 1.0.0 Pgina 14 de 59

1.3.1 Planificacin del aseguramiento de la calidad en un proyecto

1.3.2 El plan de Aseguramiento de la calidad del software.

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

Versin: 1.0.0 Pgina 15 de 59

PSP (Personal Software Process)

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin

Versin: 1.0.0 Pgina 16 de 59

1.4.1 Principios PSP

Ingeniera en Tecnologas de la Informacin y Comunicacin

Sistemas de Calidad en Tecnologas de la Informacin