Escuela de Ciencias Básicas, Tecnología e Ingeniería

Segundo encuentro sincrónico vía web

conferencia
301404 – Ingeniería de Software
Pilar Alexandra Moreno
CEAD Duitama, octubre 7 de 2020
Encuentro sincrónico - Segunda sesión

Temáticas

Unidad 2 - Modelos de proceso de

desarrollo de software.

Temáticas y Trabajo Colaborativo.

Segunda Fase Modelamiento.
Aclaración de dudas e
inquietudes
Contenidos del curso

Unidad 1 - Introducción a la Unidad 2 - Modelos de proceso Unidad 3 - Gestión de proyectos

Ingeniería de Software de desarrollo de software de software:

Software: componentes,
Fundamentos de gestión de
características, tipos y Modelo de proceso
proyectos
aplicaciones.

Ingeniería de Software: Referentes y estándares para

Modelos clásicos
definición, desafío y capas. la gestión de proyectos

El proceso de software: Modelo PMI para gestión de

Modelos recientes
Definiciones. proyectos: PMBOK

Ciclo de vida: planificación,

análisis, diseño, Marco de desarrollo ágil Trabajo en equipo:
implementación y SCRUM organización, roles y ética
mantenimiento
Modelo de Procesos de software

Se basan en
Descripción
metodologías o
simplificada ciclo
paradigmas de
de vida
desarrollo

Tradicionales,
desarrollo Diversos autores
iterativo, ágiles, clasificaciones
por componentes diferentes
y otros más.
Modelos de Desarrollo

Definen la estructura de
No existe un modelo
un proceso de desarrollo
universal
racional y controlable

Son una guía respecto

Los modelos no son al orden en que deben
rígidos adelantarse las
actividades

Establece el ciclo de
vida del software.

Pixabay. (2016). [imagen]. Recuperado de

https://pixabay.com/photo-1871449/
Clasificación de Modelos
Metodologías ágiles

Marco de
Modelos Modelos Especializados trabajo
clásicos recientes de proceso SCRUM

Cascada RAD- Rapid Desarrollo

Application
Prototipos Development – basado en
Desarrollo ágil de componentes
aplicaciones
Evolutivos:
• Incremental Programación Métodos
• Espiral extrema (XP) formales

Rational Unified
Desarrollo
Modelo en V Process -
de software
Proceso
unificado (RUP) orientado a
aspectos
Ganar-ganar
¿Qué pasa en un proceso de desarrollo de software?
¿Qué pasa en un proceso de desarrollo de software?
Modelo Cascada

Modelo lineal
secuencial
Modelo de Prototipos

Identificar los
requerimientos
conocidos

Desarrollar
Modelo lineal
modelo que secuencial
funcione

Utilizar el
prototipo No

•Abandonar la aplicación
Revisar el Sí
¿Prototipo •Implantar la aplicación
prototipo
Terminado? •Volver a desarrollar la
aplicación
•Comenzar un nuevo
prototipo
Modelos evolutivos de software

Los modelos
evolutivos son
iterativos

se

por desarrollar cada vez más completas del

caracterizan
versiones software

Tales como

y Modelo espiral
Modelo incremental
1. Modelo evolutivo: Modelo Incremental

El modelo
incremental
combina
el y
la
Modelo lineal Construcción de
secuencial prototipos

para

Entregar el
software
en

Partes pequeñas

llamadas

Incrementos
2. Modelo evolutivo: Modelo espiral
Comunicación con el cliente: Se establece comunicación
entre el desarrollador y el cliente.

Planificación: Se definen los recursos, el tiempo y otra

información relacionados con el proyecto.

Análisis de riesgos: Se evalúan riesgos técnicos y de gestión

Actividades
del modelo Ingeniería: Se construyen una o más representaciones de la
en espiral aplicación.

Construcción y acción: Construir, probar, instalar y

proporcionar soporte al usuario.

Evaluación del cliente: Se obtiene la reacción del cliente. Se

realiza la evaluación de las representaciones del software
creadas durante la etapa de ingeniería e implementada durante
la etapa de instalación.

Modelo proceso de
es un construcción de prototipos
Espiral software
evolutivo
conjuga
proporciona modelo lineal secuencial

Un desarrollo rápido de
versiones incrementales del
software
Modelo en V
Métodologías ágiles – RAD (Rapid Application
Development - Desarrollo ágil de aplicaciones)
Métodologías ágiles – RUP
(Rational Unified Process – marco de trabajo)
Fase de
iniciación

Fase de Fase de
transición elaboración

Fase de
construcción
Metodología XP

