MPS.BR - Mejora de Proceso del Software Brasileño. Guía de Implementación Parte 4: Fundamentos para Implementación del Nivel D del MR-MPS

Transcripción

1 MPS.BR - Mejora de Proceso del Brasileño Guía de Implementación Parte 4: Fundamentos para Implementación del Nivel D del MR-MPS Esta guía contiene orientaciones para la implementación del nivel D del Modelo de Referencia MR-MPS. VIGENCIA Y TRANSICIÓN: La Guía General:2011 entra en vigor el 30 de junio de Así, a partir de esta fecha pueden ser realizadas evaluaciones MPS usando el modelo de referencia MR-MPS:2011. Sin embargo, queda definido un período de transición, de 30 de junio a 31 de diciembre de 2011, durante el cual pueden ser realizadas evaluaciones MPS usando el modelo de referencia MR-MPS:2011 o la versión anterior MR-MPS:2009. A partir del 1º de enero de 2012 solo serán válidas evaluaciones MPS usando el modelo de referencia MR-MPS:2011. Las implementaciones a ser realizadas utilizando esta Guía de Implementación deberán llevar en cuenta estas vigencias. Julio de 2011 Copyright 2011 SOFTEX Derechos de esta edición reservados por la Sociedad SOFTEX La distribución ilimitada de este documento está sujeta a copyright ISBN

2 Índice 1 Prefacio Introducción Objetivo Evolucionando del nivel E al nivel D Desarrollo de Requisitos (DRE) Propósito Fundamentación teórica Resultados esperados Integración del Producto (ITP) Propósito Fundamentación teórica Resultados esperados Diseño y Construcción del Producto (PCP) Propósito Fundamentación teórica Resultados esperados Validación (VAL) Propósito Fundamentación teórica Resultados esperados Verificación (VER) Propósito Fundamentación teórica Resultados esperados Los atributos de proceso del nivel D Referencias bibliográficas Lista de colaboradores de la Guía de Implementación Parte 4: Lista de colaboradores de la Guía de Implementación Parte 4: Lista de colaboradores de la Guía de Implementación Parte 4 versión Julio/ Lista de colaboradores de la Guía de Implementación Parte 4 versión Diciembre/ MPS.BR Guía de Implementación Parte 4:2011 2/68

3 1 Prefacio El MPS.BR 1 es un programa movilizador, de largo plazo, creado en diciembre de 2003, es coordinado por la Asociación para Promoción de la Excelencia del Brasileño (SOFTEX), y cuenta con el apoyo del Ministerio de Ciencia y Tecnología (MCT), de la Financiera de Estudios y Proyectos (FINEP), del Servicio Brasileño de Apoyo a las Micro y Pequeñas Empresas (SEBRAE) y del Banco Interamericano de Desarrollo (BID). El objetivo del programa MPS.BR (acrónimo) es la Mejora de Proceso del, para lograr dos metas a mediano y largo plazo: a) meta técnica, teniendo como objetivo la creación y perfeccionamiento del modelo MPS, con resultados esperados tales como: (i) guías del modelo MPS; (ii) Instituciones Implementadoras (II) acreditadas para prestar servicios de consultoría de implementación del modelo de referencia MR-MPS; (iii) Instituciones Evaluadoras (IA) acreditadas para prestar servicios de evaluación siguiendo el método de evaluación MA-MPS; (iv) Consultores de Adquisición (CA) certificados para prestar servicios de consultoría de adquisición de software y servicios asociados; b) meta de mercado, teniendo como objetivo la propagación y adopción del modelo MPS, en todas las regiones del país, en un intervalo de tiempo justo, a un costo razonable, tanto en PYMEs (foco principal) así como en grandes organizaciones públicas y privadas, con resultados esperados tales como: (i) creación y perfeccionamiento del modelo de negocio MN-MPS; (ii) cursos, pruebas y workshops; (iii) organizaciones que implementaron el modelo MPS; (iv) organizaciones con evaluación MPS publicada (vigencia de tres años). El programa MPS.BR cuenta con dos estructuras de apoyo al desarrollo de sus actividades, el Foro de Acreditación y Control (FCC) y el Equipo Técnico del Modelo (ETM). Por medio de estas estructuras, el MPS.BR obtiene la participación de representantes de universidades, instituciones gubernamentales, centros de investigación y de organizaciones privadas, las cuales contribuyen con sus visiones complementarias que agregan calidad al emprendimiento. Cabe al FCC: (i) emitir parecer para auxiliar las decisiones de la SOFTEX sobre la acreditación de Instituciones Implementadoras (II) e Instituciones Evaluadoras (IA); (ii) supervisar los resultados de las Instituciones Implementadoras (II) e Instituciones Evaluadoras (IA), emitiendo parecer proponiendo a la SOFTEX su desacreditación en caso de comprometimiento de la credibilidad del modelo MPS. Cabe al ETM apoyar a la SOFTEX sobre los aspectos técnicos relacionados al Modelo de Referencia (MR-MPS) y Método de Evaluación (MA-MPS), para: (i) creación y perfeccionamiento continuo del MR-MPS, MA-MPS y sus guías específicas; (ii) capacitación de personas por medio de cursos, pruebas y workshops. 1 MPS.BR, MR-MPS, MA-MPS y MN-MPS son marcas de la SOFTEX. La sigla MPS.BR está asociada al programa MPS.BR Mejora del Proceso de Brasileño y la sigla MPS está asociada al modelo MPS Mejora del Proceso de. MPS.BR Guía de Implementación Parte 4:2011 3/68

