Trabajo Individual

Unidad 2: Segunda Fase - Modelamiento

Curso: INGENIERIA DE SOFTWARE - (301404A_612)

Grupo 301404_4

Tutora: Diana Judith Méndez

Juan Pablo Zapata González - Cod. 86083760

Programa de Ingeniería de Sistemas

Universidad Nacional Abierta y a Distancia UNAD

CEAD José Acevedo y Gómez
Mayo de 2019
 Contenido

Actividad individual.........................................................................................................................3
1. Propuesta de software a trabajar.........................................................................................3
2. Modelo desarrollo de software............................................................................................4
3. Explicación y justificación modelo seleccionado..................................................................4
4. Descripción de las fases del ciclo de vida y aplicación en propuesta...................................6
5. Descripción equipo de trabajo y roles..................................................................................9
6. Descripción herramientas y métodos de control...............................................................10
Bibliografía.....................................................................................................................................14
 Actividad individual

1. Propuesta de software a trabajar

La empresa de desarrollo de software Moreno & Asociados S.A.S desea realizar un software que

permita una solución para todos aquellos turistas que visitan un municipio de Colombia y por lo

general no conocen el lugar y mucho menos su historia. La aplicación funcionaría para que los

turistas puedan descargarla fácilmente. Al suscribirse tendrán toda la información de lugares,

eventos, historia y ofertas de toda clase del municipio donde se encuentre. Esta aplicación facilita

la ubicación de cada lugar y negocio que se encuentra en el municipio ofreciendo una

información detallada y precisa, tan precisa que podrá saber si en la tienda de don Chucho hay

gaseosa, o en la hostería de doña Rosa hay habitaciones disponibles, este es un ejemplo de la

información que se podría encontrar en la aplicación. Claro está, que también encontrará la

historia y la cultura del lugar, ofreciendo una experiencia placentera al visitante. El visitante

encontrará lugares que no conocía, tendrá un guía turístico en la palma de sus manos y contará

con las recomendaciones de las personas que hayan visitado esos lugares, también podrá realizar

sus compras o reservas en línea y disfrutar de los descuentos que tenga cada negocio.

Identificación del tipo de software (tipo de aplicación).

De acuerdo a los requerimientos que se están solicitando la solución informática se caracterizaría

por ser un aplicación en tiempo real ofreciendo información en todo momento y de forma

actualizada lo que permitirá al usuario estar documentado y enterado de todas las novedades

actividades y datos del lugar en el cual se encuentra o al cual piensa desplazarse esta también
puede ser una aplicación de diversos tipos pues debe permitir ejecutarse en navegadores y estar

disponible en la web para aquellos usuarios que no cuenten con un dispositivo móvil y prefieran

el uso de computadores de escritorio o portátiles.

2. Modelo desarrollo de software

SCRUM.

3. Explicación y justificación modelo seleccionado

¿Qué es?

Es una metodología ágil y flexible para gestionar el desarrollo de software, cuyo principal

objetivo es maximizar el retorno de la inversión para la empresa (ROI). Se basa en construir

primero la funcionalidad de mayor valor y en los principios de inspección continua, adaptación,

auto-gestión e innovación.

Esta metódica de trabajo promueve la innovación, motivación y compromiso del equipo que

forma parte del proyecto, por lo que los profesionales encuentran un ámbito propicio para

desarrollar sus capacidades. Se permite de igual forma en cualquier momento realinear el

software con los objetivos de negocio, ya que puede introducir cambios funcionales o de

prioridad en el inicio de cada nueva iteración sin ningún problema.

Beneficios
Cumplimento de expectativas: Se establecen expectativas indicando el valor que le aporta cada

requisito / historia del proyecto, el equipo los estima y con esta información el Product Owner

establece su prioridad. De manera regular, en las demos de Sprint el Product Owner comprueba

que efectivamente los requisitos se han cumplido y transmite feedback al equipo.

Flexibilidad a cambios: Alta capacidad de reacción ante los cambios de requerimientos

generados por necesidades o evoluciones del mercado. La metodología está diseñada para

adaptarse a los cambios de requerimientos que conllevan los proyectos complejos.

