PROCESO DE GESTIÓN DE FORMACIÓN PROFESIONAL INTEGRAL

FORMATO GUÍA DE APRENDIZAJE

1. IDENTIFICACIÓN DE LA GUIA DE APRENDIZAJE

 Denominación del Programa de Formación: Tecnólogo en Análisis y Desarrollo de Software.

 Código del Programa de Formación: 228118 Versión 1.

 Nombre del Proyecto: Construcción de software orientado al sector productivo agroindustrial,

pecuario o minero del departamento Norte de Santander.

 Fase del Proyecto: Análisis

 Actividad de Proyecto: Establecer los modelos, procesos y especificaciones del proyecto de

software

 Competencia: 220501092 - Establecer requisitos de la solución de software de acuerdo con

estándares y procedimiento técnico

 Resultados de Aprendizaje Alcanzar:

 220501092-04- Validar el informe de requisitos de acuerdo con las necesidades del cliente.
 220501093-01- Planear actividades de análisis de acuerdo con la metodología seleccionada.

 Duración de la Guía: 80

2. PRESENTACIÓN

Estimado aprendiz, el SENA extiende una cordial bienvenida a la primera guía de aprendizaje que comprende
las competencias técnicas de establecer requisitos de la solución de software de acuerdo con estándares y
procedimiento técnico.
Por otra parte, ya no es un secreto que la sociedad ha avanzado a pasos agigantados en los procesos de las
diferentes áreas de ocupación. Una de las áreas que más ha tenido repunte es la informática, que se encarga del
estudio del hardware, las redes de datos y el software necesario para tratar la información de manera
automática y se convierte en factor primordial a la hora de gestionar la información para la administración de
métodos, técnicas y procesos en todas las áreas de ocupación. Para el desarrollo de las actividades planteadas
en esta guía contará con el acompañamiento de los instructores asignados al programa, los cuales de forma
continua y permanente lo orientarán con las pautas necesarias para el logro de las actividades de aprendizaje,
brindando herramientas básicas de tipo conceptual y metodológico.
No olvide revisar y explorar los materiales de estudio del programa.
GFPI-F-135 V01
 Por consiguiente, se presentan cada una de las acciones de aprendizaje que le permitirán desarrollar lo
anteriormente mencionado.

3. FORMULACIÓN DE LAS ACTIVIDADES DE APRENDIZAJE

Ambiente Requerido:

Ambiente convencional: __ _
Ambiente real de aprendizaje: Ambiente 210 de industria Laboratorio o
taller:
Ambiente dual:
Pluritecnológico:
Ambiente Virtual o simulación:

3.1. Actividad de Reflexión Inicial. (2 HORAS)

A continuación, encontrará unas lecturas, las cuales debe leer cuidadosamente, posteriormente desarrollar las
preguntas y socializarlas de acuerdo con los lineamientos dados por el instructor.

Caso de estudio

Matutano- Frito Lay.

La firma matutano, del grupo PepsiCo, Controla el 56% del mercado español de snack. (aperitivos
ligeros envasados), lo que en 1992 representó una facturación de
unos 30 millones de pesetas. Más de mil cien vendedores visitan
quincenalmente a los ciento cincuenta mil clientes de la empresa,
con lo cual generan un enorme volumen de datos en forma de
pedidos, facturas, recibos, etc. Frito lay, el equivalente de
Matutano en Estados Unidos, dispone de un ejército de diez mil
vendedores que visitan regularmente unos cuatrocientos mil
puntos de venta y manejan, por consiguiente enormes cantidades
de datos. Pero lejos de ahogarse en esta cantidad de información,
tanto Matutano como Frito-Lay la han aprovechado para
responder mejor a las exigencias del mercado.

Las dimensiones del mercado de Frito-Lay y, en menor medida, las de Matutano, hacen que un error en la
interpretación de la demanda pueda generar millones de unidades devueltas al almacén. Por ello, resulta vital que
se pueda determinar con la mayor precisión posible, cuales son las preferencias de los consumidores, de manera
que fábricas y almacenes puedan responder a ellas con exactitud y rapidez.

Para lograr este objetivo, Frito-Lay elaboró un sistema de recolección y análisis de datos que le permite determinar
la evolución diaria de las ventas.
El sistema se basa en los repartidores quienes, provistos de computadoras portátiles, registGraFPnI-eF-n13c5aVd0a1
punto de venta los productos que deben reabastecerse y los que deben devolverse. Este método facilita la tarea
operativa de los vendedores, los cuales, al final del día transmiten los datos a la computadora central de su sede.
 La verdadera clave del sistema es el complejo software de análisis de las ventas y su comportamiento.

El hecho de contar con computadoras portátiles, que además ha disminuido el papeleo, les permite a los directivos
disponer de mejor información sobre la evolución diaria de las ventas, de especial importancia en un sector. En el
que los competidores locales pueden responder ágilmente con menores costos a los gustos y preferencias del
mercado.

Durante el desarrollo del sistema se otorgó especial importancia a la identificación de los datos que serían
conectados en los puntos de venta, así como a la manera en que serían presentados a los directivos, lo que dio
como resultado un sistema de información para ejecutivos. (en inglés, EIS: Executive Information System).

Importantes competidores de Frito-Lay en los Estados Unidos, como. Kraft. Procter & Gamble o Nabisco han
desarrollado sistemas similares hasta el punto que es difícil concebir el negocio de los snacks sin pensar en una
red de repartidores provistos de terminales portátiles.