Historias
Roles XP Proceso XP
de usuario
Programador Tarjetas para especificar requisitos del software

Cliente El cliente especifica requisitos funcionales y no

funcionales

1. El cliente
Tester: encargado
define el
de pruebas Tratamiento dinámico y flexible 4. Vuelve a
valor de
paso 1
negocio a
Tracker: encargado implementar
del seguimiento
Cada una es comprensible y delimitada

Coach: entrenador
Los programadores pueden implementarlas en unas
semanas
3. El 2. El programador
Consultor programador estima el esfuerzo
construye ese necesario para su
Se descomponen en tareas de programación valor implementación
Big boss: gestor
Las historias de usuario se asignan a los
programadores para ser implementadas durante una
iteración
Metodología XP

Exploración

Muerte del Planificación

proyecto de la entrega

Fases

Manteni-
Iteraciones
miento

Producción

Características de XP
SCRUM: Marco de trabajo

Características
Gestión regular de las expectativas del cliente, resultados
anticipados, flexibilidad y adaptación, retorno de inversión,
mitigación de riesgos, productividad y calidad, alineamiento entre
cliente y equipo, por último, equipo motivado.

Se hace uso de equipos auto-dirigidos y auto-organizados.

Se realiza a diario una reunión de Scrum, que es una reunión de

avance diaria que no dura más de 15 minutos con el objetivo de
obtener realimentación sobre las tareas del equipo y los
obstáculos que se presentan.
SCRUM
Roles principales

Dueño del producto: Product Owner

• Único responsable de gestionar la Lista del Producto (Product Backlog).
• 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.
SCRUM
Roles principales

El Equipo de Desarrollo – Development Team

• Profesionales que desempeñan el trabajo de entregar un Incremento de producto
“Terminado”, que potencialmente se pueda poner en producción, al final de cada Sprint.
• Son autoorganizados. Nadie (ni siquiera el Scrum Master) indica al Equipo de Desarrollo
cómo convertir elementos de la Lista del Producto en Incrementos de funcionalidad
potencialmente desplegables;
• Son multifuncionales, contando como equipo con todas las habilidades necesarias para
crear un Incremento de producto;
• Scrum no reconoce títulos para los miembros de un Equipo de Desarrollo, todos son
Desarrolladores, independientemente del trabajo que realice cada persona; no hay
excepciones a esta regla;
• Scrum no reconoce sub-equipos, no importan los dominios particulares que requieran ser
tenidos en cuenta, como pruebas o análisis de negocio; no hay excepciones a esta regla; y,
• Los Miembros individuales pueden tener habilidades especializadas y áreas en las que
estén más enfocados, pero la responsabilidad recae en el Equipo de Desarrollo como un
todo.
• El tamaño óptimo es lo suficientemente pequeño como para permanecer ágil y lo
suficientemente grande como para completar una cantidad de trabajo significativa. (3 a 9)
SCRUM
Roles principales
El Scrum Master o Facilitador

• Responsable de asegurar que Scrum es entendido y

adoptado. Los Scrum Masters hacen esto asegurándose de
que el Equipo Scrum trabaja ajustándose a la teoría,
prácticas y reglas de Scrum.
• Es un líder que está al servicio del Equipo Scrum.
• Ayuda a las personas externas al Equipo Scrum a entender
qué interacciones con el Equipo Scrum pueden ser de ayuda
y cuáles no.
• Ayuda a todos a modificar estas interacciones para
maximizar el valor creado por el Equipo Scrum.
SCRUM
Roles Auxiliares

Stakeholders (Clientes, Proveedores, Vendedores, etc)

• Son las personas que hacen posible el proyecto y para
quienes el proyecto producirá el beneficio acordado
que justifica su desarrollo. Sólo participan directamente
durante las revisiones del "sprint".
Administradores (Managers)
• Son los responsables de establecer el entorno para el
desarrollo del proyecto.
SCRUM - Eventos de SCRUM
El Sprint
Definición:
• Corazón de Scrum. Bloque de tiempo (time-box) 2 a 4 semanas durante el cual se crea un
incremento de producto “Terminado”, utilizable y potencialmente desplegable
• Cada nuevo Sprint comienza inmediatamente después de la finalización del Sprint previo.
Contienen y consisten:
• Reunión de Planificación del Sprint (Sprint Planning Meeting), los Scrums Diarios (Daily
Scrums), el trabajo de desarrollo, la Revisión del Sprint (Sprint Review), y la Retrospectiva
del Sprint (Sprint Retrospective).
Durante el Sprint:
• No se realizan cambios que puedan afectar al Objetivo del Sprint (Sprint Goal);
• Los objetivos de calidad no disminuyen; y,
• El alcance puede ser clarificado y renegociado entre el Dueño de Producto y el Equipo de
Desarrollo a medida que se va aprendiendo más.
Caracterísiticas
• Cada Sprint puede considerarse un proyecto con un horizonte no mayor de un mes.
• Al igual que los proyectos, los Sprints se usan para lograr algo.
• Cada Sprint tiene una definición de qué se va a construir, un diseño y un plan flexible que
guiará la construcción y el trabajo y el producto resultante.
SCRUM - Eventos de SCRUM
Reunión de Planificación de Sprint (Sprint Planning
Meeting)
Características

• Se planifica el trabajo a realizar durante el Sprint. Este plan se crea

mediante el trabajo colaborativo del Equipo Scrum completo.
• Tiene un máximo de duración de ocho horas para un Sprint de un
mes. Para Sprints más cortos, el evento es usualmente más corto.
• El Scrum Master se asegura de que el evento se lleve a cabo y que
los asistentes entiendan su propósito. El Scrum Master enseña al
Equipo Scrum a mantenerse dentro del bloque de tiempo.

Responde a las siguientes preguntas:

• ¿Qué puede entregarse en el Incremento resultante del Sprint que

comienza?
• ¿Cómo se conseguirá hacer el trabajo necesario para entregar el
Incremento
SCRUM - Eventos de SCRUM
Objetivo del Sprint (Sprint Goal)
Características:

• Es una meta establecida para el Sprint que puede ser alcanzada mediante la
implementación de la Lista de Producto.
• Proporciona una guía al Equipo de Desarrollo acerca de por qué está construyendo
el incremento.
• Es creado durante la reunión de Planificación del Sprint.
• Ofrece al equipo de desarrollo cierta flexibilidad con respecto a la funcionalidad
implementada en el Sprint.
• Los elementos de la Lista del Producto seleccionados ofrecen una función
coherente, que puede ser el objetivo del Sprint.
• El objetivo del Sprint puede representar otro nexo de unión que haga que el Equipo
de Desarrollo trabaje en conjunto y no en iniciativas separadas.
• A medida que el equipo de desarrollo trabaja, se mantiene el objetivo del Sprint en
mente.
• Con el fin de satisfacer el objetivo del Sprint se implementa la funcionalidad y la
tecnología.
• Si el trabajo resulta ser diferente de lo que el Equipo de Desarrollo espera, ellos
colaboran con el Dueño del Producto para negociar el alcance de la Lista de
pendientes del Sprint (Sprint Backlog).
SCRUM - Eventos de SCRUM
Scrum Diario (Daily Scrum)

Características:

• Es una reunión de 15 minutos para que el Equipo de Desarrollo

sincronice sus actividades y cree un plan para las siguientes 24 horas.
• Se lleva a cabo inspeccionando el trabajo avanzado desde el último
Scrum Diario y haciendo una proyección acerca del trabajo que podría
completarse antes del siguiente.
• Se realiza a la misma hora y en el mismo lugar todos los días para
reducir la complejidad.
• Durante la reunión, cada miembro del Equipo de Desarrollo explica:
• ¿Qué hice ayer que ayudó al Equipo de Desarrollo a lograr el
Objetivo del Sprint?
• ¿Qué haré hoy para ayudar al Equipo de Desarrollo a lograr el
Objetivo del Sprint?
• ¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo
logremos el Objetivo del Sprint?
SCRUM - Eventos de SCRUM
Revisión de Sprint (Sprint Review)
Características:

• Se realiza al final del Sprint para inspeccionar el Incremento y adaptar la Lista de Producto si fuese
necesario.
• Reunión informal, no es una reunión de seguimiento
• La presentación del Incremento tiene como objetivo facilitar la retroalimentación de información y
fomentar la colaboración.
• Reunión de cuatro horas para Sprints de un mes. Para Sprints más cortos, se reserva un tiempo
proporcionalmente menor.
• El Scrum Master se asegura de que el evento se lleve a cabo y que los asistentes entiendan su
propósito. El Scrum Master enseña a todos a mantener el evento dentro del bloque de tiempo fijado.

Elementos:

• Los asistentes son el Equipo Scrum y los interesados clave invitados por el Dueño de Producto;
• El Dueño de Producto explica qué elementos de la Lista de Producto se han “Terminado” y cuales no
se han “Terminado”;
• El Equipo de Desarrollo habla acerca de qué fue bien durante el Sprint, qué problemas aparecieron y
cómo fueron resueltos esos problemas;
• El Equipo de Desarrollo demuestra el trabajo que ha “Terminado” y responde preguntas acerca del
Incremento;
• El Dueño de Producto habla acerca de la Lista de Producto en el estado actual. Proyecta fechas de
finalización probables en el tiempo basándose en el progreso obtenido hasta la fecha (si es necesario);
• El grupo completo colabora acerca de qué hacer a continuación, de modo que la Revisión del Sprint
proporcione información de entrada valiosa para Reuniones de Planificación de Sprints subsiguientes.
SCRUM - Eventos de SCRUM
Retrospectiva de Sprint (Sprint Retrospective)
Características:

• Oportunidad para el Equipo Scrum de inspeccionarse a sí mismo y crear un plan de

mejoras que sean abordadas durante el siguiente Sprint.
• Tiene lugar después de la Revisión de Sprint y antes de la siguiente Reunión de
Planificación de Sprint.
• Reunión restringida a tres horas para Sprints de un mes. Para Sprints más cortos se
reserva un tiempo proporcionalmente menor.
• El Scrum Master se asegura de que el evento se lleve a cabo y que los asistentes
entiendan su propósito. El Scrum Master enseña a todos a mantener el evento
dentro del bloque de tiempo fijado. El Scrum Master participa en la reunión como un
miembro del equipo ya que la responsabilidad del proceso Scrum recae sobre él.

Propósito

• Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones, procesos y

herramientas;
• Identificar y ordenar los elementos más importantes que salieron bien y las posibles
mejoras; y,
• Crear un plan para implementar las mejoras a la forma en la que el Equipo Scrum
desempeña su trabajo.
SCRUM
Artefactos de SCRUM
1. Lista Es una lista ordenada de todo lo que podría ser necesario en el
producto, y es la única fuente de requisitos para cualquier cambio
de a realizarse en el producto. El Dueño de Producto (Product Owner)
es el responsable de la Lista de Producto, incluyendo su contenido,
Producto disponibilidad y ordenación.
(Product Nunca está completa. El desarrollo temprano de la misma solo
Backlog) refleja los requisitos conocidos y mejor entendidos al principio.

Evoluciona a medida de que el producto y el entorno en el que se

usará también lo hacen. Cambia constantemente para identificar lo
que el producto necesita para ser adecuado, competitivo y útil.
Mientras el producto exista, su Lista de Producto también existe.

Enumera todas las características, funcionalidades, requisitos,

mejoras y correcciones que constituyen cambios a ser hechos
sobre el producto para entregas futuras. Los elementos de la Lista
de Producto tienen como atributos la descripción, la ordenación, la
estimación y el valor.
SCRUM
Artefactos de SCRUM
2. Lista de Conjunto de elementos de la Lista de Producto seleccionados para
el Sprint, más un plan para entregar el Incremento de producto y
Pendiente conseguir el Objetivo del Sprint.
s del
Sprint Es una predicción hecha por el Equipo de Desarrollo acerca de qué
funcionalidad formará parte del próximo Incremento y del trabajo
(Sprint necesario para entregar esa funcionalidad en un Incremento
Backlog) “Terminado”.
Hace visible todo el trabajo que el Equipo de Desarrollo identifica
como necesario para alcanzar el Objetivo del Sprint.

Es un plan con un nivel de detalle suficiente como para que los

cambios en el progreso se puedan entender en el Scrum Diario.
El Equipo de Desarrollo la modifica durante el Sprint y emerge a lo
largo del Sprint. Esto ocurre a medida que el Equipo de Desarrollo
trabaja sobre el plan y aprende más acerca del trabajo necesario
para conseguir el Objetivo del Sprint.
SCRUM
Artefactos de SCRUM
3. Es la suma de todos los elementos de la Lista
Incremento de Producto completados durante un Sprint y
el valor de los incrementos de todos los Sprints
anteriores.

Al final de un Sprint, el nuevo Incremento debe

estar “Terminado”, lo cual significa que está en
condiciones de ser utilizado y que cumple la
Definición de “Terminado” del Equipo Scrum.

Debe estar en condiciones de utilizarse sin

importar si el Dueño de Producto decide
liberarlo o no.
SCRUM
Beneficios

Flexibilidad a cambios.

Reducción del Time to Market (Tiempo para salir a uso).

Mayor calidad del software.

Mayor productividad.

Maximiza el retorno de la inversión (ROI).

Predicciones de tiempos.

Reducción de riesgos.
SCRUM

Tomado de: Presentación Conferencia

Gestión de Proyectos. Ingeniero
Fernando Iván Camargo Sarmiento.
SCRUM: Marco de trabajo

Puntos clave

• EDT bastante concisa. Estructura desagregada

