Ilustrados comunidad mundial educativa
Inicio | Escribenos
User: Pass: Recordar ó (Registrate!)

| !Publicar Articulo¡

Ingeniería De Requerimientos - Ingeniería De Software

Resumen: La ingeniería de requerimientos y sus principales actividades. Técnicas y herramientas utilizadas en la ingeniería de requerimientos. Análisis comparativo de las técnicas de ingeniería de requerimientos.
10,730 visitas
Rating: 0
Tell a Friend
Autor: Lizka Johany Herrera J.

Indice
1. Introducción
2. La ingeniería de requerimientos y sus principales actividades
3. Técnicas y herramientas utilizadas en la ingeniería de requerimientos
4. Análisis comparativo de las técnicas de ingeniería de requerimientos
5. Conclusiones Y Recomendaciones
6. Referencias Bibliográficas

1. Introducción
En la actualidad, son muchos los procesos de desarrollo de software que existen. Con el pasar de los años, la Ingeniería de Software ha introducido y popularizado una serie de estándares para medir y certificar la calidad, tanto del sistema a desarrollar, como del proceso de desarrollo en sí. Se han publicado muchos libros y artículos relacionados con este tema, con el modelado de procesos del negocio y la reingeniería. Un número creciente de herramientas automatizadas han surgido para ayudar a definir y aplicar un proceso de desarrollo de software efectivo. Hoy en día la economía global depende más de sistemas automatizados que en épocas pasadas; esto ha llevado a los equipos de desarrollo a enfrentarse con una nueva década de procesos y estándares de calidad.

Sin embargo, ¿cómo explicamos la alta incidencia de fallos en los proyectos de software? ¿Por qué existen tantos proyectos de software víctimas de retrasos, presupuestos sobregirados y con problemas de calidad? ¿Cómo podemos tener una producción o una economía de calidad, cuando nuestras actividades diarias dependen de la calidad del sistema?

Tal vez suene ilógico pero, a pesar de los avances que ha dado la tecnología, aún existen procesos de producción informales, parciales y en algunos casos no confiables.

La Ingeniería de Requerimientos cumple un papel primordial en el proceso de producción de software, ya que enfoca un área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema; de esta manera, se pretende minimizar los problemas relacionados al desarrollo de sistemas.

La razón principal para escoger este tema se fundamentó en la gran cantidad de proyectos de software que no llegan a cumplir sus objetivos. En nuestro país somos partícipes de este problema a diario, en donde se ha vuelto común la compra de sistemas extranjeros, para luego "personalizarlos" supuestamente a la medida de las empresas.

Tal "personalización", la mayoría de las veces, termina retrasando el proyecto en meses, o incluso en años. La problemática del año 2000 trajo como consecuencia una serie de cambios apresurados en los sistemas existentes; cambios que, desde mi punto de vista, no fueron bien planificados.

El reemplazo de plataformas y tecnologías obsoletas, la compra de sistemas completamente nuevos, las modificaciones de todos o de casi todos los programas que forman un sistema, entre otras razones, llevan a desarrollar proyectos en calendarios sumamente ajustados y en algunos casos irreales; esto ocasiona que se omitan muchos pasos importantes en el ciclo de vida de desarrollo, entre estos, la definición de los requerimientos.

Estudios realizados muestran que más del 53% de los proyectos de software fracasan por no realizar un estudio previo de requisitos. Otros factores como falta de participación del usuario, requerimientos incompletos y el cambio a los requerimientos, también ocupan sitiales altos en los motivos de fracasos.

Con este trabajo se pretende alcanzar los siguientes objetivos:

  • Resaltar la importancia que tiene la Ingeniería de Requerimientos dentro del ciclo de desarrollo.
  • Dar a conocer las diferentes alternativas que existen para identificar requerimientos.
  • Ayudar a comprender la diferencia que existe entre las diferentes técnicas utilizadas en la IR.
  • Minimizar las dudas que se tiene sobre los casos de uso.
  • Mostrar la utilización de herramientas CASE dentro de la administración de requisitos.

2. La ingeniería de requerimientos y sus principales actividades
¿Qué son Requerimientos?
Normalmente, un tema de la Ingeniería de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, ha continuación se presenta la definición que aparece en el glosario de la IEEE .

(1) Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. (3) Una representación documentada de una condición o capacidad como en (1) o (2).

Los requerimientos puedes dividirse en requerimientos funcionales y requerimientos no funcionales.
Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas.
Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.

Características de los requerimientos
Las características de un requerimiento son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de características tanto individualmente como en grupo. A continuación se presentan las más importantes.
Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir, y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.
Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro.
Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.
Consistente: Un requerimiento es consistente si no es contradictorio con otro requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector.
Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.

Dificultades para definir los requerimientos

  • Los requerimientos no son obvios y vienen de muchas fuentes.
  • Son difíciles de expresar en palabras (el lenguaje es ambiguo).
  • Existen muchos tipos de requerimientos y diferentes niveles de detalle.
  • La cantidad de requerimientos en un proyecto puede ser difícil de manejar.
  • Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros.
  • Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso.
  • Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas.
  • Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
  • Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

Ingeniería de Requerimientos vs. Administración de Requerimientos
El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema es llamado Ingeniería de Requerimientos. La meta de la ingeniería de requerimientos (IR) es entregar una especificación de requisitos de software correcta y completa.

A continuación se darán algunas definiciones para ingeniería de requerimientos.
"Ingeniería de Requerimientos es la disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el sistema" Boehm 1979.

"Ingeniería de Requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes , ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones". STARTS Guide 1987.

"Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos" Leite 1987.

"Ingeniería de requerimientos es un enfoque sistémico para recolectar, organizar y documentar los requerimientos del sistema; es también el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto" Rational Software

Importancia de la Ingeniería de Requerimientos
Los principales beneficios que se obtienen de la Ingeniería de Requerimientos son:

  • Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos.
  • Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios.
  • Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la RE.
  • Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.).
  • Mejora la comunicación entre equipos: La especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso.
  • Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.

Personal involucrado en la Ingeniería de Requerimientos

Realmente, son muchas las personas involucradas en el desarrollo de los requerimientos de un sistema. Es importante saber que cada una de esas personas tienen diversos intereses y juegan roles específicos dentro de la planificación del proyecto; el conocimiento de cada papel desempeñado, asegura que se involucren a las personas correctas en las diferentes fases del ciclo de vida, y en las diferentes actividades de la IR.

No conocer estos intereses puede ocasionar una comunicación poco efectiva entre clientes y desarrolladores, que a la vez traería impactos negativos tanto en tiempo como en presupuesto. Los roles más importantes pueden clasificarse como sigue:

  • Usuario final: Son las personas que usarán el sistema desarrollado. Ellos están relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema; están familiarizados con los procesos específicos que debe realizar el software, dentro de los parámetros de su ambiente laboral. Serán quienes utilicen las interfaces y los manuales de usuario.
  • Usuario Líder: Son los individuos que comprenden el ambiente del sistema o el dominio del problema en donde será empleado el software desarrollado. Ellos proporcionan al equipo técnico los detalles y requerimientos de las interfaces del sistema.
  • Personal de Mantenimiento: Para proyectos que requieran un mantenimiento eventual, éstas personas son las responsables de la administración de cambios, de la implementación y resolución de anomalías. Su trabajo consiste en revisar y mejorar los procesos del producto ya finalizado.
  • Analistas y programadores: Son los responsables del desarrollo del producto en sí; ellos interactúan directamente con el cliente.
  • Personal de pruebas: Se encargan de elaborar y ejecutar el plan de pruebas para asegurar que las condiciones presentadas por el sistema son las adecuadas. Son quienes van a validar si los requerimientos satisfacen las necesidades del cliente.

Otras personas que pueden estar involucradas, dependiendo de la magnitud del proyecto, pueden ser: administradores de proyecto, documentadores, diseñadores de base de datos, entre otros.

Puntos a considerar durante la Ingeniería de Requerimientos
Aunque la lista no está completa, se enumeran los puntos más importantes.
Objetivos del negocio y ambiente de trabajo
Aunque los objetivos del negocio están definidos frecuentemente en términos generales, son usados para descomponer el trabajo en tareas específicas. En ciertas situaciones IR se enfoca en la descripción de las tareas y en el análisis de sistemas similares. Esta información proporciona la base para especificar el sistema que será construido; aunque frecuentemente se añadan al sistema tareas que no encajan con el ambiente de trabajo planificado.

El nuevo sistema cambiará el ambiente de trabajo, sin embargo, es muy difícil anticipar los efectos actuales sobre la organización. Los cambios no ocurren solamente cuando un nuevo software es implementado y puesto en producción; también ocurren cuando cambia el ambiente que lo rodea (nuevas soluciones a problemas, nuevo equipo para instalar, etc.). La necesidad de cambio es sustentada por el enorme costo de mantenimiento; aunque existen diversas razones que dificultan el mantenimiento del software, la falta de atención a la IR es la principal.

Frecuentemente la especificación inicial es también la especificación final, lo que obstaculiza la comunicación y el proceso de aprendizaje de las personas involucradas; esta es una de las razones por las cuales existen sistemas inadecuados.

