SEI Virtual Forum: Cloud computing y Seguridad

jscreationzs

El SEI realizó el pasado 20 de octubre un foro virtual tecnológico, donde presentó las líneas de trabajo e investigación que está desarrollando o difundiendo actualmente. El foro contó con especialistas y expertos de primer nivel dentro de la institución, quienes expusieron para mil participantes de más de 50 países, conectados en línea, los diferentes tópicos en temas como: Métodos Agile, Cómputo en la Nube, CMMI y TSP. 
En paralelo se enviaron mensajes de Twitter que permitían hacer un seguimiento de lo que estaba pasando en el foro. Tomando esa información y las presentaciones mostradas, pretendemos hacer un resumen de los principales temas.
Grace Lewis presentó los avances en “cloud computing” y las implicaciones en la arquitectura.

SEI Technologies Forum

El SEI está presentando un Foro de Tecnologías a través de los especialistas en sus diferentes áreas de trabajo e investigación. Interesante oportunidad y forma de acercarse a los expertos a través de un seminario gratuito de gran utilidad y aplicación. 
Se puede consultar en  http://www.sei.cmu.edu/go/technologies-forum/

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

El valor de las prácticas en CMMI

Un estudio realizado en el año 2003 con 103 ejecutivos de TI, entre CIOs, CTOs, vicepresidentes y directores, y presentado en un artículo, por Richard Pastore y Lorraine Cosgrove, bajo el título “The Best Best Practices”, considera, en segunda posición, que las metodologías de mejora de la calidad, como Six Sigma y CMMI, son las prácticas menos efectivas y más difíciles de implementar. (En la primera posición se menciona establecer el precio de los servicios de TI en relación con su valor).

Esta percepción puede ser altamente influenciada por el hecho de que se perciben de poco valor y burocráticas, mientras que la realidad demuestra que, muchas veces, son inadecuadamente aplicadas o no consideran las necesidades reales de la organización.

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. 

CMMI no es suficiente

En un artículo publicado por Channel Partner se comenta sobre la problemáticas de las factorías de software en España. En el análisis se plantea que la mejora del proceso con la adopción de prácticas de CMMI no es suficiente para mejorar la competitividad de la industria de software, en particular en España, pero que es completamente aplicable a nivel internacional.


Se plantea como líneas de trabajo la relación con el cliente, especialización del personal técnico, mejor reutilización del software y mejoramiento de la efectividad del modelo de producción, valorar el producto, competitividad internacional y esquemas de subcontratación.


En general las líneas que se deben fortalecer son la formación del cliente en la calidad ante el costo del producto, incrementar el nivel profesional de los recursos humanos que son la base del desarrollo de software, internacionalización del servicio como parte de la globalización de la industria y la posibilidad de contratación de servicios a nivel mundial y mejorar el uso y operación del modelo de fábrica de software.


El trabajo en la implementación de procesos con base en el modelo CMMI sin una adecuada estrategia en la Organización o en la industria, en términos globales, no permitirá llevar un proceso artesanal a un proceso industrializado de creación y producción de software. Esta puede ser la expectativa y objetivo de muchas organizaciones y gobiernos en diferentes países, que trabajan en el fortalecimiento de la industria con programas gubernamentales. 


Al fin de cuentas CMMI sólo cubre una parte de la realidad de las organizaciones. Existen otros procesos y elementos a tomar en cuenta como parte de la mejora de procesos, que no deben ser pasados por alto.

Cambios adicionales para la versión 1.3 del modelo CMMI

La nueva versión del modelo CMMI integra algunos cambios adicionales, a los que se han comentado en otros artículos.

Técnicas para identificación de requisitos

El modelo CMMI en el área de proceso de Requirements Development (RD) establece la necesidad de identificar de manera proactiva las necesidades, expectativas, restricciones y supuestos del cliente. Esas prácticas se reflejan en la meta específica 1 en particular en la práctica específica 1.1. Elicit needs 
Para identificar las necesidades del cliente se utilizan técnicas que permiten determinar de manera explícita, documentada, los requisitos implícitos que tiene el cliente. Esta actividad es continua durante el ciclo de desarrollo y combina, en diferentes puntos, diversas técnicas para obtener la visión más completa de sus necesidades. 

