CALIDAD DE SOFTWARE CMMI.

CapabilityMaturityModelIntegration, de ahora en adelante CMMI, es un modelo de referencia que se diferencia de otros modelos por el hecho de estar basado en prcticas ajustables a cualquier dominio de produccin y poseer un enfoque global e integrado de la organizacin, con el propsito de alcanzar los objetivos del negocio. De esa forma CMMI permite a empresas complejas compuestas por varias reas de negocio instaurar de una forma ms sencilla un sistema de aseguramiento de la calidad. El CMM - CMMI es un modelo de calidad del software que clasifica las empresas en niveles de madurez. Estos niveles sirven para conocer la madurez de los procesos que se realizan para producir software. El departamento de defensa de los estados unidos tena muchos problemas con el software que encargaba desarrollar a otras empresas, los presupuestos se disparaban, las fechas alargaban ms y ms. Quin no se ha encontrado con este tipo de problemas si ha trabajado con una empresa de software? Como esta situacin les pareca intolerable convoc un comit de expertos para que solucionase estos problemas, en el ao 1983 dicho comit concluy "Tienen que crear un instituto de la ingeniera del software, dedicado exclusivamente a los problemas del software, y a ayudar al Departamento de Defensa". Convocaron un concurso pblico en el que dijeron: "Cualquiera que quiera enviar una solicitud tiene que explicar cmo van a resolver estos 4 problemas", se presentaron diversos estamentos y la Universidad Carnegie Mellon gan el concurso en 1985, creando el SEI. El SEI (Software EngineeringInstitute) es el instituto que cre y mantiene el modelo de calidad CMM CMMI. El Software EngineeringInstitute (SEI) de la Carnegie MellonUniversity de los Estados Unidos, creador del modelo CMMI y de la mayora de sus predecesores, ha elaborado sus modelos bajo la premisa que la calidad de un producto o servicio est altamente influenciada por la calidad de los procesos que los producen y los mantienen [Chr06]. Es por ello que la mejora continua de los procesos debiese ir paulatinamente incrementando el nivel de capacidad y madurez de una organizacin. Los procesos en conjunto transitan desde procesos no definidos, es decir, procesos cuya organizacin cuenta con poca capacidad y con inmadurez para realizarlos, a procesos disciplinados cuya organizacin cuenta con la capacidad y madurez suficiente para desarrollarlos con calidad probada. Luego una organizacin es capaz de definir su calidad total por medio del nivel de madurez de capacidades en que se encuentre de acuerdo a sus procesos. Los niveles CMM - CMMI son 5: y Inicial o Nivel 1 CMM - CMMI. Este es el nivel en donde estn todas las empresas que no tienen procesos. Los presupuestos se disparan, no es posible entregar el proyecto en fechas, te tienes que quedar durante noches y fines de semana para terminar un proyecto. No hay control sobre el estado del proyecto, el desarrollo del proyecto es completamente opaco, no sabes lo que pasa en l.

Es el tpico proyecto en el que se da la siguiente situacin: - Cmo va el proyecto? - Bien, bien. Dos semanas despus - Cmo va el proyecto? - Bien, bien. Tres semanas despus - El lunes hay que entregar el proyecto.- No se por qu pero los proyectos se entregan los l unes. - El lunes !!?. Todava falta mucho!! - Cmo? Me dijiste que el proyecto iba bien!! Arrglatelas como quieras, pero el proyecto tiene que estar terminado para el lunes. Si no sabes el tamao del proyecto y no sabes cuanto llevas hecho, nunca sabrs cuando vas a terminar.

Repetible o Nivel 2 CMM - CMMI. Quiere decir que el xito de los resultados obtenidos se pueden repetir. La principal diferencia entre este nivel y el anterior es que el proyecto es gestionado y controlado durante el desarrollo del mismo. El desarrollo no es opaco y se puede saber el estado del proyecto en todo momento. Los procesos que hay que implantar para alcanzar este nivel son: Gestin de requisitos Planificacin de proyectos Seguimiento y control de proyectos Gestin de proveedores Aseguramiento de la calidad Gestin de la configuracin

Definido o Nivel 3 CMM - CMMI. Resumindolo mucho, este alcanzar este nivel significa que la forma de desarrollar proyectos (gestin e ingeniera) esta definida, por definida quiere decir que esta establecida, documentada y que existen mtricas (obtencin de datos objetivos) para la consecucin de objetivos concretos. Los procesos que hay que implantar para alcanzar este nivel son: Desarrollo de requisitos Solucin Tcnica Integracin del producto Verificacin Validacin Desarrollo y mejora de los procesos de la organizacin Definicin de los procesos de la organizacin Planificacin de la formacin Gestin de riesgos Anlisis y resolucin de toma de decisiones

La mayora de las empresas que llegan al nivel 3 paran aqu, ya que es un nivel que proporciona muchos beneficios y no ven la necesidad de ir ms all porque tienen cubiertas la mayora de sus necesidades.

Cuantitativamente Gestionado o Nivel 4 CMM - CMMI. Los proyectos usan objetivos medibles para alcanzar las necesidades de los clientes y la organizacin. Se usan mtricas para gestionar la organizacin.

Los procesos que hay que implantar para alcanzar este nivel son: Gestin cuantitativa de proyectos Mejora de los procesos de la organizacin

Optimizado o Nivel 5 CMM - CMMI. Los procesos de los proyectos y de la organizacin estn orientados a la mejora de las actividades. Mejoras incrementales e innovadoras de los procesos que mediante mtricas son identificadas, evaluadas y puestas en prctica. Los procesos que hay que implantar para alcanzar este nivel son: Innovacin organizacional Anlisis y resolucin de las causas Normalmente las empresas que intentan alcanzar los niveles 4 y 5 lo realizan simultneamente ya que estn muy relacionados.

A grandes rasgos os he intentado introducir el modelo de calidad del software CMM - CMMI para aquella gente que se encuentra por primera vez con l. La implantacin de un modelo de estas caractersticas es un proceso largo y costoso que puede costar varios aos de esfuerzo. Aun as el beneficio obtenido para la empresa es mucho mayor que lo invertido. CMMI Versin 1.2 CapabilityMaturityModel Integration (CMMI) es un modelo de aseguramiento de la calidad que busca la mejora continua de las organizaciones mediante el anlisis y re-diseo de los procesos que subyacen en la organizacin. Fue creado por el SEI (Software EngineeringInstitute) de la Universidad de Carnegie-Mellon y patrocinado por el Ministerio de Defensa de los Estados Unidos. Con el propsito de lograr la mejora de los procesos, CMMI provee: Una forma de integrar los elementos funcionales de una organizacin [SEI07b]. Un conjunto de mejores prcticas basadas en casos de xito probado de organizaciones experimentadas en la mejora de procesos. Ayuda para identificar objetivos y prioridades para mejorar los procesos de la organizacin [SEI07b], dependiendo de las fortalezas y debilidades de la organizacin que son obtenidas mediante un mtodo de evaluacin.

Un apoyo para que las empresas complejas en actividades productivas puedan coordinar sus actividades en la mejora de los procesos. Un punto de referencia para evaluar los procesos actuales de la organizacin [SEI07b]. CMMI v1.2 corresponde a la tercera versin entregable del modelo CMMI, posterior a las versiones 1.02 (primera versin ao 2000) y 1.1 (ao 2002) [Chr06]. Las versiones previas sirvieron como retroalimentacin para que los propios usuarios, evaluadores y evaluados hicieran acotaciones sobre posibles mejoras, las cuales fueron estudiadas, refinadas y algunas incluidas en la versin 1.2. CMMI v1.2 para desarrollo, que corresponde a una de tres constelaciones de prcticas, es una gua que ayuda a manejar, medir y monitorear procesos [SEI07a] utilizados en el desarrollo de productos y servicios de una organizacin, y contiene prcticas ligadas a la administracin de proyectos, administracin de procesos, ingeniera y soporte. Las otras dos constelaciones son CMMI para Adquisicin que provee una gua para liderar la adquisicin informada y decisiva [SEI07a], y CMMI para Servicios que proporciona una gua para la entrega de servicios a clientes internos y externos de la organizacin [SEI07a]. Ambas constelaciones se encuentran an en desarrollo. Junto con CMMI se desarroll y public el mtodo de evaluacin "AssessmentRequirementsfor CMMI (ARC)" [SEI00] en el ao 2000, el cual define los requerimientos considerados esenciales para realizar una evaluacin de CMMI en una organizacin y "Standard CMMI AppraisalMethodforProcessImprovement", (SCAMPI) [SEI01], manual seguido por los evaluadores para medir el nivel de madurez de una organizacin. Estos dos documentos tambin se han actualizado como consecuencia de la retroalimentacin de la comunidad involucrada en CMMI, generando la ltima versin 1.2 de SCAMPI [SEI06a] y ARC [SEI06b] ambas publicadas el ao 2006. Representaciones La representacin usada en CMMI entrega una gua para efectuar las actividades de mejora de los procesos y es utilizada en el mtodo de evaluacin. Segn el modelo se tienen dos formas para mejorar. Una forma es mejorar un proceso especfico o un conjunto de ellos usando la Representacin Continua (ContinuousRepresentation) y la otra es la mejora de la organizacin completa segn los procesos definidos y ocupados usando la Representacin Escalonada o por Etapas (StagedRepresentation). En la Tabla 1 se muestran los niveles para estos dos tipos de representaciones. Representacin Continua La representacin continua se focaliza en la mejora de un proceso o un conjunto de ellos relacionado(s) estrechamente a un rea de proceso en que una organizacin desea mejorar, por lo tanto una organizacin puede ser certificada para un rea de proceso en cierto nivel de capacidad. Existen seis niveles de capacidad por donde transitan los procesos asociados a un rea de proceso y cada nivel es construido sobre el nivel anterior, es decir para que un proceso alcance un nivel de capacidad necesariamente debe haber alcanzado el nivel anterior.

