Reporte de Investigación - CIMATyolanda/cursos/semestre2/ingenieria/Proyecto/reporte.pdfReporte de Investigación Yolanda de Lira Domínguez Temas de Investigación: CMMI CMMI vs

Centro de Investigación en Matemáticas, A Page 1 of 25

file://\\Yolanda\yolanda\my web page\ReporteProyecto.htm 5/26/03

Centro de Investigación en Matemáticas, A. C.

Proyecto de Tópicos Selectos de Programación II

Reporte de InvestigaciónYolanda de Lira Domínguez

Temas de Investigación:

CMMI CMMI vs. CMM CMMI vs. SPICE Software Architecture Software Architecture in CMMI

Mayo del 2002





Contenido

1 Introducción1.1 Descripción del tema seleccionado

1.2 Motivación e interés en la selección del tema

1.3 Metodología de Clasificación

1.4 Dificultades

2 Estado del Arte2.1 Resumen de los artículos seleccionados

2.2 Crítica personal de los artículos

3 Conclusiones2.3 Tendencias futuras

2.4 Beneficios obtenidos de la investigación

4 Referencias



1 Introducción



1.1 Descripción del tema seleccionado

El proyecto CMMI es un esfuerzo cooperativo de el Departamento de Defensa, industria y el Instituto de Ingeniería de Software (SEI). Provee modelos para lograr la mejora de productos y procesos. El proyecto se enfoca principalmente en construir herramientas que mantengan la mejora de procesos usados para desarrollar sistemas y productos. El propósito del proyecto es proveer mejoras en costo, horarios, y calidad de proyectos en desarrollo de ingeniería. La salida del proyecto CMMI es una colección de productos que proveen un enfoque integrado a través de la empresa para mejorar procesos, mientras reduce redundancia, complejidad y costos resultantes de el uso de múltiples modelos de madurez (CMMs). En Diciembre del 2001, el Instituto de Ingeniería de Software (SEI) liberó la versión 1.1 del CMMI. El Modelo CMMI (Capability Maturity Model Integration) es la más reciente evolución del modelo CMM y se espera que produzca similares resultados de regreso en inversión, contiene, como sus predecesores, los elementos esenciales de procesos efectivos para disciplinas especificas.

1.2 Motivación e interés en la selección del tema

La principal motivación que tuve para elegir este tema, fueron los antecedentes que tenía de otros modelos como CMM y SPICE (Software Process Improvement Capability dEvelopment). Estos dos modelos, fueron vistos con detalle en el curso, mientras que el modelo CMMI solo fue presentado brevemente, razón por la cual, creí que sería interesante conocer un poco más de este modelo, y relacionarlo con los dos modelos vistos en el curso. A raíz de esto, decidí tomar CMMI como el tema de mi investigación, cuyo propósito sería ver a fondo el modelo CMMI, hacer una comparación de este modelo con los modelos CMM y SPICE, y finalmente ver donde queda la Arquitectura de Software dentro del modelo.

1.3 Metodología de Clasificación

Para la selección de los artículos, primero realicé una búsqueda en Internet en páginas como Yahoo, Google y Altavista, usando los términos listados a continuación, en forma independiente o con combinaciones entre ellos:

CMMI CMM SPICE Software Architecture

Como era de esperarse, en cada búsqueda que realizaba aparecían muchas páginas con los términos anteriormente mencionados, lo cual consideré hacía más fácil la investigación. Lo que hacía a continuación era abrir las páginas en orden ascendente, evitando aquellas que parecieran irrelevantes. Para el término CMMI, seleccioné aquellos artículos que describieran el modelo parcial o totalmente. La mayoría de los artículos encontrados describían el modelo en forma general, otros que se enfocaban solo en algún punto, e incluso encontré algunos que comparaban este modelo con los



modelos SPICE y CMM, de los cuales elegí sólo aquellos que consideré tenían información relevante. Para el término CMM, me enfoqué especialmente en aquellos artículos que compararan este modelo con CMMI, pero seleccioné uno que describiera CMM en forma general. De igual manera procedí con el término SPICE, aunque en este caso, consideré también algunos artículos que compararan SPICE con CMM. Finalmente, con Arquitectura de software, tomaba la combinación Software Architecture – CMMI, con el fin de encontrar un artículo que relacionara CMMI con la arquitectura de software. Esta idea no fue del todo exitosa, ya que no encontré mucha información, sólo encontré una página que me sirvió para establecer la relación entre estos dos conceptos. Así pues, las principales categorías en que puedo clasificar los conceptos es:

CMMI CMMI vs CMM CMMI vs SPICE Arquitectura de Software.

En base a esta clasificación haré el resumen que se presenta más adelante.

1.4 Dificultades

Sin duda, tuve muchas dificultades en el desarrollo de la investigación. La primera dificultad a la que me enfrenté fue la elección adecuada de los artículos, ya que en ocasiones comenzaba a leer algunos artículos que no iban de acuerdo con el propósito de la investigación, y en este caso, simplemente los desechaba y buscaba otros que me pudieran servir mejor. La siguiente dificultad fue la comprensión de los artículos. Muchos de los artículos contenían conceptos que para mí eran muy difíciles de entender, y si a esto le agrego que estaban en inglés, pues se hacía mucho más difícil, razón por la cual tenía que leer y releer cada artículo, para lograr comprenderlos mejor. Otra dificultad fue posiblemente el idioma, en el sentido de que hay palabras, o incluso frases que no conocía su significado, y cuando buscaba en el diccionario, me daba cuenta de que simplemente no encajaba el significado en la redacción, en otras palabras, no sabía con certeza como se interpretaban algunas palabras dentro del contexto. Otras veces, al tratar de llevar una idea de inglés al español, no encontraba las palabras precisas, cosa que me ocurría frecuentemente, y opté mejor por hacer una mezcla entre ambos idiomas, con el fin de no alterar la idea del autor del artículo. En relación con el idioma, se encuentra también el hecho de que me distraía más fácilmente al leer los artículos en inglés, y a pesar de seguir leyendo, había momentos en los que me perdía completamente en la lectura, y pues no me quedaba mas que volver a empezar la lectura del artículo. También tuve la dificultad de falta de material de Arquitectura de Software relacionado con el modelo CMMI, en este caso, leí sólo el material que tenía, y en base a esto, traté de profundizar el tema con mis propias ideas.



