Modelo de calidad CMMI (página 3)

40.  SP 2: Establecer un paquete de datos técnicos

Práctica: "Establecer y mantener un paquete de datos técnicos".

            Un paquete de datos técnicos provee al desarrollador una descripción exhaustiva del producto o de sus componentes a medida que es desarrollado. Dicho paquete también provee flexibilidad de adquisiciones en diversas circunstancias, tales como "Performance-Based Contracting" (PBC) o "Build To Print".

            El diseño es registrado en un paquete de datos técnicos creado durante el diseño preliminar para documentar la definición de la arquitectura. Este paquete de datos técnicos es mantenido durante toda la vida del producto para registrar detalles esenciales del diseño del producto. El paquete de datos técnicos provee la descripción del producto y sus componentes que apoyan la estrategia de adquisición, o la implementación, producción, ingeniería y fases de soporte logístico del ciclo de vida del producto. La descripción incluye la definición de la configuración requerida del diseño y procedimientos para asegurar el comportamiento adecuado del producto o de sus componentes. Esto incluye todos los datos técnicos aplicables como dibujos, listas asociadas, especificaciones, descripciones de diseño, bases de datos de diseño, estándares, requerimientos de rendimiento, provisiones de aseguramiento de calidad y detalles de empaquetamiento. El paquete de datos técnicos incluye una descripción de la solución alternativa seleccionada a ser implementada.

            Un paquete de datos técnicos debería incluir lo siguiente, si dicha información es apropiada para el tipo de producto y componentes del producto:

-           Descripción de arquitectura de producto.

-           Requerimientos asignados.

-           Descripción de componentes del producto.

-           Descripción de los procesos relacionados con el ciclo de vida del producto, si no es descrito como componentes de productos separados.

-           Características de productos claves.

-           Características físicas requeridas y restricciones.

-           Requerimientos de interfaz.

-           Requerimientos de materiales.

-           Fabricación y requerimientos de manufactura.

-           Criterios de verificación usados para asegurar que los requerimientos han sido satisfechos.

-           Condiciones de uso (ambientes) y escenarios de uso / operación, modos y estados de operación, soporte, capacitación, manufactura, eliminación del producto y verificaciones a los largo de la vida útil del producto.

-           Fundamentos de decisiones y características (requerimientos, asignación de requerimientos y opciones de diseño).

            Debido a que las descripciones de diseño pueden contener una gran cantidad de información y pueden ser cruciales para el desarrollo exitoso de los componentes del producto, es aconsejable establecer criterios para organizar y seleccionar la información. Es particularmente útil utilizar la arquitectura del producto como una manera de organizar la información y elaborar vistas claras y relevantes para un tema o característica de interés. Estas vistas incluyen lo siguiente:

-           Clientes.

-           Requerimientos.

-           El ambiente.

-           Funcionalidad.

-           Lógica.

-           Seguridad.

-           Datos.

-           Estados / modos.

-           Construcción.

-           Administración

            Estas vistas son documentadas en el paquete de datos técnicos.

41.  SP 3: Diseñar interfaces utilizando criterios

Práctica: "Diseñar interfaces de componentes del producto utilizando los criterios establecidos".

            Estos diseños de interfaces incluyen lo siguiente:

-           Orígenes.

-           Destino.

-           Estímulos y características de datos para el software

-           Características eléctricas, mecánicas y funcionales para hardware

-           Líneas de comunicación.

            El criterio para interfaces frecuentemente refleja parámetros críticos que deben ser definidos, o al menos investigados, para asegurar su aplicabilidad. Estos parámetros son a menudo característicos de un cierto tipo de producto (software, mecánico, eléctrico, de servicio) y son a menudo asociados con seguridad, durabilidad y características de la misión crítica.

42.  SP 4: Ejecutar Análisis de: Hacer, Comprar o Reutilizar

Práctica: "Evaluar si los componentes del producto debieran ser desarrollados, comprados o reutilizados basándose en los criterios establecidos".

            La determinación acerca de qué producto o componentes del producto serán adquiridos es frecuentemente referido como "make-or-buy analysis" (análisis de hacer-o-comprar). Este análisis esta basado en las necesidades del proyecto; comienza tempranamente durante la primera iteración de diseño, continúa durante el proceso de diseño y concluye con la decisión de desarrollar, adquirir o reutilizar el producto.

            Factores que afectan la decisión de hacer-o-comprar incluyen los siguientes:

-           Funciones que los productos o servicios proveerán y cómo estas funciones se ajustan al proyecto.

-           Recursos y habilidades disponibles del proyecto.

-           Costos de adquisición versus costos de desarrollo interno.

-           Entregas críticas y fechas de integración.

-           Alianzas estratégicas de negocios, incluyendo requerimientos de negocio de alto nivel.

-           Investigación de mercado de productos disponibles, incluyendo productos tipo COTS.

-           Funcionalidad y calidad de productos disponibles.

-           Habilidades y capacidades de potenciales proveedores.

-           Impacto en las competencias esenciales.

-           Licencias, garantías, responsabilidades y limitantes asociadas a productos que están siendo adquiridos.

-           Disponibilidad de productos

-           Calidad propietaria de productos y componentes.

-           Reducción de riesgos.

            La decisión de hacer-o-comprar puede efectuarse aplicando un proceso formal de toma de decisiones. A medida que la tecnología evoluciona, también lo hacen las razones para elegir el desarrollo o compra de componentes de producto. Mientras el esfuerzo de desarrollo complejo puede favorecer la compra de un componente tipo COTS, los avances en la productividad y herramientas pueden presentar razones en sentido contrario. Productos tipo COTS pueden tener documentación incompleta o incorrecta y pueden no contar con soporte en el futuro.

SG 3: Implementar el Diseño del Producto       

Objetivo: "Componentes del producto, y su documentación de apoyo asociada, son implementadas según sus diseños".

            Los componentes del producto son implementados a partir de los diseños establecidos por las prácticas específicas de la práctica específica Desarrollar el Diseño. La implementación usualmente incluye pruebas unitarias de los componentes del producto antes de la integración de producto y el desarrollo de documentación de usuarios finales.

43.  SP 1: Implementar el Diseño

Práctica: "Implementar los diseños de las componentes del producto".

            Una vez que el diseño se ha completado, éste es implementado como un componente del producto. Las características de esa implementación dependen del tipo de componente.

            La implementación del diseño en el primer nivel de la jerarquía del producto implica la especificación de cada uno de los componentes del producto en el siguiente nivel de la jerarquía. Esta actividad incluye la asignación, refinamiento y verificación de cada componente del producto. También incluye la coordinación de los trabajos de desarrollo del componente del producto.

44.  SP 2: Desarrollar la documentación de apoyo del producto

Práctica: "Desarrollar y mantener la documentación de utilización final".

            Esta práctica específica desarrolla y mantiene la documentación que será usada para instalar, operar y mantener el producto.

Integración de Productos

El propósito de PI es ensamblar las componentes del producto para obtener el producto, asegurar que el producto – según la integración que se hizo – funciona correctamente, y liberar el producto al  cliente.

            PI involucra tanto:

•           Integración del producto: Integración para el producto final.

•           Integración de las componentes del producto: Integración de componentes para producir componentes más complejas.

            El ámbito de PI es alcanzar la integración del producto completo a través del ensamble de progresivas componentes, en uno o más pasos, de acuerdo a la secuencia de integración definida y los procedimientos.  Se usa el término Integración de Productos para también referirse a la Integración de Servicios.

SG 1: Preparación para la Integración del producto

Objetivo: "Preparación para la integración del producto es conducida"

            Preparar la integración de los componentes del producto incluye establecer y mantener:

•           Una secuencia de integración del producto y de las componentes del producto.

•           El ambiente para realizar la integración del producto y de las componentes del producto.

•           Procedimientos y criterios para la integración del producto y de las componentes del producto.

            La preparación para la integración comienza al inicio del proyecto y la secuencia de integración es desarrollada al mismo tiempo con las prácticas del área de proceso de Solución Técnica.

45.  SP 1: Determinar la Secuencia de Integración

Práctica: "Determinar la secuencia de integración de componentes del producto" 

            Las componentes del producto son analizadas para su integración.  Se define un conjunto de secuencias posibles para integrar las componentes y se elige la mejor secuencia posible.

46.  SP 2: Establecer el Ambiente de Integración del Producto

