2016-Guia Trabajos Practicos

SISTEMAS
UTN-FRT
2016
ANÁLISIS DE SISTEMAS 2016

Guía de Trabajos Prácticos y del Proyecto Final Integrador
Integrantes de la Cátedra
ASOCIADA Mg. Ing. Mabel Torres
ADJUNTA Ing. Silvana Marsiglia
J.T.P. Ing. Adriana Sueldo
AUX. Ing. Liliana del Prado
AUX. Ing. Francisco J. Vicente
0
Contenido
Incumbencias del Ingeniero en Sistemas de Información...................................................................... 2
Información sobre la materia.................................................................................................................3
Objetivos ...........................................................................................................................................3
Contenidos Mínimos..........................................................................................................................3
Requisitos para regularizar la asignatura ...........................................................................................3
Trabajos Prácticos .............................................................................................................................3
Ejercicios Conceptuales – Ejercicios de Autoevaluación – Situaciones problemáticas ....................3
Casos de Estudio........................................................................................................................... 4
Contenido de la carpeta de Trabajos Prácticos ............................................................................. 4
Parciales ........................................................................................................................................... 4
Recuperaciones de Parciales ......................................................................................................... 4
Proyecto Integrador ......................................................................................................................... 4
Examen Final .................................................................................................................................... 5
Programa Analítico .............................................................................................................................. 6
0 Repaso de Sistemas y Organizaciones .......................................................................................... 8
1 Trabajo Práctico N°1 ....................................................................................................................10
2 Trabajo Práctico N°2 ................................................................................................................... 13
3 Trabajo Práctico N°3 ....................................................................................................................19
4 Trabajo Práctico N°4 .................................................................................................................. 22
5 Trabajo Práctico N°5................................................................................................................... 29
6 Trabajo Práctico N°6 ...................................................................................................................36
9 Trabajo Práctico N°9 ...................................................................................................................55
1
Incumbencias del Ingeniero en Sistemas de Información
Incumbencias del Ingeniero en Sistemas de

Información
Según Ordenanza 1150 UTN
 Participar en la toma de decisiones estratégicas de una organización y asesorar, en
concordancia con las mismas acerca de las políticas de desarrollo de sistemas de información.
 Evaluar, clasificar y seleccionar proyectos de sistemas de información y evaluar y seleccionar
alternativas de asistencia interna.
 Planificar, efectuar y evaluar los estudios de factibilidad inherentes a todo proyecto de diseño
de sistemas de información y de modificación o reemplazo de los mismos, así como los
sistemas de computación asociados.
 Planificar, dirigir, ejecutar y controlar el relevamiento, análisis, diseño, desarrollo,
implementación y prueba de sistemas de información.
 Evaluar y seleccionar los sistemas de programación disponibles con miras a su utilización en
sistemas de información.
 Evaluar y seleccionar, desde el punto de vista de los sistemas de información, los equipos de
procesamiento y comunicación y los sistemas de base.
 Organizar y dirigir el área de sistemas; determinar el perfil de los recursos humanos necesarios
y contribuir a su selección y formación.
 Participar en la elaboración de programas de capacitación para la utilización de sistemas de
información.
 Determinar y controlar el cumplimiento de las pautas técnicas que rigen el funcionamiento y
la utilización de recursos informáticos en cada organización.
 Elaborar métodos y normas a seguir en cuestiones de seguridad y privacidad de la información
procesada y/o generada por los sistemas de información; participar en la determinación de las
acciones a seguir en esta materia y evaluar su aplicación.
 Elaborar métodos y normas a seguir en cuestión de salvaguardia y control, de los recursos
físicos y lógicos, de un sistema de computación; participar en la determinación de las acciones
a seguir en esta materia y evaluar su aplicación.
 Desarrollar modelos de simulación, sistemas expertos y otros sistemas informáticos
destinados a la resolución de problemas y asesorar en su aplicación.
 Realizar auditorías en áreas de sistemas y centros de cómputos así como en los sistemas de
información utilizados.
 Realizar arbitrajes, pericias y tasaciones referidas a los sistemas de información y a los medios
de procesamiento de datos.
 Realizar estudios e investigaciones conducentes a la creación y mejoramiento de técnicas de
desarrollo de sistemas de información y nuevas aplicaciones de la tecnología informática
existente
2
Información sobre la materia

Objetivos
 Elaborar modelos conceptuales de un sistema de información.
 Conocer las distintas etapas del proceso de desarrollo de sistemas de información.
 Modelar las características intrínsecas de los sistemas de información.
 Conocer y aplicar las metodologías, modelos, técnicas y lenguajes de la etapa de análisis.
 Seleccionar adecuadamente los modelos que mejor se adapten para dar soluciones a los
problemas de información.
 Conocer y aplicar los elementos que componen la ingeniería de requerimientos.
 Documentar el proceso de análisis de sistemas de información.
Contenidos Mínimos
 Procesos de desarrollo de SI. Metodologías y herramientas de análisis de sistemas.
 Técnicas de relevamiento.
 Identificación, especificación y validación de requerimientos.
 Patrones de Análisis.
 Estudio de Prefactibilidad.
 Modelado de Negocios.
 Documentación Pertinente.
Requisitos para regularizar la asignatura

Los requisitos para regularizar la asignatura son los siguientes:
 Aprobar los Trabajos Prácticos, al menos en un 90 por ciento.
 Aprobar dos (2) parciales de contenido teórico-práctico con nota de 4 (cuatro) o superior, con
posibilidad de recuperar cada examen parcial.
 Aprobar el Proyecto Integrador Anual.
 Tener el porcentaje de asistencia a clases definido por la UTN-FRT.
Trabajos Prácticos
La Guía de Trabajos Prácticos se compone por Ejercicios Conceptuales y Situaciones Problemáticas a
resolver y Casos de Estudio.
Ejercicios Conceptuales – Ejercicios de Autoevaluación – Situaciones problemáticas
Para fomentar la lecto-escritura de los estudiantes, los ejercicios conceptuales, ejercicios de
autoevaluación y las situaciones problemáticas, se resolverán en clase con escritura manual, con letra
clara, prestando atención a la redacción y a los errores de ortografía.
3
Casos de Estudio
Los Casos de Estudio correspondientes a cada Trabajo Práctico son casos con problemas de Ingeniería
en Sistemas de Información. Deberán presentarse impresos en una carpeta, siendo realizados
utilizando las herramientas CASE adecuadas. Los Casos de Estudios serán evaluados por los
profesores de la práctica.
Contenido de la carpeta de Trabajos Prácticos
 Carátula con detalle de integrantes y trabajo presentado.
 Enunciado del Trabajo Practico.
 Desarrollo del Caso de Estudio.
 Hoja final para evaluación del docente del Caso de Estudio.
 Resolución de los ejercicios conceptuales y de las situaciones problemáticas.
Parciales
El Parcial I se realizará en el mes de Junio y el Parcial II en el mes de Noviembre. Cada parcial tendrá su
instancia de recuperación, una por cada examen parcial, abordando los contenidos correspondientes a
cada uno. Los criterios de corrección de los parciales serán los siguientes:
 Cada parcial tendrá una parte teórica y una parte práctica, cada una con un peso en la
calificación final equivalente al 50 por ciento del total.
 Los parciales son escritos e individuales.
 El contenido de los parciales es incremental. Esto significa que las temáticas se van
relacionando una con otras, completándose a medida que el estudiante adquiere más
conocimiento, es decir que los contenidos de un parcial son inevitablemente re-evaluados en
el otro.
Recuperaciones de Parciales
La recuperación del primer parcial se realizará en el mes de Agosto. La recuperación del segundo
parcial será en el mes de Noviembre.
Además, los parciales tendrán 2 (dos) recuperaciones Integrales (Teoría y Práctica) en febrero del
2016.
Para tener derecho a las recuperaciones integrales (en el mes de Febrero), se debe aprobar el Proyecto
Integrador de la materia.
Proyecto Integrador
 El Proyecto Integrador se desarrollará en grupo, compuesto por 3 a 5 integrantes.
 El avance sobre el Proyecto se hace en base a guías de actividades y tareas que los integrantes
del cada grupo deben realizar utilizando técnicas de desarrollo en iteraciones y modelado en
UML.
 En las guías se detallan las fechas de entregas y los objetivos a cumplir por parte de los
estudiantes.
 El proyecto se presentará en formato impreso y digital.
 Cada grupo deberá defender mediante una exposición oral el Proyecto Integrador. Para la
defensa oral se requiere que todos los integrantes del grupo estén presentes.
4
Examen Final
 Para rendir el examen final el estudiante deberá estar regular en la materia y haber cumplido
las exigencias del plan.
 El día del examen final el estudiante deberá presentar la Carpeta de Trabajos Prácticos
(completa y aprobada por el docente) y la libreta universitaria.
 La modalidad del examen final podrá ser oral o escrita, y el mismo consiste en un conjunto de
preguntas teórico-prácticas.
 El estudiante que se presenta para realizar el examen final no podrá retirarse con “Ausente”
en la planilla de examen.
 El programa de contenidos que se dicten para cada año tendrá vigencia para los exámenes
finales que se rindan durante los dos años siguientes a de la cursada. Para rendir en mesas
posteriores, los estudiantes deberán ajustarse al programa de contenido actualizado.
5
Programa Analítico
Programa Analítico
UNIDAD 1: LOS SISTEMAS DE INFORMACIÓN
Revisión de conceptos sobre Sistemas y Organizaciones. Revisión de la Teoría General de Sistemas.
Rol profesional del Ingeniero en Sistemas de Información y del Analista de Sistemas. Técnicas para la
recolección inicial de información.
UNIDAD 2: EL CICLO DE VIDA DE LOS SISTEMAS DE INFORMACIÓN Y SISTEMAS DE SOFTWARE

Ciclo de vida de los Sistemas de Información. Proceso de desarrollo de los Sistemas. Metodologías:
estructurada y orientada a objetos. Componentes del Sistema de Información. Modelos de procesos
de desarrollo del software.
UNIDAD 3: MARCO DE DESARROLLO – PROCESO UNIFICADO

Concepto sobre el marco de desarrollo: Fases, Disciplinas, Artefactos. Actividades iniciales del
proyecto de sistemas. La actividad Análisis de Sistemas.
UNIDAD 4: MODELOS Y HERRAMIENTAS PARA EL MODELADO

Modelos: definición. Importancia de modelar. Principios del modelado. Lenguaje para el modelado.
Herramientas CASE.
UNIDAD 5: EL MODELADO DEL DOMINIO DEL PROBLEMA

Modelo del dominio del problema: vista dinámica, vista estática. Problemas de información en el
dominio. Documentar la información del dominio del problema.
UNIDAD 6: INGENIERÍA DE REQUERIMIENTOS

Ingeniería de los Requerimientos. Requerimientos. Tipos de Requerimientos. Niveles para describir los
Requerimientos. Estándar IEEE 830. Introducción a la gestión de proyectos. Estudio de pre-
factibilidad. Estudio de viabilidad.
UNIDAD 7: OBTENCIÓN Y ANÁLISIS DE LOS REQUERIMIENTOS

