Reporte de Investigación Yolanda de Lira Domínguez

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Reporte de Investigación Yolanda de Lira Domínguez"

Transcripción

1 Centro de Investigación en Matemáticas, A Page 1 of 25 Centro de Investigación en Matemáticas, A. C. Proyecto de Tópicos Selectos de Programación II Reporte de Investigación Yolanda de Lira Domínguez Temas de Investigación: CMMI CMMI vs. CMM CMMI vs. SPICE Software Architecture Software Architecture in CMMI Mayo del 2002

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

3 Centro de Investigación en Matemáticas, A Page 3 of 25 Contenido 1 Introducción 1.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 Arte 2.1 Resumen de los artículos seleccionados 2.2 Crítica personal de los artículos 3 Conclusiones 2.3 Tendencias futuras 2.4 Beneficios obtenidos de la investigación 4 Referencias

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

5 Centro de Investigación en Matemáticas, A Page 5 of 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

6 Centro de Investigación en Matemáticas, A Page 6 of 25 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.

7 Centro de Investigación en Matemáticas, A Page 7 of 25 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 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

8 Centro de Investigación en Matemáticas, A Page 8 of 25 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 Área de Proceso (PA) Área de Proceso (PA) Área de Proceso (PA) Metas Específicas Metas Genéricas

9 Centro de Investigación en Matemáticas, A Page 9 of 25 (SG) (GG) Prácticas Específicas (SP) Prácticas Genéricas (GP) 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

10 Centro de Investigación en Matemáticas, A Page 10 of 25 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]. 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 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: -staged.pdf Carpeta Local: v1-staged.pdf CMMI Continuous Representation Internet: -continuous.pdf Carpeta Local: v1-continuous.pdf

11 Centro de Investigación en Matemáticas, A Page 11 of 25 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

12 Centro de Investigación en Matemáticas, A Page 12 of 25 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

13 Centro de Investigación en Matemáticas, A Page 13 of 25 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: Carpeta Local: cmmiseswippdssv11.pdf

14 Centro de Investigación en Matemáticas, A Page 14 of 25 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). Nivel CMMI Staged Maturity CMMI Continuous Capability ISO Capability 5 Optimizing Optimizing Optimizing 4 Quantitatively Quantitatively Predictable Managed Managed 3 Defined Defined Established 2 Managed Managed Managed 1 Initial Performed Performed 0 - Incomplete Incomplete De la tabla podemos ver las similitudes que existen entre el modelo CMMI en su representación continua con el modelo ISO 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 (SPICE) y las categorías del modelo CMMI CMMI Process Areas Categories Continuos Process Management Project Management Engineering Support ISO Process Categories Organization Management Engineering Support Customer-Supplier 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.

15 Centro de Investigación en Matemáticas, A Page 15 of 25 En la siguiente ubicación se puede ver un mapeo que se hace entre el modelo CMMI y el SPICE Internet: 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.

16 Centro de Investigación en Matemáticas, A Page 16 of 25 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 confiabilidad La 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

17 Centro de Investigación en Matemáticas, A Page 17 of 25 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

18 Centro de Investigación en Matemáticas, A Page 18 of 25 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

19 Centro de Investigación en Matemáticas, A Page 19 of 25 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

20 Centro de Investigación en Matemáticas, A Page 20 of 25 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.

CMMI SM for Systems Engineering / Software Engineering / Integrated Product and Process CMMI SM -SE/SW/IPPD, V1.02

CMMI SM for Systems Engineering / Software Engineering / Integrated Product and Process CMMI SM -SE/SW/IPPD, V1.02 CMMI SM for Systems Engineering / Software Engineering / Integrated Product and Process Development,, Versión n 1.02 CMMI SM -SE/SW/IPPD, V1.02 Indice - Procesos integrados - El concepto CMMI - Introducción

Más detalles

El Modelo CMMI (for Development) Monterrey, N.L. México Noviembre 2008

El Modelo CMMI (for Development) Monterrey, N.L. México Noviembre 2008 El Modelo CMMI (for Development) Monterrey, N.L. México Noviembre 2008 El CMMI El CMMI es un enfoque de mejora de procesos que provee a las organizaciones de los elementos esenciales para un proceso efectivo.

Más detalles

Capítulo 2 Ideas generales de CMMI-SW. 2.1 Introducción. 2.2 Procesos. 2.3 Modelo de procesos

Capítulo 2 Ideas generales de CMMI-SW. 2.1 Introducción. 2.2 Procesos. 2.3 Modelo de procesos Capítulo 2 Ideas generales de CMMI-SW 2.1 Introducción El Capability Maturity Model Integration (en adelante CMMI), se compone de un conjunto de modelos, métodos de evaluación y cursos de formación para

Más detalles

Evaluaciones CMMI. Standard CMMI Appraisal Method for Process Improvement

Evaluaciones CMMI. Standard CMMI Appraisal Method for Process Improvement Evaluaciones CMMI Standard CMMI Appraisal Method for Process Improvement O cómo saber qué estudiar para el examen Juan José Cukier jcukier@pragmaconsultores.com SEI-Authorized Candidate SCAMPI Lead Appraiser

Más detalles

Problemas de PYMES en el Nivel 2 de Madurez Una Muestra Sesgada

Problemas de PYMES en el Nivel 2 de Madurez Una Muestra Sesgada del Problemas de PYMES en el Nivel 2 de Madurez Una Muestra Sesgada JuanJo Cukier, Practia Consulting Consideraciones del Estudio 27 Evaluaciones Nivel 2 entre: Junio de 2006 y Junio 2008 18 Organizaciones

Más detalles

y la madurez llegó a las empresas Iban López Jiménez

y la madurez llegó a las empresas Iban López Jiménez y la madurez llegó a las empresas Iban López Jiménez Hoy hablamos de CMM qué? CMMI y otros modelos Cifras, cifras, cifras Acreditación Un ejemplo de acreditación real: TECSIDEL Empezamos bien CMM qué?