Práctica: "Establecer y mantener el ambiente necesario para apoyar la integración de las componentes del producto".

            El ambiente para la integración de producto puede ser adquirido o desarrollado. Para establecer un ambiente, requerimientos para la compra o desarrollo de equipamientos, software u otros recursos necesitarán ser desarrollados.  El ambiente requerido en cada paso del proceso de integración de producto puede incluir equipos para realizar pruebas, simuladores (tomando el lugar de componentes de productos no disponibles), piezas de equipos reales y dispositivos de almacenamiento.

47.  SP 3: Establecer Procedimientos y Criterios de Integración del Producto

Práctica: "Establecer y mantener procedimientos y criterios para la Integración de las componentes del producto".

            Los procedimientos para la integración de las componentes del producto pueden incluir cosas como el número de iteraciones incrementales que se realizan y detalles de las evaluaciones   que serán llevadas a cabo en cada etapa.

            Los criterios pueden indicar si la componente del producto esta o no preparada para su integración o su grado de aceptación.

            Los procedimientos y criterios para la integración del producto dirigen lo siguiente: Nivel de prueba para construir componentes, Verificación de interfaces, Umbrales de desviación de ejecución, Requerimientos derivados para el ensamble y sus interfaces externas, Sustituciones permitidas de componentes, Parámetros del ambiente de prueba, Limites en los costos de prueba, Equilibrio calidad/costos para operaciones de integración, Probabilidad del funcionamiento apropiado, Tasas de entrega y sus variaciones, Tiempo de entrega desde el pedido hasta la entrega, Disponibilidad de personal y Disponibilidad de la facilidad/línea/ambiente de integración.

            Los criterios pueden ser definidos por cómo las componentes del producto están para ser verificados y las funciones que se espera que ellas tengan. Los criterios pueden ser definidos por cómo las componentes ensambladas del producto y el producto integrado final son validados y liberados. Los criterios también pueden restringir el grado de simulación permitidos para que las componentes puedan pasar una prueba, o pueden restringir el ambiente para ser usado en el test de integración.

SG 2: Asegurar la compatibilidad de interfaces

Objetivo: "Las interfaces de las componentes del producto, internas y externas, son compatibles".

            Muchos problemas de integración de productos surgen por aspectos no conocidos o no controlados de interfaces internas y externas a cada componente. La administración efectiva de requerimientos de interfaces de componentes de productos, especificaciones y diseños, ayudan a asegurar que las interfaces implementadas serán compatibles y completas.

48.  SP 1: Revisar Descripción de Interfaces para Completitud

Práctica: "Revisar descripciones de interfaces para su cobertura y completitud".

            Las interfaces deben incluir, además de las interfaces de los componentes del producto, todas las interfaces con el ambiente de integración del producto.

49.  SP 2: Gestionar Interfaces

Práctica: "Gestionar definiciones de interfaces internas y externas, diseños, y cambios en productos y componentes del producto".

            Los requerimientos de interfaz manejan el desarrollo de las interfaces necesarias para integrar las componentes del producto. Gestionar interfases del producto y componentes del producto comienza tempranamente en el desarrollo del producto. Las definiciones y el diseño para interfaces afecta, no solamente a los componentes de producto y sistemas externos, sino que también puede afectar la validación y verificación de ambientes.

            La gestión de interfaces incluye la mantención de la consistencia de las interfaces durante todo el ciclo de vida del producto, y resolución de conflictos, disconformidades, y cambios en temas.  La gestión de interfaces entre productos adquiridos desde proveedores y otros productos o componentes de productos son críticas para el éxito del proyecto.

            Las interfaces deben incluir, además de  las interfaces de las componentes del producto, todas las interfaces con el ambiente, así como con otros  como ambientes para verificación, validación, operaciones y soporte.  Los cambios en la interfase son documentados, mantenidos y fácilmente accesibles.

SG 3: Ensamblar las componentes del producto y liberar el producto

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

            La integración de las componentes del producto se hace de acuerdo a la secuencia de integración del producto y los procedimientos disponibles. Antes de la integración, cada componente del producto es verificada de acuerdo a los requerimientos de interfaz establecidos. Las componentes del producto son ensambladas en componentes  más complejas y grandes.  Estas componentes ensambladas son chequeadas para su correcta interoperación. Este proceso continúa hasta que la integración del producto es completada. Si durante este proceso se identifican problemas estos deben ser documentados y un proceso de acciones correctivas es iniciado.

