Seguridad en CMMI

El tema de seguridad es crítico en el desarrollo de los productos actuales. El incremento en ataques de diferentes formas que ponen en riesgo las instalaciones y la información que manejan las organizaciones ha incrementado los requisitos y estándares de seguridad por los clientes, la industria y gobiernos.

El CMMI Institute publicó una nota técnica "Security by Design with CMMI for Development v1.3"  que constituye una guía de aplicación para la mejora de procesos de productos seguros. El documento estructura una serie de prácticas agrupadas en cuatro áreas de proceso que cubren elementos de ingeniería, gestión de proyectos y gestión de procesos, que se integran con las áreas de proceso existentes en CMMI DEV. Como resultado las actividades, funciones, métodos y herramientas que se utilizan en el desarrollo del producto ayudan a proporcionar la seguridad que necesita el cliente. 

Atributos y medidas de calidad del software

Una atributo es una propiedad del producto, que cuando es asociada con la calidad se relaciona con los elementos que considera el cliente para aceptar o rechazar el producto. Estos atributos de calidad deben ser medidos para poder ser comparados. 

Es importante entenderlos desde la concepción de la idea a partir de las necesidades del cliente o mercado, considerarlos como parte de la solución y creación del producto para finalmente demostrar que han sido adecuadamente integrados en el producto final. Aquí se presentan diferentes atributos y medidas considerados en los entornos de desarrollo, instalación y operación que pueden ser útiles identificar en cada caso.

Consideraciones para el diseño

El diseño es la fase del proceso de desarrollo donde se clarifican los requisitos iniciales y se establecen las posibles soluciones del producto. Constituye un proceso creativo para producir una solución efectiva y precisa para un problema pobremente definido. El modelo CMMI considera actividades de diseño en diferentes áreas de proceso de la categoría de ingeniería y en particular se concentran en RD, TS y PI.

Resumen de Desarrollo del sistema de servicio en CMMI SVC v1.3

Sdepares

El área de proceso de Service System Development (SSD) es adicional para el modelo CMMI SVC y corresponde al nivel 3 de madurez en la representación por etapas y está ubicada en la categoría de procesos de Establecimiento y prestación del servicio para la representación continua.  Su propósito es analizar, diseñar, desarrollar, integrar, verificar y validar el sistema de servicio, incluyendo los componentes del sistema de servicio, para satisfacer los acuerdos de servicios existentes o previstos.


Esta área de proceso se considera adicional porque se ofrece como una alternativa para el desarrollo del sistema de servicio integrando diferentes prácticas en una única área de proceso.  De forma alternativa se pueden utilizar las áreas de proceso de ingeniería del modelo CMMI DEV para los que están familiarizados con este enfoque. 


Considera tanto el desarrollo de sistemas de servicio nuevos o de los cambios a los sistemas existentes. Como sistema de servicio considera la combinación de los componentes del sistema; procesos, productos, personas, consumibles, clientes u otros recursos que permiten ofrecer un valor en respuesta a las necesidades de los interesados. 


En términos generales las metas específicas consideran la recolección, coordinación, análisis, validación y asignación de los requisitos de los interesados para el sistema de servicios. La evaluación y selección de alternativas de solución, el diseño, construcción, integración y documentación del sistema de servicio que cumple esos requisitos. Finalmente el sistema de servicio es verificado y validado para confirmar que satisface los requisitos y que cubrirá las expectativas de uso del cliente y usuarios durante la prestación del servicio.

10 Claves para una adecuada definición y gestión de requisitos

El establecimiento de los requisitos para un producto es vital para obtener un excelente resultado. Es la base para arrancar el trabajo de desarrollo y la fuente de muchos de los problemas que se presentan, por lo que una adecuada definición y gestión de los mismos es la clave para evitar contratiempos, retrabajos e incrementos de costos.

 Existen elementos imprescindibles, que se deben tomar en cuenta, para una correcta definición y gestión de requisitos y que son presentados aquí como diez elementos claves. Estos deben ser considerados como parte del sistema de procesos, prácticas, herramientas y disciplinas a integrar para identificar, analizar, especificar, verificar y gestionar los requisitos de un producto