de trabajo. WBS: Work Breakdown Structure
• Alcance global exacto
• Alcances periódicos divulgados a todo el equipo
• Stakeholders comprometidos
• Cero burocracia
• Evaluación diaria del riesgo
¿Cuál modelo ha usado?

Análisis de
requerimientos

Mantenimiento
Diseño del
sistema

Liberación
Diseño de
CAOS programas

Validación del
sistema
Construcción
de programas

Integración
Validación de
componentes
¿Qué modelo usar?

no existe un
modelo
Influye el universal
contexto de
Pueden desarrollo
combinarse Un método de
diferentes desarrollo basado en
modelos componentes,
Depende del soportado en
tipo de arquitecturas, lineal
aplicación pero iterativo UML
Selección del Modelo

Se selecciona un según la naturaleza del

modelo de proceso proyecto y de la aplicación
software
los métodos

las herramientas

los controles y

entregas requeridas
Pixabay. (2014). [imagen]. Recuperado de
https://pixabay.com/photo-516277/
Principio(s) - Método(s) - Herramienta(s) - Modelo(s)

Las actividades en el proceso de desarrollo de software:

Se Se El método se El método
relacionan desarrollan fundamenta soportado
conformando aplicando en por

Modelo Método Principios Herramientas

Ejemplos de relación Actividades - Modelos - Procesos

¿Cómo encadenar las actividades del proceso de desarrollo de

software?
Ej.: Modelo de cascada,
Modelos (ciclo de vida)
Prototipos, RUP....

¿Cómo realizar las actividades del proceso de desarrollo de

software?
Métodos, Ej.: Orientado a objetos, orientado a eventos…

¿Cuáles principios se aplican en el proceso de desarrollo de

software?
Ej.: Incremental, iterativo, lineal secuencial...
Importancia de los modelos

Es importante entonces reconocer

las diferentes metodologías de
desarrollo, así dependiendo del
tipo de software y de cuál es el
problema a resolver se deberá
identificar el modelo de proceso
más adecuado para su desarrollo.

Cada uno de ellos ofrece etapas,

roles y características diferentes
para estructurar y organizar el
proyecto desde el análisis de
requisitos hasta la
implementación completa del
software.
Actividades del curso - Agenda

Plazo para entrega del trabajo individual: Viernes 23 de octubre

Segunda Fase - Modelamiento

Tipo de actividad: Individual ☐ Colaborativa ☒ Número de semanas 4

Momento de la Intermedia,
Inicial ☐ ☒ Final ☐
evaluación: unidad: 2
Entorno de entrega de actividad: Seguimiento y
Peso evaluativo de la actividad: 125
evaluación
Fecha de cierre de la actividad:
Fecha de inicio de la actividad: martes, 6 Trabajo individual: viernes, 23 de octubre de 2020
de octubre de 2020 Trabajo final de grupo: lunes, 2 de noviembre de
2020
Entorno de trabajo colaborativo: Foro.
Actividad colaborativa: con parte de trabajo individual y parte de trabajo grupal
Caso de estudio

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. Ejemplo tomado de: Proyecto presentado a convocatoria Colciencias,
2017.
Segunda Fase–Modelamiento.
Actividad individual
Actividad individual Producto a entregar en la actividad individual
Cada uno de los integrantes del Cada estudiante debe entregar un documento individual, el cual
grupo colaborativo selecciona y debe contener:
aplica un modelo para el 1.Resumen de la propuesta de software que trabajarán como grupo
desarrollo del software y que seleccionaron en la fase anterior. (Tipo de software y
propuesto, que sea pertinente descripción de la propuesta de software).
con el tipo de software 2.Modelo de desarrollo de software seleccionado.
seleccionado en la fase anterior y 3.Explicación y justificación de la selección del modelo.
con las especificaciones descritas 4.Descripción de las fases del ciclo de vida y su aplicación para la
en el caso de estudio. propuesta de desarrollo, de acuerdo al modelo seleccionado.
5.Descripción del equipo de trabajo y de los roles que
Como producto individual, cada implementarán en el proyecto de acuerdo al modelo seleccionado.
estudiante elabora y presenta un 6.Descripción de las herramientas y métodos de control que
informe de aplicación del modelo sugieren utilizar dentro del proceso de desarrollo de software
a la propuesta de software que (control de ejecución, control de cumplimiento, control de calidad,
seleccionaron en la fase anterior etc).
y que responde a lo planteado en
el caso de estudio, detallando los Dicho trabajo individual cada estudiante lo debe entregar en un
6 aspectos solicitados. único documento de texto tipo word (.doc o .docx)
No debe ser pdf, en el tema correspondiente al foro de la Fase 2:
Plazo de entrega: viernes 23 de Modelamiento, espacio en donde el grupo debe interactuar.
octubre Ponderación actividad individual: 12% - 60 puntos.
Para tener en cuenta

 No habrá desarrollo de software como tal, sino planificación de un

