El documento presenta el modelo de requisitos y casos de uso del Equipo 4. Describe que el modelo tiene como objetivo capturar los requisitos de los usuarios de manera estructurada para facilitar la transición al esquema conceptual. Explica que los casos de uso especifican la funcionalidad del sistema desde la perspectiva del usuario y que los actores representan los roles de los usuarios. Además, resume que el modelo de requisitos consiste en tres modelos: comportamiento basado en casos de uso, presentación/interfaces y información/dominio del problema.

1. MODELO DE REQUISITOS Y CASOS DE USO.
EQUIPO 4.
Introducción
El Modelo de Requisitos tiene como objetivo ofrecer una serie de técnicas y
métodos para capturar los requisitos de los usuarios de una manera
estructurada, así como facilitar la transición al Esquema Conceptual
manteniendo la trazabilidad. Para conseguirlo, el modelo emplea una
aproximación basada en los casos de uso, la cual se usa ampliamente en
entornos de ingeniería de requisitos, con la diferencia de que la información
recolectada se orienta de cara a generar el esquema conceptual.
La finalidad del modelo de requisitos es capturar de una manera precisa lo que el cliente
quiere que se construya. Además, el propósito es modelar los requisitos de tal manera
que personas que no estén familiarizadas con la notación empleada puedan entenderlos y
revisarlos. La notación es lo suficientemente precisa para que pueda servir de base para la
fase de modelado conceptual. Los conceptos básicos de los que se hace uso son los
actores y los casos de uso. Debido a que los casos de uso son simples y a que las
descripciones de los casos de uso se fundamentan en conceptos naturales que pueden

2. encontrarse en el espacio del problema, los clientes y los usuarios finales pueden
participar activamente en el modelado de requisitos.
A pesar de estas ventajas, existen dos inconvenientes principales:
Es difícil encontrar el nivel de abstracción correcto para especificar los casos de
uso (lo que en realidad es un caso de uso)
También es complicado encontrar un proceso para analizar y traducir las
especificaciones de los casos de uso en un modelo conceptual.
Las técnicas que se utilizan en el modelo de requisitos presentado para solucionar estos
problemas son las siguientes:
Misión del Sistema (2.1.1): describe la finalidad del sistema en una o dos frases.
También describe las responsabilidades más significativas así como una lista de
características que el sistema no va a hacer.
Árbol de Refinamiento de Funciones (2.1.2): asociado al particionamiento de las
interacciones externas de acuerdo a diferentes áreas del negocio u objetivos del
negocio.
Modelo de Casos de Uso (2.2): incluye las especificaciones de Casos de Uso para
especificar la composición de las interacciones externas y el Diagrama de Casos de
Uso para mostrar la comunicación entre el entorno (actores) y el sistema.
El objetivo fundamental del Modelo de Casos de Uso es la especificación de actores y
casos de uso y el establecimiento de las relaciones que entre ellos se producen. El
modelado de requisitos utiliza los elementos del Modelo de Casos de Uso propuesto por
Jacobson, bajo el esquema conceptual y notacional definido en UML [Jac&Al 92][UML
Web Site].
La combinación de Casos de Uso se modela estableciendo relaciones entre ellos. Con esta
finalidad, se utilizan las relaciones de extensión e inclusión. La forma de representar estas
relaciones de extensión e inclusión habrán de adecuarse a la forma en la que se
especifican los Casos de Uso y en la que se modelan los Diagramas de Secuencia ya que
estas dos herramientas son esenciales para conseguir la trazabilidad deseada entre el
Modelo de Requisito y del Modelo Conceptual.
Modelo de Requisitos
El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la
funcionalidad que debe ofrecer desde la perspectiva del usuario. Este modelo puede
funcionar como un contrato entre el desarrollador y el cliente o usuario del sistema, y por

