TESIS:
PROPUESTA DE UN MODELO DE HERRAMIENTA CASE EN LA ETAPA DE DETERMINACIÓN DE
REQUERIMIENTOS
COMENTARIOS A:
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.
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
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.
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
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.
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.
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.
Las herramientas CASE tienen puntos débiles
significativos, los cuales amenazan con minar los beneficios potenciales.
ü
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.
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.
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
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 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.
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
ü
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
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