Buscar en Gazafatonario IT

domingo, julio 22, 2012

¿Es maduro tu proceso de Ingeniería de Requisitos?


Hace algún tiempo, cuando me involucré en las iniciativas de mejoramiento de procesos de Intergrupo, las que finalmente condujeron a alcanzar el nivel CMMI 5, entendí que la cultura orgánica tiene su propio proceso natural de supervivencia y éxito y que siempre debía medir cuidadosamente lo que es adicionado y es removido de mi entorno. Por supuesto, siempre he tenido claro cuando ser “interno” o “externo” al proceso.
Fue una época en que puse en práctica algunos de los principios memorables de Deming en Administración: “La mejora de procesos debe ser realizada para mejorar el negocio – No como un objetivo en sí misma”. Y empezaba a pregonar que un proceso debe usar prácticas probadas en la industria, no solo la última moda, lo que escuchamos en la conferencia del día anterior o lo que leímos en el último artículo de la IEEE.
Y lo más importante, difundía a mil voces que debemos ser prácticos, que debemos entregar la información que se necesita, cuando se requiere y en un formato que se pueda usar. Con todo esto en mente, usamos un modelo de madurez típico como CMMI para mejorar nuestros procesos. Y uno de los primeros procesos que optimizamos fue este de la Ingeniería de Requisitos.
Pero ¿cómo saber si tu proceso es lo suficientemente maduro? ¿En la práctica qué significa identificar, documentar y administrar requisitos de software de una manera formal y razonable? Según el SEI (siglas en inglés del Instituto de Ingeniería de Software), autor del modelo CMMI, “los requisitos son manejados y las inconsistencias con los planes de proyecto y los productos de trabajo son identificadas”.
Lo que no dice el SEI en su área de proceso de RM (siglas en inglés de Administración de Requisitos), es que esas inconsistencias deben detectarse a tiempo porque cualquier cambio que involucre requisitos es altamente costoso para el proyecto y para los participantes en el mismo.
Para manejar los requisitos, el SEI recomienda:
·         Entender los requisitos
·         Acordar los requisitos con todos los involucrados
·         Administrar los cambios a los requisitos
·         Mantener una rastreabilidad bidireccional de los requisitos
·         Identificar las inconsistencias entre el trabajo del proyecto y los requisitos
Parece sencillo pero quienes hemos trasegado por los vericuetos de la Ingeniería de Requisitos con casos de uso sabemos que es más fácil decirlo que hacerlo y, sobre todo, hacerlo bien. Por ejemplo, sin duda es más simple entender y acordar requisitos entre las personas que están más involucradas en el proyecto, como los Analistas y los usuarios que quienes empiezan a llegar a medida que avanza el ciclo de vida, como los programadores o los certificadores.
Manejar los cambios, naturales por demás en un proyecto típico de software, es muchas veces otro dolor de cabeza para los participantes. Hay quienes creen que una solicitud de cambio es algo de menor valía, cuando la experiencia nos ha enseñado que sea cual fuere el momento y la fuente de la solicitud, siempre hay un impacto significativo y hay costos ocultos que solo los experimentados son capaces de descubrir a tiempo.
Por su parte, mantener una trazabilidad adecuada de los requisitos en ambas direcciones, lo que significa tener un mapa desde las necesidades del usuario y características del software, hasta el código ejecutable, pasando por los casos de prueba y otros artefactos importantes, es algo que solo se puede lograr adecuadamente con el uso de herramientas especializadas. En proyectos pequeños es posible que un Excel sirva, pero en algo más elaborado necesitamos de los instrumentos apropiados.
En cualquier caso, estas prácticas recomendadas (y esta es la palabra clave: “recomendadas”), son apenas un primer escaño para alcanzar la tan ansiada madurez en nuestros procesos de Ingeniería de Requisitos. Volveremos sobre ello más adelante.

viernes, julio 20, 2012

Ventajas y Desventajas del Uso de Prototipos


Algunas Ventajas del uso de prototipos

1.       Permiten el desarrollo de un sistema a partir de requisitos poco claros o cambiantes. Esto ocurre con cierta frecuencia en muchos proyectos de software.
2.       Como información complementaria a los requisitos constituyen un gran apoyo a las estimaciones de esfuerzo de todas las áreas, incluyendo proveedores.
3.       Son más fáciles de abordar con los usuarios finales.
4.       El usuario participa más activamente en la construcción del producto de software (La Solución), ya que “lo puede ver” y, dependiendo del tipo de prototipo,  “utilizar” desde el primer momento.
5.       Se reduce el riesgo o la incertidumbre sobre la implementación del software.
6.       Su uso redunda en una mayor satisfacción del usuario con el producto final, ya que él o ella han participado activamente de su diseño.
7.       Proporciona al usuario un mayor conocimiento del sistema con una curva menor de aprendizaje.
8.       Permite a todos los involucrados entender bien y mejor el problema antes de la implementación final.