3. lo tanto proyecta lo que el cliente desea según la percepción del desarrollador. Por lo
tanto, es esencial que los clientes puedan comprender este modelo.
El modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base para la
formación de todos los demás modelos en el desarrollo de software. En general, el
cualquier cambio en la funcionalidad del sistema es más fácil de hacer, y con menores
consecuencias, a este nivel que posteriormente. El modelo de requisitos que
desarrollaremos se basa en la metodología Objectory (Jacobson et al. 1992), basada
principalmente en el modelo de casos de uso.
Actualmente esta metodología es parte del Proceso Unificado de Rational (RUP). El
modelo de casos de uso y el propio modelo de requisitos son la base para los demás
modelos, como se describió anteriormente en el Capítulo 3 y se resume aquí:
Requisitos: El modelo de casos de uso sirve para expresar el modelo de requisitos,
el cual se desarrolla en cooperación con otros modelos como se verá más
adelante.
Análisis: La funcionalidad especificada por el modelo de casos de uso se estructura
en el modelo de análisis, que es estable con respecto a cambios, siendo un modelo
lógico independiente del ambiente de implementación.
Diseño: La funcionalidad de los casos de uso ya estructurada por el análisis es
realizada por el modelo de diseño, adaptándose al ambiente de implementación
real y refinándose aún más.
Implementación: Los casos de uso son implementados mediante el código fuente
en el modelo de implementación.
Pruebas: Los casos de uso son probados a través de las pruebas de componentes y
pruebas de integración.
Documentación: El modelo de casos de uso debe ser documentado a lo largo de
las diversas actividades, dando lugar a distintos documentos como los manuales
de usuario, manuales de administración, etc.
El diagrama de la Figura ilustra los distintos modelos.
El propósito del modelo de requisitos es comprender completamente el problema y sus
implicaciones. Todos los modelos no solamente se verifican contra el modelo de

4. requisitos, sino que también se desarrollan directamente de él. El modelo de requisitos
sirve también como base para el desarrollo de las instrucciones operacionales y los
manuales ya que todo lo que el sistema deba hacer se describe aquí desde la perspectiva
del usuario. El modelo de requisitos no es un proceso mecánico, el analista debe
interactuar constantemente con el cliente para completar la información faltante, y así
clarificar ambigüedades e inconsistencias. El analista debe separar entre los requisitos
verdaderos y las decisiones relacionadas con el diseño e implementación. Se debe indicar
cuales aspectos son obligatorios y cuales son opcionales para evitar restringir la
flexibilidad de la implementación. Durante el diseño se debe extender el modelo de
requisitos con especificaciones de rendimiento y protocolos de interacción con sistemas
externos, al igual que provisiones sobre modularidad y futuras extensiones. En ciertas
ocasiones ya se puede incluir aspectos de diseño, como el uso de lenguajes de
programación particulares.
En la metodología de Objectory, el modelo de requisitos consiste de tres modelos
principales, visualmente representado por un diagrama de tres dimensiones como se
muestra en la Figura.
El modelo de comportamiento, basado directamente en el modelo de casos de
uso, especifica la funcionalidad que ofrece el sistema desde el punto de vista del
usuario. Este modelo utiliza dos conceptos claves: actores para representar los

