martes, 26 de diciembre de 2006

Grandes meteduras de pata

Es muy curioso lo que ves y escuchas en muchas organizaciones cuando pasas por la puerta y te cuentan sus experiencias, necesidades, problemática, vivencias, etc..., en la mayoría de los casos soy yo el que más aprende, pero hay ciertos momentos que te dejan huella, y sabes desde ese mismo momento que va a ser un verdadero fracaso y lo único que quieres hacer es levantarte de la silla y correr hacia la salida más cercana.

Uno de los más típicos es el de "vamos a comprar la megaherramienta", pensando que así se arreglará todo, que la herramienta funciona sola, que todo el mundo sabrá manejarla perfectamente, que estará parametrizada según las necesidades específicas de mi organización. Tener una buena herramienta es muy útil, pero no empecemos la casa por el tejado y supeditemos todo lo que debemos atender a una herramienta, tal y como vimos en artículos anteriores.


Otro caso curioso es el de encargar a aquella persona que, por una causa u otra, tiene un método para gestionar los requisitos de las peticiones de los usuarios y le encargan que aleccione al resto de personas que realizan el mismo tipo de rol. ¡¡Cuidado!!, no siempre algo particular puede tener replicación, es igual que si nos ponemos el traje hecho a medida de otra persona, seguramente lo podremos llevar, pero no se ajustará a nuestras necesidades, y será más un estorbo (fracaso) que una utilidad.

En otros sitios no se es totalmente consciente de lo que implica un proceso de cambio, pretendiendo resultados del día a la noche. Señores, cambiar no es sencillo ni fácil, pero claro que se puede hacer.

La última es también muy típica, y es aplicable a otras muchas cosas, el intento de aplicar las cosas como aparecen en los libros o manuales. Cada organización tiene sus particularidades, necesidades, cultura y manera de hacer las cosas. Si queremos implantar un modelo de ingeniería de requisitos en Oz perfecto, pero no en una organización que debe dar respuesta y soporte a las unidades de negocio.

Definición de Herramientas

Qué entendemos por herramientas
Las herramientas son aquellos elementos que nos ayudan, o proporcionan soporte, para hacer ciertas cosas; en ciertos ámbitos les denominan “elementos facilitadores”. Responden a la pregunta, ¿con qué lo haremos?

Uno de los principales errores es pensar que se trata únicamente de un programa informático, sobre todo en el entorno de sistemas de información. Este concepto es mucho más amplio y, además de poder ser software, también podría ser una plantilla, hardware, etc.

Herramientas a utilizar
Tipificaremos las herramientas que podemos utilizar no por la fase en la que se usan, ya que se suelen utilizar en dos o más fases, sino atendiendo a su naturaleza:

  • Documento: Entendemos por documento todos los elementos escritos o que sirven de guías para otros (plantillas). A este grupo atienden, actas de reunión, peticiones de trabajo, documento de requisitos de usuario, documentos de verificación y validación, correos electrónicos,… ya se encuentren en formato físico o digital.
  • Software: Es el conjunto de programas informáticos que facilitan la gestión y desarrollo de documentos, la comunicación entre las personas que participan en la ingeniería de requisitos. El software puede ser generalista, como un procesador de textos o un cliente de correo electrónico, o específico, como un software para la gestión de requisitos, de los cuales ya hablaremos.
  • Hardware: Es la máquina sobre la que funciona el software según las especificaciones indicadas, incluyendo especificaciones de comunicaciones físicas, almacenamiento en disco, teléfonos, webcams, etc.

domingo, 24 de diciembre de 2006

Definición de Métodos

Qué entendemos por métodos
Los métodos, refiriéndonos a los métodos de trabajo, nos proporcionan las guías de cómo debemos hacer las cosas. Haciendo referencia al artículo anterior, si los procesos nos indican qué hacer, los métodos nos indican cómo hacerlo.

