DESARROLLO DE

SOFTWARE
ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

NOMBRE: JUAN DE DIOS GARCÍA DE LEÓN CANTÓN

MATRICULA: ES202112497
PLAN DE ESTUDIOS: TÉCNICO SUPERIOR UNIVERSITARIO
PROGRAMA EDUCATIVO: DESARROLLO DE SOFTWARE
ASIGNATURA: ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS
GRUPO: DS-DDOO-2102-B1-005
UNIDAD 2. INTRODUCCIÓN AL ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS
ACTIVIDAD: EVIDENCIA DE APRENDIZAJE
NOMBRE DE DOCENTE: LUIS FERNANDO YOE CUETO
FECHA: SEPTIEMBRE, 2021
Análisis y Diseño Orientado a Objetos
Unidad 2. Requerimientos para el Análisis y Diseño Orientado a Objetos

Contenido
Introducción......................................................................................................................... 2
Objetivo de la Actividad:......................................................................................................2
Indicaciones de la actividad:........................................................................................2
1.- Retoma el caso de estudio desarrollado en la actividad 1 de esta unidad y explica
cómo aplicarías las fases de estandarización de la Ingeniería de Requerimientos con
base en lo siguiente:........................................................................................................2
a) Estudio de viabilidad.............................................................................................2
b) Obtención y análisis de requerimientos....................................................................3
c) Especificación de requerimientos.............................................................................3
d) Validación de requerimientos...................................................................................4
2.- Investiga en mínimo tres fuentes válidas y confiables los siguientes puntos sobre la
metodología de desarrollo de software ágil Scrum y la metodología de desarrollo de
software tradicional RUP (Rational Unified Process):......................................................4
RUP.................................................................................................................................... 4
Definición..................................................................................................................... 4
Características generales.............................................................................................5
Fases........................................................................................................................... 5
Artefactos, documentos o entregables de cada fase....................................................5
Tipos de proyectos en los que se aplica.......................................................................6
SCRUM............................................................................................................................... 7
Definición............................................................................................................................ 7
Características generales................................................................................................7
Fases.................................................................................................................................. 7
Eventos de Scrum........................................................................................................... 7
El Sprint........................................................................................................................... 7
Sprint Planning................................................................................................................ 7
Daily Scrum..................................................................................................................... 8
Sprint Review.................................................................................................................. 8
Sprint Retrospective........................................................................................................ 8
Artefactos, documentos o entregables de cada fase.......................................................8
Tipos de proyectos en los que se aplica..........................................................................9
3.- Presenta la información del punto 2 que investigaste en un organizador gráfico de tu
preferencia, puede ser una infografía o una tabla comparativa.......................................9
Infografía......................................................................................................................... 9

UNADM | DCEIT | DS | DDOO 1

Análisis y Diseño Orientado a Objetos
Unidad 2. Requerimientos para el Análisis y Diseño Orientado a Objetos

Ilustración 1 Metodología SCRUM.............................................................................10

Ilustración 2 Metodología RUP...................................................................................11
4.- Justifica cuál de las metodologías, Scrum o RUP, aplicarías para resolver el caso de
estudio........................................................................................................................... 12
Conclusiones..................................................................................................................... 12
Fuentes de consulta......................................................................................................12

Introducción
El inicio de todo producto de software es muy importante que todos los implicados tengan
muy claro lo que se necesita para llegar a la solución desea por medio de las TI, que sea
rentable para el cliente y todos los implicados en el proyecto, para esto existen las
metodologías.
Una metodología está formada por fases, cada una de las cuales se puede dividir en
subfases, que guiarán a los desarrolladores de sistemas a elegir las técnicas más
apropiadas en cada momento del proyecto y también a planificarlo, gestionarlo, controlarlo
y evaluarlo.

Objetivo de la Actividad:
El estudiante explicará el uso de la estandarización de la Ingeniería de Requerimientos a
un caso de estudio y diferenciará entre una metodología de desarrollo de software ágil y
tradicional.

