Caso práctico

MÁSTER EN DIRECCIÓN ESTRATÉGICA EN INGENIERÍA DE
SOFTWARE
Materia:
TI037 - Análisis y Diseño Integral de Sistemas y Requerimientos
Caso práctico:
Levantamiento de requisitos de software
Presentado por:
Valentina Roca Aguilera
Profesores:
Dr.(c) Lázaro Javier Hernández
Jesús Sánchez
BOGOTÁ, COLOMBIA
1 DE NOVIEMBRE DE 2018

INFORMACIÓN GENERAL
2MÁSTER EN DIRECCIÓN ESTRATÉGICA EN INGENIERÍA DE SOFTWARE
INSTITUCIÓN: Fundación Universitaria Iberoamericana -FUNIBER.
UNIVERSIDAD: Universidad Internacional Iberoamericana.
PROGRAMA: MDEISW-Máster en dirección estratégica en ingeniería de software.
MODALIDAD: En línea.
MATERIA: TI037 - Análisis y Diseño Integral de Sistemas y Requerimientos
NOMBRE: Valentina Roca Aguilera.
CEDULA: 31305201 de Cali.
PROFESIÓN: Ingeniera de Sistemas y Telecomunicaciones.
ESTUDIOS: Diplomado en redes CCNA.
Sun Certified Solaris 10 Associate – SCSAS.
Sun Certified Java Programmer Standard Edition 6.0 –SCJP.
TOGAF Certified 9, Level 1 and 2.
IBM Architectural Design of SOA Solutions.
ITIL Fundamentos.
COBIT Fundamentos.
SCRUM Fundamentos
CORREO: valentinaroca@gmail.com
CELULAR: +57-3204498464
PAÍS: Colombia.
CIUDAD: Bogotá, Distrito Capital.
FECHA DE INICIO: 2017-10-05
FECHA: 2018-10-06

AGENDA
1. INTRODUCCIÓN
1.1 OBJETIVO GENERAL:
1.2 OBJETIVOS ESPECÍFICOS
2. TÉCNICAS DE LEVANTAMIENTO DE REQUISITOS
2.1. ISO 25010
2.2. UML
2.3. MODELO DE VISTAS 4+1
2.4. VIEW AND BEYONDS
2.5. RUP
2.6. SOA REFERENCE
2.7. SCRUM
2.8. SAFE
2.10. DEVOPS
2.11. ITIL
2.12. COBIT
2.13. TOGAF
3. DIFICULTADES EN LA FASE DE LEVANTAMIENTO
4. PRINCIPIOS Y ETAPAS BÁSICAS DE JAD
5. CONCLUSIONES
6. BIBLIOGRAFÍA
3MÁSTER EN DIRECCIÓN ESTRATÉGICA EN INGENIERÍA DE SOFTWARE

CASO PRACTICO
El presente trabajo consiste en el desarrollo del caso práctico “Levantamiento de requisitos de software” de la
materia “Análisis y Diseño Integral de Sistemas y Requerimientos”.
1.1 OBJETIVO GENERAL:
Analizar el levantamiento y análisis de requerimientos de sistemas de información en las organizaciones.
1.2 OBJETIVOS ESPECÍFICOS
Desarrollar las siguientes preguntas:
● Cuáles son las principales técnicas para el levantamiento de requisitos.
● Cuáles son las principales dificultades encontradas en la fase de levantamiento de requisitos.
● Principios básicos y principales etapas de la metodología Joint Application Design (JAD).
MÁSTER EN DIRECCIÓN ESTRATÉGICA EN INGENIERÍA DE SOFTWARE 4

TÉCNICAS DE LEVANTAMIENTO DE
REQUISITOS
Existen variedad de técnicas de levantamientos de requisitos en la actualidad, estas técnicas pueden ser:
 Entrevistas: Técnica que consiste en entrevistar a los interesados del proyecto o sistema de información. Se
desarrollan previamente las preguntas a consultar y las agendas con los entrevistados, al finalizar el proceso
de entrevistas se unifican los requisitos levantados.
 Mesas de trabajo: Se convoca a los interesados del proyecto o sistemas de información, se debe contener una