Reducción del Time to Market: Se puede empezar a utilizar las funcionalidades más importantes

del proyecto antes de que esté finalizado por completo.

Mayor calidad del software: La metódica de trabajo y la necesidad de obtener una versión

funcional después de cada iteración, ayuda a la obtención de un software de calidad superior.

Mayor productividad: Se consigue entre otras razones, gracias a la eliminación de la burocracia

y a la motivación del equipo que proporciona el hecho de que sean autónomos para organizarse.

Maximiza el retorno de la inversión (ROI): Producción de software únicamente con las

prestaciones que aportan mayor valor de negocio gracias a la priorización por retorno de

inversión.

Predicciones de tiempos: Mediante esta metodología se conoce la velocidad media del equipo

por sprint (los llamados puntos historia), con lo que consecuentemente, es posible estimar

fácilmente para cuando se dispondrá de una determinada funcionalidad que todavía está en el

Backlog.
Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de más valor en primer

lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar

riesgos eficazmente de manera anticipada.

Dentro de su simplicidad, este marco permite entregar proyectos complejos, como es el caso de

aplicativo para turistas que ofrece diferentes servicios tanto para visitantes como para

comerciantes locales; al dividir el software en módulos simples o cajas negras que a la final

conformarán el producto final se hace más simple el proceso de desarrollo.

4. Descripción de las fases del ciclo de vida y aplicación en propuesta.

Reuniones del Sprint

Se puede definir el sprint como el pulso del proyecto que a culminación de cada uno de estos
permiten el crecimiento del mismo.

Cada equipo define el sprint por un lapso de entre 2 y 4 semanas y, para el desarrollo del mismo
hará una serie de reuniones de vital importancia, estas son:

Primera Reunión Parte 1:

Definición de los requisitos a satisfacer durante este sprint, el Product Owner (Dueño de
producto-Cliente) debe estar presente para poder guiar al equipo en la dirección correcta y
responder todas las preguntas que a estas alturas suelen ser bastantes.

El Scrum Master debe asegurarse que cualquier stakeholder que maneje información de
importancia para el sprint esté presente. Cualquier ítem del backlog que se desea sea desarrollado
durante el sprint que no haya sido estimado con anterioridad será estimado de manera inmediata
durante la reunión, lo que no es una excusa para evitar la preparación del Backlog Grooming
(Revisión de las historias de usuario a introducir en el Sprint). A la culminación de esta, el
equipo se compromete con el Product Owner a cumplir con los requisitos definidos en una
estimación de tiempo que se basa en la experiencia del equipo.

Primera Reunión Parte 2:

Una vez se han sido claramente definidos los requisitos que se deben cumplir en el sprint la
segunda parte de la reunión busca entonces concretar la forma en que se desarrollará este sprint
que permite desarrollar un WorkShop de diseño en el que se especifican las tareas hasta el más
alto nivel de definición lo que termina por generar un backlog de estas plasmadas normalmente
en un tablero de tareas (Taskboard).

Reunión diaria (Daily Meeting)

Reunión con una duración estimada de 15 minutos generalmente hecha con los integrantes del
equipo de pie con el ánimo de centrar la atención en la reunión, en la que se pretende hacer la
revisión de las tareas realizadas por cada miembro durante las 24 horas anteriores, las
dificultades encontradas para la culminación exitosa de estas y la proposición de las tareas a
realizar durante las 24 horas siguientes. Es tarea del Scrum Master prestar atención a los detalles
de la ejecución de la misma, la hora de inicio, la seriedad del ejercicio, la duración de las
intervenciones, la forma centrada en que cada uno expone su parte sin demorarse en detalles
técnicos que no vienen a lugar ni en historias que no tengan que ver, así mismo asegurar que si se
presenta el Product Owner lo hace solo como observador.

Artefactos:

Product Backlog
El product Backlog, es conocido como la lista de tareas a desarrollar definidas y especificadas en
la primera reunión. Dado que se consideran los requerimientos emergentes, lo que significa que
no se conoce ni se puede conocer de antemano todas y cada una de las características que se
desea que contenga el producto, se considera el Product Backlog como un documento viviente,
que requiere una constante preparación (grooming) para mantenerlo actualizado y útil con el
paso del tiempo.