Indicaciones de la actividad:

1.- Retoma el caso de estudio desarrollado en la actividad 1 de esta unidad

y explica cómo aplicarías las fases de estandarización de la Ingeniería de
Requerimientos con base en lo siguiente:

a) Estudio de viabilidad.

Los datos para el estudio de viabilidad se pueden recuperar a través de entrevistas, el tipo
de entrevista requerida está relacionado de manera directa con el problema u oportunidad
que se sugiere. Por lo general, el analista de sistemas entrevista a las personas que piden
ayuda y a las que están relacionadas en forma directa con el proceso de toma de
decisiones, que generalmente son los administradores.
(Kendall, pág. 62)
VIABILIDAD TÉCNICA: El analista debe averiguar si es posible desarrollar el nuevo
sistema teniendo en cuenta los recursos técnicos actuales.
VIABILIDAD ECONÓMICA: La viabilidad económica es la segunda parte de la
determinación de recursos. Si los costos a corto plazo no se ven eclipsados por las
ganancias a largo plazo o no producen una reducción inmediata en los costos de

UNADM | DCEIT | DS | DDOO 2

Análisis y Diseño Orientado a Objetos
Unidad 2. Requerimientos para el Análisis y Diseño Orientado a Objetos

operación, entonces el sistema no es económicamente viable y el proyecto no debe

continuar.
VIABILIDAD OPERACIONAL: La viabilidad operacional depende de los recursos
humanos disponibles para el proyecto e implica la acción de pronosticar si el sistema
funcionará y se utilizará una vez instalado.
(Kendall, pág. 63)

Antes de empezar propiamente un proyecto, habrá que detectar una necesidad en la

organización que lo encarga y elaborar un estudio de alternativas y costes para decidir si
el proyecto de desarrollo es o no la mejor opción para satisfacer las necesidades
mencionadas. Para hacerlo, habrá que anticipar el coste del proyecto ( que recursos se
deben invertir para el desarrollo) y cuánto tiempo será necesario para desarrollarlo.

¿Existe apoyo suficiente para el proyecto por parte de la administración?¿y por parte de
los usuarios? Resistencia al cambio.
¿Los métodos que actualmente se emplean en la empresa son aceptados por todos los
usuarios?
¿Con la tecnología actual se puede implementar el sistema?
¿Se tendrá que adquirir hardware nuevo?
¿La empresa ya maneja un sistema parecido o con la misma tecnología?

b) Obtención y análisis de requerimientos.

Explica qué tareas se llevan a cabo en esta fase, cuál es el resultado y por qué es
importante realizarlo para resolver el caso de estudio.

En esta etapa después de analizar la viabilidad del proyecto y decidir por parte del cliente
su realización, se deben obtener los requerimientos del sistema para esto existen varias
formas de obtener los requerimientos del sistema así como estándares de calidad en la
obtención de los requerimientos.

Se realizan entrevistas a los usuarios del sistema y se analizan sus respuestas.

La obtención de los requerimientos son una etapa muy importante al realizar un proyecto,
una clara y ordenada planificación del sistema permitirá que éste cumpla
satisfactoriamente con el objetivo para el que sea creado, es decir, que las acciones se
enfoquen en que se produzca lo que realmente se desea y sea eficaz para la
organización.

c) Especificación de requerimientos

Explica qué tareas se llevan a cabo en esta fase, cuál es el resultado y por qué es
importante realizarlo para resolver el caso de estudio.
Justifica por qué aplicar el estándar ISO/IEC 25000 o IEEE 830-1998 para
documentar la especificación de los requerimientos.

UNADM | DCEIT | DS | DDOO 3

Análisis y Diseño Orientado a Objetos
Unidad 2. Requerimientos para el Análisis y Diseño Orientado a Objetos

En esta etapa se analizan las respuestas de los entrevistados y se catalogan en