agenda donde se aclare que se va hacer, cómo se va a desarrollar la reunión y cuáles son los objetivos.
 Encuestas: Se desarrollan encuestas que permitan conocer las necesidades de los interesados.
 Lluvia de ideas: esta técnica se puede usar en las mesas de trabajo, para levantar las principales ideas para el
desarrollo o proyecto.
 Analizar documentación.
 Prototipado: Consiste básicamente en desarrollar un prototipo de un sistema para que el cliente puede
hacerse a una idea de cómo será el sistema de información.
 Diseño participativo: Consiste en hacer mesas de trabajo con los interesados del proyecto o sistema de
información, donde un arquitecto o experto en diseño sea el responsable de hacer unos diseños a alto nivel y
donde todos los interesados puedan aportar sus ideas para mejorar el diseño.

TÉCNICAS DE LEVANTAMIENTO DE
REQUISITOS
Estas técnicas son usadas en marcos de referencia (Frameworks) o metodologías, no existe consenso de cómo levantar requisitos de software a nivel
mundial, sobre todo porque cada empresa es diferente y cada proyecto tiene sus peculiaridades, algunos ejemplos de estas metodologías o marcos de
trabajo son las siguientes:
● UML.
● ISO 25010.
● MODELO DE VISTAS 4+1.
● VIEW AND BEYONDS.
● RUP.
● SOA REFERENCE.
● SCRUM.
● SAFE.
● DEVOPS.
● TOGAF.
● ITIL
● COBIT.
Vamos a ver una breve descripción de algunos de los Frameworks o metodologías donde se hace referencia al levantamiento de requerimientos de
sistemas de información o aplicaciones o software, a continuación:

ISO 25010
ISO 25010 es un estándar para calidad para productos de software, la clasificación que se presenta es conocida como los requisitos funcionales y no
funcionales de los sistemas de información. A continuación se presenta la clasificación en la siguiente figura:
Figura 1 Requisitos de calidad de un producto de software. Fuente ISO 25000.
Con esta clasificación normalmente levantamos los requisitos funcionales y no funcionales en los proyectos de desarrollo de software en Colombia, es perfecta para
no perder de vista todo lo que un sistema de información debe cumplir para su correcto diseño, desarrollo e implementación en producción.

UML
Aunque UML es un lenguaje unificado de modelado para software, es tal vez la forma estándar a nivel mundial para hablar de requisitos funcionales de software
y el diseño de sus componentes. Consiste básicamente en un conjunto de diagramas, iconos y reglas para diseñar requisitos y modelos de los sistemas de
información. Los principales diagramas de UML se pueden observar en la siguiente figura:
Figura 2 Tipos de diagramas UML. Fuente Wikipedia.
Mediante los casos de uso podemos especificar los requisitos funcionales de un sistema de información, y mediante los diagramas de clases, secuencia,
colaboración, estados, actividad, objetos, componentes y distribución, podemos especificar el comportamiento y diseño de los componentes del sistema.

MODELO DE VISTAS 4+1
Es un modelo de vistas diseñado en los noventas para presentar el análisis y diseño de sistemas de información en cuatro simples vistas que son la lógica, la de
despliegue, la de procesos y la física, adicionando el +1 como requisitos funcionales o escenarios o casos de uso del sistema.
Figura 3 Modelo de vistas 4+1. Fuente Wikipedia.

VIEW AND BEYONDS
Es una metodología del SEI o Software Engineering Institute, nace por que los autores
consideran que no son suficientes cuatro vistas para documentar sistemas de información, que
se requieren tantas vistas como puntos de vista del sistema de información existan. Una vista
está compuesta por cinco elementos que son:
 Una presentación primaria que consiste en un diagrama tipo UML o de contexto, donde se
presenta la idea general del sistema.
 La descripción de todos los elementos que componen la presentación primaria.
 Un diagrama de contexto que muestra donde se encuentra la pieza o componente de
software que se está diseñando en el contexto general del sistema.
 La descripción de la variabilidad que este componente puede tomar y la justificación para