5. distintos papeles que los usuarios pueden jugar con el sistema, y casos de uso para
representar qué pueden hacer los actores con respecto al sistema
El modelo de presentación o modelo de interfaces o borde especifica cómo
interactúa el sistema con actores externos al ejecutar los casos de uso, en
particular, en los sistemas de información ricos en interacción con el usuario,
especifica cómo se verán visualmente las interfaces gráficas y que funcionalidad
ofrecerá cada una de ellas.
El modelo de información o modelo del dominio del problema especifica los
aspectos estructurales del sistema.
Este modelo conceptualiza el sistema según los objetos que representan las entidades
básicas de la aplicación.
Aunque en muchas metodologías se permite especificar la funcionalidad completa del
sistema utilizando el modelo del dominio del problema, incluyendo operaciones formales
sobre los objetos correspondientes a un modelo de requisitos expresado sin casos de uso,
el modelo del dominio del problema será de mucha más ayuda como apoyo al modelo de
casos de uso y no como una entidad totalmente independiente.
Es importante resaltar que esta separación en tres ejes de modelado independientes es la
base para una mayor estabilidad en el desarrollo del sistema, permitiendo minimizar los
efectos de cada uno sobre los otros dos.
CASOS DE USO.
Los casos de uso describen una interacción típica entre un usuario (actores) y un sistema
de cómputo. Es una técnica para capturar información de cómo un sistema o negocio
trabaja actualmente, o de cómo se desea que trabaje Produce algo de valor para algún
actor como el cálculo de algún resultado Describe qué hace un sistema pero no especifica
cómo lo hace El caso de uso capta alguna función visible para el usuario. El caso de uso
puede ser pequeño o grande. El caso de uso logra un objetivo discreto para el usuario. Un
caso de uso debe ser simple, claro y conciso.
Los casos de uso sirven para capturar el comportamiento deseado del sistema sin tener
que especificar cómo se implementa ese comportamiento Como medio de comprensión
del sistema para desarrolladores, usuarios finales y expertos del dominio, ayudan a validar
la arquitectura y a verificar el sistema en el transcurso del desarrollo de este.
ACTORES.
 Representa un conjunto de roles que los usuarios de los casos de uso juegan al
interactuar con éstos.

6.  Representa un rol que es jugado por una persona, un dispositivo hardware u otro
sistema que interactúe con nuestro sistema.
Se puede definir categorías generales de actores (como cliente) y especializarlos (como
ClienteComercial) a través de relaciones de generalización Cliente Cliente Comercial actor
actor generalización
 Un actor y un caso de uso se pueden comunicar a través de una asociación en
donde cada uno de ellos pueden enviar y recibir mensaje.
¿COMO SE DEBE CREAR UN CASO DE USO?
 Tras localizar los actores, procede el describirlos
 especificar describiendo un flujo de eventos
 Los actores sólo pueden conectar a los casos de uso a través de asociaciones
 Generalmente hay pocos actores asociados a cada Caso de Uso
 Preguntas clave:
 ¿cuáles son las tareas del actor?
 ¿qué información crea, guarda, modifica, destruye o lee el actor?
 ¿debe el actor notificar al sistema los cambios externos?
 ¿debe el sistema informar al actor de los cambios internos?
LA DESCRIPCIÓN DE LOS CASOS DE USO COMPRENDEN:
 el inicio: cuándo y qué actor lo produce?
 el fin: cuándo se produce y qué valor devuelve?

7.  la interacción actor-caso de uso: qué mensajes intercambian ambos?

Objetivo del caso de uso:
 ¿qué intenta el caso de uso? cronología y origen de las informaciones repeticiones
de comportamiento:
 ¿qué operaciones son iteradas?

situaciones opcionales:
 ¿qué ejecuciones alternativas se presentan en el caso de uso?
MODELOS PRESCRIPTIVOS DEL DESARROLLO DE SISTEMAS DE INFORMACIÓN
Modelo de Proceso de Software IEEE.
Análisis de requerimientos
Extraer los requisitos y requerimientos de un producto de software es la primera etapa
para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene
que hacer, se requiere de habilidad y experiencia en la ingeniería de software para
reconocer requerimientos incompletos, ambiguos o contradictorios. El resultado del
análisis de requerimientos con el cliente se plasma en el documento ERS, Especificación de
Requerimientos del Sistema, cuya estructura puede venir definida por varios estándares,
tales como CMMI. Asimismo, se define un diagrama de Entidad/Relación, en el que se
plasman las principales entidades que participarán en el desarrollo del software.
La captura, análisis y especificación de requerimientos (incluso pruebas de ellos), es una
parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se
han ideado modelos y diversos procesos de trabajo para estos fines. Aunque aún no está
formalizada, ya se habla de la Ingeniería de requerimientos, por ejemplo en dos capítulos
del libro de Sommerville "Ingeniería del software" titulados "Requerimientos del
software" y "Procesos de la Ingeniería de Requerimientos".
La IEEE Std. 830-1998 normaliza la creación de las especificaciones de requerimientos de
software (Software Requirements Specification).