funcionales y no funcionales.
Para el caso de estudio se utilizó la entrevista con los usuarios y se aplicó el formato IEEE
830-1998.
El estándar IEEE 830-930 es un estándar muy completo y bastante entendible y muy bien
estructurado.
Este documento sirve a los desarrolladores para facilitar la comunicación entre clientes y
desarrolladores; como un contrato legal entre desarrolladores y clientes; como base para
realizar las estimaciones del proyecto en costos, tiempo y magnitud; como una
herramienta de evaluación del sistema ya terminado; y para tener una base para el control
de cambios.

d) Validación de requerimientos.

Explica qué tareas se llevan a cabo en esta fase, cuál es el resultado y por qué es
importante realizarlo para resolver el caso de estudio.
Define mínimo 5 preguntas que consideres necesarias para la validación de tus
requerimientos (básate en las preguntas ejemplo que encuentras en el archivo de
temas de la unidad).

La validación de requerimientos es un proceso muy similar al de análisis, con la diferencia

principal de que el objetivo de la validación es revisar y seleccionar aquellos
requerimientos completos que son útiles para el desarrollo del sistema.
El proceso de validación es muy importante debido a que, si existe algún error en los
requerimientos, estos pueden ocasionar costos excesivos que impacten en la
construcción del sistema.

¿El sistema cumple con lo requerido por el cliente?

¿Hay conflictos entre los requerimientos?
¿Se interpretan de una sola forma los requerimientos?
¿Es claro el uso de cada requerimiento?
¿Los requerimientos se pueden implementar con la tecnología actual?
¿El desarrollo de los requerimientos no sobre pasan el presupuesto?

2.- Investiga en mínimo tres fuentes válidas y confiables los siguientes

puntos sobre la metodología de desarrollo de software ágil Scrum y la
metodología de desarrollo de software tradicional RUP (Rational Unified
Process):

-Definición
-Características generales
-Fases
-Artefactos, documentos o entregables de cada fase
-Tipos de proyectos en los que se aplica

UNADM | DCEIT | DS | DDOO 4

Análisis y Diseño Orientado a Objetos
Unidad 2. Requerimientos para el Análisis y Diseño Orientado a Objetos

RUP
Definición

El Proceso Unificado de Desarrollo de Software (PUD) fue creado por Jacobson, Booch
y Rumbaugh. Este proceso se deriva de metodologías anteriores desarrolladas por estos
tres autores, a saber, la metodología Objectory de Jacobson, la metodología de Booch y
la técnica de modelado de objetos de Rumbaugh.

El RUP nació del UML (Unified Modeling Language) y del UP (Sommerville, 2005).

Características generales

El PUD es un proceso evolutivo y se desarrolla a través de una serie de ciclos que

constituyen la vida de un sistema y se concluyen con una versión del producto, desde su
inicio hasta su muerte. Cada ciclo consta de cuatro fases: inicio, elaboración, construcción
y transición. Las fases se dividen en un conjunto de iteraciones, en las que se desarrollan
los flujos de trabajo: requerimientos, análisis, diseño, implementación y pruebas.

El RUP es un proceso basado en los modelos en Cascada y por Componentes, el cual

presenta las siguientes características: Es dirigido por los casos de uso, es centrado en la
arquitectura, iterativo e incremental (Booch, Rumbaugh y Jacobson, 2000), lo cual es
fundamental para el proceso de desarrollo de software.

Fases

 Inicio, el objetivo en esta etapa es determinar la visión del proyecto.

 Elaboración, en esta etapa el objetivo es determinar la arquitectura óptima.
 Construcción, en esta etapa el objetivo es obtener la capacidad operacional
inicial.
 Transición, el objetivo es llegar a obtener el release (versión terminada y estable
de una aplicación informática) del proyecto.