elegir dicho componente.
Esta metodología en particular a la hora de documentar requisitos funcionales y no
funcionales de los sistemas de información es mi favorita, hace el diseño más fácil y sencillo
de explicar por medio de diagramas.
A continuación se presenta una figura que ilustra lo descrito:
Figura 4 Presentación de una vista. Fuente Libro Views and Beyond.

RUP
El proceso unificado de software conceptualmente es para modelado, requerimientos, análisis y diseño, implementación, pruebas y
despliegue. Como se puede apreciar en la siguiente figura:
Figura 5 Ciclo de vida de la metodología RUP. Fuente Wikipedia.
En la gestión de requisitos o requerimientos existen dos tipos de requisitos, los funcionales y
los no funcionales. Para los requisitos funcionales se suele usar UML para especificar los
casos de uso del sistema y para los requisitos no funcionales se suele usar la categorización de
ISO 25010.
En Colombia es muy utilizada en fábricas de software en conjunto con la gestión de proyectos
PMI y CMMI. Una vez la fábrica es contratada para desarrollar el software, esta sigue la
metodología, la cual exige un grado alto de documentación y no es ágil, finalmente la fábrica
de software termina el sistema de información para el que fue contratado y pasa a producción.
Esta metodología en particular es para proyectos de implementación de un sistema de
información y presume que la gestión de requisitos de un sistema de información tiene un fin
en su fase de transición. No considera que los sistemas de información tienen un ciclo de vida
que se debe mantener como si lo consideran otras metodologías como ITIL, SOA Reference y
DevOps.

SOA REFERENCE
La arquitectura de referencia orientada por servicios fue desarrollada por IBM y donada al Open Group para el uso de la comunidad, contiene un marco
de trabajo para el ciclo de vida de los componentes y servicios de software que se desarrollan, a continuación presentamos una figura que ilustra las fases
del ciclo de vida:
Figura 6 Fases del ciclo de vida de SOA. Fuente The Open Group.
En esta metodología existe la fase de modelado, donde se levantan los requisitos
de los servicios, microservicios o componentes de software a desarrollar y
presume de una gestión continua del ciclo de vida de los sistemas de
información. SOA tiene un fuerte enfoque hacia la importancia del gobierno de
todos los componentes que forman parte de un sistema de información, tales
como sus diseños, modelos, código fuente, componentes en producción, etc.
Considerando que la base de todo son los servicios sirve para diseñar la
interoperabilidad e integración entre dos o más sistemas de información

SCRUM
Es una metodología tanto para proyecto de desarrollo de software como para proyectos de otras índoles como investigaciones o marketing. Nos
enfocaremos en su uso para desarrollo de software. Como tal es una metodología ágil, ya que se enfoca en la entrega de un producto al final de
cada Sprint, la gestión de requisitos se da después que se genera la declaración de la visión, y se presenta como un Product Backlog, que es una
lista general de requerimientos, seguidamente se seleccionan los casos más importantes en el Sprint Backlog y finalmente se hacen las historias
de usuario para que estas sean desarrolladas. Podemos observar el flujo de trabajo en la siguiente figura:
Las historias de usuario son similares a los
casos de uso de UML, pero no conllevan
tanta documentación para que el proceso
de análisis sea más ágil.
Esta metodología está de moda en
Colombia, aunque son pocas las empresas
que logran cambiar su cultura rígida por
una cultura ágil, sin tanta documentación,
auto gestionados, colaborativos, en
tiempos límites y priorizando la entrega de
valor por medio de un producto.

SAFE
Scaled Agile Framework Enterprise o SAFE, es un framework para gestión de requisitos a nivel empresarial, ya no considera como SCRUM el análisis,
diseño y desarrollo de un único sistema de información, considera toda la organización como un ecosistema que debe de planearse un portafolio de
proyectos, con diferentes programas de proyectos y equipos de trabajo SCRUM.
Gestiona los requisitos en una lista de solicitudes o Backlog al igual que SCRUM, solo que a nivel empresarial. Todas las áreas responsables como
arquitectura, recursos financieros, tesorería, etc, posteriormente estudian y analizan estos requisitos, para ser seleccionados o ser priorizados para su
posterior desarrollo. A continuación se presenta la figura que ilustra todo el ciclo SAFE:

SAFE
SAFE no es en sí un framework para gestión de requisitos, pero en el Backlog se encuentran todos los requisitos de TI de una empresa y
adicionalmente contiene todo un modelo de requisitos que demuestra una manera de expresar comportamientos de sistemas como: épicas,
capacidades, características, historias, requisitos no funcionales (NFR) y más. A continuación se presenta una figura que ilustra el metamodelo
de los objetos que componen dicho modelo:

DEVOPS
DevOps (acrónimo inglés de development -desarrollo- y operations -operaciones) es una metodología diseñada para gestionar el ciclo de vida completo de los sistemas de información
de forma cíclica, a diferencia de RUP o las metodologías en cascada, supone que un sistema de información está en continuo cambio y que estos cambios deben ser optimizados por
medio de herramientas de automatización de despliegues, repositorios de código fuente, herramientas de pruebas de carga, integración y seguridad y/o herramientas de monitoreo y
captura de alarmas. Podemos observar el ciclo de vida de los sistemas de información propuesto por DevOps en la siguiente figura:
Figura 10 DevOps Fuente Wikipedia.
DevOps considera que un sistema de información tiene el siguiente ciclo de vida: planeación, creación, verificación, empaquetado, liberación, configuración y monitoreo.
En la fase de planeación se levantas y analizan los requisitos de los sistemas de información a ser implementados y mantenidos. Los requisitos de software se podrían levantar usando
ISO 25010, UML, mesas de trabajo, entrevistas, encuestas, tormentas de ideas, etc.

Biblioteca de Infraestructura de Tecnologías de Información o ITIL,
es un conjunto de buenas prácticas para gestionar los servicios de TI en
las organizaciones, nace en los años noventa y rápidamente es uno de los
estándares favoritos de las empresas, por lo menos en Colombia.
Al aplicar continuamente ITIL en una organización, se puede percatar
que el macroproceso “Diseño del servicio”, es un proceso orientado a la
gestión de requisitos de TI, incluido por supuesto los sistemas de
información o software, solo que considera el ciclo completo de estos
requisitos y adicionalmente su parte operativa como lo son la gestión de
incidencias, resolución de problemas, seguridad, monitoreo, accesos y
eventos. Los requisitos de software en ITIL se podrían levantar usando
ISO 25010, UML, mesas de trabajo, entrevistas, encuestas, tormentas de
ideas, etc.
Consta básicamente de 5 macro procesos, con 27 procesos y 4 funciones,
que se presentan en la figura a continuación:
Figura 11 ITIL. Fuente IT Service.

COBIT es un marco de trabajo integral que ayuda a las
organizaciones a lograr la creación de valor y consecución de
objetivos estratégicos a través de principios y procesos para la
gestión y el gobierno de TI. Los procesos de COBIT se
presentan en la siguiente figura:
Como se puede apreciar en la figura, en el macroproceso de
gestión de “Construir, Adquirir e Implementar” se encuentra el
proceso “Administrar la definición de requerimientos” y
aunque se refiere a todos los requerimientos de TI de una
organización, esto incluye los requerimientos de sistemas de
información o software de la misma, los cuales se podrían
levantar usando ISO 25010, UML, mesas de trabajo,
entrevistas, encuestas, tormentas de ideas, etc.
COBIT en el proceso de “Administrar la definición de
requerimientos” hace referencia a que se debe tener un
repositorio central de requerimientos.