Este punto es el más complicado de cambiar, o de influenciar o adaptar, en todas las personas que colaboran en una organización, ya que tiene mucho que decir la cultura organizativa, o como me suelen decir “es que aquí, las cosas las hacemos así”.

No quiero decir que cuando se cambia o implanta una metodología haya que cambiar todo, ni mucho menos, además, ciertos de estos hábitos son correctos y hay que integrarlos y enriquecerlos con las nuevas maneras de hacer las cosas.


Métodos a utilizar

Haremos una categorización de los métodos a utilizar por las diferentes fases descritas en la anterior entrega y que describiremos más adelante:

  • Captación: En este punto hablaremos principalmente de las entrevistas (cómo enfocarlas y realizarlas), ya que es el método más utilizado y por tanto el que más debemos cuidar. También trataremos métodos de captación de información en momentos de crisis y otros métodos grupales.
  • Análisis: Principalmente trataremos técnicas que nos ayuden a organizar y conocer la completitud de la información que hemos recabado.
  • Formalización: Este será el apartado que más nos lleve, ya que tratará todos los temas de modelado y métodos de representación, el uso de gráficos, cómo desarrollar un DRU, etc.
  • Verificación y Validación: Los métodos de verificación nos permitirán conocer el nivel de completitud y cumplimiento de los estándares establecidos por el DRU. Los métodos de validación se orientan a la negociación del alcance acordado en el DRU con los clientes.

sábado, 23 de diciembre de 2006

Definición del Proceso de Ingeniería de Requisitos

Características del proceso
El proceso es la guía que nos permitirá hacer aquello que hayamos definido que queremos hacer. No voy a entrar en las generalidades del los procesos, y me centraré en los particulares de la ingeniería de requisitos.

El proceso debe permitirnos recabar toda la información distribuida por toda la/s organización/es, analizarla, formalizarla, verificar que el documento generado es completo y se ajusta a los estándares y validar con el cliente la exactitud de la información tratada.

Además de todo esto, es muy normal, ya sea por la imposibilidad de recabar toda la información necesaria al principio o por la amplitud de la petición que estamos atendiendo, que debamos realizar un primer acercamiento y posteriormente concretar cada una de las partes identificadas, por lo que debe seguir un ciclo de vida iterativo e incremental.

Concreción del proceso
Por todo lo anterior, creo correcto diferenciar cuatro grandes fases con un objetivo propio y bien diferenciado, las cuales son:
  • Captación: Enfocado a obtener y recabar la información necesaria de todas aquellas fuentes necesarias.
  • Análisis: En ella se analiza la completitud e idoneidad de la información recabada atendiendo a la naturaleza de la petición.
  • Formalización: Desarrollo del Documento de Requisitos del Usuario (DRU).
  • Verificación y Validación: Comprobación de la completitud del DRU, el cumplimiento de estándares y la comprobación con el cliente técnico y algún cliente usuario de que hemos entendido lo que quieren y necesitan.

jueves, 21 de diciembre de 2006

Definición de la Calidad

Introducción a la calidad
El entorno de Sistemas de Información tiene asociado muchos conceptos asociados, y uno de los más complejos y que más impacto proporcionan es la calidad, ya que, según veremos más adelante, según como definamos y caractericemos la calidad dependerá qué como realizaremos.

Siguiendo la definición que proporciona la Real Academia Española, calidad se define como “propiedad o conjunto de propiedades inherentes a algo, que permiten juzgar su valor”, y es justamente esto lo que queremos definir, determinar, verificar y validar.

Importancia de la calidad en la ingeniería de requisitos
La razón por la que debemos tener en cuenta, en primer lugar el concepto de calidad, es porque es lo que nos va a determinar un conjunto de mínimos y máximos a realizar y a tener en cuenta para atender a toda petición que realicemos la ingeniería de requisitos.

Dicho esto, y ateniéndonos a lo que aparece en el siguiente gráfico, es la calidad la que nos determinará el proceso, las técnicas y las herramientas que debemos utilizar.