Algunas Desventajas del uso de prototipos

1.       El usuario quiere empezar a trabajar desde el primer momento con el prototipo para solucionar su problema particular, cuando el prototipo es solo un modelo de lo que será el producto.
2.       Los prototipos generan o pueden generar otro tipo de problemas si su presentación y discusión con los usuarios no es controlada: puesto que son modelos inconclusos, los usuarios suelen enfocarse en aspectos “superficiales” del prototipo que los pueden dejar inconformes luego de verlos por primera vez. También es posible que se pierda mucho tiempo, innecesariamente, tratando de hacer entender al usuario la finalidad real de los prototipos.
3.       Requiere participación activa del usuario, al menos, para evaluar el prototipo. Y mucho más involucramiento si queremos que participe en su creación.
4.       Una desventaja importante a tener en cuenta es la falta de experiencia que tienen muchos Analistas Funcionales en programación y en actividades de diseño de interfaces de usuario.

Revisar/Aprobar Prototipos en Vez de Requisitos/Casos de Uso

Los prototipos son una herramienta suplementaria a la especificación de requisitos (funcionales). Con esto en mente, es posible que los usuarios revisen y aprueben estos prototipos durante la fase inicial del proyecto. Más adelante, el usuario puede confirmar su grado de satisfacción por los prototipos, más cercanos al producto final.
La otra parte de la tarea, aunque igualmente importante, es que entonces será el Analista Funcional el encargado de verificar que la descripción de los prototipos corresponda a la especificación de los requisitos en su totalidad. Las cosas así, es evidente que se incrementa el esfuerzo de los Analistas, sobre todo en la etapa de Visión y Alcance del proyecto. No obstante, el proceso de construcción de software puede mejorarse con la inclusión de guías para la elaboración de prototipos en las distintas plataformas.

Recomendación para implantar el uso de prototipos en un proceso de software

Como siempre, la recomendación es realizar algunos pilotos controlados donde pongamos en práctica el uso de prototipos en distintos proyectos, donde podamos medir y analizar los resultados con el fin de tener mejores herramientas para tomar la decisión, no solo de incluir los prototipos como una práctica común y hasta obligatoria durante el ciclo de vida, sino para que estos sean revisados/aprobados por los usuarios, en vez de los requisitos y casos de uso.

miércoles, julio 18, 2012

El uso de prototipos en el ciclo de vida de construcción del software

 Los prototipos son una técnica ampliamente usada para descubrir y documentar requisitos y casos de uso. En este caso hablamos de los prototipos de la interfaz de usuario, es decir, de todo lo que tiene que ver con la interacción usuario-máquina.

Los prototipos son muy útiles para refinar la especificación de requisitos funcionales del software, específicamente en todo lo que tiene que ver con la descripción de pantallas o formularios de entrada de datos, formulario de salida de datos (consultas), reportes, las opciones de navegación y, en general, toda la carta de navegación del usuario a través del software.

Existen prototipos rápidos y prototipos evolutivos. Los primeros son aquellos que se realizan en las primeras etapas del ciclo de vida y son usados para solucionar inquietudes iniciales relacionadas con la interfaz de usuario que no están claras o precisas en la documentación textual de los requisitos. Estos prototipos pueden ser elaborados en papel o en herramientas básicas como MS-Office (Word, Power Point, Excel, Visio).

Los prototipos evolutivos son artefactos más elaborados que se construyen durante la fase de diseño del software como complemento a la especificación de requisitos (y casos de uso) y que están muy cercanos al diseño final de la solución. Normalmente son hechos con las mismas herramientas con las que será construido el software o con alguna herramienta de automatización que permita generación de código fuente o algo parecido.

Hay distintos aspectos a tener en cuenta durante el uso de prototipos:

  •  Tipo de problema a resolver: si el problema es no-estructurado, novedoso, complejo o de manejo de información con un alto grado de personalización para un usuario o un grupo de usuario, entonces la técnica es muy útil.
  •  Conocimiento de los requisitos: si se desconocen los detalles de los requisitos del software, si existe poca información al respecto, los prototipos son útiles.
  •  Necesidad de revisar, evaluar y aprobar los requisitos: si los procedimientos o controles exigen que los requisitos del software sean revisados, evaluados y aprobados por usuarios y otro tipo de personas, los prototipos serán de gran ayuda a la hora de tomar decisiones.
  •  Este aspecto es crucial en muchas compañías ya que el alto grado de formalidad que exigimos para la especificación de requisitos, que tiene carácter contractual, exige que no solo los usuarios revisen y aprueben los requisitos y casos de uso, sino que estos deben ser revisados y valorados en distinto grado por personas de distintas áreas.