4 La creación y el perfeccionamiento de esta Guía de Implementación son también atribuciones del ETM, siendo que esta guía forma parte del siguiente conjunto de documentos del modelo MPS: Guía General:2009 [SOFTEX, 2011a]; Guía de Implementación (partes 1 a 11); Guía de Evaluación:2009 [SOFTEX, 2011b]; y Guía de Adquisición:2009 [SOFTEX, 2011c]. Esta Guía de Implementación proporciona orientaciones para implementar en las organizaciones los niveles de madurez descritos en el Modelo de Referencia MR- MPS, detallando los procesos contemplados en los respectivos niveles de madurez y los resultados esperados con la implementación de los procesos. La Guía de implementación está subdividida en once partes, contemplando, respectivamente, los siguientes niveles de madurez: Parte 1: Fundamentos para Implementación del Nivel G del MR-MPS; Parte 2: Fundamentos para Implementación del Nivel F del MR-MPS; Parte 3: Fundamentos para Implementación del Nivel E del MR-MPS; Parte 4: Fundamentos para Implementación del Nivel D del MR-MPS; Parte 5: Fundamentos para Implementación del Nivel C del MR-MPS; Parte 6: Fundamentos para Implementación del Nivel B del MR-MPS; Parte 7: Fundamentos para Implementación del Nivel A del MR-MPS; Parte 8: Implementación del MR-MPS (Niveles G a A) en organizaciones que adquieren software; Parte 9: Implementación del MR-MPS (Niveles G a A) en organizaciones del tipo ; Parte 10: Implementación del MR-MPS (Niveles G a A) en organizaciones del tipo ; y Parte 11: Implementación y Evaluación del MR-MPS (Niveles G a A) en conjunto con el CMMI-DEV. Los cambios de esta Guía de Implementación en relación a la versión 2009 se deben a: cambios realizados en la versión 2009 de la Guía General; corrección ortográfica y gramatical; adecuación de las referencias bibliográficas; e inclusión de notas explicativas contenidas en las partes 8, 9 y 10 de la Guía de implementación. MPS.BR Guía de Implementación Parte 4:2011 4/68

5 2 Introducción Los cambios que están sucediendo en los entornos de negocios han motivado a las empresas a modificar sus estructuras organizacionales y procesos productivos, saliendo de la visión tradicional basada en áreas funcionales hacia redes de procesos centrados en el cliente. La competitividad depende, cada vez más, del establecimiento de conexiones en estas redes, creando vínculos esenciales en las cadenas productivas. Lograr competitividad por la calidad, para las empresas de software, implica tanto la mejora de la calidad de los productos de software y servicios asociados, así como la de los procesos de producción y distribución de software. De esta forma, así como para otros sectores, la calidad es un factor crítico de éxito para la industria de software. Para que se tenga un sector de software competitivo nacional e internacionalmente, es esencial que los emprendedores del sector se concentren en la eficiencia y la eficacia de sus procesos, buscando ofrecer productos de software y servicios asociados conforme estándares internacionales de calidad. Se busca que el modelo MPS sea adecuado al perfil de empresas con diferentes tamaños y características, públicas y privadas, aunque con especial atención a las micro, pequeñas y medianas empresas. También se espera que el modelo MPS sea compatible con los estándares de calidad aceptados internacionalmente y que tenga como presupuesto el aprovechamiento de toda la competencia existente en los estándares y modelos de mejora de proceso ya disponibles. De esta forma, tiene como base los requisitos de procesos definidos en los modelos de mejora de proceso y atiende a la necesidad de implantar los principios de Ingeniería de de manera adecuada al contexto de las empresas, estando en consonancia con los principales abordajes internacionales para la definición, evaluación y mejora de procesos de software. El Modelo MPS se basa en los conceptos de madurez y capacidad de proceso para la evaluación y mejora de la calidad y productividad de productos de software y servicios asociados. Dentro de ese contexto, el MPS.BR posee tres componentes: Modelo de Referencia (MR-MPS), Método de Evaluación (MA-MPS) y Modelo de Negocio (MN-MPS). El Modelo MPS está descrito por medio de documentos en forma de guías: Guía General: contiene la descripción general del modelo MPS y detalla el Modelo de Referencia (MR-MPS), sus componentes y las definiciones comunes necesarias para su entendimiento y aplicación [SOFTEX, 2011a]. Guía de Adquisición: describe un proceso de adquisición de software y servicios asociados. Está descrito de modo que apoye a las instituciones que quieran adquirir productos de software y servicios asociados [SOFTEX, 2011c]. Guía de Evaluación: describe el proceso y el método de evaluación MA-MPS, los requisitos para evaluadores líderes, evaluadores adjuntos e Instituciones Evaluadoras (IA) [SOFTEX, 2011b]. Guía de Implementación: serie de once documentos que proporcionan orientaciones para implementar en las organizaciones los niveles de madurez descritos en el Modelo de Referencia MR-MPS. MPS.BR Guía de Implementación Parte 4:2011 5/68