proyecto para desarrollar una solución-software concreta.

 Para la parte individual: No envíen aportes sueltos, ni por partes

pues se pierde la secuencia de su propuesta de modelo de
desarrollo. No se calificará por el número de aportes individuales:
sólo un documento .doc consolidado individual.

 La entrega del trabajo individual debe realizarse necesariamente y

de manera obligatoria dentro del plazo establecido e indicado:
viernes 23 de octubre.
Si no lo entrega dentro del plazo, no puede participar en la parte
colaborativa. No se le calificará.
Actividad colaborativa
Actividad colaborativa Producto a entregar en la actividad colaborativa
Luego de que cada participante haya Documento grupal (Documento de texto tipo word .doc o .docx. No debe ser pdf),
realizado y enviado su documento el cual debe contener:
individual con el informe de aplicación del- Portada
modelo que sugiere, en las fechas - Introducción: En esta parte deben indicar la organización del grupo: roles y
acordadas por el mismo grupo, todos los tareas ejercidas por cada integrante, no sólo indicar el rol sino explicar qué tareas
integrantes deben revisar las diferentes ejerció cada integrante de acuerdo a su rol.
- Desarrollo de la actividad: Respuesta a los 6 puntos indicados para la actividad
alternativas recopiladas en el grupo y
colaborativa:
seleccionar la opción que presente el 1.Resumen de la propuesta de software que trabajarán como grupo y que
modelo de desarrollo de software más seleccionaron en la fase anterior. (Tipo de software y descripción de la propuesta
pertinente para la propuesta y para el de software).
caso de estudio que se está analizando. 2.Modelo de desarrollo de software seleccionado por el grupo.
Sobre dicha opción elegida, el grupo debe 3.Explicación y justificación de la selección del modelo.
elaborar y presentar un documento final 4.Descripción de las fases del ciclo de vida y su aplicación para la propuesta de
que contenga los 6 aspectos indicados, de desarrollo, de acuerdo al modelo seleccionado por el grupo.
manera completa, consolidados y 5.Descripción del equipo de trabajo y de los roles que implementarán de acuerdo
ajustados por el grupo, dentro de un al modelo seleccionado por el grupo.
documento con la estructura descrita en 6.Descripción de las herramientas y métodos de control que sugieren utilizar
la siguiente columna. dentro del proceso de desarrollo de software (control de ejecución, control de
cumplimiento, control de calidad, etc).
Ver OVI “Modelos proceso de Software” - Conclusiones: El grupo debe dar respuesta puntual a la pregunta ¿Por qué
consideran que el modelo de software elegido por el grupo es el más pertinente
disponible en las referencias de la Unidad
para responder a las necesidades planteadas en el caso de estudio?
2 del curso
Plazo de entrega: lunes, 2 de - Referencias bibliográficas.
noviembre Ponderación actividad grupal: 13% - 65 puntos.
Planeación de actividades para el desarrollo del trabajo
colaborativo
Actividad Cronograma de trabajo Responsa
bles
Lectura de los recursos teóricos Del día-mes-año–hora al
día-mes-año-hora
Preparación y entrega de los aportes Viernes 23 de octubre de
individuales 2020. 23:55 pm

Interacción del grupo con base en los Del día-mes-año–hora al

aportes individuales día-mes-año-hora
Preparación de los entregables finales del Del día-mes-año–hora al
grupo día-mes-año-hora
Revisión de los productos Del día-mes-año–hora al
día-mes-año-hora
Preparación de los entregables de acuerdo Del día-mes-año–hora al
con la norma establecida (según la versión día-mes
que se maneje)
Roles a desarrollar por el estudiante dentro del grupo
colaborativo

Rol asumido Tareas o funciones realizadas

Responsable de la comunicación entre el tutor y el equipo, como también de
presentar a su equipo la información que recoge de la observación - al desarrollo de
Líder:
las actividades - hecha a los otros equipos de grupo. Responsable de entregar el
Comunicador
producto final
Responsable de la relatoría de todos los procesos en forma escrita. También es
Relator: responsable por recopilar y sistematizar la información a entregar al facilitador-
docente.
Vigía del Controla el cronograma de tiempo establecido, y es responsable porque el equipo
Tiempo: desarrolle las diferentes actividades dentro del tiempo pactado.