Más detalles

Ingeniería de Software II

Ingeniería de Software II Ingeniería de Software II Segundo Cuatrimestre de 2008 Clase 11 Introducción a la Mejora de Procesos Modelo IDEAL Modelos de Mejora de Procesos. CMMI y SCAMPI Buenos Aires, 6 de Octubre de 2008 Discusión

Más detalles

CMMi. Lic. Virginia Cuomo

CMMi. Lic. Virginia Cuomo CMMi Lic. Virginia Cuomo 1 Agenda Repaso CMMI Introducción Arquitectura Niveles de Madurez Representaciones Representación Discreta Representación Continua Discreta VS Continua 2 Repaso Qué vimos la tercer

Más detalles

2. EL MODELO CMMI. En 1991, el Instituto de Ingeniería de Software (SEI) publicó el Modelo de

2. EL MODELO CMMI. En 1991, el Instituto de Ingeniería de Software (SEI) publicó el Modelo de 2. EL MODELO CMMI 2.1 ANTECEDENTES DE CMMI En 1991, el Instituto de Ingeniería de Software (SEI) publicó el Modelo de Capacidad de Madurez (CMM). Dicho modelo está orientado a la mejora de los procesos

Más detalles

Taller de Fundamentos de Mejora de Procesos

Taller de Fundamentos de Mejora de Procesos Taller de Fundamentos de Mejora de Procesos Capability Maturity Model, CMM and CMMI are registered in the U.S. Patent and Trademark Office Process Consulting - 22052009 Módulo 01 Diapositiva 1 Expectativas

Más detalles

SW-CMM (CMM for Software)

SW-CMM (CMM for Software) Sinopsis de los modelos SW-CMM y CMMI Juan Palacio 1.0 Abril - 2006 Síntesis de los modelos de procesos CMM y CMMI para desarrollo y mantenimiento de software. CMMI (y previamente CMM) puede emplearse

Más detalles

CMMI Capability Maturity Model Integration Modelo integrado de madurez de la capacidad

CMMI Capability Maturity Model Integration Modelo integrado de madurez de la capacidad CMMI Capability Maturity Model Integration Modelo integrado de madurez de la capacidad Robin Alberto Castro Gil rcastro@icesi.edu.co Geovany Trejos Salas gtrejos@icesi.edu.co Monitoreo y control de proyectos

Más detalles

Mejora de los procesos de gestión de proyectos a través de la combinación de PMBOK y CMMi

Mejora de los procesos de gestión de proyectos a través de la combinación de PMBOK y CMMi Mejora de los procesos de gestión de proyectos a través de la combinación de PMBOK y CMMi Alejandro Sacomani, Adriana Chalar, Leandro Antonelli, Andrés Lisse Centro de Informática, Fiscalia de Estado,

Más detalles

Beneficios del Uso de Modelos de Madurez

Beneficios del Uso de Modelos de Madurez Beneficios del Uso de Modelos de Madurez Paneil WAMPS 2012 Jorge Boria L VEWARE 1 Madurar es Mejorar probabilidad objetivo Mejorar predicciones N1 a N2 disciplina de compromiso probabilidad objetivo probabilidad

Más detalles

Objetivo: Analizar las características de los modelos de estandarización de la calidad CMM, SPICE, IEEE e ISO

Objetivo: Analizar las características de los modelos de estandarización de la calidad CMM, SPICE, IEEE e ISO INGENIERÍA DE SOFTWARE AVANZADA MIS (Sesión 10) 4.3 Modelos de mejora de proceso (CMM y SPICE) 4.4 Normas técnicas (IEEE, ISO, EU, etc.) 4.3 Modelos de mejora de proceso (CMM y SPICE) Objetivo: Analizar

Más detalles

CMMI SERVICIOS. María Smith Gutiérrez Rueda - Quality Assurance Officer y Líder del Grupo de Ingeniería de Procesos (EPG) de Aranda Software

CMMI SERVICIOS. María Smith Gutiérrez Rueda - Quality Assurance Officer y Líder del Grupo de Ingeniería de Procesos (EPG) de Aranda Software CMMI SERVICIOS María Smith Gutiérrez Rueda - Quality Assurance Officer y Líder del Grupo de Ingeniería de Procesos (EPG) de Aranda Software AGENDA 1.- Qué es CMMI servicios? 2.- En qué nos puede ayudar

Más detalles

Modelo de Capacidad y Madurez o CMM (Capability Maturity Model), es un modelo de evaluación de los procesos de una organización.

Modelo de Capacidad y Madurez o CMM (Capability Maturity Model), es un modelo de evaluación de los procesos de una organización. Anexo 1 CMMI - Capability Maturity Model Integration Modelo de Capacidad y Madurez o CMM (Capability Maturity Model), es un modelo de evaluación de los procesos de una organización. Fue desarrollado inicialmente

Más detalles

Enginyeria del Software III

Enginyeria del Software III Enginyeria del Software III Sessió 2. El model CMM El model CMMi 1 El modelo CMM El modelo Capability Maturity Model (CMM), también denominado CMM-SW, fue desarrollado por el SEI como marco de referencia

Más detalles

Capability Maturity Model Integration CMMI - Overview I

Capability Maturity Model Integration CMMI - Overview I Capability Maturity Model Integration CMMI - Overview I CAPIS Centro de Ingeniería del Software e Ingeniería del Conocimiento Junio 2004 Objetivo de la presentación Brindar una visión general del CMMI

Más detalles

El Pensamiento Sistémico en la Ingeniería de Software. Dr. Cuauhtémoc Lemus Olalde clemola@cimat.mx. Centro de Investigación en Matemáticas (CIMAT)