6 3 Objetivo La Guía de Implementación proporciona orientaciones para implementar en las organizaciones los niveles de madurez descritos en el Modelo de Referencia MR- MPS, detallando los procesos contemplados en los respectivos niveles de madurez y los resultados esperados con la implementación de los procesos. Este documento corresponde a la parte 4 de la Guía de Implementación y aborda la implementación del nivel de madurez D. Este documento está dirigido, pero no se limita, a organizaciones interesadas en utilizar el MR-MPS para mejora de sus procesos de software e Instituciones Implementadoras (II). El contenido de este documento es informativo, o sea, no se espera que una organización que está implementando el MR-MPS cumpla todos los elementos citados en la explicación referente a los resultados esperados. Las observaciones presentes en este documento buscan apenas explicitar elementos importantes en la interpretación de los resultados esperados. Durante una evaluación MPS, solo es requerido el cumplimiento de los resultados esperados definidos en la Guía General. Los evaluadores MPS deben analizar si la implementación de los procesos de la organización cumple cada resultado, con abertura a múltiples formas válidas de implementación. 4 Evolucionando del nivel E al nivel D La implementación del nivel E en una organización tiene como foco principal la estandarización de los procesos de la organización, por medio de la definición de procesos estándar, lo que incluye, además de los procesos del nivel E, todos los procesos que pertenecen a los niveles G y F del MR-MPS. La evolución del nivel E al nivel D no presenta novedades en términos de los procesos y atributos de proceso ya implantados en el nivel E, pues estos continúan con la misma capacidad. La evolución hacia el nivel D del MR-MPS implica, por lo tanto, apenas en la definición e implementación de cinco nuevos procesos con el mismo nivel de capacidad de los procesos ya implantados: Desarrollo de Requisitos (DRE), Integración del Producto (ITP), Diseño y Construcción del Producto (PCP), Validación (VAL) y Verificación (VER). Estos procesos, junto con el proceso Gestión de Requisitos (GRE), son generalmente mencionados como siendo relacionados a la ingeniería del software propiamente dicha. Los procesos de ingeniería están íntimamente relacionados e, por lo tanto, se debe evitar tratarlos de forma aislada en un abordaje meramente secuencial, sino más bien, ejecutarlos de forma interactiva y alineada con el ciclo de vida definido. Los procesos son descritos en orden alfabética en las guías, sin embargo, una posible secuencia de lectura más compatible con el orden natural con que son ejecutados dentro de un proceso de desarrollo seria: Desarrollo de Requisitos (DRE), Diseño y Construcción del Producto (PCP), Integración del Producto (ITP), Verificación (VER) y Validación (VAL). En este nivel, son permitidas algunas exclusiones de resultados esperados de algunos procesos conforme descrito en las partes 8, 9 y 10 de la Guía de Implementación. La aprobación de las exclusiones es responsabilidad del evaluador líder. Todas las exclusiones de resultados esperados deben estar listadas en el Plan de Evaluación, en el Informe de Evaluación y en el Resultado de la Evaluación. MPS.BR Guía de Implementación Parte 4:2011 6/68

7 de No hay comentarios adicionales para este tipo de organización. La mayor diferencia entre una organización del tipo y otros tipos de organización está en el Nivel D del MR-MPS. Es en este nivel que son inseridas las prácticas relacionadas a la ingeniería del producto de software. Como las Fábricas de tienen por foco la fase de implementación (construcción) del ciclo de vida, algunas actividades no son por ella realizadas, siendo, por lo tanto, excluidas del alcance de la evaluación. Estas exclusiones son detalladas en las próximas secciones. La mayor diferencia entre una organización del tipo y otros tipos de organización está en el nivel D del MR-MPS. Es en este nivel que son inseridas las prácticas relacionadas a las de producto. Como las Fábricas de Prueba tienen por foco la verificación y validación, algunas actividades no son por ella realizadas, siendo, por lo tanto, excluidas del alcance de la evaluación, conforme detallado en las próximas secciones. Estas exclusiones son detalladas en las próximas secciones. 5 Desarrollo de Requisitos (DRE) 5.1 Propósito El propósito del proceso Desarrollo de Requisitos es definir los requisitos del cliente, del producto y de los componentes del producto Estos tres tipos de requisitos atienden las diferentes necesidades de todos los involucrados en el proyecto. Inicialmente las necesidades, expectativas, restricciones e interfaces del cliente son identificadas y traducidas en requisitos del cliente. Posteriormente, los requisitos del cliente son refinados y descritos en términos técnicos originando los requisitos funcionales y no-funcionales del producto y de los componentes del producto. Una definición de esos requisitos, así como de los escenarios y conceptos operativos requeridos, también se debe elaborar en un nivel de detalle que permita la realización de diseños técnicos y la construcción de la solución del software para resolver el problema en cuestión. Todo el conjunto de requisitos se debe analizar, validar y mantener durante el ciclo de desarrollo o de mantenimiento de un producto. La Guía General [SOFTEX, 2011a] define componente de producto como una parte del producto final o algo utilizado en su desarrollo, por ejemplo un subproducto, un proceso o una herramienta, que es parte de la entrega. Los componentes son integrados en sucesivos niveles para componer el producto final. Un producto es definido como artefacto asociado a la ejecución de un proceso que se pretende entregar para un cliente o usuario final [SOFTEX, 2011a]. MPS.BR Guía de Implementación Parte 4:2011 7/68

8 Los resultados esperados de este proceso están relacionados a los resultados esperados de los procesos Diseño y Construcción del Producto (PCP), Gestión de Requisitos (GRE), Verificación (VER) y Validación (VAL), o por ser productos requeridos para su ejecución o por tener una interfaz con el proceso propiamente dicho. El conjunto de requisitos producido por el Desarrollo de Requisitos (DRE), por ejemplo, es el producto de trabajo requerido para iniciar el proceso Diseño y Construcción del Producto (PCP). De forma semejante, tanto los requisitos del cliente como los requisitos funcionales y no-funcionales del producto y de componentes del producto son productos de trabajo que están bajo el alcance del proceso Gestión de Requisitos (GRE). Finalmente, existe una intersección directa del último resultado esperado de este proceso (DRE8 Los requisitos son validados ) con el proceso Validación (VAL). de Para organizaciones de el único resultado esperado obligatorio es DRE1. Los demás resultados pueden ser excluidos, de acuerdo con el tipo de adquisición del proyecto. La aprobación de las exclusiones es responsabilidad del evaluador líder. Todas las exclusiones de resultados esperados deben estar listadas en el Plan de Evaluación, en el Documento de Evaluación y en el Resultado de la Evaluación. De cualquier forma, aún cuando no ejecuta una actividad del proceso, es responsabilidad de la organización adquiriente supervisar la ejecución del proceso por el proveedor. Para estas organizaciones, apenas el resultado DRE1 es obligatorio. Los demás resultados pueden ser excluidos. La aprobación de las exclusiones es responsabilidad del evaluador líder. Todas las exclusiones de resultados esperados deben estar listadas en el Plan de Evaluación, en el Documento de Evaluación y en el Resultado de la Evaluación. El resultado DRE1 puede ser utilizado para la comprensión y aceptación de las especificaciones que, en el ámbito de una, constituyen las necesidades del proyecto. Como no existen otras especificidades para organizaciones del tipo, no fueron incluidos comentarios en los resultados esperados. Para estas organizaciones, apenas el resultado DRE1 es obligatorio. La aprobación de las exclusiones es responsabilidad del evaluador líder, dependiendo del tipo de Prueba que será efectuado. Todas las exclusiones de resultados esperados deben estar listadas en el Plan de Evaluación, en el Documento de Evaluación y en el Resultado de la Evaluación. El resultado DRE1 puede ser utilizado para comprensión y aceptación de los requisitos que serán utilizados para. MPS.BR Guía de Implementación Parte 4:2011 8/68