Descubrimiento de los requerimientos. Técnicas para descubrir requerimientos: entrevistas,
cuestionarios, etnografía. Información del dominio para descubrir requerimientos. Clasificación y
organización de los requerimientos. Prototipos iniciales para descubrir y validar los requerimientos.
UNIDAD 8: EL ANÁLISIS ORIENTADO A OBJETOS

Análisis Orientado a Objetos. Conceptos del paradigma orientado a objetos. Patrones del Análisis.
Modelo del dominio. Casos de Uso: Diagrama y especificación de Casos de Uso. Diagrama de
secuencia. Diagrama de transición de estados. Modelo del análisis (diagrama de colaboración del
análisis)
UNIDAD 9: VALIDACIÓN DE LOS REQUERIMIENTOS

Validar los requisitos: Concepto de validación. Prototipos: componentes que facilitan la interacción
hombre-máquina. Prototipos de interfaz de usuario. Herramientas CASE para la creación de
prototipos iniciales. Revisiones de los requerimientos.
6
Programa Analítico
Guía de Trabajos
Prácticos
7
Repaso de Sistemas y Organizaciones
0 Repaso de Sistemas y Organizaciones

Preguntas de repaso
a. Explique los conceptos de Dato e Información. Ejemplifique cada uno de ellos.
b. ¿Qué es un Sistema? ¿Qué son los Subsistemas? – Ejemplifique.
c. ¿Cómo se puede identificar a los Subsistemas pertenecientes a un Sistema?
d. Defina Sistema de Información Automatizado, desde el punto de vista técnico y desde el
punto de vista de las organizaciones.
e. Clasifique los Sistemas de Información desde el punto de vista de las organizaciones.
f. ¿Cómo se interrelacionan los Sistemas de Información, según la clasificación realizada en el
punto anterior? Grafique.
g. Para el siguiente gráfico complete el significado de las funciones de un Sistema de Información
automatizado:
 Entrada
 Proceso
 Salida
 Retroalimentación
h. Diagrama de Gantt. Ejemplifique para el proyecto: Aprobar Análisis de Sistemas en Diciembre

2016, basándose en la información de la materia contenida en esta guía.
8
Repaso de Sistemas y Organizaciones
Organizaciones y Sistemas de Información

La farmacia “Melnik S.A.” está planeando la inauguración de una sucursal en una zona residencial de la
ciudad y debe instalar la misma con carácter urgente debido a que la competencia pretende abrir un
local en la misma zona. El plazo máximo establecido para la inauguración de la nueva farmacia es de
dos meses.
La organización planea implementar un Sistema de Información automatizado. Los analistas de

sistemas realizaron las entrevistas iniciales y obtuvieron la siguiente información:
 La estructura formal de la organización:

o Gerente General, del que dependerán dos áreas:
 Ventas: dividida en tres sectores: Mostrador de perfumería, Mostrador de
medicamentos y Depósito. Este último está organizado con una sección de
Reposición y otra de Expedición.
 Administración se divide en las secciones de Contabilidad y Personal.
 El nuevo Sistema de Información deberá realizar las siguientes funciones:
o Gestión de ventas para los medicamentos, drogas, psicofármacos y productos de
perfumería cosmética.
o Control de inventario: cuando el nivel de inventario de medicamentos, drogas o
psicofármacos llegue a un límite establecido, el Sistema deberá pedir la reposición del
stock por correo electrónico a la droguería de origen.
o Control de caja. Esto incluye efectivo, crédito por tarjetas, descuentos a mutuales y
obras sociales.
o Información de la deuda con proveedores y droguerías a partir de los pedidos
efectuados.
Se pide:
a. Escriba las necesidades de los dueños de la farmacia que motivan el desarrollo del Sistema de
Información automatizado (al menos 3).
b. Organigrama de la empresa.
c. Debate grupal para establecer los Recursos (humanos, materiales e inmateriales) del Sistema.
d. Para el Sistema de Información Automatizado:
i. Identifique con un nombre al Sistema de Información
ii. Identifique los subsistemas y la relación entre ellos, indicando entradas, procesos y
salidas (del sistema en general y de cada subsistema).
iii. Para cada subsistema identificado en el punto anterior, ¿A qué áreas de la
organización beneficia? ¿En qué áreas se encuentran los usuarios del subsistema?
9
Trabajo Práctico N 1
1 Trabajo Práctico N°1

Los Sistemas de Información y el rol del Analista de Sistemas
Ejercicio N°1
a. ¿Qué actividades realiza el profesional de sistemas en su rol de Analista de Sistemas?
b. ¿Qué es una entrevista para recopilar información?
c. Realice una lista de preguntas que realizaría en una entrevista inicial para conocer la
organización y sus necesidades.
d. ¿En qué situaciones conviene utilizar una estructura de rombo para la entrevista?
e. ¿En qué situaciones aplicaría un cuestionario?
Ejercicio N°2
a. Una mediana empresa manufacturera recién comienza a utilizar Internet para solicitar las
materias primas a sus proveedores y ofrecer sus productos y dar soporte a los clientes. Esta
empresa quiere organizar el Departamento Sistemas de Información. Se pide:
i. Realice el organigrama del Departamento Sistemas
ii. Describa los roles y sus funciones
iii. ¿Qué habilidades debería tener el analista de sistemas?
iv. ¿Qué características debería tener el director del área de sistemas o C.I.O. (Chief
Information Officer) de la empresa?
Bibliografía
 Kendall & Kendall. Análisis y Diseño de Sistemas. Prentice Hall. 8va. Ed.
o Capítulo 1: Sistemas, roles y metodologías de desarrollo
o Capítulo 2: Comprensión y modelado de los sistemas organizacionales
o Capítulo 4: Recopilación de la información: Métodos interactivos
 Sommerville Ian. Ingeniería del Software. Prentice Hall. 7ta. Ed.
o Capítulo 1: Introducción
o Capítulo 2: Sistemas Socio-Técnicos
10
Caso de estudio: Entrevista inicial para recopilar información

Como parte de su proyecto de análisis de sistemas para actualizar las funciones del sistema
automatizado de gestión de ventas, que pertenece a la empresa Farmacia Melnik S.A. (presentada en
el Trabajo Práctico 0), usted entrevistará al jefe del área Ventas.
Se pide:
a. Redacte cinco objetivos de la entrevista que incluyan las fuentes de información, los
formatos de información, la frecuencia con que toma decisiones, las cualidades que desea de
la información.
b. El jefe de Ventas tiene cuatro subordinados que también usan el sistema. ¿También los
entrevistaría? ¿Por qué sí o por qué no?
c. Redacte cinco preguntas abiertas que mandará por correo electrónico al jefe de ventas antes
de la entrevista.
d. Explique por qué es preferible realizar una entrevista en persona en lugar de vía el correo
electrónico.
Recuerde:
Una entrevista para recabar información es una conversación dirigida con un propósito específico que
utiliza un formato de preguntas y respuestas. En la entrevista necesitamos obtener información sobre:
 Las opiniones de los entrevistados y su parecer acerca del estado actual del sistema
 La misión, visión, las metas organizacionales y personales
 Los procedimientos informales
 Los procedimientos formales
Fuente: Adaptado de Kendall & Kendall. Análisis y Diseño de Sistemas. Prentice Hall. 8va. Ed.
11
Para leer y recordar…

Los Sistemas de Información basados en computadoras deben aplicarse de manera inteligente y
cuidadosa con el propósito de que tanto la sociedad como las empresas y las industrias puedan
aprovechar sus beneficios.
Las tecnologías representan la Infraestructura Tecnológica de Información - abreviado es TI - y es

el entorno tecnológico o plataforma sobre la cual una empresa puede construir sus sistemas de
información específicos.
Las tecnologías de entrada son dispositivos de hardware y software que permiten a los usuarios
interactuar con un Sistema de Información. Esos dispositivos se utilizan para alimentar de datos e
información a los dispositivos de cómputo.
Las tecnologías de procesamiento y memoria son los componentes responsables del

procesamiento y están formados por la CPU y la memoria RAM.
Las tecnologías de almacenamiento representan el almacenamiento secundario de los datos y la

información. También se las denomina tecnologías de almacenamiento permanente. Los
componentes más comunes son los discos magnéticos, memorias USB y DVD, entre otros.
Las tecnologías de salida son dispositivos que entregan los resultados del proceso. Estas
tecnologías proporcionan la información correcta en tiempo y forma. La salida puede ser audible,
visual, digital o impresa.
Las tecnologías de distribución consisten de medios de comunicaciones, dispositivos y software

necesario para conectar dos o más dispositivos formando una red. Las computadoras y dispositivos
conectados se llaman nodos de la red y pueden compartir datos, información y tareas de
procesamiento.
12

El Ciclo de vida de los Sistemas de Información y Sistemas de Software
Ejercicio N°1
a. Describa brevemente los componentes de un Sistema de Información. Los componentes se
muestran en la figura 1.
Software Hardware Redes Documentación
Personas Procesos Comunicaciones Datos
Figura 1. Componentes de los Sistemas de Información Automatizados
Ejercicio N°2
a. Explique el concepto de Ciclo de vida para un Sistema de Información - Grafique
b. Indique la opción correcta. Las fases del proceso de desarrollo de la Ingeniería en Sistemas, en
orden secuencial son:
 Desarrollo de los subsistemas, Integración del sistema, Instalación del sistema, Evolución
del sistema, Desmantelamiento del sistema
 Definir los requerimientos, Desarrollo del sistema, Evolución del sistema
 Definir los requerimientos, Diseño del sistema, Desarrollo de los subsistemas, Integración
del sistema, Instalación del sistema, Evolución del sistema, Desmantelamiento del
sistema
c. Describa cada una de las fases del proceso de desarrollo de la Ingeniería en Sistemas.
d. Explique las actividades de la Fase Análisis de Sistemas.
Ejercicio N°3
a. ¿Qué es un modelo de proceso de software?
b. ¿Cuáles son las actividades comunes en los procesos de desarrollo del software?
c. ¿Cuáles son las diferencias entre iteración e incremento?
d. ¿Qué desventajas tiene el modelo en cascada?
e. ¿Qué diferencia tiene el modelo en espiral presentado en la figura 2, con otros modelos de
proceso?
13
Figura 2. Modelo en espiral para el proceso de software [Fuente: Sommerville Ian, Ingeniería del Software]
Ejercicio N°4
El desmantelamiento del sistema es la última fase del proceso de la ingeniería en sistemas. Durante
esa fase se pone fuera de servicio al sistema después de que termina su periodo de utilidad operativa.
Para sistemas hardware esto puede implicar el desmontaje y reciclaje de materiales o el tratamiento
de sustancias tóxicas.
¿De qué manera los Sistemas de Información afectan al ambiente? ¿Qué se puede hacer con los
componentes del Sistema de Información para minimizar el impacto ambiental? ¿Qué entiende por
Green IT (Tecnologías de la Información sustentables)?
Desarrollar una investigación bibliográfica al respecto y elaborar un informe breve (1 carilla de hoja A4)
sobre el tema.
Ejercicio N° 5
SisInund es un sistema de detección de inundaciones * para monitorear y alertar sobre la
posibilidad de las mismas en lugares que se ven amenazados por éstas. El sistema incluye un conjunto
de sensores para detectar cambios en los niveles de los ríos y mares, vínculos a un sistema de servicio
meteorológico que proporciona la previsión del tiempo, vínculos a los sistemas de comunicación de los
servicios de emergencia (policía, gendarmería, etc.). Además el sistema SisInund dispone de un
conjunto de monitores de video instalados en lugares específicos y un cuarto de control equipado con
consolas de operación y monitores de videos.
El sistema guarda (almacena) la información de los sensores, la ubicación de los sitios en riesgo y las
condiciones de amenaza para estos sitios (nivel alto de agua en los ríos, mareas altas, vientos del
sudoeste, etc.), tablas de las mareas para los sitios costeros, el inventario y localización del equipo de
14
control de inundaciones, detalles de los contactos de los servicios de emergencia, estaciones locales
de radio, etc.
Los empleados de la sala de control pueden realizar consultas de la información almacenada en el