Estructura del CMMI Un rea de proceso es un conjunto de prcticas relacionadas que cuando son implementadas colectivamente, satisfacen un conjunto objetivos considerados importantes para mejorar esa rea de proceso. Las reas de proceso del modelo son 22. Cada una de ellas es implementada para alcanzar el nivel de madurez correspondiente y se agrupan de acuerdo a cuatro categoras: Administracin de Procesos, Administracin de Proyectos, Ingeniera y Soporte. Este agrupamiento es realizado para mostrar cmo se relaciona cada rea de proceso dentro de una categora. Sin embargo, reas de procesos de distintas categoras pueden encontrarse relacionadas, pero dado que en este documento se desarrollarn slo reas de procesos de una misma categora (Ingeniera) estas relaciones se desprecian. Descripcin de las reas de Proceso A continuacin se har una breve descripcin de cada rea de proceso nombrada en Tabla 2. Explcitamente se nombra a productos pero tambin se puede aplicar las mismas definiciones a servicios. Anlisis y Resolucin Causales (CAR): Identifica la causa de defectos u otros problemas. Luego de ellos toma acciones correctivas para prevenir la ocurrencia de tales defectos o problemas en el futuro. Anlisis y Resolucin de Decisiones (DAR): Proporciona un proceso estructurado de toma de decisiones que asegura que las alternativas se comparan con criterios establecidos y objetivos para as tomar la mejor decisin posible. Aseguramiento de Calidad de Procesos y Productos (PPQA): Proporciona un conjunto de prcticas con el objetivo de evaluar productos, servicios, procesos y sus artefactos relacionados. Definicin de Procesos Organizacionales (OPD): Establece y mantiene un conjunto de estndares tanto en procesos organizacionales como en ambientes de trabajo. Desarrollo de Requerimientos (RD): Recopila las necesidades del cliente para convertirlas en requerimientos del producto esperado.

Entrenamiento Organizacional (OT): Permite a la gente de la organizacin obtener habilidades y conocimientos necesarios para que el trabajo realizado por ellos sea efectivo y eficiente. Administracin Cuantitativa de Proyectos (QPM): Maneja mtricas cuantitativas de los procesos con el objetivo de alcanzar los objetivos de calidad establecidos. Adems mediante el anlisis de estos datos permite identificar oportunidades de mejora para los procesos. Administracin de Acuerdos con Proveedores (SAM): Gestiona la adquisicin de productos de proveedores con los cuales exista un acuerdo formal [Rig06]. Administracin de Requerimientos (REQM): Gestiona los requerimientos del producto durante todo el ciclo de vida de l, identificando inconsistencias con los artefactos y planes de proyecto. Administracin de Riesgos (RSKM): Identifica riesgos del proyecto para evaluarlos, priorizarlos y gestionarlos para prevenir su futura ocurrencia. Administracin de la Configuracin (CM): Establece y mantiene la integridad y consistencia de los artefactos [Rig06]. Administracin Integral de Proyecto (IPM): Adapta el conjunto de procesos estndares de la organizacin a procesos llevados a cabo para un proyecto en particular. Adems maneja a las partes interesadas involucradas en el proyecto. Innovacin y Despliegue Organizacional (OID): Selecciona y despliega mejoras incrementales e innovadoras que mejoran en forma medida los procesos de la organizacin y tecnologas, para alcanzar los objetivos de calidad organizacional y de realizacin de procesos derivados de los objetivos de negocio de la organizacin [Chr06]. Integracin de Producto (PI): Ensambla las componentes del producto para producir un producto ms complejo manteniendo el cumplimiento de los requerimientos establecidos. Medicin y Anlisis (MA): Establece mtricas con el objetivo de entregar resultados objetivos que sirvan como base para tomar decisiones informadas y correctivas. Monitoreo y Control de proyecto (PMC): Analiza el proyecto con el objetivo de establecer un control y evaluacin segn lo planes establecidos, tomando acciones correctivas cuando es necesario. Planificacin de Proyecto (PP): Desarrolla y mantiene planes del proyecto, compromisos adquiridos por parte de los participantes del proyecto y gestiona las partes interesadas del proyecto. Procesos Orientados a la Organizacin (OPF): Ayuda a mantener un entendimiento de los procesos por parte de los miembros de la organizacin. Tambin ayuda a identificar posibles mejoras de los procesos, que son evaluadas y eventualmente implementadas.

Rendimiento de Procesos Organizacionales (OPP): Deriva objetivos cuantitativos de calidad y ejecucin de lo procesos desde el conjunto de objetivos de negocio de la organizacin [Rig06]. Solucin Tcnica (TS): Disea, desarrollo e implementa soluciones para los requerimientos del producto establecido. Validacin (VAL): Demuestra que el producto, componentes del producto y artefactos corresponden a lo esperado para su uso. Verificacin (VER): Demuestra que el producto, componentes del producto y artefactos cumplen con los requerimientos establecidos.

Relaciones entre las reas de proceso Hay cuatro grupos o categoras de reas de procesos que ayudan a guiar el proceso de mejora de la organizacin. Estos grupos estn formados por reas de proceso que se interrelacionan fuertemente y tienen caractersticas comunes asociadas a objetivos de negocio tradicionales. Estas categoras son las indicadas en la Tabla 2 para cada rea de proceso: Administracin de procesos, Administracin de proyectos, Soporte e Ingeniera. A Continuacin se describen brevemente las tres primeras categoras, para luego enfocarse en una descripcin detallada de la categora de Ingeniera que es la de inters en este documento. Administracin de procesos: Contiene reas de proceso relacionadas con definir, planear, desplegar, implementar, monitorear, controlar, evaluar, medir y mejorar procesos [Chr06]. Administracin de proyectos: Contiene reas de proceso relacionadas con planeacin, monitoreo y control de proyectos. Soporte: Contiene reas de proceso relacionadas con actividades que apoyan el desarrollo y mantenimiento del producto, y que estn dirigidas a los procesos que son usados en el contexto del desarrollo de procesos pertenecientes a otras reas [Chr06]. Ingeniera: Cubre actividades relacionadas al desarrollo y mantenimiento que son compartidas por toda la organizacin. Cualquier disciplina tcnica involucrada en desarrollo de productos o servicios puede ocupar esta categora para enfocar el proceso de mejora. reas de Proceso de Ingeniera Las reas de proceso de Ingeniera pueden integrar los procesos asociados con diferentes disciplinas de ingeniera cuando el producto final es consecuencia de ellas, dando as un soporte para estrategias organizacionales orientas en el producto: Desarrollo de Requerimientos (RD). Gestin de Requerimientos (REQM). Solucin Tcnica (TS).

