Herramientas para la obtención, análisis y especificación de requisitos

Enviado por Maidileydys Castellano Báez

Partes: 1, 2

Resumen

Las fases de obtención y análisis dentro de la Ingeniería de requisitos tienen su fin en la comprensión y concepción de las funcionalidades que el software debe cumplir. Funcionalidades que deben ser aprobadas y aceptadas por los clientes y el equipo de desarrollo. El desconocimiento o falta de experiencia de algunos ingenieros de software para lograr obtener la lista de requisitos funcionales afecta la calidad del producto, los tiempos de desarrollo y su imagen ante los clientes.

El presente trabajo pretende exponer un conjunto de actividades mediante las cuales se emplearán herramientas que permitan obtener la lista de requisitos y la validación de la misma con los clientes. En él se definen 7 actividades para la obtención, análisis y especificación de requisitos, dentro de las cuales se proponen herramientas como: una guía de preguntas para realizar en una entrevista, los modelados de procesos de negocio para describir el entorno actual, el modelado de la base de datos y los prototipos interfaz para la validación de los requisitos. Por último se muestra en caso de estudio aplicando cada una de las actividades y herramientas definidas, con el fin de lograr una mejor comprensión de la propuesta.

Palabras clases: Entrevista, Especificación de requisitos, Herramientas, Ingeniería de requisitos, Levantamiento de requisitos, Software.

Introducción

Según el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) un requisito es: "Una condición o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado. Una condición o capacidad que debe estar presente en un sistema o componentes de un sistema para satisfacer un contrato, estándar, especificación u otro documento formal." (Chaves, 2005)

Un proyecto de software fundamenta su existo en la correcta obtención de sus requisitos mediante la colaboración y comunicación fluida entre clientes, usuarios, analistas y desarrolladores. Para lograr dicha comunicación se establece la Ingeniería de requisitos como "etapa particularmente crítica en el proceso de software ya que los errores en esta etapa originan inevitables problemas posteriores en el diseño e implementación del sistema." (Sommerville, 2005). De ahí que la Ingeniería de requisitos facilita el mecanismo apropiado para comprender lo que desea el cliente.

La Ingeniería de requisitos presenta diferentes faces entre las que se encuentran, según el modelo de guía para la mejora o evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software (CMMI), las siguientes:

Obtención (elicitación) de requisitos.
Análisis de requisitos.
Especificación de requisitos.
Validación de requisitos.
Administración de requisitos. (Team CMMI Product, 2006)

Las fases de obtención y análisis tienen como objetivo fundamental "obtener los requisitos del sistema por medio de la observación de los sistemas existentes, discusión con los usuarios potenciales y proveedores, el análisis de tareas, etcétera. Esto puede implicar el desarrollo de uno o más modelos y prototipos del sistema que ayudan al analista a comprender el sistema a especificar." (Sommerville, 2005). El gran desafío es averiguar y expresar claramente lo que los clientes necesitan. Existen múltiples técnicas que pueden ayudar en el problema que representa la obtención de requisitos de un producto, por ejemplo: la realización de entrevistas, reuniones, cuestionarios, la utilización de casos de uso, escenarios o prototipos de interfaz.

En la especificación de requisitos el analista y los desarrolladores tratarán de utilizar lenguajes de modelado o notaciones para el modelado, con el objetivo de dejar documentada la información recopilada durante la obtención y análisis de los requisitos. UML es un Lenguaje Unificado de Modelado que se utiliza como lenguaje gráfico para visualizar, especificar, construir y documentar artefactos de un sistema de software. Sirve de apoyo a la mayoría de los procesos de desarrollo orientados a objetos, captando la información sobre la estructura estática y el comportamiento dinámico de un sistema. (Rumbaugh & Jacobson, 2000)

Las obtención, análisis y especificación de requisitos en ocasiones se realiza de forma incorrecta de ahí que se afecte la calidad y la entrega en tiempo de muchos sistemas que se desarrollan en la actualidad. La mayoría de las veces este problema viene dado por la falta de experiencia de los analistas y desarrolladores en la obtención de requisitos y la falta de herramientas en las cuales se puedan apoyar para analizar y documentar las características de los negocios analizados.

El presente trabajo tiene como objetivo fundamental presentar herramientas que permitan realizar un análisis correcto de las características de los negocios a informatizar, con el fin de obtener los requisitos del sistema a desarrollar.

Desarrollo

Según la Según ISO 9000:2000 "Cualquier actividad, o conjunto de actividades, que utiliza recursos para transformar elementos de entrada en resultados puede considerarse como un proceso." (ISO, 2000)

Los resultados de un proceso han de tener un valor añadido respecto a las entradas y pueden constituir directamente elementos de entrada del siguiente proceso.

Los procesos dentro de su jerarquía pueden clasificarse en:

Macro-procesos: "Conjunto de procesos interrelacionados en la organización para el cumplimiento de la misión y el cumplimiento de los objetivos propuestos." (Monzón Quintana)
Procesos.
Sub-procesos: "Un Subproceso es un conjunto de actividades que tienen una secuencia lógica para cumplir un propósito. Un Subproceso es un Proceso por sí mismo, cuya finalidad hace parte de un Proceso más grande." (Bizagi)

La descripción detallada de los procesos de negocio ayuda a comprender e interpretar mejor las características de las entidades y facilitan el entendimiento entre clientes, analistas y desarrolladores, facilitando la obtención de los requisitos funcionales. Para lograr obtener una descripción detallada de los procesos que intervienen en el negocio que se desea informatizar los analistas de sistema utilizan diferentes técnicas como las encuestas, la observación y las entrevistas.

En el presente trabajo se propone el uso de herramientas como: las entrevistas, el modelado de procesos y el diseño de prototipos de interfaz, para lograr obtener un levantamiento de requisitos con calidad y que cumpla las expectativas de los clientes y equipo de desarrollo. Además se describen un conjunto de actividades a seguir para la obtención de requisitos que permiten aplicar dichas herramientas.

Propuesta de actividades para realizar un levantamiento de requisitos mediante herramientas que permitan el análisis de las características del negocio a informatizar:

Identificar cuantos procesos se desean informatizar.
Realizar la Guía de preguntas propuesta para cada uno de los procesos a informatizar.
Modelar cada uno de los procesos identificados utilizando la notación BPMN.
Identificar las actividades posibles a informatizar dentro de los procesos.
Obtener la lista de requisitos del sistema para cada uno de los procesos a informatizar.
Modelar la base de datos del sistema.
Realizar un prototipo de interfaz para los requisitos obtenidos.

Herramientas propuestas

Guía de preguntas a realiza en una entrevista:

Preguntas:

Para cada uno de los procesos identificados a informatizar realice las siguientes preguntas:

1. ¿Cuál es el nombre del proceso o que nombre usted le asignaría?
2. ¿Existe alguna política, regla, procedimiento, etc. por los que se rija el proceso a analizar?
3. ¿Cuándo se inicia el proceso?
4. ¿Quién inicia el proceso?

¿Qué rol ocupa dentro del proceso?

¿A qué área, instalación, empresa, etc. pertenece la persona que inicia el proceso?

5. ¿Se entrega alguna documentación o información al inicio del proceso?

¿Cuáles son los datos significativos que deben ser almacenados en el proceso de la información o documentación recibida?

¿Los datos de la información o documentación se recogen en algún registro, documento, forma, expediente, etc. de importancia para la entidad?
¿Es interés de la entidad la informatización del registro, documento, forma, expediente, etc.?

¿Cuál es el formato específico del registro, documento, forma, expediente, etc.?
¿El formato del registro, documento, forma, expediente, etc. puede ser modificado o es oficial?
¿Se realiza algún tipo de reporte, informe, etc. con los datos de la información recibida almacenados en el registro, documento, forma, expediente, etc. de la entidad?
¿Es interés de la entidad la informatización del reporte, informe, etc. con los datos de la información recibida almacenados en el registro, documento, forma, expediente, etc. de la entidad?

¿Cuál es el formato específico del reporte, informe, etc.?
¿El formato del reporte, informe, etc. puede ser modificado o es oficial?
¿Quién realiza el reporte, informe, etc.?
¿A qué área, instalación, empresa, etc. pertenece la persona que realiza el reporte, informe, etc.?
¿Quién recibe el reporte, informe, etc.?
¿A qué área, instalación, empresa, etc. pertenece la persona que recibe el reporte, informe, etc.?

6. ¿Quién recoge los datos de la información o documentación?

¿Qué rol ocupa dentro del proceso?

¿A qué área, instalación, empresa, etc. pertenece la persona que recoge los datos de la información o documentación?

7. ¿Qué otras actividades se realizan dentro del proceso luego de iniciado?
8. ¿En qué áreas, instalación, empresa, etc. se realizan dichas actividades?
9. ¿Qué roles realizan dichas actividades?
10. ¿Se recoge, entrega, registra, recibe, envía, etc. alguna documentación o información en las actividades del proceso?

¿Cuáles son los datos significativos que deben ser almacenados en el proceso de la información o documentación que se recoge, entrega, registra, recibe, envía, etc.?

¿Los datos de la información o documentación que se recoge, entrega, registra, recibe, envía, etc. son almacenados en algún registro, documento, forma, expediente, etc. de importancia para la entidad?
¿Es interés de la entidad la informatización del registro, documento, forma, expediente, etc.?

¿Cuál es el formato específico del registro, documento, forma, expediente, etc.?
¿El formato del registro, documento, forma, expediente, etc. puede ser modificado o es oficial?
¿Se realiza algún tipo de reporte, informe, etc. con los datos de la información recibida almacenados en el registro, documento, forma, expediente, etc. de la entidad?
¿Es interés de la entidad la informatización del reporte, informe, etc. con los datos de la información recibida almacenados en el registro, documento, forma, expediente, etc. de la entidad?

¿Cuál es el formato específico del reporte, informe, etc.?
¿El formato del reporte, informe, etc. puede ser modificado o es oficial?
¿Quién realiza el reporte, informe, etc.?
¿A qué área, instalación, empresa, etc. pertenece la persona que realiza el reporte, informe, etc.?
¿Quién recibe el reporte, informe, etc.?
¿A qué área, instalación, empresa, etc. pertenece la persona que recibe el reporte, informe, etc.?

11. ¿Existe algún sistema informático que intervenga en el proceso?

¿Cuáles son sus características fundamentales?

¿El sistema es interno, de la entidad o externo, que no pertenece a la entidad?
¿Cómo interactúa dentro del proceso en cada actividad?
¿Cuáles son las áreas, instalación, empresa, etc. que interactúan con el sistema?
¿Cuáles son los roles que interactúan con el sistema?
¿Se recoge, entrega, registra, recibe, envía, etc. alguna documentación o información de las actividades del proceso en el sistema?
¿Cuáles son los datos significativos almacenados de la información o documentación que se recoge, entrega, registra, recibe, envía, etc. en el sistema?
¿El sistema debe ser sustituido por el nuevo sistema o el nuevo sistema debe mantener una comunicación con el sistema existente?

¿Cuáles son los puntos de comunicación del nuevo sistema con el sistema existente?
¿Mediante cuales informaciones y actividades se comunicarán?

¿Cuáles son sus ventajas y desventajas dentro del proceso?

12. ¿Cuáles son las ventajas existentes en el proceso actual?
13. ¿Cuáles son las desventajas y problemas existentes en el proceso actual?

¿En qué actividades se encuentran dichos problemas y desventajas?

¿Cuáles pueden ser sus posibles causas?

14. ¿Existe la necesidad de modificar actividades o flujos de estas en el proceso actual para el mejor funcionamiento del sistema a desarrollar?

¿Cuáles son estas actividades o flujos de actividades que se necesitan modificar?

¿Cuáles son los responsables de autorizar el cambio en estas actividades o en este flujo de actividades?

Luego de realizar la entrevista a las personas involucradas directamente en las actividades de los procesos, se debe proceder a diseñar los mismos utilizando la notación BPMN. Business Process Modeling Notation o BPMN (en español Notación para el Modelado de Procesos de Negocio) es una notación gráfica estandarizada que permite el modelado de procesos de negocio, en un formato de flujo de trabajo (workflow). (Wikipedia.org). Para el diseño es necesario utilizar una herramienta que permita el modelado de proceso usando BPMN, un ejemplo de este tipo de herramientas es el Visual Paradigm.

Cuando se logra concluir el modelado de cada uno de los procesos se pueden presentar ante los clientes para su validación y a partir de ella comprobar si todas las características del negocio fueron recogidas correctamente. Luego los analistas identificarán cuales son las actividades de los procesos de negocio que pueden ser objeto de informatización. Seguidamente deben tomar estas actividades como punto de partida para el levantamiento y especificación de los requisitos del sistema a desarrollar.

Cuando se logra realizar una correcta especificación de requisitos se puede seguidamente obtener de forma sencilla el modelo de la base de datos con las entidades correspondientes a los procesos identificados. En cada proceso luego de su modelación y la obtención de sus requisitos se pueden identificar las entidades que pueden ser parte de la base de datos del sistema y sus interrelaciones. Una vez concluido este paso en cada proceso se puede modelar de manera general la base de datos del software a desarrollar.

Posteriormente los diseñadores, analistas y desarrolladores confeccionarán un prototipo de interfaz que permita mostrar al cliente como se pretende que quede el futuro sistema a desarrollar. De esta forma se usará este prototipo como técnica para la validación de los requisitos obtenidos.

A continuación se presenta un caso de estudio como guía para la realización del levantamiento de requisitos:

Complejo de Pizzerías

En un municipio X, existe un complejo de pizzerías las cuales actualmente presentan algunas dificultades para realizar el control de las mercancías que entran y salen de sus almacenes.

En las pizzerías el almacenero recibe semanalmente del Almacén Central los productos necesarios para prestar el servicio de ventas de pizzas. Cuando se reciben estos productos el almacenero comprueba que lo enviado por el Almacén Central coincide con la factura que trae el transportista (Representante del Almacén Central), si coincide la factura es firmada por el almacenero y el transportista y devuelta al Almacén Central. En caso de no coincidir la cantidad de productos enviados con la cantidad descrita en la factura, el almacenero confecciona un acta de no conformidad con el envío (El acta contiene la descripción de los productos faltantes o sobrantes con sus respectivas cantidades) que será firmada por el transportista y el almacenero para ser enviada una copia al Almacén Central adjunta a la factura.

Posteriormente el almacenero da entrada a cada producto en su tarjeta de estiba (ver Tabla 1), en caso de ser un producto que llega por primera vez al almacén el almacenero crea una tarjeta de estiba con los datos del producto y le da entrada en la tarjeta.

Cuando el Jefe de Cocina de la pizzería solicita un producto al almacén para brindar los servicios, el almacenero comprueba que la cantidad pedida se puede entregar y rebaja de la tarjeta la cantidad solicitada, anota dicha cantidad y el nombre del Jefe de Cocina que realizó la solicitud. Si la cantidad solicitada excede la cantidad existente en el almacén del producto pedido entonces se rebaja la cantidad existente del producto en almacén en su totalidad y se le informa al Jefe de Cocina que su solicitud no puede ser procesada completamente sino parcialmente con la cantidad que solo existe en almacén. Si no hay existencia del producto se le informa al Jefe de Cocina que su solicitud no puede ser procesada por la no existencia del producto.

Semanalmente el Jefe de Servicio solicita al almacenero que realice una orden de pedido de productos al Almacén Central la cual debe contener los productos que tienen gran demanda y los que están en el límite mínimo dentro del almacén y se consideran necesarios según la decisión del almacenero.

Los productos de mayor demanda son aquellos que son solicitados por cualquier Jefe de Cocina con una frecuencia de 4 veces por semana como mínimo. La frecuencia con que es solicitado un producto se anota por el almacenero en el informe semanal de productos solicitados (ver Tabla 2) cada vez que es solicitado un producto por un Jefe de Cocina, incluso cuando la solicitud no puede ser contestada por falta del producto en el almacén.

Los productos tienen una cantidad mínima de existencia en el almacén, si un producto llega a su cantidad mínima se deberá considerar por el almacenero como un posible producto a solicitar al Almacén Central.

Por órdenes del Jefe de Servicio el almacenero revisa diariamente el estado de los productos, en caso de que un producto se encuentre deteriorado, en mal estado, vencido, etc, el almacenero tiene que confeccionar una ficha para cada producto en mal estado (Ver Tabla 3) y separar los productos dañados del resto. Posteriormente enviar una solicitud de inspección y recogida de estos productos al Jefe de Servicio, el cual envía a un grupo de inspectores que son los encargados de comprobar que los productos está realmente dañados y que es la cantidad correspondiente, luego recogen los productos y el almacenero les da baja del almacén en cada una de sus tarjetas estibas poniendo la causa por la cual se les dio baja y además coloca la fecha de baja en la ficha del producto dañado.

Semanalmente el Jefe de Servicio solicita al almacenero un reporte del estado de los productos en el almacén con la cantidad existente de cada producto, las salidas hacia la pizzería del producto con la fecha y la cantidad, las bajas que existieron de cada producto en la semana, y la cantidad enviada del producto por el almacén central en esta semana.

En el municipio es necesario crear una aplicación Web que gestione todos los procesos del almacén de las pizzerías, teniendo en cuenta la seguridad que requiere esta aplicación y los permisos correspondientes a cada persona según el rol que desempeñan.

Además de lo anteriormente expuesto hoy se hace difícil para las personas que viven en el municipio saber cuál es la oferta de cada pizzería. Para obtener este servicio cada persona debe dirigirse personalmente al lugar y preguntar la oferta. Cuando una persona llega al lugar es atendido por un asistente el cual da la información requerida por el cliente.

Las pizzerías ofertan un servicio de entrega a domicilio donde cada cliente hace la solicitud por teléfono a un asistente y este recoge la solicitud del pedido la cual incluye el nombre de la persona, el número de carne de identidad, los productos solicitados, la dirección a la cual será dirigido el servicio. Este servicio se brinda desde las 8:00pm hasta las 6:00am.

Se hace necesario que la aplicación Web brinde la posibilidad a cada persona de conocer la oferta de cada una de las pizzerías, el precio de cada producto y además realizar una solicitud del servicio a domicilio por dicha aplicación.

Tabla 1: Tarjeta de estiba de un Producto "Y"

edu.red

Tabla 2: Informe semanal de productos solicitados.

Fecha.	Hora.	Producto.			Cantidad.

Tabla 3: Ficha de un Producto "X" en mal estado.

Producto "X"
Fecha.	Causa.	Cantidad.	Baja.

Solución del caso de estudio:

Actividades a realiza para la obtención de los requisitos del sistema:

Identificar cuantos procesos se desean informatizar.

7 Procesos y son:

Entrada a productos.
Salida a productos.
Solicitud productos.
Baja de productos.
Entrega a domicilio.
Reporte estado de productos.
Entrada a productos.

Realizar la Guía de preguntas propuesta para cada uno de los procesos a informatizar.

Respuesta de la encuesta según caso de estudio:

Respuesta a las preguntas del primer proceso:

1. ¿Cuál es el nombre del proceso o que nombre usted le asignaría?

Entrada de productos

2. ¿Existe alguna política, regla, procedimiento, etc. por los que se rija el proceso a analizar?

Reglas:

1- Cada producto dentro del almacén tiene una tarjeta de estiba con el formato de la Tabla 1.
2- El acta de no conformidad con el envío contiene la descripción de los productos faltantes o sobrantes con sus respectivas cantidades.
3. ¿Cuándo se inicia el proceso?

Cuando el Transportista llega con los productos enviados por el Almacén Central.

4. ¿Quién inicia el proceso?

El Transportista.

¿Qué rol ocupa dentro del proceso?

Rol de proveedor.

¿A qué área, instalación, empresa, etc. pertenece la persona que inicia el proceso?

Al Almacén Central.

5. ¿Se entrega alguna documentación o información al inicio del proceso?

Sí, la Factura.

¿Cuáles son los datos significativos que deben ser almacenados en el proceso de la información o documentación recibida?

NA[1]

¿Los datos de la información o documentación se recogen en algún registro, documento, forma, expediente, etc. de importancia para la entidad?

¿Es interés de la entidad la informatización del registro, documento, forma, expediente, etc.?

No.

¿Cuál es el formato específico del registro, documento, forma, expediente, etc.?

¿El formato del registro, documento, forma, expediente, etc. puede ser modificado o es oficial?

¿Se realiza algún tipo de reporte, informe, etc. con los datos de la información recibida almacenados en el registro, documento, forma, expediente, etc. de la entidad?

¿Es interés de la entidad la informatización del reporte, informe, etc. con los datos de la información recibida almacenados en el registro, documento, forma, expediente, etc. de la entidad?

No.

¿Cuál es el formato específico del reporte, informe, etc.?

¿El formato del reporte, informe, etc. puede ser modificado o es oficial?

¿Quién realiza el reporte, informe, etc.?

¿A qué área, instalación, empresa, etc. pertenece la persona que realiza el reporte, informe, etc.?

¿Quién recibe el reporte, informe, etc.?

¿A qué área, instalación, empresa, etc. pertenece la persona que recibe el reporte, informe, etc.?

6. ¿Quién recoge los datos de la información o documentación?

El almacenero.

¿Qué rol ocupa dentro del proceso?

El rol de almacenero.

¿A qué área, instalación, empresa, etc. pertenece la persona que recoge los datos de la información o documentación?

Almacén de la pizzería.

7. ¿Qué otras actividades se realizan dentro del proceso luego de iniciado?

Nota: A partir de este momento las preguntas tendrán respuesta en el diagrama que se expondrá en la Figura 1 y 2

8. ¿En qué áreas, instalación, empresa, etc. se realizan dichas actividades?
9. ¿Qué roles realizan dichas actividades?
10. ¿Se recoge, entrega, registra, recibe, envía, etc. alguna documentación o información en las actividades del proceso?

¿Cuáles son los datos significativos que deben ser almacenados en el proceso de la información o documentación que se recoge, entrega, registra, recibe, envía, etc.?

¿Los datos de la información o documentación que se recoge, entrega, registra, recibe, envía, etc. son almacenados en algún registro, documento, forma, expediente, etc. de importancia para la entidad?
¿Es interés de la entidad la informatización del registro, documento, forma, expediente, etc.?

¿Cuál es el formato específico del registro, documento, forma, expediente, etc.?
¿El formato del registro, documento, forma, expediente, etc. puede ser modificado o es oficial?
¿Se realiza algún tipo de reporte, informe, etc. con los datos de la información recibida almacenados en el registro, documento, forma, expediente, etc. de la entidad?
¿Es interés de la entidad la informatización del reporte, informe, etc. con los datos de la información recibida almacenados en el registro, documento, forma, expediente, etc. de la entidad?

¿Cuál es el formato específico del reporte, informe, etc.?
¿El formato del reporte, informe, etc. puede ser modificado o es oficial?
¿Quién realiza el reporte, informe, etc.?
¿A qué área, instalación, empresa, etc. pertenece la persona que realiza el reporte, informe, etc.?
¿Quién recibe el reporte, informe, etc.?
¿A qué área, instalación, empresa, etc. pertenece la persona que recibe el reporte, informe, etc.?

11. ¿Existe algún sistema informático que intervenga en el proceso?

¿Cuáles son sus características fundamentales?

¿El sistema es interno, de la entidad o externo, que no pertenece a la entidad?

¿Cómo interactúa dentro del proceso en cada actividad?

¿Cuáles son las áreas, instalación, empresa, etc. que interactúan con el sistema?

¿Cuáles son los roles que interactúan con el sistema?

¿Se recoge, entrega, registra, recibe, envía, etc. alguna documentación o información de las actividades del proceso en el sistema?

¿Cuáles son los datos significativos almacenados de la información o documentación que se recoge, entrega, registra, recibe, envía, etc. en el sistema?

¿El sistema debe ser sustituido por el nuevo sistema o el nuevo sistema debe mantener una comunicación con el sistema existente?

¿Cuáles son los puntos de comunicación del nuevo sistema con el sistema existente?

¿Mediante cuales informaciones y actividades se comunicarán?

¿Cuáles son sus ventajas y desventajas dentro del proceso?

12. ¿Cuáles son las ventajas existentes en el proceso actual?

Ninguna.

13. ¿Cuáles son las desventajas y problemas existentes en el proceso actual?

Proceso lento, con falta de fiabilidad en la información que se muestra en las tarjetas en cuanto a la existencia real.

¿En qué actividades se encuentran dichos problemas y desventajas?

En el registro de nuevas entradas y en la creación de nuevas tarjetas para los productos.

¿Cuáles pueden ser sus posibles causas?

Proceso manual.

14. ¿Existe la necesidad de modificar actividades o flujos de estas en el proceso actual para el mejor funcionamiento del sistema a desarrollar?

No.

¿Cuáles son estas actividades o flujos de actividades que se necesitan modificar?

¿Cuáles son los responsables de autorizar el cambio en estas actividades o en este flujo de actividades?

Modelar cada uno de los procesos identificados utilizando la notación BPMN.

Proceso modelado en BPMN:

Figura 1: Proceso Entrada de productos.

edu.red

Figura 2: Subproceso Registrar productos.

edu.red

Identificar las actividades posibles a informatizar dentro de los procesos.

Luego de realizar los diagramas de procesos, se validan con el cliente y si todo está correcto se pasa a determinar cuáles son las actividades posibles a informatizar según clientes y analistas. Para el caso de estudio serían:

Figura 3: Actividades a informatizar en el proceso Entrada de productos.

edu.red

Figura 4: Actividades a informatizar en el subproceso Registrar productos

edu.red

Obtener la lista de requisitos del sistema para cada uno de los procesos a informatizar.

Posteriormente se identifican los requisitos o funcionalidades del futuro sistema para el proceso descrito.

Listado de requisitos funcionales:

1) Buscar productos.

Mostrar los campos para realizar la búsqueda.

Nombre del producto.

Mostrar productos si se encuentran coincidencias.

2) Seleccionar un producto a buscar.
3) Buscar datos de un producto seleccionado.

Mostrar datos de un producto seleccionado.

Nombre.
Cantidad mínima.
Cantidad en existencia.

4) Crear un producto nuevo.

Mostrar datos para introducir un nuevo producto.

Nombre.
Cantidad mínima.
Cantidad en existencia.

Registrar un nuevo producto con los datos introducidos y los siguientes datos.

Fecha.
Usuario.

5) Mostrar campos para introducir una nueva entrada de un producto.

Cantidad a introducir.

6) Registrar una nueva entrada de producto con los siguientes datos.

Cantidad introducida.
Fecha.
Usuario.

7) Aumentar la cantidad de un producto con la cantidad introducida en la nueva entrada.

Obtener el modelado de la base de datos.

Primeramente se obtendrá el modelo de datos del proceso analizado a partir de sus requisitos para posteriormente obtener el modelo general cuando se termine el levantamiento de todos los procesos objetos de análisis.

Para este caso de estudio en este proceso el modelo de datos podría ser:

edu.red

Realizar un prototipo de interfaz para los requisitos obtenidos.

En este momento se realiza el prototipo de interfaz y se muestra a los clientes para validar los requisitos.

Al concluir la realización de las actividades definidas para un proceso, se repetirán para cada uno de los procesos objetos de informatización en el negocio. Finalmente se logrará obtener un adecuado listado de requisitos funcionales y un prototipo de interfaz del sistema. Dichos resultados facilitarán el desarrollo de un software de calidad, que cumpla con las expectativas de sus clientes.

Conclusiones

Realizando el conjunto de actividades propuestas para el análisis y la obtención de requisitos, aplicando las herramientas definidas en el presente trabajo, se lograr obtener un negocio con sus características descritas por proceso y representadas en diagramas que utilizan la notación BPMN. Permitiendo concebir una lista de funcionalidades que el sistema debe cumplir para satisfacer las exigencias y realizar luego el modelo de datos del software a desarrollar.

El uso de los prototipos interfaz como herramienta para la validación de la lista de requisitos, propuesta en el presente trabajo, permitirá comprobar que las funcionalidades descritas son las necesidades reales de los clientes.

El desarrollo de un caso de estudio permitió conocer como aplicar las herramientas en las diferentes actividades definidas, con el fin de ejemplificar su uso para una mejor comprensión.

Con la realización del presente trabajo se obtienen herramientas para el análisis y la documentación de las características de los negocios, que permiten comprender qué funcionalidades debe cumplir el software a desarrollar. Influyendo en el logro del consenso entre los clientes y el equipo de desarrollo, para alcanzar un sistema de calidad, en tiempo y que cumpla con las expectativas.

Partes: 1, 2

Página siguiente