Definición de elementos de la calidad
La definición de qué elementos determinará la calidad y establecerá el rango de mínimos y máximos. Entre los factores que debemos tener en cuenta están los siguientes:
  • Entorno empresarial: Tal y como definía en el primer artículo, no será lo mismo un entorno de administración pública, empresa de servicios o área de IT que da servicios a la propia empresa.
  • Criticidad: No es lo mismo crear un producto que gestione el espacio aéreo de un país, que una aplicación de gestión presupuestaria de una PYME, ya que en el primer caso debemos tener en cuenta aspectos relacionados con vidas humanas, y no en el segundo caso.
  • Legislación: Existen ciertos aspectos legislativos que dependiendo del país, sector empresarial, nivel de responsabilidad empresarial, etc., que influyen mucho y que nos permiten ser más o menos estrictos.
  • Estándares de calidad corporativa: El enfoque de la ingeniería de requisitos difiere si tenemos que atenernos a un tipo de “sello” de calidad de corporativa como ISO.
  • Mercado: Hoy en día aspectos como el time-to-market, referido a la velocidad de respuesta frente a las necesidades de nuestro público objetivo (como empresa) o a la paridad de los servicios ofrecidos por la competencia, nos obligan a alinearnos con las unidades de servicio.
  • Recursos: El nivel, calidad y número de recursos disponibles además de definir los niveles esperados de capacidad, también define los de calidad.
  • Tipología de las Peticiones: Es muy importante conocer y determinar aspectos relativos al tipo de peticiones que recibimos, como ámbito y plazo, ya que debemos diferenciar aquellas que son pesadas (coordinación de muchas personas y/o áreas), de las ligeras (pequeñas modificaciones o adaptaciones).

Impacto de la calidad
Los elementos o parámetros y políticas de calidad definidas impacta directamente en:
  • Los procesos: Definen qué hacemos y quién lo hace. Dados unos procesos estándar, estos se verán aligerados o engrosados atendiendo a los elementos descritos anteriormente para cada petición.
  • Los métodos: Definen cómo lo hacemos. La aplicación de ciertos métodos viene determinado por aquellas cosas que podemos o no hacer, además de la cultura empresarial y de entorno.
  • Las herramientas: Con qué lo hacemos. En este punto nos encontraremos desde plantillas, documentos, herramientas informáticas, herramientas físicas, etc., las cuales vendrán determinadas o influenciadas por cómo lo hacemos.
El orden anterior no es casualidad, por que ¿qué nos ha ocurrido cuando nos hemos visto supeditados a una herramienta específica para la realización de un proyecto? ¿o a la utilización de determinado lenguaje de programación? En la mayoría de los casos esas limitaciones han producido una ventaja y un inconveniente:
  • Ventaja: Obtenemos un enfoque más concreto de los elementos que tenemos que tener en cuenta y disminuye el nivel de incertidumbre.
  • Inconveniente: El enfoque al que nos obliga puede ser contraproducente y no el más idóneo y ser un lastre para conseguir los objetivos propuestos.

miércoles, 20 de diciembre de 2006

Introducción a la Ingeniería de Requisitos

¿Qué es la ingeniería de requisitos?

La ingeniería de requisitos es el conjunto de procesos, técnicas y herramientas que rige toda petición de las unidades de negocio para conseguir:

  • Una comprensión de la necesidad o problemática completa.
  • Conocer la complejidad e impacto en el negocio.
  • Realizar el primer acercamiento al lenguaje utilizado en Sistemas de Información.