Al final de cada una de las etapas del Proceso Unificado se debe entregar un
producto importante (hito): Al final del inicio: se entregan los objetivos y definición del
alcance del proyecto. Al final de la elaboración: se entrega la arquitectura del sistema.
En cada iteración de la construcción: se entrega un producto con la función anterior más
el incremento correspondiente a la nueva iteración, de tal forma que al final de la
construcción se obtiene la versión inicial del sistema con capacidad operacional, es
decir, con toda la funcionalidad requerida. Al final de la transición: se entrega el producto
completamente funcional.

Artefactos, documentos o entregables de cada fase

UNADM | DCEIT | DS | DDOO 5

Análisis y Diseño Orientado a Objetos
Unidad 2. Requerimientos para el Análisis y Diseño Orientado a Objetos

Artefactos: También denominado producto, es un modelo de información que es

producido o modificado durante el proceso de desarrollo de software. Los artefactos son
los resultados tangibles del proyecto, las cosas que se van creando y usando hasta tener
el producto software terminado. Algunos artefactos pueden ser: un modelo de casos de
uso, el documento de la arquitectura, etc.

Modelamiento del negocio

 Describir los procesos del negocio.
 Definir el modelo del dominio.
 Establecer el glosario de términos.

Requerimientos
 Definir actores.
 Determinar lista preliminar de casos de uso.
 Depurar casos de uso.
 Modelo de casos de uso.
 Documentar.

Análisis
 Diagramas de secuencia
 Diagramas de colaboración.
 Diagramas de actividad.
 Diagramas de estado.
 Modelo de análisis.

Diseño
 Lista inicial de objetos.
 Definir responsabilidades.
 Definir colaboraciones.
 Modelo de diseño.
 Modelo objeto relacional.
 Diccionario de datos.
 Diagrama de despliegue.
 Descripción de la arquitectura.
 Implementación.

Pruebas
 Modelo de pruebas.
 Pruebas individuales.
 Pruebas del sistema.

Tipos de proyectos en los que se aplica

UNADM | DCEIT | DS | DDOO 6

Análisis y Diseño Orientado a Objetos
Unidad 2. Requerimientos para el Análisis y Diseño Orientado a Objetos

Por sus características se implementa con mayor frecuencia en proyecto de gran

complejidad y magnitud, que dispongan de un equipo de trabajo con experiencia en
desarrollo de proyectos, así como con un alto conocimiento en la metodología, sin dejar
de lado su aplicabilidad en proyectos de corto tiempo y poca complejidad, pues la
metodología tiene la capacidad de poder adaptarse a los diferentes tipos de proyecto
software.

SCRUM
Definición
SCRUM es un marco de trabajo basado en los métodos ágiles, que tiene como objetivo el
control continuo sobre el estado actual del software, en el cual el cliente establece las
prioridades y el equipo SCRUM se auto-organiza para determinar la mejor forma de
entregar resultados (Abrahamsson, Salo, Ronkainen y Warsta, 2002).
SCRUM fue desarrollado en 1986 por Hirotaka Takeuchi e Ikujiro Nonaka quienes
describieron una nueva aproximación metodológica que incrementa la rapidez y la
flexibilidad en el desarrollo de nuevos productos comerciales.
Scrum es un marco de trabajo liviano que ayuda a las personas, equipos y
organizaciones a generar valor a través de soluciones adaptativas para problemas
complejos.
(Schwaber, Sutherland, 2020).

Características generales

El enfoque SCRUM propone el software funcional sobre la excesiva documentación, a

diferencia de RUP el cual es estricto en documentación. Se presenta al cliente las
soluciones operables y no solo reportes de progresos, de esta forma el cliente puede
decidir avanzar o parar, en otros enfoques solo se ven resultados al final.
De igual forma, SCRUM promueve la colaboración con el cliente en lugar de rígida
negociación de contratos. Por lo cual, es importante tener capacidad de respuesta para
los cambios en lugar de seguir estrictamente una planificación, partiendo del principio que
el proyecto software es cambiante. El propósito es que el cliente vaya observando los
resultados, pueda decidir cambios en la marcha o incluso darle un giro completo al
proyecto.

Fases

Eventos de Scrum
El Sprint es un contenedor para todos los demás eventos.