El Pensamiento Sistémico en la Ingeniería de Software. Dr. Cuauhtémoc Lemus Olalde clemola@cimat.mx. Centro de Investigación en Matemáticas (CIMAT) El en la Ingeniería de ENCICA 2004 Dr. Cuauhtémoc Lemus Olalde clemola@cimat.mx Centro de Investigación en Matemáticas (CIMAT) Noviembre, 2004 Definición de En general el PS es un cuerpo de métodos, herramientas

Más detalles

El encuentro para los que buscan liderar proyectos con éxito. Cecilia Boggi,PMP Gerente de PMO millennium3 s.a

El encuentro para los que buscan liderar proyectos con éxito. Cecilia Boggi,PMP Gerente de PMO millennium3 s.a Proyecto de Mejora CMMI Un caso de Éxito Cecilia Boggi, PMP millennium3 s.a. 1 Cecilia Boggi,PMP Gerente de PMO millennium3 s.a Lic. en Análisis de Sistemas - UBA 25 años de experiencia en proyectos de

Más detalles

Consideraciones para la implementación de SOA en el desarrollo de productos. Septiembre, 2006

Consideraciones para la implementación de SOA en el desarrollo de productos. Septiembre, 2006 Consideraciones para la implementación de SOA en el desarrollo de productos Septiembre, 2006 Consideraciones para la implementación de SOA en el desarrollo de productos Las nuevas exigencias de los mercados

Más detalles

Grupo de procesos de Planificación

Grupo de procesos de Planificación Grupo de procesos de Planificación Fuentes: Information Technology Project Management, Fifth Edition, Copyright 2007 PMBOK, Quinta edición Preparó: Ing. Ismael Castañeda Fuentes Objetivos de Aprendizaje

Más detalles

Trabajo de tesis Framework de mejora de procesos de desarrollo de software

Trabajo de tesis Framework de mejora de procesos de desarrollo de software Trabajo de tesis Framework de mejora de procesos de desarrollo de software 1 ra Sección: Cuerpo principal Universidad Nacional de La Plata Facultad de informática Carrera: Magíster en Ingeniería de Software

Más detalles

Modelo de Procesos para la Industria de Software

Modelo de Procesos para la Industria de Software MoProSoft Modelo de Procesos para la Industria de Software Modelo MoProSoft 2 Perspectiva Histórica 2002 2003 2004 2005 AMCIS Círculo de Calidad 1996 Creación 1997 Emisión NMX-I-059 EvalProsoft Pruebas

Más detalles

La madurez de los servicios TI. de los servicios. La Gestión n de Servicios de TI (ITSM) Antoni Lluís s Mesquida, Antònia Mas, Esperança Amengual

La madurez de los servicios TI. de los servicios. La Gestión n de Servicios de TI (ITSM) Antoni Lluís s Mesquida, Antònia Mas, Esperança Amengual La madurez de los servicios TI Antoni Lluís s Mesquida, Antònia Mas, Esperança Amengual 4 de Septiembre de 2009 XI Jornadas de Innovación n y Calidad del Software (JICS) 1 La Gestión n de Servicios de

Más detalles

Describir el CMMI para el desarrollo de software, evolución, alcance y representación

Describir el CMMI para el desarrollo de software, evolución, alcance y representación Unidad 6: Introducción a CMMI Objetivo terminal de la Unidad Describir el CMMI para el desarrollo de software, evolución, alcance y representación Temas: Acerca del Modelo Capacidad Madurez Evolución de

Más detalles

Modelo de Factoría Software basado en CMMI. Ramiro Carballo r.carballo@gesein.com Marzo 2006 FOCAL Fundación Dintel

Modelo de Factoría Software basado en CMMI. Ramiro Carballo r.carballo@gesein.com Marzo 2006 FOCAL Fundación Dintel Modelo de Factoría Software basado en CMMI Ramiro Carballo r.carballo@gesein.com Marzo 2006 FOCAL Fundación Dintel Asociación n Española para la Calidad www.aec.es COMITÉ DE SOFTWARE Grupos de Trabajo:

Más detalles

Prof. Juan José Díaz Nerio. Foro de Tecnología : Gestión de la Calidad del Software. Domingo 16 Noviembre 2014

Prof. Juan José Díaz Nerio. Foro de Tecnología : Gestión de la Calidad del Software. Domingo 16 Noviembre 2014 Prof. Juan José Díaz Nerio. Foro de Tecnología : Gestión de la Calidad del Software. Domingo 16 Noviembre 2014 Agenda La Crisis del Software Conceptos asociados a Calidad Atributos de Calidad Funciones

Más detalles

De CMM (Capability Maturity Model) a CMMI (Capability Maturity Model Integration)

De CMM (Capability Maturity Model) a CMMI (Capability Maturity Model Integration) De CMM (Capability Maturity Model) a CMMI (Capability Maturity Model Integration) Preparado por: Amelia Soriano Alguna Bibliografía Carnagie Mellon - Software Engineering Institute, Capability Maturity

Más detalles

CLASE 2: INTRODUCCIÓN A LA ING. DE SOFTWARE. MODELOS DE PROCESOS. MEJORES PRÁCTICAS. USB Ing. De Software. Prof. I. C. Martínez

CLASE 2: INTRODUCCIÓN A LA ING. DE SOFTWARE. MODELOS DE PROCESOS. MEJORES PRÁCTICAS. USB Ing. De Software. Prof. I. C. Martínez CLASE 2: INTRODUCCIÓN A LA ING. DE SOFTWARE. MODELOS DE PROCESOS. MEJORES PRÁCTICAS USB Ing. De Software. Prof. I. C. Martínez Ing. De Software Ingeniería de Software La Ingeniería de Software es la ciencia

Más detalles

PRESENTACIÓN CMMI: (CAPABILITY MATURITY MODEL INTEGRATION)

PRESENTACIÓN CMMI: (CAPABILITY MATURITY MODEL INTEGRATION) PRESENTACIÓN CMMI: (CAPABILITY MATURITY MODEL INTEGRATION) INDICE 1. Introducción 2. Estructura CMMI 3. Nivel 2 4. Nivel 3 5. Nivel 4 6. Nivel 5 7. Bibliografía INTRODUCCIÓN Qué es y por qué usar CMMI?