Punto de vista de los clientes

Muchos sistemas tienen diferentes tipos de clientes. Cada grupo de clientes tiene necesidades diferentes y, diferentes requerimientos tienen diferentes grados de importancia para ellos. Por otro lado, escasas veces tenemos que los clientes son los mismos usuarios; trayendo como consecuencia que los clientes soliciten procesos que causan conflictos con los solicitados por el usuario.

Diferentes puntos de vistas también pueden tener consecuencias negativas, tales como datos redundantes, inconsistentes y ambiguos.

El tamaño y complejidad de los requerimientos ocasiona desentendimiento, dificultad para enfocarse en un solo aspecto a la vez y dificultad para visualizar relaciones existentes entre requerimientos.

  • Barreras de comunicación

La ingeniería de requerimientos depende de una intensa comunicación entre clientes y analistas de requerimientos; sin embargo, existen problemas que no pueden ser resueltos mediante la comunicación.

Para remediar esto, se deben abordar nuevas técnicas operacionales que ayuden a superar estas barreras y así ganar experiencia dentro del marco del sistema propuesto.

  • Evolución e integración del sistema

Pocos sistemas son construidos desde cero. En la práctica, los proyectos se derivan de sistemas ya existentes. Por lo tanto, los analistas de requerimientos deben comprender esos sistemas, que por lo general son una integración de componentes de varios proveedores.

Para encontrar una solución a problemas de este tipo, es muy importante hacer planeamientos entre los requerimientos y la fase de diseño; esto minimizará la cantidad de fallas directas en el código.

  • Documentación de requerimientos

Los documentos de ingeniería de requerimientos son largos. La mayoría están compuestos de cientos o miles de páginas; cada página contiene muchos detalles que pueden tener efectos profundos en el resto del sistema.

Normalmente, las personas se encuentran con dificultades para comprender documentos de este tamaño, sobre todo si lo leen cuidadosamente. Es casi imposible leer un documento de especificación de gran tamaño, pues difícilmente una persona puede memorizar los detalles del documento. Esto causa problemas y errores que no son detectados hasta después de haberse construido el sistema.

Actividades de la Ingeniería de Requerimientos

En el proceso de IR son esenciales diversas actividades. En este documento serán presentadas secuencialmente, sin embargo, en un proceso de ingeniería de requerimientos efectivo, estas actividades son aplicadas de manera continua y en orden variado.

Dependiendo del tamaño del proyecto y del modelo de proceso de software utilizado para el ciclo de desarrollo, las actividades de la IR varían tanto en número como en nombres. La tabla #1 muestra algunos ejemplos de las actividades identificadas para cada proceso.

A pesar de las diferentes interpretaciones que cada desarrollador tenga sobre el conjunto de actividades mostradas en la tabla anterior, podemos identificar y extraer cinco actividades principales que son:

  • Análisis del Problema
  • Evaluación y Negociación
  • Especificación
  • Validación
  • Evolución

 

 

Tabla 1. Actividades de la IR para diferentes modelos de procesos de Ingeniería de Software
MODELO Oliver and Steiner 1996 EIA / IS-632 IEEE Std 1220- 1994 CMM nivel Repetitivo (2) RUP
           
Actividades Evaluar la información disponible Análisis de requerimientos Análisis de Requerimientos Identificación de requerimientos Análisis del Problema
Definir métricas efectivas Análisis funcional Estudio de los requerimientos Identificación de restricciones del sistema a desarrollar Comprender las necesidades de los involucrados
Crear un modelo del comportamiento del sistema Síntesis Validación de requerimientos Análisis de los requerimientos Definir el sistema
Crear un modelo de los objetos Análisis y control del sistema Análisis funcional Representación de los requerimientos Analizar el alcance del proyecto
Ejecutar el análisis   Evaluación y estudio de funciones Comunicación de los requerimientos Modificar la definición del sistema
Crear un plan secuencial de construcción y pruebas   Verificación de funciones Validación de requerimientos Administrar los cambios de requerimientos
    Síntesis    
    Estudio y evaluación del diseño    
    Verificación física    
    Control    

 

A continuación se explicará cada una de ellas, presentándolas en el orden en que deben ser aplicadas para un nuevo proyecto.
Análisis del Problema
El objetivo de esta actividad es entender las verdaderas necesidades del negocio.
Antes de describir qué pasos deben cumplirse en esta actividad, debemos tener una definición clara del término "Problema".
"Un problema puede ser definido como la diferencia entre las cosas como se perciben y las cosas como se desean" . Aquí vemos nuevamente la importancia que tiene una buena comunicación entre desarrolladores y clientes; de esta comunicación con el cliente depende que entendamos sus necesidades.

A través de la definición de problema, podemos ver entonces que la actividad de "Análisis del Problema" tiene por objetivo que se comprendan los problemas del negocio, se evalúen las necesidades iniciales de todos los involucrados en el proyecto y que se proponga una solución de alto nivel para resolverlo.

Durante el análisis del problema, se realizan una serie de pasos para garantizar un acuerdo entre los involucrados, basados en los problemas reales del negocio.

Estos pasos son los siguientes

Comprender el problema que se está resolviendo: Es importante determinar quién tiene el problema realmente, considerar dicho problema desde una variedad de perspectivas y explorar muchas soluciones desde diferentes puntos de vista. Veamos la siguiente necesidad: "El cliente se queja mucho por la enorme fila que debe formar para realizar una transacción bancaria".

Perspectiva del cliente = Pérdida de tiempo
Perspectiva del banco = Posibles pérdidas de clientes

Posibles soluciones pueden ser, determinar por qué demoran los cajeros, colocar una nueva caja (implica contratación de nuevos cajeros), abrir una nueva sucursal (involucra personal nuevo y estudio de mercado), realizar transacciones por otros medios (teléfono, internet, mediante cajeros automáticos, autobancos, etc).

Como puede verse, múltiples soluciones aplican para el mismo problema, sin embargo, sólo una de ellas será la más factible. Las soluciones iniciales, deben ser definidas tomando en cuanta tanto la perspectiva técnica como la del negocio.

Construir un vocabulario común: Debe confeccionarse un glosario en dónde se definan todos los términos que tengan significados comunes (sinónimos) y que serán utilizados durante el proyecto. Por ejemplo, las palabras pignoración, retención, valor en suspenso, custodia, garantía, entre otras, son utilizadas para referirse a la acción de dejar una prenda (puede ser cualquier forma de ahorros) como garantía de una deuda adquirida.

La creación de un glosario es sumamente beneficiosa ya que reduce los términos ambiguos desde el principio, ahorra tiempo, asegura que todos los participantes de una reunión están en la misma página, además de ser reutilizable en otros proyectos.

Identificar a los afectados por el sistema: Identificar a todos los afectados evita que existan sorpresas a medida que avanza el proyecto. Las necesidades de cada afectado, son discutidas y sometidas a debate durante de ingeniería de requerimientos, aunque esto no garantiza que vaya a estar disponible toda la información necesaria para especificar un sistema adecuado.

Para saber quiénes son las personas, departamentos, organizaciones internas o externas que se verán afectadas por el sistema, debemos realizar algunas preguntas.

  • ¿Quién usará el sistema que se va a construir?
  • ¿Quién desarrollará el sistema?
  • ¿Quién probará el sistema?
  • ¿Quién documentará el sistema?
  • ¿Quién dará soporte al sistema?
  • ¿Quién dará mantenimiento al sistema?
  • ¿Quién mercadeará, venderá, y/o distribuirá el sistema?
  • ¿Quién se beneficiará por el retorno de inversión del sistema?

Como vemos, debe conocerse la opinión de todo aquél que de una u otra forma está involucrado con el sistema, ya sea directa o indirectamente.

Definir los límites y restricciones del sistema: Este punto es importante pues debemos saber lo que se está construyendo, y lo que no se está construyendo, para así entender la estrategia del producto a corto y largo plazo. Debe determinarse cualquier restricción ambiental, presupuestaria, de tiempo, técnica y de factibilidad que limite el sistema que se va a construir.

Evaluación y negociación de los requerimientos

La diversa gama de fuentes de las cuales provienen los requerimientos, hacen necesaria una evaluación de los mismos antes de definir si son adecuados para el cliente. El término "adecuado" significa que ha sido percibido a un nivel aceptable de riesgo tomando en cuenta las factibilidades técnicas y económicas, a la vez que se buscan resultados completos, correctos y sin ambigüedades.

En esta etapa se pretende limitar las expectativas del cliente apropiadamente, tomando como referencia los niveles de abstracción y descomposición de cada problema presentado.

Los principales pasos de esta actividad son:

Descubrir problemas potenciales: En este paso se asegura que todas las características descritas en el punto 1.1 estén presentes en cada uno de los requerimientos, es decir, se identifican aquellos requerimientos ambiguos, incompletos, inconsistentes, etc.

Clasificar los requerimientos:

En este paso se busca identificar la importancia que tiene un requerimiento en términos de implementación. A esta característica se le conoce como prioridad y debe ser usada para establecer la secuencia en que ocurrirán las actividades de diseño y prueba de cada requisito. La prioridad de cada requerimiento dependerá de las necesidades que tenga el negocio.

En base a la prioridad, cada requerimiento puede ser clasificados como mandatorio, deseables o innecesarios. Un requerimiento es mandatorio si afecta una operación crítica del negocio. Si existe algún proceso que se quiera incluir para mejorar los procesos actuales, estamos ante un requerimiento deseable; y si se trata de un requerimiento informativo o que puede esperar para fases posteriores, el requerimiento es catalogado como innecesario.

Una vez hecha esta categorización de los requerimientos, puedo tomar como estrategia general el incluir los mandatorios, discutir los deseables y descartar los innecesarios. Antes de decidir la inclusión de un requerimiento, también debe analizarse su costo, complejidad, y una cantidad de otros factores. Por ejemplo, si un requerimiento fuera trivial de implementar, puede ser una buena idea incluirlo por más que éste sea sólo deseable.

Evaluar factibilidades y riesgos: Involucra la evaluación de factibilidades técnicas (¿pueden implementarse los requerimientos con la tecnología actual?); factibilidades operacionales (¿puede ser el sistema utilizado sin alterar el organigrama actual?); factibilidades económicas (¿ha sido aprobado por los clientes el presupuesto?).

En la actividad de evaluación y negociación, se incrementa la comunicación entre el equipo de desarrollo y los afectados. Para que los requerimientos puedan ser comunicados de manera efectiva, hay una serie de consideraciones que deben tenerse en cuenta; entre las principales tenemos:

  • Documentar todos los requerimientos a un nivel de detalle apropiado.
  • Mostrar todos los requerimientos a los involucrados en el sistema.
  • Analizar el impacto que causen los cambios a requerimientos antes de aceptarlos.
  • Establecer las relaciones entre requerimientos que indiquen dependencias.
  • Negociar con flexibilidad para que exista un beneficio mutuo.
  • Enfocarse en intereses y no en posiciones.

Especificación de Requisitos de Software (SRS)

La especificación de requisitos de software es la actividad en la cual se genera el documento, con el mismo nombre, que contiene una descripción completa de las necesidades y funcionalidades del sistema que será desarrollado; describe el alcance del sistema y la forma en como hará sus funciones, definiendo los requerimientos funcionales y los no funcionales.

En la SRS se definen todos los requerimientos de hardware y software, diagramas, modelos de sistemas y cualquier otra información que sirva de soporte y guía para fases posteriores.

Es importante destacar que la especificación de requisitos es el resultado final de las actividades de análisis y evaluación de requerimientos; este documento resultante será utilizado como fuente básica de comunicación entre los clientes, usuarios finales, analistas de sistema, personal de pruebas, y todo aquel involucrado en la implementación del sistema.

Los clientes y usuarios utilizan la SRS para comparar si lo que se está proponiendo, coincide con las necesidades de la empresa. Los analistas y programadores la utilizan para determinar el producto que debe desarrollarse. El personal de pruebas elaborará las pruebas funcionales y de sistemas en base a este documento. Para el administrador del proyecto sirve como referencia y control de la evolución del sistema.

La SRS posee las mismas características de los requerimientos: completa, consistente, verificable, no ambigua, factible, modificable, rastreable, precisa, entre otras. Para que cada característica de la SRS sea considerada, cada uno de los requerimientos debe cumplirlas; por ejemplo, para que una SRS se considere verificable, cada requerimiento definido en ella debe ser verificable; para que una SRS se considere modificable, cada requerimiento debe ser modificable y así sucesivamente. Las características de la SRS son verificadas en la actividad de Validación, descrita en el punto 3.4.

La estandarización de la SRS es fundamental pues ayudará, entre otras cosas, a facilitar la lectura y escritura de la misma. Será un documento familiar para todos los involucrados, además de asegurar que se cubren todos los tópicos importantes.

Existen plantillas creadas para la SRS, sin embargo, cada uno tiene la potestad de crear su propia plantilla. En el anexo #1 se muestra una plantilla completa para la especificación de requisitos.

Validación de Requisitos

La validación es la actividad de la IR que permite demostrar que los requerimientos definidos en el sistema son los que realmente quiere el cliente; además revisa que no se haya omitido ninguno, que no sean ambiguos, inconsistentes o redundantes.

En este punto es necesario recordar que la SRS debe estar libre de errores, por lo tanto, la validación garantiza que todos los requerimientos presentes en el documento de especificación sigan los estándares de calidad.

No debe confundirse la actividad de evaluación de requerimientos con la validación de requerimientos. La evaluación verifica las propiedades de cada requerimiento, mientras que la validación revisa el cumplimiento de las características de la especificación de requisitos.

Durante la actividad de validación pueden hacerse preguntas en base a cada una de las características que se desean revisar. A continuación se presentan varios ejemplos:

  • ¿Están incluidas todas las funciones requeridas por el cliente? (completa)
  • ¿Existen conflictos en los requerimientos? (consistencia)
  • ¿Tiene alguno de los requerimientos más de una interpretación? (no ambigua)
  • ¿Está cada requerimiento claramente representado? (entendible)
  • ¿Pueden los requerimientos ser implementados con la tecnología y el presupuesto disponible? (factible)
  • ¿Está la SRS escrita en un lenguaje apropiado? (clara)
  • ¿Existe facilidad para hacer cambios en los requerimientos? (modificable)
  • ¿Está claramente definido el origen de cada requisito? (rastreable)
  • ¿Pueden los requerimientos ser sometidos a medidas cuantitativas? (verificable)

La validación de requerimientos es importante pues de ella depende que no existan elevados costos de mantenimiento para el software desarrollado.

Evolución de los requerimientos

Los requerimientos son una manera de comprender mejor el desarrollo de las necesidades de los usuarios y cómo los objetivos de la organización pueden cambiar, por lo tanto,

es esencial planear posibles cambios a los requerimientos cuando el sistema sea desarrollado y utilizado. La actividad de evolución es un proceso externo

que ocurre a lo largo del ciclo de vida del proyecto.

Los requerimientos cambian por diferentes razones. Las más frecuentes son:

  • Porque al analizar el problema, no se hacen las preguntas correctas a las personas correctas.
  • Porque cambió el problema que se estaba resolviendo.
  • Porque los usuarios cambiaron su forma de pensar o sus percepciones.
  • Porque cambió el ambiente de negocios.
  • Porque cambió el mercado en el cual se desenvuelve el negocio.

Cambios a los requisitos involucra modificar el tiempo en el que se va a implementar una característica en particular, modificación que a la vez puede tener impacto en otros requerimientos. Por esto, la administración de cambios involucra actividades como establecer políticas, guardar históricos de cada requerimiento, identificar dependencias entre ellos y mantener un control de versiones.

Tener versiones de los requerimientos es tan importante como tener versiones del código, ya que evita tener requerimientos emparchados en un proyecto

Entre algunos de los beneficios que proporciona el control de versiones están:

  • Prevenir cambios no autorizados.
  • Guardar revisiones de los documentos de requerimientos.
  • Recuperar versiones previas de los documentos.
  • Administrar una estrategia de "releases".
  • Prevenir la modificación simultánea a los requisitos.

En vista que las peticiones de cambios provienen de muchas fuentes, las mismas deben ser enrutadas en un solo proceso. Esto se hace con la finalidad de evitar problemas y conseguir estabilidad en los requerimientos.

3. Técnicas y herramientas utilizadas en la ingeniería de requerimientos

Técnicas utilizadas en la actividades de IR

Existen varias técnicas para la IR, sin embargo, en este documento se van a estudiar sólo algunas de ellas. Cada técnica puede aplicarse en una o más actividades de la IR; en la práctica, la técnica más apropiada para cada actividad dependerá del proyecto que esté desarrollándose.

Este análisis de técnica vs. actividad será discutido en el capítulo IV. Por el momento sólo mencionaremos en qué consiste cada técnica.

Entrevistas y Cuestionarios

Las entrevistas y cuestionarios se emplean para reunir información proveniente de personas o de grupos. Durante la entrevista, el analista conversa con el encuestado; el cuestionario consiste en una serie de preguntas relacionadas con varios aspectos de un sistema.

Por lo común, los encuestados son usuarios de los sistemas existentes o usuarios en potencia del sistema propuesto. En algunos casos, son gerentes o empleados que proporcionan datos para el sistema propuesto o que serán afectados por él.

Las preguntas que deben realizarse en esta técnica, deben ser preguntas de alto nivel y abstractas que pueden realizarse al inicio del proyecto para obtener información sobre aspectos globales del problema del usuario y soluciones potenciales.

Con frecuencia, se utilizan preguntas abiertas para descubrir sentimientos, opiniones y experiencias generales, o para explorar un proceso o problema. Este tipo de preguntas son siempre apropiadas, además que ayudan a entender la perspectiva del afectado y no están influenciadas por el conocimiento de la solución.

Las preguntas pueden ser enfocadas a un elemento del sistema, tales como usuarios, procesos, etc. El siguiente ejemplo muestra algunos tipos de preguntas abiertas.