Integracin de Productos (PI). Verificacin (VER). Validacin (VAL). RD identifica las necesidades de un cliente y las transforma en "requerimientos del producto". Luego, estos son analizados para producir "requerimientos de las componentes del producto", "requerimientos de interfaz de las componentes" y un modelo conceptual de alto nivel de la solucin . Los distintos requerimientos son suministrados a TS que produce una arquitectura del producto, un diseo del producto en componentes y diseo de las propias componentes. Adems, TS desarrolla cada componente las cuales son suministradas a PI - donde las componentes son integradas verificando el cumplimiento de las interfaces que fueron definidas. TS utiliza a VER para realizar la verificacin del diseo. REQM mantiene los requerimientos describiendo actividades para obtener y controlar los cambios y la trazabilidad de las necesidades del cliente al producto. Como REQM controla los cambios a los requerimientos que pueden tener como fuente todas las otras reas de proceso de Ingeniera, esta rea de proceso es recursiva, dinmica y transversal a la categora. El rea de proceso VER asegura que los artefactos satisfacen los requerimientos especificados. VER es un rea incremental, pues comienza con la verificacin de las componentes del producto para terminar con la verificacin del producto completo. VAL es un rea de proceso incremental que valida el producto, las componentes del producto, los artefactos intermedios y los procesos con respecto a las necesidades de los clientes. Los conflictos que son descubiertos son usualmente resueltos en RD y TS. PI es el responsable de generar la mejor secuencia de integracin de componentes posible, integrarlas y dar la aprobacin para la entrega del producto al cliente. PI usa prcticas especficas de VER y VAL para implementar el proceso de integracin del producto. A continuacin se detalla cada una de las reas de proceso de la categora de Ingeniera del modelo CMMI. Esta informacin fue obtenida de la referencia del modelo, CMMI para Desarrollo v1.2 . Administracin de Requerimientos El rea de proceso Administracin de Requerimientos (REQM) se encarga de administrar todos los requerimientos recibidos o generados por el proyecto, incluyendo tanto los tcnicos y no-tcnicos como los impuestos por la organizacin. Cuando un proyecto recibe requerimientos, estos son revisados con un proveedor para resolver inconsistencias y malentendidos antes de ser ingresados a los planes del proyecto. El jefe de proyecto administra los cambios en los requerimientos a medida que el proyecto avanza e identifica inconsistencias que ocurren entre planes, productos de trabajo y requerimientos.

SG 1: Administrar Requerimientos Objetivo: "Los requerimientos deben ser administrados y las inconsistencias con el plan de proyecto y artefactos son identificadas" Los proyectos deben mantener actualizados y aprobados el conjunto de requerimientos durante el transcurso del proyecto para realizar lo siguiente: - Administrar todos los cambios en los requerimientos. - Mantener las relaciones entre los requerimientos, el plan del proyecto y los productos de trabajo. - Identificar las inconsistencias entre los requerimientos, el plan del proyecto y los productos de trabajo. - Tomar las acciones correctivas. 22. SP 1 Obtener una comprensin de los requerimientos Prctica: "Desarrollar entendimiento comn con los responsables de entregar los requerimientos sobre el significado y alcance de cada uno de ellos" A medida que el proyecto avanza y los requerimientos son derivados, todas las actividades o disciplinas recibirn requerimientos. Para evitar un flujo descontrolado de requerimientos, se establecen criterios para sealar las fuentes oficiales de las cuales recibirlos. Se debe asegurar un entendimiento compatible y compartido con los proveedores de requerimientos sobre el significado de cada uno de ellos. El resultado de este anlisis y dilogo es un conjunto de requerimientos consensuado. 23. SP 2 Obtener compromiso con los requerimientos Prctica: "Obtener compromiso de requerimientos por parte del los participantes del proyecto" Mientras la prctica especfica anterior se ocupa de alcanzar entendimiento con los proveedores de requerimientos, esta prctica especfica se refiere a los acuerdos y compromisos de quienes tienen que cumplir con las actividades necesarias para implementar los requerimientos, es decir, el equipo de proyecto. A medida que los requerimientos evolucionan, esta prctica especfica asegura que los participantes del proyecto se comprometan con los requerimientos aprobados y con los cambios resultantes en planes, actividades y artefactos. 24. SP 3 Administrar cambios a los requerimientos Prctica: "Manejar cambios de requerimientos a medida que estos se desarrollan durante el proyecto"

Durante el proyecto, los requerimientos cambian por distintas razones. A medida que las necesidades cambian y el trabajo avanza, se obtienen requerimientos adicionales y puede ser necesario modificar los existentes. Es esencial administrar estos requerimientos nuevos y modificados en forma efectiva y eficiente. Para analizar el impacto de los cambios de forma efectiva, es necesario que la fuente de cada requerimiento sea conocida y que el fundamento del cambio sea documentado. El Jefe de Proyecto puede, sin embargo, verificar mtricas apropiadas de volatilidad de requerimientos para juzgar si se requieren nuevos controles o modificar los actuales. 25. SP 4 Mantener trazabilidad bidireccional de los requerimientos Prctica: "Mantener trazabilidad bidireccional entre requerimientos y artefactos". El propsito de esta SP es mantener la trazabilidad bidireccional por cada nivel de descomposicin del producto final. Cuando los requerimientos son bien administrados, la trazabilidad puede ser establecida desde la fuente del requerimiento a su nivel ms bajo, y desde el nivel ms bajo volver a sus orgenes. Dicha trazabilidad bidireccional ayuda a determinar que todos los requerimientos fuente han sido completamente abordados y que todos los requerimientos de ms bajo nivel puedan ser relacionados con una fuente vlida. La trazabilidad puede tambin cubrir relaciones horizontales, tales como interfaces y es particularmente necesaria al evaluar el impacto de cambios a requerimientos en los planes, actividades y productos de trabajo del proyecto. 26. SP 5: Identificar inconsistencias entre artefactos del proyecto y los requerimientos Prctica: "Identificar inconsistencias entre los planes de proyecto y artefactos y los requerimientos" Esta prctica especfica detecta las inconsistencias entre requerimientos y los planes de proyecto y artefactos, e inicia las acciones correctivas para solucionarlas. Desarrollo de Requerimientos El rea de proceso de Desarrollo de Requerimientos (RD) se encarga de identificar las necesidades de los clientes y traducirlas en requerimientos. El conjunto de requerimientos de un proyecto es analizado para producir una solucin conceptual de alto nivel. Estos requerimientos se destinan a ciertos componentes del producto final y son los que describen su rendimiento, caractersticas de diseo, su verificacin, etc. para comprensin y utilizacin futura por parte de desarrolladores. SG 1: Desarrollar requerimientos del cliente Objetivo: "Necesidades de las partes interesadas, expectaciones, restricciones, e interfaces son recogidas y traducidas en requerimientos del cliente". Las necesidades de las partes interesadas (clientes, usuarios finales, proveedores, desarrolladores y encargados de prueba) son la base para determinar los requerimientos del

cliente. Estas necesidades, expectativas, restricciones, interfaces, conceptos operacionales y conceptos de productos son analizados, matizados, refinados y elaborados para traducirlos en un conjunto de requerimientos del cliente. Frecuentemente estas son mal identificadas o contradictorias. Ya que las necesidades de actores, expectativas, restricciones y limitaciones deben ser claramente identificadas y entendidas, un proceso iterativo es usado durante todo el proyecto para conseguir este objetivo. Para facilitar la interaccin requerida, un sustituto del usuario final o cliente es frecuentemente involucrado para representar las necesidades de ste y ayudar a resolver conflictos. Restricciones de ambiente, legales y otras debieran ser consideradas cuando se crea o resuelve el conjunto de requerimientos del cliente. 27. SP 1: Obtener necesidades Prctica: "Identificar y recoger las necesidades, expectativas, restricciones e interfaces de las partes interesadas para todas las fases del ciclo de vida del producto". La obtencin va ms all de recopilar requerimientos, ya que implica buscar activamente la identificacin de requerimientos que no hayan sido provistos explcitamente por el cliente. Los requerimientos adicionales debiesen abordar las diversas actividades del ciclo de vida del producto y su impacto en l. 28. SP 2: Desarrollar los requerimientos del cliente Prctica: "Transformar las necesidades de las partes interesadas, expectativas, restricciones e interfaces en requerimientos del cliente". Las distintas entradas de las partes interesadas deben ser consolidadas, la informacin faltante debe ser obtenida y los conflictos deben ser resueltos al documentar el conjunto de requerimientos reconocidos por el cliente. Los requerimientos del cliente pueden incluir necesidades, expectativas y restricciones con respecto a verificacin y validacin. En algunas situaciones, el cliente provee un conjunto de requerimientos al proyecto, o los requerimientos existen como una salida de actividades anteriores del proyecto. En estos casos, los requerimientos del cliente podran contradecir las necesidades, expectativas, restricciones e interfaces de las partes interesadas y debern ser transformadas en un conjunto de requerimientos reconocidos por el cliente, luego de resolver los conflictos adecuadamente. Las partes interesadas que forman parte de todas las etapas del ciclo de vida del producto debieran incluir funciones tcnicas y de negocios. De esta manera, los conceptos de todos los procesos relacionados con el ciclo de vida del producto son considerados junto con el concepto del producto. SG 2: Desarrollar requerimientos de productos Objetivo: "Requerimientos del cliente son refinadas y elaboradas para desarrollar requerimientos del producto y componentes del producto". Los requerimientos del cliente son analizados en conjunto con el desarrollo del concepto operacional para obtener un conjunto de requerimientos ms detallado y preciso y se le llama