9 Como no existen especificidades para organizaciones del tipo Fábrica de, no fueron incluidos comentarios adicionales a los resultados esperados. 5.2 Fundamentación teórica Requisitos son la base de todo el proyecto de software. Un requisito es una característica del sistema o la descripción de algo que el sistema es capaz de realizar para lograr sus objetivos [PFLEEGER, 2004]. En el SWEBOK [IEEE, 2004], un requisito es descrito como una propiedad que el software debe tener para resolver algún problema en el mundo real. De acuerdo con el IEEE Engineering Standards, un requisito es descrito de dos formas: (i) una condición o capacidad necesaria para que un usuario resuelva un problema o logre un objetivo, o (ii) una condición o una capacidad que se debe lograr o estar presente en un sistema para cumplir un contrato, estándar, especificación u otro documento formalmente impuesto. Un desarrollo cuidadoso de requisitos es una condición fundamental para éxito del proyecto, pues los requisitos forman las bases para todo el ciclo del proyecto, desde el desarrollo hasta el mantenimiento. Diferentes tipos de requisitos necesitan ser considerados durante el desarrollo. Los requisitos del cliente expresan los resultados deseados para superar los problemas reales. Los requisitos funcionales y no-funcionales del producto 2 definen las soluciones computacionales desarrolladas utilizando sistemas nuevos y existentes [ALEXANDER e ROBERTSON, 2004]. Estos tipos de requisitos necesitan ser pensados de manera diferente, teniendo sus definiciones y asociaciones representadas de forma explícita. Según SOMMERVILLE [SOMMERVILLE, 2003], algunos de los problemas comunes en el desarrollo de requisitos son resultantes de la falta de una nítida separación entre esos diferentes niveles de descripción de requisitos. Desarrollar requisitos incluye las siguientes actividades: Identificación, análisis, validación y comunicación de las necesidades, expectativas y restricciones de los clientes, para obtener los requisitos de los clientes, que constituyen un entendimiento sobre lo que será satisfactorio para los involucrados; Recolección y coordinación de las necesidades de los involucrados, con priorización y negociación de posibles conflictos; Establecimiento de los requisitos del cliente; Establecimiento de los requisitos funcionales y no-funcionales del producto y de los componentes del producto consistentes con los requisitos de los clientes. 2 Los requisitos del producto pueden referirse tanto a los requisitos de un sistema como a los productos de software que lo componen. MPS.BR Guía de Implementación Parte 4:2011 9/68

10 La Ingeniería de Requisitos es definida como el proceso de descubrir, analizar, documentar y verificar las funciones y restricciones del sistema [SOMMERVILLE, 2003], y puede ser dividida en dos grupos de actividades relacionadas: el Desarrollo de Requisitos (que incluye las actividades relacionadas a la Identificación, Análisis y Modelaje); y la Gestión de Requisitos (incluyendo las actividades de Identificación, Rastreabilidad y Gestión de Cambios). El Desarrollo de Requisitos crea e interpreta los requisitos y la Gestión de Requisitos organiza, relaciona los requisitos entre sí y con otros productos de trabajo y mantiene los registros de estos requisitos. Algunos de los mayores desafíos en la creación y mantenimiento de productos de software están directamente relacionados a los requisitos [COAD e YOURDON, 1992]: (i) comprensión del dominio del problema; (ii) comunicación efectiva con los reales usuarios del producto; y (iii) evolución continua de los requisitos. El proceso Desarrollo de Requisitos propone actividades para minimizar los riesgos asociados a los desafíos citados en (i) y (ii), mientras que la combinación de los procesos Gestión de Requisitos y Desarrollo de Requisitos busca minimizar los riesgos causados por el desafío (iii). De acuerdo con el SWEBOK [IEEE, 2004], el Desarrollo de Requisitos incluye los siguientes pasos: Identificación de requisitos identificación, de forma proactiva, de los requisitos; Análisis y negociación de requisitos examen de los requisitos recolectados y negociación con los involucrados, caso de que hayan requisitos en conflicto; Especificación y Modelaje de los requisitos documentación y creación de modelos de los requisitos con el propósito de obtener una mejor comprensión del problema a ser solucionado; y Validación de requisitos examen de la especificación para asegurar que inconsistencias, omisiones y ambigüedades hayan sido detectadas y corregidas. La identificación de requisitos se inicia con la aplicación de técnicas apropiadas para descubrir los reales requisitos del cliente, considerando las necesidades, expectativas y restricciones impuestas por el cliente [PRESSMAN, 2005]. Existen diversas técnicas para identificación de requisitos, entre las principales están: entrevistas, prototipaje, técnica FAST (como JAD) y brainstorming. La entrevista es la técnica más comúnmente utilizada. Para potencializar sus resultados, son necesarias una planificación y una preparación cuidadosa, identificándose los candidatos a la entrevista, definiendo sus objetivos y listando las cuestiones que deben ser obligatoriamente formuladas. El prototipaje incluye los siguientes pasos: estudio preliminar de los requisitos del usuario; construcción del prototipo; y examen del mismo por los usuarios. Prototipos son apenas modelos del producto final y no necesitan estar completos. Son muy útiles para evaluación de requisitos críticos o complejos. Técnicas facilitadas de especificación de aplicaciones o técnicas FAST (Facilitated Application Specification Techniques) incentivan la creación de un equipo conjunto de clientes y desarrolladores que trabajan juntos para [PRESSMAN, 2005]: identificar problemas; proponer elementos de la solución; negociar diferentes abordajes; y especificar un conjunto preliminar de requisitos. Utilizando una técnica MPS.BR Guía de Implementación Parte 4: /68

