Protocolo Colaborativo - Metodologia para Desarrollo de Software U2

Asignatura Datos del CIPA Fecha
Nombre CIPA:
Integrantes: HOWAR DAVID IBAÑEZ
METODOLOGIA MARTINEZ, SERGIO LUIS TORRES LADEUTH,
PARA DESARROLLO ANDRES ENRIQUE ESCOBAR QUINTERO, ELKIN 28/04/2023
DE SOFTWARE ALBERTO MONSALVE PACHECO, ISRAEL
ALVAREZ RUIZ, JORGE IVAN CAUSADO
MADERA
Actividad
Protocolo colaborativo de la unidad n°: 2
Análisis y síntesis:
Síntesis e interpretación colaborativa de los temas vistos en la unidad
Los temas de los cuales se trata esta síntesis son MODELO CICLO DE VIDA
PRODUCTO O PROYECTO DE SOFTWARE PROPUESTO POR BOHEM EN 1987,
FASES DE RUP, SCRUM, DOCUMENTOS METODOLOGÍA SCRUM, ROLES
SCRUM (PRODUCT OWNER, SCRUM MASTER, CLIENTE), PROYECTO: WEB,
MÓVIL, PRODUCT BACKLOG, PÓKER, SPRINT BACKLOG, TABLERO, KANBAN,
MOCKUP Y BALSAMIQ.
MODELO CICLO DE VIDA PRODUCTO O PROYECTO DE SOFTWARE

PROPUESTO POR BOHEM EN 1987
El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez
por Barry Boehm en 1986, utilizado generalmente en la ingeniería de software.
Las actividades de este modelo consistes en la confirmación en un espiral, en la que cada

bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a
ninguna prioridad, sino que las siguientes se eligen en función del análisis de riesgo,
comenzando por el bucle interior.
La ingeniería de software se vale y establece a partir de una serie de modelos que

establecen y muestran las distintas etapas y estados por los que pasa un producto software,
desde su concepción inicial, pasando por su desarrollo, puesta en marcha y posterior
mantenimiento, hasta la retirada del producto. A estos modelos se les denomina «modelos
de ciclo de vida del software». El primer modelo concebido fue el de Royce, más
comúnmente conocido como desarrollo en cascada o desarrollo lineal secuencial. Este
modelo establece que las diversas actividades que se van realizando al desarrollar un
producto software suceden de forma lineal.
Boehm, autor de diversos artículos de ingeniería del software; modelos de estimación de
esfuerzo y tiempo que se consume en hacer productos software; y Modelos de Ciclo de
Vida; ideó y promulgó un modelo desde un enfoque distinto al tradicional en Cascada: El
Modelo Evolutivo Espiral. Su Modelo de Ciclo de Vida en Espiral tiene en cuenta
fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza
mirando las posibles alternativas de desarrollo, se opta por la de riesgo más asumible y se
hace un ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se
vuelve a evaluar las distintas nuevas alternativas y riesgos y se realiza otra vuelta de la
Nombre CIPA:
MADERA
espiral, así hasta que llegue un momento en el que el producto software desarrollado sea
aceptado y no necesite seguir mejorándose con otro nuevo ciclo.
Este modelo fue propuesto por Boehm en 1986 en su artículo «A Spiral Model of Software
Development and Enhancement». En 1988, Boehm publicó un artículo similar destinado a
una audiencia más amplia. Básicamente consiste en una serie de ciclos que se repiten en
forma de espiral, comenzando desde el centro. Se suele interpretar como que dentro de cada
ciclo de la espiral se sigue un Modelo Cascada, pero no necesariamente debe ser así. El
Espiral puede verse como un modelo evolutivo que conjuga la naturaleza iterativa del
modelo MCP con los aspectos controlados y sistemáticos del Modelo Cascada, con el
agregado de gestión de riesgo.
FASES RUP
La estructura dinámica del RUP permite que el proceso de desarrollo se fundamentalmente