Del Usuario

  • ¿Quién es el cliente?
  • ¿Quién es el usuario?
  • ¿Son sus necesidades diferentes?
  • ¿Cuáles son sus habilidades, capacidades, ambiente?

Del Proceso

  • ¿Cuál es la razón por la que se quiere resolver este problema?
  • ¿Cuál es el valor de una solución exitosa?
  • ¿Cómo usted resuelve el problema actualmente?
  • ¿Qué retrasos ocurren o pueden ocurrir?

Del Producto

  • ¿Qué problemas podría causar este producto en el negocio?
  • ¿En qué ambiente se usará el producto?
  • ¿Cuáles son sus expectativas para los conceptos fácil de usar, confiable, rendimiento?
  • ¿Qué obstáculos afectan la eficiencia del sistema?

El éxito de esta técnica combinada, depende de la habilidad del entrevistador y de su preparación para la misma. Los analistas necesitan ser sensibles las dificultades que algunos entrevistados crean durante la entrevista y saber cómo tratar con problemas potenciales. Asimismo, necesitan considerar no sólo la información que adquieren a través del cuestionario y la entrevista, sino también, su significancia.

Lluvia de Ideas (Brainstorm)
Este método comenzó en el ámbito de las empresas, aplicándose a temas tan variados como la productividad, la necesidad de encontrar nuevas ideas y soluciones para los productos del mercado, encontrar nuevos métodos que desarrollen el pensamiento creativo a todos los niveles, etc. Pero pronto se extendió a otros ámbitos, incluyendo el mundo de desarrollo de sistemas; básicamente se busca que los involucrados en un proyecto desarrollen su creatividad, promoviendo la introducción de los principios creáticos.

A esta técnica se le conoce también como torbellino de ideas, tormenta de ideas, desencadenamiento de ideas, movilización verbal, bombardeo de ideas, sacudidas de cerebros, promoción de ideas, tormenta cerebral, avalancha de ideas, tempestad en el cerebro y tempestad de ideas, entre otras.

Principios de la lluvia de ideas

  • Aplazar el juicio y no realizar críticas, hasta que no agoten las ideas, ya que actuaría como un inhibidor. Se ha de crear una atmósfera de trabajo en la que nadie se sienta amenazado.
  • Cuantas más ideas se sugieren, mejores resultados se conseguirán: "la cantidad produce la calidad". Las mejores ideas aparecen tarde en el periodo de producción de ideas, será más fácil que encontremos las soluciones y tendremos más variedad sobre la que elegir.
  • La producción de ideas en grupos puede ser más efectiva que la individual.
  • Tampoco debemos olvidar que durante las sesiones, las ideas de una persona, serán asociadas de manera distinta por cada miembro, y hará que aparezcan otras por contacto.

El equipo en una lluvia de ideas debe estar formado por:

El Director: es la figura principal y el encargado de dirigir la sesión. Debe ser un experto en pensamiento creador. Su función es formular claramente el problema y que todos se familiaricen con él. Cuando lo haga, debe estimular ideas y hacer que se rompa el hielo en el grupo. Es el encargado de que se cumplan las normas, no permitiendo las críticas. Debe permanecer callado e intervenir cuando se corte la afluencia de ideas, por lo que le será útil llevar ya un listado de ideas. Debe hacer que todos participen y den ideas. Además, es la persona que da concede la palabra y da por finalizada la sesión. Posteriormente, clasificará las ideas de la lista que le proporciona el secretario. 

El secretario: registra por escrito las ideas según van surgiendo. Las enumera, las reproduce fielmente, las redacta y se asegura que todos están de acuerdo con lo escrito. Por último realizará una lista de ideas. 

Los participantes: pueden ser habituales o invitados; cualquier involucrado en el proyecto entra en esta categoría. Su función es producir ideas. Conviene que entre ellos no halla diferencias jerárquicas.

Las personas que componen el grupo deben estar motivadas para solucionar el problema, y con un ambiente que propicie la participación de todos. Todos pueden sentirse confiados y con la sensación de que pueden hablar sin que se produzcan críticas. Todas las ideas en principio deben tener el mismo valor, pues cualquiera de ellas puede ser la clave para la solución. Es necesario prestar mucha atención a las frases que pueden coartar la producción de ideas. Además durante la celebración no deben asistir espectadores.

Debemos evitar todos los bloqueos que paralizan la ideación: como son nuestros hábitos o ideas preconcebidas, el desánimo o falta de confianza en si mismo, el temor y la timidez.

Las fases de aplicación en el Brainstorm son:

Descubrir hechos

Al menos con un día de antelación, el director comunica por escrito a los miembros del grupo sobre los temas a tratar. El director explica los principios de la Tormenta de ideas e insiste en la importancia de tenerlos en cuenta. La sesión comienza con una ambientación de unos 10 minutos, tratando un tema sencillo y no comprometido. Es una fase especialmente importante para los miembros sin experiencia. Se determina el problema, delimitándolo, precisándolo y clarificándolo. A continuación se plantea el problema, recogiendo las experiencias que se poseen o consultando documentación. Cuando es complejo, conviene dividirlo en partes. Aquí es importante la utilización del análisis, desmenuzando el problema en pequeñas partes para conectar lo nuevo y lo desconocido.

Producir ideas (es la fase de tormenta de ideas propiamente dicha)

Se van aplicando alternativas. Se busca producir una gran cantidad de ideas, aplicando los principios que hemos visto. Además, es útil cuando se ha trabajado mucho, alejarse del problema, pues es un buen momento para que se produzcan asociaciones. Muchas de las nuevas ideas serán ideas antigüas, mejoradas o combinadas con varias ya conocidas.

Al final de la reunión, el director da las gracias a los asistentes y les ruega que no abandonen el problema, ya que al día siguiente se le pedirá una lista de ideas que les puedan haber surgido. Se incorporan las ideas surgidas después de la reunión.

Descubrir soluciones

Se elabora una lista definitiva de ideas, para seleccionar las más interesantes.  La selección se realiza desechando las ideas que no tienen valor y se estudia si son válidas las que se consideran interesantes. Lo mejor es establecer una lista de criterios de conveniencia para cada idea. Se seleccionan las ideas más útiles y si es necesario se ponderarán. Pueden realizarlo los mismos miembros del grupo o crear otros para esta tarea; la clasificación debe hacerse por categorías (tarea que corresponde al director). Se presentan las ideas de forma atractiva, haciendo uso de soportes visuales. 

Prototipos

Los prototipos permiten al desarrollador crear un modelo del software que debe ser construido.

Al igual que todos los enfoques al proceso de desarrollo del software, el prototipado comienza con la captura de requerimientos. Desarrolladores y clientes se reúnen y definen los objetivos globales del software, identifican todos los requerimientos que son conocidos, y señalan áreas en las que será necesaria la profundización en las definiciones. Luego de esto, tiene lugar un "diseño rápido". El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles al usuario (por ejemplo, entradas y formatos de las salidas). El diseño rápido lleva a la construcción de un prototipo. El prototipo es evaluado por el cliente y el usuario y utilizado para refinar los requerimientos del software a ser desarrollado. Un proceso de iteración tiene lugar a medida que el prototipo es "puesto a punto" para satisfacer las necesidades del cliente y permitiendo al mismo tiempo una mejor comprensión del problema por parte del desarrollador.

Existen principalmente dos tipos de prototipos:

Prototipo rápido (o concept prototipe): El prototipado rápido es un mecanismo para lograr la validación pre-compromiso. Se utiliza para validar requerimientos en una etapa previa al diseño específico. En este sentido, el prototipo puede ser visto como una aceptación tácita de que los requerimientos no son totalmente conocidos o entendidos antes del diseño y la implementación. El prototipo rápido puede ser usado como un medio para explorar nuevos requerimientos y así ayudar a "controlar" su constante evolución.

Prototipo evolutivo: Desde una perspectiva diferente, todo el ciclo de vida de un producto puede ser visto como una serie incremental de detallados prototipos acumulativos. Tradicionalmente, el ciclo de vida está dividido en dos fases distintas: desarrollo y mantenimiento. La experiencia ha demostrado que esta distinción es arbitraria y va en contra de la realidad ya que la mayor parte del costo del software ocurre después de que el producto se ha entregado. El punto de vista evolutivo del ciclo de vida del software considera a la primera entrega como un prototipo inicial en el campo. Modificaciones y mejoras subsecuentes resultan en nuevas entregas de prototipos más maduros. Este proceso continúa hasta que se haya desarrollado el producto final. La adopción de esta óptica elimina la distinción arbitraria entre desarrollo y mantenimiento, resultando en un importante cambio de mentalidad que afecta las estrategias para la estimación de costos, enfoques de desarrollo y adquisición de productos.

Proceso de Análisis Jerárquico (AHP)

Esta técnica tiene por objetivo resolver problemas cuantitativos, para facilitar el pensamiento analítico y las métricas. Consiste en una serie de pasos a saber:

  • Encontrar los requerimientos que van a ser priorizados.
  • Combinar los requerimientos en las filas y columnas de la matriz n x n de AHP.
  • Hacer algunas comparaciones de los requerimientos en la matriz
  • Sumar las columnas
  • Normalizar la suma de las filas
  • Calcular los promedios

Estos pasos pueden aplicarse fácilmente a una cantidad pequeña de requerimientos, sin embargo, para un volumen grande, esta técnica no es la más adecuada.

Administración de Requerimientos con Casos de Uso

¿Qué son los Casos de Uso?

Los casos de uso son una técnica para especificar el comportamiento de un sistema: "Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios."

Todo sistema de software ofrece a su entorno una serie de servicios. Un caso de uso es una forma de expresar cómo alguien o algo externo a un sistema lo usa. Cuando decimos "alguien o algo" hacemos referencia a que los sistemas son usados no sólo por personas, sino también por otros sistemas de hardware y software.

Por ejemplo, un sistema de ventas, si pretende tener éxito, debe ofrecer un servicio para ingresar un nuevo pedido de un cliente. Cuando un usuario accede a este servicio, podemos decir que está "ejecutando" el caso de uso ingresando pedido.

Los Casos de Uso fueron introducidos por Jacobson en 1992 [Jacobson92]. Sin embargo, la idea de especificar un sistema a partir de su interacción con el entorno es original de McMenamin y Palmer, dos precursores del análisis estructurado, que en 1984 definieron un concepto muy parecido al del caso de uso: el evento. Para McMenamin y Palmer, un evento es algo que ocurre fuera de los límites del sistema, ante lo cual el sistema debe responder. Siguiendo con nuestro ejemplo anterior, nuestro sistema de ventas tendrá un evento "Cliente hace Pedido". En este caso el sistema deberá responder al estimulo que recibe.

Sin embargo, existen algunas diferencias entre los casos de uso y los eventos. Las principales son:

  • Los eventos se centran en describir qué hace el sistema cuando el evento ocurre, mientras que los casos de uso se centran en describir cómo es el diálogo entre el usuario y el sistema.
  • Los eventos son "atómicos": se recibe una entrada, se la procesa, y se genera una salida, mientras que los casos de uso se prolongan a lo largo del tiempo mientras dure la interacción del usuario con el sistema. De esta forma, un caso de uso puede agrupar a varios eventos.
  • Para los eventos, lo importante es qué datos ingresan al sistema o salen de él cuando ocurre el evento (estos datos se llaman datos esenciales), mientras que para los casos de uso la importancia del detalle sobre la información que se intercambia es secundaria. Según esta técnica, ya habrá tiempo más adelante en el desarrollo del sistema para ocuparse de este tema.

Los casos de uso combinan el concepto de evento del análisis estructurado con otra técnica de especificación de requerimientos bastante poco difundida: aquella que dice que una buena forma de expresar los requerimientos de un sistema es escribir su manual de usuario antes de construirlo. Esta técnica, si bien ganó pocos adeptos, se basa en un concepto muy interesante: al definir requerimientos, es importante describir al sistema desde el punto de vista de aquél que lo va a usar, y no desde el punto de vista del que lo va a construir. De esta forma, es más fácil validar que los requerimientos documentados son los verdaderos requerimientos de los usuarios, ya que éstos comprenderán fácilmente la forma en la que están expresados.

Los Casos de Uso y UML

A partir de la publicación del libro de Jacobson, gran parte de los más reconocidos especialistas en métodos Orientados a Objetos coincidieron en considerar a los casos de uso como una excelente forma de especificar el comportamiento externo de un sistema. De esta forma, la notación de los casos de uso fue incorporada al lenguaje estándar de modelado UML (Unified Modeling Language) propuesto por Ivar Jacobson, James Rumbaugh y Grady Booch, tres de los precursores de las metodologías de Análisis y Diseño Orientado a Objetos, y avalado por las principales empresas que desarrollan software en el mundo. UML va en camino de convertirse en un estándar para modelado de sistemas de software de amplia difusión.

A pesar de ser considerada una técnica de Análisis Orientado a Objetos, es importante destacar que los casos de uso poco tienen que ver con entender a un sistema como un conjunto de objetos que interactúan, que es la premisa básica del análisis orientado a objetos "clásico". En este sentido, el éxito de los casos de uso no hace más que dar la razón al análisis estructurado, que propone que la mejor forma de empezar a entender un sistema es a partir de los servicios o funciones que ofrece a su entorno, independientemente de los objetos que interactúan dentro del sistema para proveerlos.

Como era de esperar, es probable que en el futuro los métodos de análisis y diseño que prevalezcan hayan adoptado las principales ventajas de todos los métodos disponibles en la actualidad (estructurados, métodos formales, métodos orientados a objetos, etc.).

Definiciones y Notaciones

Actores

Un actor es una agrupación uniforme de personas, sistemas o máquinas que interactúan con el sistema que estamos construyendo de la misma forma. Por ejemplo, para una empresa que recibe pedidos en forma telefónica, todos los operadores que reciban pedidos y los ingresen en un sistema de ventas, si pueden hacer las mismas cosas con el sistema, son considerados un único actor: "Empleado de Ventas".

Los actores son externos al sistema que vamos a desarrollar. Por lo tanto, al identificar actores estamos empezando a delimitar el sistema, y a definir su alcance. Definir el alcance del sistema debe ser el primer objetivo de todo analista, ya que un proyecto sin alcance definido nunca podrá alcanzar sus objetivos.

Es importante tener clara la diferencia entre usuario y actor. Un actor es una clase de rol, mientras que un usuario es una persona que, cuando usa el sistema, asume un rol. De esta forma, un usuario puede acceder al sistema como distintos actores. La forma más simple de entender esto es pensar en perfiles de usuario de un sistema operativo. Una misma persona puede acceder al sistema con distintos perfiles, que le permiten hacer cosas distintas. Los perfiles son en este caso equivalentes a los actores.

Otro sistema que interactúa con el que estamos construyendo también es un actor. Por ejemplo, si nuestro sistema deberá generar asientos contables para ser procesados por el sistema de contabilidad, este último sistema será un actor, que usa los servicios de nuestro sistema.

También puede ocurrir que el actor sea una máquina, en el caso en que el software controle sus movimientos, o sea operado por una máquina. Por ejemplo, si estamos construyendo un sistema para mover el brazo de un robot, el hardware del robot será un actor, asumiendo que dentro de nuestro sistema están las rutinas de bajo nivel que controlan al hardware.

Los actores se representan con dibujos simplificados de personas, llamados en inglés "stick man" (hombres de palo).

Si bien en UML los actores siempre se representan con "hombres de palo", a veces resulta útil representar a otros sistemas con alguna representación más clara.

 

Las flechas, que existían en la propuesta original de Jacobson, pero que desaparecieron del modelo semántico de UML, pueden usarse para indicar el flujo de información entre el sistema y el actor. Si la flecha apunta desde el actor hacia el sistema, esto indica que el actor está ingresando información en el sistema. Si la flecha apunta desde el sistema hacia el actor, el sistema está generando información para el actor.

Identificar a los actores es el primer paso para usar la técnica de casos de uso. Por ejemplo, en el sistema de pedidos nombrado anteriormente, sin conocer prácticamente ningún detalle sobre cómo funcionará, podemos decir que:

    • El grupo de usuarios que ingrese pedidos al sistema será un actor.
    • El grupo de usuarios que haga otras operaciones con los pedidos, como por ejemplo autorizarlos, cancelarlos y modificar sus plazos de entrega, será un actor.
    • Todo grupo de usuarios que reciba ciertos informes del sistema, como por ejemplo estadísticas de ventas, será un actor.

Es común que los distintos actores coincidan con distintas áreas de la empresa en la que se implementará el sistema, o con jerarquías dentro de la organización (empleado, supervisor y gerente son distintos actores, si realizan tareas distintas).

Todos los actores participan de los casos de uso. Ahora bien, es lógico que existan intersecciones entre lo que hacen los distintos actores. Por ejemplo, un supervisor puede autorizar pedidos, pero también puede ingresarlos. Veremos más adelante cómo, definiendo actores abstractos, podemos especificar este comportamiento común para evitar redundancia.

Casos de Uso

Como mencionamos anteriormente, un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios. Un caso de uso es iniciado por un actor. A partir de ese momento, ese actor, junto con otros actores, intercambian datos o control con el sistema, participando de ese caso de uso.

El nombre de un caso de uso se expresa con un verbo en gerundio, seguido generalmente por el principal objeto o entidad del sistema que es afectado por el caso. Gráficamente, los casos de uso se representan con un óvalo, con el nombre del caso en su interior.

Es importante notar que el nombre del caso siempre está expresado desde el punto de vista del actor y no desde el punto de vista del sistema. Por eso el segundo caso de uso se llama "Recibiendo información de pedidos" y no "Generando información de pedidos".

Los casos de uso tienen las siguientes características:

    • Están expresados desde el punto de vista del actor.
    • Se documentan con texto informal.
    • Describen tanto lo que hace el actor como lo que hace el sistema cuando interactúa con él, aunque el énfasis está puesto en la interacción.
    • Son iniciados por un único actor.
    • Están acotados al uso de una determinada funcionalidad del sistema, claramente diferenciada.

