MDEISW - Maestría en Dirección Estratégica en Ingeniería de

Software.

SOLUCIÓN DE CASO
PRÁCTICO
TI037 - Análisis y Diseño Integral de Sistemas y Requerimientos

Ing. Omar Orrala Palacios

1-1-2019
 Solución de caso práctico MDEISW - TI037

1. ¿Cuáles son las principales dificultades encontradas en la fase de levantamiento

de requisitos?
De acuerdo con Londoño, Anaya, & Tabares, (2008), podemos encontrar ciertas
dificultades tales como:
Problemas de alcance: No definir claramente los objetivos y alcance del proyecto, ya
que generalmente, los analistas dedican la mayor parte de los esfuerzos a la definición de
requisitos funcionales y de estructura, prestando poca atención a las restricciones de
contexto y a la definición de los atributos de calidad esperados del producto.
Problemas de volatilidad: Cuando no está bien definido el alcance puede ocurrir que un
proyecto involucre un tiempo extenso en su desarrollo, y los requisitos tiendan a cambiar.
Problemas de composición y entendimiento de requisitos: Describir las necesidades
desde una perspectiva de solución de ingeniería y no desde el enfoque del negocio, lo cual
dificulta la comunicación entre el cliente y el desarrollador.
Problemas de Trazabilidad. Cuando no se controla la evolución de los requisitos desde
fases tempranas de desarrollo hasta la implementación. No es posible garantizar la
evolución de los requisitos en elementos del modelo de otras fases del proceso. La
trazabilidad pierde la característica básica de un modelo de requisitos, y no permite tener
un control de los cambios y un análisis de impacto.
Manejo de conflictos: Dificultad de encontrar un enfoque que facilite el análisis y
solución de conflictos entre los participantes del proyecto de desarrollo para dar
apoyo a las decisiones y gestionar los riesgos. El manejo de conflictos es clave
durante el levantamiento y análisis de requisitos, ya que se deben contemplar las
consideraciones de los involucrados como clientes y usuarios finales, las condiciones
de negocio y de tecnología y otros que pueden dar origen a conflictos que deben ser
resueltos.

Dificultad en el soporte de mapeo. Mal enfoque para facilitar la transformación

de un requisito de software en artefactos de software de una etapa siguiente. En la
medida que se pierde el enfoque, este no facilitará el proceso de mapeo o
transformación de los artefactos de una fase a otra, y se estará mal logrando la
trazabilidad.

Problemas de validación y verificación: Falta de capacidad para revisar y evaluar los

resultados intermedios durante el proceso, es decir, validar si se están haciendo las cosas
como se debe y verificar que los productos generados corresponden a lo que se ha
solicitado.
Problemas de Escalabilidad: Falta de capacidad del enfoque para ajustarse a diferentes
tipos de proyectos, tanto por su tamaño como por su misma naturaleza.
Dificultades organizacionales: Otras dificultades que se encuentran en el proceso de
levantamiento de requisitos son de orden institucional o empresarial, tales como una
adecuada planificación estratégica en la organización y un manual de proceso actualizado,
definición de funciones y niveles de acceso a la información, políticas, reglamentos
desactualizados, una adecuada aplicación de normas y estándares de calidad a los
procesos institucionales y a la cadena de valor empresarial.

ING. OMAR ORRALA PALACIOS 1

 Solución de caso práctico MDEISW - TI037

2. ¿Cuáles son las principales técnicas para el levantamiento de requisitos?