iterativo en las cuatro fases.
1. Fase de inicio: (se define el alcance del proyecto)
Se define el alcance del proyecto con los clientes, se identifican los riesgos asociados al
proyecto, se elabora el plan de las fases y el de la iteración posterior, se detalla de manera
general la arquitectura del software.
2. Fase de Elaboración: (Definición, análisis y diseño)
Se diseña la solución preliminar, se selecciona los casos de uso que permiten definir la
arquitectura base del sistema y se desarrollara el primer análisis del dominio del problema.
3. Fase de desarrollo o construcción: (implementación)
La función de esta fase es completar la funcionalidad del sistema, se clarifican los
requisitos pendientes, se administran los cambios de acuerdo a las evaluaciones realizadas
por los usuarios, y se realizan las mejoras para el proyecto.
4. Fase de transición: (fin del proyecto y pruebas)
Fase de cierre, el propósito es asegurar que le software esté disponible para los usuarios
finales, se ajustan los errores y defectos encontrados en las pruebas de aceptación, se
capacitan a los usuarios y se provee el soporte necesario.
Planear las 4 fases incluye: Asignación de tiempo, Hitos Principales, Iteraciones por Fases,
Plan de proyecto.
 Disciplinas a realizar en cada una de las fases

 Proceso
Nombre CIPA:
MADERA
 Modelado de negocio
 Requisitos
 Análisis y diseño
 Implementación
 Pruebas
 Despliegue
 Soporte
 Gestión de cambio y configuraciones
 Gestión del proyecto
 Entorno
Cada fase en RUP puede des componerse en iteraciones. Una iteración es un ciclo de
desarrollo completo dando como resultado una entrega de producto ejecutable (interna o
Nombre CIPA:
MADERA
externa)
El proceso define una serie de roles:
Los roles se distribuyen entre los miembros del proyecto y que definen las tareas de cada
uno y el resultado (artefactos) que se espera de ellos. Todos los miembros del equipo
comparten:
 Base de conocimiento
 Proceso
 Vista de cómo desarrollar software
 Lenguaje de modelamiento (UML)
Los procesos deberán adaptarse a las necesidades del cliente ya que es muy importante
interactuar con él, las características propias del proyecto, el tamaño del mismo, así como
su tipo o las regulaciones que lo condicionen, influirán en su diseño específico, También se
deberá tener en cuenta el alcance del proyecto en un área subnormal.
SCRUM
Scrum es un marco de gestión de proyectos de metodología ágil que ayuda a los equipos a
estructurar y gestionar el trabajo mediante un conjunto de valores, principios y prácticas. Al
igual que un equipo de rugby (de donde proviene su nombre) cuando entrena para un gran
partido, scrum anima a los equipos a aprender a través de las experiencias, a
autoorganizarse mientras aborda un problema y a reflexionar sobre sus victorias y derrotas
para mejorar continuamente.
Aunque son los equipos de desarrollo de software los que utilizan con mayor frecuencia
este tipo de scrum, sus principios y lecciones se pueden aplicar a todo tipo de trabajo en
equipo. Esta es una de las razones por las que es tan popular. Aunque se considera a
menudo un marco de gestión de proyectos ágil, scrum incluye un conjunto de reuniones,
herramientas y funciones que, de forma coordinada, ayudan a los equipos a estructurar y
gestionar su trabajo.
DOCUMENTOS DEL SCRUM
Product backlog
El product backlog es un documento de alto nivel para todo el proyecto. Contiene
descripciones genéricas de todos los requerimientos, funcionalidades deseables, etc.
priorizadas según su valor para el negocio (business value). Es el qué va a ser construido.
Nombre CIPA:
MADERA
Es abierto y cualquiera puede modificarlo.

Sprint backlog
El sprint backlog es un documento detallado donde se describe el cómo el equipo va a
implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas con
ninguna tarea de duración superior a 16 horas. Si una tarea es mayor de 16 horas, deberá ser
rota en mayor detalle. Las tareas en el sprint backlog nunca son asignadas, son tomadas por
los miembros del equipo del modo que les parezca oportuno.
Burn down
La burn down chart es una gráfica mostrada públicamente que mide la cantidad de
requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando
una línea que conecte los puntos de todos los Sprints completados, podremos ver el
progreso del proyecto. Lo normal es que esta línea sea descendente, hasta llegar al eje
horizontal, momento en el cual el proyecto se ha terminado.
ROLES SCRUM (PRODUCT OWNER, SCRUM MASTER, CLIENTE)
1.- Product Owner (Dueño del Producto)

Tiene la responsabilidad de decidir qué trabajo necesita hacerse y maximizar el valor del
producto o proyecto que esté llevando a cabo. Esto, que se expresa fácilmente, pero
realmente es una tarea que conlleva lo siguiente:
Nombre CIPA:
MADERA
 Gestiona prioridades.- El Product Owner tiene la responsabilidad de gestionar los