Enfoques para Peer reviews

Existen diferentes métodos y técnicas para realizar un Peer review, o revisión entre colegas, que cubren diferentes niveles de formalidad, rigor, efectividad y costo. 

Proyectos de mantenimiento

El modelo CMMI DEV, según se establece en el prefacio, "es un modelo de madurez para la mejora de procesos de desarrollo de productos y servicios". Contiene mejores prácticas orientadas a las actividades de desarrollo y mantenimiento que cubren el ciclo de vida del producto desde su creación hasta la liberación y mantenimiento. Adicionalmente en el glosario establece que desarrollo incluye también las actividades de mantenimiento, por lo que las empresas pueden considerar las prácticas tanto para el desarrollo como el mantenimiento.

Aplicación de prácticas a proyectos de mantenimiento

En empresas dedicadas al desarrollo y comercialización de productos propios, típicamente sus proyectos son mayormente de mantenimiento correctivo o por mejoras. En este caso la aplicación de las prácticas de ingeniería, en el modelo CMMI, son cuestionadas por los ciclos que tienen para los proyectos, en general con un esfuerzo disponible de horas o días para ofrecer la solución.

Una posible alternativa es manejar los proyectos de mantenimiento por ciclos, tal vez un año o seis meses, donde se considere la planificación de recursos y mecanismos de seguimiento.

Lo ideal para estos proyectos es contar con una herramienta para seguimiento de órdenes de servicio o requerimientos de cambio. En la misma herramienta se puede documentar fácilmente lo que se hizo y así tener documentado todo el producto en un repositorio único. Para las actividades de PPQA lo mejor es definir periodos de revisión y elegir las órdenes que se tengan ya sean cerradas o activas, mayormente los hallazgos son lecciones aprendidas para las siguientes.

En el caso de las mejoras planeadas que pueden ser proyectos de más tiempo y mejor controlados se puede tener un esquema más amplio aunque muchas veces se reutilizan muchos de los artefactos porque los ambientes, productos y recursos muchas veces son los mismos.

Diferentes niveles de pruebas

Una situación recurrente que se presenta, sobre todo en empresas con pocas o nulas prácticas de ejecución de pruebas, es que se realizan "diferentes" niveles de pruebas pero en todos los casos se repiten los mismos escenarios de pruebas.

No se hace un adecuado plan de pruebas para diferenciar entre los tipos y niveles de pruebas, de manera que sea efectivo en la detección e identificación de los defectos que corresponde a cada uno. Es importante diferenciar entre las pruebas estáticas y dinámicas, caja blanca y caja negra. Distinguir entre el objetivo de las pruebas unitarias, sistema o funcionales, pruebas integrales y de aceptación.

En las pruebas unitarias se hacen pruebas a nivel bajo a diferencia de las otras pruebas que deben revisar cuestiones a otro nivel. Es importante garantizar el resultado de las pruebas unitarias, no sólo es pasar la compilación sin errores, para no tener problemas de bajo nivel en otras pruebas.

Las prácticas en las áreas de proceso de VER y VAL ayudan a mejorar esos resultados.

CCB: Configuration Control Board o Change Control Board

En el modelo CMMI, en el área de proceso de Configuration Management (CM), se establece la existencia del CCB como parte de las prácticas y funciones para el control de los componentes de configuración. Este acrónimo que viene de Configuration Control Board o Change Control Board se refiere al Comité de control de la configuración o Comité de control de cambios.

Funciones y estructura del CCB El comité de control de cambios tiene la autoridad para aceptar o rechazar las propuestas de cambio a componentes de configuración. Como estos cambios tienen sentido controlarlos una vez que se crean las líneas base, el comité de control de cambios tiene la autoridad para gestionar las líneas base del producto y asegurar que los cambios son adecuadamente considerados y coordinados. De acuerdo con el tamaño de la organización, proyecto y complejidad del producto se pueden requerir diferentes niveles de control. En proyectos pequeños es una responsabilidad del líder o persona asignada en lugar de un grupo de personas. Pueden existir múltiples niveles de autoridad de acuerdo con la criticidad de los cambios, la naturaleza respecto al impacto en presupuesto y calendario o la etapa del ciclo de vida.