Explique brevemente cada una de las técnicas.
Según (Kendall & Kendall, 2011), se contempla una clasificación en función a los
métodos empleados, tales como: Métodos interactivos, Métodos discretos y Modelado
ágil y prototipos.
Entre de los métodos interactivos, están las entrevistas, y las encuestas o cuestionarios
Las entrevistas: Se realizan con los usuarios o interesados clave. Direccionan al usuario
hacia aspectos específicos del requerimiento a levantar. Son útiles para obtener y
documentar información detallada sobre los requerimientos y sus niveles de
granularidad. Pueden ser entrevistas formales o informales. Una clave es mantenerse
enfocado en los objetivos de la entrevista. Las preguntas abiertas son útiles para
identificar información faltante. Las preguntas cerradas son útiles para confirmar y
validar información. El éxito de las entrevistas depende del grado de conocimiento del
entrevistador y entrevistado, disposición del entrevistado de suministrar información,
buena documentación de la discusión y en definitiva de una buena relación entre las
partes.
Durante el proceso de la entrevista, los analistas esperan escuchar cuestiones de
Interacción Humano Computadora, relacionadas con la ergonomía, la estética, la
capacidad de uso y la utilidad, así como los objetivos, sentimientos, opiniones y
procedimientos informales en las entrevistas con los encargados de tomar las decisiones
en la organización. Las entrevistas son diálogos planeados de preguntas y respuestas
entre dos personas. Los analistas utilizan la entrevista para desarrollar su relación con
un cliente, observar el entorno de trabajo y recolectar datos. Es preferible llevar a cabo
las entrevistas en persona.
Los cinco pasos para planear la entrevista son leer el material sobre los antecedentes,
establecer los objetivos de la entrevista, decidir a quiénes entrevistar, preparar al
entrevistado y decidir sobre los tipos y la estructura de las preguntas. Las preguntas son
de dos tipos básicos: abiertas o cerradas. Las preguntas abiertas permiten todas las
opciones de respuesta para el entrevistado. Las preguntas cerradas limitan las posibles
opciones de respuesta. Las preguntas de sondeo o de seguimiento pueden ser cerradas o
abiertas, pero le piden al entrevistado una contestación más detallada.
Las entrevistas se pueden estructurar en tres formas: pirámide, embudo o diamante. Las
estructuras de pirámide empiezan con preguntas cerradas detalladas y se amplían con
preguntas más generalizadas. Las estructuras de embudo empiezan con preguntas
abiertas generales y después se restringen a preguntas cerradas más específicas. Las
estructuras en forma de diamante combinan las ventajas de las otras dos estructuras,
pero se requiere más tiempo para llevarlas a cabo.
Las encuestas o cuestionarios: Son técnicas útiles para recopilar eficientemente los
requerimientos de muchas personas. La clave para el éxito es que tengan un propósito y
audiencia claramente definida, establecer fechas topes para llenar la encuesta, con
preguntas claras y concisas. Deben enfocarse en los objetivos de negocio que se

ING. OMAR ORRALA PALACIOS 2

 Solución de caso práctico MDEISW - TI037

necesitan identificar. Pueden apoyarse con entrevistas de seguimiento con usuarios