El último punto es tal vez el más difícil de definir. Uno podría, después de todo, decir que todo sistema tiene un único caso de uso denominado "Usando el Sistema". Sin embargo, la especificación resultante sería de poco utilidad para entenderlo; sería como implementar un gran sistema escribiendo un único programa.

La pregunta importante es: ¿Qué es una "funcionalidad claramente diferenciada"? Por ejemplo, ¿ingresar pedidos es un caso de uso y autorizarlos es otro? ¿Cancelar los pedidos, es otro caso de uso, o es parte del caso de uso referido al ingreso de pedidos?

Si bien se pueden encontrar argumentos válidos para cualquiera de las dos alternativas, en principio la respuesta a todas estas preguntas es que todos son casos de uso distintos. Lamentablemente, si en la programación los criterios para dividir la funcionalidad en programas suelen ser difusos, los criterios para dividir la funcionalidad de un sistema en casos de uso son aún más difusos, y por esto se hace importante usar el sentido común en estas decisiones.

En principio, podríamos decir que la regla general es: una función del sistema es un caso de uso si se debe indicar explícitamente al sistema que uno quiere acceder a esa función. Por ejemplo, si uno quiere dar de alta un pedido, accederá a la funcionalidad de "alta de pedidos del sistema". Sin embargo, si uno quiere dar de alta un campo del pedido, no debe indicar al sistema que quiere acceder a esa función. Dar de alta un campo de un pedido es una función que forma parte de un caso de uso mayor: "dar de alta un pedido".

Cuando pensamos en el grado de detalle de la división de los casos de uso también resulta útil imaginar que uno está escribiendo el manual del usuario del sistema. A nadie se le ocurriría escribir un manual de usuario con un solo capítulo en el que se describe toda su funcionalidad. De la misma forma, no se debe escribir una especificación con un solo caso de uso.

Extensiones (Extends)

Muchas veces, la funcionalidad de un caso de uso incluye un conjunto de pasos que ocurren sólo en algunas oportunidades. Supongamos que estamos especificando un sistema en el cual los clientes pueden ingresar pedidos interactivamente, y que dentro de la funcionalidad del ingreso de pedidos el usuario puede solicitar al sistema que le haga una presentación sobre los nuevos productos disponibles, sus características y sus precios. En este caso, tengo una excepción dentro del caso de uso "Ingresando Pedido". La excepción consiste en interrumpir el caso de uso y pasar a ejecutar el caso de uso "Revisando Presentación de Nuevos Productos". En este caso decimos que el caso de uso "Revisando Presentación de Nuevos Productos", extiende el caso de uso "Ingresando Pedido" y se representa por una línea de trazos desde el caso que ‘extiende a’ al caso que es ‘extendido’.

Las extensiones tienen las siguientes características:

    • Representan una parte de la funcionalidad del caso que no siempre ocurre.
    • Son un caso de uso en sí mismas.
    • No necesariamente provienen de un error o excepción.

Usos (Uses)

Es común que la misma funcionalidad del sistema sea accedida a partir de varios casos de uso. Por ejemplo, la funcionalidad de buscar un producto puede ser accedida desde el ingreso de pedidos, desde las consultas de productos, o desde los reportes de ventas por producto. ¿Cómo hago para no repetir el texto de esta funcionalidad en todos los casos de uso que la acceden? La respuesta es simple: sacando esta funcionalidad a un nuevo caso de uso, que es usado por los casos de los cuales fue sacada. Este tipo de relaciones se llama relaciones de uso y se representa por una línea punteada desde el caso que ‘usa a’ al caso que es ‘usado’.

Decimos, por ejemplo, que el caso de uso "Obteniendo reporte de ventas por producto", usa al caso de uso "Buscando producto".

Este concepto no es novedoso, es simplemente el concepto de la subrutina o subprograma usado en un nivel más alto de abstracción.

Las características de las relaciones de uso son:

    • Aparecen como funcionalidad común, luego de haber especificado varios casos de uso.
    • Los casos usados son casos de uso en sí mismos.
    • El caso es usado siempre que el caso que lo usa es ejecutado. Esto marca la diferencia con las extensiones, que son opcionales.

Abstracción

Al identificar relaciones de uso y extensión, puede ser que extraigamos casos de uso que son accedidos por varios actores. Por ejemplo, el caso de uso "buscando datos de producto" es accedido por muchos actores (el empleado de ventas que ingresa un pedido, el gerente que quiere obtener estadísticas por producto, el supervisor que quiere consultar la información de algún producto, etc.). Ahora bien, como el caso de uso nunca se ejecuta fuera del contexto de otro caso de uso, decimos que es un caso de uso abstracto. Lo llamamos abstracto porque no es implementable por sí mismo: sólo tiene sentido como parte de otros casos.

De la misma forma, el actor que participa de este caso de uso, que reúne características comunes a todos los actores de los casos de uso que lo usan, es un actor abstracto. En nuestro ejemplo, podemos decir que tenemos un actor abstracto "Buscador de Datos de Producto". Los actores abstractos, entonces, son necesarios para no dejar sin actores a los casos de uso abstractos.

Herencia

La duda ahora es cómo relacionar este actor abstracto con los actores concretos: los que sí existen en la realidad y ejecutan casos de uso concretos, como "ingresando pedido" y "obteniendo estadísticas de ventas".

Para esto podemos usar el concepto de herencia, uno de los conceptos básicos de la orientación a objetos. Como todos los actores concretos también ejecutan el caso "buscando datos de producto", a través de la relación de uso, podemos decir que los actores concretos heredan al actor abstracto.

La relación de herencia no necesariamente implica la existencia de un caso abstracto. Puede ocurrir que un actor ejecute todos los casos que ejecuta otro actor, y algunos más. En nuestro sistema, el supervisor de ventas puede hacer todo lo que hace el empleado de ventas, pero además puede autorizar pedidos. En este caso, podemos decir que el Supervisor de Ventas hereda al Empleado de Ventas, aunque el Empleado de Ventas no sea un actor abstracto. De esta forma, toda la funcionalidad que está habilitada para el Empleado de Ventas también lo está para el Supervisor.

El Proceso de Ingeniería de Requerimientos con Casos de Uso
A continuación, se describen los pasos a seguir para aplicar la técnica con casos de uso a la IR.
Identificar los Actores
Si la primera pregunta que un analista debe hacer a sus usuarios es ¿Para qué es este sistema?, la segunda es claramente ¿Para quiénes es este sistema? Como mencionamos al hablar sobre los actores, identificar a todos ellos es crítico para un buen análisis de requerimientos. Por lo tanto, antes de avanzar con los casos de uso, debo tratar de identificar todos los tipos de usuario diferentes que tiene el sistema. Si el sistema será implementado en una empresa, debo preguntar cuáles de las áreas afectadas usarán o actualizarán su información.

A pesar de hacer una identificación inicial de los actores, también debo repetirla a medida que empiezo a describir los casos de uso, ya que al conocer más detalles del sistema, pueden aparecer nuevos tipos de usuarios.

Identificar los Principales Casos de uso de cada Actor

El siguiente paso es enunciar los nombres de los principales casos de uso de cada uno de los actores que se identificaron en el paso anterior. No es necesario especificar cuáles son las acciones dentro del caso de uso. Tampoco debo preocuparme si no aparecen muchos casos, ya que existen técnicas para encontrar nuevos casos de uso a partir de los existentes.

Identificar Nuevos Casos a Partir de los Existentes

Uno de los principales errores que se pueden cometer al identificar requerimientos es algo que parece obvio, pero que muchas veces ocurre: ¡olvidarse de algún requerimiento! Como los requerimientos están en la cabeza de los usuarios, el éxito de esta tarea depende de la habilidad del analista. Para ayudarnos a identificar nuevos casos de uso a partir de los casos existentes, podemos aplicar las mismas técnicas utilizadas para identificar eventos según el análisis estructurado. Algunas de las preguntas que debemos hacernos son:

  • ¿Cuáles son las tareas de un actor?
  • ¿Necesita el actor estar informado de ciertas ocurrencias del sistema?
  • ¿Necesita el actor informar al sistema de cambios externos súbitos?
  • ¿Proporciona el sistema el comportamiento correcto al negocio?
  • ¿Pueden ser todos los requerimientos funcionales, desarrollados por los casos de uso?
  • ¿Qué casos de uso soportarán y mantendrán al sistema?
  • ¿Qué información debe ser modificada o creada?

Documentación de Casos de Uso

Una vez que identificamos todos los casos de uso, empezamos a documentar sus pasos; este documento se crea para cada caso de uso, detallando lo que el sistema debe proporcionar al actor cuando el caso de uso es ejecutado. Esta tarea no es estrictamente secuencial de la anterior: es posible que, mientras empezamos a documentar los casos, sigamos buscando otros nuevos.