Más detalles

Planificaciones. 7510 - Técnicas de Diseño. Docente responsable: PANTALEO GUILLERMO GUSTAVO. 1 de 5

Planificaciones. 7510 - Técnicas de Diseño. Docente responsable: PANTALEO GUILLERMO GUSTAVO. 1 de 5 Planificaciones 7510 - Técnicas de Diseño Docente responsable: PANTALEO GUILLERMO GUSTAVO 1 de 5 OBJETIVOS En este curso se busca introducir a los alumnos en el concepto de diseño de software. Para lograrlo

Más detalles

CMMI : mejora del proceso en Fábricas de Software

CMMI : mejora del proceso en Fábricas de Software CMMI : mejora del proceso en Fábricas de Software Cecilia Rigoni Brualla Caelum, Information & Quality Technologies Introducción Introducción Idea / Necesidad Investigación Diseño Inversión PRODUCTO Introducción

Más detalles

MSF. Microsoft Solutions Framework

MSF. Microsoft Solutions Framework MSF Microsoft Solutions Framework Breve Historia Desarrollado como resultado de los procesos en Microsoft: Mejores prácticas de la Industria. 25 años del grupo desarrollo + MS Consulting. Primera versión

Más detalles

Diplomado de. Administración. de Proyectos Diplomado de Administración de Proyectos: Preparación para la certificación del PMI

Diplomado de. Administración. de Proyectos Diplomado de Administración de Proyectos: Preparación para la certificación del PMI Diplomado de Administración de Proyectos Diplomado de Administración de Proyectos: Preparación para la certificación del PMI Módulo 1. Conceptos básicos de la Administración de Proyectos Conceptos básicos

Más detalles

Enginyeria del Software III

Enginyeria del Software III Enginyeria del Software III Sessió 3. L estàndard ISO/IEC 15504 Antònia Mas Pichaco 1 Introducción El proyecto SPICE representa el mayor marco de colaboración internacional establecido con la finalidad

Más detalles

Evaluación y Mejora de Procesos Software

Evaluación y Mejora de Procesos Software Evaluación y Mejora de Procesos Software Calidad de Procesos y Productos Software, Santander, 12-16 de julio de 2010 Dr. Javier Garzás, CISA, CGEIT y CSQE javier.garzas@kybeleconsulting.com Kybele Consulting

Más detalles

Proceso de Arquitectura de Software. Segunda. Semana. Dr. Cuauhtémoc Lemus Olalde. Noviembre 7, 2002. Informática

Proceso de Arquitectura de Software. Segunda. Semana. Dr. Cuauhtémoc Lemus Olalde. Noviembre 7, 2002. Informática Segunda Semana de Informática Proceso de Arquitectura de Software Dr. Cuauhtémoc Lemus Olalde Noviembre 7, 2002 Desarrollo Tradicional Requerimientos Diseño Codificación e Integración Prueba y Aceptación

Más detalles

Análisis Comparativo de Modelos de Calidad

Análisis Comparativo de Modelos de Calidad Análisis Comparativo de Modelos de Calidad Identificación de Mejores Prácticas para la Gestión de Calidad en Pequeños Entornos Vianca Vega Zepeda Departamento de Ingeniería de Sistemas y Computación Universidad

Más detalles

Calidad en el Servicio

Calidad en el Servicio Calidad en el Servicio Por qué es importante los procesos en el servicio? Beneficios de un modelo de referencia Resultados que se obtienen al operar servicios bajo estándares internacionales CMMI para

Más detalles

Maira Alejandra Bedoya Núñez. Universidad Francisco de Paula Santander Av. Gran Colombia No. 12E-96 Colsag. Cúcuta Norte de Santander 057-5751359,

Maira Alejandra Bedoya Núñez. Universidad Francisco de Paula Santander Av. Gran Colombia No. 12E-96 Colsag. Cúcuta Norte de Santander 057-5751359, Procesos necesarios para alcanzar el Nivel 2 de CMMI, en el área de Administración de Configuraciones de Software, para empresas pequeñas desarrolladoras de software. Judith del Pilar Rodríguez Tenjo Universidad

Más detalles

SCOPE PLANNING IN SOFTWARE PROJECTS PLANIFICACIÓN DEL ALCANCE EN PROYECTOS DE SOFTWARE

SCOPE PLANNING IN SOFTWARE PROJECTS PLANIFICACIÓN DEL ALCANCE EN PROYECTOS DE SOFTWARE Recibido: 23 de febrero de 2011 Aceptado: 29 de marzo de 2011 SCOPE PLANNING IN SOFTWARE PROJECTS PLANIFICACIÓN DEL ALCANCE EN PROYECTOS DE SOFTWARE MSc. Ailin Orjuela, MSc. Luis Alberto Esteban, MSc.

Más detalles

ESCUELA POLITÉCNICA NACIONAL

ESCUELA POLITÉCNICA NACIONAL ESCUELA POLITÉCNICA NACIONAL FACULTAD DE INGENIERÍA DE SISTEMAS MARCO DE TRABAJO PARA LA GESTIÓN DE LA CALIDAD EN PROYECTOS DE DESARROLLO DE SOFTWARE BASADO EN PMBOK Y CMMI DEV. TESIS PREVIA A LA OBTENCIÓN

Más detalles

Nuevo modelo de evaluación de procesos de TI de ISACA basado en COBIT (PAM)

Nuevo modelo de evaluación de procesos de TI de ISACA basado en COBIT (PAM) Nuevo modelo de evaluación de procesos de TI de ISACA basado en COBIT (PAM) Salomón Rico B. Socio de Information & Techonology Risk Services Deloitte México Salomón Rico B. Socio responsable de la práctica

