Entradas etiquetadas como Requisitos

Requisitos legales

Se le llama requisitos legales a aquellas condiciones, impuestas por ley, que deban ser cumplidas por el proyecto, ya sea en la ejecución del proyecto como tal o en la funcionalidad provista por el sistema terminado. Los requisitos legales nacen de las leyes vigentes y que apliquen a nuestro proyecto de desarrollado ya sea por su naturaleza o por la jurisdicción bajo la cual se encuentra nuestra empresa.

Los requisitos legales surgidos por la naturaleza de nuestro proyecto, son aquellas obligaciones legales que puedan existir para ciertos tipos de aplicaciones. Son ejemplos comunes: las aplicaciones bancarias, los sistemas electorales y aquellos sistemas que manejen información privada del publico.

Las aplicaciones bancarias se encuentran sometidas a una amplia gama de requisitos legales. Tanto de confidencialidad como de confiabilidad en las transacciones. Se suele incluir en la legislación de muchos países aspectos tales como los registros de las operaciones, la interoperatividad de los sistemas, la criptografía a utilizar y las garantías de correcto funcionamiento.

Un poco más recientes, son las aplicaciones para sistemas electorales. En algunos países de la región así como en algunas jurisdicciones locales en los Estados Unidos, se han comenzado a utilizar sistemas de voto electrónico, ya sea en sustitución de las votaciones manuales o como complemento de estas en casos específicos. Como es natural esperar, los procesos de votación electrónica han de contar con gran cantidad de partes interesadas o stakeholders, razón esta por la cual hay grandes requerimientos de transparencia, confiabilidad y exactitud exigidos a estos sistemas por la ley y los reglamentos respectivos.

Incluso en aplicaciones más comunes pueden existir requisitos legales a considerar. Aquellos sistemas que recojan información de sus usuarios y que a la vez, permitan el registro del publico general como usuarios de las mismas, suelen estar sometidas a regulaciones sobre la seguridad de los datos.

Una variación también muy común es la de restringir el registro de menores de edad, por así requirlo las leyes de defensa de los niños u otros grupos protegidos.

Los requisitos legales surgidos por la jurisdicción son una matería de amplia discusión en estos días de Internet. En los viejos días era fácil identificar la jurisdicción competente, pues esta coincidia con el área geografica en que se ubicaba nuestra empresa. Hoy en día en cambio, es necesario considerar jurisdicciones adicionales, ya que nuestros productos pueden ser utilizados en otros países con más facilidad que nunca antes, y el incumplir con los eventuales requisitos legales de otras jurisdicciones pueden causar problemas con la comercialización de nuestras aplicaciones.

Todo esto significa que en aplicaciones de gran escala es conveniente obtener asesoría legal de parte de un escritorio juridico o abogado, tomando lo que este nos indique como requisitos funcionales o no funcionales, según sea el caso.

Anuncios

, , , , , ,

3 comentarios

Líneas Base

Una línea base es el compromiso, negociado y aceptado, que se alcanza con el cliente para que este comprenda que hemos de poner un alto en la captación de necesidades con miras a enfocarnos por unos días, en construir aquello nos ha pedido hasta el día de hoy.

Como estrategia de organización del proyecto, su principal virtud es la de permitir la gestión de requerimientos, al introducir pausas regulares en las exigencias del cliente, con miras a ver primero el logro de las primeras ideas, antes de introducir nuevas variaciones.

Al contar con las líneas base como estrategia de gestión de requisitos, es posible disminuir el riesgo que representan para los proyectos las especificaciones incompletas: simplemente no vamos a aspirar a tener todas las cartas en la mano, vamos a trabajar con lo que tenemos hasta un punto y luego, alcanzados los primeros objetivos, volver a recoger lo que se nos haya escapado la primera vez.

Por lo mismo, es posible también reducir el riesgo de desorden en los requisitos del proyecto. Hay una disciplina en el equipo del trabajo, que se le puede explicar al cliente. Dicho de otra forma, es una forma educada de pedirle paciencia.

, , , , , , , ,

Deja un comentario

Definimos Terminos de Referencia como…