Requisitos del cliente, producto, componentes del producto e interfaz

En el modelo CMMI las prácticas de RD consideran básicamente tres niveles de requisitos, del cliente, producto y componentes del producto. Adicionalmente a estos se menciona la identificación de requisitos de interfaz, igualmente importantes. 
Los diferentes niveles de requisitos cubren, durante todo el desarrollo del producto, las diferentes etapas de refinamiento de las necesidades iniciales del cliente que son diseñadas en la solución a nivel de requisitos del producto y a un nivel más bajo de instanciación como requisitos de componentes del producto. Estos niveles de requisitos se van obteniendo a través de diferentes iteraciones y refinamientos donde se detallan, derivan y asignan las dependencias de requisitos de alto nivel hacia los requisitos obtenidos a niveles más bajos. 

Metas, prácticas y subprácticas

El modelo CMMI establece un conjunto de prácticas que permiten mejorar los procesos operativos de la organización. Es un modelo descriptivo, no prescriptivo, en el sentido que determina qué se debe hacer pero no establece cómo. Cada organización define la forma y modo de aplicarlo, considerando los elementos que son obligatorios, sugeridos o el material informativo en las áreas de proceso.


Los elementos obligatorios son las Metas (Specific Goals & Generic Goals), que son las características que se deben demostrar para determinar si un área de proceso se cumple para efectos de la evaluación. La falta de cumplimiento de una meta, que sea aplicable, invalida el cumplimiento del área de proceso.


Los componentes sugeridos son las Prácticas (Specific Practices & Generic Practices), que son las actividades que se implementan para demostrar el cumplimiento de las metas, ya sea como están definidas por el modelo o de alguna manera alternativa definida por la organización que garantice el logro de las metas. La falta de cumplimiento de una práctica no necesariamente invalida el cumplimiento de la meta y por consiguiente del área de proceso, muchas veces se consideran como oportunidades de mejora para la organización pero en conjunto son los elementos que se utilizan para determinar el cumplimiento de la meta.


La parte informativa del modelo, en este caso las Subprácticas, proporcionan una descripción detallada de la forma en que se interpretan o aplican las prácticas según lo que se espera del modelo. Otros elementos que proporcionan información son los ejemplos, productos de trabajo, notas, referencias y títulos. El incumplimiento de una subpráctica no necesariamente afecta el cumplimiento de una meta, pero son ideas útiles y necesarias para la mejora de procesos y el entendimiento adecuado de las metas y prácticas por lo que es importante tomarlos en cuenta.


Los componentes, metas y prácticas, se dividen en específicos y genéricos. La diferencia tiene sentido para la forma en que se aplican pero, al final tienen la misma implicación que se comentó anteriormente. Los específicos son únicos para un área de proceso. En el caso de los genéricos son los mismos para todas las áreas de proceso, aunque se aplican y evalúan de manera independiente para cada área de proceso.


La forma en que se aplican tiene mucha relación con la representación del modelo que se use para efectos de implantación y evaluación de las áreas de proceso. Sobre todo para determinar las metas y prácticas genéricas que son aplicables al área de proceso según se hable de niveles, de madurez o de capacidad.

Resumen de Solución técnica en CMMI DEV v1.3

El área de proceso de Technical Solution (TS) corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito diseñar, desarrollar e implementar soluciones para los requerimientos. Las soluciones, los diseños y las implementaciones engloban productos, componentes de producto y procesos del ciclo de vida asociados al producto, de manera individual o en combinación, según sea apropiado.


TS es el centro del desarrollo y mantenimiento del producto, depende de los requerimientos definidos en RD para generar el producto y que se mantienen actualizados a través de REQM. Como parte de las prácticas definidas se desarrolla, de manera iterativa, las diferentes soluciones a los requerimientos del cliente, productos y componentes del producto. Esas soluciones son diseñadas y finalmente construidas para crear el producto o servicio y los procesos asociados durante todo el ciclo de vida.