Más detalles

Introduction to CMMI-DEV V1.3 (Introducción a CMMI-Desarrollo Versión 1.3)

Introduction to CMMI-DEV V1.3 (Introducción a CMMI-Desarrollo Versión 1.3) Introduction to CMMI-DEV V1.3 (Introducción a CMMI-Desarrollo Versión 1.3) Este curso oficial impartido por un instructor certificado por el SEI, tiene tres días de duración e introduce a los directivos

Más detalles

Visual Studio Team System

Visual Studio Team System Visual Studio Team System MSF for CMMi Process Improvement Aurelio Porras Development Tools Advisor aureliop@microsoft.com Microsoft Ibérica El éxito es raro Fallidos Problemáticos Existosos 2004 15% 51%

Más detalles

Syllabus. 1. Descripción del curso Tu curso está integrado con la siguiente información: Clave y nombre del programa o curso:

Syllabus. 1. Descripción del curso Tu curso está integrado con la siguiente información: Clave y nombre del programa o curso: 1. Descripción del curso Tu curso está integrado con la siguiente información: Área Responsable: Clave y nombre del programa o curso: Modalidad: Dirección de proyectos SPMP05 Seminario de Administración

Más detalles

Mejorando los procesos de negocio para asegurar la excelencia operativa. Daniel Vidales / Business Transformation Services Marzo, 2014

Mejorando los procesos de negocio para asegurar la excelencia operativa. Daniel Vidales / Business Transformation Services Marzo, 2014 Mejorando los procesos de negocio para asegurar la excelencia operativa Daniel Vidales / Business Transformation Services Marzo, 2014 Business Transformation Motores de la Transformación de Negocios Qué

Más detalles

METHODOLOGY FOR ASSESSMENT OF THE R&D PROCESS MATURITY OF AN ORGANIZATION

METHODOLOGY FOR ASSESSMENT OF THE R&D PROCESS MATURITY OF AN ORGANIZATION METHODOLOGY FOR ASSESSMENT OF THE R&D PROCESS MATURITY OF AN ORGANIZATION González González, R.; Rodríguez Montequín, V.; Villanueva Balsera, J.; Barros Alonso, S. Universidad de Oviedo Several standards,

Más detalles

Capitulo 4. Comparación entre la Representación Continua y la. Representación por Etapas

Capitulo 4. Comparación entre la Representación Continua y la. Representación por Etapas Capitulo 4. Comparación entre la Representación Continua y la Representación por Etapas "In God we trust, all others bring data." Deming Tal como ya se mencionó al final del Capitulo 2, dentro del CMMI

Más detalles

Técnico Certified Software Engineer Professional (CSIP)

Técnico Certified Software Engineer Professional (CSIP) Técnico Certified Software Engineer Professional (CSIP) Dirigido a: Profesionales de la ingeniería de sistemas Estudiantes universitarios de ingeniería en sistemas Requisitos: Requisitos para aplicar a

Más detalles

ESTÁNDARES Y MODELOS DE CALIDAD DEL SOFTWARE

ESTÁNDARES Y MODELOS DE CALIDAD DEL SOFTWARE ESTÁNDARES Y MODELOS DE CALIDAD DEL SOFTWARE INTRODUCCIÓN La calidad es un concepto complejo, que se viene aplicando en el campo de la informática desde hace muchos años, la aplicación de la calidad al

Más detalles

Definición de un Proceso de Implantación de Sistemas

Definición de un Proceso de Implantación de Sistemas Definición de un Proceso de Implantación de Sistemas Alicia Mon, Marcelo Estayno, Fernando López Gil, Eduardo De María 1 1 Grupo de Ingeniería de Software (G.I.S.) / Departamento de Sistemas / Universidad

Más detalles

Tres pilares para la Implantación de Sistemas

Tres pilares para la Implantación de Sistemas WICC 2012 621 Tres pilares para la Implantación de Sistemas Alicia Mon, Marcelo Estayno, Fernando López Gil, Eduardo De María 1 1 Grupo de Ingeniería de Software (G.I.S.) / Departamento de Sistemas / Universidad

Más detalles

CAPÍTULO 2. CMM : CAPABILITY MATURITY MODEL

CAPÍTULO 2. CMM : CAPABILITY MATURITY MODEL CAPÍTULO 2. CMM : CAPABILITY MATURITY MODEL Teniendo en cuenta que este trabajo tiene como objetivo el mostrar la metodología de evaluación del modelo de Capacidad de Madurez, es necesario antes de profundizar

Más detalles

Documentando la arquitectura de software Principios básicos por Omar Gómez

Documentando la arquitectura de software Principios básicos por Omar Gómez Documentando la arquitectura de software Principios básicos por Omar Gómez En la actualidad, uno de los temas candentes que se habla dentro de la comunidad de desarrollo de software es el referente a las

Más detalles

INGENIERÍA DE SOFTWARE Rational Unified Process RUP

INGENIERÍA DE SOFTWARE Rational Unified Process RUP 1 INGENIERÍA DE SOFTWARE Rational Unified Process RUP Rubby Casallas Departamento de Sistemas y Computación Facultad de Ingeniería Universidad de los Andes Referencias 2 http://www.rational.com/ http://www-306.ibm.com/software/awdtools/rup/

Más detalles

COMPILACION BIBLIOGRAFICA CMMI - escm-sp

COMPILACION BIBLIOGRAFICA CMMI - escm-sp COMPILACION BIBLIOGRAFICA CMMI - escm-sp Presentado Por Luz Marina López Gómez UNIVERSIDAD DE CALDAS FACULTAD DE INGENIERIAS Ingeniería de Sistemas Y Computación Octubre 06 de 2010 Manizales COMPILACION

Más detalles

E t s ima m c a i c ón ó n en e n pr p oy o e y c e t c os o s de d s f o twa w r a e

E t s ima m c a i c ón ó n en e n pr p oy o e y c e t c os o s de d s f o twa w r a e Estimación en proyectos de software Agosto 2009 CONTENIDO 1 Introducción 2 Modelos de estimación 3 La estimación en el modelo CMMi 4 Análisis de puntos funcionales 5 COCOMO II Referencias 1 Software Cost

Más detalles

13. Project Integration Management

13. Project Integration Management 13. Project Integration Management 13.1 Un pieza importante para el exito de un proyecto: " Excelente Project Integration Management" Project managers deben coordinar todas las áreas de conocimiento durante

Más detalles

Introducción al Unified Process. Curso IIC 2143 Ingeniería de Software Rodrigo Sandoval 2010

Introducción al Unified Process. Curso IIC 2143 Ingeniería de Software Rodrigo Sandoval 2010 Introducción al Unified Process Curso IIC 2143 Ingeniería de Software Rodrigo Sandoval 2010 Unified Process - UP Un framework de Proceso de Desarrollo de Software, una de cuyas versiones es el más documentado

Más detalles

Metodologías de seguridad en el desarrollo de la democracia electrónica. Javier Martín José A. Rubio

Metodologías de seguridad en el desarrollo de la democracia electrónica. Javier Martín José A. Rubio Metodologías de seguridad en el desarrollo de la democracia electrónica Javier Martín José A. Rubio Índice Introducción al problema Panorama de las metodologías de seguridad OCTAVE SSE-CMM Conclusiones

Más detalles

White Paper 2006. Una Introducción a CMMI

White Paper 2006. Una Introducción a CMMI White Paper 2006 Una Introducción a CMMI White Paper 2006 Contenidos INTRODUCCIÓN... 4 NIVELES DE MADUREZ Y ÁREAS DE PROCESO...4 UN MODELO DE REFERENCIA NO ES LA DESCRIPCIÓN DE UN PROCESO...7 PROCESOS

Más detalles

Motivación para la mejora de procesos basada en CMMI

Motivación para la mejora de procesos basada en CMMI Motivación para la mejora de procesos basada en CMMI ESI 2007 1 Situación real Sólo el 34% de los proyectos de software tiene éxito. Standish Group, CHAOS Report, 2003 ESI 2007 2 Qué está sucediendo? Problemáticos

Más detalles

Capítulo 1. Introducción

Capítulo 1. Introducción Capítulo 1. Introducción 1.1. Propósito de la Guía BABOK El propósito principal de la Guía BABOK Guide es definir la profesión del Análisis de Negocio y proveer un conjunto de prácticas comúnmente aceptadas.

Más detalles

Cómo citar el artículo Número completo Más información del artículo Página de la revista en redalyc.org

Cómo citar el artículo Número completo Más información del artículo Página de la revista en redalyc.org REICIS. Revista Española de Innovación, Calidad e Ingeniería del Software E-ISSN: 1885-4486 reicis@ati.es Asociación de Técnicos de Informática España Mesquida, Antoni Lluís; Mas, Antònia; Amengual, Esperança

Más detalles

Modelos y Normas Disponibles de Implementar

Modelos y Normas Disponibles de Implementar Modelos y Normas Disponibles de Implementar AmericaVeintiuno tiene capacidad para asesorar a una organización en base a diferentes modelos o normativas enfocadas al mercado informático. A partir de determinar

Más detalles

Desarrollo de un ciclo de mejora Construcción de un método de diagnóstico

Desarrollo de un ciclo de mejora Construcción de un método de diagnóstico Desarrollo de un ciclo de mejora Construcción de un método de diagnóstico Alicia Mon, Marcelo Estayno, Andrea Arancio {aliciamon, mestayno, andrea.arancio}@fibertel.com.ar G.I.S. UNLaM 1 Resumen. Las pequeñas

Más detalles

1. Introducción. 2. El concepto de calidad del software. 3. Estándares de calidad existentes. 4. La norma ISO 9000-3

1. Introducción. 2. El concepto de calidad del software. 3. Estándares de calidad existentes. 4. La norma ISO 9000-3 Contenido INGENIERIA DE SOFTWARE Tema 6: Administración de la calidad del software Presenta: David Martínez Torres Universidad Tecnológica de la Mixteca dtorres@mixteco.utm.mx Cubo 37 1. Introducción 2.

Más detalles

Dennis Garcia - PMP Ingeniero Electrónico de la universidad Javeriana, Magister Negocios TI del Korean Advanced Institute of Science and Technology.

Dennis Garcia - PMP Ingeniero Electrónico de la universidad Javeriana, Magister Negocios TI del Korean Advanced Institute of Science and Technology. Dennis Garcia - PMP Ingeniero Electrónico de la universidad Javeriana, Magister Negocios TI del Korean Advanced Institute of Science and Technology. Mas de 10 años de experiencia en formulación de proyectos

Más detalles

Las Factorías de Software según niveles de madurez ISO

Las Factorías de Software según niveles de madurez ISO Las Factorías de Software según niveles de madurez ISO Dr. Javier Garzás www.javiergarzas.com @jgarzas JORNADA. El modelo de AENOR de Gobierno y Gestión de las TICs con estándares ISO. Organizada por:

Más detalles

CMMI. Un modelo para optimizar los procesos de desarrollo. Jordi Borja Sanz (jordi.borja@borland.com) Technical Director Borland Spain & Portugal

CMMI. Un modelo para optimizar los procesos de desarrollo. Jordi Borja Sanz (jordi.borja@borland.com) Technical Director Borland Spain & Portugal CMMI. Un modelo para optimizar los procesos de desarrollo Jordi Borja Sanz (jordi.borja@borland.com) Technical Director Borland Spain & Portugal Agenda Por qué CMMI? Qué es CMMI? Beneficios obtenidos de

Más detalles

Uso de la representación continua de CMMI para la Mejora de Negocio