De tanto en tanto nos vamos a encontrar con que la organización que requiere el desarrollo elabora para nosotros un documento de requisitos, en formato libre, al que llaman no sin cierto orgullo “Términos de Referencia”. La práctica viene de otras áreas de la ingeniería donde una petición simple de parte del cliente puede ser analizada y convertida en un trabajo completo, con un razonable nivel de calidad.

Sin embargo, en Ingeniería del Software los términos de referencia no pueden ser utilizados con buenos resultados. Típicamente son documentos incompletos, que mezclan requisitos con análisis e incluso con diseño, cuya existencia es señal de acceso limitado a los stakeholders por parte de la organización de desarrollo. En otras palabras: si nos dan Términos de Referencia tendremos problemas más adelante.

El acto de especificar un sistema de software a demostrado repetidamente ser difícil. Es necesario indicar un gran número de aspectos distintos, mantener la diferencia entre requisito y solución, actuar primero a lo ancho, capturar valor de negocio, entre otros puntos que son propios de nuestra profesión y que resultan incompatibles con las premisas detrás de un documento de términos de referencia.

Veamos algunos de estos puntos en detalle. Comencemos por la definición:

Términos de Referencia: Documento elaborado por el cliente con indicaciones de las especificaciones requeridas al sistema de software por desarrollar.

En otras palabras: en un documento de Términos de Referencia el cliente ha querido ahorrarnos a nosotros el trabajo de especificación. Muy amable de su parte, pero si la organización de desarrollo no interviene en la especificación entonces nos enfrentamos a varios problemas:

  • Se ha asumido un modelo de ciclo de vida en cascada. Los modelos actuales son iterativos, repitiendo múltiples veces el paso de especificación. Un esquema más rígido, como el cascada, suele incrementar el riesgo de fracaso del proyecto.
  • Si el cliente siente que ya ha desarrollado los requisitos a satisfacción puede verse renuente a dedicar esfuerzos nuevos en este asunto. Tendríamos entonces problemas al presupuestar horas para actividades de elicitación de requisitos.
  • El documento en si mismo es un problema. Su estructura es necesariamente ad-hoc, independiente de la metodología que se vaya a seguir en el desarrollo. Puede ser difícil de analizar y haber dejado puntos importantes por fuera.

Si solo fuera para tener una idea del proyecto, básicamente cualquier documento o carta es bueno. Sin embargo los términos de referencia vienen con intenciones más amplias: sustituir la especificación profesional por un único documento, valido para el desarrollo así como para el cálculo de la oferta económica. No importa como lo vea, los términos de referencia son un problema.

Sin embargo, los Términos de Referencia son también un hecho. En algunas situaciones incluso son lógicos: en las licitaciones se distribuyen especificaciones para acto seguido requerir ofertas de costo cerrado. Si esto funciona bien en tantos sectores distintos, el cliente puede pensar que ha de valer también para sus proyectos de software.

Por lo anterior será inevitable que nos topemos con estos documentos. Tendremos que desarrollar entonces alguna técnica para sacar el mayor provecho de los mismos, sin importar cuan diferentes sean de caso en caso y de cliente en cliente. A fin de cuentas ellos son el cliente, y uno no puede ser tan descortez de desachar los resultados de su trabajo.

Finalmente me gustaría recordar que todos sin excepción hemos luchado con los términos de referencia de nuestros profesores y preparadores. ¿Cuantas veces en nuestros estudios tuvimos que llevar a cabo un proyecto a partir de un breve enunciado carente de toda norma de calidad? Así como entonces fue difícil producir un programa autenticamente útil a partir de dichas especifiones, aquí nos va a costar mucho trabajo en conseguir satisfacer el cliente si nos atenemos unicamente a lo dicho en los malvados, digo, en los variables Términos de Referencia.

, , , , , , , ,

3 comentarios

Flujos de eventos alternativos

En un caso de uso, los flujos de eventos se refieren a los pasos que alternativamente van realizando los actores y el sistema en el contexto del requisito funcional capturado en el caso. Dichos pasos por claridad, se separan en el flujo principal y los flujos alternativos; de forma tal que en el flujo principal representamos el día feliz, donde todo ocurre sin problemas y en los flujos alternativos lidiamos con las situaciones de error y el comportamiento esperado del sistema en respuesta a dichos errores.