50.  SP 1: Confirmar Componentes para Integración preparados

Práctica: "Confirmar, previo al ensamble, que cada componente del producto requerido para ensamblar el producto ha sido debidamente identificado,  funciones corresponden a su descripción y  las interfaces de las componentes del producto cumplen con las descripciones de las interfaces".

            El propósito de esta práctica específica es asegurar que las componentes del producto adecuadamente identificadas que cumplen con su descripción puedan ser realmente ensambladas de acuerdo a la secuencia de integración del producto y procedimientos disponibles. También la consistencia entre las componentes de producto y descripciones de interfase son chequeadas.

            Quienes conducen la integración del producto son los responsables en última instancia de chequear para asegurarse que todo está correcto y así continuar con el ensamble.

51.  SP 2: Ensamblar las componentes del producto

Práctica: "Ensamblar las componentes del producto de acuerdo a la secuencia de integración y procedimientos disponibles".

            Las actividades de ensamblaje de esta práctica específica y las actividades de evaluación de la próxima son conducidas en forma iterativa, desde los componentes iniciales del producto, a través de los componentes ensamblados provisorios, hasta el producto como un todo.

52.  SP 3: Evaluar Componentes del Producto ensambladas

Práctica: "Evaluar componentes de producto ensamblados para la compatibilidad de interfase".

            Esta evaluación involucra examinar y probar las componentes del producto ensambladas para su realización, conveniencia o preparación usando los procedimientos y ambiente disponibles. Esto es realizado para los diferentes pasos del ensamble según lo dispuesto por la secuencia de integración y procedimientos disponibles. La secuencia de integración del producto y procedimientos disponibles, el número de componentes, y la complejidad del producto podrían definir una secuencia de integración y evaluación más refinada.

53.  SP 4: Empaquetar y Entregar Productos o Componentes del Producto

Práctica: "Empaquetar el producto ensamblado o componente del producto  y entregarlo al cliente apropiado".

            Los requerimientos de empaque para algunos productos pueden ser dirigidos según sus especificaciones y criterios de verificación. Esto es especialmente importante cuando los ítems son registrados y transportados por los clientes. En tales casos, pudiese haber condiciones de estrés y ambiente especificadas para el paquete. En otras circunstancias economía y requerimientos de transporte, responsabilidad, y facilidad y seguridad del desempaque son factores importantes.

Verificación

El propósito de Verificación (VER) es asegurar que los artefactos cumplen con los requerimientos especificados.

            VER involucra la verificación del producto o servicios y artefactos intermedios con respecto a los requerimientos seleccionados, incluyendo requerimientos del cliente, del producto o servicio y componentes del producto o servicio. VER es un proceso incremental porque se aplica al desarrollo del producto y artefactos, comenzando con la verificación de los requerimientos, pasando por la verificación de artefactos y terminando con la verificación del producto completo.

            VER y VAL son similares pero tienen diferencias. VAL demuestra que el producto que se entregará satisface su uso entendido, mientras que VER se enfoca en que los artefactos reflejen los requerimientos especificados. En otras palabras, VER asegura que algo se construye correctamente, mientras que VAL asegura que se construye algo correcto.

SG 1: Preparar la verificación

Objetivo:   "La preparación de la verificación es conducida".

            Una preparación es necesaria para asegurar que los requerimientos de verificación están incluidos en los requerimientos del producto y las componentes del producto, diseños, planes de desarrollo y programas. La verificación incluye selección, inspección, prueba, análisis y demostración de artefactos.

            Los métodos de verificación incluyen, pero no están limitados a ellos, inspecciones, revisiones de pares, auditorias, inspecciones, análisis, simulaciones, pruebas y demostraciones.

            La preparación también supone la definición de herramientas de apoyo, equipamientos para pruebas y software, simulaciones, prototipos y facilidades.

54.  SP 1: Seleccionar artefactos para Verificación

Práctica: "Seleccionar artefactos a ser verificados y métodos de verificación que serán usados para cada uno de ellos".

            Los artefactos son seleccionados basándose en su contribución para alcanzar los objetivos y requerimientos del proyecto, y para dirigir los riesgos del proyecto.

            Los artefactos que serán verificados pueden incluir aquellos asociados con la mantención, entrenamiento y servicios de apoyo. Los métodos de verificación dirigen el enfoque técnico de la verificación de artefactos y los procedimientos específicos que serán usados para verificar que los productos de trabajo específicos cumplan sus requerimientos.

            La selección de los métodos de verificación comienza típicamente con la participación en la definición de los requerimientos del producto o componentes del producto para asegurar que estos requerimientos son verificables.