Composición del CCB La composición del comité varia dependiendo de los niveles de autoridad requeridos, siempre existe un representante de gestión de la configuración y los representantes de los involucrados al nivel que corresponda. El comité de control de cambios puede incluir como miembros al personal de:

• Desarrollo
• Aseguramiento de calidad
• Gestión de la configuración
• Pruebas y control de calidad
• Documentación
• Mantenimiento
• Liberación del producto
• Gerente de proyecto/programa
• Ingeniería de sistema o hardware
• Representantes del cliente
• Áreas administrativas: Comercial, financiero o ventas

Las actividades del comité de control de cambios están sujetas a revisiones de aseguramiento de calidad y auditorías a la configuración, para evaluar el cumplimiento de sus actividades.

Resumen de Verificación

El área de proceso de Verification (VER) 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 asegurar que los productos de trabajo seleccionados cumplen sus requerimientos especificados. 
Las prácticas de VER permiten identificar defectos en etapas tempranas de la creación del producto y reducir los altos costos asociados a la identificación y corrección de defectos que se pueden presentar más adelante. En conjunto con VAL permite dar certeza al cliente o usuario que el producto cumple sus necesidades y que por otra parte puede ser utilizado. En su estructura de prácticas es muy similar a VAL pero con un enfoque diferente. 
Verificación
Las técnicas de VER son muy similares a las utilizadas por PPQA y se debe evitar duplicar esfuerzos al ejecutar esas actividades que tienen propósitos diferentes pero ocurren sobre los mismos productos de trabajo. Mientras que la primera encuentra defectos asociados al incumplimiento de los requerimientos, en la segunda se encuentran hallazgos o desviaciones al proceso que se debe utilizar. Lo ideal es que con una actividad se puedan cubrir ambos enfoques, muchas veces integrando el punto de vista de aseguramiento de calidad como parte de las actividades de verificación. 
En particular VER hace énfasis, en la meta específica 2, en el uso de la técnica de Peer Reviews o Revisiones entre pares. Esto obliga al uso de esta técnica adicionalmente a otras que pueden ser aplicables para cumplir la meta específica 3. Al definir la estrategia de verificación, como parte de las prácticas de la meta específica 1, se deben identificar los productos de trabajo a revisar y las técnicas de verificación que se utilizarán, ya sean Peer Reviews u otro tipo de revisiones, inspecciones, demostraciones y pruebas. 
Establecer la estrategia de verificación 
SG1 La preparación para la verificación es llevada a cabo.

• SP1.1 Seleccionar los productos de trabajo a verificar y los métodos de verificación que serán usados para cada uno.
• SP1.2 Establecer y mantener el entorno necesario para dar soporte a la verificación.
• SP1.3 Establecer y mantener los procedimientos y los criterios de verificación para los productos de trabajo seleccionados.

Ejecutar las revisiones entre pares

SG2 Las revisiones entre pares son realizadas sobre los productos de trabajo seleccionados

• SP2.1 Preparar las revisiones entre pares de los productos de trabajo seleccionados.
• SP2.2 Llevar a cabo las revisiones entre pares sobre los productos de trabajo seleccionados, e identificar los problemas resultantes de la revisión entre pares.
• SP2.3 Analizar los datos sobre la preparación, la realización y los resultados de las revisiones entre pares.

Ejecutar la verificaciones 
SG3 Los productos de trabajo seleccionados son verificados frente a sus requerimientos especificados.

• SP3.1 Realizar la verificación sobre los productos de trabajo seleccionados.
• SP2.2 Analizar los resultados de las actividades de verificación.

Resumen de Validación