2 Estado del Arte

2.1 Resumen de los artículos seleccionados

De acuerdo con la clasificación descrita en el punto 1.3, el resumen lo haré en cuatro secciones:

CMMI CMMI vs CMM CMMI vs SPICE CMMI y la Arquitectura de Software.

En la primera sección, hablaré del modelo CMMI, donde describiré su estructura, representaciones y disciplinas que cubre. En la segunda sección, haré una comparación de los modelos CMM y CMMI. En la tercera sección, compararé CMMI con el modelo SPICE, y en la última sección, daré una breve introducción a la Arquitectura de Software, y explicaré como se relaciona ésta con el modelo CMMI. CMMI

Como respuesta de una crisis percibida en el desarrollo de software relacionado con problemas de costo y calidad de software, el Departamento de Defensa fundó el Instituto de Ingeniería de Software (SEI) en la Universidad Carnegie Mellon en Pittsbirgh, Pennsylvania a principios de los 1980’s. El SEI comenzó el desarrollo de un modelo de mejora de procesos para ingeniería de Software en 1988. En Agosto de 1991 la primera versión de el Modelo de Madurez para software (SW-CMM Software Capability Maturity Model) fue publicado por el SEI [10]. Un modelo de madurez (Capability Maturity Model CMM ) es un modelo de prácticas maduras en una disciplina específica, usado para asignar una capacidad de grupo de desempeñar esta disciplina [8].

Diferentes Modelos CMM

A consecuencia de la publicación del primer CMM, el Enterprise Process Improvement Collaboration (EPIC), un trabajo cooperativo de la industria y el gobierno, desarrolló y publicó el Modelo de Madurez para ingeniería de sistemas (SE-CMM Systems Engineering Capability Maturity Model), y el International Council Systems Engineering (INCOSE) desarrolló y publicó el Systems Engineering Capability Assessment Model (SECAM). Otros modelos CMM fueron desarrollados, entre los cuales, podemos mencionar el SA-CMM (Software Acquisition CMM), el People CMM, y el IPPD-CMM (Integrated Product and Process Developement CMM). Otras organizaciones han producido sus propios CMMs. Después creció el interés de combinar los Systems Engineering CMMs en un solo modelo. El EIA (Electronic



Industries Aliance) en acuerdo con EPIC e INCOSE comenzaron un trabajo para consolidar los dos Systems Engineering CMMs. El Systems Engineering CMMs resultante fue nombrado Systems Engineering Capability Model (SECM). Algunas organizaciones desarrollaron CMMs integrando varias disciplinas, uno de estos modelos es el FAA-iCMM (Federal Aviation Administration’s Integrated Capability Maturity Model). Como la versión 2.0 del SW-CMM estaba completando su proceso de revisión, Office of the Secretary of Defense (OSD) propuso que el proyecto CMMI se intentara realizar como un trabajo cooperativo de la industria, gobierno y el SEI y que la versión 2.0 del CMM fuera cancelada como un producto independiente y reemplazada por la versión de el producto CMMI [10].

Proyecto CMMI.

El proyecto CMMI es un esfuerzo cooperativo de el Departamento de Defensa, industria y el Instituto de Ingeniería de Software (SEI). Provee modelos para lograr la mejora de productos y procesos. El proyecto se enfoca principalmente en construir herramientas que mantengan la mejora de procesos usados para desarrollar sistemas y productos. El propósito del proyecto es proveer mejoras en costo, horarios, y calidad de proyectos en desarrollo de ingeniería. La salida del proyecto CMMI es un producto que provee un enfoque integrado a través de la empresa para mejorar procesos, mientras reduce redundancia, complejidad y costos resultantes de el uso de múltiples modelos de madurez (CMMs). En Diciembre del 2001, el Instituto de Ingeniería de Software (SEI) liberó la versión 1.1 del CMMI. El Modelo CMMI (Capability Maturity Model Integration) es la más reciente evolución del modelo CMM y se espera que produzca similares resultados de regreso en inversión, contiene, como sus predecesores, los elementos esenciales de procesos efectivos para disciplinas especificas . CMMI es un modelo de procesos, o una colección estructurada de elementos que describe características de procesos probados por experiencia para ser efectivos. Te dice “que hacer” pero no “como hacerlo” [8]. La estructura del modelo CMMI se presenta en la siguiente figura:

Modelo

Metas Específicas

Área de Proceso

(PA)

Metas Genéricas

Área de Proceso

(PA)

Área de Proceso

(PA)



Figura 1. Estructura del modelo CMMI