Uso de la representación continua de CMMI para la Mejora de Negocio Uso de la representación continua de CMMI para la Mejora de Negocio III Semana del CMMI Casimiro Hernández Parro 1 de Marzo 2007 Capability Maturity Model and CMMI are registered in the U.S. Patent and

Más detalles

EASY Software & Innovation. Diagnóstico CMMI. Versión: 1.0

EASY Software & Innovation. Diagnóstico CMMI. Versión: 1.0 EASY Software & Innovation Diagnóstico CMMI EASY Software & Innovation Versión:.0 NATHALY GONZÁLEZ MONTENEGRO FERNANDO BERNATE HEREDIA ANDRÉS MAURICIO RAMOS BONILLA NÉSTOR BOHÓRQUEZ SALDAÑA KERLYN HANS

Más detalles

Objetivos FACULTAD DE INGENIERIA. DEPARTAMENTO DE INGENIERIA DE SISTEMAS. Código de la asignatura 4070. Fecha de Actualización Julio 24 de 2012

Objetivos FACULTAD DE INGENIERIA. DEPARTAMENTO DE INGENIERIA DE SISTEMAS. Código de la asignatura 4070. Fecha de Actualización Julio 24 de 2012 Nombre de la asignatura Ingeniería de Software Código de la asignatura 4070 Fecha de Actualización Julio 24 de 2012 Intensidad horaria semanal Horas Contacto 4 Horas Trabajo Independiente 8 Créditos Académicos

Más detalles

A continuación se describe con mayor detalle cada una de las unidades: UNIDAD 2: Calidad en el desarrollo, adquisición, operación y mantenimiento del

A continuación se describe con mayor detalle cada una de las unidades: UNIDAD 2: Calidad en el desarrollo, adquisición, operación y mantenimiento del 1. OBJETIVOS: Incorporar los conceptos de indicador, métrica, medida, escala de medición, y proceso de medición. Entender la importancia de los indicadores de desempeño de procesos, su medición y seguimiento.

Más detalles

Modelos de Medición. De los Procesos de Desarrollo de Software

Modelos de Medición. De los Procesos de Desarrollo de Software Modelos de Medición De los Procesos de Desarrollo de Software Otros Modelos de Medición Junto con CMMI, buscan definir estándares y varas de medición para determinar la madurez y calidad de los procesos

Más detalles

Certificación Certificación como Business Process Management Professional (CPP)

Certificación Certificación como Business Process Management Professional (CPP) Certificación Certificación como Business Process Management Professional (CPP) Duración 96 horas Objetivo general: Prepara al participante con todos los elementos para realizar el examen de certificación

Más detalles

UNIVERSIDAD DE OVIEDO MÁSTER UNIVERSITARIO EN DIRECCIÓN DE PROYECTOS

UNIVERSIDAD DE OVIEDO MÁSTER UNIVERSITARIO EN DIRECCIÓN DE PROYECTOS UNIVERSIDAD DE OVIEDO MÁSTER UNIVERSITARIO EN DIRECCIÓN DE PROYECTOS ÁREA DE PROYECTOS DE INGENIERÍA TRABAJO FIN DE MÁSTER METODOLOGÍA PARA LA EVALUACIÓN DE LA MADUREZ DEL SISTEMA DE GESTIÓN DE LA I+D+I

Más detalles

Palabras Clave: Calidad de software, CMM, CMMI, ISO, comparación de modelos

Palabras Clave: Calidad de software, CMM, CMMI, ISO, comparación de modelos MODELOS DE CALIDAD PARA DESARROLLO DE SOFTWARE, COMPARACIÓN Carro Cartaya, Juan Carlos; Nápoles del Toro, Dalia AVANTE Infanta #58, Esq. A P, Centro Habana, Ciudad Habana, Cuba. CP: 10300 carro@avante.co.cu;

Más detalles

Qué es el Modelo CMMI?

Qué es el Modelo CMMI? El principal problema que tienen las empresas en sus áreas de tecnología, así como las empresas desarrolladoras de software al iniciar un proyecto, radica en que el tiempo de vida del proyecto y el presupuesto

Más detalles

4. SUMILLA 1. CMMI v 1.2 2. People Software Process & Team Software Process 3. Estándares ISO/IEC 4. Técnicas de Prueba de Software

4. SUMILLA 1. CMMI v 1.2 2. People Software Process & Team Software Process 3. Estándares ISO/IEC 4. Técnicas de Prueba de Software Universidad Católica San Pablo Facultad de Ingeniería y Computación Programa Profesional de Ciencia de la Computación SILABO CS391. Calidad de Software (Obligatorio) 2014-2 1. DATOS GENERALES 1.1 CARRERA

Más detalles

C O B I T. Conozca la. nueva Versión. CobIT 5

C O B I T. Conozca la. nueva Versión. CobIT 5 C O B I T Contenido Panorama general de la nueva Versión COBIT 5...1 Puntos relevantes en el contenido de la versión COBIT 5...2 Certificación en la nueva versión COBIT 5...8 Diferencias ITIL y COBIT 5...8

Más detalles

E a v l a ua u c a i c ón ó n de d l e Pr P oc o e c s e o s o de d Ing n e g n e i n er e ía a de d e So S f o twa w r a e

E a v l a ua u c a i c ón ó n de d l e Pr P oc o e c s e o s o de d Ing n e g n e i n er e ía a de d e So S f o twa w r a e Proceso de Ingeniería de Software Evaluación del Proceso de Ingeniería de Software 3. Evaluación del proceso 3.1. Modelos del proceso de evaluación 3.2. Métodos del proceso de evaluación 2 Los objetivos

Más detalles

CALIDAD DEL SOFTWARE TESTS DE EXAMEN ACTUALIZADO SEP. 2010 TEMA 4 MODELOS, METODOLOGÍAS Y ESTÁNDARES: ESTRATEGIAS PARA ALCANZAR LA CALIDAD