8. Especificación
La especificación de requisitos describe el comportamiento esperado en el software una
vez desarrollado. Gran parte del éxito de un proyecto de software radicará en la
identificación de las necesidades del negocio (definidas por la alta dirección), así como la
interacción con los usuarios funcionales para la recolección, clasificación, identificación,
priorización y especificación de los requisitos del software.
Entre las técnicas utilizadas para la especificación de requisitos se encuentran:
Caso de uso,
Historias de usuario,
Siendo los primeros más rigurosos y formales, los segundas más ágiles e informales.
Arquitectura
La integración de infraestructura, desarrollo de aplicaciones, bases de datos y
herramientas gerenciales, requieren de capacidad y liderazgo para poder ser
conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El rol en el
cual se delegan todas estas actividades es el del Arquitecto.
El arquitecto de software es la persona que añade valor a los procesos de negocios gracias
a su valioso aporte de soluciones tecnológicas.
La arquitectura de sistemas en general, es una actividad de planeación, ya sea a nivel de
infraestructura de red y hardware, o de software.
La arquitectura de software consiste en el diseño de componentes de una aplicación
(entidades del negocio), generalmente utilizando patrones de arquitectura. El diseño
arquitectónico debe permitir visualizar la interacción entre las entidades del negocio y
además poder ser validado, por ejemplo por medio de diagramas de secuencia. Un diseño
arquitectónico describe en general el cómo se construirá una aplicación de software. Para
ello se documenta utilizando diagramas, por ejemplo:
Diagramas de clases
Diagramas de base de datos
Diagrama de despliegue
Diagrama de secuencia

9. Siendo los dos primeros los mínimos necesarios para describir la arquitectura de un
proyecto que iniciará a ser codificado. Depende del alcance del proyecto, complejidad y
necesidades, el arquitecto elige qué diagramas elaborar.
Las herramientas para el diseño y modelado de software se denominan CASE, (Computer
Aided Software Engineering) entre las cuales se encuentran:
Enterprise Architect
Microsoft Visio for Enterprise Architects
Programación
Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de
software, pero no necesariamente es la que demanda mayor trabajo y ni la más
complicada. La complejidad y la duración de esta etapa está íntimamente relacionada al o
a los lenguajes de programación utilizados, así como al diseño previamente realizado.
Prueba
Consiste en comprobar que el software realice correctamente las tareas indicadas en la
especificación del problema. Una técnica de prueba es probar por separado cada módulo
del software, y luego probarlo de forma integral, para así llegar al objetivo. Se considera
una buena práctica el que las pruebas sean efectuadas por alguien distinto al
desarrollador que la programó, idealmente un área de pruebas; sin perjuicio de lo anterior
el programador debe hacer sus propias pruebas. En general hay dos grandes formas de
organizar un área de pruebas, la primera es que esté compuesta por personal inexperto y