Es necesario entonces contar con una aproximación sistemática sobre como disponer los flujos de eventos principal y alternativos, de forma que capturen en forma clara y precisa cada condición que el flujo del día feliz ha asumido como libre de error pero que es a su vez, el punto de inicio de un flujo alternativo.

La idea aquí es la de indicar el paso del flujo principal y la condición precisa que de violarse hace que se ejecute el flujo alternativo. De ser posible la condición ha de estar expresada en términos del modelo de dominio de forma tal que facilitar su traducción al sistema software.

Los pasos del flujo alternativo han de tener una enumeración propia de forma tal que no choquen los unos con los otros ni con los pasos del flujo principal. La forma exacta en que vamos a enumerar es cosa de cada quien, por lo que es un punto a documentar como parte del Plan de Gestión de Requisitos, documento este que suele ser parte del Plan de Desarrollo de Software.

Un ejemplo de todo lo anterior puede ser visto como parte del ejemplo de caso de uso en este blog. En el ejemplo referido se hace mención al caso de uso “llamada de voz” y se ha señalado la condición de error “número incorrecto”. Veamos una versión ligeramente modificada del caso de uso de ejemplo para discutir como se puede implementar los flujos alternativos:

Código: CS-0100.
Nombre: Llamada de voz.
Actores: Usuario.
Descripción: El usuario del teléfono levanta el auricular y marca el número de destino. Al completar la secuencia de dígitos la conexión se realiza. Por medio de tonos particulares el sistema indica el estado de error y de progreso en la conexión.
Precondición: El teléfono está colgado.
Postcondición: Ninguna.
Diagrama:

Sencillo Modelo de Casos de Uso

Flujo Principal:
Paso 1 – Usuario:
Levanta el auricular.
Paso 2 – Sistema: Da el tono de marcado.
Paso 3 – Usuario: Indica el número de teléfono.
Paso 4 – Sistema: Realiza la conexión. Da tono de aviso en tanto se levanta el teléfono del lado contrario de la conexión. Permite la conversación al hacerse efectiva la conexión.
Paso 5 – Usuario: Conversa y al finalizar esta, tranca el teléfono.
Paso 6 – Sistema: Termina la conexión.

Flujo alternativo: Número incorrecto
Paso 3 – Sistema:
Presenta tono de error. El caso de uso termina.

Flujo alternativo: Desconexión inesperada
Paso 5.1 – Sistema:
Detecta un fin inesperado de la conexión. Indica todo de error.
Paso 5.2Usuario: Tranca el teléfono.
Paso 5.3 – Sistema: Registra error. El caso de uso termina.

Tabla 1 – Ejemplo de caso de uso con flujos alternativos

Como ya dije, este ejemplo es una modificación del ya visto en el post ejemplo de caso de uso, donde ahora se han considerado dos flujos alternativos, uno para la condición de número incorrecto y otro para la desconexión inesperada.

La condición ha sido indicada en términos abstractos, comprensibles desde una perspectiva técnica y luego se ha indicado el paso en que dicha condición se puede violentar. En el flujo alternativo del número incorrecto el paso es el tres y en caso de problemas las acciones a tomar son solo una: el sistema presenta tono de error.

Otro tanto puede ser dicho en el segundo flujo alternativo. La desconexión inesperada sin embargo a dado lugar a tres pasos. El sistema detecta un fin inesperado e indica tono de error. El usuario entonces tranca el teléfono. Finalmente el sistema registra el error. Estos tres pasos han sido enumerados con la secuencia 5.1, 5.2 y 5.3, de forma de hacer referencia a que son un flujo alternativo del paso cinco del flujo principal al tiempo de mantener una secuencia numerica propia.

, , , , , , , , ,

7 comentarios

El flujo de eventos del día feliz