55.  SP 2: Establecer el ambiente de Verificación

Práctica: "Establecer y mantener el ambiente necesario para apoyar la verificación".

            Un ambiente debe ser establecido para permitir que la verificación tome lugar. El ambiente de verificación puede ser adquirido, desarrollado, reutilizado, modificado, o una combinación de estos, dependiendo de las necesidades del proyecto. 

            Cada ambiente requerido va a depender de los artefactos seleccionados para su verificación y los métodos de verificación usados.

56.  SP 3: Establecer procedimientos y criterios de verificación

Práctica: "Establecer y mantener procedimientos y criterios de verificación para los artefactos seleccionados"

            Los criterios de verificación son definidos para asegurar que los artefactos cumplan con sus requerimientos.

SG 2: Realizar Revisión de Pares

Objetivo: "Revisiones de pares son desarrolladas sobre artefactos seleccionados".

            La revisión de pares es un análisis metodológico de artefactos realizado por los productores o desarrolladores pares  para identificar defectos a ser removidos y recomendar otros cambios según sean  necesarios.

            La revisión de pares es un método de ingeniería importante y efectivo implementado vía inspecciones u otros métodos de revisión.

57.  SP 1: Preparar la revisión de pares

Práctica: "Preparar para la revisión de pares de artefactos seleccionados".

            Actividades de preparación  para la revisión de pares típicamente incluyen identificar el personal que será invitado a participar en la revisión de pares de cada artefacto; identificar los revisores claves que deben participar en la revisión de pares; preparar y actualizar cualquier material que será usado durante la revisión de pares.

58.  SP 2: Conducir la revisión de pares

Práctica: "Conducir la revisión de pares sobre artefactos seleccionados e identificar defectos resultantes de la revisión de pares".

            Uno de los propósitos de conducir la revisión de pares es encontrar y remover tempranamente defectos. La revisión de pares es realizada incrementalmente tal como los artefactos estén siendo desarrollados. Estas revisiones son estructuradas y no son revisiones administrativas.

            La revisión de pares puede ser realizada en cualquier tipo de artefacto.  Cuando surgen defectos de la revisión de pares, estos deben ser comunicados al desarrollador principal del artefacto para su corrección.

            La revisión de pares debe dirigir lo siguiente: Debe haber la preparación suficiente, la conducción debe ser administrada y controlada, datos consistentes y suficientes deben ser registrados, y puntos de acción deben ser registrados. 

59.  SP 3: Analizar los datos de la revisión de pares

Práctica: "Analizar datos acerca de la preparación, conducción y resultados de la revisión de pares".

Analizar datos acerca de la preparación, conducción y resultados de la revisión de pares.

SG 3: Verificar Artefactos Seleccionados

Objetivo: "Los artefactos son verificados contra sus requerimientos específicos".

            Los métodos, procedimientos y criterios de evaluación son usados para verificar que el artefacto seleccionado y cualquier mantención asociada, entrenamiento y servicios de soporte usan el ambiente de verificación apropiado. Actividades de verificación deben ser realizadas durante todo el ciclo de vida del producto.

60.  SP 1: Realizar la verificación

Práctica: "Realizar verificación de los artefactos seleccionados".

            Verificar incrementalmente productos y artefactos promueve la detección temprana de problemas y puede resultar en la remoción temprana de defectos. Los resultados de la verificación ahorran costos considerables de fallas aisladas y trabajo repetido asociado a la resolución de problemas.

61.  SP 2: Analizar resultados de verificación identificando acciones correctivas

Práctica: "Analizar los resultados de todas las actividades de verificación".

            Los resultados actuales deben ser comparados con los criterios de verificación establecidos para determinar la aceptabilidad.

            Los resultados del análisis son registrados como evidencia de que la verificación fue realizada.

            Para cada artefacto, todos los resultados de verificación son analizados incrementalmente para asegurar que los requerimientos hayan sido cumplidos.  Dado que la revisión de pares es uno de varios métodos de verificación, los datos de revisión de pares deben ser incluidos en esta actividad de análisis para asegurar que los resultados de la verificación son suficientemente analizados.