Un contenido típico de un documento de caso de uso sería:

  • Describir cómo comienza el caso de uso y cómo termina.
  • Realizar un flujo normal de eventos.
  • Realizar un flujo alterno de eventos.
  • Detallar las excepciones al flujo de eventos.

Definir Prioridades

Una vez documentados los casos de uso, es conveniente definir las prioridades de los distintos requerimientos, expresados como casos de uso. Para los escenarios claves y los casos de uso que serán analizados en su iteración, se debe:

  • Representar la funcionalidad central de cada caso de uso.
  • Cubrir varios aspectos de arquitectura.
  • Poner bajo estrés un punto delicado de la arquitectura.

Gráficos a Utilizar

Dependiendo del tamaño del sistema, es probable que un único gráfico con todos los casos de uso nos quede chico. No olvidemos que los modelos gráficos son para aclarar el texto, y no para confundir. Si el gráfico de casos de uso es una maraña indescifrable, no está cumpliendo su objetivo. Por lo tanto, podemos usar las siguientes reglas para incluir gráficos de casos de uso dentro de la SRS.

    • Un gráfico de casos de uso no debe mostrar más de 15 casos
    • Si es necesario particionar el gráfico, debe hacerse por actor. La primera partición debe separar los casos centrales de los casos auxiliares, ya que probablemente les interesen a personas distintas.
    • Si las relaciones de uso y las extensiones entran en el diagrama principal, sin dejar de cumplir con la regla 1, debo dejarlas ahí. Lo mismo se aplica a los actores abstractos.
    • Si las relaciones de uso no entran en el diagrama principal, debo mostrarlas en gráficos teniendo en cuenta que siempre debo mostrar todos los casos de uso que usan a otro en un mismo diagrama.
    • Si tengo un caso de uso que es usado por gran parte de los otros casos, como por ejemplo el caso de uso "Identificándose ante el sistema", debo evitar mostrarlo en el gráfico principal, ya que las flechas serán imposibles de organizar. Es probable que no haga falta mostrar esta relación de uso en un gráfico.

Herramientas automatizadas para la Administración de Requerimientos

Hoy en día, la Ingeniería de Software cuenta con una serie de herramientas automatizadas destinadas a diferentes propósitos. Dentro de las herramientas CASE que sirven de apoyo a los procesos de Ingeniería de Software, están las especializadas en la administración de requisitos. Estas herramientas se concentran en capturar requerimientos, administrarlos y producir una especificación de requisitos.

Las ventajas que nos proporcionan la herramientas automatizadas para IR son:

  • Permiten un mayor control de proyectos complejos.
  • Permiten reducir costos y retrasos en la liberación de un proyecto.
  • Permiten una mayor comunicación en equipos de trabajo.
  • Ayudan a determinar la complejidad del proyecto y esfuerzos necesarios.

En este capítulo veremos dos de las herramientas más utilizadas para este propósito: RequisitePro y DOORS.

RequisitePro
RequisitePro(R) es la herramienta que ofrece Rational Software para tener un mayor control sobre los requerimientos planteados por el usuario y todos aquellos requerimientos técnicos o nuevos requerimientos de usuario que surjan durante el ciclo de vida del proyecto
.

Con RequisitePro los requerimientos se encuentran documentados bajo un esquema organizado de documentos; éstos esquemas, cumplen completamente con los estándares requeridos por IEEE, ISO, SEI, CMM y por el Rational Unified Process.

RequisitePro se integra con aplicaciones para la administración de cambios, herramientas de modelado de sistemas y con herramientas de pruebas. Esta integración asegura que los diseñadores conocen los requerimientos del usuario, del sistema y del software en el momento de su desarrollo. RequisitePro permite el desarrollo en equipo, vía el check-in y check-out de los documentos involucrados en el proyecto. Con esta integración, se pueden conservar juntos todos los requerimientos y ser manipulados por todos y cada uno de los miembros del equipo.

Todos los requerimientos tienen atributos y estos son la principal fuente de información para ayudarle a planear, comunicar y rastrear las actividades del proyecto a través del ciclo de vida. Cada proyecto tiene necesidades únicas y se deberán seleccionar los atributos que sean críticos para asegurar su éxito: prioridad de desarrollo, status, autor, responsable, relaciones, fecha de registro, fecha última modificación, versión, etc.

RequisitePro permite la asignación de prioridades a los requerimientos en base a:

  • Beneficios al cliente: Todos los requerimientos no son desarrollados de igual forma. Se les da prioridad en base a la importancia relativa del usuario final basado en un análisis previo de los analistas y desarrolladores del equipo.
  • Esfuerzo: Claramente, algunos requerimientos o cambios a éstos demandan más tiempo y recursos que otros. Estimar el número de semanas-personas o líneas de código requeridas en base a requerimientos, es la mejor forma de determinar que y que no puede ser desarrollado en el tiempo estipulado.

Una característica importante es que la curva de aprendizaje de RequisitePro es pequeña, este aprendizaje puede ser basado en el uso de los tutoriales, los cuales guían por los puntos principales en el uso de la herramienta.

Beneficios de RequisitePro

  • Permite el trabajo en equipo por medio de un repositorio compartido de información.
  • Permite la clasificación de requerimientos, en base a las necesidades de cada empresa:  usuario, técnicos, comunicación, pruebas.
  • Define atributos para todos los tipos de requerimientos especificados.
  • Ayuda a manipular el alcance del proyecto mediante la asignación de prioridad de desarrollo a cada uno de los requerimientos planteados.
  • Características avanzadas de rastreo, por medio de matrices, que permiten visualizar las dependencias entre requerimientos dentro de un proyecto o en diferentes proyectos.
  • Marcas que automáticamente indican cuándo un requerimiento es impactado por cambios a otro requerimiento o a atributos asociados.
  • Administración de cambios mediante el rastreo y la visualización histórica de los cambios efectuados al requerimiento, cuándo y quién los realizó.
  • Manejo de plantillas creadas por el usuario, o creadas por otras empresas.
  • Recolección de requerimientos mediante su importación por medio de Wizards para obtenerlos automáticamente de fuentes externas, incluyendo archivos o bases de datos.
  • Interactúa con los demás productos Rational para el ciclo de vida, así como con herramientas de Microsoft Office.
  • Ayuda a determinar en forma automatizada cuántos requerimientos tiene el proyecto.
  • Ayuda a determinar responsables y actores en cada uno de los requerimientos.
  • RequisitePro, le permite organizar sus requerimientos, establecer y mantener relaciones padre/hijo entre ellos.

Doors
DOORS(R) es la herramienta de administración de requisitos creada por Quality Systems and Software. Esta herramienta permite capturar, relacionar, analizar y administrar un rango de información para asegurar el cumplimiento del proyecto en materia de requerimientos
.
DOORS' permite el acceso de un gran número de usuarios concurrentes en la red, manteniendo en línea un gran número de requerimientos así como su información asociada.
DOORS ayuda al usuario a procesar las solicitudes de cambios de requerimientos en línea. Permite realizar cualquier modificación vía remota cuando la base de datos está off-line, incorporando sus actualizaciones a la base de datos maestra. Esto hace más fácil la comunicación del equipo con otras organizaciones, subcontratistas y proveedores.

Esta herramienta proporciona rastreabilidad multi-nivel para aquellas relaciones entre requerimientos que poseen gran tamaño. DOORS cuenta con un wizard que le permite generar enlaces a reportes de muchos niveles, para desplegarlos en la misma vista.

Beneficios de DOORS

  • Análisis y comparación de requerimientos.
  • Clasificación de requerimientos.
  • Interpretación manual de cada requerimiento.
  • Identificación de Inconsistencias.
  • Operación vía batch.
  • Permite compartir requerimientos entre proyectos.
  • Permite crear relaciones entre requerimientos mediante la táctica drag-and-drop
  • Envía una notificación vía email cuando los cambios son revisados.
  • Permite visualizar los cambios pendientes de otros usuarios para anticipar el impacto que ocasionará.
  • Despliega estadísticas y métricas a través de gráficas.
  • Los documentos están escritos en lenguaje claro, lo que proporciona una comprensión inmediata de cada requerimiento.
  • Permite importar sus documentos a formatos de herramientas de Microsoft Office, RTF, HTML, texto, entre otros.
  • Las plantillas presentan la información de manera estandarizada.

4. Análisis comparativo de las técnicas de ingeniería de requerimientos

En este capítulo se presentan las principales ventajas y desventajas de cada una de las técnicas utilizadas en las etapas de la Ingeniería de Requerimientos.

 

Técnica Ventajas Desventajas
 

 

 

Entrevistas y Cuestionarios

  • Mediante ellas se obtiene una gran cantidad de información correcta a través del usuario.
  • Pueden ser usadas para obtener un pantallazo del dominio del problema.
  • Son flexibles.
  • Permiten combinarse con otras técnicas.
  • La información obtenida al principio puede ser redundante o incompleta.
  • Si el volumen de información manejado es alto, requiere mucha organización de parte del analista, así como la habilidad para tratar y comprender el comportamiento de todos los involucrados.
 

 