El Sprint
Los Sprints son el corazón de Scrum, donde las ideas se convierten en valor.
Son eventos de duración fija de un mes o menos para crear consistencia.

UNADM | DCEIT | DS | DDOO 7

Análisis y Diseño Orientado a Objetos
Unidad 2. Requerimientos para el Análisis y Diseño Orientado a Objetos

Un nuevo Sprint comienza inmediatamente después de la conclusión del Sprint anterior.

Todo el trabajo necesario para lograr el Objetivo del Producto, incluido la Sprint
Planning, Daily Scrums, Sprint Review y Sprint Retrospective, ocurre dentro de los
Sprints.

Sprint Planning
La Sprint Planning inicia el Sprint al establecer el trabajo que se realizará para el Sprint.
El Scrum Team crea este plan resultante mediante trabajo colaborativo.
El Product Owner se asegura de que los asistentes estén preparados para discutir los
elementos más importantes del Product Backlog y cómo se relacionan con el Objetivo
del Producto.

Daily Scrum
El propósito de la Daily Scrum es inspeccionar el progreso hacia el Objetivo del Sprint y
adaptar el Sprint Backlog según sea necesario, ajustando el trabajo planificado entrante.
La Daily Scrum es un evento de 15 minutos para los Developers del Scrum Team. Para
reducir la complejidad, se lleva a cabo a la misma hora y en el mismo lugar todos los días
hábiles del Sprint. Si el Product Owner o Scrum Master están trabajando activamente
en elementos del Sprint Backlog, participan como Developers.

La reunión está dirigida por el SCRUM Manager y sólo puede intervenir el Equipo
SCRUM. Éste hace las siguientes preguntas a cada miembro del equipo:
¿Qué hiciste ayer?
¿Cuál es el trabajo para hoy?
¿Qué necesitas?

Sprint Review
El propósito de la Sprint Review es inspeccionar el resultado del Sprint y determinar
futuras
adaptaciones. El Scrum Team presenta los resultados de su trabajo a los interesados
clave y se discute el progreso hacia el Objetivo del Producto.
La Sprint Review es el penúltimo evento del Sprint y tiene un límite de tiempo de máximo
cuatro horas para un Sprint de un mes. Para Sprints más cortos, el evento suele ser de
menor duración.

Sprint Retrospective
El propósito de la Sprint Retrospective es planificar formas de aumentar la calidad y la
efectividad.
El Scrum Team inspecciona cómo fue el último Sprint con respecto a las personas, las
interacciones, los procesos, las herramientas y su Definición de Terminado.
(Schwaber, Sutherland, 2020).

UNADM | DCEIT | DS | DDOO 8

Análisis y Diseño Orientado a Objetos
Unidad 2. Requerimientos para el Análisis y Diseño Orientado a Objetos

Artefactos, documentos o entregables de cada fase

Artefactos de Scrum
Los artefactos de Scrum representan trabajo o valor. Están diseñados para maximizar la
transparencia de la información clave. Por lo tanto, todas las personas que los
inspeccionan tienen la misma base de adaptación.
Cada artefacto contiene un compromiso para garantizar que proporcione información que
mejore la transparencia y el enfoque frente al cual se pueda medir el progreso:

● Para el Product Backlog, es el Objetivo del Producto.

● Para el Sprint Backlog, es el Objetivo del Sprint.
● Para el Increment es la Definición de Terminado.

Estos compromisos existen para reforzar el empirismo y los valores de Scrum para el
Scrum Team y sus interesados.
(Schwaber, Sutherland, 2020).

SCRUM produce los siguientes tres artefactos:

Pila del producto: Es el corazón de SCRUM, es la relación de requisitos del producto, en
la cual no es necesario excesivo detalle pero sí deben estar priorizados. Ésta lista o pila
del producto está en constante evolución y abierta a todos los roles, pero es el propietario
del producto el responsable y quien decide sobre esta.