Cada PA está formada de metas, a su vez, cada meta está formada de prácticas. Las metas y las prácticas son específicas o genéricas. Las prácticas específicas corresponden a una sola PA, mientras que las prácticas específicas van a través de todas las PAs. Las metas y prácticas genéricas, tienen “elaboraciones” que las instancían para cada PA. Las metas específicas se aplican a solo una PA, mientras que las metas genéricas se aplican a más de una PA. Una práctica específica es una actividad considerada importante para alcanzar una meta específica. Las practicas genéricas son prácticas que se aplican a cualquier PA, ya que pueden mejorar el desempeño y control de cualquier proceso. Un ejemplo de práctica y meta específica es: PA: Requirement Management Meta: “Requerimientos son mantenidos y reflejados en planes, actividades y productos” Práctica: “Mantener la traceabilidad de requerimientos a su fuente de requerimiento” Un ejemplo de práctica y meta genérica es: Metas Genéricas se aplican a todas las PAs Meta: “Institucionalizar un proceso definido”m Práctica: “Proveer Recursos” El modelo CMMI tiene un total de 25 PA y 411 prácticas.

Un modelo, dos representaciones.

Al menos dos objetivos eran claros más allá de la necesidad de integración al comienzo del desarrollo del CMMI:

Conservar Los niveles de madurez por etapas para mantener la flexibilidad necesaria en muchas organizaciones que tienen que adaptar sus procesos de mejora a sus metas de negocios y no viceversa.

La transición de organizaciones que usaron el CMMI v1.1 en el pasado al el CMMI debería ser tan fácil como fuera posible para proteger las considerables inversiones hechas.

La solución de esos retos fue un modelo y dos representaciones: por etapas (staged ) y continua (continuous). La representación continua es claramente más flexible en cuanto a que permite formar una estrategia de mejora que se adapte a las metas globales de la respectiva organización. La representación

(SG) (GG)

Prácticas Específicas

(SP)

Prácticas Genéricas

(GP)



continua es más compatible con el modelo ISO 15504/ SPICE La representación por etapas, en contraste, es el modelo preferido por organizaciones que quieren migrar más fácilmente de CMM v1.1 a el CMMI. La mayor diferencia que existe entre las dos representaciones es en el nivel más alto: En la representación por etapas se tiene todavía los niveles de madurez (MLs Maturity Levels) como en el modelo CMM v1.1. y las Areas de Procesos (PA Process Areas) son asignadas a los cuatro niveles más altos de los cinco Niveles de Madurez (Managed, Defined, Quantitatively Managed, Optimizing). En la representación continua, sin embargo, los niveles de madurez son reemplazados por niveles de Capacidad (CLs Capability Levels) cono una medida asignada individualmente a cada PA (Process Area). La siguiente tabla (Tabla 1) muestra los niveles existentes de capacidad o madurez de cada representación [21].

Tabla 1. Niveles de Capacidad y Madurez de CMMI Ambas representaciones reconocen que las áreas de procesos pueden ser agrupadas en cuatro categorías generales: project management, engineering, support, and process management. Otra diferencia entre las representaciones es la estructura. Hay un mapeo unidireccional de la representación continua a la representación por etapas llamado “equivalent staging”. Ambas representaciones de los modelos están en las siguientes ubicaciones: CMMI Staged Representation Internet: http://unicoi.kennesaw.edu/ase/ase02_01/bookcase/se_sh/cmms/cmmi-staged.pdf Carpeta Local: v1-staged.pdf CMMI Continuous Representation Internet: http://unicoi.kennesaw.edu/ase/ase02_01/bookcase/se_sh/cmms/cmmi-continuous.pdf Carpeta Local: v1-continuous.pdf

Nivel CMMI Staged Maturity CMMI Continuous Capability

5 Optimizing Optimizing 4 Quantitatively Managed Quantitatively Managed 3 Defined Defined 2 Managed Managed 1 Initial Performed 0 - Incomplete



CMMI vs CMM

Las comparaciones que se harán entre los modelos CMMI y CMM, serán solamente en referencia al modelo SW-CMM, son considerar el resto de los modelos CMM. La mayor diferencia encontrada en el CMMI caen en cuatro categorías: disciplinas cubiertas, niveles de madurez, áreas de procesos, y estructura del modelo. Disciplinas cubiertas

El cambio más obvio es que el modelo CMMI cubre múltiples disciplinas. Actualmente el CMMI cubre las siguientes disciplinas:

Software Engineering (SW) Ingeniería de Software cubre el desarrollo de sistemas de software. Ingenieros de software se centran en aplicar enfoques cuantificables, sistemáticos y disciplinados para el desarrollo, operación y mantenimiento del software.

Systems Engineering (SE)

Ingeniería de Sistemas trata con el desarrollo de los sistemas totales, que pueden o no incluir software. Los ingenieros en Sistemas se centran en transformar las necesidades, expectativas y restricciones de los clientes en productos soluciones y mantener esos productos soluciones a lo largo de la vida de el producto.

Integrated Product and Process Development (IPPD) Desarrollo de procesos y productos integrados es un enfoque sistemático que realiza una colaboración de “stakeholders” relevantes a lo largo de la vida del producto para satisfacer mejor las necesidades, expectativas y requerimientos del cliente.

Supplier Sourcing (SS) Esta disciplina es aplicable a proyectos que usan proveedores par desempeñar funciones que son críticas para el éxito de el proyecto.

CMM sólo cubre la primera de las cuatro disciplinas cubiertas por CMMI, por lo que se puede decir, que CMMI es más completo y puede ser empleado por mayor variedad de organizaciones.

Niveles de Madurez y Áreas de Procesos