presupuestos, de contratar al equipo de desarrollo y de explicar cuál es el valor que
produce el producto en el que está invirtiendo.
o Representante del negocio.- Cuando es alguien de negocio, aportará valor a su
trabajo al producto dependiendo de al menos dos variables. La primera es la
capacidad de decisión que tiene. En ocasiones, es normal que el Product Owner no
pueda realmente tomar decisiones sin consultar con otra persona. En ese caso, no es
un Product Owner real y debe, o de ser sustituido por la persona que toma las
decisiones, o tomarlas por el mismo.
 Intraemprendedor. En esta el Product Owner aporta valor al negocio. En esta faceta
es un Product Manager ágil, capaz de medir el valor generado y utilizar la
flexibilidad de entregar cada Sprint para incrementar ese valor.
2.- El Scrum Master
Actúa como un líder servicial, ayudando al equipo y a la organización a usar lo mejor
posible la Metodología Scrum, se focaliza en la parte de negocio y es responsable del ROI
del proyecto. Traslada la visión del proyecto al equipo, formaliza las prestaciones en
historias a incorporar en el Product Backlog y las prioriza de forma regular.
3.- Team (Equipo de Desarrollo)
Grupo de profesionales con los conocimientos técnicos necesarios y que desarrollan el
proyecto de manera conjunta llevando a cabo las historias a las que se comprometen al
inicio de cada sprint. Sprint es una serie de periodos de tiempos pequeños, cuya duración es
de 1 a 4 semanas, con preferencia por los intervalos más cortos. En cada Sprint, el equipo
construye y entrega un incremento del producto. Cada incremento es un subconjunto del
producto, reconocible y visualmente mejorado, que cumple con el criterio de aceptación y
está construido con un nivel de calidad llamado definición de terminado.
Estos tres roles de Scrum se requieren para crear el producto del proyecto, son los
responsables del éxito de cada sprint y del proyecto en su totalidad.
PROYECTO: WEB, MOVIL
La Web móvil es la misma Web que la de escritorio, utiliza la misma arquitectura básica y
muchas de las mismas tecnologías. Pero existen claras diferencias que impiden que su
funcionamiento y manejo sea el mismo, como son: el tamaño de la pantalla, las diferentes
formas de uso (táctil, teclado del móvil, etc.) y el ancho de banda.
Otra diferencia que se debería de tener en cuenta es que es "móvil". Accedemos a Internet
desde lugares en los que sería imposible hacerlo con un ordenador de sobremesa o incluso
un portátil. Esto influye también en el uso que le damos, se hacen más búsquedas o
Nombre CIPA:
MADERA
consultas, además de que la información se debe de disponer de forma más clara y directa.
Debido a todo esto, al programar una Web para móvil debemos de tener en cuenta que ni el
contenido, ni la apariencia, ni la estructura de la web va a ser la misma que la que
podríamos hacer para un ordenador de escritorio. Hemos de diseñar muy bien este tipo de
aplicaciones y orientarlas al uso principal que le va a dar el usuario. Para esto se suele
referir a la regla del 20%: el 80% del contenido del sitio web de escritorio no es válido para
una web móvil.
PRODUCT BACKLOG
El product backlog es una lista de funciones y elementos, ordenados según las prioridades,
que son necesarios para cumplir con los objetivos y las expectativas del proyecto. La regla
general es desarrollar uno de estos conjuntos de trabajo pendiente del producto para cada
producto y asignarle a un equipo ese trabajo pendiente en particular.
A veces, hay muchos conjuntos de product backlogs y varios equipos que trabajan en un
solo producto más amplio. Tomemos el ejemplo de Adobe Creative Cloud. Adobe Creative
Cloud es un producto que abarca a muchos otros de menor tamaño como Photoshop,
Ilustrador y After Effects. Cada uno de estos productos no tan grandes tendrían su propio
product backlog y diferentes equipos designados para su desarrollo.
Los equipos que trabajan con metodologías ágiles dedican tiempo a crear productos y a
hacer ajustes a medida que los proyectos avanzan. Dada la naturaleza de las metodologías
ágiles, sabemos que las tareas del product backlog no son definitivas e inamovibles y que
no todos los elementos se podrán finalizar. El equipo de Desarrollo deberá readaptar el
trabajo pendiente del producto a medida que se prioricen las tareas necesarias.
Nombre CIPA:
MADERA
PÓKER
Planning Poker es una técnica para calcular una estimación basada en el consenso, en su
mayoría utilizada para estimar el esfuerzo o el tamaño relativo de las tareas de desarrollo de
software. Es una variación del método Wideband Delphi. Es utilizado comúnmente en el
desarrollo ágil de software, en particular en la metodología Extreme Programming.
El método fue descrito por primera vez por James Grenning en 2002 y más tarde se
volvería más popular y comercial por Mike Cohn con el libro Agile Estimating and
Planning.
El planning poker, está basado en una lista de características que deben ser estimadas y una
baraja de cartas por cada participante. La lista de características, por lo general una lista de
historias de usuario, describe el software que se va a desarrollar.
Las cartas en el mazo están numeradas. Un mazo típico contiene tarjetas con sucesivos
términos de la sucesión de Fibonacci incluyendo un cero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89;
a razón de reflejar la incertidumbre inherente en la estimación en el proyecto. Otros mazos
utilizan progresiones similares.
Un mazo que se encuentra en el mercado utiliza la siguiente secuencia: 0, ½, 1, 2, 3, 5, 8,