CALIDAD DEL SOFTWARE TESTS DE EXAMEN ACTUALIZADO SEP. 2010 TEMA 4 MODELOS, METODOLOGÍAS Y ESTÁNDARES: ESTRATEGIAS PARA ALCANZAR LA CALIDAD TEMA 4 MODELOS, METODOLOGÍAS Y ESTÁNDARES: ESTRATEGIAS PARA ALCANZAR LA CALIDAD 1. MODELOS, METODOLOGÍAS Y ESTÁNDARES 1.1 Definiciones 01 [Feb. 2006] [Feb. 2007] Cuál de las siguientes frases referidas

Más detalles

Encuesta Perfil de Egreso del Ingeniero en Computación y/o Informática en Chile (Para programas de 10 semestres o más)

Encuesta Perfil de Egreso del Ingeniero en Computación y/o Informática en Chile (Para programas de 10 semestres o más) Encuesta Perfil de Egreso del Ingeniero en Computación y/o Informática en Chile (Para programas de 10 semestres o más) Nombre del Encuestado e-mail Nombre de la Carrera Universidad Unidad Académica Sede

Más detalles

La Gestión de Equipos para la Mejora del Proceso Software

La Gestión de Equipos para la Mejora del Proceso Software La Gestión de Equipos para la Mejora del Proceso Software Esperança Amengual, Antònia Mas Departament de Matemàtiques i Informàtica Universitat de les Illes Balears 07122 Palma de Mallorca - Illes Balears,

Más detalles

Ingeniería de Software II

Ingeniería de Software II Ingeniería de Software II Segundo Cuatrimestre 2007 Clase 1b: Modelos de Ciclo de Vida Buenos Aires, 23 de Agosto de 2007 Qué es un modelo del ciclo de vida de un sistema? 8Una representación estandarizada

Más detalles

Propuesta de un modelo de análisis para estimación del tamaño del software y gestión de costos y riesgos a partir de requerimientos funcionales

Propuesta de un modelo de análisis para estimación del tamaño del software y gestión de costos y riesgos a partir de requerimientos funcionales Propuesta de un modelo de análisis para estimación del tamaño del software y gestión de costos y riesgos a partir de requerimientos funcionales S.Forigua, O.Ballesteros Abstract. This paper describes the

Más detalles

Sistema para auditar el cumplimiento de CMMI-SW nivel 2.

Sistema para auditar el cumplimiento de CMMI-SW nivel 2. Sistema para auditar el cumplimiento de CMMI-SW nivel 2. César Gabriel Vargas 1 Germán Biagioli 2 Trabajo final para obtener el grado de Licenciado en Informática / Licenciatura en Sistemas De la Facultad

Más detalles

Cuál es la madurez que necesitarían los procesos para el desarrollo de sistemas de software crítico?

Cuál es la madurez que necesitarían los procesos para el desarrollo de sistemas de software crítico? Cuál es la madurez que necesitarían los procesos para el desarrollo de sistemas de software crítico? Patricia Rodríguez Dapena, Josefina Alonso Nocelo, José Carlos Sánchez Domínguez SoftWcare, S.L C/.

Más detalles

Aseguramiento de la calidad y pruebas de software. 2- Estándares y Modelos para la mejora del proceso de software

Aseguramiento de la calidad y pruebas de software. 2- Estándares y Modelos para la mejora del proceso de software Aseguramiento de la calidad y pruebas de software 2- Estándares y Modelos para la mejora del proceso de software Blanca A. Vargas Govea vargasgovea@itesm.mx Febrero 8, 2013 Objetivo Conocer los diferentes

Más detalles

Universidad Ricardo Palma Facultad de Ingeniería

Universidad Ricardo Palma Facultad de Ingeniería Universidad Ricardo Palma Facultad de Ingeniería Escuela Académico Profesional de Ingeniería Informática Sílabo Plan de Estudios 2006-II I. DATOS GENERALES Curso : Calidad de Código : IF 0905 Ciclo : IX

Más detalles

Evolución de los modelos CMMI

Evolución de los modelos CMMI Evolución de los modelos CMMI Enrique Morey Capability Maturity Model and CMMI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University ESI 2009 1 Pregunta Qué entendemos como

Más detalles

CMMI (Capability Maturity Model Integrated)

CMMI (Capability Maturity Model Integrated) CMMI (Capability Maturity Model Integrated) El SEI (software engineering institute) a mediados de los 80 desarrolló el CMM (modelo de madurez de la capacidad de software). CMMI: CMM integrado, una mezcla

Más detalles

Organiza: Miembros de la red:

Organiza: Miembros de la red: Organiza: CMMI Capability Maturity Model Integration o El Modelo de Capacidad de Madurez e Integración ha sustituido actualmente al SW-CMM Capability Maturity Model for Software o Modelo de Madurez de

Más detalles

SW-CMM Capability Maturity Model for Software

SW-CMM Capability Maturity Model for Software SW-CMM Capability Maturity Model for Software Introducción 1986 Comienzan Estudios. SEI (Software Engineering Institute - UCM). 1991 Nace CMM v1.0 1994 CMM v1.1 P-CMM SE-CMM SW-CMM CMMs IPD-CMM CMMI SA-CMM

Más detalles

MODELOS DE CALIDAD EN EL DESARROLLO DE SOFTWARE

MODELOS DE CALIDAD EN EL DESARROLLO DE SOFTWARE MODELOS DE CALIDAD EN EL DESARROLLO DE SOFTWARE INTRODUCCIÓN Los Modelos de Calidad son herramientas que guían a las Organizaciones a la Mejora Continua y la Competitividad dando les especificaciones de

Más detalles

Diplomado en Administración de Proyectos

Diplomado en Administración de Proyectos Diplomado en Administración de Proyectos HP221 Grupos de procesos y áreas de conocimiento 1 Bienvenida Bienvenido al curso Grupos de procesos y áreas de conocimiento! El PMBOK Guide -Project Management

Más detalles