individuales. Pueden contener tanto preguntas cerradas como preguntas abiertas.
Mediante el uso de encuestas, los analistas de sistemas pueden recopilar datos sobre
cuestiones de HCI1, posturas, creencias, comportamiento y características de las
personas clave en la organización. Las encuestas son útiles si las personas en la
organización están dispersas en una zona amplia, si hay muchas personas involucradas
con el proyecto de sistemas, si se requiere un trabajo exploratorio antes de recomendar
alternativas o si existe la necesidad de detectar problemas antes de llevar a cabo las
entrevistas.
Una vez que se establecen los objetivos para la encuesta, el analista puede empezar a
escribir preguntas abiertas o cerradas. Lo ideal sería que las preguntas fueran simples,
específicas, cortas, sin predisposiciones ni condescendencias, con precisión técnica,
dirigidas a personas que tengan conocimientos apropiados y escritas en un nivel de
lectura apropiado. Tal vez el analista de sistemas quiera usar escalas, ya sea para medir
las posturas o características de los encuestados o hacer que éstos actúen como jueces
en relación con el tema del cuestionario. Escalar es el proceso de asignar números u
otros símbolos a un atributo o característica. El control consistente del formato y estilo
de los cuestionarios puede producir una mejor tasa de respuesta. Podemos diseñar
encuestas Web para fomentar respuestas consistentes. Además, es importante ordenar y
agrupar las preguntas de una forma significativa para ayudar a los encuestados a
entender el cuestionario. Se pueden administrar las encuestas de varias formas; por
ejemplo, vía electrónica a través del correo electrónico o Web, o estando el analista
presente entre un grupo de usuarios.
El diseño de aplicaciones conjuntas, JAD: Se utiliza para reducir tanto el tiempo como
el costo de las entrevistas personales, tal vez los analistas quieran considerar el diseño
de aplicaciones conjuntas (JAD) como alternativa. Mediante el uso de JAD los analistas
pueden analizar los requerimientos humanos de información y diseñar una interfaz de
usuario con los usuarios en un ambiente de grupo. Una evaluación cuidadosa de la
cultura específica de la organización ayudará al analista a juzgar si es adecuado usar
JAD.
Las mesas de trabajo (Workshops): son técnicas efectivas para obtener información
rápidamente de varias personas. Es recomendable tener una agenda predefinida y
preseleccionar a los participantes, siguiendo buenas prácticas para reuniones efectivas.
Se puede utilizar un facilitador neutral y un transcriptor (que no sea el mismo
facilitador). Se puede utilizar un material común sobre el cual enfocar la atención y
conversar, por ejemplo, una presentación con un desglose del proceso que se está
estudiando o un flujograma. Se pueden combinar con otras técnicas como pueden ser
las entrevistas y cuestionarios.
Tormenta de ideas: Es una sesión de trabajo estructurada orientada para obtener la
mayor cantidad de ideas posibles. Es recomendable limitarlas en el tiempo, utilizar
ayudas visuales y designar un facilitador. Las reglas son importantes, por ejemplo, los
criterios para evaluar ideas y asignarles un puntaje, no permitir las críticas a las ideas y

1
Interacción Humano Computadora (HCI)
ING. OMAR ORRALA PALACIOS 3
 Solución de caso práctico MDEISW - TI037

limitar el tiempo de discusión. En una primera fase, se deben identificar la mayor

cantidad de ideas, para luego evaluarlas. Todas las ideas deben ser consideradas y deben
limitarse que una idea se le ahogue o critique antes de tener tiempo de desarrollarla.
Entre los métodos discretos distinguimos el muestreo, la investigación y la observación.
Los métodos discretos se consideran insuficientes para recopilar información cuando se
utilizan por sí solos, por lo que deben utilizarse junto con uno o varios de los métodos
interactivos.
Muestreo: Los tipos de muestras útiles para un analista de sistemas son: de
conveniencia, intencionadas, simples aleatorias y complejas aleatorias. El último tipo
incluye las subcategorías de muestreo sistemático y muestreo estratificado. Hay varios
lineamientos a seguir para determinar el tamaño de las muestras.
Investigación, análisis de documentación: Consiste en obtener la información sobre
los requerimientos funcionales y requerimientos no funcionales de software a partir de
documentos que ya están elaborados. Es útil cuando los expertos en la materia no están
disponibles para ser entrevistados o ya no forman parte de la organización. Utiliza la
documentación que sea relevante al requerimiento que se está levantando.
Ejemplos de documentación: Planes de negocio, actas de constitución de proyecto,
reglas de negocio, contratos, definiciones de alcance, memorándums, correos
electrónicos, documentos de entrenamiento, entre otros.
Los analistas de sistemas necesitan investigar los datos y formularios actuales y
archivados, los cuales revelan dónde ha estado la organización y hacia dónde creen sus
miembros que se dirige. Hay que analizar tanto los documentos cuantitativos como los
cualitativos.
Debido a que los documentos son mensajes persuasivos, debe tomar en cuenta que
modificarlos Puede también cambiar a la organización.
Observación: Consiste en estudiar el entorno de trabajo de los usuarios, clientes e
interesados de proyecto (Stakeholders).
Es una técnica útil cuando se está documentando la situación actual de procesos de
negocio. Puede ser de dos tipos, pasiva o activa. En observación pasiva, el observador
no hace preguntas, limitándose solo a tomar notas y a no interferir en el desempeño
normal de las operaciones. En observación activa, el observador puede conversar con el
usuario. Se puede utilizar el método STROBE2 para comprender mejor la verdadera
forma en que los encargados de tomar decisiones recopilan, procesan, almacenan y
comparten la información para poder llevar a cabo su trabajo.