requerimientos del producto y de componentes del producto. Los requerimientos del producto y de componentes del producto abordan las necesidades asociadas con cada fase del ciclo de vida del producto. De los requerimientos obtenidos surgen de las restricciones, consideraciones de temas no explcitamente indicados en la lnea base de requerimientos del cliente y factores introducidos por la arquitectura seleccionada, el diseo y las consideraciones especficas de negocio del desarrollador. Los requerimientos son revisados con nivel anterior de conjunto de requerimientos y arquitectura funcional, y el concepto preferido del producto es refinado. Los requerimientos son asociados a funciones y componentes del producto incluyendo objetos, personas y procesos. La trazabilidad de los requerimientos a funciones, objetos, pruebas, problemas u otras entidades es documentada. Los requerimientos asociados y las funciones son la base de la sntesis de la solucin tcnica. A medida que los componentes internos son desarrollados se definen interfaces adicionales y establecen los requerimientos de interfaz. 29. SP 1: Establecer requerimientos del producto y de componentes del producto Prctica: "Establecer y mantener requerimientos del producto y componentes del producto, los cuales son basados en los requerimientos del cliente". Los requerimientos del cliente pueden ser expresados en los trminos del cliente y pueden ser descripciones no tcnicas. Los requerimientos del producto son la expresin de estos requerimientos en trminos tcnicos que pueden ser usados para decisiones de diseo. Requerimientos del producto y de componentes del producto abordan la satisfaccin del cliente, los negocios, los objetivos del proyecto y los atributos asociados, tales como eficacia y economa. Tambin abordan el costo y rendimiento de otras fases del ciclo de vida. La modificacin de requerimientos debido a la aprobacin de cambios en estos es cubierta por funciones de mantenimiento de esta rea de proceso; mientras que la administracin de cambios de requerimientos es cubierta por el rea de proceso de Administracin de Requerimientos. 30. SP 2: Destinar requerimientos de componentes del producto Prctica: "Destinar los requerimientos por cada componente del producto". Los requerimientos de componentes del producto incluyen el destino de stos al comportamiento del producto final, el diseo de restricciones y el ajuste, formacin y creacin de funciones para satisfacer los requerimientos y facilitar la produccin. En los casos donde los requerimientos de alto nivel especifiquen comportamiento que ser responsabilidad de dos o ms componentes del producto, este comportamiento debe ser dividido para ser asociado a cada componente de producto como requerimiento derivado. 31. SP 3: Identificar requerimientos de interfaz Prctica: "Identificar requerimientos de interfaz".

Interfaces entre funciones (o entre objetos) son identificadas. Interfaces funcionales pueden impulsar el desarrollo de soluciones alternativas. Los requerimientos de interfaces entre productos o entre componentes del producto identificados en la arquitectura del producto son definidos. Estos son controlados como parte de la integracin del producto y componentes del producto y son parte integral de la definicin de la arquitectura. SG 3: Analizar y validar requerimientos Objetivo: "Los requerimientos son analizados y validados, y una definicin de la funcionalidad requerida es desarrollada". Las prcticas especficas de este objetivo especfico apoyan el desarrollo de los requerimientos en los objetivos especficos 1 y 2. Las prcticas especficas asociadas con este objetivo cubren el anlisis y validacin de requerimientos con respecto al ambiente previsto por el usuario. Los anlisis son desarrollados para determinar que impacto tendr el ambiente operacional previsto en la habilidad para satisfacer las necesidades de las partes interesadas, sus expectativas, restricciones e interfaces. Aspectos como viabilidad, necesidades de misin corporativa, restricciones de costos, tamao de potencial de mercado y estrategia de adquisicin deben ser tomados en consideracin dependiendo del contexto del producto. Los objetivos de los anlisis son determinar requerimientos candidatos para conceptos de productos que van a satisfacer las necesidades, expectativas y restricciones de las partes interesadas y luego traducir estos conceptos a requerimientos. En paralelo con esta actividad, los parmetros que sern usados para evaluar la eficacia del producto son determinados basados en la informacin del cliente y el concepto preliminar del producto. Los requerimientos son validados para aumentar la probabilidad de que el producto resultante funcionar como se espera en el ambiente de produccin. 32. SP 1: Establecer conceptos operacionales y escenarios Prctica: "Establecer y mantener conceptos operacionales y escenarios asociados". Un escenario es tpicamente una secuencia de eventos que pueden ocurrir en la utilizacin del producto, el cual es usado para hacer explicitas algunas de las necesidades de las partes interesadas. En contraste, un concepto operacional para un producto usualmente depende de la solucin de diseo y del escenario. Ya que las soluciones alternativas no son usualmente definidas cuando se definen los conceptos operacionales iniciales, las soluciones conceptuales son desarrolladas para usarse cuando se analizan los requerimientos. Los conceptos operacionales son refinados a medida que las decisiones sobre la solucin son tomadas y requerimientos de ms bajo nivel detallados son desarrollados. As como una decisin de diseo para un producto puede convertirse en un requerimiento para componentes del producto, el concepto operacional puede convertirse en escenarios (requerimientos) para componentes del producto. Los conceptos operacionales y escenarios son desarrollados para facilitar la seleccin de soluciones para componentes del producto que podrn,

cuando se implementen, satisfacer el uso esperado del producto. Los conceptos operacionales y escenarios documentan la interaccin de los componentes del producto con el ambiente, los usuarios y otros componentes del producto independiente de la disciplina de ingeniera. Los escenarios pueden incluir secuencias operacionales, si stas son una expresin de los requerimientos del cliente ms que conceptos operacionales. 33. SP 2: Establecer una definicin de la funcionalidad requerida Prctica: "Establecer y mantener una definicin de la funcionalidad requerida". La definicin de funcionalidad, tambin referida como "anlisis funcional", es la descripcin de lo que se pretende que el producto haga. La definicin de funcionalidad puede incluir acciones, secuencias, entradas, salidas u otra informacin que d a conocer la manera en la cual el producto va a ser usado. El anlisis funcional no es lo mismo que el anlisis estructurado en Desarrollo de Software y no supone un diseo de software orientado a la funcionalidad. En el diseo de software orientado al objeto, se relaciona con definir los denominados "servicios" o "mtodos". La definicin de funciones, sus agrupaciones lgicas y sus asociaciones con requerimientos es referido como arquitectura funcional. 34. SP 3: Analizar requerimientos Prctica: "Analizar requerimientos para asegurar que ellos son necesarios y suficientes". A la luz del concepto operacional y los escenarios, los requerimientos para un nivel de la jerarqua del producto son analizados para determinar si ellos son necesarios y suficientes para alcanzar los objetivos de niveles ms altos de la jerarqua del producto. Los requerimientos analizados proveen la base para requerimientos ms detallados y precisos en niveles inferiores de la jerarqua de productos. Mientras los requerimientos son definidos, sus relaciones con requerimientos y la funcionalidad definida de ms alto nivel deben ser entendidas. Otra de las acciones es la determinacin de cules requerimientos claves sern usados para medir el avance. Por ejemplo, el peso de un producto o el tamao de un software pueden ser monitoreados durante su desarrollo basndose en sus riesgos. 35. SP 4: Analizar requerimientos para lograr balance Prctica: "Analizar requerimientos para balacear necesidades y restricciones de los Stakeholders". Necesidades y restricciones pueden abordar costos, cronogramas, funcionalidades, componentes reutilizables, mantenimiento o riesgos. 36. SP 5: Validar requerimientos Prctica: "Los requerimientos se validan para asegurar que el producto resultante operar como est previsto en el ambiente del usuario"