Las metas definidas en TS interactúan en diferentes etapas del desarrollo y en diferentes instancias del producto y sus componentes. El establecimiento de soluciones, el desarrollo del diseño y la implementación del diseño se ejecutan de manera iterativa de acuerdo con las necesidades del desarrollo.


En la versión 1.3 del modelo no existen cambios significativos en cuanto a las metas y prácticas específicas para esta área de proceso. 


Establecer soluciones
SG1 Las soluciones de producto o de componentes de producto son seleccionadas a partir de soluciones alternativas.

• SP1.1 Desarrollar las soluciones alternativas y los criterios de selección.
• SP1.2 Seleccionar las soluciones de componentes de producto con base en los criterios de selección.

Desarrollar el diseño a las soluciones

SG2 Los diseños de producto o de los componentes de producto son desarrollados.

• SP2.1 Desarrollar un diseño para el producto o el componente de producto.
• SP2.2 Establecer y mantener un paquete de datos técnicos.
• SP2.3 Diseñar las interfaces de componentes de producto usando los criterios establecidos.
• SP2.4 Evaluar si los componentes de producto se deberían desarrollar, comprar o reutilizar en base a los criterios establecidos.

Implementar el diseño

SG3 Los componentes de producto y la documentación de soporte asociada son implementadas a partir de sus diseños.

• SP3.1 Implementar los diseños de los componentes de producto.
• SP3.2 Desarrollar y mantener la documentación de uso final

Resumen de Integración del producto

El área de proceso de Product Integration (PI) corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito ensamblar el producto a partir de sus componentes, asegurar que el producto, una vez integrado, funciona correctamente, y entregar el producto. 

Aunque PI maneja como propósito el ensamblado de componentes y comprobación del funcionamiento del producto ensamblado antes de la entrega, eso solamente hace referencia a la meta específica 3 del área de proceso. Para cubrir las otras dos metas específicas se requiere definir y establecer la infraestructura para la integración del producto y gestionar las interfaces durante todo el ciclo de desarrollo del producto para garantizar, en el momento de la integración, que no se presenten problemas. Por ello, aunque el resultado de PI es el producto integrado, para poder llegar hasta ahí es fundamental una efectiva gestión de las interfaces. 

Las interfaces se identifican como requerimientos en RD, se diseñan en TS y finalmente se gestionan para facilitar la integración en PI. 

Establecer la infraestructura para la integración 
SG1 La preparación para la integración del producto es llevada a cabo.

• SP1.1 Determinar la secuencia de integración del componente de producto
• SP1.2 Establecer y mantener el entorno necesario para dar soporte a la integración de los componentes del producto.
• SP1.3 Establecer y mantener los procedimientos y los criterios para integración de los componentes del producto

Gestionar las interfaces entre componentes

SG2 Las interfaces del componente de producto, tanto internas como externas, son compatibles.

• SP2.1 Revisar las descripciones de la interfaz en cuanto a cobertura y completitud.
• SP2.2 Gestionar las definiciones, diseños y cambios de las interfaces internas y externas para los productos y los componentes de producto.

Ensamblar los componentes para liberar el producto

SG3 Los componentes de producto verificados son ensamblados, y el producto integrado es verificado y validado antes de ser entregado.

• SP3.1 Confirmar, antes de ensamblar, que cada componente de producto requerido para ensamblar el producto ha sido identificado correctamente, funciona de acuerdo con su descripción y que las interfaces de componente de producto cumplen con las descripciones de la interfaz.
• SP3.2 Ensamblar los componentes de producto de acuerdo a la secuencia de integración de producto y a los procedimientos disponibles.
• SP3.3 Evaluar los componentes de producto ensamblados para la compatibilidad de la interfaz.
• SP3.4 Empaquetar el producto o componente de producto ensamblado y entregar al cliente apropiado.

