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

(1)

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

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 2011. 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

Derechos de esta edición reservados por la Sociedad SOFTEX La distribución ilimitada de este documento está sujeta a copyright ISBN 978-85-99334-72-0

(2)

Índice

1 Prefacio ... 3

2 Introducción ... 5

3 Objetivo ... 6

4 Evolucionando del nivel E al nivel D ... 6

5 Desarrollo de Requisitos (DRE) ... 7

5.1 Propósito ... 7

5.2 Fundamentación teórica ... 9

5.3 Resultados esperados ... 12

6 Integración del Producto (ITP) ... 19

7 Diseño y Construcción del Producto (PCP) ... 31

8 Validación (VAL) ... 41

9 Verificación (VER) ... 50

10 Los atributos de proceso del nivel D ... 60

Referencias bibliográficas... 61

Lista de colaboradores de la Guía de Implementación – Parte 4:2011 ... 65

Lista de colaboradores de la Guía de Implementación – Parte 4:2009 ... 66

Lista de colaboradores de la Guía de Implementación – Parte 4 versión 1.1 - Julio/2007 ... 67

Lista de colaboradores de la Guía de Implementación – Parte 4 versión 1.0 - Diciembre/2006 ... 68

(3)

1 Prefacio

El MPS.BR¹ 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 Software 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 Software, 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 Software Brasileño y la sigla MPS está asociada al modelo MPS – Mejora del Proceso de Software.

(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 Fábrica de Software;

• Parte 10: Implementación del MR-MPS (Niveles G a A) en organizaciones del tipo Fábrica de Pruebas; 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.

(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 Software 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.

(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.

(7)

Comentarios adicionales para implementación en diferentes tipos de organización Adquirientes

de Software (Parte 8)

No hay comentarios adicionales para este tipo de organización.

Fábrica de Software (Parte 9)

La mayor diferencia entre una organización del tipo Fábrica de Software 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 Software 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.

Fábrica de Pruebas (Parte 10)

La mayor diferencia entre una organización del tipo Fábrica de Pruebas 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 Pruebas 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].

(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).

Para organizaciones Adquirientes de Software 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 Fábrica de Software, constituyen las necesidades del proyecto.

Como no existen otras especificidades para organizaciones del tipo Fábrica de Software, 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 Pruebas.

(9)

Como no existen especificidades para organizaciones del tipo Fábrica de Pruebas, 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 Software 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² 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.

(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

(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.

(12)

5.3 Resultados esperados

5.3.1 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.

Este resultado es obligatorio cualquiera que sea el tipo de adquisición.

Sin comentario adicional para este resultado.

(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].

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.

5.3.3 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

(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.

5.3.4 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 no- funcionales 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

(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.

5.3.5 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.

(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.

5.3.6 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;

(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.

5.3.7 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:

(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.

5.3.8 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).

(19)

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).

(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.

Para organizaciones Adquirientes de Software el único resultado esperado obligatorio es ITP9. Los demás resultados pueden ser excluidos, de acuerdo con el tipo de adquisición del proyecto.

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 Fábrica de Software. Caso la Fábrica de Software 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 Software, no fueron incluidos comentarios en los resultados esperados.

Fábrica de

Pruebas En organizaciones del tipo Fábrica de Pruebas son permitidas exclusiones de todos los resultados esperados de proceso. Caso la

(21)

(Parte 10) Fábrica de Pruebas 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.

Como no existen especificidades para organizaciones del tipo Fábrica de Pruebas, 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 12119 [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

(22)

modo que se cumplan correctamente los requisitos funcionales y no-funcionales pretendidos [TIAN, 2005]. La prueba de integración es el proceso de verificar si los componentes juntos, ejecutan conforme está descrito en las especificaciones y en el diseño de los programas. A partir de este momento, otros tipos de prueba son realizados: prueba funcional; prueba de desempeño; prueba de aceptación; y prueba de instalación [PFLEEGER, 2004].

La integración del producto es más que un único montaje de los componentes del producto al final del diseño y de la construcción. La integración del producto puede ser incremental, usando un proceso iterativo de composición de componentes del producto, evaluación y composición de más componentes del producto [SEI, 2010].

Una integración incremental ofrece algunas ventajas en relación a un abordaje en que el producto es totalmente integrado de una vez, entre ellas [McCONNELL, 2004]:

• Es más fácil localizar los errores, una vez que la parte del producto que está siendo integrada es menor;

• Los miembros del proyecto consiguen ver el resultado de su trabajo más temprano en el proyecto, lo que aumenta su motivación;

• Mejor supervisión del progreso, una vez que el gerente puede ver claramente cual porción del producto está, o no, lista;

• Mejores relaciones con el cliente, que también consigue ver progresos más concretos en el proyecto;

• Los componentes del producto son probados de forma más amplia, una vez que los mismos componentes podrán ser probados diversas veces a lo largo de las pruebas de integración de las partes;

• Es posible reducir el tiempo de desarrollo, pues es posible el paralelismo en las actividades del proyecto.

Es importante que sea definida una estrategia de regresión, una vez que el producto ciertamente sufrirá cambios durante su desarrollo o después de ser entregado al cliente, sean por mantenimientos (correctivos o evolutivos) o inclusiones de nuevos elementos (requisitos o módulos). Esa estrategia debe posibilitar que el producto sea probado nuevamente después de que un cambio sea realizado, de modo que se asegure que cambios o correcciones en el producto no afecten ni damnifiquen otras partes. Prueba de regresión implica en ejecutar nuevamente un conjunto de pruebas ya conducidos anteriormente para asegurar que los cambios realizados no hayan producido efectos colaterales indeseados [PRESSMAN, 2005].

El producto, después de integrado, probado y empaquetado, es entregado al cliente e instalado en el entorno pretendido para operación.

De forma general, podemos resumir algunos de los beneficios esperados por el uso de un abordaje cuidadoso de integración de productos [McCONNELL, 2004], pueden ser resumidos en: (i) detección de defectos más fácil; (ii) menos defectos; (iii) menor tiempo para llegar a productos o partes de productos funcionales; (iv) menor tiempo total de desarrollo; (v) mejores relaciones con el cliente; (vi) moral elevada del equipo; (vii) mayor chance de completarse el proyecto; (viii) estimativas de tiempo más confiables; (ix) informes de status más precisos; (x) mayor calidad del código; y (xi) menos documentación.

(23)

6.3 Resultados esperados

6.3.1 ITP1 - Una estrategia de integración, consistente con el diseño y con los requisitos del producto, es desarrollada y mantenida para los componentes del

6.3.2 producto

Se debe definir una estrategia, incluyendo procedimientos y criterios, para conducir la integración de los componentes del producto, determinando cuales componentes serán integrados y cuál será la secuencia de integración. Es importante que la estrategia de integración escogida sea consistente con el diseño, arquitectura y con los requisitos del producto.

La estrategia de integración a ser adoptada se compone con base en la determinación de la secuencia de integración. La secuencia de integración proporciona un apoyo a la integración incremental y evaluación de componentes del producto. Debe contener informaciones sobre los productos a ser integrados en cada incremento de integración, además de las verificaciones a ser realizadas usando las definiciones de las interfaces entre los componentes del producto.

Diversas estrategias de integración diferentes pueden ser encontradas en la literatura, tales como [PFLEEGER, 2004; McCONNELL, 2004]:

• Integración Bottom-Up: Cada componente en el nivel inferior de la jerarquía del sistema es desarrollado y probado individualmente. Los próximos componentes a ser integrados y probados son aquellos que “llaman” a los que fueron previamente integrados. Ese abordaje es seguido repetidamente, hasta que todos los componentes sean considerados;

• Integración Top-Down: Reverso del abordaje Bottom-Up. El nivel superior (normalmente un componente de control principal) es desarrollado y probado. En seguida, todos los componentes llamados por el(los) componente(s) probado(s) son desarrollados, combinados y probados como una gran unidad. Ese abordaje es seguido repetidamente, hasta que todos los componentes sean considerados;

• Integración Sándwich: Combinación entre los abordajes Top-Down e Bottom- Up. Primero, son integrados y probados los componentes de más alto nivel (Top- Down). Después, son integrados y probados los componentes de nivel inferior (Bottom-Up). Entonces, la integración y las pruebas convergen para los componentes del sistema de nivel intermediario. Esas tres camadas justifican el nombre del abordaje;

• Integración Orientada a Riesgos: Se identifica el nivel de riesgos asociado a cada componente. Con eso, se analizan cuáles serán las partes más difíciles de implementar, y estas son desarrolladas e integradas primero. Las partes más simples son desarrolladas, integradas y probadas después;

• Integración Orientada a la Funcionalidad: Consiste en desarrollar, integrar y probar una funcionalidad por vez. Así, las funcionalidades van siendo integradas incrementalmente, componiendo la funcionalidad total del sistema;

• Integración en Forma de T: Se construye e integra una parte completa del sistema, del nivel más alto al más bajo de jerarquía, permitiendo la verificación

(24)

de cuestiones arquitecturales (parte vertical del “T”). Después de eso, las demás funcionalidades y partes del sistema son construidas e integradas. Normalmente es usada en conjunto con los abordajes orientados a riesgos y a funcionalidades.

Una buena práctica consiste en definir las secuencias de integración alternativa para un producto dado, así como los criterios para la selección de alternativas, y entonces seleccionar, entre las alternativas, basándose en los criterios definidos, aquella que sea la más adecuada. Por ejemplo, en un proyecto se podría seleccionar una entre las seis estrategias de integración descritas arriba con base en criterios como:

experiencia del equipo en el uso de la estrategia; tiempo necesario para entrega de productos intermediarios; complejidad del producto; entre otros. Es importante, también, documentar las razones por las cuales una estrategia de integración fue seleccionada y no otra.

La secuencia de integración, así como la estrategia de integración a ser adoptada, se debe revisar, siempre que sea necesario, puesto que esta puede ser afectada por diversos factores, como por ejemplo, atrasos en la construcción, cambios en el cronograma de entregas, o cambios en las prioridades de construcción.

6.3.3 ITP2 - Un entorno para integración de los componentes del producto es establecido y mantenido

El entorno de integración necesario en cada etapa del proceso de integración del producto puede incluir herramientas de pruebas, simuladores (funcionando como componentes de productos todavía indisponibles), partes de equipamientos o componentes del producto reales, dispositivos de almacenamiento, entre otros. El objetivo de este resultado esperado es asegurar que el entorno para integración de los componentes del producto fue definido y mantenido conforme necesario.

El conjunto de requisitos del entorno de integración del sistema puede contener requisitos de equipamientos, software u otros recursos. Estos requisitos generalmente son identificados a partir del desarrollo de los requisitos y de la arquitectura del producto.

(25)

Criterios y procedimientos de verificación del entorno de integración del producto deben ser definidos para asegurar el apoyo adecuado del entorno en la integración de los elementos de producto.

Una decisión importante en relación al entorno de integración es determinar si este será construido internamente, reutilizado o adquirido de un proveedor externo. Para eso, puede ser necesario realizar un análisis entre desarrollar, comprar o reutilizar (ver el resultado esperado PCP5 del proceso Diseño y Construcción del Producto).

Vale resaltar que el entorno de integración puede, inclusive, ser un entorno del cliente.

6.3.4 ITP3 - La compatibilidad de las interfaces internas y externas de los componentes del producto es asegurada

Muchos problemas relacionados a la integración de productos son originados de aspectos desconocidos o no controlados, tanto de las interfaces internas como externas. Para asegurar que las interfaces internas y externas de los componentes del producto sean compatibles y que su descripción sea completa, las interfaces deben ser revisadas.

Además de las interfaces entre componentes del producto, pueden ser consideradas, también, todas las interfaces con el entorno de integración del producto y con otros entornos, como el de validación, el de verificación, el de operación y el de soporte, conforme necesario.

Listas de verificación con las situaciones más comunes de problemas de consistencia y completitud en las interfaces podrán ser utilizados para tornar la revisión más objetiva y aumentar su efectividad.

Las descripciones de las interfaces deben ser periódicamente revisadas para asegurar que no haya diferencia entre las descripciones existentes y los productos que están siendo desarrollados.