Preguntas de caso de estudio.

1. Identifique y explique los tipos de sistemas de información.

R/
-Sistemas de procesamiento de transacciones

Los sistemas de procesamiento de transacciones (TPS por sus siglas en inglés) son los sistemas empresariales
básicos que sirven al nivel operacional de la organización.
Un sistema de procesamiento de transacciones es un sistema computarizado que realiza y registra las
transacciones rutinarias diarias necesarias para el funcionamiento de la empresa. Se encuentran en el nivel
más bajo de la jerarquía organizacional y soportan las actividades cotidianas del negocio.

 -Sistemas de control de procesos de negocio

Los sistemas de control de procesos de negocio (BPM por sus siglas en inglés) monitorizan y controlan los
procesos industriales o físicos, como puede ser la refinación de petróleo, generación de energía o los sistemas
de producción de acero en una planta siderúrgica.

-Sistemas de colaboración empresarial

Los sistemas de colaboración empresarial (ERP por sus siglas en inglés) son uno de los tipos de sistemas de
información más utilizados. Ayudan a los directivos de una empresa a controlar el flujo de información en sus
organizaciones.

-Sistemas de Información de Gestión

Los sistemas de información de gestión (MIS por sus siglas en inglés) son un tipo de sistemas de información
que recopilan y procesan información de diferentes fuentes para ayudar en la toma de decisiones en lo referente
a la gestión de la organización.

 -Sistemas de apoyo a la toma de decisiones

Un sistema de apoyo a la toma de decisiones o de soporte a la decisión (DSS por sus siglas en inglés) es un
sistema basado en ordenadores destinado a ser utilizado por un gerente particular o por un grupo de gerentes a
cualquier nivel organizacional para tomar una decisión en el proceso de resolver una problemática
semiestructurada. Los sistemas de apoyo a la toma de decisiones son un tipo de sistema computerizado de
información organizacional que ayuda al gerente en la toma de decisiones cuando necesita modelar, formular,
calcular, comparar, seleccionar la mejor opción o predecir los escenarios.
-Sistemas de Información Ejecutiva

Los sistemas de información ejecutiva (EIS por sus siglas en inglés) proporcionan un acceso rápido a la
información interna y externa, presentada a menudo en formato gráfico, pero con la capacidad de presentar
datos básicos más detallados si es necesario. Los sistemas información ejecutiva proporcionan información
crítica de una amplia variedad de fuentes internas y externas en formatos fáciles de usar para ejecutivos y
gerentes.

2. ¿Qué ventajas Competitivas, dio a Frito-Lay el uso de los sistemas de información?

R/ les permite a los directivos disponer de mejor información sobre la evolución diaria de las ventas, Este
método facilita la tarea operativa de los vendedores, los cuales, al final del día transmiten los datos a la
computadora central de su sede

3. ¿En qué consistió la utilización inteligente de los datos?

R/ Consistió en elaborar un sistema de recolección y análisis de datos que le permite determinar la evolución
diaria de las ventas, los repartidores quienes, provistos de computadoras portátiles, registGraFPnI-eF-n13c5aVd0a1
punto de venta los productos que deben reabastecerse y los que deben devolverse. Este método facilita la tarea
operativa de los vendedores, los cuales, al final del día transmiten los datos a la computadora central de su sede.

4. ¿Qué podría haber pasado Sí Frito-Lay no hubiera modificado su sistema de reparto.

R/ frito lay maneja una cantidad enorme volumen de datos en forma de pedidos, facturas, recibos, etc,
por lo cual no implementar un software de análisis de ventas hubiera significado una saturación en los
datos manejados empresa, por ende la demanda del producto no seria abastecida , teniendo
perdidas considerables y viéndose afectada el futuro de la misma.

3.2 Actividades de contextualización e identificación de conocimientos necesarios para

el aprendizaje.
(2 HORAS)

Procedo a mi autodiagnóstico tomando como referencia las lecturas en la Actividad de Reflexión Inicial y teniendo
en cuenta su conocimiento construido a partir de una experiencia previa para fomentar el análisis, la reflexión y el
espíritu crítico del aprendiz genero respuestas a los siguientes interrogantes planteados mediante el uso de lluvia
de ideas:
1. ¿Que es Validación de requisitos?

R/ La validación de requisitos es el proceso de verificar que los requisitos estén definidos para el
desarrollo y definir el sistema que el cliente realmente quiere. Para verificar problemas relacionados
con los requisitos, realizamos la validación de requisitos. La validación de requisitos generalmente nos
ayuda a detectar errores en una etapa temprana del desarrollo del producto para que no resulte en una
repetición excesiva del trabajo cuando se detecte más adelante en el ciclo de vida del desarrollo del
software.

2. ¿Sabe usted cuales son las verificaciones que se llevan a cabo en un proceso de validación?

R/

Calidad: La calidad del software es el grado o medida en que el producto cumple con sus
especificaciones.

Comprobación y análisis de sistemas:

Inspecciones del software: analizan y comprueban las representaciones del sistema como el documento de
requerimientos, los diagramas de diseño y el código fuente del programa. Las inspecciones de software y los
análisis automatizados son técnicas estáticas puesto que no requieren que el sistema se ejecute.