sistema. El sistema también avisa mediante alertas sobre una posible inundación.
Se pide:
a. Clasifique la tecnología usada en el sistema, e incluya la que Ud. considere conveniente

para el óptimo funcionamiento del sistema.
Tecnologías Descripción
Tecnologías de entrada
Tecnologías de procesamiento
Tecnologías de salida
b. Modelar la arquitectura conceptual del sistema mediante un diagrama de bloques que

represente los subsistemas y la interrelación entre ellos.
* Fuente: Adaptado de Sommerville Ian. Ingeniería del Software. Prentice Hall. 7ta. Ed.
Bibliografía
o Capítulo 1: Sistemas, roles y metodologías de desarrollo
Sección: El ciclo de vida del desarrollo de sistemas
o Capítulo 4: Procesos del Software
15
Caso de Estudio: Selección de modelos de proceso

Sugiera el modelo de proceso de desarrollo genérico que podría utilizarse para gestionar el
desarrollo de los siguientes sistemas:
1. Un sistema de control antibloqueo de frenos de un automóvil. Las necesidades del cliente

se conocen y éstas tienen baja probabilidad de cambios.
2. Un sistema de realidad virtual para ayudar a los estudiantes a desarrollar habilidades de
comunicación. Las personas que realizarán el sistema y los clientes no tienen experiencia
previa en el desarrollo de sistemas de realidad virtual.
3. Un sistema de gestión de préstamos de libros universitarios que reemplace al existente.
Las personas que desarrollarán en sistema trabajan en equipos dispersos y existen riesgos
que pueden originar problemas en el proyecto.
4. Un sistema interactivo que permita a los pasajeros encontrar los horarios de los colectivos
de larga distancia a partir de terminales de autoconsulta. El cliente que nos solicitó el
sistema está comprometido a participar y a formar parte de nuestro equipo de desarrollo.
Se pide:
a. Justifique la selección del modelo de proceso de desarrollo genérico, según el tipo de
sistema a desarrollar y de las características de cada modelo.
b. Escriba las ventajas y desventajas de los modelos de proceso seleccionados en el apartado
a.
c. Grafique cada uno de los modelos elegidos.
d. Suponga que Ud. debe desarrollar un sistema para la Gestión de préstamos de libros de
una biblioteca.
Las actividades que deberá realizar para desarrollar el sistema, según el proceso de
ingeniería en sistemas son: Definir los requerimientos, Diseño del sistema, Desarrollo de
los subsistemas, Integración del sistema, Instalación del sistema, Evolución del sistema,
Desmantelamiento del sistema. Se pide:
Realice el Diagrama de Gantt con las actividades del proceso de ingeniería en sistema.
Fuente: Adaptado de Sommerville Ian. Ingeniería del Software. Prentice Hall. 7ta. Ed.
16
Caso de Estudio: Arquitectura conceptual del Sistema de

Información
Una Universidad de gestión privada pretende instalar un conjunto de Puntos de Información
Universitaria (PIU) a través de los cuales se pueda facilitar información a la comunidad universitaria.
El sistema de información deberá vincular a las Áreas:
 Académica: en la que los estudiantes podrán acceder a través de un usuario y contraseña a su

estado académico.
 Administrativa-Contable: en la que se registra el estado de cuenta del Estudiante y su
habilitación para la inscripción del siguiente año. También se pueden emitir una constancia de
libre deuda.
 Sección Alumnos: donde se consulta sobre la documentación necesaria para los diferentes
trámites.
Se pide:
a. Describa brevemente las tecnologías más adecuadas a fin de satisfacer las necesidades de
la Universidad.
b. Elabore un diagrama de bloques, como la arquitectura conceptual del sistema, en el que
se observen las entradas, procesos y salidas de los diferentes subsistemas.
17
Para leer y recordar…

La elección de un ciclo de vida no es una tarea sencilla. Para facilitar nuestro trabajo, los ingenieros en
sistemas disponemos de preguntas organizadas en una lista. Estas listas se consideran buenas
prácticas que nos ayudan a decidir de manera razonable y justificada el ciclo de vida más conveniente
para el problema a solucionar. La lista de preguntas también se conoce como lista de verificación.
Las respuestas a las preguntas pueden ser: Si, No, No se sabe o una descripción breve. Las respuestas
no son correctas o erróneas, solamente tienen como objetivo enfocar las propuestas del equipo de
trabajo y guiar los distintos factores a considerar.
Las respuestas junto con las características de cada modelo de proceso nos permitirán elegir el ciclo de
vida.
La cantidad de preguntas no está cerrada, mientras estudiamos y ganamos más experiencia podemos
agregar otras preguntas.
 Ejemplo de Lista de verificación o Checklist
Pregunta Respuesta
¿Tiene un nombre el sistema?
¿Conocemos quiénes usarán el sistema?
¿El cliente está dispuesto a participar en el desarrollo del
sistema?
¿Qué tipo de sistema nos solicitan?
¿Conocemos los objetivos del sistema?
¿Es necesaria la documentación de cada fase o etapa de
desarrollo?
¿El cliente solicitará cambios en el sistema?
¿Conocemos todos los requisitos?
¿El sistema utilizará nuevas tecnologías?
¿Se necesita el desarrollo de prototipos?
¿Es necesario el estudio de riesgos?
¿Son necesarias las iteraciones?
¿Se realizarán entregas incrementales?
¿Las personas que realizarán el sistema tienen experiencia
anterior?
¿Qué tamaño tiene nuestro sistema? Según la cantidad de
personas que realizarán el sistema:
 Chico 1 o 2 personas
 Mediano 3 a 10 personas
 Grande más de 10 personas
18

Marco de desarrollo – Proceso Unificado
Ejercicio N°1
a. La figura 3 muestra el modelo del Proceso Unificado Rational (RUP), es un modelo en fases y
con disciplinas o flujos de trabajo. Se pide completar en la figura la perspectiva dinámica y de
la perspectiva estática del modelo.
Figura 3. Fases y disciplinas para el proceso Unificado Rational [Fuente:Booch, Jacobson, Rumbaugh. El proceso
Unificado de Desarrollo]
Ejercicio N°2
a. Un sistema se puede representar por un conjunto de artefactos. Un artefacto es un
documento o información creada o producida por los trabajadores en el desarrollo del
sistema.
Los artefactos pueden ser: artefactos de ingeniería y artefactos de gestión.
Los artefactos de ingeniería incluyen el código fuente que se puede compilar y ejecutar y los
modelos visuales modelados con el Lenguaje Unificado de Desarrollo, por ejemplo Modelo de
Casos de Uso, Modelo del Dominio, Diagrama de actividades, Diagrama de Estados, etc.
Ejemplos de artefactos de gestión son el documento Visión y Análisis del Negocio,
Especificación complementaria, el plan de desarrollo y especificaciones del entorno de
desarrollo, etc.
Se pide completar la tabla 1 con los artefactos técnicos y de ingeniería que podrían crearse
en la Fase Inicio del Proceso Unificado
19
Tabla 1. Ejemplo de artefactos de la fase inicio [Fuente: Larman C., UML y Patrones]
Ejercicio N°3
a. Realice un cuadro con las fases y disciplinas del artefacto: Marco de Desarrollo.
b. ¿Cuántas de las fases representadas en el Marco de Desarrollo se trabajarán en la Materia
Análisis de Sistemas? Explique
c. ¿Se puede realizar un estudio de sistemas sin incluir el Marco de Desarrollo?
Ejercicio N°4
a. La tabla 2 muestra una parte de las tareas que el líder de proyectos ha planificado para guiar
el desarrollo durante la Fase Inicio. Se pide realizar un Diagrama de Gantt que muestre el
calendario.
20
Tabla 2. Principales tareas de la Fase Inicio [Adaptado de: Larman C., UML y Patrones]
Bibliografía
 Larman C. UML y Patrones, 2da. Ed.
o Capítulo 2: Desarrollo iterativo y el Proceso Unificado
o Capítulo 4: Inicio
 Sitio WEB para consultar la estructura de la metodología RUP
http://sce.uhcl.edu/helm/rationalunifiedprocess/
21

Modelos y herramientas para el modelado
Ejercicio N°1
a. Nombre las actividades del ciclo de vida del sistema que se pueden automatizar con
herramientas CASE.
b. ¿Qué es UML? Investigue su historia e evolución.
c. ¿Qué importancia tiene el modelado en la Ingeniería en Sistemas de Información?
d. Nombre los diagramas y los elementos que modelan la vista estática del sistema y los que
modelan la vista dinámica del sistema, según UML.
Ejercicio N°2
a. Describa cada uno de los elementos del Diagrama de Actividades que se muestran en la figura
4.
b. ¿Por qué utilizamos el Diagrama de Actividades y no un Diagrama de Flujo?
Figura 4. Elementos más comúnmente utilizados del Diagrama de Actividades
22
Ejercicio N°3
Para el Diagrama de Actividades que se muestra en la figura 5, se pide:
i. Escriba la descripción del proceso que negocio que modela el diagrama [el
proceso que modela el diagrama es un proceso de negocio manual].
ii. Complete en el diagrama el flujo de objetos con el objeto de datos: préstamo y
lista de socios.
iii. Identifique en el diagrama, los elementos usados para modelar el proceso de
negocio.
Figura 5. Diagrama de Actividades para el proceso manual de préstamo de libros de una biblioteca
23
Ejercicio N°4
Describa cada uno de los elementos del Diagrama de Transición de Estados que se muestran en la
figura 6.
Figura 6. Elementos del Diagrama de Transición de Estados
Ejercicio N°5
El Diagrama de Transición de Estados de la figura 7 muestra el funcionamiento de un semáforo
ubicado en la intersección de una calle peatonal. El semáforo se enciende por primera vez en luz
verde. Un temporizador controla el tiempo entre las transiciones. De la luz verde a la luz roja debe
pasar 30 segundos, de la luz amarilla a la luz roja pasan 3 segundos y de la luz roja a la luz verde debe
pasar 30 segundos.
¿Cómo modificaría el diagrama para pasar brevemente por la luz amarilla entre de la luz roja y la luz
verde?
Figura 7. Diagrama de Transición de Estados para el funcionamiento de un semáforo
24
Ejercicio N°6
Un sistema de contestador de teléfono almacena mensajes entrantes y permite visualizar el número
de mensajes aceptados mediante LEDs.
El sistema del contestador permite al propietario del teléfono realizar llamadas desde cualquier lugar
al contestador para escuchar los mensajes que tiene guardados en el contestador, para ello el
propietario del teléfono debe ingresar una secuencia finita de números (clave) y reproducir los
mensajes almacenados.
Se pide:
a. Realizar el Diagrama de Transición de Estados, correspondiente al contestador automático.
Fuente: Adaptado de Sommerville Ian. Ingeniería del Software. Prentice Hall. 7ta. Ed.
Bibliografía
 Booch G., Rumbaugh J., Jacobson I. El Lenguaje Unificado de Modelado. Pearson Addison