Validación

El propósito de Validación (VAL) es demostrar que un producto o componentes del producto cumplen su uso planeado cuando es ubicado en su planeado ambiente.

            Actividades de validación pueden ser aplicadas a todos los aspectos del producto en cualquiera de sus ambientes planeados, tal como operación, entrenamiento, manufactura, mantención, y servicios de soporte,  Los métodos empleados para conseguir la validación pueden ser aplicados a artefactos así como también a productos o servicios y componentes del producto o servicios.

SG 1: Preparar la validación

Objetivo: "La preparación para la validación es conducida".

            Actividades de preparación incluyen la selección de productos y los componentes del producto para validación, y establecer y mantener el ambiente, procedimientos y criterios de validación. Los artefactos seleccionados para validación pueden incluir sólo el producto o puede incluir niveles apropiados de las componentes del producto que son usados para construir el producto.  El ambiente de Integración de Productos, Verificación y Validación puede ser el mismo.

62.  SP 1: Seleccionar Productos para la validación

Práctica: "Seleccionar productos y componentes de productos a ser validados y los métodos de validación que serán usados para cada uno".

            Productos y componentes de productos son seleccionados para validación sobre la base de sus relaciones con las necesidades del usuario. Para cada componente de producto, el alcance de la validación (comportamiento operacional, mantención, entrenamiento e interfase de usuario) debería ser determinado.

            Los requerimientos y restricciones para realizar la validación son recopilados. Entonces, los métodos de validación son seleccionados basándose en su capacidad para demostrar que las necesidades de los usuarios están satisfechas. Los métodos de validación no sólo definen el enfoque técnico de la validación del producto, sino también dirige las necesidades para los equipos a utilizar y ambientes de validación. Requerimientos derivados, como requerimientos de interfaces para hacer pruebas y equipamientos, pueden ser generados.

            Los métodos de validación deben ser seleccionados tempranamente en la vida del proyecto para que sean claramente entendidos y acordados con las partes interesadas.

            Los métodos de validación dirigen el desarrollo, mantención, soporte y entrenamiento para el producto o las componentes del producto según sea apropiado.

63.  SP 2: Establecer el ambiente para la validación

Práctica: "Establecer y mantener el ambiente necesario para apoyar la validación".

            Los requerimientos para el ambiente de validación son manejados por el producto o las componentes de productos seleccionadas, por el tipo de artefacto (por ejemplo, diseño, prototipo, versión final) y por los métodos de validación. Esto podría producir requerimientos para la compra o desarrollo de equipamiento, software u otros recursos. El entorno de validación puede incluir la reutilización de recursos existentes. En este caso, se deben hacer arreglos para el uso de estos recursos. Ejemplos de tipos de elementos en un ambiente de validación incluyen lo siguiente:

-           Herramientas de prueba interconectadas con el producto que esta siendo validado.

-           Software para prueba.

-           Subsistemas simulados o componentes.

-           Sistemas simulados.

-           Sistemas reales.

-           Facilidades y productos provistos por el cliente.

-           Las personas hábiles para operar o usar todos los elementos precedentes.

-           Ambiente de prueba con computador dedicado o sistema distribuido. 

64.  SP 3: Establecer Procedimientos y Criterios de Validación

Práctica: "Establecer y mantener procedimientos y criterios de validación"

            Procedimientos y criterios de validación son definidos para asegurar que el producto o las componentes del producto van a satisfacer su uso planificado cuando es ubicado en su ambiente planificado. La aceptación de casos de pruebas y procedimientos pueden satisfacer la necesidad de procedimientos de validación.

            Los procedimientos y criterios de validación incluyen pruebas y evaluaciones de mantenimiento, entrenamiento y servicios de soporte.

SG 2: Validar Productos o Componentes del Producto

Objetivo: "El producto o las componentes del producto son validados para asegurar que son aptas para su uso en su ambiente operacional previsto".

            Los métodos, procedimientos y criterios de validación son usados para validar los productos y las componentes de los  productos seleccionados y cualquier mantenimiento, entrenamiento y servicios de apoyo asociado usando el apropiado ambiente de validación. Actividades de validación son realizadas durante todo el ciclo de vida del producto.

65.  SP 1: Realizar la validación