11 FAST, una reunión es conducida con participación de ingenieros de software y de clientes. Son establecidas reglas para preparación y participación de esa reunión. Es sugerida una agenda, con foco en el problema a ser resuelto, y un facilitador controla la reunión. Un mecanismo de definición es utilizado (como flip-charts, cuadro negro, planillas). La meta es identificar el problema, proponer elementos de la solución, negociar diferentes abordajes y especificar un conjunto preliminar de requisitos. Los abordajes más populares del FAST son: JAD (técnica desarrollada por la IBM) y The Method (creada por la Performance Resources Inc.). La técnica Brainstorming consiste en la conducción de reuniones donde las personas sugieren y exploran ideas, siendo una técnica muy utilizada para la generación de nuevas ideas. Una sesión brainstorming consiste en dos fases: Generación de Ideas en la cual los participantes son incentivados a proponer ideas sin críticas de los demás; y Consolidación, en la cual es hecha la evaluación de viabilidad y la priorización de las ideas propuestas. Después de la identificación, los requisitos deben ser modelados para obtener una mejor comprensión del producto a ser desarrollado. El modelo de requisitos debe enfocar aquello que el producto debe hacer y no en cómo debe hacerlo. Generalmente, se usa una notación gráfica para describir informaciones transformadas por el producto, el procesamiento de las informaciones, el comportamiento del producto y otras características [PRESSMAN, 2005]. Los principales paradigmas de modelaje de requisitos son: Análisis Estructurada; y Análisis Orientada a Objetos. En el Análisis Estructurado son creados modelos que representan el flujo y el contenido de la información (datos y control), el producto es dividido en particiones funcionales y de comportamiento y la esencia de aquello que se debe construir es descrita. Los siguientes modelos son elaborados: Diagramas de flujo de datos (DFDs); Diagrama de Transición de Estado (DTE); Diccionario de Datos. En el Análisis Orientado a Objetos el objetivo es modelar los conceptos (objetos) del dominio del producto, sus relaciones y comportamientos. Ese modelo es refinado continuamente hasta obtenerse un modelo con suficiente detalle para su implementación en la forma de código ejecutable. Los siguientes modelos son elaborados: Modelo de Casos de Uso y Escenarios; Modelo de Clases; Diagramas de Secuencia y de Actividad; Diagramas de Estados. MPS.BR Guía de Implementación Parte 4: /68

12 5.3 Resultados esperados DRE1 - Las necesidades, expectativas y restricciones del cliente, tanto del producto como de sus interfaces, son identificadas El alcance de este resultado esperado envuelve la utilización de métodos adecuados para identificar necesidades, expectativas, restricciones e interfaces del cliente. Se debe buscar el envolvimiento de representantes del cliente y utilizar técnicas de identificación de requisitos para identificar de forma proactiva requisitos adicionales no discutidos explícitamente por los clientes. Algunos ejemplos de técnicas de identificación de requisitos son [IEEE, 2004; SEI, 2010; PFLEEGER, 2004; PRESSMAN, 2005; SOMMERVILLE, 2003]: entrevistas; cuestionarios; construcción de escenarios operativos y análisis de tareas del usuario final; prototipos y modelos; técnicas facilitadoras de especificación de aplicaciones (como, por ejemplo, JAD); casos de uso; brainstorming; observación de productos y entornos existentes; análisis de casos de negocio; estudio de fuentes de información como documentos, estándares o especificaciones; etnografía; QFD (Quality Function Deployment); e ingeniería reversa (para sistemas legados). Además de esas técnicas historias de usuarios también pueden ser utilizadas cuando se desarrolla utilizando métodos agiles. Cualquiera que sea la técnica utilizada, el logro de este resultado se debe evidenciar por medio de registros que muestren la utilización de algún método para identificar necesidades, expectativas y restricciones del cliente en relación al producto y sus interfaces. En algunas situaciones la organización, por su ramo de actividad, puede recibir los requisitos del cliente o requisitos funcionales y no-funcionales del producto y de los componentes del producto ya especificados. Aún en este caso, es necesario que haya una revisión del conjunto de requisitos recibido, de forma proactiva, buscando identificar errores, inconsistencias y requisitos ausentes. Como resultado, tendrá una nueva lista de requisitos o la confirmación de la anterior, caso de que no se hayan tenido cambios. de Este resultado es obligatorio cualquiera que sea el tipo de adquisición. MPS.BR Guía de Implementación Parte 4: /68