Se agregarán nuevos ítems; algunos ítems existentes serán desagregados en varios ítems más
pequeños; otros ítems serán removidos al darnos cuenta que ya no son necesarios. Es más, los
ítems deben ser estimados para conocer la relación costo beneficio de los mismos, lo que influirá
de manera directa en la ubicación que el mismo tendrá en el backlog.

Para determinar que una tarea se ha definido adecuadamente, esta debe cumplir la regla

INVEST:

Independiente: No depender de otras.

Negociable: Mientras no esté incluida dentro de un sprint, puede ser renegociada, cambiada,
ampliada veces que sean necesarias.

Valorable: Aportar valor al usuario y al negocio.

Estimable: Debe ser comprensible y estimable por los miembros del equipo.

Pequeña (S por Small): Disponer de un tamaño adecuado para poder priorizarla e incluirla dentro
de un sprint.

Testeable: Debe contar con una serie de pruebas o criterios que permitan asegurar que cumplen
objetivo.
Sprint Backlog

Es el tablero de tareas, en el que se plasman las tareas del product Backlog, para verificar el
estado en que se encuentran, en el que se identifican las columnas de Tareas por hacer, las que
están en ejecución, en prueba y las terminadas, y, en el que además se puede identificar los
cuellos de botella o represamiento de tareas.

Burndown del Sprint

El gráfico de burndown de tareas del sprint tiene por objeto ayudar al equipo en la
monitorización de su progreso y ser el indicador principal que informa las posibilidades de
alcanzar su compromiso al finalizar el sprint.

El formato clásico requiere que el equipo estime la duración de cada tarea en horas de forma
diaria. El burndown deberá completarse de forma tal que grafica cuántas horas de trabajo restan
para concluir el sprint.

Backlog de Impedimentos

El backlog de impedimentos consiste en la lista de situaciones que están impidiendo que el

equipo progrese. Estas son situaciones que el Scrum Master debe eliminar con el fin de que el
equipo trabaje de la mejor manera posible. Se debe entender que los impedimentos son de
cualquier tipo, sea cual sea la magnitud de lo que representan.

5. Descripción equipo de trabajo y roles.

Dueño del producto: ProductOwner (Johan Herley Torres Briceño)

  Único responsable de gestionar la Lista del Producto (ProductBacklog).
 Expresar claramente los elementos de la Lista del Producto
 Ordenar elementos en Lista del Producto para alcanzar los objetivos y misiones de la
mejor manera posible
 Optimizar el valor del trabajo desempeñado por el Equipo de Desarrollo
 Asegurar que la Lista del Producto es visible, transparente y clara para todos, y que
muestra aquello en lo que el equipo trabajará a continuación
 Asegurar que el Equipo de Desarrollo entiende los elementos de la Lista del Producto al
nivel necesario.

El Equipo de Desarrollo –DevelopmentTeam (Jorge Alfonso Barrera, Harold Bautista

Agudelo, Freddy Alberto Bautista)

 Entregar un Incremento de producto “Terminado”, que potencialmente se pueda poner en

producción, al final de cada Sprint.

ScrumMaster o Facilitador (Juan Zapata)

 Asegurar que Scrum es entendido y adoptado.

 Ayudar a las personas externas al Equipo Scrum a entender qué interacciones con el
Equipo Scrum pueden ser de ayuda y cuáles no.
 Ayudar a todos a modificar estas interacciones para maximizar el valor creado por el
Equipo Scrum.

6. Descripción herramientas y métodos de control.

Los tres principales artefactos o herramientas Scrum son: el Product Backlog, Sprint Backlog y

el Incremento.
Product Backlog

El Product Backlog es un inventario que contiene cualquier tipo de trabajo que haya que hacer en

el producto: requerimientos, casos de uso, tareas y dependencias. Es la principal fuente de

información sobre el producto en Scrum, una lista, en cualquier formato, que contiene todos los

requerimientos que necesitamos implementar en el producto. Esta lista es el resultado del trabajo