Las pruebas del software: Llevan a cabo una implementación del software con los datos de prueba y examinan
las salidas del software y su comportamiento operacional para comprobar que se desempeñe conforme a lo
requerido.

Pruebas
Prueba de interfaz: Muchas fallas de aplicaciones se deben a problemas con las interfaces, por lo que es
recomendable la aplicación de estas pruebas.

Prueba del sistema: La prueba del sistema es la culminación de las pruebas de integración. Consiste en pruebas
que validan la aplicación completa, contra sus requerimientos.

Prueba de utilidad: Una buena interfaz4 puede mejorar mucho el valor de una aplicación. La prueba de utilidad
valida la aceptación de la aplicación por los usuarios.

Prueba para los requerimientos de interfaz de usuario: La tarea principal de las pruebas de utilidad es asegurar
que la aplicación satisface los requerimientos establecidos.

Pruebas de instalación: El hecho de que se haya probado la aplicación en el entorno propio no asegura que
trabaje de marera apropiada.

3. ¿Conoce los conceptos de Verificabilidad, Comprensibilidad, Rastreabilidad y Adaptabilidad

R/ verificabilidad: El proceso de verificación y validación (V&V) aborda todas las etapas del ciclo de vida
del software de manera determinante, siendo utilizado para establecer si determinada tarea o producto,
cumple con las necesidades del usuario y los requisitos establecidos para su desarrollo.

Comprensibilidad: Grado en el que los datos tienen atributos que permiten ser leídos e interpretados
por los usuarios y son expresados utilizando lenguajes, símbolos y unidades apropiados en un contexto
de uso específico. Cierta información sobre la comprensibilidad puede ser expresada mediante
metadatos.
 Rastreabilidad: Se enfoca en poder rastrear detalladamente los puntos por los que ha atravesado
una solicitud o petición, junto con información relacionada con cada uno de estos puntos, donde se
incluyen los datos de tiempo, errores, latencia y demás.

Adaptabilidad: Capacidad de el software que le permite ser adaptado de forma efectiva y eficiente a
diferentes entornos determinados casos de uso.

3.3 Actividades de apropiación del conocimiento (Conceptualización y Teorización). (70 HORAS)

Como aprendiz, participo activamente en el proceso de formación con mis compañeros aprendices y mi instructor
en cada una de las Actividades y Subactividades, como también de las explicaciones y exposición magistral
del tema en referencia.

Actividad de Aprendizaje 1. GA2-220501092-AA4: determinar los requisitos funcionales y no funcionales

del software de acuerdo con los requerimientos del cliente

Esta actividad se centra en dos grandes bloques:

1. Análisis de las diferentes técnicas de análisis de requisitos
En este componente formativo se abordan el análisis de requisitos (priorización, descomposición funcional,
matriz de trazabilidad) y estándares, y/o guías existentes para la especificación formal de los mismos
dependiendo del tipo de marco de trabajo usado (tradición o ágil).
2. Estándares o modelos para el proceso de documentación de requisitos del software.
En este componente formativo se abordan los temas de técnicas de validación de requisitos (revisiones,
prototipos y casos de prueba) y el tema de los requerimientos duraderos y volátiles.

A. Apreciado aprendiz a continuación, podrá Afianzar algunos de los conceptos más importantes asociados al
proceso de priorización de requisitos, mediante la siguiente actividad planteada consiste en organizar dos
columnas: en una se deben poner las técnicas de priorización y en otra columna aparte las definiciones
caracteristicas, el objetivo es que el aprendiz haga la union entre la técnica y caracteristica, de esta manera
podra hacer un repaso general del desarrollo de este primer componente formativo.
En el siguiente link podrá encontrar la actividad para su desarrollo
https://sena.territorio.la/content/index.php/institucion/Titulada/institution/SENA/Tecnologia/228118/C
ontenido/OVA/CF4//actividades/actividad_01/story.html.

B. Construir el documento de requisitos que especifique los requisitos funcionales y no funcionales teniendo en
cuenta las características del software a realizar y el estándar IEEE830. Tenga En cuenta para realizar la
evidencia el material de formación, y el ejemplo puesto en plataforma de como diligenciar el IEEE830.
Puede usar cómo base el ejemplo para adaptar su propio documento,

Ejemplo
diligenciamiento IEE
teniendo en cuenta el proyecto de formación.

Elementos para tener en cuenta en el documento técnico de validación: se deben seguir las
normas básicas de presentación de un documento escrito, es decir el documento debe tener como mínimo una
portada, introducción, y la lista de:
o Requisitos funcionales.
o Requisitos no funcionales.
G F P I -F -1 35 V01
Respecto a lista de requerimientos el aprendiz deberá agregar una sección donde se d e s c r ib a
cada requisito usando los siguientes elementos del estándar IEEE830.
 Perspectiva del producto.
  Funciones del producto.
 Características de los usuarios.
 Restricciones.
 Requisitos funcionales (formato de casos de uso).
 Requisitos no funcionales.

Respecto a la lista de requerimientos el aprendiz deberá agregar una sección donde se describa cada requisito
usando la estructura de historias de usuario con los siguientes elementos por historia:

 Número de historia (priorizada).

 de la historia.
 Usuario.
 Puntos estimados de esfuerzo.
 Descripción de la historia de usuario.
 Observaciones.
 Criterios de aceptación.