Wesley, 2da. Ed.
o Capítulo 1: Por qué modelamos
o Capítulo 2: Presentación del UML
o Capítulo 7: Diagramas
o Capítulo 20: Diagrama de Actividades
o Capítulo 22: Máquinas de Estado
 Herramientas Case para el modelado con UML
o argoUML (http://argouml.uptodown.com
25
Caso de Estudio: Diagrama de Actividades –Diagrama de

Estados
La siguiente descripción pertenece al sistema de Gestión de Préstamos y Devoluciones de Libros de la
biblioteca de una facultad. El sistema está automatizado e interactúa con otros dos sistemas: el
sistema de alumnos y el sistema de la biblioteca central de la universidad. Las figuras 8 y 9 muestran
una porción de las ventanas como prototipos de interfaz de usuario, las cuales nos ayudan a clarificar
la descripción del sistema.
Los datos de los socios [legajo, apellido y nombre, carrera que cursa] se obtienen desde el sistema de
alumnos. La información de los libros [nombre del libro, autores, edición] se obtiene del sistema de la
biblioteca central. Los Socios solicitan al Bibliotecario el préstamo de hasta 3 ejemplares de distintos
libros. Si el socio está moroso el sistema no permite realizar el préstamo. Los préstamos se realizan
por 7 días.
Cuando el socio devuelve los libros el Bibliotecario busca la información del Socio y los préstamos que
están pendientes de devolución. En caso de haber un retraso en la devolución, se impone una multa al
socio. El valor de la multa puede cambiar y depende del período del año.
La política establecida para las multas es $10,00 por cada ejemplar. El importe de la multa cambia en
el período de exámenes finales y es de es de $20 por cada ejemplar. Si el Socio devuelve el libro
después de las vacaciones, el importe de la multa es de $40. El socio puede realizar devoluciones
parciales, es decir que le pueden quedar libros pendientes a devolver.
Cuando el socio devuelve el libro el Bibliotecario registra la información de la devolución y el sistema

modifica el estado del ejemplar de “Prestado” a “Devuelto”.
El Jefe de la Biblioteca necesita reportes mensuales para el control de inventario de los libros, para
analizar las devoluciones según los días de retraso y las multas de los socios.
Se pide:
a. Realizar el Diagrama de Actividades del proceso usando UML.
26
Figura 8. Ventana para la devolución de libros del sistema Gestión de Préstamos y Devoluciones de Libros
Figura 9. Ventana para el préstamo de libros del sistema Gestión de Préstamos y Devoluciones de Libros
27
Diagrama de Transición de Estados

En la implementación de un sistema operativo basado en UNIX, cada proceso tiene asociado un
número identificador (PID), un estado, y un conjunto de cero a muchos procesos hijos.
Al momento de la creación de un proceso, se le asigna un estado inicial de "Creado". Este estado

representa que el proceso fue recientemente creado y no está listo para ejecutar. Luego de realizarse
las rutinas de preparación, se verifica la memoria principal del sistema. Si hay memoria suficiente, el
proceso pasa a un estado de "Ready (in-core)", en el cual el proceso se encuentra listo para ejecutar en
cuanto el planificador lo disponga. Si no hay memoria suficiente, se almacena la imagen del proceso
en memoria secundaria, y el proceso pasa a un estado de "Ready (swapped)". En este estado, el
proceso se encuentra listo para ejecutar, pero primero se lo deberá llevar a memoria principal para que
el planificador pueda planificar su ejecución (al pasar a memoria principal, el proceso cambiará su
estado a "Ready (in-core)")1.
El planificador elige, según un esquema de planificación determinado, un proceso en estado "Ready

(in-core)" para asignarlo al procesador y que empiece la ejecución del código del proceso. Cuando esto
sucede, el proceso cambia a un estado de "Running". Cuando el planificador desea asignar otro
proceso al procesador, cambia el estado del proceso en ejecución a "Ready (in-core)".
Cuando un proceso finaliza su ejecución (debe encontrarse en estado "Running"), pasa a un estado de
"Zombie", el cual significa que el proceso no existe más, pero deja un registro para que su proceso
padre recolecte estadísticas2.
Se pide:
a. Realizar el Diagrama de Transición de Estados usando UML.
1 En los sistemas basados en UNIX, este pasaje de memoria secundaria a memoria principal es realizado por
el "swapper".
2
Por simplicidad se ignoran los estados de suspendido o "Sleeping" de los procesos, y los procesos de
"swapping" bidireccionales.
28

El Modelado del dominio del problema
Ejercicio N°1
a. El valor de la información se vincula directamente con la forma en que la información apoya a
las personas que toman decisiones, con el propósito de cumplir objetivos organizacionales o
de cualquier otro dominio de aplicación. Por lo tanto la información debe tener ciertas
características para que sea de utilidad. Describa 5 características de calidad de la
información.
b. Ejemplifique cinco problemas de información que se pueden encontrar en los procesos de
negocio.
Ejercicio N°2
a. En UML se utiliza el siguiente símbolo para representar conceptos del dominio de interés.
Indique qué se representa en cada parte del símbolo.
b. Explique para qué se utiliza el Modelo del Dominio.
Ejercicio N°3
a. ¿Cómo se denomina el artefacto para especificar las reglas del proceso de negocio?
b. ¿Cuál es el nombre del artefacto que además de definir el alcance y los objetivos de alto nivel
de un sistema contiene una declaración clara del problema?
Ejercicio N°4
a. En el Área de Servicio de una Concesionaria de Autos se confecciona una Orden de
Reparación. La orden contiene datos del Vehículo, datos del propietario y la información de
los problemas que posee el automotor. Complete la estructura de la información.
b. El siguiente es un ejemplo de regla de negocios de una Empresa dedicada a venta de
Repuestos para Automotores, agregue por lo menos tres reglas.
Id Regla Grado de variación origen

Los días jueves se aplica
01 un descuento del 10% a Alta Reglas del proceso de
todos los artículos ventas
29
Ejercicio N°5
Se desea desarrollar un Sistema de Información para automatizar las ventas en un supermercado que
tiene 3 cajas para cobrar. El sistema incluye componentes de hardware, como computadoras y lectores
de códigos de barras, y software de base para ejecutar el sistema. Se dispone de la siguiente
descripción de los requerimientos del usuario:
Los clientes llegan a la caja con los artículos para comprar. El Cajero escanea el código de los artículos,
o en algunos casos lo teclea manualmente. Si el Cliente compra más de un artículo del mismo tipo, el
Cajero ingresa la cantidad de artículos (por ejemplo, si se quieren comprar 5 aceites (iguales), el Cajero
ingresa el código del aceite una sola vez y luego la cantidad). El Sistema presenta la suma parcial y
detalles de cada línea de venta. Al finalizar el registro de los artículos de la venta, el Cajero introduce
los datos del pago, que el Sistema valida y registra. Solo se consideran pagos en efectivo. El Sistema
actualiza el inventario y registra la venta en el libro mayor de ventas. El Cliente recibe un recibo del
Sistema y luego se va con los artículos.
Los datos de los artículos son: código, descripción, stock. Se debe poder conocer el subtotal, total y la
fecha de las ventas registradas y del pago la cantidad de dinero recibido.
Se pide:
a. Realizar el Modelo del Dominio.
b. Justifique el Modelo del Dominio realizado en el apartado a, mediante el uso de una lista de
categorías, frases nominales y de la conservación de asociaciones necesito-conocer.
c. Para el documento Visión, desarrolle la sección Visión general del producto.
d. Para el documento Especificación Complementaria, desarrolle la sección Información del
dominio de interés.
Fuente: Adaptado de Larman C. UML y Patrones. Pearson Prentice Hall. 2da. Ed.
Bibliografía
o Capítulo 7: Identificación de otros requisitos [sección 7.2 y 7.4]
o Capítulo 10: Modelo del Dominio: Visualización de Conceptos
o Capítulo 11: Modelo del Dominio: Añadir Asociaciones
o Capítulo 12: Modelo del Dominio: Añadir Atributos
 Booch G. Análisis y Diseño Orientado a Objetos
o Capítulo 2: El Modelo de Objetos
 OMG Std. Plantilla para la Especificación Complementaria [Disponible en el Aula Virtual de la
materia]
 OMG Std. Plantilla del Documento Visión [Disponible en el Aula Virtual de la materia]
30
Caso de Estudio: Modelo del dominio

Se desea modelar una imitación del juego Pac-Man. El juego está constituido por una serie de niveles
en donde participan 5 personajes: Pac-Man y 4 Fantasmas de diferente color. Ver figura 10.
El escenario del juego es un laberinto, en donde hay ubicados puntos pequeños, llamados Pac-dots, y
4 puntos grandes, llamados Power Pellets. En el centro del laberinto hay un lugar llamado base. Pac-
Man y los Fantasmas recorren el laberinto, siendo Pac-Man controlado por el usuario. Al inicio del
juego, el jugador tiene 3 vidas.
Figura 10: Prototipo de la pantalla del juego
Cuando un fantasma colisiona con Pac-Man; si las vidas restantes son mayores a cero, entonces se
decrementan en 1 y se reinicia el nivel actual. Caso contrario, se termina el juego.
Cuando Pac-Man se come una Power Pellet, le proporciona la habilidad temporal de comerse a los
fantasmas. Cuando un fantasma es comido, retornará a la base para revivir. Luego de un cierto
intervalo de tiempo transcurrido desde que Pac-Man se comió la Power Pellet, esta pierde su efecto, y
los fantasmas dejan de ser vulnerables.
Si Pac-Man come otra Power Pellet antes de que se termine el efecto de la Power Pellet anterior, se
reinicia el intervalo de tiempo durante el que los fantasmas son vulnerables.
Cuando Pac-Man colisiona con un Pac-dot, se lo come. Esto causa que el contador de puntajes se
incremente en 1. Por cada Power Pellet comida, el contador de puntos se incrementa en 2. Cuando
Pac-Man se come el último Pac-dot, se pasa al siguiente nivel.
Cada nivel define una cierto comportamiento para los fantasmas, incluyendo su velocidad. También
varía el tiempo que duran los efectos de la Power Pellet.
Se pide:
1. Realice el Modelo del Dominio.
2. Realice un Diagrama de Transición de estados para las clases Pac-Man y Fantasma.
31
Caso de Estudio: Visión y Especificación Complementaria

Un hospital tucumano para pacientes adultos, se caracteriza por la gratuidad en la atención y la
recuperación de gastos, siendo además un referente provincial y regional como hospital-escuela.
El hospital actualmente tiene cinco áreas de servicios: Clínica Médica, Cirugía, Unidad de Terapia
Intensiva, Farmacia y Laboratorio. Cada una de las áreas tiene un Jefe de área.
Con el propósito de incorporar transparencia a los procesos de compras, el hospital tiene dos maneras
de realizar las compras:
1. Compra directa: solamente para atender situaciones de urgencia

2. Compra por licitación pública
Considerando a sus proveedores aliados estratégicos el hospital entrega anualmente premios a los
mejores proveedores que se destacan en el cumplimiento de la entrega justo a tiempo, la calidad de
sus productos y el cuidado del medio ambiente.
La Gerencia de Administración que se encarga de dirigir los procesos de adquisición y suministro de

elementos para las áreas de servicios, nos solicitó desarrollar un sistema de información para las
compras directas, con los siguientes objetivos:
 Automatizar la recepción de los productos

 Actualizar el inventario de los productos recibidos
 Controlar y verificar que los productos recibidos coincidan con el tipo y cantidad pedida
La Gerencia de Administración quiere evitar el riesgo de adquirir los insumos a proveedores no

autorizados, asegurarse que los jefes de cada área de servicio conozcan en tiempo real si la solicitud de
compra fue aprobada y disminuir el error de recibir productos que no se compraron.
El proceso de compra directa se inicia cuando la sección Compras recibe una solicitud de compras de
alguna de las áreas de servicio. A partir de la solicitud de compras, la sección Compras emite una orden
de compra aprobada, en la cual se especifica el proveedor y el detalle los productos que cada área de
servicio solicita. La sección Compras envía las órdenes de compras autorizadas a los proveedores.
Actualmente el proceso de compra directa se realiza manualmente.
La recepción de los productos se realiza en cada área de servicio, allí los proveedores entregan los
productos, la orden de compra y el remito. El empleado del área de servicio controla la trazabilidad de
los documentos y los compara para verificar que tanto la cantidad como el tipo de productos del
remito coincidan con la orden de compra autorizada. Los productos defectuosos no se reciben.
El empleado del área de servicio registra manualmente el ingreso de productos en un formulario de

entrada de productos e incrementa el inventario del producto correspondiente.
Si la cantidad de producto recibida no coincide con la cantidad pedida o su tipo o hay algún producto
faltante, el producto de la orden de pedido queda pendiente de recibir. Esta situación también se
refleja en el remito del proveedor.
32
Si los datos coinciden (cantidad y tipo) entonces el Jefe del área de servicio firma el remito y la orden
de compra y la envía a la sección Compras. De esa manera la sección Compras dispone de la
información para iniciar el proceso de pago de los proveedores.
Los proveedores que realizan entregas de productos los días lunes y/o feriados y sin faltantes o
productos defectuosos reciben su pago en efectivo.
La recepción y pago de la factura de los proveedores queda fuera del alcance del enunciado.
Se pide:
a. Escribir los problemas de información que posee actualmente el proceso de negocio de

compras directas del hospital y diga las posibles causas de esos problemas.
b. Producir parcialmente el documento Visión para el sistema Compras directas. El documento
deberá contener las siguientes secciones:
i. Propósito del documento.
ii. Descripción del problema / oportunidad.
iii. Personal involucrado en el desarrollo del sistema (No usuarios).
iv. Resumen de Usuarios.
v. Visión general del producto [Resumir las características más sobresalientes del
Sistema de Información Automatizado. Puede mostrar la organización del
sistema usando un Diagrama de Bloques].
c. Producir parcialmente el documento de Especificación Complementaria para el sistema
Compras directas. El documento deberá contener las siguientes secciones:
i. Propósito del documento.
ii. Reglas del dominio.
iii. Información del dominio de interés [Recuerde: que es muy útil proporcionar a
nuestro equipo de trabajo las descripciones o diagramas que expliquen cómo se
realizan los procesos. Las descripciones se presentan con el fin de que todos los
stakeholders puedan comprender el contexto de estudio].
Nota: para un mejor entendimiento del proceso puede realizar el diagrama de actividades, el diagrama
de transición de estados y el modelo del dominio.
33
Aprendiendo a modelar el dominio del problema

Se descompone el vocabulario del dominio del sistema en clases conceptuales y se identifica cómo
esos conceptos se relacionan entre sí para satisfacer los requisitos de información.
Lo que el sistema deberá recordar se inicia con el estudio las entidades en el contexto del sistema,
como por ejemplo un objeto o concepto libro del sistema de gestión de préstamos (figura 11). En la
tabla 3 se muestra la organización conceptual de la información la cual está separada por conceptos.
Libro Principios de Sistemas de Información
Autores Ralph Stair, George Reynolds
Editorial Cenage Learning
Edición 9 na
Figura 11. Datos que se pueden obtener de un libro
Tabla 3. Organización conceptual de la estructura de la información
Categoría Concepto Atributo Ejemplo de valor
nombre Ralph
Rol de
Autor (1)
persona
apellido Stair
Lugar Editorial (2) nombre Cenage Learning

ISBN Número Estándar Internacional de Libros
nombre Principios de Sistemas de Información

Objeto edición 9
Libro
tangible
autor (1)
editorial (2)
Si se modela las clases conceptuales con UML la estructura de la información queda representada de
la siguiente figura:
34
Figura 12. Modelo del dominio que representa la información de los libros que un sistema necesita recordar
35

Ingeniería de Requerimientos
Ejercicio N°1
a. ¿Qué importancia tiene la Ingeniería de los Requerimientos para los Ingenieros en Sistemas de
Información?
b. Grafique el modelo en espiral de los procesos de la Ingeniería de los Requerimientos
c. ¿Cuándo es conveniente utilizar el enfoque en espiral de los procesos de la Ingeniería de los
Requerimientos?
Ejercicio N°2
Para todos los sistemas nuevos, el proceso de Ingeniería de Requerimientos debería empezar con un
estudio de viabilidad. La figura 13 muestra la entrada necesaria para realizar el estudio de viabilidad,
los participantes y los resultados del estudio de viabilidad.
Se pide:
a. Complete los nombres de los roles que participan en el estudio de viabilidad.

b. Complete el nombre del informe que se obtiene al finalizar el estudio de viabilidad
c. ¿Cuáles son las cuestiones que resuelve el estudio de viabilidad?
d. Ejemplifique una lista de preguntas para entrevistar a los usuarios finales o interesados. La
entrevista tiene como objetivo completar el informe de viabilidad.
Figura 13. Primera actividad del proceso de Ingeniería de Requerimientos: el estudio de viabilidad
36
Ejercicio N°4
a. ¿Qué entiende por requerimientos del usuario y requerimientos del sistema?
b. Comente brevemente los problemas de la utilización del lenguaje natural para definir los
Requerimientos del Usuario y del Sistema.
c. Para el siguiente requisito:
El sistema deberá proporcionar visores adecuados para que el usuario lea documentos desde el
repositorio de documentos
i. Indique si es correcto o incorrecto. (Considere las características para la redacción
de los requerimientos).
ii. Justifique su respuesta explicando por qué es correcto o incorrecto, según su
elección.
iii. Si considera incorrecto redacte nuevamente el requisito.
d. ¿Qué significa que la especificación de los requerimientos de un sistema deba ser completa y
consistente?
Ejercicio N°5
a. Realice el árbol de clasificación de los Requerimientos no Funcionales.
b. Para un sistema de información de Inscripción de Alumnos ejemplifique un requisito de
inteoperabilidad, un requisito de implementación, un requisito de entrega y un requisito de
eficiencia.
Ejercicio N°6
Un taller mecánico realiza la reparación de automóviles a los clientes que habitualmente llevan sus
vehículos. Cuando un cliente llega al taller y solicita un servicio, como por ejemplo alineado y
balanceado, cambio de aceite, cambio de neumáticos, etc., el responsable de administración se fija si
hay disponibilidad y avisa el tiempo de espera. El cliente acepta o rechaza el tiempo de espera.
Cuando llega el turno, los mecánicos realizan el servicio, cargan en el sistema la Orden de trabajo con
las tareas realizadas, los insumos consumidos (nombre, cantidad, precio unitario) y los repuestos
utilizados (nombre, cantidad, precio unitario) y avisan al cliente que puede dirigirse a administración.
Ejemplo de insumos pueden ser aceite, gasoil, grasa, etc. y de repuestos pueden ser correas,
rulemanes, caños de escape, etc.
El sistema actualiza el stock de insumos y de repuestos automáticamente a través de la Orden de

trabajo. El responsable de administración revisa la Orden de trabajo y genera la factura para el cliente.
El cliente paga el servicio y se retira.
Se pide:
a. Descubra las ambigüedades y omisiones en la descripción del sistema. El Diagrama de Actividades

es una herramienta que nos ayuda a descubrir ambigüedades y omisiones.
b. Proponga una solución a los problemas planteados en el punto anterior y redacte nuevamente la
descripción del sistema.
37
c. Para la descripción del sistema, desarrolle dos requerimientos funcionales. Utilice el siguiente
formato propuesto para el estándar IEEE 830-1998.
Número de Requerimiento
Requerimiento
Prioridad
Entradas
Acción / Proceso Se especifica en lenguaje estructurado
Salidas
Bibliografía
o Capítulo 3: Administración de proyectos
Secciones: Determinación de la viabilidad
Determinación de las necesidades de hardware y software
o Capítulo 6: Requerimientos del Software
o Capítulo 7: Procesos de la Ingeniería de los Requerimientos
 IEEE Std. 29148 – 2011- Guía para escribir los requisitos [Disponible en el Aula Virtual]
 IEEE Std. 830 – 1998 – Plantilla para especificar los Requerimientos del Software [Disponible
en el Aula Virtual]
38
Caso de Estudio: Aplicación de la Ingeniería de Requerimientos

El Gerente General de un negocio dedicado al envío de comida a domicilio requirió los servicios de una
consultora en Ingeniería en Sistemas para solicitar un sistema que permita que sus clientes puedan
hacer sus pedidos desde la Web y también que la información de ventas esté permanentemente
actualizada.
El área de influencia del negocio de nuestro cliente es la ciudad de Tafí Viejo, Tucumán. Es decir que
por ahora, no podrá satisfacer pedidos de otras ciudades o localidades.
El sistema requiere de un catálogo interactivo con los platos disponibles para el menú. El usuario podrá
buscar e identificar los platos, seleccionarlos, agregarlos al pedido, aceptar el pedido e indicar el
horario de entrega. El pedido puede incluir varios tipos de platos. El cliente puede pagar el pedido en el
domicilio o con tarjeta de crédito.
La información que el sistema registra del cliente es la siguiente: apellido y nombre, mail para
contacto, número de teléfono (fijo), número de celular, dirección de envío. El sistema registra esta
información cuando el cliente solicita un pedido por primera vez.
Cada plato tiene una descripción, un precio unitario y una foto que muestra la presentación del plato.
El cliente selecciona el plato y lo agrega a su pedido El sistema calcula el total con impuestos y cargos
por envío y muestra el total a pagar.
Si el cliente acepta el pedido éste pasa del estado “Nuevo” a un estado “Aceptado” y el Cliente puede
seleccionar la forma de pago. Al momento de aceptar el pago o seleccionar pago en domicilio, el
sistema envía una notificación al área de elaboración (cocina). El jefe de cocina deriva el pedido al chef
y modifica el estado del pedido a “En proceso de elaboración”.
Cuando la cocina termina de elaborar la comida ésta se embala y el administrador del área distribución
imprime un recibo y se lo entrega al cadete que hace el reparto junto con la comida embalada. En se
momento el administrador modifica el estado del pedido a “En reparto”.
El cadete entrega al cliente la comida y el recibo. El pedido cambia de estado a “Entregado”. En caso
de pago en domicilio en cadete recibe el pago. Cuando el cadete regresa al negocio y entrega el
dinero, el administrador modifica el estado del pedido a “Completado”.
Las primeras ventanas del prototipo de usuario, para el sub-sistema cliente, se muestran en la figura
14.
Se pide:
a. Identifique los subsistemas.
b. Realice el diagrama de bloques representando los subsistemas.
c. Realice la viabilidad técnica.
d. Especifique cuatro Requerimientos del Sistema utilizando un formato estándar.
e. Escriba cuatro Requerimientos no funcionales de seguridad, usabilidad, fiabilidad y
estándares según Std. IEEE 830-1998.
Nota: Los siguientes diagramas: diagrama de actividades, diagrama de transición de estados, modelo
del dominio le ayudarán a especificar mejor la descripción del sistema.
39
40
Figura 14. Cuatro ventanas de los primeros prototipos del usuario de la parte cliente del sistema de Gestión on-line de
pedidos
41

Obtención y Análisis de los Requerimientos
Ejercicio N°1
La segunda etapa del proceso de Ingeniería de Requerimientos es la Obtención y Análisis de los
Requerimientos. La figura 15 muestra el proceso dentro de una espiral de forma que las actividades se
entrelazan a medida que el proceso avanza desde el anillo interior a los exteriores de la espiral.
Se pide:
a. Describir el proceso de descubrimiento de requerimientos. La descripción deberá la siguiente

información: definición, fuentes de información, técnicas para descubrir los requerimientos,
tareas que se realizan durante el proceso, participantes y el resultado esperado del proceso.
b. ¿Qué importancia tiene el modelo de la arquitectura del sistema en la clasificación y
organización de los requerimientos?
Figura 15. Segunda actividad del proceso de Ingeniería de Requerimientos: Obtención y análisis de Requerimientos
[Fuente: Sommerville Ian, Ingeniería del Software]
Ejercicio N°2
a. Escriba dos opciones para administrar o aplicar el cuestionario.
b. La etnografía es una técnica de observación que es especialmente efectiva para descubrir dos
tipos de requerimientos. Explique cuáles son esos requerimientos.
42
Ejercicio N°3
a. Para un sistema del Caso de Estudio del Trabajo Práctico 6, escriba una lista de preguntas que
permitan descubrir otros requerimientos del sistema automatizado. La entrevista será
realizada con los usuarios finales directamente implicados en el sistema de información.
b. Un analista de sistemas preparó la siguiente lista de preguntas para realizar durante una
entrevista :
Lista de preguntas
¿Cuántas veces a la semana se actualizan los precios de los productos?
En promedio, ¿Cuántos pedidos de productos realizan los clientes?
¿Quién recibe la información de las ventas diarias?
¿Podría mencionar dos prioridades principales para mejorar la infraestructura de tecnología?
Según el tipo de preguntas, ¿Qué desventajas deberá afrontar el analista de sistemas si realiza la
entrevista con esas preguntas? Justifique su respuesta
Ejercicio N°4
a. Obtener y comprender los requerimientos de los stakeholders es difícil por varias razones.
Escriba dos razones que justifiquen ésta dificultad.
Ejercicio N°5
a. Para obtener los requerimientos podemos utilizar prototipos iniciales o exploratorios del
sistema. Esos prototipos ¿pueden realizarse en papel? Explique.
b. En el modelo evolutivo podemos trabajar con prototipos a fin de conocer con claridad los
detalles de las necesidades de nuestro cliente y evolucionar el sistema agregando nuevos
atributos propuestos por el cliente. ¿Cómo evolucionaría el prototipo?
43
Caso de Estudio: Análisis de Requerimientos

Un sanatorio nos solicitó un sistema de información automatizado, para el área de recepción de
llamadas de emergencias médicas relacionadas con la población adulta. El sanatorio no cuenta con el
servicio especializado para la atención de emergencia infantil.
Una emergencia médica es toda aquella situación de gravedad en donde una persona necesita una
atención inmediata. Una situación de gravedad es por ejemplo: pérdida de conocimiento de cualquier
origen; paro cardiorespiratorio; accidentes graves que causan traumatismos con hemorragias severas;
episodios convulsivos; electrocución; dolor de pecho en población de riesgo o con antecedentes
cardíacos; complicaciones severas de las distintas etapas de la gestación; caídas de altura;
hemorragias; heridas de arma blanca o de fuego; politraumatismos y quemaduras graves.
Una emergencia médica debe atenderse en el menor tiempo posible caso contrario puede generar
complicaciones fatales, por lo tanto el paciente debe trasladarse en ambulancias de urgencias.
El proceso de emergencia médica se inicia con el llamado telefónico de un ciudadano quien solicita el
servicio de emergencia del sanatorio para una persona o familiar cercano. El personal especializado,
que pueden ser enfermeras/os coordinadores, es el responsable de atender las llamadas e inicia un
protocolo de preguntas orientadas a identificar la emergencia.
Actualmente se está trabajando con los siguientes requerimientos del sistema:
 Las enfermeras coordinadoras cuando inician el interrogatorio telefónico podrán registrar una
nueva orden de emergencia.
 Una orden de emergencia tiene la siguiente información:
 datos propios de la orden y la llamada: el número de orden, el número de
teléfono, fecha, hora y teléfono del que se realiza la llamada;
 datos de la persona que llamó: apellido y nombre y relación con el paciente;
 datos personales del paciente: apellido y nombre, sexo, edad, dirección donde se
encuentra el paciente
 evento o situación de gravedad
 El sistema permitirá la interoperabilidad con otras aplicaciones mediante servicios Web para
mapas, basados en estándares y con independencia de la plataforma.
 El sistema deberá obtener y mostrar la localización específica del llamado dentro de un mapa de
calles de la ciudad.
 El sistema permitirá obtener la ubicación de las ambulancias sobre el mapa que se está
consultando.
 El sistema deberá determinar el mínimo recorrido que deberá realizar la ambulancia para llegar
al sitio señalado.
 El sistema imprimirá la orden de emergencia y el recorrido recomendado para llegar al lugar de
la emergencia.
 Cada usuario final del sistema se deberá autenticar mediante el ingreso de un nombre de usuario
y contraseña. El acceso será verificado por el sistema.
44
 El sistema será desarrollado siguiendo la metodología ágil proporcionada por el Proceso

Unificado de desarrollo: UP ágil.
 La especificación de los requerimientos l sistema se realizará siguiendo las recomendaciones y
buenas prácticas del estándar IEEE 830-1998.
 El sistema será rápido y fácil de usar.
 Cada ambulancia puede transportar como máximo 1 paciente.
 Las ambulancias son clasificadas según la disposición de los recursos para tratar la emergencia.
 El sistema deberá proveer reportes de seguimiento por fecha de órdenes de emergencia.
Se pide:
a. Realice el diagrama de bloques que represente la organización del sistema [arquitectura
conceptual del sistema].
b. Clasifique y priorice los requerimientos.
c. Analice los requerimientos y determine si éstos cumplen con las características y buenas
prácticas recomendadas por la IEEE 830-1998.
d. Proponga los prototipos exploratorios de interfaz de usuario.
e. Realice el Diagrama de Casos de Usos.
f. Documente los Casos de Usos para especificar la interacción del usuario con el sistema.
Bibliografía
o Capítulo 6: Modelo de Casos de Uso: escritura de requisitos en contexto
o Capítulo 7: Procesos de la Ingeniería de los Requerimientos
o Capítulo 16: Diseño de Interfaces de Usuario
 Kendall & Kendall. Análisis y Diseño de Sistemas. Prentice Hall. 6ta. Ed.
o Capítulo 6: Elaboración de prototipos, RAD y programación extrema
 Herramientas CASE para el modelado de los prototipos de interfaz de usuario
45
Para leer y consultar…

Realizar entrevistas es para nosotros una tarea cotidiana en nuestro trabajo. Podemos tener una Guía de
Preguntas, como un checklist que nos ayudan en la preparación de la entrevista para la búsqueda de
Información.
Las preguntas no tienen ningún orden de importancia. No es necesario seleccionar todas las preguntas
a la vez, hay que leerlas y elegir las que mejor se adapten al contexto del sistema o problema que
necesitemos solucionar. Podemos agregar nuevas preguntas.
Proceso ¿Podría describir cada paso del proceso actual?

– Dominio del Problema – ¿Qué secuencia tienen las actividades?
¿Hay actividades paralelas?
¿Qué reglas se aplican en el proceso?
Las reglas ¿Pueden cambiar?
¿Qué restricciones se aplican?
¿Cuándo y cómo se inicia el proceso?
¿Cuándo y cómo termina el proceso?
¿Quiénes participan en el proceso?
Dato e información que necesita el ¿Cuál será el formato de los datos, tanto para la entrada como para la salida?
sistema ¿Quién recibe o modifica la información?
¿Quién produce o genera la información?
¿Cuán a menudo serán recibidos o enviados los datos?
¿Cuán exactos deben ser los datos?
¿Con qué grado de precisión deben hacerse los cálculos?
¿Cuántos datos fluyen a través del sistema?
¿Debe retenerse algún dato por algún período de tiempo?
Si hay cálculos, ¿Cómo se realizan?
Usuarios y factores humanos ¿Quién usará el sistema?

¿Habrá varios tipos de usuario?
¿Cuál es el nivel de habilidad de cada tipo de usuario?
¿Qué clase de entrenamiento requerirá cada tipo de usuario?
¿Cuán fácil le será al usuario comprender y utilizar el sistema?
¿Cuán difícil le resultará al usuario hacer uso indebido del sistema?
Funcionalidad del Sistema de ¿Qué hará el sistema?

Información ¿Cuándo lo hará?
¿Existen varios modos de operación?
¿Cómo y cuándo puede cambiarse o mejorarse el sistema?
Interfaces del Sistema de ¿Los datos de entrada provienen de otro sistema de información?
Información ¿La salida del sistema va a uno o más sistemas?
¿Existe una manera preestablecida en que deben formatearse los datos?
Ambiente físico del sistema ¿Dónde está el equipo que el sistema necesita para funcionar?
¿Existe una localización o varias?
¿Hay restricciones ambientales como temperatura, humedad o interferencia magnética?
46

Análisis Orientado a Objetos
Ejercicio N°1
a. Indique qué afirmación de las siguientes es correcta:
 Un requerimiento no funcional es equivalente a un caso de uso.
 Un caso de uso, generalmente, tiene asociados varios requerimientos funcionales.
 Un caso de uso tiene asociado exactamente un requerimiento no funcional.
b. ¿Para qué se usa el Diagrama de Casos de Uso? Nombre dos usos más importantes y
ejemplifique.
c. Hay tres tipos de actores externos en relación a un sistema. ¿Por qué es importante identificar
al actor de apoyo?
Ejercicio N°2
a. Escriba una guía para descubrir las asociaciones en el Modelo del Dominio.
b. Indique: ¿Cuál de los dos modelos es más conveniente utilizar en un Modelo del Dominio?
Justifique su elección.
 1
 2
c. Ejemplifique una situación donde sea necesario utilizar clases conceptuales de especificación.
d. Según la publicación La Especificación de Requisitos con Casos de Uso: Buenas y Malas Prácticas
¿Cuáles son los errores más comunes en la especificación usando Casos de Uso?
Ejercicio N°3
La figura 16 muestra un Diagrama de Secuencia del Sistema que forma parte de la especificación de
un Sistema de Gestión de Compras de una organización. El sistema tiene como objetivo realizar de
forma automatizada las órdenes de compras que se envían a proveedores.
Durante la iteración actual, el equipo de Análisis de Sistemas realizó el Diagrama de Secuencia del
Sistema para la descripción del caso de uso Registrar orden de compra y un Modelo del Dominio parcial
figura 17.
47
Gerente
Figura 16. Diagrama de Secuencia del Sistema para el Caso de Uso <Registrar Orden de Compra>
Caso de Uso:<Registrar Orden de Compra>
Actores: Empleado del área de compras
Precondiciones: El empleado está autenticado e identificado en el Sistema. Los datos de los

productos y de los proveedores se encuentran registrados en el sistema.
Postcondiciones: Se registra la orden de compra en el Sistema. Se envían los datos de la orden de

compra al sistema del proveedor correspondiente. Se registra el estado de la orden como enviada.
Flujo normal de los eventos – Flujo de éxito

1. Este caso de uso comienza cuando el Gerente de Compras desea registrar una nueva orden de
compra.
2. El Gerente inicia el registro de la orden de compra.
3. El Gerente ingresa el código del proveedor.
4. El Sistema presenta los datos del proveedor. [nombre, dirección, teléfono, e-mail]
5. El Gerente ingresa el código del producto.
6. El Sistema presenta los datos del producto. [descripción, precio unitario]
7. El Gerente ingresa la cantidad del producto.
8. El Sistema agrega el producto a la orden de compra y presenta el subtotal y el total
actualizado.
______________________________________________________________________________
9. El Gerente finaliza el registro de la orden de compra.
10. _______________________________________________________________________________
11. El Sistema registra la orden de compra.
48
El Modelo del Dominio parcial:
Figura 17. Modelo del Dominio parcial para el Caso de Uso <Registrar Orden de Compra>
Se pide:
a. Complete el documento del Caso de Uso <Registrar Orden de Compra>, considerando el

Diagrama de Secuencia presentado en la figura 16.
b. Complete el Modelo del Dominio según el documento del Caso de Uso <Registrar Orden
de Compra>
c. Realice los contratos de las operaciones.
Ejercicio N°4
Modelar un sistema que permita conocer la densidad de un cuerpo. Los cuerpos pueden ser, por
ejemplo esferas, cubos, cilindros, conos entre otros. El usuario ingresa el valor de la masa de los
cuerpos. La densidad se calcula como la masa dividida en el volumen.
El cálculo del volumen varía según el tipo de cuerpo, por ejemplo el volumen del cubo es lado^3, el
volumen del cilindro PI*radio^2*altura. La densidad puede expresarse en las siguientes unidades:
kg/m³, g/cm³, kg/L.
Se pide:
a. Realice el Modelo del Dominio [clases conceptuales, asociaciones, atributos,

multiplicidad].
b. Realice el prototipo de interfaz de usuario.
c. Explique generalización. ¿Cuándo es conveniente definir una superclase conceptual?
d. En UML ¿cómo se modela la agregación?
49
Ejercicio N°5
a. Explique las clases borde, control y entidad.
b. Realice un cuadro comparativo entre el Modelo de Casos de Uso y el Modelo del Análisis.
c. ¿Cuáles son las ventajas de realizar el Modelo del Análisis?
Ejercicio N°6
Una importante empresa de alquiler de vajillas para eventos nos solicita desarrollar un sistema de
información automatizado, con los siguientes objetivos:
 Registrar los datos de los clientes a fin de tener una comunicación constante con ellos.
 Registrar los datos de los eventos para los que estarán asignados los respectivos recursos en
alquiler, para evitar las demoras o tiempos de espera de los clientes.
 Controlar la existencia de cada producto disponible en la empresa para alquilar para eventos.
A continuación se describe del proceso de alquiler de vajillas, tal como nos dijo nuestro cliente. La
descripción del proceso refleja las necesidades de nuestro cliente:
Cuando una persona requiera los servicios de la empresa, el empleado le solicitará al cliente los datos
personales (apellido, nombre, dirección, teléfono) y completará una ficha personal del cliente.
Una vez que cliente fue registrado podrá solicitar los productos ofrecidos por la empresa. El empleado
consultará la disponibilidad de los elementos para alquilar solicitados por el cliente, el sistema permitirá
verificar si está disponible para el alquiler en la fecha en la que se desarrollará el evento y le comunicará al
cliente si puede ser atendido su pedido.
Las primeras ventanas del prototipo de usuario se muestran a continuación:
50
Se pide:
a. Indicar elementos de interfaz de usuario se utilizaron para construir el prototipo.

b. Datos que podría agregar a las ventanas, de manera de mejorar los prototipos.
c. Realice el documento de Casos de Uso.
d. Modelo del dominio.
e. Contrato de operaciones.
Bibliografía
o Parte 2 y Parte 3
o Capítulo 8: Modelos del Sistema
 Booch G., Rumbaugh J., Jacobson I. El Lenguaje Unificado de Modelado. Pearson Addison
Wesley, 2da. Ed.
o Capítulo 8: Diagrama de Clases
 Booch G., Rumbaugh J., Jacobson I El proceso unificado de desarrollo de software.
Pearson Addison Wesley, 2da. Ed.
o Capítulo 8: Análisis
 Jill Nicola. Paper. Business Object Modeling with Collaboration Patterns [Disponible en el
Aula Virtual]
 Jose Antonio Pow Sang Portillo. Paper, La Especificación de Requisitos con Casos de Uso:
Buenas y Malas Prácticas [Disponible en el Aula Virtual]
51
Caso de Estudio: Análisis Orientado a Objetos

El MK5000 es un taxímetro de última generación. Está compuesto por un display de 5 dígitos, de 7
segmentos cada uno, más un punto para la representación de la coma decimal. Posee dos pulsadores
rectangulares, cada uno pintado de un color diferente (para facilitar la identificación de los mismos).
Además, tiene un conjunto de 10 luces led, 9 rojas y una blanca, y una impresora de tickets integrada.
Para registrar un viaje, se debe presionar el pulsador de color verde. La tarifa inicial del viaje aparece
en el display de 5 dígitos, que se ilumina en color verde para facilitar la visualización de los números en
la oscuridad. A medida que transcurre el viaje, el monto total a pagar se renueva automáticamente en
el display cada 22 segundos, según un monto a cobrar por cuadra recorrida.
Cuando se llega a destino, se debe presionar el pulsador rojo. El MK5000 imprimirá de forma
automática el ticket para el pasajero, el cual incluye datos sobre el viaje. Cuando se presiona
nuevamente el pulsador rojo, el MK5000 desactiva la luz verde del display. Además se encenderá el
conjunto de 9 leds de color rojo y 1 led de color blanco, para indicar a sus clientes, que su taxi se
encuentra disponible nuevamente. Estas luces se apagan cuando se presiona el botón verde para el
inicio del registro del viaje.
Para el registro del número de cuadras recorridas durante el viaje, el MK5000 posee un sensor
magnético, que debe conectarse a la rueda del auto. La rueda posee un imán que el sensor magnético
detecta. Al girar la rueda, el sensor informa la cantidad de vueltas que realizó la misma.
La impresora de tickets del MK5000 es una de las más rápidas del mercado. Contiene un depósito de
tinta que indica el nivel de tinta actual, y un rollo de papel para la impresión de los tickets.
Un ejemplo de ticket impreso luego de un viaje se encuentra a continuación. Contiene todos los datos
que se deben registrar durante el viaje.
Para el caso expuesto y su contexto, se pide:

1. Realizar el Modelo del Dominio.
2. Documentar el caso de uso Realizar Viaje.
3. Realizar el Modelo del Análisis.
52
Para el siguiente Caso de Uso se pide:
a. Complete los flujos alternativos del Caso del Uso

b. Complete el Modelo del Análisis que se muestra en la figura 19.
Caso de uso < Pagar Factura>
Precondiciones: El Comprador ha recibido los bienes y servicios y al menos una factura del Sistema.
Postcondiciones: La factura ha sido pagada o el pago de la factura ha sido cancelado y no se ha

realizado ninguna transferencia.
Flujo normal de los eventos – Flujo de éxito
1. Este caso de uso comienza cuando el Comprador desea pagar una factura.
2. El Sistema presenta las facturas pendientes de pago.
3. El Sistema verifica que el contenido de cada factura es consistente con las confirmaciones de
pedido recibidas anteriormente * y notifica al Comprador.
4. El Comprador decide pagar una factura por banco.
5. El Sistema genera una petición de pago para transferir el dinero a la cuenta del vendedor.
6. El Sistema realiza el pago, transfiriendo el dinero de la cuenta del comprador a la cuenta del
vendedor.
7. El Sistema notifica al comprador y al vendedor sobre el resultado de la transacción.
Flujos alternativos
6.a. No hay suficiente dinero en la cuenta del Comprador.

El Sistema cancelará el pago y notificará al Comprador.
Figura 18. Modelo del Dominio para el Caso de Uso <Pagar Factura>
* Forma parte del Caso de Uso <Confirmar Pedido>
53
Figura 19. Modelo del Análisis parcial para el Caso de Uso <Pagar Factura>
54

Validación de los requerimientos
Ejercicio N°1
El último proceso de la Ingeniería de Requerimientos es la validación de requerimientos, tal como se
puede observar en la figura 20 que muestra el modelo en espiral de los procesos de la Ingeniería de
Requerimientos.
Figura 20. Modelo en espiral de la Ingeniería de Requerimientos
Se pide:
a. Describir el proceso de validación de requerimientos. La descripción deberá la siguiente

información: definición, porque es importante la validación de requerimientos, participantes
y el resultado esperado del proceso.
Ejercicio N°2
a. Describa las verificaciones que se pueden realizar sobre el documento de Especificación de
Requerimientos.
b. ¿Qué técnicas de validación de requerimientos se pueden utilizar? Describirlas
Ejercicio N°3
a. Explique las siguientes clases de prototipos:
i. Prototipo corregido
ii. Prototipo funcional
iii. Prototipo primero de una serie y Prototipo de características seleccionadas
55
Ejercicio N°4
a. ¿Cuáles son las ventajas y desventajas de la elaboración de prototipos?
b. Al momento de crear los prototipos de usuario es importante considerar un conjunto de
factores humanos. Detalle cuatro factores más importantes.
c. Explique el papel del usuario en la elaboración de prototipos.
Bibliografía
 Kendall & Kendall. Análisis y Diseño de Sistemas. Prentice Hall. 6ta. Ed.
o Capítulo 6: Elaboración de prototipos, RAD y programación extrema
o Capítulo 16: Diseño de interfaces de usuario
56
Caso de Estudio: Validación de requerimientos
Figura 21. Prototipo de interfaz de usuario para el Sistema de Gestión de Turnos
La figura 21 muestra el prototipo de interfaz de usuario para la solicitud de turnos de

prestaciones brindadas por un Instituto de Radiología.
El Instituto necesita que los pacientes puedan reservar turnos para los estudios usando
Internet. Para reservar turnos los pacientes eligen el tipo de estudio a realizarse y
comprueban la disponibilidad horaria según un calendario. El paciente puede elegir el horario
del turno disponible y confirmar la reserva del turno. Para el Instituto es importante que el
paciente conozca el apellido y nombre del médico que le realizará el estudio en el horario
elegido.
Al confirmar el turno, el paciente ingresa sus datos personales. En caso de que el paciente se
haya realizado estudios anteriores puede buscar su información personal ingresando su DNI o
e-mail de contacto.
La duración de cada turno varía según el tipo de estudio. Por ejemplo para un estudio de Eco
Dopler la duración es de 40 minutos.
Para un mejor contacto con los pacientes se requiere que el sistema envíe un mail al paciente
indicando la fecha y hora del turno y el tipo de estudio solicitado. Además, se le enviará vía
SMS un recordatorio al paciente veinticuatro horas antes del turno.
Se pide:
a. Validar el prototipo de interfaz de usuario con las necesidades del Instituto
Radiológico a fin de comprobar si se está construyendo el sistema correcto.
b. En caso de haber encontrado inconvenientes, proponer nuevos prototipos que
satisfagan las necesidades del usuario.
57

Introducción a la gestión de proyecto de sistemas
Ejercicio N°1
a. Realice el Diagrama de Actividad del Proceso de Calendarización de un proyecto de sistemas. El
Diagrama deberá contener evento inicial, evento final, objetos de datos, calles, estados de actividad
/ acción
b. La siguiente tabla contiene una columna con la información que el líder de proyecto necesita para
identificar cada actividad o tarea. Se pide:
 Complete la definición de cada uno de los datos necesarios para identificar a las actividades del
proyecto de sistemas.
Información de cada actividad Definición

Nombre de la actividad / tarea
Evento que hace comenzar la actividad
Duración
Fecha inicial
Fecha de entrega
Personas
Hito
Entregas
Ejercicio N°2
a. Dependencias entre las actividades. También se conoce como relación entre tareas. Se pide:
 Complete el siguiente cuadro que muestra la dependencia entre las tareas.
Dependencia entre las Actividades Descripción
Fin a comienzo La actividad / tarea comienza cuando su predecesora

finaliza
Fin a fin
Comienzo a fin La actividad / tarea finaliza cuando su predecesora

comienza
Ejercicio N°3
a. Complete la siguiente lista con las actividades, tareas e hitos, según los procesos de la Ingeniería
en Sistemas de Información.
58
Nombre del Proyecto: --------------------------------------
Estructura de Descomposición del Trabajo
Nivel de Fases del

Proyecto 2. Planificación del Proyecto
2.1. Seleccionar la estrategia de trabajo
2.2. Calendarizar el Proyecto

Nivel de
Actividades del 2.2.1. Identificar Actividades a realizar
Proyecto
2.2.2. -------------------------------------------------------
2.2.3. -------------------------------------------------------
2.2.4. Asignar personas a las actividades
Nivel de Tareas de 2.2.5. ---------------------------------------------------------

Proyecto
2.2.6. --------------------------------------------------- ------
2.3. Presentación y aceptación de la Planificación del Proyecto
3. Análisis de Sistemas
3.1. --------------------------------------------
3.2. ………………………………………………….
3.3. …………………………………………………
4. Diseño de Sistemas
4.1. ----------------------------------------------
Ejercicio N°4
a. De las siguientes afirmaciones marque las afirmaciones correctas:
 Se recomienda que la duración de las actividades debe ser por lo menos una semana.
 La subdivisión más fina de las tareas en sub-tareas es lo más conveniente.
 Cada fase del proyecto está libre de problemas.
 Podemos agregar un 30% más a la estimación del calendario para tratar problemas
imprevistos.
59
Caso de Estudio
Para solucionar el caso de estudio, considere el enunciado del Ejercicio 5, del trabajo práctico N° 2, página
14.
Se pide:
a. Seleccione un modelo de proceso de desarrollo para el proyecto
b. Asigne un nombre el proyecto de sistemas
c. Realice la calendarización del proyecto
d. Realice la factibilidad técnica y operativa del proyecto
e. Escriba una lista de riesgos potenciales del proyecto
Bibliografía
o Capítulo 3: Administración de proyectos
Secciones: Determinación de la viabilidad
Planeación y Control de actividades – Uso del gráfico de Gantt para programar
proyectos
o Capítulo 5: Gestión de Proyectos
60
Contenido para el
Trabajo Final
Integrador
61
Contenido para el Trabajo Final Integrador
1. Portada: contenido: Nombre del sistema o proyecto, apellido y nombre de los estudiantes,
número de legajo, comisión, apellido y nombre del profesor, año
2. Índice
3. Agradecimientos
4. Nota de Autorización presentada en la organización.
5. Nota de confirmación del trabajo realizado en la Organización
6. Cuerpo del trabajo (contenido del mismo)
Elección de un responsable: será conveniente tener un guía para el trabajo, preferentemente
relacionado con el área de estudio.
Conocimiento de las actividades generales de la empresa: describir brevemente el / los
procesos de Negocios que son el Dominio del Problema, a través de una Elicitación, (detallar las
funciones de cada departamento de la empresa). Misión. Visión y Objetivos de la Organización.
Elaborar el Organigrama para conocer la estructura de la Organización resaltando el área donde
se desarrolla el sistema a analizar.
Definición del tema a desarrollar: usted deberá elegir el sistema a analizar, seguramente se
encontrará dentro de otros sistemas, por tal motivo deberá establecer la jerarquía de sistemas
para un mejor entendimiento del mismo.
Determinar: objetivos, ambiente y límite del sistema los que deberán estar bien definidos
usando los conocimientos adquiridos en la materia.
Diagrama de Gantt: Definir los tiempos sobre la base de las actividades a desarrollar para el
trabajo total. (Tenga en cuenta que este gráfico tiene su versión formulada y su versión real)
Modelado del Negocio (Diagrama de Actividades)
Documento Visión: Escribir los Problemas\Oportunidades del Negocio.
Elabore el Diagrama de Bloques del Sistemas donde se observen los subsistemas, sus entradas,
procesos y salidas.
Estudio de Viabilidad del Proyecto.
Documento Especificación Complementaria: Escribir las Reglas del Dominio-Reglas del Proceso
de Negocio.
Estándar de la IEEE/ANSI 830 – 1998 (Std 29148 – 2011) (Requerimientos Funcionales y No
Funcionales)
Aplicar la Metodología del Proceso Unificado (UP):
o Modelo de Casos de Uso: Diagrama de Casos de Uso. Documentar los Casos de Uso (Formato
Completo). Diagrama de Secuencia. Contrato de las operaciones.
o Modelo del Dominio.
o Diagrama de Transición de Estados
o Modelo del Análisis.
Prototipo de Interfaz Gráfica (No funcionales).
7. Observaciones finales del trabajo, conclusiones y Bibliografía.
Nota: el Trabajo Práctico Final deberá ser presentado impreso y en soporte óptico:
- Soporte Óptico: CD conteniendo un archivo con formato .HTML
- Trabajo Impreso: carpeta anillada o encuadernada.
62

2016-Guia Trabajos Practicos

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

2016-Guia Trabajos Practicos

Cargado por

Copyright:

Formatos disponibles

SISTEMAS

ANÁLISIS DE SISTEMAS 2016

Incumbencias del Ingeniero en Sistemas de

Información sobre la materia

Requisitos para regularizar la asignatura

UNIDAD 2: EL CICLO DE VIDA DE LOS SISTEMAS DE INFORMACIÓN Y SISTEMAS DE SOFTWARE

UNIDAD 3: MARCO DE DESARROLLO – PROCESO UNIFICADO

UNIDAD 4: MODELOS Y HERRAMIENTAS PARA EL MODELADO

UNIDAD 5: EL MODELADO DEL DOMINIO DEL PROBLEMA

UNIDAD 6: INGENIERÍA DE REQUERIMIENTOS

UNIDAD 7: OBTENCIÓN Y ANÁLISIS DE LOS REQUERIMIENTOS

UNIDAD 8: EL ANÁLISIS ORIENTADO A OBJETOS

UNIDAD 9: VALIDACIÓN DE LOS REQUERIMIENTOS

0 Repaso de Sistemas y Organizaciones

h. Diagrama de Gantt. Ejemplifique para el proyecto: Aprobar Análisis de Sistemas en Diciembre

Organizaciones y Sistemas de Información

La organización planea implementar un Sistema de Información automatizado. Los analistas de

 La estructura formal de la organización:

1 Trabajo Práctico N°1

Caso de estudio: Entrevista inicial para recopilar información

Para leer y recordar…

Las tecnologías representan la Infraestructura Tecnológica de Información - abreviado es TI - y es

Las tecnologías de procesamiento y memoria son los componentes responsables del

Las tecnologías de almacenamiento representan el almacenamiento secundario de los datos y la

Las tecnologías de distribución consisten de medios de comunicaciones, dispositivos y software

2 Trabajo Práctico N°2

Software Hardware Redes Documentación

Personas Procesos Comunicaciones Datos

Figura 1. Componentes de los Sistemas de Información Automatizados

Los empleados de la sala de control pueden realizar consultas de la información almacenada en el

a. Clasifique la tecnología usada en el sistema, e incluya la que Ud. considere conveniente

b. Modelar la arquitectura conceptual del sistema mediante un diagrama de bloques que

Caso de Estudio: Selección de modelos de proceso

1. Un sistema de control antibloqueo de frenos de un automóvil. Las necesidades del cliente

Caso de Estudio: Arquitectura conceptual del Sistema de

El sistema de información deberá vincular a las Áreas:

 Académica: en la que los estudiantes podrán acceder a través de un usuario y contraseña a su

Para leer y recordar…

 Ejemplo de Lista de verificación o Checklist

3 Trabajo Práctico N°3

4 Trabajo Práctico N°4

Figura 4. Elementos más comúnmente utilizados del Diagrama de Actividades

Figura 6. Elementos del Diagrama de Transición de Estados

Figura 7. Diagrama de Transición de Estados para el funcionamiento de un semáforo

a. Realizar el Diagrama de Transición de Estados, correspondiente al contestador automático.

Caso de Estudio: Diagrama de Actividades –Diagrama de

Cuando el socio devuelve el libro el Bibliotecario registra la información de la devolución y el sistema

Diagrama de Transición de Estados

Al momento de la creación de un proceso, se le asigna un estado inicial de "Creado". Este estado

El planificador elige, según un esquema de planificación determinado, un proceso en estado "Ready

5 Trabajo Práctico N°5

b. Explique para qué se utiliza el Modelo del Dominio.

Id Regla Grado de variación origen

Caso de Estudio: Modelo del dominio

Figura 10: Prototipo de la pantalla del juego

Caso de Estudio: Visión y Especificación Complementaria

1. Compra directa: solamente para atender situaciones de urgencia

La Gerencia de Administración que se encarga de dirigir los procesos de adquisición y suministro de

 Automatizar la recepción de los productos

La Gerencia de Administración quiere evitar el riesgo de adquirir los insumos a proveedores no

El empleado del área de servicio registra manualmente el ingreso de productos en un formulario de

a. Escribir los problemas de información que posee actualmente el proceso de negocio de

Aprendiendo a modelar el dominio del problema

Libro Principios de Sistemas de Información