Prototipado

En el desarrollo del software existe un método de validación, el cual consiste en la creación de una maqueta o versión del producto final, con el fin de comprobar la correctitud y completitud del ERS.

Pero, ¿qué es un prototipo?, un prototipo es un modelo a escala, pero no tan funcional como para ser evaluado como el producto final, ya que a pesar de tener funciones del sistema, éste no tiene la totalidad de las funciones que se verán en el producto final. Los prototipos suelen utilizarse mayormente en dos fases del proyecto:

-Etapa de análisis: se utilizan prototipos para obtener los requerimientos del usuario, como principal objetivo tienen obtener y validar los requerimientos esenciales, manteniendo abiertas las opciones de  implementación.

-Etapa de diseño: se utilizan para evaluar aspectos de la implementación realizada, el propósito que tienen es, basándose en los requerimientos obtenidos previamente, mostrar las ventanas, navegación, interacción, controles y botones al usuario y de esta forma obtener una retroalimentación que permita mejorar el diseño de la interfaz del producto.

Existen muchos tipos de prototipos, algunos de ellos son:

Cada tipo de prototipo necesita de tiempo para su construcción, por lo que la respuesta para saber cuál es recomendable construir consta de dos factores:

-Recursos y tiempo disponibles: cuanto más limitados sean estos recursos, más conveniente será crear prototipos sencillos.

-Fidelidad deseada: si el usuario no logra entender el prototipo por tener una fidelidad muy baja, se deberá pasar a construir prototipos de una fidelidad mayor con la intención de que el usuario o cliente logre entender de qué trata el prototipo realmente.

Algunas ventajas que contiene la creación de prototipos son:

-Modificación del sistema en etapas tempranas de su desarrollo: los cambios iniciales durante el desarrollo de un proyecto son menos costosos que si se realizaran en etapas tardías del proyecto.

-Eliminación de requerimientos indeseables: durante la creación de prototipos y la evaluación de éstos con el cliente se pueden encontrar requerimientos que quizás no lleguen a ser como el cliente pensó que serían cuando los solicitó.

-Diseño de sistemas acorde a las necesidades del cliente: al igual que el punto anterior, durante la revisión de los prototipos con el cliente se pueden cambiar los requerimientos que se encontraron en un principio por otros que sean acorde a los que el cliente espera.

Algunas desventajas son:

-Adoptarlo como el sistema final: los usuarios pueden considerar el prototipo como si fuera el sistema final aun cuando está incompleto o es inadecuado para su uso.

Es importante saber el tipo de prototipo que se desea implementar de acuerdo a la fidelidad que busca el cliente en éste, además es necesario utilizar correctamente el tiempo del que se dispone para la creación de los prototipos, ya que es tiempo valioso en el desarrollo del sistema.

BURCH J. G. y GRUDNITSKI G.,1997, Diseño de Sistemas de Información. Megabyte Noriega Asociados.

KENDALL, K. E. y KENDALL J. E.,1991, Análisis y Diseño de Sistema. Prentice –Hall Hispanoamericana S.A.

Elicitación de Requerimientos

¿Qué es la elicitación de requerimientos? Es la parte principal en el desarrollo de proyectos de software y tiene un impacto alto en el diseño y en las demás fases del ciclo de vida del producto que se piensa desarrollar. La elicitación se considera como la primera etapa en el proceso de abstraer una idea o comprensión mas acertada del problema que se desea resolver con el software.

Existen varias técnicas para la elicitación de requerimientos, algunas son:

- Entrevistas

Son reuniones normalmente entre dos personas, pero se pueden realizar con más personas, en las que se plantean una serie de preguntas para obtener respuestas que ayuden a entender el contexto de un determinado dominio de problemas.

Las entrevistas deben planificarse, determinando su duración, los temas a tratar y seleccionando el número mínimo de personas a entrevistar dentro de la organización en función de su perfil profesional.

- Estudio de documentación

Consiste en realizar una lectura profunda basada en documentos que ayuden a encontrar una solución a un problema especifico.

- Observación in situ

Consiste en la observación directa de las prácticas que se realizan en la organización para la que se va a desarrollar el software.

Existen algunas variantes de la observación in situ como son la inmersión dentro de la organización para la que se va a desarrollar el software o la realización de periodos de aprendizaje por parte de los ingenieros de requisitos, en las que la observación pasiva se cambia por una participación en los procesos a observar como si fuera un miembro más del personal de la organización bajo estudio.

- Joint Application Development

Se basa en realizar reuniones integradas por miembros del equipos de desarrollo y miembros de la organización a la que se le desarrollará el software. Durante la reunión el coordinador planea los puntos a discutir para determinar los objetivos y requisitos generales del sistema a desarrollar.

- Tormenta de ideas

Es una técnica de reuniones en grupo, cuyo objetivo es la generación de ideas en un ambiente libre de criticas o juicios.

- Talleres de trabajo

Son reuniones integradas por clientes y usuarios y parte del equipo de desarrollo. Se trata de reuniones en las que se exploran distintos casos de uso sin llegar a un nivel profundo del caso de uso, evitando de esa forma un nivel excesivo de detalle, lo que alargaría las reuniones más tiempo del necesario.

Existen muchas formas para la elicitación de requerimientos y todas funcionan de diferente forma de acuerdo al grupo con el que se desean obtener requerimientos para un sistema que se desea desarrollar. Antes de escoger una técnica, se debe analizar la organización y el sistema que se quiere realizar para de esta forma poder escoger la técnica que permita obtener requerimientos de una forma mas sencilla y mas detallada o con una mejor compresión.

M. G. Christel & K C. Kang. “Issues in Requirements Elicitation”. Technical Report CMU/SEI-92-TR-012, ESCTR-92-012. Software Engineering Institute, Carnegie Mellon University, 1992.

I. Sommerville & P. Sawyer. “Requirements Engineering: A Good Practice Guide”. John Wiley & Sons, 1997.  

Modelo de casos de uso

¿Qué es un caso de uso?. Son una descripción de los pasos o actividades que se deben realizar para llevar a cabo algún proceso. Es una secuencia de interacciones que se desarrollan entre un sistema y los actores en respuesta a un evento que inicia un actor principal en el propio sistema. 

Los diagramas de caso de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante la interacción con usuarios u otros sistemas. El uso de éstos es muy común para la obtención de requisitos funcionales en el desarrollo de un sistema. 

La idea de utilizar casos de uso es evitar el lenguaje técnico, prefiriendo así la lengua que utilice el usuario final, facilitando el entendimiento de éstos. Los casos de uso son a menudo elaborados en colaboración con el cliente junto con los analistas de requerimientos.

Un caso de uso se centra en describir como alcanzar una meta o tarea única, esto significa que a veces es necesario especificar decenas o centenares de casos de uso para un solo proyecto. 

Un caso de uso debe:

• Describir una tarea del negocio que sirva a una meta
• Tener un nivel apropiado de detalle
• Ser bastante sencillo

Durante la creación de un caso de uso se pueden dar algunas situaciones como:

• Un actor se comunica con un caso de uso
• Un caso de uso extiende de otro caso de uso
• Un caso de uso incluye otro caso de uso

Utilizar casos de uso tiene mucho éxito en sistemas interactivos, ya que permite ver observar la intención que tiene el actor al hacer uso del sistema.

Una limitación que tienen los casos de uso es que aunque son útiles para establecer los requisitos de comportamiento de un sistema, no permiten establecer completamente los requisitos funcionales ni determinan los requisitos no funcionales.

A pesar de ésto último, es muy importante desarrollar casos de uso para poder entender el comportamiento que tendrá el sistema durante su ejecución de acuerdo a las acciones que realice el usuario.

Jacobson, I., P. Jonsson, M. Christerson and G. Overgaard, Ingeniería de Software Orientada a Objetos - Un acercamiento a través de los casos de uso. Addison Wesley Longman, Upper Saddle River, N.J., 1992.