¿Quién participa en la ingeniería de requisitos?
Para la correcta consecución de los objetivos de la ingeniería de requisitos necesitamos la identificación y participación de los siguientes roles:
  • Cliente administrativo: Es aquella persona o personas que tienen la responsabilidad de alinear las peticiones realizadas al área de IT con sus objetivos estratégicos y de adecuar los recursos necesarios para su consecución.
  • Cliente técnico: Es aquella persona o personas que tienen la responsabilidad de proporcionar una visión global de las necesidades desde un punto de vista operativo (qué hay que hacer) y de realizar una validación del producto (DRC) obtenido.
  • Cliente usuario: Es aquella persona o personas que tienen la responsabilidad de proporcionar una visión específica de las necesidades desde el punto de vista técnico (cómo hay que hacerlo).
  • Ingeniero de Requisitos: Es aquella persona o personas que tienen la responsabilidad de captar la información de los diferentes clientes, analizarla y formalizarla en un documento de requisitos del cliente garantizando la adecuación del producto realizado (DRU) y la calidad del mismo. En algunos ámbitos se le denomina analista de negocio.
  • Consultor: Es aquella persona o personas, internas o externas a la organización, que sirven como apoyo al ingeniero de requisitos para:
    • Comprender mejor el negocio del cliente y obtener una visión más concreta de sus necesidades, tanto a corto plazo como futuras.
    • Colaborar en el desarrollo del DCU como experto en los procesos, técnicas y herramientas utilizadas en la ingeniería de requisitos.
Debemos tener en cuenta que una misma persona puede desempeñar uno o más roles.

¿Cuándo se realiza la ingeniería de requisitos?
La ingeniería de requisitos es uno de los primeros pasos en todo ciclo de vida de los proyectos de software en el ámbito de TI. Independientemente de si estamos hablando de un ciclo en cascada, iterativo o ágil, se debe seguir un proceso de ingeniería de requisitos que se adapte a cada una de las metodologías utilizadas.

Lo que sí está claro, es que es prácticamente imposible tener un DCU completo desde el inicio, lo cual nos obliga a diversas revisiones del documento, por lo que propondremos un proceso guía iterativo e incremental con el objetivo de tener diversos niveles de concreción y profundidad en cada una de ellas, y que se pueda adaptar al ciclo de vida global de desarrollo de proyectos en la organización.

¿Dónde se aplicaría la ingeniería de requisitos?
La ingeniería de requisitos en el ámbito de sistemas de información, tiene tres ámbitos de aplicación:
  1. Administración Pública: Como trabajo previo a la preparación de pliegos técnicos.
  2. Empresas de Servicios: Ayudará al desarrollo de la presentación de propuestas y podrá ser cumplimentado una vez que haya que desarrollar el DRC como entregable intermedio del producto comprometido.
  3. Áreas de Sistemas de Información: En el entorno de las empresas que dan servicio a las unidades de negocio dentro de su propia organización para definición del alcance de las peticiones, pudiendo formar parte del contrato.
¿Por qué se realiza la ingeniería de requisitos?
Para poder responder a esta pregunta nos tenemos que centrar en su ámbito de aplicación, los proyectos, es decir, ¿por qué es necesaria la ingeniería de requisitos en los proyectos? Como toda actividad debe realizar algún tipo de aporte significativo, sino no es justificable su realización, debemos avanzar un poco más y preguntarnos ¿qué inconvenientes proporciona la no realización la ingeniería de requisitos en los proyectos?

Según una referencia realizada por Juan Palacio Bañares en el Compendio de Ingeniería del Software I, la causa de fracaso de los proyectos responde a la siguiente distribución:


Teniendo en cuenta todos aquellos aspectos que están implicados en la ingeniería de requisitos, el porcentaje total asociado es un mínimo de un 52%. Si representáramos estas causas tipificadas en un diagrama de Pareto, sería la principal causa de fracaso de los proyectos, por lo que sería el primer elemento a afrontar para solucionar las causas de fracaso.

Bibliografía inicial
[1] Amador Durán Toro. Un Entorno Metodológico de Ingeniería de Requisitos para Sistemas de Información. http://www.lsi.us.es/~amador/.
[2] Roger S. Pressman. Ingeniería del Software, un enfoque práctico. 6ª edición.
[3] Juan Palacio Bañeres. Compendio de Ingeniería del Software I.