La validacin de requerimientos es realizada tempranamente con los usuarios para obtener certeza de que los requerimientos permitirn guiar el desarrollo que resulte en una validacin final exitosa. Las organizaciones maduras tpicamente realizarn validacin de requerimientos de una manera ms sofisticada aplicando diversas tcnicas y ampliarn la base de la validacin para incluir necesidades y expectativas de otras partes interesadas. Solucin Tcnica El PA de Solucin Tcnica (TS) tiene como propsito disear, desarrollar e implementar soluciones a requerimientos. Es aplicable a cualquier nivel de la arquitectura del producto y a cada producto, componente de producto y proceso relacionado con el ciclo de vida del producto. Estos procesos relacionados con el ciclo de vida del producto son desarrollados conjuntamente con el producto y los componentes del producto. Dicho desarrollo puede incluir la seleccin o adaptacin de procesos existentes (procesos estndares) o el desarrollo de nuevos procesos. SG 1: Seleccionar soluciones para componentes del producto Objetivo: "Soluciones de producto o de componentes del producto son seleccionadas a partir de alternativas de solucin". Las soluciones alternativas y sus ventajas relativas son consideradas antes de seleccionar una solucin. Los requerimientos claves, los temas de diseo y las restricciones son establecidos para ser utilizados en el anlisis de soluciones alternativas. Las caractersticas de la arquitectura que proveen una base para la mejora y evolucin del producto son consideradas. El uso de componentes de producto tipo COTS (Commercial Off TheShelf) es considerado en relacin con costos, cronograma, rendimiento y riesgos. Las alternativas tipo COTS pueden ser utilizadas con o sin adaptaciones. En ocasiones, dichos elementos requieren modificaciones en aspectos tales como interfaces o personalizacin de alguna de sus caractersticas para cumplir en mejor forma con los requerimientos del producto. Un indicador de buen proceso de diseo es que el diseo fue escogido despus de compararlo y evaluarlo con soluciones alternativas. Las decisiones de arquitectura deben ser tomadas. Algunas de estas decisiones pueden requerir un proceso formal de toma de decisiones. En general las soluciones son definidas como un conjunto. Esto significa que al definir la siguiente capa de componentes, la solucin para cada uno de los componentes del conjunto es definida. Las soluciones alternativas no son slo formas distintas de abordar los mismos requerimientos, sino tambin reflejan un destino diferente de requerimientos entre los componentes del producto que componen el conjunto solucin. El objetivo es optimizar el conjunto de requerimientos como un todo y no sus partes. 37. SP 1: Desarrollar soluciones alternativas y criterios de seleccin Prctica: "Desarrollar alternativas de solucin y criterios de seleccin". Las alternativas de solucin deben ser identificadas y analizadas para poder seleccionar una solucin equilibrada a travs del ciclo de vida del producto en trminos de costos, cronograma y

rendimiento. Estas soluciones se basan en arquitecturas de producto propuestas que abordan caractersticas crticas del producto y abarcan un conjunto de soluciones factibles. Las alternativas de soluciones frecuentemente comprenden asociaciones alternativas de requerimientos a diferentes componentes del producto. Dichas alternativas pueden incluir el uso de soluciones COTS en la arquitectura del producto. Las alternativas de soluciones cubren el rango aceptable de costo, cronograma y rendimiento. Los requerimientos de componentes del producto son recibidos y utilizados junto con problemas de diseo, restricciones, y criterios para desarrollar soluciones alternativas. Los criterios de seleccin abordarn tpicamente costos (tiempo, recursos humanos y otros gastos) y riesgos (tcnicos, de costo y cronograma). Las consideraciones para alternativas de soluciones y criterios de seleccin incluyen lo siguiente: Costo de desarrollo, construccin, adquisicin, mantenimiento, soporte, etc. Rendimiento. Complejidad de componentes del producto y de procesos relacionados con su ciclo de vida.

Robustez del producto en operacin y condiciones de uso, modos de operacin, ambientes y variaciones de los procesos relacionados con el ciclo de vida del producto. Expansin y crecimiento del producto. Limitantes de la tecnologa. Sensibilidad a los mtodos y materiales de construccin. Riesgos. Evolucin de requerimientos y tecnologa. Dada de baja (eliminacin) del producto. Capacidades y limitantes de usuarios finales y operadores. Caractersticas de productos tipo COTS.

La anterior es una lista bsica de consideraciones. Las organizaciones debieran hacer proyecciones para acortar la lista de alternativas que sean consistentes con sus objetivos de negocio. Los costos de ciclo de vida del producto pueden estar fuera del control de las organizaciones de desarrollo aunque sea un parmetro atractivo para minimizar costos. Un cliente puede no estar dispuesto a pagar por funciones que cuestan ms en el corto plazo pero que en ltima instancia disminuyen el costo durante la vida til del producto. En tales casos, los clientes debieran al menos estar informados de las posibilidades de reducir los costos durante la vida til de un producto. Los criterios utilizados para seleccionar las soluciones finales debieran proveer un enfoque equilibrado de costos, beneficios y riesgos.

38. SP 2: Seleccionar soluciones para componentes del producto Prctica: "Seleccionar las componentes del producto que mejor satisfacen los criterios establecidos". Seleccionar soluciones para componentes del producto que mejor satisfagan los criterios establecidos. Requerimientos de ms bajo nivel son generados a partir de la alternativa seleccionada y utilizados para desarrollar el diseo de los componentes de producto. Los requerimientos de interfaz entre componentes de producto son funcionalmente descritos al inicio. Las descripciones de interfaz fsica son incluidas en la documentacin de interfaces hacia elementos y actividades externas al producto.

La descripcin de soluciones y los fundamentos de la seleccin son documentadas. La documentacin evoluciona a medida que las soluciones y los diseos son detallados, desarrollados e implementados. El mantenimiento de un registro de fundamentos es crtico para la toma de decisiones. SG 2: Desarrollar el diseo Objetivo: "Diseos del producto y componentes del producto son desarrolladas" Diseos de productos o componentes de productos deben proveer el contenido apropiado no slo para la implementacin, sino tambin para otras fases del ciclo de vida del producto tales como modificacin, adquisicin, mantenimiento e instalacin. La documentacin de diseo provee una referencia para apoyar el entendimiento mutuo del diseo por parte de las partes interesadas y as apoyar futuros cambios al diseo ya sea durante el desarrollo como en las fases siguientes del ciclo de vida del producto. Una descripcin completa del diseo es documentada incluyendo una completa gama de caractersticas y parmetros incluyendo forma, ajuste, funcin, interfaz, caractersticas del proceso de construccin y otros parmetros. Estndares establecidos de diseo de proyecto u organizacionales (listas, plantillas, estructura de objetos) forman la base para alcanzar un alto grado de definicin y completitud en la documentacin del diseo. 39. SP 1: Disear el producto o los componentes del producto Prctica: "Desarrollar un diseo para el producto o componente del producto". El diseo del producto consiste en dos extensas fases que pueden superponerse en ejecucin: diseo preliminar y diseo detallado. El diseo preliminar establece las capacidades y la arquitectura del producto, incluyendo divisiones del producto, identificacin de los componentes del producto, estados de sistemas y modos, interfaces principales e interfaces externas del producto. El diseo detallado define completamente la estructura y las capacidades de los componentes del producto. La definicin de la arquitectura es guiada a partir de un conjunto de requerimientos de arquitectura. Estos requerimientos expresan los elementos de calidad y rendimiento que son crticos para el xito del producto. La arquitectura define los elementos estructurales y los

mecanismos de coordinacin que directamente satisfacen los requerimientos o apoyan su realizacin a medida que se establecen los detalles del diseo del producto. Las arquitecturas pueden incluir estndares y reglas de diseo que dirigen el desarrollo de los componentes del producto y sus interfaces, as como una gua para ayudar a sus desarrolladores. Los arquitectos postulan y desarrollan un modelo del producto, haciendo juicios sobre la asociacin de requerimientos con los componentes del producto, incluyendo hardware y software. Mltiples arquitecturas que apoyan las soluciones alternativas pueden ser desarrolladas y analizadas para determinar las ventajas y desventajas en el contexto de los requerimientos de arquitectura. Los conceptos operacionales y escenarios son usados para generar casos de uso y escenarios de calidad que se usan para refinar la arquitectura. Tambin son usados como un medio para evaluar qu tan apropiada es la arquitectura para el propsito previsto durante las evaluaciones, las cuales son realizadas peridicamente durante todo el diseo del producto. Durante el diseo detallado, los detalles de la arquitectura del producto son finalizados, los componentes del producto son definidos completamente y las interfaces son descritas en su totalidad. Los diseos de los componentes de productos pueden ser optimizados para ciertas caractersticas de rendimiento o calidad. A medida que el diseo madura, los requerimientos asignados a componentes de productos de ms bajo nivel son monitoreados para asegurar que esos requerimientos son satisfechos. 40. SP 2: Establecer un paquete de datos tcnicos Prctica: "Establecer y mantener un paquete de datos tcnicos". Un paquete de datos tcnicos provee al desarrollador una descripcin exhaustiva del producto o de sus componentes a medida que es desarrollado. Dicho paquete tambin provee flexibilidad de adquisiciones en diversas circunstancias, tales como "PerformanceBasedContracting" (PBC) o "BuildToPrint". El diseo es registrado en un paquete de datos tcnicos creado durante el diseo preliminar para documentar la definicin de la arquitectura. Este paquete de datos tcnicos es mantenido durante toda la vida del producto para registrar detalles esenciales del diseo del producto. El paquete de datos tcnicos provee la descripcin del producto y sus componentes que apoyan la estrategia de adquisicin, o la implementacin, produccin, ingeniera y fases de soporte logstico del ciclo de vida del producto. La descripcin incluye la definicin de la configuracin requerida del diseo y procedimientos para asegurar el comportamiento adecuado del producto o de sus componentes. Esto incluye todos los datos tcnicos aplicables como dibujos, listas asociadas, especificaciones, descripciones de diseo, bases de datos de diseo, estndares, requerimientos de rendimiento, provisiones de aseguramiento de calidad y detalles de empaquetamiento. El paquete de datos tcnicos incluye una descripcin de la solucin alternativa seleccionada a ser implementada. Un paquete de datos tcnicos debera incluir lo siguiente, si dicha informacin es apropiada para el tipo de producto y componentes del producto: Descripcin de arquitectura de producto.

