cmmi trabajo final

16
Facultad de Ciencias e Ingeniería CALIDAD DE SOFTWARE Alumnos: LEON DOMPER, Carlos VELA CHUNG, Hilary Catedrático: - César Palacios Chávez.

Upload: caledomper

Post on 02-Oct-2015

1 views

Category:

Documents


0 download

DESCRIPTION

Trabajo acerca del CMMI. Definicion y caracteristicas.

TRANSCRIPT

Facultad de Ciencias e Ingeniera

CALIDAD DE SOFTWARE

Alumnos: LEON DOMPER, CarlosVELA CHUNG, Hilary

Catedrtico:

Csar Palacios Chvez.

Contenido

Modelo de Capacidad y Madurez2I.NIVELES DE MADUREZ2SCAMPI - MTODO ESTNDAR DE EVALUACIN DE CMMI PARA MEJORA DE PROCESOS4I.OBJETIVOS4II.CLASES DE MTODOS5III.SCAMPI LEADER APPRAISER6ISO/IEC 155047I.LOS NIVELES DE MADUREZ7II.PUNTOS FUERTES Y PUNTOS DBILES8III.ASPECTOS COMUNES Y COMPARATIVAS DE MODELOS9INGENIERA DE REQUISITOS11I.FASES DE IMPLEMENTACIN11

MODELO DE CAPACIDAD Y MADUREZEl Modelo de Madurez de Capacidades o CMM (Capability Maturity Model), es un modelo de evaluacin de los procesos de una organizacin. Fue desarrollado inicialmente para los procesos relativos al desarrollo e implementacin de software por la Universidad Carnegie-Mellon para el SEI (Software Engineering Institute).El SEI es un centro de investigacin y desarrollo patrocinado por el Departamento de Defensa de los Estados Unidos de Amrica y gestionado por la Universidad Carnegie-Mellon. CMM es una marca registrada del SEI.Este modelo establece un conjunto de prcticas o procesos clave agrupados en reas Clave de Proceso (KPA - Key Process Area). 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 VerificadasI. NIVELES DE MADUREZA su vez estas reas de Proceso se agrupan en cinco niveles de madurez, de modo que una organizacin que tenga institucionalizadas todas las prcticas incluidas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel de madurez.Los niveles son:1. Inicial. Las organizaciones en este nivel no disponen de un ambiente estable para el desarrollo y mantenimiento de software. Aunque se utilicen tcnicas correctas de ingeniera, los esfuerzos se ven minados por falta de planificacin. El xito de los proyectos se basa la mayora de las veces en el esfuerzo personal, aunque a menudo se producen fracasos y casi siempre retrasos y sobrecostes. El resultado de los proyectos es impredecible.2. Repetible. En este nivel las organizaciones disponen de unas prcticas institucionalizadas de gestin de proyectos, existen unas mtricas bsicas y un razonable seguimiento de la calidad. La relacin con subcontratistas y clientes est gestionada sistemticamente.3. Definido. Adems de una buena gestin de proyectos, a este nivel las organizaciones disponen de correctos procedimientos de coordinacin entre grupos, formacin del personal, tcnicas de ingeniera ms detalladas y un nivel ms avanzado de mtricas en los procesos. Se implementan tcnicas de revisin por pares (peer reviews).4. Gestionado. Se caracteriza porque las organizaciones disponen de un conjunto de mtricas significativas de calidad y productividad, que se usan de modo sistemtico para la toma de decisiones y la gestin de riesgos. El software resultante es de alta calidad.5. Optimizado. La organizacin completa est volcada en la mejora continua de los procesos. Se hace uso intensivo de las mtricas y se gestiona el proceso de innovacin.As es como el modelo CMM establece una medida del progreso, conforme al avance en niveles de madurez. Cada nivel a su vez cuenta con un nmero de reas de proceso que deben lograrse. El alcanzar estas reas o estadios se detecta mediante la satisfaccin o insatisfaccin de varias metas claras y cuantificables. Con la excepcin del primer nivel, cada uno de los restantes Niveles de Madurez est compuesto por un cierto nmero de reas Claves de Proceso, conocidas a travs de la documentacin del CMM por su sigla inglesa: KPA. Cada KPA identifica un conjunto de actividades y prcticas interrelacionadas, las cuales cuando son realizadas en forma colectiva permiten alcanzar las metas fundamentales del proceso. Las KPAs pueden clasificarse en 3 tipos de proceso: Gestin, Organizacional e Ingeniera.Las prcticas que deben ser realizadas por cada rea Clave de Proceso estn organizadas en 5 Caractersticas Comunes, las cuales constituyen propiedades que indican si la implementacin y la institucionalizacin de un proceso clave es efectivo, repetible y duradero.Estas 5 caractersticas son: i) Compromiso de la realizacin, ii) La capacidad de realizacin, iii) Las actividades realizadas, iv) Las mediciones y el anlisis, v) La verificacin de la implementacin.Las organizaciones que utilizan CMM para mejorar sus procesos disponen de una gua til para orientar sus esfuerzos. Adems, el SEI proporciona formacin a evaluadores certificados (Lead Assesors) capacitados para evaluar y certificar el nivel CMM en el que se encuentra una organizacin. Esta certificacin es requerida por el Departamento de Defensa de los Estados Unidos, pero tambin es utilizada por multitud de organizaciones de todo el mundo para valorar a sus subcontratistas de software.Se considera tpico que una organizacin dedique unos 18 meses para progresar un nivel, aunque algunas consiguen mejorarlo. En cualquier caso requiere un amplio esfuerzo y un compromiso intenso de la direccin.Como consecuencia, muchas organizaciones que realizan funciones de factora de software o, en general, outsourcing de procesos de software, adoptan el modelo CMM y se certifican en alguno de sus niveles. Esto explica que uno de los pases en el que ms organizaciones certificadas existan sea India, donde han florecido las factoras de software que trabajan para clientes estadounidenses y europeos.