13 5.3.2 DRE2 - Un conjunto definido de requisitos del cliente es especificado y priorizado a partir de las necesidades, expectativas y restricciones identificadas Las necesidades, expectativas y restricciones del cliente identificadas anteriormente son traducidas en requisitos del cliente. Para que esto ocurra, puede ser necesaria la resolución de conflictos entre los proveedores de requisitos y los demás involucrados en el proyecto relacionados a la especificación de los requisitos. Además de esto, pueden surgir cuestiones relevantes a ser verificadas y/o validadas. La priorización de los requisitos auxilia en la determinación del alcance del proyecto, iteración o incremento y asegura que los requisitos funcionales y no funcionales que son críticos sean tratados más rápidamente [SEI, 2010]. de Dependiendo del tipo de adquisición, este resultado puede ser excluido del alcance de la evaluación de la organización adquiriente debido al hecho de que la actividad correspondiente es ejecutada por el proveedor DRE3 - Un conjunto de requisitos funcionales y no-funcionales, del producto y de los componentes del producto que describen la solución del problema a ser resuelto, es definido y mantenido a partir de los requisitos del cliente El alcance de este resultado esperado comprende la consolidación de las necesidades, expectativas, restricciones del cliente en un conjunto de requisitos funcionales y no-funcionales del producto y de los componentes del producto. Definir los requisitos funcionales incluye analizar los requisitos del cliente para identificar las funciones requeridas en el producto. Requisitos funcionales describen las funciones o los servicios que se espera que el sistema suministre. Un requisito funcional describe una interacción entre el sistema y su entorno [IEEE, 2004; SEI, 2010; SOMMERVILLE, 2003]. Son ejemplos de requisitos funcionales: generar informe con los resultados de las pruebas clínicas de un paciente; formatear un texto; y registrar un cliente. Requisitos no-funcionales son requisitos que expresan condiciones o cualidades específicas que el producto y/o componentes del producto debe cumplir. En vez de informar lo que el producto hará, los requisitos no-funcionales señalan las restricciones que deben ser obedecidas. Requisitos no-funcionales son algunas MPS.BR Guía de Implementación Parte 4: /68

14 veces conocidos como restricciones o requisitos de calidad [IEEE, 2004; SEI, 2010]. Son ejemplos de requisitos no-funcionales: el tiempo de respuesta máximo para consultas debe ser tres segundos; o el sistema debe estar disponible para el cliente siete días por semana, veinticuatro horas por día. Requisitos no funcionales pueden ser clasificados de acuerdo con su tipo en diferentes categorías como: requisitos de usabilidad, requisitos de desempeño, requisitos de confiabilidad, entre otros [SOMMERVILLE, 2003]. Al especificar los requisitos funcionales y no funcionales es posible percibir cosas como: la falta de informaciones, la existencia de inconsistencias y errores. En esas situaciones, es necesario buscar informaciones complementarias y resolver las inconsistencias detectadas. Durante la ejecución de un proyecto, pueden ocurrir cambios en los requisitos. Esos cambios deben ser gestionados por medio del proceso Gestión de Requisitos (GRE), de modo que se mantengan los requisitos funcionales y no funcionales consistentes con los demás productos de trabajo y se minimice el impacto de los cambios en el proyecto. de Dependiendo del tipo de adquisición, este resultado puede ser excluido del alcance de la evaluación de la organización adquiriente debido al hecho de que la actividad correspondiente es ejecutada por el proveedor DRE4 - Los requisitos funcionales y no-funcionales de cada componente del producto son refinados, elaborados y atribuidos Lograr este resultado esperado significa elaborar los requisitos funcionales y nofuncionales de cada componente del producto en los términos técnicos necesarios para el desarrollo del producto y para los componentes del producto. Para refinar los requisitos funcionales y no-funcionales pueden ser utilizadas técnicas de modelaje como especificación de casos de uso de negocio, modelos de contexto [SOMMERVILLE, 2003] y otras como las citadas en la sección 5.2. Los requisitos del cliente pueden ser descritos utilizando los términos usados por los clientes y pueden contener descripciones no técnicas. Los requisitos funcionales y no-funcionales de cada componente del producto son la expresión de los requisitos del cliente en términos técnicos, de modo que puedan guiar el diseño del producto y de los componentes del producto. Requisitos funcionales pueden ser descritos de MPS.BR Guía de Implementación Parte 4: /68

15 muchas formas como, por ejemplo: funciones; opciones del sistema; o aún como servicios o métodos Orientados a Objetos (OO). Al definir los requisitos funcionales y no-funcionales, una práctica común es categorizar los requisitos en grupos, por medio de algún criterio. Ejemplos de criterios para ese fin son [CACHERO e KOCH, 2002]: propósitos similares; dependencia funcional; y datos considerados. El logro de este resultado esperado puede envolver: Derivar requisitos funcionales y no-funcionales que resulten de decisiones de diseño, tales como selección de tecnología; Atribuir requisitos funcionales y no-funcionales y restricciones para cada componente del producto; Establecer las relaciones entre los requisitos del cliente y los requisitos funcionales y no-funcionales de cada componente del producto, de acuerdo con el proceso Gestión de Requisitos. Como indicador del alcance de este resultado, se debe evidenciar que el conjunto de requisitos funcionales y no-funcionales haya sido refinado, detallado y documentado a lo largo del ciclo de vida del desarrollo del producto y de los componentes del producto. Los registros de las actualizaciones realizadas en esos requisitos también deben ser documentados como evidencia del logro de este resultado. de Dependiendo del tipo de adquisición, este resultado puede ser excluido del alcance de la evaluación de la organización adquiriente debido al hecho de que la actividad correspondiente es ejecutada por el proveedor DRE5 - Interfaces internas y externas del producto y de cada componente del producto son definidas Las interfaces internas y externas del producto y de cada componente del producto deben ser especificadas y documentadas de acuerdo con la arquitectura definida del producto. Las definiciones de esas interfaces son útiles para diseñar y construir las unidades de código de los componentes del producto, así como para servir de base para verificar la integración entre cada componente del producto y para verificar la integración del producto con otros elementos externos. MPS.BR Guía de Implementación Parte 4: /68