Requerimientos asignados. Descripcin de componentes del producto.

Descripcin de los procesos relacionados con el ciclo de vida del producto, si no es descrito como componentes de productos separados. Caractersticas de productos claves. Caractersticas fsicas requeridas y restricciones. Requerimientos de interfaz. Requerimientos de materiales. Fabricacin y requerimientos de manufactura. Criterios de verificacin usados para asegurar que los requerimientos han sido satisfechos.

Condiciones de uso (ambientes) y escenarios de uso / operacin, modos y estados de operacin, soporte, capacitacin, manufactura, eliminacin del producto y verificaciones a los largo de la vida til del producto. Fundamentos de decisiones y caractersticas (requerimientos, asignacin de requerimientos y opciones de diseo). Debido a que las descripciones de diseo pueden contener una gran cantidad de informacin y pueden ser cruciales para el desarrollo exitoso de los componentes del producto, es aconsejable establecer criterios para organizar y seleccionar la informacin. Es particularmente til utilizar la arquitectura del producto como una manera de organizar la informacin y elaborar vistas claras y relevantes para un tema o caracterstica de inters. Estas vistas incluyen lo siguiente: Clientes. Requerimientos. El ambiente. Funcionalidad. Lgica. Seguridad. Datos.

Estados / modos. Construccin. Administracin Estas vistas son documentadas en el paquete de datos tcnicos.

41. SP 3: Disear interfaces utilizando criterios Prctica: "Disear interfaces de componentes del producto utilizando los criterios establecidos". Estos diseos de interfaces incluyen lo siguiente: Orgenes. Destino. Estmulos y caractersticas de datos para el software Caractersticas elctricas, mecnicas y funcionales para hardware Lneas de comunicacin.

El criterio para interfaces frecuentemente refleja parmetros crticos que deben ser definidos, o al menos investigados, para asegurar su aplicabilidad. Estos parmetros son a menudo caractersticos de un cierto tipo de producto (software, mecnico, elctrico, de servicio) y son a menudo asociados con seguridad, durabilidad y caractersticas de la misin crtica. 42. SP 4: Ejecutar Anlisis de: Hacer, Comprar o Reutilizar Prctica: "Evaluar si los componentes del producto debieran ser desarrollados, comprados o reutilizados basndose en los criterios establecidos". La determinacin acerca de qu producto o componentes del producto sern adquiridos es frecuentemente referido como "make-or-buyanalysis" (anlisis de hacer-o-comprar). Este anlisis esta basado en las necesidades del proyecto; comienza tempranamente durante la primera iteracin de diseo, contina durante el proceso de diseo y concluye con la decisin de desarrollar, adquirir o reutilizar el producto. Factores que afectan la decisin de hacer-o-comprar incluyen los siguientes: Funciones que los productos o servicios proveern y cmo estas funciones se ajustan al proyecto. Recursos y habilidades disponibles del proyecto. Costos de adquisicin versus costos de desarrollo interno.

Entregas crticas y fechas de integracin. Alianzas estratgicas de negocios, incluyendo requerimientos de negocio de alto nivel. Investigacin de mercado de productos disponibles, incluyendo productos tipo COTS. Funcionalidad y calidad de productos disponibles. Habilidades y capacidades de potenciales proveedores. Impacto en las competencias esenciales.

Licencias, garantas, responsabilidades y limitantes asociadas a productos que estn siendo adquiridos. Disponibilidad de productos Calidad propietaria de productos y componentes. Reduccin de riesgos.

La decisin de hacer-o-comprar puede efectuarse aplicando un proceso formal de toma de decisiones. A medida que la tecnologa evoluciona, tambin lo hacen las razones para elegir el desarrollo o compra de componentes de producto. Mientras el esfuerzo de desarrollo complejo puede favorecer la compra de un componente tipo COTS, los avances en la productividad y herramientas pueden presentar razones en sentido contrario. Productos tipo COTS pueden tener documentacin incompleta o incorrecta y pueden no contar con soporte en el futuro. SG 3: Implementar el Diseo del Producto Objetivo: "Componentes del producto, y su documentacin de apoyo asociada, son implementadas segn sus diseos". Los componentes del producto son implementados a partir de los diseos establecidos por las prcticas especficas de la prctica especfica Desarrollar el Diseo. La implementacin usualmente incluye pruebas unitarias de los componentes del producto antes de la integracin de producto y el desarrollo de documentacin de usuarios finales. 43. SP 1: Implementar el Diseo Prctica: "Implementar los diseos de las componentes del producto". Una vez que el diseo se ha completado, ste es implementado como un componente del producto. Las caractersticas de esa implementacin dependen del tipo de componente. La implementacin del diseo en el primer nivel de la jerarqua del producto implica la especificacin de cada uno de los componentes del producto en el siguiente nivel de la jerarqua.

Esta actividad incluye la asignacin, refinamiento y verificacin de cada componente del producto. Tambin incluye la coordinacin de los trabajos de desarrollo del componente del producto. 44. SP 2: Desarrollar la documentacin de apoyo del producto Prctica: "Desarrollar y mantener la documentacin de utilizacin final". Esta prctica especfica desarrolla y mantiene la documentacin que ser usada para instalar, operar y mantener el producto. Integracin de Productos El propsito de PI es ensamblar las componentes del producto para obtener el producto, asegurar que el producto segn la integracin que se hizo funciona correctamente, y liberar el producto al cliente. PI involucra tanto: Integracin del producto: Integracin para el producto final. Integracin de las componentes del producto: Integracin de componentes para producir componentes ms complejas. El mbito de PI es alcanzar la integracin del producto completo a travs del ensamble de progresivas componentes, en uno o ms pasos, de acuerdo a la secuencia de integracin definida y los procedimientos. Se usa el trmino Integracin de Productos para tambin referirse a la Integracin de Servicios. SG 1: Preparacin para la Integracin del producto Objetivo: "Preparacin para la integracin del producto es conducida" Preparar la integracin de los componentes del producto incluye establecer y mantener: Una secuencia de integracin del producto y de las componentes del producto. El ambiente para realizar la integracin del producto y de las componentes del producto. Procedimientos y criterios para la integracin del producto y de las componentes del producto. La preparacin para la integracin comienza al inicio del proyecto y la secuencia de integracin es desarrollada al mismo tiempo con las prcticas del rea de proceso de Solucin Tcnica. 45. SP 1: Determinar la Secuencia de Integracin Prctica: "Determinar la secuencia de integracin de componentes del producto"

Las componentes del producto son analizadas para su integracin. Se define un conjunto de secuencias posibles para integrar las componentes y se elige la mejor secuencia posible. 46. SP 2: Establecer el Ambiente de Integracin del Producto Prctica: "Establecer y mantener el ambiente necesario para apoyar la integracin de las componentes del producto". El ambiente para la integracin de producto puede ser adquirido o desarrollado. Para establecer un ambiente, requerimientos para la compra o desarrollo de equipamientos, software u otros recursos necesitarn ser desarrollados. El ambiente requerido en cada paso del proceso de integracin de producto puede incluir equipos para realizar pruebas, simuladores (tomando el lugar de componentes de productos no disponibles), piezas de equipos reales y dispositivos de almacenamiento. 47. SP 3: Establecer Procedimientos y Criterios de Integracin del Producto Prctica: "Establecer y mantener procedimientos y criterios para la Integracin de las componentes del producto". Los procedimientos para la integracin de las componentes del producto pueden incluir cosas como el nmero de iteraciones incrementales que se realizan y detalles de las evaluaciones que sern llevadas a cabo en cada etapa. Los criterios pueden indicar si la componente del producto esta o no preparada para su integracin o su grado de aceptacin. Los procedimientos y criterios para la integracin del producto dirigen lo siguiente: Nivel de prueba para construir componentes, Verificacin de interfaces, Umbrales de desviacin de ejecucin, Requerimientos derivados para el ensamble y sus interfaces externas, Sustituciones permitidas de componentes, Parmetros del ambiente de prueba, Limites en los costos de prueba, Equilibrio calidad/costos para operaciones de integracin, Probabilidad del funcionamiento apropiado, Tasas de entrega y sus variaciones, Tiempo de entrega desde el pedido hasta la entrega, Disponibilidad de personal y Disponibilidad de la facilidad/lnea/ambiente de integracin. Los criterios pueden ser definidos por cmo las componentes del producto estn para ser verificados y las funciones que se espera que ellas tengan. Los criterios pueden ser definidos por cmo las componentes ensambladas del producto y el producto integrado final son validados y liberados. Los criterios tambin pueden restringir el grado de simulacin permitidos para que las componentes puedan pasar una prueba, o pueden restringir el ambiente para ser usado en el test de integracin. SG 2: Asegurar la compatibilidad de interfaces Objetivo: "Las interfaces de las componentes del producto, internas y externas, son compatibles".