Resumen de Solución técnica

El área de proceso de Technical Solution (TS) corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito diseñar, desarrollar e implementar soluciones para los requerimientos. Las soluciones, los diseños y las implementaciones engloban productos, componentes de producto y procesos del ciclo de vida asociados al producto, de manera individual o en combinación, según sea apropiado. TS es el centro del desarrollo y mantenimiento del producto, depende de los requerimientos definidos en RD para generar el producto y que se mantienen actualizados a través de REQM. Como parte de las prácticas definidas se desarrolla, de manera iterativa, las diferentes soluciones a los requerimientos del cliente, productos y componentes del producto. Esas soluciones son diseñadas y finalmente construidas para crear el producto o servicio y los procesos asociados durante todo el ciclo de vida. Las metas definidas en TS interactúan en diferentes etapas del desarrollo y en diferentes instancias del producto y sus componentes. El establecimiento de soluciones, el desarrollo del diseño y la implementación del diseño se ejecutan de manera iterativa de acuerdo con las necesidades del desarrollo. Establecer soluciones SG1 Las soluciones de producto o de componentes de producto son seleccionadas a partir de soluciones alternativas.

• SP1.1 Desarrollar las soluciones alternativas y los criterios de selección.
• SP1.2 Seleccionar las soluciones de componentes de producto que mejor satisfacen los criterios establecidos.

Desarrollar el diseño a las soluciones

SG2 Los diseños de producto o de los componentes de producto son desarrollados.

• SP2.1 Desarrollar un diseño para el producto o el componente de producto.
• SP2.2 Establecer y mantener un paquete de datos técnicos.
• SP2.3 Diseñar las interfaces de componentes de producto usando los criterios establecidos.
• SP2.4 Evaluar si los componentes de producto se deberían desarrollar, comprar o reutilizar en base a los criterios establecidos.

Implementar el diseño

SG3 Los componentes de producto y la documentación de soporte asociada son implementadas a partir de sus diseños.

• SP3.1 Implementar los diseños de los componentes de producto.
• SP3.2 Desarrollar y mantener la documentación de uso final

Interfaces

Una interfaz es la frontera por la cual se comunican dos sistemas. Puede ser un conector utilizado para conectar otro dispositivo o puede ser un acuerdo utilizado para permitir la comunicación entre dos aplicaciones. Frecuentemente existe un componente intermedio entre los sistemas que permite conectar sus interfaces. En el modelo CMMI el área de proceso de Product Integration (PI) se encarga de administrar las interfaces del producto durante el proyecto. En particular la meta específica SG2 se encarga de Asegurar la compatibilidad de interfaz y SG3 permite Confirmar que el producto cumple con las interfaces establecidas, que puede ser ensamblado y que funciona adecuadamente. Las interfaces deben considerar tanto las interfaces de los componentes del producto como las interfaces con los diferentes ambientes que se requieren para verificación, validación, operación y soporte. En el área de proceso de Requeriments Development (RD, SP2.3) se establecen los requerimientos de interfaz, que serán diseñadas como interfaz para la solución a los requerimientos como parte de Technical Solution (TS, SP2.3). Las prácticas de Verification (VER) permite revisar la interfaz de los productos o componentes. Otras área de proceso que consideran el manejo de elementos relacionados con la interfaz son:

• Configuration Management (CM) Descripción de la interfaz
• Integrated Project Management (IPM) Interfaz entre grupos y riesgos de interfaz entre grupos
• Organizational Innovation and Deployment (OID) Estándares de interfaz
• Organizational Process Definition (OPD) Definición de interfaz del proceso
• Risk Management (RSKM) Administración de riesgos de interfaz
• Project Planning (PP) Complejidad de la interfaz para la estimación y compromisos de interfaz
• Requirements Management (REQM) Rastreabilidad de requerimientos de interfaz
• Supplier Agreement Management (SAM) Interfaz con proveedores
• VER y Validation (VAL) Ambientes de verificación y validación

M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor