TESIS: PROPUESTA DE UN MODELO DE HERRAMIENTA CASE EN LA ETAPA DE DETERMINACIÓN DE REQUERIMIENTOS

 

COMENTARIOS A:

bherrera@pampano.unacar.mx

behesa_pe@msn.com

behesa70@yahoo.com.mx

 

CAPITULO I

INTRODUCCIÓN

 

No siempre han tenido éxito los proyectos  mediante las herramientas CASE , no obstante  en muchas organizaciones actuales  no se disponen de análistas formados, ni de experiencias CASE y las causas más frecuentes por las que puede fracasar un proyecto son:

 

Ø      No se tienen en cuenta las tres primeras etapas del ciclo de vida del desarrollo de sistemas

Ø      No se concreta ninguna metodología

Ø      El proyecto de evaluación es demasiado ambicioso

Ø      Los usuarios no están motivados

 

Para la mayoría de las organizaciones de tamaño medio y grandes, y para las compañías de desarrollo de software la problemática de hoy no esta en la decisión de adquirir un CASE, sino sobre todo en la propia introducción del CASE en las primeras etapas del ciclo de vida.

 

La introducción del case se lleva a cabo teniendo en cuenta todos los aspectos considerados con el desarrollo de un proyecto informático, en el cuál se le añade las características muy particulares de los usuarios.

 

Las herramientas para la productividad  configuran la dimensión de la tecnología en el cuarteto personas – proceso  - producto – tecnología, y como tales desempeñan un papel muy importante en el desarrollo de un sistema.

 

El adoptar una nueva herramienta puede ser una de las formas más rápidas de mejorar la productividad, pero también puede ser una de las más arriesgadas

 

PLANTEAMIENTO DEL PROBLEMA

 

Se propone un modelo de herramienta CASE en la Etapa de determinación de requerimiento .

 

En la actualidad existe diversas herramientas CASE que sirven de apoyo para el desarrollo de sistemas, las cuales se caracterizan por el aumento en la productividad y garantizan una calidad.

 

Las herramientas de ayuda al desarrollo de sistemas, surgieron para dar solución a los problemas de diversas empresas: plazos y presupuestos incumplidos, insatisfacción del usuario, escasa productividad y baja calidad de los desarrollos. Una de las herramientas que se dirige principalmente a mejorar la calidad, es las herramientas CASE (ingeniería de software asistida por computadora) otras a mejorar la productividad.

 

Las herramientas para productividad producen en raras ocasiones el ahorro de tiempo prometido a sus clientes, aunque el utilizar una nueva herramienta, puede que disminuya inicialmente la productividad., otras aunque han sido descartadas proporcionan en ciertos casos ahorros significativos en la planificación.

 

Para Poder alcanzar una mayor productividad y calidad en el desarrollo de un sistema debemos:

 

Ø      Contar con una herramienta que permita satisfacer las necesidades de los analistas y de los usuarios.

Ø      Facilitar la revisión de aplicación.

Ø      Dar un soporte para el desarrollo de prototipo de sistemas en la fase de determinación de requerimientos.

Ø      Mejorar la habilidad para satisfacer los requerimientos del usuario.

 

Actualmente ninguna de las herramientas CASE en la etapa de determinación de requerimientos aportan o cumple con todas las necesidades que requieren los analistas y desarrolladores de sistemas.

 

Existen herramientas que dan más apoyo en las fases de análisis y diseño de sistema pero no se cuenta con una herramienta que de apoyo, soporte y facilidad para la fase de determinación de los requerimientos, sobre todo que es una de las etapas en la cual se basa éxito del desarrollo de un sistema.

 

El contar con una herramienta que nos de: disminución de tiempo, nos garantiza consistencia y automatización las tareas tediosas de determinar los requerimientos basándose en las actividades de:

Ø      Anticipación de requerimiento.

Ø       Investigación de requerimientos.

Ø       Especificación de requerimientos.

 

Se puede lograr una mejor determinación de requerimientos que cumpla con las necesidades de los análistas y usuarios considerando los siguientes puntos:

 

Ø      Estableciendo una estrategia para la determinación y requerimiento tomando en cuenta los diversos medios, para adquirir información sobre lo que se pretende solucionar:

·        ¿como se va a lograr?

·         ¿con que se cuenta?

·         ¿qué proceso son necesarios?

·      ¿cómo se va automatizar las tareas manuales?

·      ¿Qué Requerimientos son funcionales y cuales no?

 

 

Ø      Utilizando una metodología de análisis y diseño de sistemas estructurado, el cual tiene la habilidad para mejorar la exactitud de los requerimientos específicos de las aplicaciones.

 

Ø      Llevar acabo el modelo de herramienta Case el cual contara con todos los aspectos considerados en el desarrollo de un sistema en la etapa de la determinación de requerimiento en base a las investigaciones preliminares del sistema.

 

Ø      Basándose en la metodología de Pressman

 

 

OBJETIVO:

 

Establecer un modelo para una herramienta case con un enfoque estructurado que permita apoyar en la determinación de requerimientos para el desarrollo de un sistema, cumpliendo con las necesidades de los analistas y usuarios.

 

HIPÓTESIS

 

Con el desarrollo de un modelo de herramientas CASE debe mejorar la determinación de los requerimientos para el desarrollo de un sistema, siendo esta una de las tapas más importantes, permitiendo determinar las características particulares, así como las restricciones que debe tener un sistema, este modelo podrá:


 

·        Cumplir con las necesidades de los analistas y usuarios

·        Adquirir Mayor Comunicación con la siguiente etapa del desarrollo de un sistema

·        Tener la habilidad que se requiere para lograrlo

 

MARCO TEÓRICO

 

Ø      Herramientas Case

Ø      Desarrollo rápido de aplicaciones

Ø      El papel de los requerimientos en el desarrollo del software

Ø      Determinación de requerimiento.

Ø      Tipos de Requerimientos

Ø      Trabajos relacionados

 

TRABAJOS RELACIONADOS

 

v     Evaluación de proyectos informáticos

v     Herramientas CASE

v     www.paisvirtual.com/informatica/aplicaciones/hendrix/herracase.htm

www.bvs.sld.cu/instituciones/cecam/amcim41.htm

 

CAPITULO  2

 

HERRAMIENTAS CASE

 

Las Herramientas de Ayuda al Desarrollo de Sistemas de Información, surgieron para intentar dar solución a los problemas inherentes a los proyectos de generación de aplicaciones informáticas: plazos y presupuestos incumplidos, insatisfacción del usuario, escasa productividad y baja calidad de los desarrollos. Algunas de estas herramientas se dirigen principalmente a mejorar la calidad, como es el caso de las herramientas CASE (Computer Aided Software Engineering- Ingeniería de Software Asistida por Computadora). Otras van dirigidas a mejorar la productividad durante la fase de construcción, como es el caso de los lenguajes de cuarta generación (4GL-Fourth Generation Language).

 

Son un conjunto de métodos, utilidades y técnicas que facilitan la automatización del ciclo de vida del desarrollo de sistemas de información, completamente o en alguna de sus fases.

 

El empleo de herramientas Case permiten integrar el proceso de ciclo de vida:

 

ü      Análisis de datos y procesos integrados mediante un repositorio.

ü      Generación de interfaces entre el análisis y el diseño.

ü      Generación del código a partir del diseño.

ü      Control de mantenimiento.


 

TIPOS DE HERRAMIENTAS CASE

 

No existe una única clasificación de herramientas CASE y, en ocasiones, es difícil incluirlas en una clase determinada. Podrían clasificarse atendiendo a:

 

ü      Las plataformas que soportan.

ü      Las fases del ciclo de vida del desarrollo de sistemas que cubren.

ü      La arquitectura de las aplicaciones que producen.

ü      Su funcionalidad.

 

Las herramientas CASE, en función de las fases del ciclo de vida , se pueden agrupar de la forma siguiente:

 

Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son llamadas también CASE workbench.

Las herramientas I-CASE se basan en una metodología. Tienen un repositorio y aportan técnicas estructuradas para todas las fases del ciclo de vida. Estas son las características que les confieren su mayor ventaja: una mejora de la calidad de los desarrollos. Sin embargo, no todas ellas son modernas en el sentido de aprovechar la potencia de las estaciones de trabajo o la utilización de lenguajes de alto nivel o técnicas de prototipo.

 

Herramientas que comprenden algunas fases del ciclo de vida de desarrollo de software:

ü      Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior) o front-end, orientadas a la automatización y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: análisis y diseño. Una estrategia posible es utilizar una U-CASE para análisis y diseño, combinada con otras herramientas más modernas para las fases de construcción y pruebas. En este caso, habría que vigilar cuidadosamente la integración entre las distintas herramientas.

 

ü      Herramientas de bajo nivel, L-CASE (Lower CASE - CASE inferior) o back-end, dirigidas a las últimas fases del desarrollo: construcción e implantación.

ü      Juegos de herramientas o toolkits, son el tipo más simple de herramientas CASE.

 

Las que Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se encontrarían las herramientas de reingeniería, orientadas a la fase de mantenimiento como son:

 

ü      Herramientas de planificación de sistemas de gestión.

ü      Herramientas de análisis y diseño

ü      Herramientas de programación

ü      Herramientas de integración y prueba 

ü      Herramientas de gestión de prototipos

ü      Herramientas de mantenimiento

ü      Herramientas de gestión de proyectos

ü      Herramientas de soporte

 

BENEFICIOS DE LAS HERRAMIENTAS CASE

 

Entre los beneficios ofrecidos por la tecnología CASE se encuentran los siguientes:

 

ü      Facilidad para la revisión de aplicaciones

ü      Soporte para el desarrollo de prototipos de sistemas

ü      Generación de código

ü      Mejora en la habilidad para satisfacer los requerimientos del usuario

ü      Soporte interactivo para el proceso de desarrollo


 

 

Facilidad para la revisión de aplicaciones

 

Las herramientas CASE proporcionan un beneficio substancial para las organizaciones al facilitar la revisión de las aplicaciones. Contar con un depósito central agiliza el proceso de revisión ya que éste proporciona bases para las definiciones y estándares para los datos. Las capacidades de generación interna, si se encuentran presentes, contribuyen  a modificar el sistema por medio de las especificaciones más que por los ajustes al código fuente.

 

Soporte para el desarrollo de prototipos de sistemas

 

El desarrollo de prototipos de aplicaciones toma varias formas. En ocasiones se desarrollan diseños para pantallas y reportes con la finalidad de mostrar la organización y composición de los datos, encabezados y mensajes. Los ajustes necesarios al diseño se hacen con rapidez para alterar la presentación y las características de la interfase. Sin embargo, no se prepara el código fuente, de naturaleza orientada hacia procedimientos, como una parte del prototipo.

 

Generación de código

 

Algunas herramientas CASE tienen la capacidad de producir el código fuente. La ventaja más visible de esta característica es la disminución del tiempo necesario para preparar un programa. Sin embargo, la generación del código también asegura una estructura estándar y consistente para el programa (lo que tiene gran influencia en el mantenimiento) y disminuye la ocurrencia de varios tipos de errores, mejorando de esta manera la calidad. Las características de la generación del código permiten volver a utilizar el software y las estructuras estándares para generar dicho código, así como el cambio de una especificación modular, lo que significa volver a generar  el código y los enlaces con otros módulos. Ninguna de las herramientas que existen en el presente es capaz de generar un código completo.

 

Mejora en la habilidad  para satisfacer los requerimientos del usuario

 

Es bien conocida la importancia de satisfacer los requerimientos del usuario, ya que esto guarda relación con el éxito del sistema. De manera similar, tener los requerimientos correctos mejora la calidad de las practicas de desarrollo. Parece ser que las herramientas CASE disminuyen el tiempo de desarrollo, una característica que es importante para los usuarios. Las herramientas afectan la naturaleza y cantidad de interacción entre los encargados del desarrollo y el usuario. Las descripciones gráficas y los diagramas, así como los prototipos  de reportes y la composición de las pantallas, contribuyen a un intercambio de ideas más efectivo.

 

Soporte interactivo para el proceso de desarrollo

 

La experiencia ha demostrado que el desarrollo de sistemas es un proceso interactivo. Las herramientas CASE soportan pasos interactivos al eliminar el tedio manual de dibujar diagramas, elaborar catálogos y clasificar. Como resultado de esto, se anticipa que los analistas repasarán y revisarán los detalles del sistema con mayor frecuencia y en forma más consistente.

 

DEBILIDADES DE LAS HERRAMIENTAS CASE

 

Las herramientas CASE tienen puntos débiles significativos, los cuales amenazan con minar los beneficios potenciales.


 

Falta de niveles estándar para el soporte de la metodología

 

No existe un conjunto “estándar” de herramientas CASE. Por tanto, se debe tener precaución al seleccionar una herramienta de este tipo.

 

Existen dos significados para las palabras “soporte de la metodología”. Una herramienta puede:

1) Dar soporte a los diagramas que emplea una metodología

2) Soportarlos e imponer la metodología, sus reglas y procesos.

 

Las herramientas CASE que existen en el presente, tienen una de las siguientes características:

 

ü      Son independientes de la metodología.

ü      Permiten que los usuarios definan sus propias metodologías.

ü      Soportan una metodología.

ü      Soportan las metodologías más diseminadas.

 

En todas ellas existen ciertos compromisos. Las herramientas que son independientes de la metodología, no pueden fomentar el uso de las reglas y estándares de la misma. Estas herramientas quizá proporcionen los componentes de una metodología  (por ejemplo: diagramas de flujos de datos, un diccionario de datos y facilidades para la descripción de procesos), pero no el marco de referencia, reglas y procedimientos que en realidad constituyen el núcleo de la metodología. Aunque se puede llevar a cabo acciones básicas para la validación de diseños y diagramas para detectar  componentes faltantes, éstas son sólo funciones mecánicas. Por otra parte, esta clase de herramientas no puede proporcionar ayuda metodológica o pedir al usuario que realice tareas necesarias para la metodología que aún esta sin terminar.

 

Estas herramientas mejoran la productividad al efectuar tareas tediosas y de documentación, aunque ellas no puedan asegurar buenos resultados. Desde el punto de vista funcional, las capacidades que brindan para garantizar la calidad son mínimas.

 

Conflictos en el uso de los diagramas

 

Las herramientas difieren en el uso que hacen los diagramas. Algunas son herramientas exclusivamente para gráficas, que se abocan al dibujo de diagramas para el análisis de entrada y salida de datos. Este tipo de herramientas puede restringir ya sea el proceso de desarrollo normal seguido por una organización  o el estilo particular de trabajo de los analistas.

 

Otros vendedores de herramientas consideran los diagramas como documentación y aceptan entradas por medio de formas o lenguajes de especificación y, en ocasiones, en forma gráfica. Por tanto, se debe tener cuidado cuando se selecciona una herramienta para apoyar los métodos existentes en una organización

 

Diagramas no utilizados

 

En general, los productos CASE emplean gráficas para modelar y generar informes sobre el análisis y desarrollo de sistemas. Una de las afirmaciones de los vendedores de herramientas es que las presentaciones gráficas y la documentación mejoran la comunicación entre los miembros del equipo de desarrollo, propician una calidad mayor de la entrada proporcionada por el cliente y mejoran la productividad de desarrollo de software. Sin embargo, los investigadores han encontrado que, en algunos casos, las herramientas gráficas, automatizadas o manuales, no se emplean del todo. O tal vez no se utilicen en la forma que deberían emplearse. Por otra parte, algunos analistas prefieren para algunas tareas un lenguaje estructurado o descriptivo.

Muchos profesionales de los sistemas de información no hacen uso de herramientas gráficas en el desarrollo de software; más bien las emplean para automatizar la producción de informes y documentación del sistema, como los diagramas de flujo utilizados por los programadores para documentar un programa una vez terminado.

 

Alcance limitado

 

Aunque muchas herramientas basadas en computadoras incluyen la capacidad de verificar las especificaciones para determinar su complementes o consistencia, virtualmente no llevan a cabo ningún análisis de los requerimientos de la aplicación. Por tanto, el alcance de las actividades de desarrollo asociado con las herramientas existentes es bastante limitado.

 

La mayor parte de productos CASE describe (documenta) pero no analiza. De poca ayuda es proporcionar una regla de inclusión en los mejores enfoques y una regla de exclusión para los que son poco satisfactorios. No ofrecen o evalúan, soluciones potenciales para los problemas relacionados con sistemas. Y tampoco existe una garantía clara para que dos analistas que utilicen los mismos métodos aplicados a información idéntica, formulen recomendaciones igualmente aceptables.

 

COMPONENTES Y FUNCIONALIDADES DE UNA HERRAMIENTA CASE

 

A continuación se describen los principales componentes de una herramienta CASE y sus funcionalidades:

 

Repositorio. Base de datos central de una herramienta CASE. El repositorio amplia el concepto de diccionario de datos para incluir toda la información que se va generando a lo largo del ciclo de vida del sistema, como por ejemplo: componentes de análisis y diseño (diagramas de flujo de datos, diagramas entidad - relación, esquemas de bases de datos, diseños de pantallas), estructuras de programas, algoritmos, etc. En algunas referencias se le denomina Diccionario de Recursos de Información.

 

La mayoría de las herramientas CASE poseen un repositorio propio o bien trabajan sobre un repositorio suministrado por otro fabricante o vendedor.

 

Apoyándose en la existencia del repositorio se efectúan comprobaciones de integridad y consistencia:

ü      Que no existan datos no definidos.

ü      Que no existan datos autodefinidos (datos que se emplean en una definición pero que no han sido definidos previamente).

ü      Que todos los alias (referencias a un mismo dato empleando nombres distintos) sean correctos y estén actualizados.

 

Las características más importantes de un repositorio son:

 

Tipo de información: Que contiene alguna metodología concreta, datos, gráficos, procesos, informes, modelos o reglas.

 

Tipo de controles:  Incorpora algún módulo de gestión de cambios, de mantenimiento de versiones, de acceso por clave, de redundancia de la información. La gestión de cambios y el mantenimiento de versiones, ayudarán en el caso de que convivan diferentes versiones de la misma aplicación o se tengan que realizar cambios en la versión en producción y en la de desarrollo, simultáneamente.

 

Tipo de actualización: Si los cambios en los elementos de análisis o diseño se ven reflejados en el repositorio en tiempo real o mediante un proceso por lotes (batch). Esto será importante en función a la necesidad de que los cambios sean visibles por todos los usuarios, en el acto.

 

Reutilización de módulos para otros diseños: El repositorio es la clave para identificar, localizar y extraer código para su reutilización.

 

Posibilidad de exportación e importación: Para extraer información del repositorio y tratarla con otra herramienta (formateo de documentos, mejora de presentación) o incorporar al repositorio, información generada por otros medios.

 

Interfases automáticas con otros repositorios:  O bases de datos externas.

 

Módulos de diagramación y modelización:   Algunos de los diagramas y modelos utilizados con mayor frecuencia son:

 

ü      Diagrama de flujo de datos.

ü      Modelo entidad - interrelación.

ü      Historia de la vida de las entidades.

ü      Diagrama Estructura de datos.

ü      Diagrama Estructura de cuadros.

ü      Técnicas matriciales.

 

Algunas características referentes a los diagramas son:

Número máximo de niveles: Para poder soportar diseños complejos.

 

Número máximo de objetos: Que se pueden incluir para no encontrarse limitado en el diseño de grandes aplicaciones.

 

Número de diagramas distintos en pantalla:  O al mismo tiempo en diferentes ventanas.

 

 

 

Dibujos en formato libre: Con la finalidad de añadir comentarios, dibujos, información adicional para aclarar algún punto concreto del diseño.

 

Actualización del repositorio por cambios en los diagramas: Resulta más fácil modificar de forma gráfica un diseño y que los cambios queden reflejados en el repositorio.

 

Control sobre el tamaño, fuente y emplazamiento de los textos: En el diagrama.

 

Comparaciones entre gráficos de distintas versiones: De esta forma será más fácil identificar qué diferencias existen entre las versiones.

 

Inclusión de pseudocódigo:  Que servirá de base a los programadores para completar el desarrollo de la aplicación.

 

Posibilidad de deshacer el último cambio: Facilitando que un error no conlleve perder el trabajo realizado.

 

Herramienta de prototipado.  El objetivo principal de esta herramienta es poder mostrar al usuario, desde los momentos iniciales del diseño, el aspecto que tendrá la aplicación una vez desarrollada. Ello facilitará la aplicación de los cambios que se consideren necesarios, todavía en la fase de diseño.

 

La herramienta será tanto más útil, cuanto más rápidamente permita la construcción del prototipo y por tanto antes, se consiga la implicación del usuario final en el diseño de la aplicación. Asimismo, es importante poder aprovechar como base el prototipo para la construcción del resto de la aplicación. Actualmente, es imprescindible utilizar productos que incorporen esta funcionalidad por la cambiante tecnología y necesidades de los usuarios.

 

Los prototipos han sido utilizados ampliamente en el desarrollo de sistemas tradicionales ya que proporcionan una realimentación inmediata, que ayudan a determinar los requisitos del sistema. Las herramientas CASE están bien dotadas, en general, para crear prototipos con rapidez y seguridad.

 

Generador de código:  Normalmente, se suele utilizar sobre ordenadores personales o estaciones de trabajo, por lo que el paso posterior del código al host puede traer problemas, al tener que compilar en ambos entornos.

 

Las características más importantes de los generadores de código son:

 

ü      Lenguaje generado:  Si se trata de un lenguaje estándar o un lenguaje propietario.

ü      Portabilidad del código generado: Capacidad para poder ejecutarlo en diferentes plataformas físicas y/o lógicas.

ü      Generación del esqueleto del programa o del programa completo: Si únicamente genera el esqueleto será necesario completar el resto mediante programación.

ü      Posibilidad de modificación del código generado: Suele ser necesario acceder directamente al código generado para optimizarlo o completarlo.

ü      Generación del código asociado a las pantallas e informes de la aplicación: Mediante esta característica se obtendrá la interfase de usuario de la aplicación.

 

Módulo generador de documentación: El módulo generador de la documentación se alimenta del repositorio para transcribir las especificaciones allí contenidas.


 

Algunas características de los generadores de documentación son:

 

ü      Generación automática a partir de los datos del repositorio, sin necesidad de un esfuerzo adicional.

ü      Combinación de información textual y gráfica, lo que hace más fácil su comprensión.

ü      Generación de referencias cruzadas. Con ello se podrá localizar fácilmente en qué partes de la aplicación se encuentra un determinado objeto o elemento, con el fin de analizar el impacto de un cambio o identificar los módulos afectados por un determinado error.

ü      Ayuda de tratamiento de textos. Facilidad para la introducción de textos complementarios a la documentación que se genera de forma automática.

ü      Interfase con otras herramientas: procesadores de textos, editores gráficos, etc.

 

 Módulo de gestión de proyectos: Algunos productos CASE incorporan un módulo para la gestión del proyecto de desarrollo de sistemas. Sus características más importantes serán analizadas en el apartado de otras herramientas.


 

 

CAPITULO 3

 

DESARROLLO RAPIDO DE APLICACIONES

 


 

 

CAPITULO 4

 

DETERMINACIÓN DE REQUERIMIENTOS

 

La determinación de requerimientos, es una de las etapas básicas para el desarrollo de sistemas de información, en la cual se hace un estudio del sistema actual, de conocer como trabaja , y que se puede mejorar , con la finalidad  de conocer los métodos actuales o si es o si es necesario  hacer algunos ajustes, en sí significa estudiar el sistema existente y recopilar los datos en relación con éste para recopilar cuales son esos requerimientos.

 

Un requerimiento es una nueva características  que debe incluirse en un nuevo sistema , que consiste en la forma de captar o procesar datos , producir una información, controlar alguna actividad o dar apoyo. En sí es un rango de instrucciones abstractas de alto nivel de un servicio o de un sistema, limitado a detallar una especificación funcional matemática.

 

Es inevitable como los Requerimientos pueden servir en una función dual

 

ü      Puede ser la base para una declaración de un contrato, por lo tanto, deber estar abierto a interpretación.

ü      Puede ser la base para el contrato en sí, por lo tanto, debe ser definido en detalle.

ü      Ambas declaraciones serán  llamadas  Requerimientos

 

REQUERIMIENTOS BÁSICOS

 

Para obtener los requerimientos se debe hacer ciertas preguntas, que nos conlleven a conocer dichos requerimientos.

 

1. ¿ Cuál es el proceso básico?

Se  requiere de antecedentes de datos fundamentales  y de las descripciones del sistema, como:

ü      El propósito de esa actividad

ü       Pasos que se realizan 

ü      En donde se realizan

ü       Quien los ejecuta

ü      Tiempo que consumen

ü       Frecuencia con que se realizan 

ü      Quien utiliza la información resultante

 

Con base a estas cuestiones , proporcionan un amplio entendimiento más amplio de los procesos básicos

 

2. ¿Qué datos se utilizan o se producen durante este proceso

 

Es necesario conocer los datos que deben utilizarse  para realizar  esta actividad, así como la información resultante.

 

3. ¿Cuáles son los limites impuestos  por tiempo y cantidad de trabajo

 

4. ¿Qué controles de rendimiento utilizan?

 

 

DEFINICIÓN / ESPECIFICACIÓN DE REQUERIMIENTOS

 

Definición de Requerimientos: Una declaración en un Lenguaje Natural incluye los diagramas de los servicios del sistema y sus límites operacionales, escrito para clientes.

 

 

Especificación de Requerimientos: Un documento estructurado con descripción o detalle de los servicios del sistema, escrito como un contrato entre el cliente y el contratista.

 

Especificación de Software: Descripción detallada de software, la cual, puede servir como una base para diseño o implementación, escrito para desarrolladores.

 

Definición de Requerimientos: El Software proporciona significado de representación y acceso a archivos externos creados por otras herramientas

 

 

Especificación de Requerimientos: El usuario debe proporcionar facilidades para definir el tipo de archivos externos.

 

 

ü      Cada tipo de archivo externo puede tener una herramienta asociada. La cual, será aplicada para el archivo.

ü      Cada tipo de archivo externo será representado como un icono específico mostrado al    usuario.

ü      Las facilidades proporcionadas para la representación del icono en un tipo de archivo    externo será definido por el usuario.