TOGAF
The Open Group Architecture Framework o TOGAF, es un marco de trabajo o caja de
herramientas para desarrollar arquitectura empresarial, el cual cuenta con el componente
ADM o “Metodología de desarrollo de arquitectura”, el cual es el eje central de TOGAF y
dirige todo proceso de arquitectura empresarial, a continuación se presenta la figura:
Como se puede apreciar en la figura del método ADM, el eje central se encuentra el
Requirements Manager o Administración de requerimientos, que consiste básicamente en
la gestión de requisitos que son o fueron levantados durante el ciclo ADM. Todos los
requerimientos de TI de la organización deben entrar por esta fase del método y define dos
tipos de requerimientos, los funcionales y los no funcionales. Como lo vimos
anteriormente estos se pueden levantar usando técnicas como entrevistas, encuestas,
lluvias de ideas o analizando documentación, aplicando o usando UML y clasificándolos
con ISO 25010.
Figura 13 TOGAF ADM. Fuente Open Group.

DIFICULTADES EN LA FASE DE
LEVANTAMIENTO
En el punto dos de este trabajo, pudimos apreciar que la fase de levantamiento de requisitos se puede encontrar en muchas metodologías como RUP, SOA
Reference, SCRUM, SAF, DevOps, ITIL, COBIT y TOGAF y muchas más metodologías que existen en la industria. Considero en mi experiencia que el
levantamiento de requisitos es el eje central para que una organización puede obtener el valor que espera de su área de TI. Pero son muchas las dificultades en la
fase de levantamiento, a continuación se presentan las principales dificultades que he identificado:
 Una organización que no cuenta con planeación estratégica donde tenga claramente identificados cuál es su visión y misión, con respectivas metas,
objetivos e indicadores. Esta organización solo tendrá caos en el momento de la planeación de sus proyectos de TI, ya que estos pueden o no aportar valor a la
organización, y por ende los requisitos de cada componente nuevo de TI no estará alineado al negocio.
 La falta de un repositorio central de requisitos, un repositorio donde reposen todos los requisitos de TI de la organización, que permita hacer una traza de que
a ocurrido con cada uno de ellos, cuál fue el motivo para tomar una decisión por ejemplo entre comprar un software o construirlo InHouse. Este repositorio
debe contener el histórico de todos y cada uno de los requisitos y permitir reconstruir su historia.
 Además no solo es tener el repositorio, es tener un área que alinea dichos requisitos con los objetivos estratégicos de la organización, por ejemplo un área de
arquitectura empresarial. Esta área deberá ser responsable no solo de la alineación con negocio, si no de la alineación con TI y la priorización de los mismos,
para posteriormente diseñar los proyectos que la organización requiere cumplir con sus metas y objetivos.
 Tener un proceso claro y conocido por toda la organización de cómo reportar requisitos o de TI, una forma única donde todos los interesados puedan reportar
necesidades de TI de sus respectivas áreas, dichos requisitos deberán ingresar en el repositorio central de requisitos, para ser analizados, priorizados y
clasificados.

LEVANTAMIENTO
 Para levantar requisitos no solo es usar una o más técnicas de levantamiento de requisitos, los especialistas deben conocer holísticamente la organización y el
negocio de la misma, para lograr entender qué es lo que realmente el cliente necesita y sobre todo analizar cómo estos requisitos tal vez encajen en otros
proyectos que ya se encuentran en marcha en la organización y así no cometer el error que hoy en día sufren las organizaciones cuando se trata de proyectos de TI
y es que muchas veces se adquieren sistemas de información similares en diferentes áreas y esto incrementa los costos de construcción, operación y
mantenimiento de los mismos.
 Una o más técnicas de levantamiento de requisitos de TI y técnicas de documentación de los mismos para luego almacenarlos en el repositorio, según se
defina en el proceso de administración de requisitos.
 Un estándar o método de clasificación de requisitos para que estos no se solapen con otros requisitos.
 Tener y mantener actualizado el catálogo de servicios de TI que la organización tiene, para conocer de primera mano si lo solicitado o necesitado por el negocio,
ya existe en la organización y se puede reutilizar. Como por ejemplo un servicio de gestión correo el cual usará un sistema de información para el envío de
correos.
 Tener estructurado el gobierno de TI, tanto de los activos de información, activos de software, activos de hardware y talento humano con los que la organización
cuenta. Muchas organizaciones no saben qué sistemas tienen en sus centros de datos, en ocasiones ya cuentan con sistemas que hacen lo que requieren, pero al no
haber gobierno de TI, cuando llega el requisito o la necesidad de negocio al área de TI, se opta por adquirir un nuevo componente o software.