Práctica: "Realizar la validación sobre los productos y las componentes del producto seleccionados".

            Para que sea aceptable para los usuarios, un producto o componente del producto debe realizarse como es esperado en su ambiente operacional planificado.

            Las actividades de validación son realizadas y los datos resultantes son recogidos de acuerdo a los métodos, procedimientos y criterios establecidos.

            Los procedimientos de validación sobre la marcha deben ser documentados y las desviaciones que ocurran durante la ejecución deben ser atendidas, según sea apropiado.

66.  SP 2: Analizar los resultados de la validación

Práctica:"Analizar los resultados de las actividades de validación".

            Los datos resultantes de las pruebas de validación, inspecciones, demostraciones o evaluaciones son analizadas contra los criterios de validación definidos. Los informes de análisis indican si las necesidades fueron satisfechas; en el caso de las deficiencias, estos documentos informan el grado de éxito o fracaso y categorizan las probables causas de fracaso. Las pruebas recolectadas, inspecciones o resultados revisados son comparados con los criterios de evaluación establecidos para determinar si avanzar o enfocarse en los requerimientos que están bajo cuestión.

            Analizar informes o documentación de validación sobre la marcha también puede indicar que los malos resultados de las pruebas son debido a problemas en los procedimientos de validación o un problema en el ambiente de validación.

Proceso de Desarrollo de Software de ORDEN Integración

Introducción