Entre los métodos avanzados o modelado ágil o de prototipos, existen técnicas de

recopilación de información útil para complementar el SDLC3 tradicional; tanto los

2
Observación estructurada del entorno (STROBE).
3
Ciclo de vida de desarrollo de sistemas, Systems Development Life Cycle (SDLC).
ING. OMAR ORRALA PALACIOS 4
 Solución de caso práctico MDEISW - TI037

métodos ágiles como la interacción humano-computadora comparten sus raíces en los

prototipos.
Prototipos: Cuando los analistas de sistemas utilizan prototipos buscan reacciones de
los usuarios, sugerencias, innovaciones y planes de revisión para realizar mejoras al
prototipo y por ende modificar los planes del sistema con un mínimo de costo y de
interrupciones. Los cuatro lineamientos principales para desarrollar un prototipo son: 1)
trabajar en módulos administrables, 2) crear el prototipo con rapidez, 3) modificar el
prototipo y 4) hacer énfasis en la interfaz de usuario. Aunque no siempre es necesario o
conveniente usar prototipos, hay que tener en cuenta que existe tres ventajas principales
interrelacionadas en cuanto a su uso: 1) el potencial de cambiar el sistema durante las
primeras etapas de su desarrollo, 2) la oportunidad de detener el desarrollo en un sistema
que no está funcionando y 3) la posibilidad de desarrollar un sistema que se acerque más
a las necesidades y expectativas de los usuarios. Éstos tienen que desempeñar un papel
definido en el proceso de creación de prototipos, por lo que los analistas de sistemas
deben trabajar en forma sistemática para obtener y evaluar las reacciones de los usuarios
en relación con el prototipo.
RAD: Un uso específico de los prototipos es el desarrollo rápido de aplicaciones (RAD).
Ésta es una metodología orientada a objetos con tres fases: planeación de
requerimientos, taller de diseño RAD e implementación. El modelado ágil es una
metodología de desarrollo de software que define un plan general con rapidez, desarrolla
y entrega el software rápidamente y después revisa el software en forma continua para
agregar características adicionales. Los valores de la metodología ágil que comparten
tanto el cliente como el equipo de desarrollo son comunicación, simpleza,
retroalimentación y valentía. Las actividades ágiles son codificación, prueba, escucha y
diseño. Los recursos disponibles son tiempo, costo, calidad y alcance.

XP: Las prácticas ágiles diferencian a los métodos ágiles, incluyendo un tipo de método
ágil conocido como programación extrema (XP), de los otros procesos de desarrollo de
sistemas. Las cuatro prácticas básicas de la metodología ágil son 1) entregas pequeñas,
2) semana de trabajo de 40 horas, 3) cliente en el sitio y 4) programación en pareja. El
proceso de desarrollo ágil incluye elegir una tarea que esté directamente relacionada con
una de las características deseadas del cliente con base en las historias de usuarios, elegir
un socio de programación, seleccionar y escribir los casos de prueba apropiados, escribir
el código, ejecutar los casos de prueba, depurar el código hasta que se ejecuten todos
los casos de prueba, implementarlo con el diseño existente e integrarlo a lo que ya existe.