Quien se preocupa por verificar al interior del equipo que se estén asumiendo las
Dinamizador responsabilidades individuales y de grupo, propicia que se mantenga el interés por
del Proceso: la actividad y por último cuestiona permanentemente al grupo para generar puentes
entre lo que ya se aprendió.
Responsable de conseguir el material y/o las herramientas de acuerdo a las
Utilero: necesidades del equipo para el desarrollo de las actividades y/o procesos.
Roles y responsabilidades para la producción de
entregables
Roles Función
Consolidar el documento que se constituye como el producto final del debate, teniendo en
cuenta que se hayan incluido los aportes de todos los participantes y que solo se incluya a
Compilador
los participantes que intervinieron en el proceso. Debe informar a la persona encargada de
las alertas para que avise a quienes no hicieron sus participaciones, que no se les incluirá en
el producto a entregar.
Asegurar que el escrito cumpla con las normas de presentación de trabajos exigidas por el
docente.
Revisa que los aportes de los integrantes sean elaboraciones conceptuales propias (no
Revisor copias textuales o plagios) y que las citas y referencias bibliográficas estén completas y
adecuadas a las normas APA. Avisa a la persona de alertas para que informe a los
integrantes del equipo en caso que haya que realizar algún ajuste sobre estos aspectos.
Asegurar que el documento contenga los criterios presentes en la rúbrica. Debe comunicar
Evaluador a la persona encargada de las alertas para que informe a los demás integrantes del equipo
en caso que haya que realizar algún ajuste sobre el tema.
Alertar sobre los tiempos de entrega de los productos y enviar el documento en los tiempos
Entregas estipulados, utilizando los recursos destinados para el envío, e indicar a los demás
compañeros que se ha realizado la entrega.
Asegurar que se avise a los integrantes del grupo de las novedades en el trabajo e informar
Alertas al docente mediante el foro de trabajo y la mensajería del curso, que se ha realizado el
envío del documento.
Rúbrica de evaluación
Aspectos evaluados
Rol del estudiante en el foro de
Trabajo Colaborativo
Calidad de los aportes del
estudiante en el Trabajo
Colaborativo
Calidad de la propuesta
individual presentada por el
estudiante como trabajo
individual
Niveles de desempeño de la actividad individual Pun
ta-
Valoración alta Valoración media Valoración baja
je
El estudiante ingresa
El estudiante se presenta El estudiante inicia sólo una
continuamente al foro, pero no
oportunamente en el foro, asume semana antes de la fecha de
cumple a cabalidad con el rol 20
un rol y lo cumple a cabalidad. cierre y no tiene rol definido.
asumido o no asume un rol.
(Hasta 20 puntos) (Hasta 14 puntos) (Hasta 5 puntos)
El estudiante realiza aportes que
El estudiante realiza aportes
ayudan, en alguna medida, a la
coherentes y pertinentes que
consolidación del modelo de El estudiante no realiza aportes
ayudan a la consolidación del
desarrollo de software propuesto para la consolidación del
modelo de desarrollo de software
por el grupo, y/o no los hizo en el modelo de desarrollo de 20
propuesto por el grupo, dentro
tiempo establecido para la software propuesto por el grupo
del tiempo establecido para la
actividad colaborativa. Sus aportes
actividad colaborativa.
pudieron ser mejores.
(Hasta 20 puntos) (Hasta 14 puntos) (Hasta 5 puntos)
El estudiante aporta una El estudiante aporta una
propuesta de aplicación de un propuesta de aplicación de un
El estudiante no aporta una
modelo de desarrollo de software modelo de desarrollo de software
propuesta de aplicación de un
para la propuesta elegida de para la propuesta elegida de
modelo de desarrollo de
acuerdo al caso de estudio acuerdo al caso de estudio
software para la propuesta 20
planteado, describiendo de planteado, pero no describe de
elegida de acuerdo al caso de
manera pertinente todos los 6 manera pertinente todos los 6
estudio planteado
aspectos indicados para el trabajo aspectos indicados para el trabajo
individual individual
(Hasta 20 puntos) (Hasta 14 puntos) (Hasta 5 puntos)
Rúbrica de evaluación
Niveles de desempeño de la actividad colaborativa Pun
Aspectos evaluados
Valoración alta Valoración media Valoración baja taje
Realiza una correcta selección del Realiza la selección del modelo de
modelo de desarrollo de acuerdo a la desarrollo, pero no es muy acorde con No realiza la selección de un
Fines de la propuesta
propuesta de software y de acuerdo la propuesta de software ni con las modelo de desarrollo para la
grupal – Modelo de 20
con las características expuestas en el características expuestas en el caso de propuesta de software elegida
desarrollo propuesto
caso de estudio. estudio.
(Hasta 20 puntos) (Hasta 14 puntos) (Hasta 5 puntos)
Identifica fases pertinentes del Identifica fases del modelo de No identifica fases del modelo
modelo de desarrollo para la desarrollo, pero no son muy de desarrollo para la propuesta
Fines del trabajo grupal propuesta de software, de acuerdo pertinentes para la propuesta de de software, de acuerdo con las
– Fases del modelo de con las características y software, de acuerdo con las características y requerimientos 20
desarrollo requerimientos planteados en el caso características y requerimientos planteados en el caso de
de estudio. planteados en el caso de estudio. estudio.
(Hasta 20 puntos) (Hasta 14 puntos) (Hasta 5 puntos)
Describe un equipo de trabajo Describe un equipo de trabajo con
adecuado con roles definidos para la algunos roles definidos pero no es
Fines del trabajo grupal No describe un equipo de
propuesta de software, de acuerdo pertinente para la propuesta de
– Equipo de trabajo y trabajo con roles definidos para
con las características y software, de acuerdo con las 20
roles del modelo de la propuesta de software
requerimientos planteados en el caso características y requerimientos
desarrollo
de estudio planteados en el caso de estudio
(Hasta 20 puntos) (Hasta 14 puntos) (Hasta 5 puntos)
El documento se ajusta a la estructura El documento se ajusta a la estructura
El documento no se ajusta a la
estipulada en la guía de actividades y estipulada en la guía de actividades,
estructura estipulada en la guía
no presenta errores de redacción ni pero presenta algunos errores de
Estructura del de actividades, presenta errores
ortografía. Además contiene redacción y ortografía. Además no
documento final del de redacción y ortografía. 5
introducción y conclusiones que contiene introducción y/ó conclusiones
grupo Además, no contiene ni
responden de manera adecuada a lo que respondan de manera adecuada a
introducción ni conclusiones.
planteado en la guía. lo planteado en la guía.
(Hasta 5 puntos) (Hasta 3 puntos) (Hasta 1 puntos)
Indicaciones finales

 Estudiante que no envíe o no realice su actividad individual, de acuerdo a