10. que desconozca el tema de pruebas, de esta forma se evalúa que la documentación
entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede
entenderlos y el software hace las cosas tal y como están descritas. El segundo enfoque es
tener un área de pruebas conformada por programadores con experiencia, personas que
saben sin mayores indicaciones en qué condiciones puede fallar una aplicación y que
pueden poner atención en detalles que personal inexperto no consideraría.
Documentación
Todo lo concerniente a la documentación del propio desarrollo del software y de la
gestión del proyecto, pasando por modelaciones (UML),diagramas de casos de uso,
pruebas, manuales de usuario, manuales técnicos, etc. todo con el propósito de
eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.
Mantenimiento
Fase dedicada a mantener y mejorar el software para corregir errores descubiertos e
incorporar nuevos requisitos. Esto puede llevar más tiempo incluso que el desarrollo del
software inicial. Alrededor de 2/3 del tiempo de ciclo de vida de un proyecto2 está
dedicado a su mantenimiento. Una pequeña parte de este trabajo consiste eliminar
errores (bugs); siendo que la mayor parte reside en extender el sistema para incorporarle
nuevas funcionalidades y hacer frente a su evolución.
Modelos y filosofías de desarrollo de software
La ingeniería de software dispone de varios modelos, paradigmas y filosofías de
desarrollo, en los cuales se apoya para la construcción del software, entre ellos se puede
citar:
Modelo en cascada o Clásico (modelo tradicional)
Modelo de prototipos
Modelo en espiral
Desarrollo por etapas
Desarrollo iterativo y creciente o Iterativo e Incremental
RAD (Rapid Application Development)
Desarrollo concurrente
Proceso Unificado

11. RUP (Proceso Unificado de Rational)
Naturaleza de la IS
La ingeniería de software tiene que ver con varios campos en diferentes formas:
Matemáticas
Los programas tienen muchas propiedades matemáticas. Por ejemplo la corrección y la
complejidad de muchos algoritmos son conceptos matemáticos que pueden ser
rigurosamente probados. El uso de matemáticas en la IS es llamado métodos formales.
Creación
Los programas son construidos en una secuencia de pasos. El hecho de definir
propiamente y llevar a cabo estos pasos, como en una línea de ensamblaje, es necesario
para mejorar la productividad de los desarrolladores y la calidad final de los programas.
Este punto de vista inspira los diferentes procesos y metodologías que se encuentran en la
IS.
Gestión de Proyectos
El desarrollo de software de gran porte requiere una adecuada gestión del proyecto. Hay
presupuestos, establecimiento de tiempos de entrega, un equipo de profesionales que
liderar. Recursos (espacio de oficina, insumos, equipamiento) por adquirir. Para su
administración se debe tener una clara visión y capacitación en Gestión de Proyectos.
Arte
Los programas contienen muchos elementos artísticos. Las interfaces de usuario, la
codificación, etc. Incluso la decisión para un nombre de una variable o una clase. Donald
Knuth es famoso por argumentar a la programación como un arte.
3.6. HERRAMIENTAS CASE.
Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software
Asistida por Computadora) son diversas aplicaciones informáticas destinadas a aumentar
la productividad en el desarrollo de software reduciendo el costo de las mismas en
términos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los
aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar

12. un diseño del proyecto, cálculo de costos, implementación de parte del código
automáticamente con el diseño dado, compilación automática, documentación o
detección de errores entre otras, que analizaba la relación existente entre los requisitos
de un problema y las necesidades que éstos generaban, el lenguaje en cuestión se
denominaba PSL (Problem Statement Language) y la aplicación que ayudaba a buscar las
necesidades de los diseñadores PSA (Problem Statement Analyzer).
Aunque ésos son los inicios de las herramientas informáticas que ayudan a crear nuevos
proyectos informáticos, la primera herramienta CASE fue Excelerator que salió a la luz en
el año 1984 y trabajaba bajo una plataforma PC.
Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época en la
que IBM había conseguido una alianza con la empresa de software AD/Cycle para trabajar
con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban
todo el ciclo de vida del software. Pero poco a poco los mainframes han ido siendo menos
utilizados y actualmente el mercado de las Big CASE ha muerto completamente abriendo
el mercado de diversas herramientas más específicas para cada fase del ciclo de vida del
software.
Objetivos
1. Mejorar la productividad en el desarrollo y mantenimiento del software.
2. Aumentar la calidad del software.
3. Reducir el tiempo y coste de desarrollo y mantenimiento de los sistemas
informáticos.
4. Mejorar la planificación de un proyecto
5. Aumentar la biblioteca de conocimiento informático de una empresa ayudando a
la búsqueda de soluciones para los requisitos.
6. Automatizar el desarrollo del software, la documentación, la generación de código,
las pruebas de errores y la gestión del proyecto.
7. Ayuda a la reutilización del software, portabilidad y estandarización de la
documentación
8. Gestión global en todas las fases de desarrollo de software con una misma
herramienta.
9. Facilitar el uso de las distintas metodologías propias de la ingeniería del software.