del Product Owner con el cliente, los distintos stakeholders, sponsors, comités, etc, y refleja el

estado real del trabajo pendiente de implementar en el producto, así como el ya realizado.

Un Product Backlog contiene distintos elementos:

 Funcionalidades

 Bugs

 Historias de usuario: una forma de expresar elementos de un Product Backlog. Para

obtener el máximo valor de una historia de usuarios es necesario expresarlas desde el

punto de vista del usuario.

 Tareas técnicas

 Trabajo de investigación

Sprint Backlog

Se trata de una lista de elementos en los que trabajar durante la etapa de Sprint. Estos elementos

normalmente se componen de tareas técnicas más pequeñas que permiten conseguir un

incremento de software terminado.

Todo el trabajo que el Development Team haya seleccionado para hacer durante el siguiente

Sprint pasa al Sprint Backlog. Su propósito es mantener la transparencia dentro del desarrollo,

actualizándolo durante toda la iteración.

Incremento

Un Incremento es el resultado del Sprint, es la suma de todas las tareas, casos de uso, historias de

usuario y cualquier elemento que se haya desarrollado durante el Sprint y que será puesto a

disposición del usuario final en forma de software, aportando un valor de negocio al producto

que se está desarrollando.

Otros artefactos

El marco de trabajo Scrum destaca los 3 elementos expuestos previamente como

imprescindibles. Sin embargo, hay otros que, a pesar de no formar parte del core, son necesario

para asegurar la calidad de la metodología Scrum.

Definition of Done (DoD): La DoD es un documento que define qué se considera hecho en un

equipo Scrum. La idea es establecer una serie de criterios comunes para especificar cuando un

ítem está completamente terminado y que aplique a todos los ítems que forman parte del

incremento.

Definition of Ready (DoR): El DoR es un documento que define cuándo un requerimiento

(historia de usuario o similar) se considera listo para que el equipo de desarrollo pueda

entenderlo, valorarlo e incluirlo en un Sprint Planning con idea de acometerlo en un Sprint.

Burndown Chart: El Burndown Chart es un gráfico de trabajo pendiente a lo largo del tiempo

que muestra la velocidad a la que se están completando los objetivos, requisitos, o historias de

usuarios. Permite extrapolar si el equipo podrá completar el trabajo en el tiempo estimado.

 Bibliografía

Weitzenfeld, A. (2005). Modelo de Proceso. En Ingeniería de Software Orientada a Objetos con

UML, Java e Internet (pp. [35]-50). Mexico City, Mexico: Cengage Learning.
Recuperado de
http://bibliotecavirtual.unad.edu.co:2619/apps/doc/CX3004300023/GVRL?
u=unad&sid=GVRL&xid=23dc4521

Weitzenfeld, A. (2005). Modelos Clásicos. En Ingeniería de Software Orientada a Objetos con

UML, Java e Internet (pp. 50-54). Mexico City, Mexico: Cengage Learning. Recuperado
de http://bibliotecavirtual.unad.edu.co:2619/apps/doc/CX3004300024/GVRL?
u=unad&sid=GVRL&xid=69d44b62

Weitzenfeld, A. (2005). Modelos Recientes. En Ingeniería de Software Orientada a Objetos con

UML, Java e Internet (pp. 54-56). Mexico City, Mexico: Cengage Learning. Recuperado
de http://bibliotecavirtual.unad.edu.co:2619/apps/doc/CX3004300025/GVRL?
u=unad&sid=GVRL&xid=8d8a7106

Schwaber, K. & Sutherland, J. (2013). La Guía definitiva de Scrum: Las reglas del juego.
Recuperado de http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-ES.pdf

Moreno, P. (Productor). (2018). Modelos del Proceso de Software [OVI]. Recuperado de

http://hdl.handle.net/10596/22472

Instituto Nacional de Tecnologías de la Comunicación. (2009). Modelos de ciclo de vida del

software. Curso de introducción a la ingeniería del software. (pp. [24]-32). Recuperado
de http://jmpovedar.files.wordpress.com/2011/08/curso-de-introduccic3b3n-a-la-
ingenieria-del-software.pdf