las indicaciones para cada fase en el tiempo establecido para entrega de
aportes individuales(23 de octubre), tiene calificación de 0.0.
 El grupo debe enviar el documento final, una vez lo realicen, lo revisen y lo
consoliden con base en los trabajos individuales que hayan enviado.
 Si el estudiante envió su trabajo individual después del plazo indicado,
tendrá una calificación total de 0 puntos en el trabajo colaborativo y no se
le aplicará la rúbrica de evaluación de la actividad.
 Si el estudiante envía su trabajo individual en el plazo establecido, pero
no participa en la consolidación del trabajo de grupo sólo se le aplicará el
ítem de la rúbrica de evaluación referente al trabajo individual.
 Si se comprueban plagios y/o copias textuales de otros trabajos o de
internet, el grupo tendrá una calificación total en el trabajo colaborativo
de 0 puntos y no se le aplicará la rúbrica de evaluación de la actividad.
Indicaciones finales

 Para los plazos y tiempos de la participación en la parte

colaborativa de la actividad, deben tener en cuenta la Resolución de
Rectoría No. 6808 - Referentes y lineamientos para desarrollo del
trabajo colaborativo en donde se indica: “Para aquellos estudiantes
que ingresan faltando dos o tres días para el cierre de la actividad,
el docente no tendrá en cuenta estas participaciones para la
asignación de la calificación en respeto del cumplimiento de
aquellos estudiantes que sí lo han hecho.”

 Al inicio de cada fase, deben distribuir entre todos los integrantes

del grupo los roles para la etapa de elaboración del trabajo grupal:
aportes, desarrollo, interacción, complementos y consolidación del
producto final del grupo

¡Éxitos en el desarrollo de la Fase 2- Modelamiento!

Indicaciones finales

Evaluación final del curso

Cuestionario en línea
Proctoring en el curso

Opciones para descargar y revisar los instructivos:

1. Cómo hacer el registro
2. Cómo probar que el registro quedó bien

Opciones para realizar el registro:

1. Enlace de registro: Esta opción es por donde
realizan su registro siguiendo el instructivo.
2. Estado de registro: Por aquí pueden confirmar si
su registro quedó bien y fue aceptado, según el
instructivo.

Deben realizar su registro en el curso, cuanto antes.

Es un proceso obligatorio para el desarrollo de la evaluación final.
Si no lo realizan, no pueden presentar dicha actividad.
¡GRACIAS POR SU ATENCIÓN!