Realización de Alternativas
Alternativamente el área de Proceso se llama: Solución Técnica
Fuente: 2009, CMMI®, Guía para la integración de procesos y la mejora de productos, Segunda edición, Mary Beth Chrissis, Mike Konrad y Sandy Shrum.
La Solución Técnica (TS) tiene como propósito diseñar, desarrollar e implementar soluciones a requerimientos organizados en caso de uso (en nuestro caso), se:
- Aplica a cualquier nivel de la arquitectura del producto, a cada producto y a cada componente de producto y proceso relacionado con el ciclo de vida del producto.
- Se relaciona con procesos del ciclo de vida del producto. Estos procesos se desarrollan conjuntamente con el producto y los componentes del producto.
- El desarrollo puede incluir la selección o adaptación de procesos existentes (procesos estándares) o el desarrollo de nuevos procesos.
Las metas específicas (SG) del área del Proceso TS son:
1. SG 1: Seleccionar soluciones para los componentes del producto.
- Soluciones alternativas y sus ventajas relativas deben considerarse antes de seleccionar una solución.
- Requerimientos claves, aspectos de diseño y restricciones deben establecerse para utilizarse en el análisis de soluciones alternativas.
- Las características de la arquitectura proveen una base para la mejora y evolución del producto son consideradas.
- El uso de componentes de producto tipo COTS (Commercial Off The Shelf) deben considerarse en relación con costos, cronograma, rendimiento y riesgos. Las alternativas COTS pueden usarse con o sin adaptaciones.
- Algunas veces, dichos elementos requieren modificaciones de interfaces o personalización de características para cumplir los requerimientos del producto.
- Un indicador de buen proceso de diseño, es su selección después de compararlo y evaluarlo con soluciones alternativas. La selección de arquitectura requiere un proceso formal de toma de decisiones.
- Generalmente, las soluciones se definen como un todo; al definir la siguiente capa de componentes, la solución para cada uno de los componentes del conjunto debe definirse.
- Las soluciones alternativas no son sólo formas distintas de abordar los mismos requerimientos, sino que deben reflejar el destino diferente de requerimientos entre los componentes del producto que componen el conjunto solución.
- El objetivo es optimizar el conjunto de requerimientos como un todo y no sus partes.
Prácticas Espeíficas (SP):
SP 1: Desarrollar soluciones alternativas y criterios de selección
- Las alternativas de solución deben identificarse y analizarse para seleccionar una solución equilibrada a través del ciclo de vida del producto en términos de costos, cronograma y rendimiento. Estas soluciones se basan en arquitecturas de producto propuestas que abordan características críticas del producto y cubren un conjunto de soluciones factibles.
- Las alternativas de solución comprenden relaciones alternativas de requerimientos a diferentes componentes del producto. Dichas alternativas pueden incluir el uso de soluciones COTS en la arquitectura del producto.
- Las alternativas de solución cubren el rango aceptable de costo, cronograma y rendimiento (desempeño). Los requerimientos de componentes del producto son recibidos y utilizados junto con problemas de diseño, restricciones, y criterios para desarrollar soluciones alternativas.
- Los criterios de selección abordarán típicamente costos (tiempo, recursos humanos y otros gastos) y riesgos (técnicos, de costo y cronograma).
- Los aspectos a considerar en las alternativas de solución y criterios de selección incluyen:
. Costo de desarrollo, construcción, adquisición, mantenimiento, soporte, etc.
. Rendimiento.
. Complejidad de componentes del producto y de procesos respecto al ciclo de vida.
. Robustez del producto en operación y condiciones de uso, modos de operación, ambientes y variaciones de los procesos relacionados con el ciclo de vida del producto.
. Expansión y crecimiento del producto.
. Limitantes de la tecnología.
. Sensibilidad a los métodos y materiales de construcción.
. Riesgos.
. Evolución de requerimientos y tecnología.
. Dada de baja (eliminación) del producto.
. Capacidades y limitantes de usuarios finales y operadores.
. Características de productos tipo COTS.
Prácticas Espeíficas (SP):
SP 1: Desarrollar soluciones alternativas y criterios de selección
- Las alternativas de solución deben identificarse y analizarse para seleccionar una solución equilibrada a través del ciclo de vida del producto en términos de costos, cronograma y rendimiento. Estas soluciones se basan en arquitecturas de producto propuestas que abordan características críticas del producto y cubren un conjunto de soluciones factibles.
- Las alternativas de solución comprenden relaciones alternativas de requerimientos a diferentes componentes del producto. Dichas alternativas pueden incluir el uso de soluciones COTS en la arquitectura del producto.
- Las alternativas de solución cubren el rango aceptable de costo, cronograma y rendimiento (desempeño). Los requerimientos de componentes del producto son recibidos y utilizados junto con problemas de diseño, restricciones, y criterios para desarrollar soluciones alternativas.
- Los criterios de selección abordarán típicamente costos (tiempo, recursos humanos y otros gastos) y riesgos (técnicos, de costo y cronograma).
- Los aspectos a considerar en las alternativas de solución y criterios de selección incluyen:
. Costo de desarrollo, construcción, adquisición, mantenimiento, soporte, etc.
. Rendimiento.
. Complejidad de componentes del producto y de procesos respecto al ciclo de vida.
. Robustez del producto en operación y condiciones de uso, modos de operación, ambientes y variaciones de los procesos relacionados con el ciclo de vida del producto.
. Expansión y crecimiento del producto.
. Limitantes de la tecnología.
. Sensibilidad a los métodos y materiales de construcción.
. Riesgos.
. Evolución de requerimientos y tecnología.
. Dada de baja (eliminación) del producto.
. Capacidades y limitantes de usuarios finales y operadores.
. Características de productos tipo COTS.
- Las organizaciones debieran hacer proyecciones para acortar la lista de alternativas para que sean consistentes con sus objetivos de negocio.
- Los costos de ciclo de vida del producto pueden estar fuera del control de las organizaciones de desarrollo aunque sea un parámetro atractivo para minimizar costos.
- Un cliente puede no estar dispuesto a pagar por funciones que cuestan más en el corto plazo pero que en última instancia disminuyen el costo durante la vida útil del producto. En tales casos, los clientes deben estar informados de las posibilidades de reducir los costos durante la vida útil de un producto.
- Los criterios utilizados para seleccionar las soluciones finales deben proveer un enfoque equilibrado de costos, beneficios y riesgos.
SP 2: Seleccionar soluciones para componentes del producto
Práctica: "Seleccionar los componentes del producto que mejor satisfagan los criterios establecidos".
- Elegir soluciones para componentes del producto que mejor satisfagan los criterios establecidos.
- Los requerimientos de más bajo nivel deben generarse a partir de la alternativa seleccionada. Se utilizan para desarrollar el diseño de los componentes de producto.
- Los requerimientos de interfaz entre componentes de producto se describen funcionalmente al inicio. Las descripciones de interfaz física deben incluirse en la documentación de interfaces hacia elementos y actividades externas al producto
- La descripción de soluciones y los fundamentos de la selección deben documentarse. La documentación evoluciona a medida que las soluciones y los diseños se detallan, desarrollan e implementan.
- El mantenimiento de un registro de fundamentos es crítico para la toma de decisiones.
- Los costos de ciclo de vida del producto pueden estar fuera del control de las organizaciones de desarrollo aunque sea un parámetro atractivo para minimizar costos.
- Un cliente puede no estar dispuesto a pagar por funciones que cuestan más en el corto plazo pero que en última instancia disminuyen el costo durante la vida útil del producto. En tales casos, los clientes deben estar informados de las posibilidades de reducir los costos durante la vida útil de un producto.
- Los criterios utilizados para seleccionar las soluciones finales deben proveer un enfoque equilibrado de costos, beneficios y riesgos.
SP 2: Seleccionar soluciones para componentes del producto
Práctica: "Seleccionar los componentes del producto que mejor satisfagan los criterios establecidos".
- Elegir soluciones para componentes del producto que mejor satisfagan los criterios establecidos.
- Los requerimientos de más bajo nivel deben generarse a partir de la alternativa seleccionada. Se utilizan para desarrollar el diseño de los componentes de producto.
- Los requerimientos de interfaz entre componentes de producto se describen funcionalmente al inicio. Las descripciones de interfaz física deben incluirse en la documentación de interfaces hacia elementos y actividades externas al producto
- La descripción de soluciones y los fundamentos de la selección deben documentarse. La documentación evoluciona a medida que las soluciones y los diseños se detallan, desarrollan e implementan.
- El mantenimiento de un registro de fundamentos es crítico para la toma de decisiones.
2. SG 2: Desarrollar el diseño.
Objetivo: "Diseños del producto y componentes del producto son desarrolladas"
- Diseños de productos o componentes de productos deben proveer el contenido apropiado no sólo para la implementación, sino también para otras fases del ciclo de vida del producto tales como modificación, adquisición, mantenimiento e instalación.
- La documentación de diseño provee una referencia para apoyar el entendimiento mutuo del diseño por parte de las partes interesadas y así apoyar futuros cambios al diseño ya sea durante el desarrollo como en las fases siguientes del ciclo de vida del producto.
- Una descripción completa del diseño es documentada incluyendo una completa gama de características y parámetros incluyendo forma, ajuste, función, interfaz, características del proceso de construcción y otros parámetros. Estándares establecidos de diseño de proyecto u organizacionales (listas, plantillas, estructura de objetos) forman la base para alcanzar un alto grado de definición y completitud en la documentación del diseño.
SP 1: Diseñar el producto o los componentes del producto
Práctica: "Desarrollar un diseño para el producto o componente del producto".
- El diseño del producto tiene dos extensas fases que pueden superponerse en ejecución: diseño preliminar y diseño detallado.
- El diseño preliminar establece las capacidades y la arquitectura del producto, incluyendo divisiones del producto, identificación de los componentes del producto, estados de sistemas y modos, interfaces principales e interfaces externas del producto.
- El diseño detallado define completamente la estructura y las capacidades de los componentes del producto.
- La definición de la arquitectura es guiada a partir de un conjunto de requisitos de arquitectura. Estos requerimientos expresan los elementos de calidad y rendimiento que son críticos para el éxito del producto.
- La arquitectura define los elementos estructurales y los mecanismos de coordinación que directamente satisfacen los requerimientos o apoyan su realización a medida que se establecen los detalles del diseño del producto.
- Las arquitecturas pueden incluir estándares y reglas de diseño que dirigen el desarrollo de los componentes del producto y sus interfaces, así como una guía para ayudar a sus desarrolladores.
- Los arquitectos postulan y desarrollan un modelo del producto, haciendo juicios sobre la asociación de requerimientos con los componentes del producto, incluyendo hardware y software. Múltiples arquitecturas que apoyan las soluciones alternativas pueden ser desarrolladas y analizadas para determinar las ventajas y desventajas en el contexto de los requerimientos de arquitectura.
- Los conceptos operacionales y escenarios son usados para generar casos de uso y escenarios de calidad que se usan para refinar la arquitectura. También son usados como un medio para evaluar qué tan apropiada es la arquitectura para el propósito previsto durante las evaluaciones, las cuales son realizadas periódicamente durante todo el diseño del producto.
- Durante el diseño detallado, los detalles de la arquitectura del producto son finalizados, los componentes del producto son definidos completamente y las interfaces son descritas en su totalidad. Los diseños de los componentes de productos pueden ser optimizados para ciertas características de rendimiento o calidad. A medida que el diseño madura, los requerimientos asignados a componentes de productos de más bajo nivel son monitoreados para asegurar que esos requerimientos son satisfechos.
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 se desarrolla. 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.
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.
SP 4: Ejecutar Análisis de: Hacer, Comprar o Reutilizar
Práctica: “Evaluar si los componentes del producto deben ser desarrollados, comprados o reutilizados basándose en los criterios establecidos”.
- Determinar qué producto o componentes del producto se adquieren refiere a “make-or-buy analysis” (análisis de hacer-o-comprar). Este análisis se basa en las necesidades del proyecto; comienza tempranamente durante la primera iteración de diseño, continúa en 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.
3. 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.
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.
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.
La secuencia sigue con la Integración del Producto.
Objetivo: "Diseños del producto y componentes del producto son desarrolladas"
- Diseños de productos o componentes de productos deben proveer el contenido apropiado no sólo para la implementación, sino también para otras fases del ciclo de vida del producto tales como modificación, adquisición, mantenimiento e instalación.
- La documentación de diseño provee una referencia para apoyar el entendimiento mutuo del diseño por parte de las partes interesadas y así apoyar futuros cambios al diseño ya sea durante el desarrollo como en las fases siguientes del ciclo de vida del producto.
- Una descripción completa del diseño es documentada incluyendo una completa gama de características y parámetros incluyendo forma, ajuste, función, interfaz, características del proceso de construcción y otros parámetros. Estándares establecidos de diseño de proyecto u organizacionales (listas, plantillas, estructura de objetos) forman la base para alcanzar un alto grado de definición y completitud en la documentación del diseño.
SP 1: Diseñar el producto o los componentes del producto
Práctica: "Desarrollar un diseño para el producto o componente del producto".
- El diseño del producto tiene dos extensas fases que pueden superponerse en ejecución: diseño preliminar y diseño detallado.
- El diseño preliminar establece las capacidades y la arquitectura del producto, incluyendo divisiones del producto, identificación de los componentes del producto, estados de sistemas y modos, interfaces principales e interfaces externas del producto.
- El diseño detallado define completamente la estructura y las capacidades de los componentes del producto.
- La definición de la arquitectura es guiada a partir de un conjunto de requisitos de arquitectura. Estos requerimientos expresan los elementos de calidad y rendimiento que son críticos para el éxito del producto.
- La arquitectura define los elementos estructurales y los mecanismos de coordinación que directamente satisfacen los requerimientos o apoyan su realización a medida que se establecen los detalles del diseño del producto.
- Las arquitecturas pueden incluir estándares y reglas de diseño que dirigen el desarrollo de los componentes del producto y sus interfaces, así como una guía para ayudar a sus desarrolladores.
- Los arquitectos postulan y desarrollan un modelo del producto, haciendo juicios sobre la asociación de requerimientos con los componentes del producto, incluyendo hardware y software. Múltiples arquitecturas que apoyan las soluciones alternativas pueden ser desarrolladas y analizadas para determinar las ventajas y desventajas en el contexto de los requerimientos de arquitectura.
- Los conceptos operacionales y escenarios son usados para generar casos de uso y escenarios de calidad que se usan para refinar la arquitectura. También son usados como un medio para evaluar qué tan apropiada es la arquitectura para el propósito previsto durante las evaluaciones, las cuales son realizadas periódicamente durante todo el diseño del producto.
- Durante el diseño detallado, los detalles de la arquitectura del producto son finalizados, los componentes del producto son definidos completamente y las interfaces son descritas en su totalidad. Los diseños de los componentes de productos pueden ser optimizados para ciertas características de rendimiento o calidad. A medida que el diseño madura, los requerimientos asignados a componentes de productos de más bajo nivel son monitoreados para asegurar que esos requerimientos son satisfechos.
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 se desarrolla. 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.
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.
SP 4: Ejecutar Análisis de: Hacer, Comprar o Reutilizar
Práctica: “Evaluar si los componentes del producto deben ser desarrollados, comprados o reutilizados basándose en los criterios establecidos”.
- Determinar qué producto o componentes del producto se adquieren refiere a “make-or-buy analysis” (análisis de hacer-o-comprar). Este análisis se basa en las necesidades del proyecto; comienza tempranamente durante la primera iteración de diseño, continúa en 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.
3. 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.
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.
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.
La secuencia sigue con la Integración del Producto.