Muchos problemas de integracin de productos surgen por aspectos no conocidos o no controlados de interfaces internas y externas a cada componente. La administracin efectiva de requerimientos de interfaces de componentes de productos, especificaciones y diseos, ayudan a asegurar que las interfaces implementadas sern compatibles y completas. 48. SP 1: Revisar Descripcin de Interfaces para Completitud Prctica: "Revisar descripciones de interfaces para su cobertura y completitud". Las interfaces deben incluir, adems de las interfaces de los componentes del producto, todas las interfaces con el ambiente de integracin del producto. 49. SP 2: Gestionar Interfaces Prctica: "Gestionar definiciones de interfaces internas y externas, diseos, y cambios en productos y componentes del producto". Los requerimientos de interfaz manejan el desarrollo de las interfaces necesarias para integrar las componentes del producto. Gestionar interfases del producto y componentes del producto comienza tempranamente en el desarrollo del producto. Las definiciones y el diseo para interfaces afecta, no solamente a los componentes de producto y sistemas externos, sino que tambin puede afectar la validacin y verificacin de ambientes. La gestin de interfaces incluye la mantencin de la consistencia de las interfaces durante todo el ciclo de vida del producto, y resolucin de conflictos, disconformidades, y cambios en temas. La gestin de interfaces entre productos adquiridos desde proveedores y otros productos o componentes de productos son crticas para el xito del proyecto. Las interfaces deben incluir, adems de las interfaces de las componentes del producto, todas las interfaces con el ambiente, as como con otros como ambientes para verificacin, validacin, operaciones y soporte. Los cambios en la interfase son documentados, mantenidos y fcilmente accesibles. SG 3: Ensamblar las componentes del producto y liberar el producto Objetivo: "Componentes del producto verificadas son ensambladas y el producto integrado, verificado y validado es entregado". La integracin de las componentes del producto se hace de acuerdo a la secuencia de integracin del producto y los procedimientos disponibles. Antes de la integracin, cada componente del producto es verificada de acuerdo a los requerimientos de interfaz establecidos. Las componentes del producto son ensambladas en componentes ms complejas y grandes. Estas componentes ensambladas son chequeadas para su correcta interoperacin. Este proceso contina hasta que la integracin del producto es completada. Si durante este proceso se identifican problemas estos deben ser documentados y un proceso de acciones correctivas es iniciado. 50. SP 1: Confirmar Componentes para Integracin preparados

Prctica: "Confirmar, previo al ensamble, que cada componente del producto requerido para ensamblar el producto ha sido debidamente identificado, funciones corresponden a su descripcin y las interfaces de las componentes del producto cumplen con las descripciones de las interfaces". El propsito de esta prctica especfica es asegurar que las componentes del producto adecuadamente identificadas que cumplen con su descripcin puedan ser realmente ensambladas de acuerdo a la secuencia de integracin del producto y procedimientos disponibles. Tambin la consistencia entre las componentes de producto y descripciones de interfase son chequeadas. Quienes conducen la integracin del producto son los responsables en ltima instancia de chequear para asegurarse que todo est correcto y as continuar con el ensamble. 51. SP 2: Ensamblar las componentes del producto Prctica: "Ensamblar las componentes del producto de acuerdo a la secuencia de integracin y procedimientos disponibles". Las actividades de ensamblaje de esta prctica especfica y las actividades de evaluacin de la prxima son conducidas en forma iterativa, desde los componentes iniciales del producto, a travs de los componentes ensamblados provisorios, hasta el producto como un todo. 52. SP 3: Evaluar Componentes del Producto ensambladas Prctica: "Evaluar componentes de producto ensamblados para la compatibilidad de interfase". Esta evaluacin involucra examinar y probar las componentes del producto ensambladas para su realizacin, conveniencia o preparacin usando los procedimientos y ambiente disponibles. Esto es realizado para los diferentes pasos del ensamble segn lo dispuesto por la secuencia de integracin y procedimientos disponibles. La secuencia de integracin del producto y procedimientos disponibles, el nmero de componentes, y la complejidad del producto podran definir una secuencia de integracin y evaluacin ms refinada. 53. SP 4: Empaquetar y Entregar Productos o Componentes del Producto Prctica: "Empaquetar el producto ensamblado o componente del producto y entregarlo al cliente apropiado". Los requerimientos de empaque para algunos productos pueden ser dirigidos segn sus especificaciones y criterios de verificacin. Esto es especialmente importante cuando los tems son registrados y transportados por los clientes. En tales casos, pudiese haber condiciones de estrs y ambiente especificadas para el paquete. En otras circunstancias economa y requerimientos de transporte, responsabilidad, y facilidad y seguridad del desempaque son factores importantes. Verificacin

El propsito de Verificacin (VER) es asegurar que los artefactos cumplen con los requerimientos especificados. VER involucra la verificacin del producto o servicios y artefactos intermedios con respecto a los requerimientos seleccionados, incluyendo requerimientos del cliente, del producto o servicio y componentes del producto o servicio. VER es un proceso incremental porque se aplica al desarrollo del producto y artefactos, comenzando con la verificacin de los requerimientos, pasando por la verificacin de artefactos y terminando con la verificacin del producto completo. VER y VAL son similares pero tienen diferencias. VAL demuestra que el producto que se entregar satisface su uso entendido, mientras que VER se enfoca en que los artefactos reflejen los requerimientos especificados. En otras palabras, VER asegura que algo se construye correctamente, mientras que VAL asegura que se construye algo correcto. SG 1: Preparar la verificacin Objetivo: "La preparacin de la verificacin es conducida". Una preparacin es necesaria para asegurar que los requerimientos de verificacin estn incluidos en los requerimientos del producto y las componentes del producto, diseos, planes de desarrollo y programas. La verificacin incluye seleccin, inspeccin, prueba, anlisis y demostracin de artefactos. Los mtodos de verificacin incluyen, pero no estn limitados a ellos, inspecciones, revisiones de pares, auditorias, inspecciones, anlisis, simulaciones, pruebas y demostraciones. La preparacin tambin supone la definicin de herramientas de apoyo, equipamientos para pruebas y software, simulaciones, prototipos y facilidades. 54. SP 1: Seleccionar artefactos para Verificacin Prctica: "Seleccionar artefactos a ser verificados y mtodos de verificacin que sern usados para cada uno de ellos". Los artefactos son seleccionados basndose en su contribucin para alcanzar los objetivos y requerimientos del proyecto, y para dirigir los riesgos del proyecto. Los artefactos que sern verificados pueden incluir aquellos asociados con la mantencin, entrenamiento y servicios de apoyo. Los mtodos de verificacin dirigen el enfoque tcnico de la verificacin de artefactos y los procedimientos especficos que sern usados para verificar que los productos de trabajo especficos cumplan sus requerimientos. La seleccin de los mtodos de verificacin comienza tpicamente con la participacin en la definicin de los requerimientos del producto o componentes del producto para asegurar que estos requerimientos son verificables. 55. SP 2: Establecer el ambiente de Verificacin