SCAMPI - MTODO ESTNDAR DE EVALUACIN DE CMMI PARA MEJORA DE PROCESOSPara llevar a cabo la evaluacin basada en CMMI el SEI ha diseado el Mtodo Estndar de Evaluacin de CMMI para Mejora de Procesos (Standard CMMI Appraisal Method for Process Improvement, SCAMPI), que consiste en una serie de mtodos formales para la evaluacin del modelo, que pueden usarse para evaluar: Si los procesos tal y como estn definidos son adecuados segn los requisitos de CMMI Cmo esos procesos se estn desplegando en la organizacin Cmo los procesos estn institucionalizados en la organizacinEl uso de SCAMPI nos permite: Comprender mejor el nivel de competencia en ingeniera de una organizacin, identificando los puntos fuertes y dbiles de sus procesos actuales. Relacionar esos puntos fuertes y dbiles con el modelo CMMI. Priorizar planes de mejora. Centrarse en las mejoras ms importantes que haya que acometer segn el nivel de madurez de la organizacin y de los recursos disponibles. Obtener para la organizacin su clasificacin en uno de los niveles del modelo. Identificar riesgos de desarrollo y adquisicin relativos a las limitaciones de la organizacin.I. OBJETIVOSLos objetivos de SCAMPI son: Proveer un mtodo de certificacin comn e integrado capaz de soportar certificaciones en el contexto de mejoras de procesos internos, seleccin de proveedores y monitoreo de procesos. Proveer un mtodo eficiente de certificacin capaz de ser implementado dentro de restricciones razonables de performance.Para poder cumplir con el mtodo de evaluacin SCAMPI, el trabajo se debe organizar en tres fases1. Planificar y preparar la certificacin: lleva de 3 a 5 meses2. Conducir la certificacin: ejecucin de la evaluacin y reportes los resultados preeliminares3. Reportar los resultados de la certificacin: reportes de los resultados finales.Las tareas a realizar dentro del SCAMPI son:1. Desarrollar un plan de certificacin.2. Determinar los indicadores de implementacin de las prcticas (PIIs)3. Entrevistas, con los empleados, gerencia y dems participantes.4. Seleccionar y preparar el equipo de certificacin.5. Obtener y analizar evidencia objetiva preeliminar6. Preparar una coleccin de evidencia objetiva.7. Examinar la evidencia8. Verificar y validar la evidencia9. Documentar la evidencia10. Generar reportes de los resultados de la evaluacin11. Publicar los resultados de la evaluacin12. Empaquetar y archivar los instrumentos de certificacin.Adelantndonos al prximo captulo, podemos decir que la herramienta a construir podr ser usada como apoyo para ejecutar varias de estas actividades, como por ejemplo para examinar la evidencia, documentar la evidencia, generar reportes etc.II. CLASES DE MTODOSEn funcin de su grado de adaptacin y rigurosidad se distingue entre: SCAMPI-C: Mide la idoneidad de los procesos, mediante entrevistas o revisin documental. Es el mtodo idneo para poder obtener una foto rpida del estado de los procesos en una organizacin para comenzar un programa de mejora de procesos. SCAMPI-B: Permite evaluar la idoneidad y el grado de despliegue de los procesos, mediante entrevistas o revisin documental. Es recomendable para hacer auditoras de los procesos de una organizacin antes de afrontar el proceso de certificacin con la evaluacin formal. SCAMPI-A: Es el ms formal que mide la idoneidad, despliegue e institucionalizacin de los procesos. Es el necesario para poder obtener un certificado de un determinado nivel de madurez.El mtodo formal de evaluacin SCAMPI-A tiene una serie de requisitos aadidos: Debe ser realizado por una persona acreditada por el SEI como SCAMPI Leader Appraiser Se debe formar un equipo de evaluacin (Assessment Team Members) de al menos 4 personas, y todos sus miembros deben haber pasado el curso oficial de introduccin a CMMI. El equipo de evaluacin debe tener una experiencia mnima (6 aos de experiencia media y 25 aos en total en desarrollo de software, 10 aos en gestin) en las disciplinas que son objeto de la evaluacin Para garantizar la objetividad de las evaluaciones, las personas que participan como equipo de evaluacin no pueden tener responsabilidad sobre los proyectos seleccionados y personas a entrevistar.A pesar de que el mtodo SCAMPI Clase A cumple con todos los requerimientos definidos por el SEI para esta clase de mtodos en el documento Appraisal Requirements for CMMI, (ARC) algunos casos de estudio han demostrado que el uso de este mtodo de evaluacin involucra altos costos y consume mucho tiempo para poder obtener resultados. Por tanto, no es factible para muchas organizaciones emplear una evaluacin Clase A, sobre todo en pequeas organizaciones, por lo que para estos casos una evaluacin Clase B o C es la ms adecuada.Todos los SCAMPIs deben ser supervisados por agentes autorizados del SEI, inclusive C y B para garantizar interpretaciones correctas y autorizadas.III. SCAMPI LEADER APPRAISERLas evaluaciones de las organizaciones se llevan a cabo por supervisores de evaluacin externos que tienen la autorizacin del SEI. Estos supervisores han recibido la formacin necesaria y tienen acceso a mtodos de evaluacin, materiales de formacin, asistencia tcnica y actualizacin formativa proporcionados por el SEI. A travs de su participacin en evaluaciones de organizaciones y de los mecanismos de realimentacin previstos en los mtodos de evaluacin, los supervisores de evaluacin contribuyen a la mejora continua de la tecnologa de evaluacin del SEI.Para que un profesional tenga la consideracin de supervisor de evaluacin SCAMPI debe estar en posesin del informe favorable que acredite que ha superado el plan formativo para supervisores de evaluacin diseado por el SEI. Para acceder a esta formacin son necesarios los siguientes requisitos:1. El SEI debe haber aceptado como asociada para servicios de evaluacin SCAMPI a la organizacin a la que el profesional pertenezca.2. Completar con xito el proceso de seleccin, acreditando los conocimientos mnimos requeridos. Se exige haber formado parte de un equipo de evaluacin SCAMPI en al menos dos evaluaciones en los dos aos inmediatamente anteriores a la solicitud.3. Aprobar un curso de introduccin a CMMI.4. Aprobar un curso de conocimientos intermedios de CMMI.