Los niveles del CMMI tienen las mismas definiciones que el CMM, aunque se hicieron algunos cambios en los nombres de los niveles. Los niveles 1,3 y 5 mantienen sus nombres, Initial, Defined y Optimizing, pero los niveles 2 y 4 cambiaron sus nombres por Managed y Quantitatively Managed, respectivamente, quizás para enfatizar con mayor claridad la evolución de la administración de procesos desde un enfoque cualitativo a uno cuantitativo. Si recordamos, el nombre de los niveles 2 y 4 del CMM eran Repeated y Managed respectivamente. El CMMI contiene 25 PA y 411 prácticas para las cuatro disciplinas



actualmente cubiertas, mientras que el CMM contiene 18 KPA y 150 prácticas. En la figura 2, podemos ver las prácticas del modelo CMMI asociadas a cada nivel, y la correspondiente categoría en la que se agrupa [11].

Figura 2 CMMI Process Areas.

Aunque muchas de las áreas de procesos encontradas en el CMMI son esencialmente las mismas que en el CMM, se reflejan algunos cambios significativos en el aspecto de que en el CMMI se cubren procesos que anteriormente no eran cubiertos en el CMM. El nivel 2 sobrevive la transición a el CMMI relativamente intacto Software Subcontracting ha sido renombrado como Supplier Agreement Management y cubre un rango de situaciones de adquisición y contratación. Measurement and and Análisis es una nueva área de procesos que primordialmente consolida las prácticas previamente encontradas en el CMM como Measurement and Análisis Common Feature en una sola área de proceso. El nivel 3 fue el que más sufrió cambios: la práctica de CMM llamada Software Product Engineering ha sido expandida en 5 áreas de procesos en el CMMI: Requirements Development addresses, Techincal Solution, Product Integration, Verification and Validation. Risk Management es una nueva área, al igual que Decision Analisis and Resolution. Para la disciplina IPPD, se adicionan 2 áreas de procesos: Integrated Teaming y Organized Environment for Integration. La disciplina SS adiciona Integrated Supplier Management. En el nivel 4, Software Quality Management and Quantitative Product Management del CMM ha sido reemplazada por dos nuevas áreas de procesos: Organizational Process Performance y Quantitative Project Management. El nivel 5 no ha cambiado dramáticamente con la liberación del CMMI. Process Change Management y Technology Change Management del CMM han sido



combinadas en un área de proceso: Organizational Innovation and Deployment. Defect Prevention ha sido renombrada como Causal Analysis and Resolution [8]. Con el crecimiento en el número de áreas de procesos y prácticas, el CMMI es significativamente más grande que el CMM. En la siguiente figura (Figura 3) podemos ver un mapeo de las prácticas del CMM en las prácticas del CMMI [5].

Figura 3. Mapeo de las KPA del CMM in las PAs del CMMI. Cambios Estructurales

Cada uno de los modelos CMM en los que se basa el CMMI es un modelo por etapas o continuo, que se enfocan en la madurez o capacidad de la organización respectivamente. El uso de los términos madurez y capacidad puede ser confuso inicialmente. Niveles de madurez se refieren a la organización entera, y niveles de capacidad se refieren a áreas de procesos individuales. CMMI tiene ambas representaciones, mientras que el CMM para software, tiene como representación la de etapas. Una organización que adopte el CMMI debe decidir cual representación sería mas adecuada. Muchas organizaciones que tienen experiencia con el CMM elegirán la representación por etapas.

Básicamente, estas son las principales diferencias entre los modelos CMM y CMMI. Aquí cabe mencionar que si una organización usa actualmente el modelo CMM, y desea hacer la transición al modelo CMMI, no es posible saber con certeza el nivel que le corresponderá. En la siguiente ubicación, se puede ver un mapeo que se hace entre el modelo CMMI y el modelo CMM. Internet: http://www.stsc.hill.af.mil/consulting/cmmi/cmmiseswippdssv11.pdf Carpeta Local: cmmiseswippdssv11.pdf



CMMI vs SPICE La diferencia que existe entre estos dos modelos, es prácticamente la misma que existe entre el modelo CMM y el modelo SPICE. Los modelos CMMI se basan en niveles, mientras que el modelo SPICE se basa en categorías. Las categorías del modelo SPICE son: Organization, Management, Engineering, Support y Customer Supplier. Recordemos que el modelo CMMI tiene dos representaciones, que determinan la capacidad y madurez de la organización. La siguiente tabla muestra los niveles de madurez y capacidad de cada representación, así como los del modelo ISO 15504(también conocido como SPICE).

De la tabla podemos ver las similitudes que existen entre el modelo CMMI en su representación continua con el modelo ISO 15504. Si recordamos, en el modelo CMMI las áreas de procesos se agrupan en cuatro categorías generales: project management, engineering, support, and process management. Este agrupamiento se da de manera más natural en la representación continua del modelo. Con el propósito de hacer la comparación, en la siguiente tabla se listan las categorías de procesos del ISO 15504 (SPICE) y las categorías del modelo CMMI

En la tabla vemos que podemos hacer un mapeo entre categorías, y con esto, llegamos a que la representación continua es la mas compatible con el modelo SPICE.

Nivel CMMI Staged Maturity

CMMI Continuous Capability

ISO 15504 Capability

5 Optimizing Optimizing Optimizing 4 Quantitatively

Managed Quantitatively Managed

Predictable

3 Defined Defined Established 2 Managed Managed Managed 1 Initial Performed Performed 0 - Incomplete Incomplete

CMMI Process Areas Categories Continuos

ISO 15504 Process Categories

Process Management Organization Project Management Management Engineering Engineering Support Support Customer-Supplier



En la siguiente ubicación se puede ver un mapeo que se hace entre el modelo CMMI y el SPICEInternet: http://www-sqi.cit.gu.edu.au/courses/cmmi/report/docs/MappingReport.pdf