Pila del SPRINT: Son los requisitos comprometidos por el equipo para el Sprint, se
construyen con el nivel de detalle suficiente para lograr su ejecución por el equipo de
trabajo.

Incremento: Es una parte del producto desarrollado en un Sprint, y que es factible de ser
usado, contiene las pruebas, una codificación limpia y documentada.
(Pérez A. UNIMINUTO, 2011).

Tipos de proyectos en los que se aplica

Según estudios recientes, las metodologías ágiles tienen una gran aceptación en la
industria del software (West & Grant, 2010), sin embargo, según sus fundadores, éstas
sólo son aplicables cuando se dan las siguientes condiciones (Fowler, 2000):

• Proyectos pequeños y equipos con menos de 100 personas.

• Requerimientos cambiantes.
• Equipo de desarrollo competente.
• Cliente dispuesto a participar con el equipo.

3.- Presenta la información del punto 2 que investigaste en un organizador

gráfico de tu preferencia, puede ser una infografía o una tabla comparativa.

UNADM | DCEIT | DS | DDOO 9

Análisis y Diseño Orientado a Objetos
Unidad 2. Requerimientos para el Análisis y Diseño Orientado a Objetos

Infografía

https://www.canva.com/design/DAEoziZTMxo/JjbE4bcvXHb-a0B8VJYCmg/view?
utm_content=DAEoziZTMxo&utm_campaign=designshare&utm_medium=link&utm_sourc
e=sharebutton

UNADM | DCEIT | DS | DDOO 10

Análisis y Diseño Orientado a Objetos
Unidad 2. Requerimientos para el Análisis y Diseño Orientado a Objetos

Ilustración 1 Metodología SCRUM

UNADM | DCEIT | DS | DDOO 11

Análisis y Diseño Orientado a Objetos
Unidad 2. Requerimientos para el Análisis y Diseño Orientado a Objetos

Ilustración 2 Metodología RUP

UNADM | DCEIT | DS | DDOO 12

 Análisis y Diseño Orientado a Objetos
Unidad 2. Requerimientos para el Análisis y Diseño Orientado a Objetos

4.- Justifica cuál de las metodologías, Scrum o RUP, aplicarías para

resolver el caso de estudio.

Elegiría la metodología SCRUM ya que tiene un gran control a los cambios imprevistos y
tomando en cuenta el caso de estudio sería una gran opción para estar haciendo entregas
parciales y poder dar una solución totalmente acorde a lo requerido por el cliente.

Conclusiones
En todo desarrollo de un producto de software es muy importante llevar un estudio de
viabilidad, así como la obtención de requerimientos para después llevar toda la
metodología elegida para el desarrollo del producto de software.
Para aumentar las probabilidades de éxito de los proyectos de software es necesario
hacer un esfuerzo adicional en su inicio. Considero que la elección de un modelo de
desarrollo adecuado es un aspecto clave para iniciar un proyecto de software
correctamente, ya que un modelo que no se adapte al proyecto entorpece su desarrollo.

Fuentes de consulta

Gutiérrez, D. (2011). Métodos de desarrollo de software. Caracas: Universidad de los Andes.

Pérez A. (2011). Cuatro enfoques metodológicos para el desarrollo de software. Revista

académica uniminuto.
https://core.ac.uk/download/pdf/230219821.pdf

Schwaber, K. & Sutherland, J. (2020). La guía de Scrum.

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Spanish-Latin-South-
American.pdf

Qué es SCRUM. (2008, agosto 4). Proyectos Ágiles. https://proyectosagiles.org/que-es-scrum/

Home. (s. f.). Scrum.Org. Recuperado 4 de septiembre de 2021, de

https://www.scrum.org/index

Unidad 3—Rational Unified Process. (s. f.). Recuperado 4 de septiembre de 2021, de

http://cidecame.uaeh.edu.mx/lcc/mapa/PROYECTO/libro10/unidad_3__rational_unified_pr

ocess.html

UNADM | DCEIT | DS | DDOO 13