ISO/IEC 15504El ISO/IEC 15504, tambin conocido como Software Process Improvement Capability Determination, abreviado SPICE, en espaol, Determinacin de la Capacidad de Mejora del Proceso de Software es un modelo para la mejora, evaluacin de los procesos de desarrollo, mantenimiento de sistemas de informacin y productos de software.Este modelo establece conjuntos predefinidos de procesos con objeto de definir un camino de mejora para una organizacin. En concreto, establece 6 niveles de madurez para clasificar a las organizaciones. Al ser un modelo para el desarrollo software, toma como base el modelo de procesos ISO/IEC 12207:2008 (Systems and software engineering -- Software life cycle processes).I. LOS NIVELES DE MADUREZLa norma ISO 15504 permite realizar evaluaciones usando niveles de madurez, la evaluacin ms extendida en la actualidad.Los niveles de madurez son conjuntos predefinidos de procesos que ayudan a una organizacin a mejorar en el desarrollo software evolucionando por los distintos niveles.En este modelo, se han establecido 6 niveles, y en cada nivel se ha definido una serie de procesos que indican la madurez de la organizacin. Como se observa en la siguiente tabla, el nivel inferior (nivel 0) se corresponde con una organizacin inmadura, los siguientes niveles van haciendo crecer a la organizacin en su madurez, hasta el mximo nivel, el nivel 5.NivelEstado