Carpeta Local: MappingReport.pdf

CMMI y la Arquitectura de Software. En esta sección, daré una breve introducción a lo que es la Arquitectura de Software, para después establecer la relación que existe con el modelo CMMI. Arquitectura de Software

Como el tamaño y la complejidad de sistemas de software rece, el diseño y especificación de la estructura global del sistema comienza a tener problemas más significantes que la elección de algoritmos y estructuras de datos de computación. Problemas estructurales incluyen la organización de un sistema como una composición de elementos; estructuras globales de control; protocolos de comunicación, sincronización y acceso de datos; la asignación de funcionalidad a diseño de elementos; la composición de elementos de diseño; distribución física; escala y desempeño; dimensiones de evolución; y selección a través de alternativas de diseño. Este es el nivel de diseño de Arquitectura de software [3]. La Arquitectura de Software se enfoca en el análisis y la descomposición de alto nivel de un sistema en sus principales componentes, así como el proceso de diseño utilizado en dicha descomposición. Dichos componentes son:

Valorar la calidad de los atributos de un sistema Medio de Comunicación entre los interesados Líneas de productos de software

La Arquitectura de Software permite la valoración y diseño de los atributos de un sistema de software. El diseño de la arquitectura es realizado al inicio del proceso de desarrollo de software (después de la especificación de requerimientos). De acuerdo con la definición de Bass (1998): “La arquitectura del software de un programa ó de un sistema computacional es la estructura ó las estructuras del sistema, que abarcan componentes, las características externamente visibles de esos componentes y los relaciones entre ellos”. Al seleccionar una arquitectura, se imponen límites mínimos y máximos de calidad en los atributos del sistema.



Nos enfocaremos en lo siguientes requerimientos de calidad: Calidad en el desarrollo de requerimientos, que afectarán la

capacidad de mantenimiento Calidad en los requerimientos operacionales, tales como desempeño

y confiabilidadLa calidad en los requerimientos deberá de tener mayor influencia en la arquitectura del sistema que los requerimientos funcionales. Con respecto a Arquitecturas de software cabe mencionar lo siguiente:

Es complejo plasmar las especificaciones de requerimientos en la

arquitectura El proceso de arquitectura de software no se encuentra

debidamente formalizado y no hay una metodología madura disponible. El diseño de una arquitectura de software todavía es considerado un

arte. Es importante especificar, analizar y diseñar la arquitectura. Requerimientos de calidad tienen un gran impacto en la

arquitectura del sistema. El diseño de la arquitectura es parte del proceso de desarrollo y

evolución de los productos de software.

CMMI y Arquitectura de Software

De acuerdo con Daniel Karlstrom [24], el modelo CMMI contiene prácticas relacionadas con Arquitectura de software. Las áreas de procesos que se relacionan con Arquitecturas de Software son cuatro, tres de las cuales se encuentran en el nivel 3 y una en el nivel 2. Estas prácticas son:

Nivel 2 Project Planning (PP) Nivel 3 Requirements Development (RD) Nivel 3 Technical Solution (TS) Nivel 3 Product Integration (PI)

A continuación veremos en que consiste cada una de estas prácticas y después veremos porque se relaciona con la Arquitectura de software (AS). Project Planning (PP) Establece y mantiene planes que definen actividades de proyecto. Planeación del proyecto incluye desarrollar el plan del proyecto, interactuar con “stakeholders” apropiadamente y obtener un obligación con el plan, así como el mantenimiento del plan. Planeación comienza con los requerimientos que define el producto y el proyecto. Planeación incluye estimar los atributos del producto de trabajo, negociar las obligaciones, los recursos necesarios, producir un horario, identificar y analizar riesgos del proyecto. El plan de proyecto provee las bases para desempeñar y controlar las actividades del proyecto que se derivan de las obligaciones con el cliente del



proyecto. El plan de proyecto necesitará usualmente ser revisado como progreso del proyecto para manejar cambios en requerimientos y obligaciones, estimaciones inciertas, acciones correctivas y cambios de procesos. Tiene relacionadas 3 metas específicas y una genérica. SG1 Establish Estimates Estimados de parámetros en la planeación del proyecto se establecen y mantienen SG2 Develop a Project Plan

Un plan de proyecto es establecido y mantenido como la base para administrar el proyecto

SG3 Obtain Commitment to the Plan

Compromisos del plan de proyecto se establecen y mantienen

GG2 Institutionalize a Managed Process El proceso es institucionalizado como un proceso administrado. Las correspondientes prácticas son: SG1 Establish Estimates SP1.1 Estimate the scope to the project SP1.2 Establish estimates of Project Attributes SP1.3 Define Project Life Cycle SP1.4 Determine Estimates of Efforts and Cost SG2 Develop a Project Plan SP2.1 Establish the Budget and Schedule SP2.2 Identify Project Risks SP2.3 Plan for Data Management SP2.4 Plan for Project Resources SP2.5 Plan for Needed Knowledge and Skills SP2.6 Plan Stakeholder Involvement SP2.7 Establish the Project Plan SG3 Obtain Commitment to the Plan SP3.1 Review subordinate plans SP3.2 Reconcile work and Resource Levels SP3.3 Obtain Plan Commitment

GG2 Institutionalize a Managed Process GP2.1 Establish an Organizational Policy GP2.2 Plan the Process GP2.3 Provide Resources GP2.4 Assign Responsibility GP2.5 Train People GP2.6 Manage Configurations GP2.7 Identify and involve relevant Stakeholders GP2.8 Monitor and control the process GP2.9 Objectively Evaluate Adherence GP2.10 Review Status with Higher-Level Management