Lluvia de Ideas

  • Los diferentes puntos de vista y las confusiones en cuento a terminología, son aclaradas por expertos.
  • Ayuda a desarrollar ideas unificadas basadas en la experiencia de un experto.
  •  
  • Es necesaria una buena compenetración del grupo participante.
 

 

 

Prototipos

  • Ayudan a validar y desarrollar nuevos requerimientos.
  • Permite comprender aquellos requerimientos que no están muy claros y que son de alta volatilidad.
  • El cliente puede llegar a pensar que el prototipo es una versión del software que será desarrollado.
  • A menudo, el desarrollador hace compromisos de implementación con el objetivo de acelerar la puesta en funcionamiento del prototipo
Análisis Jerárquico
  • Permite determinar el grado de importancia de cada requerimiento.
  • Ayuda a identificar conflictos en los requerimientos.
  • Muestra el orden en que deben ser implementados los requerimientos.
  • Debe construirse un estándar claro de evaluación, que incluya la participación del cliente.
 

 

Casos de Uso

  • Representan los requerimientos desde el punto de vista del usuario.
  • Permiten representar más de un rol para cada afectado.
  • Identifica requerimientos estancados, dentro de un conjunto de requerimientos.
  • En sistemas grandes, toma mucho tiempo definir todos los casos de uso.
  • El análisis de calidad depende de la calidad con que se haya hecho la descripción inicial.

 

En base a las ventajas y desventajas mostradas anteriormente, se hace una comparación entre algunas de las técnicas.

Entrevistas vs. Casos de Uso: Un alto porcentaje de la información recolectada durante una entrevista, puede ser usada para construir casos de uso. Mediante esto, el equipo de desarrollo puede entender mejor el ambiente de trabajo de los involucrados. Cuando el analista sienta que tiene dificultades para entender una tarea, pueden recurrir al uso de un cuestionario y mostrar los detalles recavados en un caso de uso. De hecho, durante las entrevistas cualquier usuario puede utilizar diagramas de casos de uso para explicar su entorno de trabajo.

Entrevistas vs. Lluvia de Ideas: Muchas de las ideas planteadas en el grupo, provienen información recopilada en entrevistas o cuestionarios previos. Realmente la lluvia de ideas trata de encontrar las dificultades que existen para la comprensión de términos y conceptos por parte de los participantes; de esta forma se llega a un consenso.

Casos de Uso vs. Lluvia de Ideas: La lista de ideas proveniente del brainstorm puede ser representada gráficamente mediante casos de uso.

El siguiente cuadro muestra las técnicas que pueden ser utilizadas en las diferentes actividades de la IR.

 

  Análisis del Problema Evaluación y negociación Especificación de Requisitos Validación Evolución
Entrevistas y Cuestionarios X       X
Lluvia de Ideas   X     X
Prototipos       X  
Análisis Jerárquico   X     X
Casos de Uso X   X   X

 

5. Conclusiones Y Recomendaciones

A pesar de la importancia que tiene la Ingeniería de Requerimientos, ha costado mucho que se le preste la atención adecuada a esta actividad. Aún quedan muchos desafíos que deben ser mejorados, tales como la integración de requerimientos funcionales y no funcionales, la evaluación de especificaciones alternativas, la formalización de la SRS, entre otras.

Cada actividad y técnica de la IR utilizada individualmente, dará diferentes soluciones para diferentes proyectos, incluyendo aquellos casos en los que el dominio y el área del problema son el mismo. Por esta razón, considero que no existe un modelo de proceso ideal para la IR; encontrar el método o la técnica perfecta es una ilusión, pues cada método y técnica ofrece diferentes soluciones ante un problema.

En esta investigación se presentaron una serie de actividades y técnicas, que no pertenecen a un modelo de proceso en sí, sino, que son una alternativa al material publicado por diferentes autores y que, desde mi punto de vista, son las más importantes.

Debemos recordar que la Ingeniería de Requerimientos es una actividad que involucra a clientes, usuarios, equipo de desarrollo, administradores de proyectos, etc.; por lo tanto, el proceso de IR no depende solamente de la forma en cómo se percibe el problema, sino también, del nivel de experiencia que tengan los involucrados.

Tomando en cuenta la magnitud de comunicación y el trabajo en equipo que debe existir en la IR, considero necesario enfatizar más en cerrar las brechas que todavía existen, incluyendo los siguientes elementos:

  • Factores sociales: involucrar al grupo para compartir sus experiencias.
  • Factores de problemas específicos: el dominio de la estructura y estándares disponibles.
  • Factores organizacionales: tiempo y costo presupuestados.
  • Factores de diseño: por ejemplo, interfases de usuario

Es importante tomarse el tiempo necesario para conocer a nuestros clientes y usuarios, así como su ambiente de trabajo. Esto, también ayuda a establecer una buena relación de trabajo y comunicación entre el equipo de desarrollo y los clientes. Es realmente necesario que los clientes y usuarios participen en la definición de sus requerimientos, pues ellos son los que deciden nuestro destino en el proyecto, deciden si les gustamos o no y además financian el proyecto.

En cuanto a la investigación realizada de la técnica de Casos de Uso para la Ingeniería de Requerimientos, puede decirse que los casos de uso son independientes del método de diseño que se utilice, y por lo tanto, del método de programación. Luego de documentar los requerimientos de un sistema con casos de uso, se puede diseñar un sistema "estructurado" (manteniendo una separación entre datos y funciones), o un sistema Orientado a Objetos, sin que la técnica sea de mayor o menor utilidad en alguno de los dos casos. Esto da más flexibilidad al método, y probablemente contribuya a su éxito.

Otro punto a considerar, es la inclusión del término "Administración de Requerimientos" en la década de los 90. Con esta nueva visión, se busca encontrar una descripción más apropiada de las actividades involucradas, a la vez de enfatizar la importancia de mantener una buena relación entre los afectados y el equipo del proyecto.

Entregar software de calidad, a tiempo y dentro del presupuesto, hará que nuestros clientes confíen y asegurará el crecimiento y madurez de la relación de negocio.

6. Referencias Bibliográficas

Libros
Senn, James A. "Análisis y Diseño de Sistemas de Información". Segunda Edición. McGraw Hill. 1992.
Fowler, Martín. "UML Gota a Gota". Primera edición. Addison Wesley Longman. 1999.
Publicaciones de diferentes Universidades encontradas en el Web
Brackett, Jhon W. "Software Requirements". Software Engineering Institute Education Program – Carnegie Mellon University.
1990.
Saiedian, H.; Dale, R. "Requirements Engineering: Making the connection between the software developer and customer". Department of Computer Science – University of Nebraska. 1999.
Oberg, Roger; Probasco Leslee; Ericsson, Maria. "Applying Requirements Management with Use Cases". Rational Software Corporation. 1998.
Hofmann, Hubert. "Requirements Engineering". Institute for Informatics – University of Zurich. 1993.
Object Management Group. "OMG Unified Modeling Language Specification". 1999.
Malan, Ruth. "Functional Requirements and Use Cases". Hewlette-Packard Company. 1999.
International Council of Systems Engineering. "INSIGTH – Requirements Sharing the Vision". Volumen 4. INCOSE. 2000.
Direcciones electrónicas sobre este tema
IEEE Task Force on Requirements Engineering. http://www.shu.ac.uk/tfre/web.links.html
Software Engineering Resources by Roger S. Pressman & Associates Inc. http://www.rspa.com/spi/index.html
Lista de publicaciones de un grupo de Ingeniería de Software. http://www.soi.city.ac.uk/~gespan/sw_group_pub.html
Publicaciones de Elsevier Science. http://www.elsevier.nl/

 

Trabajo enviado por:
Lizka Johany Herrera J.
johany@cwp.net.pa

Articulos relacionados:
Manual de Excel 7.0
Resumen:
Generalidades. Trabajo con libros y hojas de cálculos. Formateo de Libros de Trabajo. Operar con un libro de trabajo. Creación, Edición e Impresión de Gráficos. Impresión...
Teclas de acceso rápido en Windows (en PDF).- Guía rápida de las combinaciones de teclas para usar en este Sistema Operativo (pdf)
Resumen:
Este documento muestra las grandes posibilidades del uso del teclado bajo Windows. Si actualmente trabajas con un ordenador portátil (o sobremesa), no necesitarás utiliza...
El poder de la hoja de cálculo de Excel
Resumen:
El Poder del SOLVER. Ejemplo de cómo usar "SOLVER". Proceso de construcción de modelos.
Word 97 Manual de Referencia
Resumen:
Márgenes. Asistentes. Iconos. Página. Presentación preliminar. Impresión. Tablas. Barras de menu. Insertar. Vincular. Tabulación. Tablas, filas y columnas. Indices alfabé...
Manual Básico e Intermedio de Word 97
Resumen:
Lo Básico. Barra de Herramientas. Formato. Herramientas de Texto. Inserción de Objetos. Tablas. Más Herramientas. Hacer Páginas Web. Conceptos básicos de Visual Basic for...
Copyright © 2011 ilustrados.com, Monografias, tesis, bibliografias, educacion. Tofos los temas y publicaciones son propiedad de sus respectivos autores ©