LEVANTAMIENTO
Entonces si pensamos holísticamente, las organizaciones necesitan tener su planeación estratégica, de la cual salen los
proyectos e iniciativas de TI y son gestionadas y controladas por áreas de arquitectura empresarial, mediante procesos, por
medio de estos procesos ya sean de levantamiento o recepción de necesidades de TI, se administran los requisitos de TI, los
cuales son analizados, clasificados, priorizados, documentados y almacenados en un repositorio, para su posterior ejecución
como proyectos, pero al mismo tiempo el área de TI debe tener un catálogo de servicios gobernado, para validar que se
puede reusar en dichos proyectos.

PRINCIPIOS Y ETAPAS BÁSICAS DE JAD
Joint Application Design (JAD) es una metodología de levantamiento de requisitos para la fase de análisis y diseño de un sistema de información. Consiste básicamente en hacer sesiones
de trabajo o JAD sesiones, con los interesados del sistema de información.
Los interesados son: patrocinador ejecutivo, expertos de negocio, facilitador, usuarios, representantes de TI, analistas y observadores. Estos participan en las sesiones JAD para analizar y
diseñar los requisitos funcionales y no funcionales del sistema de información.
Como se puede apreciar esta metodología apoya la fase de análisis y levantamiento de información apalancada en la participación de los interesados del sistema de información a
desarrollar. Sus principales principios son:
 Definir los objetivos de las sesiones.
 Prepararse para las sesiones.
 Conducir las sesiones.
 Producir los documentos de las sesiones.
Las principales etapas o pasos a seguir en esta metodología son:
 Planeación y diseño: consiste básicamente en planear y diseñar el trabajo que se va a desarrollar para el levantamiento de requisitos, entre sus principales tareas se encuentran las
siguientes:
 Identificar y seleccionar los participantes en las sesiones.
 Definir las sesiones de trabajo o talleres a realizar.
 Identificar el alcance del proyecto.
 Identificar objetivos y limitaciones del proyecto.
 Identificar los factores críticos del éxito del proyecto.
 Identificar los entregables del proyecto.

 Preparación: consiste básicamente en organizar y planificar las sesiones de trabajo, entre sus principales tareas se encuentran las siguientes:
 Agendar las sesiones de trabajo con los participantes.
 Preparar los salones o salas donde se desarrollaran las sesiones.
 Aprovisionar los recursos para las sesiones, como tableros o software requeridos.
 Ejecutar: consiste básicamente en la ejecución de las sesiones de trabajo con los respectivos participantes identificados, entre sus principales tareas se encuentran las siguientes:
 Definir el alcance del proyecto.
 Definir objetivos y limitaciones del proyecto.
 Definir los factores críticos del éxito del proyecto.
 Definir los entregables del proyecto.
 Definir los requerimientos funcionales y no funcionales.
 Definir las actividades del proyecto, el cronograma y responsables.
 Finalizar:
 Documentar y firmar todos los documentos generados.
 Desarrollar una sesión de presentación del proyecto.

Entonces cómo se puede apreciar las sesiones JAD pueden generar los siguientes beneficios:
 Simplificar: Consolidar y simplificar meses de reuniones y llamadas telefónicas en unos pocos talleres estructurados.
 Identificar: Identificar y detectar los posibles objetivos, metas, alcance, recursos, agenda, problemas y participantes para el diseño de la solución.
 Cuantificar: Cuantificar o medir las necesidades de información, procesamiento, capacidad y demás requerimientos no funcionales del sistema de información.
 Aclarar: Aclarar y detallar todos los requisitos y sus restricciones y limitaciones en las sesiones de trabajo.
 Unificar: Consolidar y unificar criterios de los participantes del proyecto por medio de las sesiones de trabajo.
 Satisfacer: Cumplir o satisfacer las necesidades de los clientes del sistema de información.