Lineamientos para la entrega del producto:

 Productos para entregar: documentos requerimientos funcionales y no funcionales.
 Formato: PDF o Word.
 Extensión: libre.
 Para hacer el envío del producto remítase al área de la actividad correspondiente y acceda al espacio
para el envío de la evidencia: especificación de los requerimientos funcionales y no funcionales del
software en IEEE830 GA1-220501092-AA4-EV01

C. Apreciado aprendiz a continuación, podrá Afianzar el proceso de priorización de requisitos por medio de
algunas técnicas (puntos de historia y valor del negocio, técnica urgente, MoSCow y matriz de priorización).
Utilización la siguiente técnica didatica Construcción de lista de priorizada de requisitos de
acuerdo con técnica de priorización.

Acontinuacion, se listan un conjunto de requerimientos descritos de manera informal como historias de

usuario. Luego dependiendo de la técnica se definen algunas etiquetas y/o valores asignados con los cuales
debera realizar los calculos y analisis correspondientes para definir el orden de prioridad de los requisitos.
En el siguiente link podrá encontrar la actividad para su desarrollo
https://sena.territorio.la/content/index.php/institucion/Titulada/institution/SENA/Tecnologia/228118/C
ontenido/OVA/CF4//actividades/actividad_02/story.html

D. Al construir una matriz de trazabilidad se deben usar los campos que se consideren útiles para el proyecto,
pues no todos los proyectos son iguales y la estructura definida para uno puede no resultar conveniente para
otro proyecto. Cuando se usa, esta matriz debe permanecer actualizada a lo largo del ciclo de
vida de construcción del proyecto.
De acuerdo a lo anterior apreciados aprendices los invicto a diligenciar el formato de Matriz
GFPI-F-135 V01

Ejemplo_estructura
_matriz_trazabilidad
de trazabilidad de acuerdo al proyecto de formación por empresas
Elementos para tener en cuenta en el documento técnico de trazabilidad: se deben seguir las
normas básicas de presentación de un documento escrito, es decir el documento debe tener como mínimo una
portada, introducción, y la lista de:
o identificar resultado que se alcanza con cada requisito.
o visualizar qué requisitos son necesario cumplir para determinado entregable

Identificación
Identificador: código único para cada requisito.
Código jerárquico: código que permite categorizar cada grupo de requisitos.
Descripción: texto explicativo del requerimiento.
Tipo: categoría del requisito (requerimiento de negocio, requerimiento de los
interesados, funcionales y no funcionales, requerimientos del proyecto, requerimiento
de calidad)

Estado
Versión: versión del requerimiento (importante para el control de cambios).
Estado: activo, cancelado, diferido, agregado, aprobado, asignado o
completado.
Fecha de estado: momento en el que se realizó la última modificación del
estado.
Responsable: persona encargada del requisito.
Prioridad: escalas de prioridad usada en el proyecto (alta, media, baja; 1, 2,
3, 4, 5). Otras características: cualquier otro campo de valor para la
organización.

Objetivo Objetivo: objetivo que pretende alcanzar el requerimiento.

Necesidad de negocio: necesidad de negocio que se pretende cubrir con el
objetivo del proyecto y por ende con el requisito.
Entregable: producto

Lineamientos para la entrega del producto:

 Productos para entregar: Plantilla de Matriz de trazabilidad .
 Formato: PDF o Excel .
 Extensión: libre.
 Para hacer el envío del producto remítase al área de la actividad correspondiente y acceda al espacio
para el envío de la evidencia: Plantilla Matriz de Trazabilidad del proyecto de formación.
GFPI-F-135 V01
E. Las historias de usuario son una explicación general e informal de una función del software escrita desde la
perspectiva del usuario final o cliente. Permiten describir de una manera muy breve un requerimiento, estimar
prioridades, alcance y tiempo de realización (Rivadeneira, 2014). En la siguiente tabla, se puede observar la
estructura base de un documento de historia de usuario.

Las historias de usuario tienen varios beneficios respecto a otros instrumentos de redacción de
requerimientos, entre los cuales se pueden listar:

 Las historias de usuario se centran en solucionar problemas a usuarios reales.

 Las historias de usuario permiten la colaboración, ya que como su descripción es corta se necesita que
el equipo colabore para decidir cómo dar solución a la historia para cumplir con la necesidad
expresada por el usuario.
 Las historias impulsan la creatividad, ya que fomentan que el equipo piense de forma crítica y creativa
sobre cómo solucionar de la mejor manera el objetivo.
 Las historias de usuario motivan, pensar en la mejor solución para una problemática particular
representan retos y pequeñas victorias para el equipo.

Apreciados aprendices de acuerdo a lo mencionado anteriormente y teniendo en cuenta la tabla estructura

base de un documento de historia y el material didáctico
https://sena.territorio.la/content/index.php/institucion/Titulada/institution/SENA/Tecnologia/228118/C
ontenido/OVA/CF5//actividades/actividad_01/index.html y Con la historia de usuario del proyecto de
formación realizada en la guía de aprendizaje 1.

crear la tabla estructura base documento de historia de usuario de su proyecto de formación . Lineamientos

para la entrega del producto:

 Productos para entregar: Plantilla de Matriz de trazabilidad .
 Formato: PDF o Excel .
 Extensión: libre.
 Para hacer el envío del producto remítase al área de la actividad correspondiente y acceda al espacio