16 Las definiciones de las interfaces deben ser definidas en términos de tipos y formatos de datos de entrada y salida entre los componentes del producto y entre elementos del sistema, especificaciones de protocolos de comunicación, entre otros. de Dependiendo del tipo de adquisición, este resultado puede ser excluido del alcance de la evaluación de la organización adquiriente debido al hecho de que la actividad correspondiente es ejecutada por el proveedor DRE6 - Conceptos operativos y escenarios son desarrollados El logro de este resultado esperado exige el desarrollo de conceptos operativos y escenarios para el producto y para los componentes del producto. Un concepto operativo para un producto depende del diseño de la solución y de un escenario, por lo tanto son elaborados cuando las decisiones de diseño son tomadas y los requisitos detallados. Un escenario es una secuencia de eventos posible de ocurrir en el uso de un producto y es utilizado para tornar explícitas algunas necesidades de los involucrados [SEI, 2010]. Una forma posible de describir los escenarios es utilizar el modelaje de escenarios sugerida por la UML, en la cual el escenario es una secuencia específica de acciones que ilustra el comportamiento de un caso de uso. Al describir un escenario, se deben considerar los siguientes elementos: Flujo principal describe una secuencia de acciones que serán ejecutadas considerando que ningún error ocurrirá durante la ejecución de las acciones; Flujos Alternativos describen lo que ocurre cuando el actor (rol que interactúa con el sistema) hace una elección alternativa, diferente de la descrita en el flujo principal, para lograr su objetivo. Flujos alternativos pueden describir opciones exclusivas entre sí; Flujos de Excepción corresponden a la descripción de las situaciones de excepción, cuando algo inesperado ocurre en la interacción con el sistema; Condición previa define qué hipótesis son asumidas como verdaderas para que el escenario sea iniciado. Se debe usar en casos de uso cuya realización no tenga sentido en ningún momento, pero solamente cuando el sistema esté en un determinado estado con ciertas propiedades; MPS.BR Guía de Implementación Parte 4: /68

17 Condición posterior estado al que el sistema llega después de que el caso de uso es realizado. El logro de este resultado esperado puede abarcar: Definir el entorno en el cual el producto operará, incluyendo límites y restricciones; Elaborar un concepto operativo detallado para cada producto o componente del producto que defina la interacción del producto, del usuario final, del entorno y que satisfaga las necesidades de operación, mantenimiento y apoyo; Revisar conceptos operativos y escenarios para refinar y descubrir nuevos requisitos. de Dependiendo del tipo de adquisición, este resultado puede ser excluido del alcance de la evaluación de la organización adquiriente debido al hecho de que la actividad correspondiente es ejecutada por el proveedor DRE7 - Los requisitos son analizados, usando criterios definidos, para equilibrar las necesidades de los interesados con las restricciones existentes Este resultado busca asegurar que los requisitos, en sus diferentes niveles, sean analizados, de modo que se balanceen las necesidades de los interesados considerando las restricciones de proyecto existentes. Los requisitos del producto pueden ser analizados juntamente con escenarios, conceptos operativos y definiciones detalladas de los requisitos, para determinar si ellos son necesarios, correctos, probables y suficientes para lograr los objetivos y requisitos de alto nivel (requisitos del cliente) [SEI, 2010]. Técnicas de Verificación pueden ser utilizadas para asegurar que: Todos los requisitos hayan sido declarados de forma no ambigua; Las inconsistencias, omisiones y errores hayan sido detectados y corregidos; Los requisitos de diferentes niveles estén consistentes entre sí. El logro de este resultado esperado puede comprender: MPS.BR Guía de Implementación Parte 4: /68

18 Analizar las necesidades, expectativas y restricciones de los involucrados, con el objetivo de organizarlas y eliminar posibles conflictos; Analizar escenarios y conceptos operativos para refinar las necesidades, restricciones e interfaces del cliente y descubrir nuevos requisitos; Analizar requisitos para asegurar que los mismos estén completos, factibles y verificables, de acuerdo con los criterios establecidos en el proceso Verificación (VER). Para el análisis del balanceo entre necesidades y restricciones pueden ser utilizados modelos, simulaciones, prototipos y evaluaciones de riesgos en los requisitos y en la arquitectura funcional. En [KELLNER et al., 1999] son presentados los principales conceptos relacionados a la simulación de procesos de software. de Dependiendo del tipo de adquisición, este resultado puede ser excluido del alcance de la evaluación de la organización adquiriente debido al hecho de que la actividad correspondiente es ejecutada por el proveedor DRE8 - Los requisitos son validados Este resultado esperado busca asegurar que los requisitos sean validados, utilizando técnicas adecuadas, de modo que se asegure que el producto tendrá el desempeño adecuado cuando instalado en el entorno al que se destina. La validación aumenta la confianza de que los requisitos definidos son capaces de guiar el desarrollo satisfactoriamente. Cuanto antes los problemas sean identificados, menos re-trabajo y costo serán necesarios para adecuar los requisitos a las expectativas del cliente. Las técnicas de validación son discutidas en la sección que presenta el proceso Validación (VAL). Y para cumplir este resultado esperado, la validación debe estar de acuerdo con criterios establecidos por el proceso Validación (VAL). MPS.BR Guía de Implementación Parte 4: /68

19 de Dependiendo del tipo de adquisición, este resultado puede ser excluido del alcance de la evaluación de la organización adquiriente debido al hecho de que la responsabilidad por ejecutar la validación es del proveedor. De cualquier forma, el adquiriente participa de las actividades de validación. 6 Integración del Producto (ITP) 6.1 Propósito El propósito del proceso Integración del Producto es combinar los componentes del producto, produciendo un producto integrado consistente con su diseño, y demostrar que los requisitos funcionales y no-funcionales se cumplen para el entorno al que se destina el producto o entorno equivalente El proceso Integración del Producto se refiere a cómo integrar un producto y cuál es la secuencia de integración a ser usada. Trata, también, de la creación de un entorno operativo en el cual se pueda implantar el producto satisfactoriamente; de la documentación de los procedimientos y criterios de integración del producto; de cómo asegurar la integración correcta de las partes; y de la entrega del producto. Los resultados esperados de este proceso están relacionados a resultados esperados de los procesos Diseño y Construcción del Producto (PCP), Verificación (VER), Validación (VAL), Gestión de Decisiones (GDE), Gestión de Configuración (GCO) y Gestión de Requisitos (GRE). La intersección de este proceso con el proceso Diseño y Construcción del Producto (PCP) está presente en el resultado esperado referente al establecimiento del entorno de integración, en lo que respecta a la compra, reutilización o desarrollo del entorno. También está presente en el resultado esperado referente a la gestión de las interfaces internas de los productos y componentes del producto, en lo que respecta al proyecto de interfaces entre componentes del producto. La intersección de este proceso con el proceso Verificación (VER) está presente en los resultados esperados referentes a la verificación de las interfaces, del entorno de integración, de los componentes del producto y del producto integrado, en lo que respecta a la realización de pruebas de unidades, integración y regresión, además de revisiones por pares. De modo semejante, en el caso de que haya la necesidad de validar interfaces, entorno de integración, componentes de producto o producto integrado, puede ser identificada la interacción con el proceso Validación (VAL). MPS.BR Guía de Implementación Parte 4: /68