Requirements Development (RD) El propósito de desarrollo de requerimientos es producir y analizar clientes, productos y requerimientos de componentes de productos. Los requerimientos desarrollados serán la base para el diseño. Esto incluye lo siguiente:

Colección y coordinación de necesidades de “stakeholders” Desarrollo de los requerimientos del ciclo de vida del producto Establecimiento de los requerimientos del cliente Establecimiento del producto inicial y requerimientos de

componentes de producto consistente con los requerimientos del cliente. Elicitación, análisis y comunicación de las necesidades del cliente,

expectativas y restricciones para alcanzar las necesidades del cliente.

Esta área de proceso maneja todos los requerimientos del cliente mejor que solo los requerimientos a nivel del producto, porque el cliente puede proveer requerimientos específicos de diseño. Análisis son usados para mantener, definir y seleccionar los requerimientos en todos los niveles desde alternativas competentes. Análisis incluye lo siguiente:

Análisis de necesidades y requerimientos Desarrollo de un concepto operacional Definición de funcionalidad requerida

Tiene relacionadas 3 metas específicas y una genérica. SG1 Develop Customer Requirements

Necesidades de “stakeholders”, expectativas, restricciones e interfaces son recolectadas y trasladadas a los requerimientos del cliente

SG2 Develop Product Requirements

Los requerimientos del cliente son refinadas y elaboradas para desarrollar el producto y requerimientos de componentes del producto para el ciclo de vida del producto.

SG3 Analyze and validate Requirements

Los requerimientos son analizados y validados, y una definición de funcionalidad requerida es desarrollada.

GG2 Institutionalize a Defined Process El proceso es institucionalizado como un proceso definido. Las correspondientes prácticas son: SG1 Develop Customer Requirements SP1.1 Elicit Needs

SP1.2 Transform Stakeholder Needs, Expectations, Constraints and Interfaces into Customer Requirements

SG2 Develop Product Requirements SP2.1 Establish Product and Product Component Requirements



SP2.2 Allocate Product Component Requirements SP2.3 Identify Interface Requirements SG3 Analyze and Validate Requirements SP3.1 Establish Operational Concepts and Scenarios SP3.2 Establish a Definition of Required Functionally SP3.3 Analyze Requirements SP3.4 Evaluate Product Cost, Schedule and Risk SP3.5 Validate Requirements with Comprehensive Methods.

GG3 Institutionalize a Defined Process GP2.1 Establish an Organizational Policy GP3.1 Establish a Defined Process GP2.2 Plan the Process GP2.3 Provide Resources GP2.4 Assign Responsibility GP2.5 Train People GP2.6 Manage Configurations GP2.7 Identify an Involve Relevant Stakeholders GP2.8 Monitor and Control the Process GP3.2 Collect Improvement Information GP2.9 Objectively Evaluate Adherence GP2.10 Review Status with Higher-Level Management

Technical Solution (TS) El propósito de desarrollo de Soluciones técnicas es desarrollar, diseñar e implementar soluciones a los requerimientos. Soluciones, diseños e implementaciones abarcan productos, componentes de productos y procesos relacionados con productos ya sea por separado o con combinaciones apropiadas. Tiene relacionadas 3 metas específicas y una genérica. SG1 Select Product Component Solutions

Productos, componentes de productos incluyendo procesos relacionados con productos son seleccionados para soluciones alternativas.

SG2 Develop the Design

Diseño del producto o componentes del producto son desarrollados. SG3 Implement the Product Design

Componentes del producto y documentación asociada son implementadas para su diseño.

GG2 Institutionalize a Defined Process El proceso es institucionalizado como un proceso definido. Las correspondientes prácticas son: SG1 Select Product Component Solutions SP1.1 Develop Detailed Alternative solutions and Selection Criteria

SP1.2 Evolve Operational Concepts and Scenarios SP1.3 Select Product Component Solutions



SG2 Use Effective Design Methods SP2.1 Use Effective design methods SP2.2 Establish a Complete Technical Data Package SP2.3 Design Comprehensive Interface SP2.4 Perform make, buy, or reuse analyses SG3 Implement the product design SP3.1 Implement the design SP3.2 Establish Product Support documentation GG3 Institutionalize a Defined Process GP2.1 Establish an Organizational Policy GP3.1 Establish a Defined Process GP2.2 Plan the Process GP2.3 Provide Resources GP2.4 Assign Responsibility GP2.5 Train People GP2.6 Manage Configurations GP2.7 Identify an Involve Relevant Stakeholders GP2.8 Monitor and Control the Process GP3.2 Collect Improvement Information GP2.9 Objectively Evaluate Adherence GP2.10 Review Status with Higher-Level Management

Product Integration (PI) El propósito de Integración del producto es ensamblar el producto desde sus componentes, asegurando que el producto integrado funcione apropiadamente, y entregar el producto. El enfoque de esta área de proceso es realizar la integración completa del producto ensamblando progresivamente sus componentes en un una etapa o en etapas incrementales e acuerdo a una estrategia definida de integración. Un aspecto crítico de integración del producto es la administración de interfaces internas y externas de los productos y sus componentes para asegurar la compatibilidad a través de las interfaces. Tiene relacionadas 3 metas específicas y una genérica. SG1 Prepare for Product Integration

La estrategia para conducir la integración del producto es establecida y mantenida.

SG2 Ensure Interface Compatibility

Las interfaces del producto son compatibles SG3 Assemble Product Components and Deliver Product

Componentes verificadas del producto son ensambladas y el producto integrado, verificado y validado es entregado.