para el envío de la evidencia: Tabla estructura base documento de historia de usuario de
su proyecto de formación
GFPI-F-135 V01
F. El marco de trabajo Scrum está soportado en un proceso de construcción iterativo e incremental evolutivo,
en el que se identifican tres roles principales: el equipo de trabajo (team) conformado por los desarrolladores,
diseñadores, personal de calidad y de infraestructura requerido para la
 construcción del producto de software; el scrum master que realizan funciones parecidas a las de un
director de proyecto, pero más enfocados en garantizar que el equipo de trabajo tenga todas las herramientas y
recursos necesarios para el desarrollo de su trabajo; y, finalmente, el dueño del producto (product owner) que
se convierte en un representante del cliente y quien es el único encargado de la gestión de requisitos del
proyecto (ScrumStudy, 2021).
Scrum establece el concepto de sprint para referirse a una iteración que contempla tiempos fijos entre 2 y 4
semanas dependiendo del equipo de trabajo, durante este tiempo se incluye la planeación del sprint, donde se
definen los requerimientos a desarrollar en ese periodo de tiempo, una fase de construcción del producto y,
finalmente, un proceso de despliegue para poder hacer la respectiva demostración de lo construido al final de
iteración en reuniones de revisión; en este marco de trabajo se redefine el concepto de requerimiento hecho y
normalmente va mucho más allá de construir el código, por lo general, se incluyen procesos de validación con
pruebas unitarias y pruebas de integración.

Para realizar la siguiente actividad debes tener en cuenta lo mencionado anteriormente y el material de
estudio Análisis y especificación de requisitos.

Aplicar la metodología Scrum en su proyecto de formación como marcos de trabajo agiles

en la especificación de requisitos.
Nota ( Calcular los tiempos del proyecto con datos hipotéticos )

Lineamientos para la entrega del producto:

 Productos para entregar: .
 Formato: PDF o Word .
 Extensión: libre.
 Para hacer el envío del producto remítase al área de la actividad correspondiente y acceda al espacio
para el envío de la evidencia: Aplicar la metodología Scrum en su proyecto de formación
como marcos de trabajo agiles en la especificación de requisitos.

G. Actividad de Aprendizaje 2. GA2-220501092-AA5 aplicar técnicas de validación de requisitos

del software.
Esta actividad se centra en el estudio de los componentes de la fase de elicitación de requisitos, técnicas y
herramientas de captura de requisitos.

La validación de los requerimientos busca ratificar que los

requerimientos realmente están especificando lo que el
cliente desea y necesita. Este proceso es muy importante,
pues un error en un documento de requerimientos puede
ocasionar el desgaste importante de muchos recursos si
estos errores son detectados en etapas más avanzadas del
proyecto como diseño, construcción o despliegue a
producción. Los costos asociados para el arreglo de
problemas en los requerimientos siempre van a ser menores
que en
otras etapas, ya que un error en los requerimientos se propaga en cascada en todas las fases subsiguientes del
ciclo de vida.
Según Sommerville (2011), en el proceso de validación de requerimientos se llevanGFaPIc-Fa-1b3o5
Vla0s1 siguientes verificaciones:
 Verificación de validez: los requerimientos son razonables e identifican realmente todas las
funciones necesarias para cumplir con las necesidades del cliente.
Verificación de consistencia: los requerimientos no presentan contradicciones.
Verificaciones de completitud: se incluyen todas las funcionalidades y restricciones definidas por los
usuarios del sistema.
Verificaciones de realismo: los requerimientos son realizables de acuerdo con la tecnología existente,
el presupuesto y los tiempos definidos.
Verificabilidad: es posible demostrar la realización de cada requerimiento y que hace lo que debe
hacer. Es decir, existe una forma clara en la que se le pueda realizar pruebas.

Evidencia de conocimiento: GA2-220501092-AA5-EV01 realizar una presentación en

PowerPoint u Otra aplicación para la determinación de las especificaciones funcionales del
software y metodología a utilizar.

A partir de la revisión de las diferentes herramientas tecnológicas

disponibles para la gestión de requisitos, seleccionar una para
configurar los requerimientos del proyecto seleccionado.
A continuación les comparto una Lista de Software de
Gestió n de Requisitos

Estas son las principales herramientas de gestió n de

requisitos que está n en la reseñ a de software en el
siguiente link

https://thedigitalprojectmanager.com/es/tools/herramientas-gestion-requisitos/

Lineamientos para la entrega del producto:

 Producto para entregar: documento.
 Formato: PDF o Word.
 Extensión: libre.
 Para hacer el envío del producto remítase al área de la actividad correspondiente y acceda al
espacio para el envío de la evidencia: taller para la determinación de las
especificaciones funcionales del software y metodología a utilizar GA2-
220501092- AA5-EV01.

H. Evidencia de producto: GA2-220501092-AA5-EV02 informe de evaluación de los requerimientos

Teniendo en cuenta las características de las técnicas de validación de requisitos abordadas en la actividad de
aprendizaje, construir los prototipos del sistema y los casos de prueba asociados a cada interfaz desarrollada.

Elementos a tener en cuenta en el documento técnico de validación

G F PI -F - 13 5 V 01
 Se deben seguir las normas básicas de presentación de un documento escrito, e s d e c ir e l
