- 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.
- 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.
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
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. 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.
- Introducción
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
Nombre: Describir el Problema de Negocio
Artefactos de Entrada: Bases de Licitación, Contrato y Anexos.
Artefactos de Salida: Conceptos del Dominio, Proceso de Negocio, Visión del Sistema.
Actores Involucrados: Analistas, Jefe de Proyecto, Stakeholders.
Descripción:
A partir de lo estipulado en las Bases de Licitación, en los Contratos y Anexos y por medio de entrevistas personales se pretende generar la Visión del Sistema que tiene el cliente. Los analistas junto con el Jefe de Proyecto deben identificar los principales Stakeholders del proyecto y recoger sus visiones particulares sobre cómo el nuevo sistema los afectará en su quehacer cotidiano (qué esperan de él y cómo piensan interactuar con él). Se deben además identificar todos los procesos, conceptos y relaciones entre ellos que estarán dentro del dominio del problema del sistema. Para ello lo primero que se debe realizar es obtener una visión general de la empresa cliente, de sus procesos de negocio claves y de sus necesidades y dificultades que presenta en la actualidad. Además de obtener los procesos de negocio, estos se deben analizar identificando sus entradas, salidas, procedimientos internos, actores participantes y el entorno en el que se ejecutan generando de este estudio los Diagramas de Procesos, los cuales identifican cómo el cliente realiza actualmente sus actividades.
Nombre: Especificar Requerimientos de la solución
Artefactos de Entrada: Bases de Licitación, Contrato y Anexos, Concepto de Dominio, Proceso de Negocio, Descripción de la Solución.
Artefactos de Salida: Requerimiento original ofrecido, Requerimiento de Negocio, Criterios de Aceptación, Requerimiento de Sistema, Requerimientos Funcionales, Requerimientos No Funcionales.
Actores Involucrados: Analistas, Jefe de Proyecto, Stakeholders
Descripción (ver Figura 6)
En función de las Bases de Licitación y de reuniones informales con el cliente, se busca encontrar la respuesta a la pregunta ¿qué debe hacer el sistema?
En esta disciplina se deben compatibilizar los deseos del cliente y los alcances contractuales ofrecidos con lo que se puede lograr sistematizar de acuerdo a las capacidades tecnológicas tanto del cliente como de ORDEN Integración. Para ello, se registran aquellos requerimientos planteados directamente por el cliente como Requerimientos de Negocio. Estos conforman la primera forma de requerimientos para el proyecto. Esta lista debe permanecer invariable por el resto del proyecto como registro de las necesidades originales del cliente. Luego se identifican aquellos requerimientos que fueron originalmente ofrecidos en la Descripción de la Solución, desarrollada en la propuesta del proyecto, y en el contrato firmado con el cliente. Sobre los requerimientos originales ofrecidos, se les debe relacionar con aquellos Requerimientos de Negocio a los que estén dando respuesta. En función de estas relaciones se deben identificar aquellos requerimientos de negocio que no estén ofrecidos y aquellos requerimientos ofrecidos que no obedecen a ningún requerimiento de negocio identificado y generar riesgos asociados a estas diferencias. En el caso de Requerimientos de Negocio que no se hayan ofrecido, estos se deben dejar en claro al cliente para lograr un acuerdo en cuanto a que no se debe esperar dicha funcionalidad o a que el tamaño del proyecto ofrecido ha cambiado por lo tanto se debe clasificar como cambio. En el caso de los requerimientos ofrecidos que no responden a ningún Requerimiento de Negocio se deben tener en cuenta que puede que no sean necesarios para el cliente y por lo tanto se pueden descartar previo acuerdo con todas las partes involucradas.
Figura 6: Especificar Requerimientos de la solución
La lista de Requerimientos originales ofrecidos permanece invariable como registro del límite comprometido del sistema. Finalmente se genera una lista definitiva con todos los Requerimientos del Sistema, los cuales deben estar relacionados por lo menos con uno de los requerimientos ofrecidos. Lo que se debe lograr es identificar y acotar los límites de cada requerimiento y los actores involucrados. Los Requerimientos de Sistema deben además estar relacionados con aquellos Procesos de Negocio que van a sistematizar y con aquellos Conceptos de Dominio con los que tendrán que lidiar. Cualquier proceso y concepto que quede sin relacionar con algún requerimiento de sistema se considerará fuera del dominio del sistema y debe quedar apropiadamente registrado.
Como prueba final se debe comprobar que cada uno de los Requerimientos originales ofrecidos que se pretenden implementar esté siendo realizado por un Requerimiento de Sistema y que el 100% de los Requerimientos de Sistema estén dando cumplimiento a por lo menos uno de los Requerimientos originales ofrecidos. Los Requerimientos de Sistema que no estén cumpliendo requerimientos ofrecidos dan cuenta de cambios en el tamaño del sistema que se piensa desarrollar en relación al que se ofreció. Requerimientos originales que no estén siendo realizados por Requerimientos de Sistema dan cuenta de posibles omisiones de funcionalidad comprometida en el sistema a ser desarrollado y que luego podrían ser objetadas por los clientes.
Nombre: Realizar Análisis y Diseño de la Solución
Artefactos de Entrada: Descripción de la solución, Visión del Sistema, Requerimiento de Sistema
Artefactos de Salida: Planteamiento de Arquitectura Inicial
Actores Involucrados: Arquitecto
Descripción:
En función de los requerimientos identificados el arquitecto del proyecto construye un Planteamiento de Arquitectura Inicial, identificando módulos y componentes principales y las soluciones tecnológicas asociadas a cada uno. Se debe determinar además cuáles componentes de la arquitectura son aquellos que tienen mayor riesgo de desarrollo.
Nombre: Desarrollar Solución Sistémica
Artefactos de Entrada: Planteamiento de Arquitectura Inicial
Artefactos de Salida: Prueba de Concepto
Actores Involucrados: Desarrollador
Descripción:
Con el Planteamiento de Arquitectura Inicial ya realizado se debe determinar si hay aspectos del sistema que requieran una prueba de concepto de la solución planteada para asegurar la factibilidad de la misma. Si se determina que son necesarias una o más pruebas de concepto, estas se desarrollan de acuerdo a la importancia de cada una.
Nombre: Asegurar Correctitud y Funcionalidad de la Solución
Artefactos de Entrada: Requerimiento original ofrecido, Visión del Sistema, Prueba de Concepto
Artefactos de Salida: N.A.
Actores Involucrados: Jefe de Proyecto, Arquitecto.
Descripción:
Verificar que las Pruebas de Concepto se ajusten a lo ofrecido y que concuerde con la Visión del Sistema que tiene el cliente. Esta verificación generalmente involucra una revisión de pares con otro arquitecto con el fin de examinar la solución planteada por el arquitecto del proyecto y proponer cambios o mejoras a ésta.
Nombre: Desplegar Solución
Artefactos de Entrada: Prueba de Concepto
Artefactos de Salida:
Actores Involucrados: Jefe de proyecto, Arquitecto, Stakeholders
Descripción:
De ser necesario se pueden desplegar en un ambiente temporal algunas de las pruebas de concepto verificadas para ser mostradas a los Stakeholders interesados y demostrar su correctitud y funcionalidad ante ellos.
- Fase de Inicio
La Fase de Elaboración – Construcción tiene por objetivo establecer una base sólida de la Arquitectura de Software a partir del análisis y diseño de los requerimientos, para luego implementar el sistema en base a estos diseños y arquitectura planteados. En el diagrama de la Figura 7 se modela esta fase, destacando con gris las disciplinas que por su complejidad presentan un diagrama de actividades adicional para detallar su comportamiento.
Figura 7: Fase de Elaboración – Construcción
Nombre: Describir el Problema de Negocio
Artefactos de Entrada: Visión del Sistema, Concepto de Dominio, Proceso de Negocio
Artefactos de Salida: N. A.
Actores Involucrados: Analista
Descripción:
Se revisan los documentos de Visión del Sistema, Procesos de Negocio y Concepto de Dominio en términos de los requerimientos que se quieren atacar. Se pueden realizar correcciones menores a estos documentos cuando corresponda, en función del análisis que se realiza en esta etapa de vida del proyecto.
Nombre: Especificar Requerimientos de la solución
Artefactos de Entrada: Planteamiento de Arquitectura Inicial, Requerimiento de Sistema, Arquitectura del Sistema
Artefactos de Salida: Criterios de Aceptación, Requerimiento de Sistema, Prototipo de Sistema, Mecanismos de Diseño (Patrones)
Actores Involucrados: Analistas, Arquitecto, Stakeholders, Jefe de Proyecto
Descripción (ver Figura 8):
La diferencia entre las fases de Elaboración y Construcción radica que durante la Elaboración se atacan los requerimientos de arquitectura más importantes, que darán como resultado la mayor parte de los mecanismos de diseño del sistema.
Sobre el conjunto de Requerimientos de Sistema que se quieren atacar se deben detallar por completo los antecedentes necesarios para comprender y acotar qué es lo que debe hacer cada parte del sistema, indicando los escenarios principales, secundarios y las restricciones. Esto incluye la realización de prototipos no funcionales, que sirvan tanto para mostrar al cliente una vista previa del sistema como para la fase de diseño donde la interfaz se debe diseñar completamente.
Figura 8: Especificar Requerimientos de la solución
Se debe determinar que los Requerimientos de Sistema estén cumpliendo con los requerimientos ofrecidos y que no se requiere más de lo originalmente ofrecido del sistema. Cualquier desviación de estas líneas debe ser debidamente controlada. También se deben revisar los Criterios de Aceptación de los requerimientos con el cliente con los analistas encargados y con analistas que no sean parte del proyecto por medio de una revisión de pares y si existe una modificación en los requerimientos también se debe modificar este documento con la debida aprobación del cliente. Luego el arquitecto debe determinar si los mecanismos de diseño definidos alcanzan para cubrir estos requerimientos si se deben generar nuevos mecanismos o si se deben adaptar los antiguos. Esto debiese darse solo en la fase de la Elaboración ya que durante la Construcción todos los problemas deben haber sido previamente atacados y por tanto no debiese surgir la necesidad de crear nuevos mecanismos para los mismos problemas.
- Fase de Elaboración – Construcción
| Página siguiente |