ü      Cuando un usuario selecciona una representación de icono de un archivo externo, el        efecto de la selección es aplicar las herramientas asociadas con el tipo de archivo externo al archivo representado por la selección del icono.

 

 

 

 

 

 

 

 

 

 

Clases de Requerimientos

 

 

Requerimientos Durables: Establecer requerimientos derivados de las actividades de la organización del cliente. Por ejemplo, un hospital siempre tendrá doctores, enfermeras, etc. Puede ser derivado de modelos de dominio.

Requerimientos Volátiles: Los requerimientos cambian durante el desarrollo o cuando el sistema está en uso. En un hospital, los requerimientos  se derivan de las políticas salud-cuidados.

 

Clasificación de Requerimientos

 

ü      Requerimientos Cambiantes: Los requerimientos que cambian por el ambiente del sistema.

ü      Surgimiento de los Requerimientos: Requerimientos que surgen como una comprensión del desarrollo del sistema.

ü      Requerimientos en Consecuencial: Requerimientos que resultan de la introducción del sistema a la computadora.

ü      requerimientos Compatibles: Requerimientos que dependen de otros sistemas o de otros procesos de la organización.

 

Cambios en el Documento de Requerimientos

 

ü      El documento de requerimientos debe ser organizado, de tal forma que los cambios en los requerimientos puedan ser hechos sin tener que re-escribir demasiado.

ü      Las referencias externas deben ser minimizadas y las secciones del documento deben ser tan modulares como sea posible.

ü      Los cambios son fáciles cuando se trata de un documento electrónico. Sin embargo, la falta de estándares para documentos electrónicos lo hace  difícil.

 

 

 

 

 

 

Análisis de Requerimientos

 

Entendiendo los requerimientos del cliente para un sistema de software

 

Objetivos

ü      Describir diferentes enfoques para descubrir los requerimientos.

ü      Explicar la necesidad de un análisis desde múltiples perspectivas

ü      Ilustrar un enfoque estructurado al análisis de requerimientos

ü      Explicar por qué influyen los factores organizacionales y sociales en los requerimientos del sistema

 

 

Análisis de Requerimientos

 

ü      A veces llamados extracción ó exploración de los requerimientos

ü      Involucra trabajo técnico de grupo con los clientes para averiguar el dominio de la aplicación, los servicios que el sistema debe proporcionar y las restricciones operacionales propias del sistema

ü      Debe involucrar a los usuarios finales, administradores, ingenieros de mantenimiento, etc. Quienes son llamados líder especialista “stakeholders”

 

Problemas del análisis de requerimientos

 

ü      Los especialistas (stakeholders) no saben realmente lo que quieren

ü      Éstos expresan requerimientos en sus términos propios

ü      Diferentes especialistas pueden tener requerimientos en conflicto

ü      Los factores políticos y organizacionales pueden influir en los requerimientos del sistema

ü      Los requerimientos cambian durante el proceso de análisis. Y pueden surgir nuevos especialistas

 

 

 

 

 

 


 

 

ESTRUCTURA DE LA TESIS

 

1.      INTRODUCCIÓN

2.      HERRAMIENTAS CASE.

3.      DESARROLLO RAPIDO DE APLICACIONES

4.      DETERMINACIÓN DE REQUERIMIENTOS

5.      PROPUESTA DEL MODELO.

6.      DESCRIPCIÓN DEL MODELO

7.      CASO DE ESTUDIO.

8.      TRABAJO A FUTURO.

9.      CONCLUSIONES.

10.  BIBLIOGRAFÍA


 

BIBLIOGRAFÍA.

 

INGENIERÍA DEL SOFTWARE

ROGER S. PRESMAN

 

ANÁLISIS Y DISEÑO DE SISTEMAS

KENDALL & KENDALL

 

ANÁLISIS Y DISEÑO DE SISTEMA DE INFORMACIÓN

JAMES A. SENN

 

DESARROLLO Y GESTION DE PROYECTOS INFORMATICOS

STEVE MCCONNELL

1