documento debe tener como mínimo una portada, introducción, alcance, lista de requerimientos y
versión del documento.
  Deberá seleccionar cuatro (4) historias de usuario o requisitos del proyecto seleccionado para
representarlos por medio de prototipos y realizar sus respectivos casos de prueba.
 Para la construcción de prototipos deberá usar una de las herramientas propuestas en el componente
formativo y exportar dichos elementos desarrollados como imágenes para ser

Plantilla prototipo
inicial de prueba.do
incluidos dentro del documento.
 Por cada interfaz desarrollada deberá construir un caso de prueba el cual debe tener los siguientes
elementos.
 Objetivo del caso de prueba.
 Identificador.
 Nombre del requerimiento o historia de usuario asociada.
 Precondiciones.
 Lista de pasos con los resultados esperados.
Lineamientos para la entrega del producto:
 Producto para entregar: documento informe técnico de validación.
 Formato: PDF o Word.
 Extensión: Para el prototipo pueden utilizar las siguientes aplicaciones .
 Para hacer el envío del producto remítase al área de la actividad correspondiente y acceda al
espacio para el envío de la evidencia: informe de evaluación de los requerimientos GA2-
220501092-AA5-EV02.

I. Actividad de aprendizaje 3: GA2 -220501093-AA1 estructurar el plan de actividades de

análisis a partir de las características del proyecto y el modelo de desarrollo
seleccionado.
En esta actividad de aprendizaje se abordan las técnicas de validación de requisitos: revisiones, los prototipos
y los casos de prueba.

Las metodologías de desarrollo

de software siempre parten de un componente
teórico y cuando son usadas por los equipos de
trabajo conllevan a la utilización de un conjunto de
técnicas y métodos que al final determinarán las
tareas generales y específicas que se deberían
realizar para alcanzar un objetivo.

Existen diferentes tipos de metodologías de desarrollo

de software que fueron ideadas pensando en
problemas particulares presentados en la industria en
contextos específicos, por lo cual es importante
conocer sus diferentes características y contrastarlas
con las necesidades particulares a las que se enfrenta a
la hora de desarrollar un producto y servicio.

Es decir, cada una de estas tiene ventajas y enfoques

que pueden ser reutilizados en diferentes momentos. Existen dos grandes clasificaciones de metodologías de
desarrollo de software que se agrupan generalmente como marcos de trabajo
tradicionales o marcos de trabajo ágiles que se verán GFPI-F-135 V01

A continuación, se describen las acciones y las correspondientes evidencias que conforman la actividad
de aprendizaje:
 Evidencia conocimiento: GA1-220501093-AA1-EV01 taller sobre metodologías de desarrollo
de software

Las metodologías de desarrollo son indispensables en los grupos de trabajo y organizaciones relacionadas con
la industria de software, partiendo de la información abordada en este componente desarrollar el taller sobre
metodologías de desarrollo de software propuesto.

Elementos para tener en cuenta en el taller:

● Seleccionar diferentes fuentes de información relacionadas con las metodologías de desarrollo de

software.
● Detallar las características que identifican a los marcos de trabajo tradicionales y los marcos de
trabajo ágiles.
● Utilizar imágenes de construcción propia o que tengan los derechos respectivos de uso.

Lineamientos para la entrega del producto:

● Producto para entregar: documento con el desarrollo del taller propuesto.
● Formato: PDF o Word.
● Extensión: libre.
● Para hacer el envío del producto remítase al área de la actividad correspondiente y acceda al espacio para el
envío de la evidencia: taller sobre metodologías de desarrollo de software. GA2- 220501093AA1-
EV01.

J. Evidencia conocimiento: GA1-220501093-AA1-EV02 infografía sobre metodologías

de desarrollo de software
Realizar una investigación corta profundizando en las metodologías de desarrollo de software que existen en
la industrial y a partir de esta investigación construir una infografía en la que se resuman las principales
características, ventajas y desventajas de 3 marcos de trabajo ágiles y tres marcos de trabajo tradicionales.

Elementos para tener en cuenta en la infografía:

Debe incluir tres marcos de trabajo ágiles y tres marcos de trabajo tradicionales.
Debe incluir un marco de trabajo tradicional y un marco de trabajo ágil que no se haya desarrollado durante
el componente formativo 6.
Utilizar imágenes de construcción propia o que tengan los derechos respectivos de uso.

Lineamientos para la entrega del producto:

● Producto para entregar: infografía y metodologías de desarrollo.
● Formato: PDF o Word.
● Extensión: libre.
● Para hacer el envío del producto remítase al área de la actividad correspondiente y acceda al espacio para el
envío de la evidencia: infografía sobre metodologías de desarrollo de software. GA1-
220501093AA1-EV02.

K. Evidencia de desempeño: GA1-220501093-AA1-EV03 Foro. Especificación de la metodología

a aplicar Argumentar y debatir sobre la metodología de desarrollo a aplicar en el proyecto por medio
del foro dispuesto para este fin. GFPI-F-135 V01
Elementos para tener en cuenta en la actividad:
● Recuerde que toda participación en el foro debe presentar una argumentación clara, con buena ortografía.
 ● Apoyar cada argumentación teniendo en cuenta los siguientes elementos de las metodologías:
○ Origen.
○ Características / Principios.
○ Elementos / Roles / Herramientas de apoyo.
○ Gráfica resumen.
Debe comentar las argumentaciones realizadas por otros.