Prctica: "Establecer y mantener el ambiente necesario para apoyar la verificacin". Un ambiente debe ser establecido para permitir que la verificacin tome lugar. El ambiente de verificacin puede ser adquirido, desarrollado, reutilizado, modificado, o una combinacin de estos, dependiendo de las necesidades del proyecto. Cada ambiente requerido va a depender de los artefactos seleccionados para su verificacin y los mtodos de verificacin usados. 56. SP 3: Establecer procedimientos y criterios de verificacin Prctica: "Establecer y mantener procedimientos y criterios de verificacin para los artefactos seleccionados" Los criterios de verificacin son definidos para asegurar que los artefactos cumplan con sus requerimientos. SG 2: Realizar Revisin de Pares Objetivo: "Revisiones de pares son desarrolladas sobre artefactos seleccionados". La revisin de pares es un anlisis metodolgico de artefactos realizado por los productores o desarrolladores pares para identificar defectos a ser removidos y recomendar otros cambios segn sean necesarios. La revisin de pares es un mtodo de ingeniera importante y efectivo implementado va inspecciones u otros mtodos de revisin. 57. SP 1: Preparar la revisin de pares Prctica: "Preparar para la revisin de pares de artefactos seleccionados". Actividades de preparacin para la revisin de pares tpicamente incluyen identificar el personal que ser invitado a participar en la revisin de pares de cada artefacto; identificar los revisores claves que deben participar en la revisin de pares; preparar y actualizar cualquier material que ser usado durante la revisin de pares. 58. SP 2: Conducir la revisin de pares Prctica: "Conducir la revisin de pares sobre artefactos seleccionados e identificar defectos resultantes de la revisin de pares". Uno de los propsitos de conducir la revisin de pares es encontrar y remover tempranamente defectos. La revisin de pares es realizada incrementalmente tal como los artefactos estn siendo desarrollados. Estas revisiones son estructuradas y no son revisiones administrativas.

La revisin de pares puede ser realizada en cualquier tipo de artefacto. Cuando surgen defectos de la revisin de pares, estos deben ser comunicados al desarrollador principal del artefacto para su correccin. La revisin de pares debe dirigir lo siguiente: Debe haber la preparacin suficiente, la conduccin debe ser administrada y controlada, datos consistentes y suficientes deben ser registrados, y puntos de accin deben ser registrados. 59. SP 3: Analizar los datos de la revisin de pares Prctica: "Analizar datos acerca de la preparacin, conduccin y resultados de la revisin de pares". Analizar datos acerca de la preparacin, conduccin y resultados de la revisin de pares. SG 3: Verificar Artefactos Seleccionados Objetivo: "Los artefactos son verificados contra sus requerimientos especficos". Los mtodos, procedimientos y criterios de evaluacin son usados para verificar que el artefacto seleccionado y cualquier mantencin asociada, entrenamiento y servicios de soporte usan el ambiente de verificacin apropiado. Actividades de verificacin deben ser realizadas durante todo el ciclo de vida del producto. 60. SP 1: Realizar la verificacin Prctica: "Realizar verificacin de los artefactos seleccionados". Verificar incrementalmente productos y artefactos promueve la deteccin temprana de problemas y puede resultar en la remocin temprana de defectos. Los resultados de la verificacin ahorran costos considerables de fallas aisladas y trabajo repetido asociado a la resolucin de problemas. 61. SP 2: Analizar resultados de verificacin identificando acciones correctivas Prctica: "Analizar los resultados de todas las actividades de verificacin". Los resultados actuales deben ser comparados con los criterios de verificacin establecidos para determinar la aceptabilidad. Los resultados del anlisis son registrados como evidencia de que la verificacin fue realizada. Para cada artefacto, todos los resultados de verificacin son analizados incrementalmente para asegurar que los requerimientos hayan sido cumplidos. Dado que la revisin de pares es uno de varios mtodos de verificacin, los datos de revisin de pares deben ser incluidos en esta actividad de anlisis para asegurar que los resultados de la verificacin son suficientemente analizados.

Validacin El propsito de Validacin (VAL) es demostrar que un producto o componentes del producto cumplen su uso planeado cuando es ubicado en su planeado ambiente. Actividades de validacin pueden ser aplicadas a todos los aspectos del producto en cualquiera de sus ambientes planeados, tal como operacin, entrenamiento, manufactura, mantencin, y servicios de soporte, Los mtodos empleados para conseguir la validacin pueden ser aplicados a artefactos as como tambin a productos o servicios y componentes del producto o servicios. SG 1: Preparar la validacin Objetivo: "La preparacin para la validacin es conducida". Actividades de preparacin incluyen la seleccin de productos y los componentes del producto para validacin, y establecer y mantener el ambiente, procedimientos y criterios de validacin. Los artefactos seleccionados para validacin pueden incluir slo el producto o puede incluir niveles apropiados de las componentes del producto que son usados para construir el producto. El ambiente de Integracin de Productos, Verificacin y Validacin puede ser el mismo. 62. SP 1: Seleccionar Productos para la validacin Prctica: "Seleccionar productos y componentes de productos a ser validados y los mtodos de validacin que sern usados para cada uno". Productos y componentes de productos son seleccionados para validacin sobre la base de sus relaciones con las necesidades del usuario. Para cada componente de producto, el alcance de la validacin (comportamiento operacional, mantencin, entrenamiento e interfase de usuario) debera ser determinado. Los requerimientos y restricciones para realizar la validacin son recopilados. Entonces, los mtodos de validacin son seleccionados basndose en su capacidad para demostrar que las necesidades de los usuarios estn satisfechas. Los mtodos de validacin no slo definen el enfoque tcnico de la validacin del producto, sino tambin dirige las necesidades para los equipos a utilizar y ambientes de validacin. Requerimientos derivados, como requerimientos de interfaces para hacer pruebas y equipamientos, pueden ser generados. Los mtodos de validacin deben ser seleccionados tempranamente en la vida del proyecto para que sean claramente entendidos y acordados con las partes interesadas. Los mtodos de validacin dirigen el desarrollo, mantencin, soporte y entrenamiento para el producto o las componentes del producto segn sea apropiado. 63. SP 2: Establecer el ambiente para la validacin Prctica: "Establecer y mantener el ambiente necesario para apoyar la validacin".

Los requerimientos para el ambiente de validacin son manejados por el producto o las componentes de productos seleccionadas, por el tipo de artefacto (por ejemplo, diseo, prototipo, versin final) y por los mtodos de validacin. Esto podra producir requerimientos para la compra o desarrollo de equipamiento, software u otros recursos. El entorno de validacin puede incluir la reutilizacin de recursos existentes. En este caso, se deben hacer arreglos para el uso de estos recursos. Ejemplos de tipos de elementos en un ambiente de validacin incluyen lo siguiente: Herramientas de prueba interconectadas con el producto que esta siendo validado. Software para prueba. Subsistemas simulados o componentes. Sistemas simulados. Sistemas reales. Facilidades y productos provistos por el cliente. Las personas hbiles para operar o usar todos los elementos precedentes. Ambiente de prueba con computador dedicado o sistema distribuido.

64. SP 3: Establecer Procedimientos y Criterios de Validacin Prctica: "Establecer y mantener procedimientos y criterios de validacin" Procedimientos y criterios de validacin son definidos para asegurar que el producto o las componentes del producto van a satisfacer su uso planificado cuando es ubicado en su ambiente planificado. La aceptacin de casos de pruebas y procedimientos pueden satisfacer la necesidad de procedimientos de validacin. Los procedimientos y criterios de validacin incluyen pruebas y evaluaciones de mantenimiento, entrenamiento y servicios de soporte. SG 2: Validar Productos o Componentes del Producto Objetivo: "El producto o las componentes del producto son validados para asegurar que son aptas para su uso en su ambiente operacional previsto". Los mtodos, procedimientos y criterios de validacin son usados para validar los productos y las componentes de los productos seleccionados y cualquier mantenimiento, entrenamiento y servicios de apoyo asociado usando el apropiado ambiente de validacin. Actividades de validacin son realizadas durante todo el ciclo de vida del producto. 65. SP 1: Realizar la validacin

Prctica: "Realizar la validacin sobre los productos y las componentes del producto seleccionados". Para que sea aceptable para los usuarios, un producto o componente del producto debe realizarse como es esperado en su ambiente operacional planificado. Las actividades de validacin son realizadas y los datos resultantes son recogidos de acuerdo a los mtodos, procedimientos y criterios establecidos. Los procedimientos de validacin sobre la marcha deben ser documentados y las desviaciones que ocurran durante la ejecucin deben ser atendidas, segn sea apropiado. 66. SP 2: Analizar los resultados de la validacin Prctica:"Analizar los resultados de las actividades de validacin". Los datos resultantes de las pruebas de validacin, inspecciones, demostraciones o evaluaciones son analizadas contra los criterios de validacin definidos. Los informes de anlisis indican si las necesidades fueron satisfechas; en el caso de las deficiencias, estos documentos informan el grado de xito o fracaso y categorizan las probables causas de fracaso. Las pruebas recolectadas, inspecciones o resultados revisados son comparados con los criterios de evaluacin establecidos para determinar si avanzar o enfocarse en los requerimientos que estn bajo cuestin. Analizar informes o documentacin de validacin sobre la marcha tambin puede indicar que los malos resultados de las pruebas son debido a problemas en los procedimientos de validacin o un problema en el ambiente de validacin.

http://www.ingenierosoftware.com/calidad/cmm-cmmi.php http://www.monografias.com/trabajos57/modelo-calidad-cmmi/modelo-calidad-cmmi.shtml