20 La intersección de este proceso con el proceso Gestión de Decisiones (GDE) está presente en los resultados esperados referentes al desarrollo y selección de la estrategia de integración, en caso de que se desee seleccionar la estrategia de integración de acuerdo con un proceso formal de decisión. También puede haber intersección en el resultado esperado relacionado al establecimiento del entorno de integración, ya que la decisión sobre adquirir, reutilizar o desarrollar el entorno también puede seguir un proceso formal de selección. La intersección de este proceso con el proceso Gestión de Configuración (GCO) está presente en el resultado esperado referente a la gestión de las interfaces internas de los productos y componentes del producto, en lo que respecta al control de los cambios. También existen relaciones en el resultado esperado referente a la entrega del producto y su documentación para el cliente, en lo que respecta a la liberación del producto. La intersección de este proceso con el proceso Gestión de Requisitos (GRE) está presente en el resultado esperado referente a la gestión de las interfaces internas de los productos y componentes del producto, en lo que respecta a la gestión de los cambios. También existen relaciones en el resultado esperado referente a pruebas de regresión, una vez que se puede hacer uso de una matriz de rastreabilidad. de Para organizaciones de el único resultado esperado obligatorio es ITP9. Los demás resultados pueden ser excluidos, de acuerdo con el tipo de adquisición del proyecto. La aprobación de las exclusiones es responsabilidad del evaluador líder. Todas las exclusiones de resultados esperados deben estar listadas en el Plan de Evaluación, en el Documento de Evaluación y en el Resultado de la Evaluación. De cualquier forma, aunque no sea ejecuta una actividad del proceso, es responsabilidad de la organización adquiriente supervisar la ejecución del proceso del proveedor. Son permitidas exclusiones de los resultados esperados del proceso, dependiendo del alcance de actuación de la. Caso la tenga en su alcance de trabajo la realización de actividades de integración del código desarrollado, este proceso deberá estar presente, caso contrario, podrá ser excluido del alcance de la evaluación. La aprobación de las exclusiones es responsabilidad del evaluador líder. Todas las exclusiones de resultados esperados y procesos deben estar listadas en el Plan de Evaluación, en el Documento de Evaluación y en el Resultado de la Evaluación. Como no existen especificidades para organizaciones del tipo Fábrica de, no fueron incluidos comentarios en los resultados esperados. En organizaciones del tipo son permitidas exclusiones de todos los resultados esperados de proceso. Caso la MPS.BR Guía de Implementación Parte 4: /68

21 tenga en su alcance de trabajo, la realización de actividades de integración del código desarrollado, este proceso deberá estar presente, caso contrario, deberá ser excluido del alcance de la evaluación. La aprobación de las exclusiones es responsabilidad del evaluador líder. Todas las exclusiones de resultados esperados deben estar listadas en el Plan de Evaluación, en el Documento de Evaluación y en el Resultado de la Evaluación. Como no existen especificidades para organizaciones del tipo Fábrica de, no fueron incluidos comentarios adicionales a los resultados esperados. 6.2 Fundamentación teórica En proyectos pequeños, la integración puede envolver apenas algunas clases o archivos que necesitan funcionar juntos. En proyectos grandes, puede envolver miles de programas y componentes que forman un sistema mayor. Independientemente del tamaño, algunos principios básicos deben ser aplicados [McCONNELL, 2004]. La integración del producto puede abarcar tanto la integración del software como la integración del sistema. En la integración del software, se integran las unidades del software, produciendo elementos de software integrados. En la integración del sistema, se integran los elementos del sistema (incluyendo elementos de software, elementos de hardware, operaciones manuales, y otros sistemas, conforme necesario) para producir un sistema completo [ISO/IEC, 2008]. La integración de los componentes del producto debe ser planificada, incluyendo requisitos de prueba, procedimientos, datos, responsabilidades y cronograma. Esa planificación debe estar adecuadamente documentada [ISO/IEC, 2008]. Un aspecto crítico de la integración de productos es la gestión de interfaces internas y externas del producto o componentes del producto, para asegurar compatibilidad entre las interfaces [SEI, 2010]. Una interfaz puede ser vista, de manera general, como siendo una frontera de comunicación entre componentes, tales como partes de un software, elementos de hardware hasta un usuario. Normalmente se refiere a una abstracción que un componente provee de sí mismo hacia el exterior. Según la ISO/IEC [ISO/IEC, 1994], una interfaz es una frontera compartida entre dos unidades funcionales, definida por características funcionales, características físicas comunes de interconexión, y otras características, conforme apropiado. Se debe dar atención a la gestión de interfaces a lo largo del proyecto. El orden en el cual se construyen los componentes del producto influencia en el orden en la cual se les puede integrar, ya que no se puede integrar lo que aun no fue construido. Tanto la secuencia de construcción como la de integración, son tópicos importantes a ser considerados, pues construir e integrar software en un orden equivocado puede tornar la codificación, las pruebas y la depuración más difíciles [McCONNELL, 2004]. Las pruebas de integración también tienen rol importante para asegurar que las diferentes partes del producto puedan interactuar adecuadamente en conjunto, de MPS.BR Guía de Implementación Parte 4: /68