GG2 Institutionalize a Defined Process El proceso es institucionalizado como un proceso definido.



Las correspondientes prácticas son: SG1 Prepare for Product Integration SP1.1 Establish a Product Integration Strategy

SP1.2 Establish the Product Integration Environment SP1.3 Define Detailed Product Integration Procedures

SG2 Ensure Interface Compatibility SP2.1 Review Interface Descriptions for Completeness SP2.2 Manage Interfaces SG3 Assemble Product Components and Deliver Product SP3.1 Confirm Readiness of Product Components for Integration SP3.2 Assemble Product Components SP3.3 Checkout Assembled Product Components SP3.4 Package and Deliver the Product or Product Component GG3 Institutionalize a Defined Process GP2.1 Establish an Organizational Policy GP3.1 Establish a Defined Process GP2.2 Plan the Process GP2.3 Provide Resources GP2.4 Assign Responsibility GP2.5 Train People GP2.6 Manage Configurations GP2.7 Identify an Involve Relevant Stakeholders GP2.8 Monitor and Control the Process GP3.2 Collect Improvement Information GP2.9 Objectively Evaluate Adherence GP2.10 Review Status with Higher-Level Management

Después de analizar cada una de las áreas de proceso relacionadas con la Arquitectura de Software, me di cuenta que la mayoría tienen que ver con los requerimientos, a excepción de la última que se relaciona directamente con la integración del producto.

Si recordamos, en el tradicional modelo de cascada, la arquitectura de software se encuentra entre las etapas de requerimientos y diseño, y es en esta parte donde se centran la mayoría de las prácticas de las áreas de procesos antes mencionadas. Es en estas prácticas donde entra la Arquitectura de software, la cual, desde mi punto de vista, se relaciona con las siguientes prácticas:

Establish the project plan Establish a Definition of Required Functionality Select Product Component Solutions Establish a Product Integration Strategy

Estas prácticas son las que se relacionan con la arquitectura de software en el sentido de que todas tienen en común el establecimiento de un esquema estructurado.

2.2 Crítica personal de los artículos



La mecánica que seguiré para esta sección consiste en hacer referencia de cada artículo, mencionando en cada caso, si tiene relación con algún otro artículo en la lista. El artículo “CMM vs. CMMI: From Conventional to Modern Software Management” de Walker Royce, no se relaciona mucho con el resto de los artículos, lo único que encuentro en común es la descripción de los niveles del modelo CMMI, descritas en la representación por etapas del modelo CMMI. El artículo “The Measurement and Analysis Process Area in CMMI” de Dave Zubrow, no se relaciona con artículo, ya que sólo este se centra primordialmente en esta ‘’area de proceso del CMMI. El artículo “Evolutionary Differences Between CMM for Software and the CMMI” de Tim Kasse me pareció sumamente interesante, ya que explica brevemente los cambios sufridos con las principales áreas de procesos del modelo CMM al modelo CMMI. Tiene similitudes con el artículo de Ruiz Merandosqueta [8] en la introducción. En el artículo “Comparación Práctica de los modelos de madurez SW-CMM vs CMMI” de Elizabeth Almeraz y Marina Pérez Vargas, no tiene mucho en común con el resto de los artículos, ellas se dedican a criticar el modelo CMMI a favor de las pequeñas empresas de México, cosa que ningún otro artículo hace, de hecho, es de los pocos artículos que piensan que la liberación del modelo CMMI es perjudicial para algunas organizaciones. El artículo “CMMI ¿Evolución o nuevo modelo?” de Alvaro Ruiz Mendarozqueta, como lo habia mencionado, se parece al de Tim Kasse[6] en la parte introductoria. Este artículo tiene además la particularidad de que la mayoría de la información contenida ahí viene del libro CMMI Distilled [1]. El artículo “Seguimiento” no tiene en absoluto nada que ver con el resto de los artículos. El artículo “Concept of Operations for the Capability Maturity Model Integration” de Carnegie Mellon University me pareció muy interesante por la forma en que presenta el contenido. Gran parte de la información aquí es similar a el contenido en los artículos de Gerold Kefer [21] y el de Frank Koch [11]. El artículo de Frank Koch.: “CMMI What you need to know!”, presenta sólo información general acerca del modelo CMMI, tiene similitudes con el artículo anterior y con el de Gerold Kefer [11] El artículo de Emmanuel Baker, describe sólo el modelo CMM, sus niveles y principles características. Frank Koch[12] con si artículo “Metrics and the Immature Software Process”, da su punto de vista acerca de las metricas en los procesos de software, y hace referencia a algunas áreas del CMMI. Paula Ashley con su artículo “Defect Prevention”, al igual que Dave Zubrow [5] se enfocan solo en un área del modelo. Aunque el artículo de MERANT [15], pretende básicamente dar publicidad a su producto, describe las características básicas del modelo CMMI, las cuales coinciden con los artículos de la Carnegie Mellon Universiti [10] y el de Frank Kock [11] principalmente.



Los artículos de Heinz[17] y Philips[16] son ambos respuestas a las “preguntas mas frecuentes ” acerca del modelo CMMI. Los artículos de Rout Terence [18] y [20] tratan ambos del modelo SPICE, en el primero se hace una comparación el modelo CMM y en el segundo describe el modelo en sí. El artículo de Gasser[19], junto con los últimos tres artículos, son referentes a la Arquitectura de Software, pero a pesar de referirse al mismo tema, lo enfocan de manera distinta: Gasser[19] ve la AS desde el punto de vista práctico, Dewayne [22] se enfoca en los fundamentos, Garlan [23] en los problemas de AS y Karlstrom [24] en la relación que tiene la AS con el modelo CMMI.