ORDEN Integración es una organización tecnológica chilena perteneciente al consorcio de Sonda S.A. cuya misión es la de aportar con soluciones informáticas precisas, de calidad, en forma oportuna y a un precio justo al progreso y desarrollo de sus clientes. Cuenta con más de 25 años de experiencia tanto a nivel nacional como internacional y su visión es la de ser una empresa global, con capacidad de aprendizaje, leal a sus principios y de creciente competitividad, por lo cual su inversión y proceso de transformación es constante[2]. Es considerada la fábrica de software de Sonda S.A., ya que es aquí donde se realizan la mayoría de los desarrollos de software a medida. Algunos sus clientes son: Hospital Universitario Austral de Buenos Aires, Poder Judicial, FONASA, Cámara de Comercio de Santiago, METRO Santiago, Dirección General de Aeronáutica Civil, Registro Civil, Contraloría General de la República, entre otros. Dado que estos y sus demás clientes son instituciones de prestigio nacional, la calidad de los productos y servicios ofrecidos deben poder estar de alguna manera garantizada; esto como parte de la estrategia de calidad definida por la organización. Es por ello que el 2005 ORDEN recibió la certificación de calidad del ya obsoleto modelo CMM nivel 2 y actualmente ha iniciado el proceso de acreditación de CMMI nivel 3, lo que va a implicar que no sólo la organización cuente con una metodología propia, con un proceso de desarrollo de software bien definido de acuerdo a su propia forma de hacer negocio, sino que se ponga énfasis en la ingeniería de la metodología, lo cual sumado a los procesos de gestión y apoyo se conforme una estructura completa de todo el ciclo productivo de desarrollo de proyectos software. Sin embargo el objetivo principal que persigue tanto el modelo como la organización es que la metodología sea conocida formalmente y bien utilizada por todos los miembros de ORDEN, cambiando para mejor la forma de trabajar de cada una de estas personas, no con el propósito de obligar a la gente a realizar sus actividades cotidianas de una manera determinada, sino para mejorar el orden, la comunicación, la responsabilidad y finalmente la productividad de todos. De esta forma se lograría institucionalizar la metodología y madurar como organización.

            Como se acaba de mencionar, ORDEN Integración actualmente se encuentra trabajando junto con la empresa chilena América XXI en la mejora de sus procesos de negocio con el objetivo de certificarse bajo CMMI Nivel 3 para los primeros meses del siguiente año. Es por ello que han decidido enfocarse en los componentes esperados – prácticas específicas y genéricas – para  cumplir con los componentes requeridos – objetivos específicos y genéricos – de este nivel de madurez del modelo en su versión 1.2. Para alcanzar tal certificación ORDEN integración se encuentra por un lado redefiniendo algunos de sus procesos de acuerdo al modelo para luego ser publicados a la organización, mientras que por otro lado aquellos los procesos que ya fueron redefinidos y publicados están en etapa de institucionalización en la organización.

            Los procesos de ORDEN Integración están divididos en dos grandes áreas. La primera corresponde a los Procesos de Administración de Proyectos e Ingeniería de Software y la segunda a los Procesos de la Administración General de la Fábrica de Software. Dentro del área de Procesos de Administración de Proyectos e Ingeniería de Software se encuentran una serie de subáreas que en conjunto son las encargadas de desarrollar y apoyar un proyecto en particular siguiendo su ciclo de vida por completo. Estas subáreas incluyen: Procesos Organizacionales (capacitaciones, métricas), Procesos de Administración de Proyecto (planificación, control y seguimiento, riesgos), Procesos de Ingeniería de Software (requerimientos, análisis y diseño, construcción, pruebas y despliegue) y Procesos de Soporte (administración de la configuración, aseguramiento de la calidad). Dentro del área de Procesos de la Administración General de la Fábrica de Software se encuentran todos los procesos que no participan directamente del desarrollo de un proyecto, pero que son vitales para el funcionamiento interno de la organización: Planificación y Control Estratégico (presupuesto anual), Procesos de Cierre Mensual de Actividades, Evaluación y Preparación de Propuestas, Administración de Personal y Administración de Proveedores y Alianzas Estratégicas.

            Como se mencionó anteriormente, es dentro del área de Procesos de Administración de Proyectos e Ingeniería de Software donde efectivamente los proyectos son desarrollados de inicio a fin. En la subárea de Procesos de Ingeniería de Software se encuentra alojado el Proceso de desarrollo de software de ORDEN Integración, que será presentado en detalle en este documento.

            El proceso o metodología de desarrollo de software de ORDEN Integración está basado en un modelo iterativo – incremental inspirado en el proceso de desarrollo unificado RUP (Rational Unified Process, [Jac99]) desarrollado por Rational y perteneciente actualmente a IBM. Se dice que está inspirado en RUP ya que está acomodado de acuerdo a la experiencia de la organización en el desarrollo de proyectos de ingeniería de software de acuerdo al conocimiento por parte de sus creadores sobre la metodología RUP y en parte también por el conocimiento de estos sobre el modelo de calidad CMMI.  La metodología consta de tres fases instauradas por ORDEN Integración: Fase de Inicio, Fase de Elaboración – Construcción y Fase de Transición. Estas fases son análogas a las fases de la metodología RUP. La Fase de Elaboración – Construcción se presenta como una sola fase en los modelos debido a que presenta más ítems en común que diferentes, pero como metodología de desarrollo es tratada en fases diferentes al igual que en el RUP, por lo cual implícitamente se puede decir que la metodología de ORDEN Integración se realiza en cuatro fases. En cada una de estas se desarrollan seis disciplinas de Ingeniería: Describir el Problema de Negocio, Especificar Requerimientos de la Solución, Realizar Análisis y Diseño de la Solución, Desarrollar Solución Sistémica, Asegurar Correctitud y Funcionalidad de la Solución y Desplegar Solución, además de tres procesos transversales y de apoyo a estas disciplinas en cualquiera de las tres fases, los cuales son: Administración de Requerimientos, Revisión de Pares y Pruebas de Software.

            En este documento se describirán las tres fases separadamente mediante un diagrama UML, describiendo las disciplinas presentes en cada fase, los procesos, actividades a realizar, entradas y artefactos generados para cada una de ellas. En los casos de las disciplinas de la fase que requieran de análisis adicional por su complejidad, se detallará su comportamiento en un diagrama de actividades realizando la descripción respectiva. Las líneas de color negro corresponden al flujo de actividades que se realizan en la disciplina y las de color azul al flujo de artefactos utilizados o generados en la misma. Además se describirán los artefactos utilizados y generados en el proceso de desarrollo, además de los actores responsables de cada uno de ellos y finalmente de describirán los tres procesos de apoyo a las disciplinas ya mencionados.

 Fase de Inicio

Es la fase que da por iniciado un proyecto. Durante esta fase se debe establecer el caso de negocio para el sistema y se debe delimitar el alcance del proyecto. El diagrama de la Figura 5 es el que modela esta fase y la disciplina resaltada en gris tiene un diagrama de actividades adicional debido a su complejidad.

Figura 5: Fase de Inicio

Figura 6: Especificar Requerimientos de la solución