Historia del usuario: Las historias de usuario, son una aproximación simple al
levantamiento de requerimientos de software, en la cual la conversación pasa a ser más
importante que la formalidad de requerimientos escritos. Es recomendable que sean
escritas por el mismo cliente o interesado (con apoyo del facilitador si es necesario), con
énfasis en las funcionalidades que el sistema deberá realizar. Al redactar una historia de
usuario deben tenerse en cuenta describir el Rol, la funcionalidad y el resultado esperado
de la aplicación en una frase corta. Las historias de usuario son una de las técnicas más
difundidas para levantar requerimientos de software en metodologías ágiles.

ING. OMAR ORRALA PALACIOS 5

 Solución de caso práctico MDEISW - TI037

3. JAD (Join Application Design) es una metodología que permite la extracción de

información de alta calidad de usuarios en un corto periodo de tiempo a través
de reuniones estructuradas que buscan decisiones por consenso, que es una de las
formas más productivas de decisiones en grupo. Hacer una búsqueda en internet
y enviar sus principios básicos y sus principales etapas.
Según Armando De Giusti Lie Rodolfo Bertone & Verónica Balda Ana Laura Vicenzi,
(1997), los principios básicos de JAD consisten en:
• Dinámica de grupos, definir los objetivos de las sesiones
• Ayudas visuales, prepararse para las sesiones
• Proceso racional y organizado, conducir las sesiones
• Producir los documentos de las sesiones, método de documentación WYSIWYG.
Dinámica de grupo: JAD, utiliza las ventajas de la dinámica de grupo en la definición
de objetivos, requerimientos y diseño externo, ayudados por un líder de sesión
experimentado, los gerentes, usuarios y profesionales de sistemas de información trabajan
como un equipo en sesiones de grupo para analizar los requerimientos, generar ideas
innovadoras y tomar decisiones que den forma al diseño del sistema. Las sesiones JAD,
incluyen a varios participantes (analistas, usuarios, ejecutivos, entre otros), quienes
aportarán sus distintas capacidades. Es necesario seleccionar un patrocinador ejecutivo,
algún superior que introduzca y concluya la sesión JAD. Es necesario seleccionar un
ejecutivo del grupo de usuarios que tenga cierto tipo de autoridad sobre el personal de
sistemas de información implicado en el proyecto. Esta persona será un símbolo
importante y visible del compromiso de la organización con el proyecto de sistemas. Debe
haber por lo menos un analista de sistemas de información presente, aunque por lo general
asume un rol pasivo, a diferencia de las entrevistas tradicionales, donde el analista
controla la interacción. El analista del proyecto deberá estar presente durante el JAD para
escuchar qué dicen los usuarios y qué requieren. Además, podría ser necesaria una
opinión experta sobre costos desproporcionados de posibles soluciones propuestas
durante la sesión. Sin este tipo de retroalimentación inmediata, pueden surgir soluciones
irreales con costos excesivos en la propuesta, que serán difíciles de descartar más
adelante. Se pueden elegir de ocho a doce usuarios de cualquier rango para que participen
en las sesiones JAD. Se trata de seleccionar a los que puedan articular la información que
necesitan para realizar sus trabajos, así como lo que desean en un sistema de cómputo
nuevo o mejorado.
El líder de la sesión no debe ser un experto en análisis y diseño de sistemas, sino alguien
con excelentes habilidades de comunicación como para poder facilitar las interacciones
apropiadas. El objetivo es contar con alguien que pueda atraer la atención del grupo para
tratar con las cuestiones importantes de sistemas, negociar y resolver conflictos en forma
satisfactoria y ayudar a que los miembros del grupo lleguen a un consenso. La sesión
JAD, debe incluir uno o dos observadores que sean analistas o expertos técnicos de otras
áreas funcionales para ofrecer explicaciones técnicas y consejos al grupo durante las
sesiones. Además, debe haber un registrador del departamento de sistemas de
información en las sesiones JAD para escribir y documentar formalmente todo lo que se
haga.