Lineamientos para la entrega del producto:

● Producto para entregar: argumentación en el foro.
● Extensión: libre.
● Para hacer el envío del producto remítase al área de la actividad correspondiente y acceda al espacio
para el envío de la evidencia: Foro. Especificación de la metodología a aplicar. GA1-
220501093-AA1-EV03.

L. Evidencia de producto: GA1-220501093-AA1-EV04 documento identificando la

metodología para el proyecto de desarrollo de software

Teniendo en cuenta la información recopilada y la idea de proyecto selecciona realizar un informe donde se
describa y justifique la metodología de desarrollo de software a utilizar.
Elementos para tener en cuenta en el informe:

● Se deben seguir las normas básicas de presentación de un documento escrito, es decir el documento
debe tener como mínimo una portada, introducción, desarrollo y bibliografía.
● El informe debe evidenciar una justificación clara de la selección de la metodología respecto al proyecto
a desarrollar.
● Debe incluir una descripción del contexto y características del proyecto.
● El informe debe evidenciar el uso de filtros tales como tamaño del proyecto, periodicidad de
realimentación con el cliente, estado de la tecnología, etc.

Lineamientos para la entrega del producto:

● Producto para entregar: informe.
● Formato: PDF o Word
● Extensión: libre.
● Para hacer el envío del producto remítase al área de la actividad correspondiente y acceda al espacio para el
envío de la evidencia: documento identificando la metodología para el proyecto de desarrollo
de software. GA1-220501093-AA1-EV04.

4. ACTIVIDADES DE EVALUACIÓN (6 HORAS )

Continuando con el proceso de aprendizaje, es el momento que el aprendiz aplique o transfiera el aprendizaje
desarrollado en la fase anterior. En este momento se propone desarrollar las siguientes actividades:

 Teniendo en cuenta el tema Metodologías de desaííollo de softwaíe , responda y socialice las

siguientes preguntas en grupo:
o Qué características debe tener la metodología SCRUM?
o Cuales son las fases y disciplinas de RUP?
o Entre los marcos de trabajo ágiles explique las características y ventajas de la
programación extrama XP
G F P I- F- 13 5 V 01
o Con su instructor líder realice una mesa redonda en donde expongan las conclus i o n e s y u n
breve resumen de lo aprendido en clase sobre Metodologías de desarrollo de Software.
 o Con su equipo de trabajo defina cada una de las características de la Metodología
Desarrollo rápido de aplicaciones RAD.
o Realice una presentación, utilizando las TIC, en donde socialice la importancia de la
Planeación de proyectos de Software
Evidencias de Aprendizaje
Evidencias de Desempeño:
Especificación de los requerimientos
funcionales y no funcionales del
software.
GA2-220501092-AA4-EV01
Evidencias de conocimiento: Taller
para la determinación de las
especificaciones funcionales del
software y metodología a utilizar.
GA2-220501092-AA5-EV01
Evidencia de producto: Informe de
evaluación de los requerimientos.
GA2-220501092-AA5-EV02
Evidencias de conocimiento: Taller
sobre metodologías de desarrollo de
software.
GA1-220501093-AA1-EV01
Evidencias de conocimiento:
Infografía sobre metodologías de
desarrollo de software.
GA1-220501093-AA1-EV02
Evidencia de desempeño: Foro.
Especificación de la metodología a
aplicar.
GA1-220501093-AA1-EV03
Evidencia de producto: Documento
identificando la metodología para el
proyecto de desarrollo de software.
GA1-220501093-AA1-EV04
Criterios de Evaluación Técnicas e Instrumentos de
Evaluación
Genera la documentación de la
especificación de requisitos de IE-GA2-220501092-AA4-EV01
acuerdo con normatividad y Lista de chequeo
estándares relacionados.
IE-GA2-220501092-AA4-EV02
Lista de chequeo
Presenta el informe de requisitos de
acuerdo con estándares
establecidos
Evalúa el informe de requisitos con IE-GA1-220501092-AA5-EV01
el cliente según las necesidades Lista de chequeo
establecidas.
Realiza cambios a la
documentación de especificación
de requisitos a partir de los IE- GA1-220501092-AA5-EV02
hallazgos encontrados. Lista de chequeo
IE-GA1-220501093-AA1-EV01
Identifica metodologías de Lista de chequeo
desarrollo de software de acuerdo
con las características del software IE-GA1-220501093-AA1-EV02
a desarrollar. Lista de chequeo
IE-GA1-220501093-AA1-EV03
Establece las actividades de análisis Lista de chequeo
de acuerdo con la metodología
seleccionada.
IE-GA1-220501093-AA1-EV04
Lista de chequeo
GFPI-F-135 V01
5. GLOSARIO DE TÉRMINOS

Cláusulas adverbiales: una cláusula adverbial es un grupo de palabras que desempeña el papel de un adverbio.
(Como todas las cláusulas, una cláusula adverbial contiene un sujeto y un verbo).

Diagrama de flujo: es un esquema de los pasos separados de un proceso en orden secuencial, que se puede adaptar
para una amplia variedad de propósitos y se puede utilizar para describir varios procesos, como un proceso de
fabricación, un proceso administrativo o de servicio o un plan de proyecto. Es una herramienta común de análisis de
procesos.