En estos casos es cuando los prototipos juegan un papel muy importante ya que aclaran situaciones que no están precisas en los documentos de texto. Sobre todo, con el bajo grado de madurez que tienen los documentos de requisitos y de casos de uso en el medio.

Otros aspectos a tener en cuenta en el uso de prototipos son: la cantidad y calidad de los riesgos del proyecto/requerimiento, no disponibilidad de los usuarios para revisiones y aprobaciones, uso de nuevas tecnologías o la falta de experiencia en el uso de esas tecnologías, entre otros.


Algunas Ventajas del uso de prototipos

  1.  Permiten el desarrollo de un sistema a partir de requisitos poco claros o cambiantes. Esto ocurre con cierta frecuencia en muchos proyectos de software.
  2.  Como información complementaria a los requisitos (y casos de uso) constituyen un gran apoyo a las estimaciones de esfuerzo de todas las áreas, incluyendo proveedores.
  3.  Son más fáciles de abordar con los usuarios finales.
  4.  Precisamente, el usuario participa más activamente en la construcción del producto de software (La Solución), ya que “lo puede ver” y, dependiendo del tipo de prototipo,  “utilizar” desde el primer momento.
  5. Se reduce el riesgo o la incertidumbre sobre la implementación del software.
  6. En general, el uso de prototipos redunda en una mayor satisfacción del usuario con el producto final, ya que él o ella han participado activamente de su diseño.
  7. Proporciona al usuario un mayor conocimiento del sistema con una curva menor de aprendizaje.
  8. Permite a todos los involucrados (usuarios y equipo de trabajo, incluyendo proveedores) entender bien y mejor el problema antes de la implementación final.
Algunas Desventajas del uso de prototipos

  1.  En general, encontramos que el usuario quiere empezar a trabajar desde el primer momento con el prototipo para solucionar su problema particular, cuando el prototipo es solo un modelo de lo que será el producto.
  2.  Los prototipos generan o pueden generar otro tipo de problemas si su presentación y discusión con los usuarios no es controlada: puesto que son modelos inconclusos, los usuarios suelen enfocarse en aspectos “superficiales” del prototipo que los pueden dejar inconformes luego de verlos por primera vez. También es posible que se pierda mucho tiempo, innecesariamente, tratando de hacer entender al usuario la finalidad real de los prototipos.
  3.  Requiere participación activa del usuario, al menos, para evaluar el prototipo. Y mucho más involucramiento si queremos que participe en su creación.
  4. Una desventaja importante a tener en cuenta es la falta de experiencia que tienen muchos Analistas Funcionales en programación y en actividades de diseño de interfaces de usuario.

Revisar/Aprobar Prototipos en Vez de Requisitos/Casos de Uso

Los prototipos son una herramienta complementaria, una técnica más, para la especificación de requisitos (funcionales), incluyendo casos de uso. Con esto en mente, es posible que los usuarios revisen (previa presentación “en vivo”) y aprueben estos prototipos durante la fase de Visión del proyecto/requerimiento. Más adelante, al final de la fase de Diseño (Planeación), el usuario puede confirmar su grado de satisfacción por los prototipos, estos ya más cercanos al producto final.

Tanto los primeros como estos últimos prototipos deben incluir el diseño de formularios de captura o ingreso de datos, formularios de consulta, reportes, opciones de navegación (menú), mensajes de usuario, ayudas en línea, entre otros aspectos. La única diferencia entre unos y otros prototipos debería ser la herramienta usada en la construcción de los prototipos y la precisión (menor en Visión, mayor en Planeación) de tales prototipos.

La otra parte de la tarea, aunque igualmente importante, es que entonces será el Analista Funcional el encargado de verificar que la descripción de los prototipos corresponda a la especificación de los requisitos en su totalidad. Las cosas así, es evidente que se incrementa el esfuerzo de los Analistas, sobre todo en la etapa de Visión y Alcance del proyecto. No obstante, el proceso de construcción de software puede mejorarse con la inclusión de guías para la elaboración de prototipos en las distintas plataformas.

Recomendación para implantar el uso de prototipos en un proceso de software

Como siempre, la recomendación es realizar algunos pilotos controlados donde pongamos en práctica el uso de prototipos en distintos proyectos, donde podamos medir y analizar los resultados con el fin de tener mejores herramientas para tomar la decisión, no solo de incluir los prototipos como una práctica común y hasta obligatoria durante el ciclo de vida, sino para que estos sean revisados/aprobados por los usuarios, en vez de los requisitos y casos de uso.