CONCLUSIONES
Para análisis, diseño, desarrollo, pruebas, implementación, mantenimiento y operación de un sistema de información existen
muchas técnicas, metodologías y marcos de trabajo que incluyen el levantamiento de requisitos como lo vimos con anterioridad,
pero realmente considero que lo complejo no es levantar bien o mal los requisitos, si no gestionarlos en el tiempo.
Si todo solo se centrara en el diseño de un solo sistema en una organización, fácilmente levantamos los requisitos con entrevistas,
lluvia de ideas o analizando la documentación existente y documentando dichos requisitos con UML,ISO 25010, modelado 4+1 o
View and Beyonds, dichos requisitos guiarán el desarrollo y puesta en producción siguiendo tal vez metodologías como RUP, SOA
Reference, SCRUM o DevOps. Y para su puesta en marcha y operación en producción podríamos usar ITIL y/o COBIT. Para la
gestión de requisitos a nivel organizacional usar TOGAF o SAFE.
Realmente en una organización coexisten muchos sistemas de información y la interoperabilidad es clave para su correcta
ejecución, los requerimientos que lleguen nuevos deberían considerarse pensando en la organización como un ecosistema de
componentes, los cuales pueden prestarse servicios los unos a los otros. Por esta razón es importante tener procesos de gestión de
requisitos, repositorio de requisitos, un área responsable, metodologías claras y definidas de gestión, gobierno de los servicios de TI
y una base de datos de activos de TI.

BIBLIOGRAFÍA
 Clements, P. Bachmann, F. Bass, L. (2010). Garlan, D. Ivers, J. Little, R. Merson, P. Nord, R. Stafford, J. Documenting Software Architectures, Views and Beyond. Boston MA:
Pearson Education, Inc.
 Wikipedia. (2018). Diseño participativo. Recuperado de https://es.wikipedia.org/wiki/Dise%C3%B1o_participativo
 Wikipedia. (2018). Rational Unified Process. Recuperado de https://en.wikipedia.org/wiki/Rational_Unified_Process.
 The Open Group. (2018). Service-Oriented Architecture. Recuperado de http://www.opengroup.org/soa/source-book/soa/index.htm.
 Scrum Study. (2018). Why Scrum Study. Recuparado de https://www.scrumstudy.com/whyscrum/why-scrumstudy
 OMG®. (2018). What is UML. Recupardo de http://www.uml.org/what-is-uml.htm
 ISO 25000. (2018). ISO/IEC 25010. Recuperado de https://iso25000.com/index.php/normas-iso-25000/iso-25010
 Wikipedia. (2018). Modelo de vistas 4+1. Recuperado de https://es.wikipedia.org/wiki/Modelo_de_Vistas_de_Arquitectura_4%2B1
 Scaled Agil. (2018). What is SAFE. Recuperado de https://www.scaledagileframework.com/what-is-safe/
 Scaled Agil. (2018). SAFE Requirements Model. Recuperado de https://www.scaledagileframework.com/safe-requirements-model/
 Wikipedia. (2018). DevOps. Recuperado de https://es.wikipedia.org/wiki/DevOps
 ITIL® Foundation Gestión Servicios TI. (2018). Gestión de la demanda de los servicios de TI. Recuperado de
http://faquinones.com/gestiondeserviciosit/itilv3/diseno_servicios_TI/gestion_continuidad_servicios_ti.php
 Open Group. (2018). The TOGAF® Standard, Version 9.2 . Recuperado de http://pubs.opengroup.org/architecture/togaf9-doc/arch/index.html
 ISACA. (2018). COBIT 5 Introductions Spanish. Recuperado de https://m.isaca.org/COBIT/Documents/COBIT5-Introduction-Spanish.ppt
 Wikipedia. (2018). Joint Application Design. Recuperado de https://es.wikipedia.org/wiki/Joint_Application_Design
 University of Missouri-St. Louis. (2018). Joint Application Development (JAD). Recuperado de: https://www.umsl.edu/~sauterv/analysis/488_f01_papers/rottman.htm

GRACIAS POR SU ATENCIÓN

Caso práctico

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Caso práctico

Similar a Caso práctico (20)

Más de Valentina Roca

Más de Valentina Roca (12)

Último

Último (20)

Caso práctico