3 Conclusiones2.3 Tendencias futuras

Como conclusiones puedo señalar las siguientes:

Hay más de un modelo CMM El modelo CMMI integra los principales modelos CMM El modelo CMMI tiene dos representaciones, la primer, por etapas, se basa en el SW-

CMM, mientras que la segunda, continua, se basa en el SE-CMM. El modelo CMMI tiene metas y prácticas específicas y genéricas. Las primeras se aplican

sólo a un área de proceso y las segundas a más de una. Las principales diferencias entre los modelos CMM y CMMI se refieren principalmente a

las disciplinas cubiertas, los niveles de madurez, las áreas de procesos, y la estructura del modelo.

La representación continua del CMMI se parece más al modelo SPICE que la representación por etapas, que a su vez se parece más al SW-CMM.

La Arquitectura de Software se relaciona con el modelo CMMI en las siguientes prácticas:- Establish the project plan - Establish a Definition of Required Functionality - Select Product Component Solutions - Establish a Product Integration Strategy

Como tendencia futura tengo el de relacionar lo aprendido a lo largo de la realización del proyecto con la manera en que llevo a cabo mis funciones en el proyecto de la materia de Sistemas de Información, que, por lo que me di cuenta, es muy aplicable principalmente por las prácticas del modelo.

2.4 Beneficios obtenidos de la investigación

Así como las dificultades a las que me enfrenté fueron muchas, los beneficios también son considerables. El primer beneficio obtenido fue el de adquisición de conocimiento relacionado con el tema. También obtuve el beneficio de mejorar mi proceso de investigación ampliando



mi criterio de sección de artículos. Otro de los beneficios fue el mejoramiento en lectura y comprensión de artículos, ya que sentí que entre mas avanzaba con el proyecto, comprendía más rápido los artículos. Finalmente, considero como beneficio también el practicar lecturas en inglés, ya que como mencioné anteriormente, leer artículos de este género es un poco complicado para mí, leerlos en inglés resulta mucho más complejo aún. Creo que obtuve más beneficios de los mencionados, pero prácticamente estos son los principales. Los siguientes links son para ver los documentos relacionados con el proyecto: Ver Bibliografía Extendida Ver presentación de Procesos de Software Ver presentación de Arquitecturas de Software

4 Referencias

[1] Ahern, Dennis; Clouse, Aaron; Turner, Richard: “CMMI Distilled: A practical introduction to the integrated process improvement”, Addison-Wesley, USA 2001

[2] Wang, Yingxu; King, Graham: “Software Engineering Processes: Principles and

Applications”, CRC Press, USA 2000.

[3] Shaw, Mary; Garlan, David: “Software Architecture: Perspectives on an Emerging Discipline”, Prentice Hall, USA 1996.

[4] Royce, Walker: “CMM vs. CMMI: From Conventional to Modern Software Management”,

The Rational Edge

[5] Zubrow, Dave: “The Measurement and Analysis Process Area in CMMI”, SEI

[6] Kasse, Tim: “Evolutionary Differences Between CMM for Software and the CMMI”, SPI Partners

[7] Almeraz, Elizabeth; Pérez Vargas, Marina: “Comparación Práctica de los modelos de

madurez SW-CMM vs CMMI”, Avantare

[8] Ruiz Mendarozqueta, Alvaro: “CMMI ¿Evolución o nuevo modelo?”, ASSE 2002

[9] “Seguimiento”, SEL Software Engineering Laboratory

[10] Carnegie Mellon University: “Concept of Operations for the Capability Maturity Model Integration”

[11] Koch, Frank J.: “CMMI What you need to know!” ,Process Perspectives No 7 Spring

2002

[12] Koch, Frank J.: “Metrics and the Immature Software Process”, Q/P Management Group



[13] Baker, Emmanuel R; Koch, Frank J.: “The SEI Capability Maturity Model”, Q/P

Management Group

[14] Ashley, Paula: “Defect Prevention”, Process Perspectives No 5 Winter 1997

[15] MERANT: “PVCS Dimensions supports the CMMI”, Merant

[16] Philips, Mike: “Messages from the Field”, SEI

[17] Heinz, Lauren: “CMMI Myths and Realities”, SEI

[18] Rout, Terence P.: “SPICE and the CMM: Is the CMM compatible with ISO/IEC 15504?”, SQI, Software Quality Institute

[19] Gasser, Christian: “Software Architecture: theory and (mostly) practice”, UNIFR

University of Fribourg

[20] Rout, Terence P.: “The SPICE Project – Past, Present and Future”, SQI Software Quality Institute

[21] Keefer, Gerold; Lubecka, Hanna: “The CMMI in 45 Minutes”,AVOCA Advanced Visioning

of Components Architectures

[22] Perry, Dewayne E.; Wolf, Alexander L.: “Foundations for the Study of Software Architecture”, ACM SIGSOFT Software Engineering notes, 17:4, October 1992

[23] Garlan, Davvid; Perry, Dewayne E.: “Introduction to the Special Issue on Software

Architecture”, IEEE Transactions on SE, 21 (4) April 1995, pp 269-274

[24] Karlstrom, Daniel: “Software Architectures: Relevant parts of SW-CMM, SE-CMM and CMMI” LUCAS, Center for Applied Software Research.

Documents

Reporte de Investigación - CIMATyolanda/cursos/semestre2/ingenieria/Proyecto/reporte.pdfReporte de Investigación Yolanda de Lira Domínguez Temas de Investigación: CMMI CMMI vs