13, 20, 40, 100 y además, dos tarjetas: una con signo de interrogación (?) y otra con signo
de infinito (∞). Ambas pueden ser usadas para declarar completa incertidumbre o
desconocimiento de la característica. También puede existir una carta con el dibujo de una
taza de café que puede usarse para indicar que un participante está demasiado cansado para
continuar y necesita un descanso.
SPRINT BACKLOG
El sprint backlog es básicamente una lista de tareas identificadas por el scrum team; ésta
deberá ser completada durante cada sprint.
El sprint backlog es representado a través de un tablero de tareas; hace visible todo el
trabajo necesario para alcanzar el compromiso que se hizo con el product owner para el
sprint. Permite ver las tareas donde el equipo está teniendo problemas y no avanza, para
tomar decisiones al respecto.
Para cada uno de los objetivos/requisitos del proyecto se muestran las tareas a cubrir; el
esfuerzo pendiente para finalizarlas y la auto asignación que han hecho los miembros del
equipo, también son visibles.
La práctica habitual es gestionar el sprint backlog mediante un tablero con post its. Al lado
de cada objetivo se colocan las tareas necesarias para completarlo y se van moviendo para
cambiarlas de estado. Pendiente, en progreso, hechas.
Nombre CIPA:
MADERA
Para cada miembro del equipo se puede utilizar adhesivos de colores más pequeños sobre
cada tarea, de manera que se pueda ver en qué tareas está trabajando cada cual.
Este tablero o cuadro de mandos actúa como radiador de información tanto para el equipo
como para cualquier otra persona relacionada con el proyecto.
Actualmente, existen incluso servicios digitales para la creación de tableros para
seguimiento de tareas; sin embargo, si se quieres tener el control integral de la gestión de
proyectos, en Integra IT desarrollamos proyectos de software gestionados con SCRUM.
TABLERO KANBAN
Un tablero de kanban es una herramienta ágil de gestión de proyectos diseñada para ayudar
a visualizar el trabajo, limitar el trabajo en curso y maximizar la eficiencia (o el flujo).
Puede ayudar tanto a los equipos ágiles como a los de DevOps a definir el orden de su
Nombre CIPA:
MADERA
trabajo diario. Los tableros de kanban utilizan tarjetas, columnas y la mejora continua para
ayudar a los equipos tecnológicos y de servicios a comprometerse con la cantidad de
trabajo adecuada y, por supuesto, a llevarla a cabo.
"Kanban" es una palabra japonesa que significa "señal visual". Si trabajas en el ámbito de
los servicios o de la tecnología, tu trabajo suele ser invisible e intangible. Un tablero de
kanban ayuda a visibilizar tu trabajo para que puedas mostrárselo a los demás y que todo el
mundo trabaje en sintonía.
Kanban ha recorrido un largo camino desde sus orígenes en el ámbito de la producción lean
gracias a un pequeño pero mañoso grupo de entusiastas del kanban. El trabajo de David
Anderson para definir el método kanban ayudó a llevar el kanban al dominio del software y
los servicios; y Personal Kanban, de Jim Benson y Tonianne DeMaria, ha contribuido a
extender las aplicaciones de kanban a ámbitos que ni te imaginarías.
MOCKUP
Para desarrollar una aplicación es necesario pensar en todas las partes y elementos que le
Nombre CIPA:
MADERA
presentaremos al usuario para que este sienta que, con la UI que le estamos presentando,
puede tener una buena UX. Por ello, en este post, te hablaremos sobre qué es un mockup y
por qué es importante al momento de realizar un diseño.
Un mockup, también llamado wireframe, es un esquema que realizamos de un diseño
gráfico o un diseño web que representa la idea de una aplicación que nosotros tenemos o
que un cliente quiere implementar.
Esto significa que es un diseño base o un boceto que se realiza a partir de unas premisas. Es
decir, es necesario que pienses en cuáles son las necesidades del cliente, cuáles van a ser los
pasos que tendrá que dar el usuario para navegar en esta aplicación y cuál es el tipo de
pantalla al que está destinado este diseño.
Es importante resaltar que no es obligatorio realizar un mockup por medio de un programa
de edición de imágenes como Adobe Photoshop, sino que también existe la posibilidad de
organizar esas ideas en papel. Todo esto depende de la comodidad del diseñador.
¿Por qué es importante un mockup?
Este esquema no siempre se cumple en su totalidad, sino que es una forma de representar
las ideas del cliente y presentarle un posible diseño que abarca todas sus necesidades y, a su
vez, piensa en el usuario.
Realizar un mockup es importante por qué te servirá para ver todos los errores que presenta
o pueden presentarse en tu aplicación. Además, puede ayudarte a ahorrar tiempo cuando
llegue el momento de diseñar.
BALSAMIQ
Balsamiq Mockups permite a los diseñadores y desarrolladores de software construir un