ING. OMAR ORRALA PALACIOS 6

 Solución de caso práctico MDEISW - TI037

Ayudas Visuales: El poco entendimiento de los conceptos de requerimientos y diseño ha

sido siempre una de las barreras que ha limitado la participación efectiva de los usuarios.
Muchas veces los usuarios y representantes de sistemas de información parecen estar de
acuerdo, pero surgen diferencias cuando el sistema es entregado. JAD introduce
numerosos tipos de ayudas visuales para hacer los conceptos de diseño más tangibles.
Utilizar prototipos, gráficos, transparencias, pizarras, proyectores o cualquier dispositivo
para presentar información, sirve para comunicar y validar mejor las ideas durante el
proceso de diseño.
Proceso racional y organizado: JAD emplea análisis top-down, y tareas bien definidas
para llevar a cabo la definición de objetivos requerimientos y diseño externo. El análisis
consiste en estudiar primero las áreas de alto nivel y más generales antes que los detalles.
Manejar cada nivel de detalle secuencialmente ayuda a asegurar un análisis completo por
dos razones: primero, reduce en gran parte la posibilidad de obtener diseños incompletos.
Una vez definido el panorama del sistema, cada nivel de detalle sucesivo puede ser
relacionado al cuadro completo. Segundo, cada nivel de detalle recibe la cantidad
apropiada de atención. La tendencia natural en el diseño de software es pasar directamente
a los detalles, asumiendo que los temas más amplios y de alto nivel son evidentes. JAD
garantiza el análisis incorporando tareas específicas que manejan cada nivel de detalle del
diseño en la secuencia apropiada. Cada tarea debe estar bien definida para que el proceso
sea organizado.
Método de documentación WYSIWYG: JAD produce un documento, cuyo propósito
es registrar los resultados obtenidos de manera que los usuarios y profesionales de
sistemas de información puedan entender las decisiones tomadas: los usuarios deben ser
capaces de revisar cuidadosamente y aprobar los contenidos del documento como una
medida de garantía de calidad; los profesionales del área de sistemas deben ser capaces
de acceder rápidamente a la información que necesitan para realizar el diseño interno, la
codificación y el testeo técnico del sistema. Los documentos de JAD efectivamente
comunican a ambos grupos a través de un método de documentación WYSIWYG. El
método asegura que el contenido y formato del documento sea completamente familiar a
los usuarios y profesionales de sistemas. Todas las ideas y decisiones expresadas en el
documento son generadas en las sesiones de grupo. La familiaridad del formato de los
documentos lleva a un proceso de revisión más efectivo. Los participantes de la sesión no
tienen que esforzarse para comprender el documento, sino que pueden concentrarse en
validar la exactitud de los contenidos.

Etapas de JAD
JAD posee dos fases: Planificación y Diseño. En el proyecto se ajustan los requerimientos
a un nivel más elevado, más que todo tomando en cuenta el rendimiento y la facilidad de
estos, en cuanto al ciclo de diseño se efectúa una intensa utilización de prototipos y se
diseña la interfaz de usuario, la calendarización, el presupuesto y el esquema de la base
de datos. Es por ello, que cada una de estas etapas tomaría entre uno y diez días. No se
debe confundir la fase diseño-JAD con la fase de diseño del proyecto ya que JAD se trata
de una técnica que se adaptaría en fase de estudio y análisis.

ING. OMAR ORRALA PALACIOS 7

 Solución de caso práctico MDEISW - TI037