Gerundio: es una forma del verbo finalizada en “ing” que funciona como un sustantivo y tiene relación con
actividades finalizadas o concretas.

Hardware: corresponde a todas las partes físicas y tangibles de una computadora: sus componentes eléctricos,
electrónicos, electromecánicos y mecánicos, sus cables, gabinetes o cajas, periféricos de todo tipo y cualquier otro
elemento físico involucrado

Infinitivo: Es una forma del verbo antecedida por “to” que funciona como un sustantivo y tiene relación con futuras o
abstractas.

Metodología: ciencia que consta de métodos y técnicas, que se aplican sistemáticamente durante un proceso de
investigación o para solucionar una problemática.

Requerimientos: es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un
conjunto de casos de uso que describe todas las interacciones que tendrán los usuarios con el software.

Requisitos de usuarios: necesidades que los usuarios expresan verbalmente

Requisitos del sistema: son los componentes que el sistema debe tener para realizar determinadas tareas

Requisitos funcionales: servicios que el sistema debe proporcionar al finalizar el sistema

Stakeholders: interesados o participantes en un proyecto.

Software: soporte lógico, programas, parte no mecánica de un sistema. Serie de instrucciones necesarias para ejecutar
diversas aplicaciones y tareas.

Teoría general de sistemas: es un esfuerzo de estudio interdisciplinario que trata de encontrar las propiedades
comunes a entidades, los sistemas, que se presentan en todos los niveles de la realidad, pero que son objetivo
tradicionalmente de disciplinas académicas diferentes.
GFPI-F-135 V01
Verbo transitivo: es un verbo que requiere del uso de un objeto directo sobre el que recae la acción.

Verbo intransitivo: es un verbo que no requiere del uso de un objeto directo.

Verbos compuestos: son verbos que contienen una o más partículas que hacen que el significado del verbo cambie
ligera o totalmente.

6. REFERENTES BILBIOGRÁFICOS

Andrade, A. M., Del Río, C. A., y Alvear, D. L. (2019). A study on time and motion to increase the efficiency of a
shoe manufacturing company | Estudio de Tiempos y Movimientos para Incrementar la Eficiencia en una Empresa de
Producción de Calzado. Información Tecnológica, 30(3), 83–94. https://doi.org/10.4067/S0718-
07642019000300083

De Guevara, D. M. Á. L. (2014). Sistema operativo, búsqueda de la información: Internet/Intranet y correo

electrónico. UF0319. Tutor Formación. Figarola, I. (s.f.). Fonética inglesa (th).
https://www.abaenglish.com/es/fonetica-inglesa/th/

Fresno, C., C. (2018). ¿Cómo funciona internet? El Cid Editor.

https://elibronet.bdigital.sena.edu.co/es/ereader/senavirtual/36728?page=34

Gallardo, Y. (2020). Word para principiantes – 2020. [Video]. YouTube

https://www.youtube.com/watch?v=4ooZlyprmc

Gaskin, S., Vargas, A., & Martin, C. L. (2011). Go! with Microsoft Word 2013, Introductory. Langara College. Gómez
de Silva, G., A., y Briseño, A. (2008). Software (pp. 23–44). Cengage Learning.
https://link.gale.com/apps/doc/CX3004400004/GVRL?u=sena&sid=GVRL&xid=d8990326

Ibarra, S., J. I. (2013). Manual sistema operativo, búsqueda de la información: Internet/intranet y correo electrónico.
Editorial CEP, S.L. https://elibronet.bdigital.sena.edu.co/es/ereader/senavirtual/50724?page=19

Ibiza, D. (2019). Tutorial Trello: Guía de uso con ejemplos reales prácticos. [Video]. YouTube.
https://www.youtube.com/watch?v=_UB44coH3SM&feature=youtu.be

Ladrón de Guevara, M. (2018). Sistema operativo, búsqueda de la información: internet/intranet y correo

electrónico UF0319. Editorial Tutor Formación.
https://elibronet.bdigital.sena.edu.co/es/lc/senavirtual/titulos/44263

Moure, O.(1999). El acento en las palabras de dos sílabas.

http://www.ompersonal.com.ar/ompronounce/unit11/page1.htm
GFPI-F-135 V01
Naranjo, G., M. R. (2010). Manual Ofimática básica en formación continua. Formación para el empleo.
Editorial CEP, S.L
https://elibro-net.bdigital.sena.edu.co/es/ereader/senavirtual/50987?page=1

Pressman, R. (2010). Ingeniería del software, un enfoque práctico. McGraw-Hill.

Real Academia Española. (1970). Diccionario de la lengua española (Vol. 19). Espasa-Calpe.
Systems, V. (2013). Inglés: grado superior. McGraw-Hill
https://elibro- net.bdigital.sena.edu.co/es/ereader/senavirtual/50221?page=1

Valentín, L., G.M. (2015). Ofimática. Editorial CEP, S. L.

https://elibronet.bdigital.sena.edu.co/es/ereader/senavirtual/51049?page=16

7. CONTROL DEL DOCUMENTO

Nombre Cargo Dependencia Fecha

Autor (es) José Yesid Villamizar INSTRUCTOR CEDRUM 10/10/2022

Torres

8. CONTROL DE CAMBIOS (diligenciar únicamente si realiza ajustes a la guía)

Nombre Cargo Dependencia Fecha Razón del Cambio

Autor (es)

GFPI-F-135 V01