Nivel 0 - Organizacin inmaduraLa organizacin no tiene un implementacin efectiva de los procesos

Nivel 1 - Organizacin bsicaLa organizacin implementa y alcanza los objetivos de los procesos

Nivel 2 - Organizacin gestionadaLa organizacin gestiona los procesos y los productos de trabajo se establecen, controlan y mantienen

Nivel 3 - Organizacin establecidaLa organizacin utiliza procesos adaptados basados en estndares

Nivel 4 - Organizacin predecibleLa organizacin gestiona cuantitativamente los procesos

Nivel 5 - Organizacin optimizandoLa organizacin mejora continuamente los procesos para cumplir los objetivos de negocio

La consecucin de los niveles de madurez es de forma escalonada, esto significa que para alcanzar un determinado nivel de madurez deben haberse alcanzado tambin los niveles inferiores.

II. PUNTOS FUERTES Y PUNTOS DBILESComo ha quedado recogido en los apartados anteriores, SPICE ha sido un proyecto de lenta maduracin, que ha variado mucho desde su borrador inicial en 1995, hasta los modelos que estn acabando de ser publicados. Muchas de las crticas o mejoras propuestas a lo largo de estos aos por diversos autores, han sido recogidas as como ciertos aspectos positivos (como la representacin continua del modelo) han sido adoptadas por otros.Cabe destacar el considerable nmero de estudios de evaluacin emprica realizados, pudiendo revisar sus conclusiones ms significativas en [33], en cuanto a validez predictiva, veracidad de la capacidad, demostracin de su capacidad para identificacin de fuerzas, debilidades y riesgos as como dirigir y priorizar el proceso de mejora.Segn ISO 9001, evaluando su versin 1.0, sus mayores contribuciones han sido:Primer modelo de procesos de 2 dimensiones, dimensiones independientes para los procesos y la capacidad.El resultado de una evaluacin de proceso puede ser representado por un perfil de proceso, una grfica de 2 dimensiones.Inicialmente recoga una escala refinada de procesos de 9 atributos y 6 niveles, que posteriormente fue mejorada con la desaparicin de la escala de procesos y la adopcin de los PRMs.Define un conjunto de criterios de conformidad para permitir la comparacin de modelos externos de procesos y encontrar requisitos comunes.Por el contrario, temas abiertos eran:Pensaba que el dominio de procesos debera ser ms amplio para abarcar todos los posibles ciclos de vida (algo no necesario por la adopcin de modelos externos, los PRMs) y que era difcil que todos los atributos de proceso fueran universales, aplicables a todos los procesos y prcticas base.La dimensin capacidad ha alcanzado un alto grado de dificultad y existen solapamientos con la dimensin procesos.La complejidad de las evaluaciones (y por consiguiente el costo) es significativa-mente ms alta que en otros modelos. Por ltimo, en sus conclusiones, al valorar el panorama de distintos estndares existentes, afirma la necesidad de pruebas de la efectividad y el impacto de la adopcin de estos modelos de mejora tanto en la ingeniera del software como en otros campos y resalta la necesidad de bsqueda de integracin y facilidad para la evolucin que deben adoptar los estndares, aspectos que, aunque no lo recoja el autor, estn resueltos por SPICE frente a otros modelos.En el Modelo de Capacidad de Procesos se afirma que el desarrollo de ISO 15504 ha acercado a lo mejor de los expertos internacionales en evaluacin de procesos, y a travs de la sinergia de estas relaciones ha llevado a significativos avances en el estado del arte y en la argumentacin terica del proceso.III. ASPECTOS COMUNES Y COMPARATIVAS DE MODELOSAqu pretendemos reflexionar sobre la esclavitud creativa de los estndares, la base terica o rigurosidad formal de los modelos, sobre las comparativas existentes entre modelos, as como recoger documentos que realizan mapeos entre modelos.Hay una corriente de autores que consideran que los estndares reducen la autonoma de los desarrolladores, siendo experimentada como una carga, restricciones coercitivas, ahogando la creatividad requerida en el desarrollo de software innovador, veneran al proceso, ignorando a las personas. Frente a esta postura, est la que defiende que esta interdependencia (frente al trabajo autnomo) toma una forma colaborativa, niveles de proceso maduros llevan a un proceso de desarrollo ms socializado, el esfuerzo colaborativo aumenta la eficiencia y efectividad.Otra crtica habitual es que muchas veces en el mbito de la mejora de procesos, los medios se olvidan del fin. Debe evitarse que el verdadero objetivo de mejorar el pro-ceso se desplace a la misin artificial de alcanzar un mayor nivel de madurez.Tambin se critica la ausencia de base terica formal y la vaguedad del soporte emprico. Aunque la aparicin de la Teora de la Evaluacin, un marco terico de propsito general que define los diferentes tipos de mtodos de evaluacin y sus parmetros, ha aportado resultados iniciales esperanzadores, ninguno de los actuales mtodos de evaluacin, la siguen. En este ltimo estudio aparece una comparativa de rigurosidad formal de los modelos ms difundidos as como un experimento de aplicacin comparativa.Por otro lado, es difcil discernir en el estudio de los resultados empricos, la parte correspondiente de la mejora a la aplicacin de un estndar, en lugar de otro.No existen comparativas actualizadas entre los modelos estudiados, por lo que, como referencia, se aportan una taxonoma comparativa y una recopilacin de estudios comparativos, tanto cuantitativos como cualitativos, econmicos y tcnicos de diferentes estndares.En cuanto a comparativas y mapeos entre reas clave, con la desaparicin de la dimensin Proceso, esta carece de sentido con SPICE por lo que entre ISO 9001 y CMM destacaremos a organizaciones de desarrollo software. Destaca la sinergia entre ambos y el que cada vez ms compaas consideren el uso conjunto de CMMI e ISO 9000 para aumentar la eficacia del proceso de mejora.A modo de resumen, presentamos un cuadro comparativo con las principales caractersticas de cada modelo:ISO 9001:2000CMMIISO 15504