Un flujo de eventos consiste en enumerar los pasos que sucesivamente realizan los actores y el sistema en el contexto de un caso de uso. Es decir, que un flujo de eventos es en su forma más básica un simple listado de acciones, que corresponden con un caso de uso en concreto.

Si pensamos un poco en el tema nos podemos percatar que la funcionalidad promedio de un caso de uso ha de tener bifurcaciones e incluso bucles. Esto es natural pensarlo ya que hay una similitud muy fuerte entre la noción de algoritmo y la de flujo de eventos vistos estos como listado de pasos.

Sin embargo, a diferencia de las notaciones formales utilizadas para expresar algoritmos, los flujos de eventos se construyen en lenguaje natural, lo cual impone limitaciones sobre cuan precisamente podemos indicar condiciones y bifurcaciones sin comprometer la claridad.

La solución a este problema claro esta, es la de tener más de un flujo de eventos. Tendremos uno sencillo y claro, que exprese lo que ha de ocurrir en el caso más probable y a su vez, tendremos otros flujos alternativos que lidien con las condiciones de error o casos que requieran bifurcación.

Al flujo de eventos principal, ese que contiene el caso más probable, se le llama Flujo de Eventos del Día Feliz, como forma de hacer referencia a la ausencia de condiciones de error. En otras palabras, le llamamos día feliz ya que en este flujo de eventos principal vamos a asumir que todo ocurre de la mejor forma: el actor tiene disponible la información y la indica sin fallas, el sistema puede completar todas las operaciones y así sucesivamente para cada posible desviación. En el flujo del día feliz simplemente todo ocurre correctamente.

, , , , , , , ,

7 comentarios

Todo requisito debe ser preciso y legible

La especificación de un sistema es un trabajo retador. En él participan no solo los desarrolladores de aplicaciones, sino también los clientes. Esto significa que la especificación de requisitos, ya sea como casos de uso o como declaraciones tradicionales tipo “el sistema debe…” ha de ser entendida a la vez, por lo clientes y por los desarrolladores. Dicho en otras palabras: la especificación contiene detalles técnicos que los clientes luchan por entender, a la vez que incluye información sobre el negocio que es nueva y potencialmente confusa para los desarrolladores.

Esta situación nos obliga a luchar por dos atributos básicos en todo nuestro sistema de requisitos: la claridad y la precisión.

Precisión de un requisito. Un requisito es preciso cuando indica sin ambigüedad lo que se desea especificar. Debe ir directo al punto y evitar todo adorno en el lenguaje. Debe documentar solo un aspecto del sistema y lo debe de hacer en forma exacta.

Y también

Claridad o legibilidad de un requisito. Un requisito es legible cuando el lenguaje en el que esta escrito es fácil de entender, tanto por los clientes como los analistas. La legibilidad se extiende no solo a la especificación escrita, sino también a los formalismos gráficos como los diagramas de casos de uso.

Es curioso observar que en los cursos universitarios sobre el tema, los profesores tengan la presión de explicar métodos y técnicas avanzadas, como las relaciones de extensión e inclusión de casos de uso, forzando al estudiante a adoptar estar técnicas en forma demasiado temprana. Esto causa una deformación profesional en el estudiante, quien sale del curso con la creencia que es mejor una especificación sofisticada que haga uso de todo lo visto en el curso, en lugar de una aproximación más informal y relajada que puede en verdad ser entendida por el cliente.

El lugar correcto para la extensión y la inclusión, así como para todas las técnicas de modelado de requisitos más sofisticadas, es en aquellos dominios de aplicación donde los requisitos reales sean muy complejos. Es decir por lo tanto, que en la práctica el analista ha de hacer esfuerzos por mantenerse sencillo, normalmente no vale la pena la complejidad del modelo de requisitos.

También es de hacer notar, que en mi experiencia la mayoría de los clientes intentan hacer otro tanto. Ellos suelen expresar lo que necesitan en la forma más directa que tienen disponible, sin embargo dado que los clientes son a su vez profesionales en un área especifica, la forma correcta en la ellos se expresan suponen tensión a los desarrolladores, quienes deben luchar por desarrollar un vocabulario común con el cliente para poder comprender sin errores lo que este pide.

En conclusión: lo sencillo se entiende más y la especificación de un sistema ha de entenderse bien. Cuan sofisticado hagamos nuestro modelo de casos de uso o nuestro documento de especificación, no es ni de lejos lo que en verdad importa. Es mucho mejor un caso de uso sencillo pero que captura valor de negocio, que uno sofisticado que haga un uso abundante de las técnicas más esotericas de modelado.

, , , , , , , , , , ,

2 comentarios

Casos de uso: preferir la amplitud a lo detallado

Un caso de uso es la descripción de un escenario de interacción -un uso- entre un actor y el sistema. Dicho escenario captura el requisito funcional que el sistema ha de cumplir y documenta lo que se ha discutido entre el equipo de desarrollo y el cliente en una forma simple, de fácil lectura y razonablemente exacta.

Todo bien hasta aquí.

En sistemas reales, es inevitable encontrarse con las siguientes dos situaciones:

  1. Algunos requisitos quedan sin descubrir y se convierten en riesgos.
  2. Algunos requisitos muy especificados jamás encuentran un lugar en el desarrollo.

O en otras palabras, si no tenemos cuidado, tendremos casos de uso que especifican en detalle algo que esta por fuera del alcance del proyecto en tanto uno o más puntos importantes habrán quedado en el anonimato y nos atacaran en castigo a nuestro olvido.

Ambas situaciones son peligrosas y aún si las controlamos representaran costos imprevistos que pueden hacer peligrar el proyecto.

¿Como podemos evitar estos problemas? Sin querer decir que es una receta mágica, lo que la experiencia nos enseña es que un modelo de casos de uso (y quizás todo sistema de requisitos) ha de preferir documentar primero a lo ancho, cubriendo áreas cuanto más amplias mejor, del sistema a desarrollar, antes de descender a los detalles de las partes de mayor interés.

Si suponemos un desarrollo cualquiera, este consejo de ir primero a lo amplio y luego a lo detallado, significa que tendremos muchos casos de uso apenas en estado de borrador, que delinean a grandes rasgos lo que se pretende del sistema en términos de su funcionalidad y el alcance del proyecto. Luego, según vayamos atendiendo los requisitos en nuestras iteraciones o fases, podremos dedicar algo de tiempo en obtener los detalles de cada caso de uso de manera de desarrollar el sistema correcto.

Esta aproximación es interesante también desde el punto de vista de la gestión del proyecto. Es posible crear un plan de proyecto que dedique algunas semanas a la creación de un modelo de casos de uso muy amplio pero sin mayores detalles, para luego decir cuales casos de uso van en cada una de las iteraciones.

Claro que al gestionar nuestros proyectos de esta forma hay que priorizar los casos de uso, según el riesgo y según su relevancia para establecer una arquitectura estable, conceptos que ahora si podemos entender sin mayores problemas: del total de casos de uso identificados, detallamos en las primeras iteraciones aquellos que sean identificados como de alto riesgo o como de mayor impacto en la arquitectura del software.

La otra vía es casi imposible de practicar: documentar en detalle los requisitos aún antes de comenzar a desarrollar la primera línea del código es decir que todo se puede saber de antemano, por lo que para aquellos de entre nosotros que carecemos de la omnisciencia vamos inevitablemente a cometer errores.

Entonces no tentemos al destino. Los requisitos cambian durante el tiempo de vida de los proyectos; no perdamos el tiempo capturando detalles que van a cambiar. Por otra parte, identificar a grandes rasgos las principales características que se nos piden es vital para tener una idea de la magnitud del desarrollo así como de los recursos que tendremos que invertir (tiempo, dinero, etc.) y finalmente, no tiene mucho sentido excluir a los requisitos de la planificación del proyecto, por lo que tenemos de una u otra forma que integrar a los casos de uso en el diseño del proceso de desarrollo.

Todo lo anterior nos obliga a todos quienes practicamos el desarrollo guiado por casos de uso a trabajar primero a lo ancho: prefiriendo lo amplio a lo detallado en tanto dichos detalles no sean impresindibles.

, , , , , , , ,

Deja un comentario