El área de proceso de Validation (VAL) 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 demostrar que un producto o componente de producto se ajusta a su uso previsto cuando se sitúa en su entorno previsto. Las prácticas definidas en el área de proceso de VAL, en conjunto con VER, tienen elementos muy similares pero desde diferentes perspectivas. En su aplicación pueden coincidir utilizando las mismas técnicas, pero cuidando que se demuestren ambos enfoques. Mientras que en VER se busca demostrar que los productos de trabajo cumplen con los requerimientos que los definen en VAL se demuestra que el producto generado puede ser utilizado. Una diferencia entre VER y VAL está en que el primero puede ser aplicado a productos internos, no necesariamente dirigidos al cliente, mientras que el segundo está orientado a los productos que serán entregados y utilizados por el cliente o usuarios finales. Una pequeña diferencia que se aprecia al leer detenidamente el propósito y entender la diferencia entre productos de trabajo y componentes del producto, en el glosario del modelo. Lo cual no quiere decir que se aplique hasta el final del desarrollo, sino que por principio son prácticas que se aplican en todas las fases del desarrollo del producto utilizando las diferentes perspectivas que se van obteniendo del producto final. Otro elemento diferente en el momento de aplicar las validaciones es el entorno de operación. Las prácticas de validación deben aplicarse en un ambiente similar, o lo más cercano posible, al ambiente real de operación del producto, que permita ubicar al usuario en el contexto de uso y determinar cualquier problema que se pueda presentar. La creación de este ambiente de validación es un elemento fundamental en la preparación, sobre todo por la cuestión de presupuesto y tiempos para su preparación. La identificación, investigación, exploración y definición adecuada de los requerimientos en RD puede reducir las diferencias de perspectivas entre VER y VAL. Al final cuando los requerimientos implícitos, muchas veces relacionados con el uso y operación, son establecidos de manera explícita la diferencia entre VER y VAL son reducidas considerablemente.

La aplicación de VER y VAL se da en conjunto con otras áreas de proceso de ingeniería como RD y TS, pero son fundamentales para cumplir la meta específica 3 de PI que tiene que ver con la integración de los componentes y liberación del producto.

VAL requiere por una meta establecer la estrategia de validación y por la otra ejecutar las validaciones definidas en la estrategia y analizar los resultados. Estrategia de validación SG1 La preparación para la validación es llevada a cabo.

• SP1.1 Seleccionar los productos y los componentes de producto a validar y los métodos de validación que serán usados para cada uno.
• SP1.2 Establecer y mantener el entorno necesario para dar soporte a la validación.
• SP1.3 Establecer y mantener los procedimientos y los criterios de validación

Ejecutar las validaciones

SG2 El producto o los componentes de producto son validados para asegurar que sean adecuados para usar en su entorno operacional previsto.

• SP2.1 Realizar la validación sobre los productos y los componentes de producto seleccionados.
• SP2.2 Analizar los resultados de las actividades de validación.

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 Gestión de requerimientos

El área de proceso de Requirements Management (REQM) corresponde al nivel 2 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 gestionar los requerimientos de los productos y de los componentes del producto del proyecto, e identificar inconsistencias entre esos requerimientos y los planes y productos de trabajo del proyecto. Las prácticas de REQM son la base para la definición y ejecución de las actividades del proyecto y constituyen la entrada para PP. Básicamente aquí se garantiza que los requerimientos son válidos, tanto por el contenido como por la fuente de donde se originan, que están comprometidos y que si son modificados se realiza de manera controlada. Para poder determinar el impacto de los cambios es imprescindible contar con una traza de los requerimientos hacia las diferentes entidades del producto y a la inversa. Cuando se presentan cambios a requerimientos, y es algo que sucederá en la gran mayoría de las ocasiones, pueden presentarse inconsistencias particularmente por problemas de comunicación dentro del equipo que desconoce los cambios que han sido aprobados. REQM debe identificar esas situaciones y tomar acciones correctivas para garantizar su solución. Gestionar los requerimientos SG1 Los requerimientos son gestionados y las inconsistencias con los planes y productos de trabajo del proyecto son identificadas.

• SP1.1 Desarrollar una comprensión del significado de los requerimientos con los proveedores de los requerimientos.
• SP1.2 Obtener el compromiso de los participantes de proyecto sobre los requerimientos.
• SP1.3 Gestionar los cambios a los requerimientos a medida que evolucionan durante el proyecto
• SP1.4 Mantener la trazabilidad bidireccional entre los requerimientos y los productos de trabajo
• SP1.5 Identificar las inconsistencias entre los planes del proyecto, los productos de trabajo y los requerimientos.

Actualización sobre cambios en la versión 1.3 de CMMI

Recientemente el SEI publicó internamente la versión draft de lo que será el CMMI v1.3. Revisando la documentación, además de los cambios que ya se habían anunciado, hay algunas modificaciones que destacan en una primera ojeada.