mbito de aplicacinGenricoSoftware y SistemasSoftware y Sistemas

En su favorEl ms extendido y sencilloEl de mayor prestigioMs consensuado y probado

En su contraSimple, general, no gua paso a pasoDifcil de entender, mayor inversin, prescriptivoDifcil en capacidad, complejo para evaluar

ProcesosEstructura propiaEstructura propiaDelega en ISO 12207, por mayor aplicabilidad

ValidacinEncuestas satisfaccinEncuestas satisfaccin y casos de estudioTrials y esfuerzo emprico

ObjetivoCumplimiento de requisitos de calidad por procesosMejora del proceso, determinacin capacidad contratistaValoracin del proceso y gua para la mejora.

RepresentacinPlanaContinua y por etapasContinua (por etapas a nivel de proceso)

Tcnicas anlisisGuas y listas de comprobacinCuestionarios de evaluacinVarios

Mtodo para mejora de procesosNinguno, gua ISO 9004IDEAL, mapa guiadoSPICE 4 Parte

INGENIERA DE REQUISITOSEn la ingeniera de sistemas y la ingeniera de software, la Ingeniera de requisitos o Ingeniera de requerimientos comprende todas las tareas relacionadas con la determinacin de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de las partes interesadas, que pueden entrar en conflicto entre ellos.Muchas veces se habla de requerimientos en vez de requisitos; esto se debe a una mala traduccin del ingls. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al ingls como request.El propsito de la ingeniera de requisitos es hacer que los mismos alcancen un estado ptimo antes de alcanzar la fase de diseo en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigedades o contradicciones, etc.I. FASES DE IMPLEMENTACINDesde un punto de vista conceptual, las actividades son de cinco clases. Obtener requisitos: a travs de entrevistas o comunicacin con clientes o futuros usuarios, para saber cules son sus expectativas. Analizar requisitos: detectar y corregir las carencias o falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados en el diseo. Documentar requisitos: igual que todas las etapas, los requisitos deben estar debidamente documentados. Verificar los requisitos: consiste en comprobar la implementacin de los requerimientos. Validar los requisitos: comprobar que los requisitos implementados sean funcionales para lo que inicialmente se construy el producto.1