13. Clasificación
Aunque no es fácil y no existe una forma única de clasificarlas, las herramientas CASE se
pueden clasificar teniendo en cuenta los siguientes parámetros:
1. Las plataformas que soportan.
2. Las fases del ciclo de vida del desarrollo de sistemas que cubren.
3. La arquitectura de las aplicaciones que producen.
4. Su funcionalidad.
La siguiente clasificación es la más habitual basada en las fases del ciclo de desarrollo que
cubren:
Upper CASE (U-CASE), herramientas que ayudan en las fases de planificación,
análisis de requisitos y estrategia del desarrollo, usando, entre otros diagramas
UML.
Middle CASE (M-CASE), herramientas para automatizar tareas en el análisis y
diseño de la aplicación.

14. Lower CASE (L-CASE), herramientas que semi-automatizan la generación de código,
crean programas de detección de errores, soportan la depuración de programas y
pruebas. Además automatizan la documentación completa de la aplicación. Aquí
pueden incluirse las herramientas de Desarrollo rápido de aplicaciones.
Existen otros nombres que se le dan a este tipo de herramientas, y que no es una
clasificación excluyente entre sí, ni con la anterior:
Integrated CASE (I-CASE), herramientas que engloban todo el proceso de
desarrollo software, desde análisis hasta implementación.

15. MetaCASE, herramientas que permiten la definición de nuestra propia técnica de
modelado, los elementos permitidos del metamodelo generado se guardan en un
repositorio y pueden ser usados por otros analistas, es decir, es como si
definiéramos nuestro propio UML, con nuestros elementos, restricciones y
relaciones posibles.
CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de
software
.
IPSE (Integrated Programming Support Environment), herramientas que soportan
todo el ciclo de vida, incluyen componentes para la gestión de proyectos y gestión
de la configuración activa.

16. Por funcionalidad podríamos diferenciar algunas como:
Herramientas de generación semiautomática de código.
Editores UML.
Herramientas de Refactorización de código.
Herramientas de mantenimiento como los sistemas de control de versiones.
Case mas utilizada: CASE ERWIN:

17. Es una herramienta de diseño de base de datos. Brinda productividad, en diseño,
generación y mantenimiento de aplicaciones. Permite visualizar la estructura, los
elementos importantes, y optimizar el diseño de la base de datos. Genera
automáticamente las tablas y miles de líneas de stored procedure y triggers para los
principales tipos de base de datos. ERwin hace fácil el diseño de una base de datos. Los
diseñadores de bases de datos sólo apuntan y pulsan un botón para crear un gráfico del
modelo E-R (Entidad- relación) de todos sus requerimientos de datos y capturar las reglas
de negocio en un modelo lógico, mostrando todas lasentidades, atributos, relaciones, y
llaves importantes.
ERwin establece una conexión entre una base de datos diseñada y una base de
datos, permitiendo transferencia entre ambas y la aplicación de ingeniería reversa.
Usando esta conexión, Erwin genera automáticamente tablas, vistas, índices,
reglas de integridad referencial (llaves primarias, llaves foraneas), valores por
defecto y restricciones de campos ydominios.
44. ERwin soporta principalmente bases de datos relacionales SQL y bases de
datos que incluyen Oracle, Microsoft SQL Server, Sybase, DB2, e Informix. El mismo
modelo puede ser usado para generar múltiples bases de datos, o convertir una
aplicación de unaplataforma de base de datos a otra.