Cada fase consiste en tres partes, como lo son: La preparación (decidir quién asistirá a
cada reunión), sesión o reunión propiamente dicha y conclusión, donde se extraen los
principales puntos consensuados durante la sesión y se plasman en algún soporte
permanente. Una vez culminado el proceso de JAD, se prosigue con el modelo de
desarrollo escogido. (Vargas Selena, 2011)
Preparación: Antes de que la sesión JAD comience, se debe:
• Definir el alcance del sistema.
• Identificar los problemas, limitaciones y restricciones.
• Estimar las necesidades de recursos (tiempo, presupuesto, personal) para
desarrollar el sistema.
• Identificar los gastos preliminares, beneficios, riesgos e impactos del proyecto.
• Identificar la naturaleza y los atributos principales del proyecto, las dependencias
del proyecto, y la interrelación del proyecto.
• Identificar los sub-proyectos apropiados. (El proyecto es a veces, descompuesto
en varios sub-proyectos, debido a la oportunidad y / o las limitaciones
presupuestarias.)
• Realice el análisis de los antecedentes necesarios para definir parámetros
fundamentales como el número de usuarios, el tamaño de la base de datos, el
rendimiento requerido, y las respuestas mínimas aceptables.
• Planificar la sesión JAD.
El período de sesiones: Una sesión JAD comienza con una descripción del material
recogido durante la etapa de preparación. Una vez que los participantes entiendan el
problema, el proceso de identificación de las dimensiones del problema, las posibles
causas, necesidades, y soluciones alternativas comienzan. Durante una sesión JAD, es
responsabilidad del moderador gestionar con eficacia el período de sesiones, para
asegurar que el equipo se mantenga enfocado en los temas del programa, para alentar a
todos los miembros del equipo a participar, para resolver los conflictos generados durante
el período de sesiones. Debido a que el equipo está compuesto en gran parte del personal
no técnico, es importante que los analistas de los sistemas de información traten de
minimizar el uso de términos técnicos. Las sesiones, consisten en reuniones de grupos,
donde los participantes del proyecto desarrollan en forma conjunta los requerimientos y/o
diseño del sistema. El líder de sesión facilita la dinámica de grupo y conduce a los
participantes a través de tareas, los analistas documentan los resultados. Esta fase podría
durar entre 1 a 10 días
Finalizar el informe de la JAD
En esta etapa se actualizan los documentos necesarios y se prepara un informe final que
resume todos los debates, hechos, resultados y conclusiones. Se construye un plan de
acción y un calendario para el desarrollo del sistema. Las sesiones de seguimiento son
necesarias, para recoger la información adicional requerida. Se producen las salidas
formales del JAD. Los resultados de diseño son prototipados y presentados al gerente del
proyecto. Esta fase requiere de 3 a 15 días. Si un proyecto tiene mas de un diseño, se
realiza una revisión final cuando se concluyen todos los diseños. El objetivo de esta etapa
es asegurar que los subsistemas se ajusten a lo determinado en la sesión del plan.

ING. OMAR ORRALA PALACIOS 8

 Solución de caso práctico MDEISW - TI037

Bibliografía
Armando De Giusti Lie Rodolfo Bertone, I. E., & Verónica Balda Ana Laura Vicenzi,
M. (1997). UNIVERSIDAD NACIONAL DE LA PLATA Trabajo de Grado JAD-
CASE Administrador de Flujo de Tareas y Documentos para la Especificación de
Requerimientos Directores: Alumnos. Recuperado de
http://sedici.unlp.edu.ar/bitstream/handle/10915/2158/Documento_completo__.pdf
?sequence=1
Kendall, K., & Kendall, J. E. (2011). Análisis y Diseño de Sistemas (Octava edi).
Londoño, L., Anaya, R., & Tabares, M. (2008). Revista EIA. Revista EIA. Escuela de
ingenieria de Antioquia. Recuperado de
http://www.scielo.org.co/scielo.php?script=sci_arttext&pid=S1794-
12372008000100004
Vargas Selena. (2011). JOINT APPLICATION DEVELOPMENT(JAD). Recuperado
31 de diciembre de 2018, de http://selene-vargas.blogspot.com/2011/09/joint-
application-developmentjad.html

ING. OMAR ORRALA PALACIOS 9