gran software al permitir esbozar fácilmente las ideas, luego colaborar rápidamente e iterar
sobre ellas.
Mockups ofrece la misma velocidad y sensación áspera como dibujar con un lápiz, pero
con la ventaja del medio digital: agrandar contenedores es solo una operación de arrastre,
no es necesario volver a empezar al reorganizar los elementos y tus wireframes serán lo
suficientemente claros como para que puedan tener sentido en el futuro.
Una de las mejores herramientas para crear prototipos, bocetos o wireframes es Balsamiq
Mockups. Este programa tiene varias ventajas:
 Es un programa de escritorio, es decir, solo tienes que registrarte para poder
empezar a utilizarlo sin ningún tipo de descarga.
o Programado en Flex y AIR por lo que crea muy rápido Wireframes.
 Interfaz fácil de usar: como se ha creado con AIR es instalable tanto en Windows
como Linux y Mac OS X.
Nombre CIPA:
MADERA
o Te permite escoger entre un montón de objetos prediseñados como: barras de

estado, menús, barras de progreso, etc. Además, te permite exportar el diseño que
realices en PNG, PDF e incluso al portapapeles.
 Permite incrustar tus diseños en tu página web o en informes de errores. Puedes
compartir tus diseños a través de un sistema muy parecido a Dropbox. Balsamiq
funciona como cualquier aplicación normal, te permite arrastrar, soltar, guardar
mockups en un archivo, copiar y pegar, deshacer, etc.
Bueno hasta Aquí llega Nuestra Síntesis. Muchas Gracias Por La Observación.
Discusión:
Dudas, desacuerdos, discusiones
Nombre CIPA:
MADERA

Protocolo Colaborativo - Metodologia para Desarrollo de Software U2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Protocolo Colaborativo - Metodologia para Desarrollo de Software U2

Cargado por

Copyright:

Formatos disponibles

Asignatura Datos del CIPA Fecha

MODELO CICLO DE VIDA PRODUCTO O PROYECTO DE SOFTWARE

Las actividades de este modelo consistes en la confirmación en un espiral, en la que cada

La ingeniería de software se vale y establece a partir de una serie de modelos que

La estructura dinámica del RUP permite que el proceso de desarrollo se fundamentalmente

 Disciplinas a realizar en cada una de las fases

DOCUMENTOS DEL SCRUM

Es abierto y cualquiera puede modificarlo.

ROLES SCRUM (PRODUCT OWNER, SCRUM MASTER, CLIENTE)

1.- Product Owner (Dueño del Producto)

 Gestiona prioridades.- El Product Owner tiene la responsabilidad de gestionar los

PROYECTO: WEB, MOVIL

Un mazo que se encuentra en el mercado utiliza la siguiente secuencia: 0, ½, 1, 2, 3, 5, 8,

Balsamiq Mockups permite a los diseñadores y desarrolladores de software construir un

o Te permite escoger entre un montón de objetos prediseñados como: barras de

También podría gustarte