0% encontró este documento útil (0 votos)
0 vistas69 páginas

Proyecto Final Progra

Jhon de la casa de los famosos en vivo en español y el original de la casa de los famosos en vivo en español
Derechos de autor
© All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
0 vistas69 páginas

Proyecto Final Progra

Jhon de la casa de los famosos en vivo en español y el original de la casa de los famosos en vivo en español
Derechos de autor
© All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como DOCX, PDF, TXT o lee en línea desde Scribd

Portada

Centro Escolar: José María peralta Lagos

Asignatura: “Desarrollo de aplicaciones de software


para la solución de problemas”

Docente: José Israel Aquino

Grado y sección: 2° ITSI “B”

Año: 2026

Integrantes

 Luis Ademir Maldonado Villanueva


 Demian Ernesto Maldonado Vilanueva
 Melvin Francisco Ortiz orellana
 Cristian Antonio santos campos


Contenido
ETAPA DE INFORMARSE.........................................................................................................3
Etapa de planificación.........................................................................................................17
Etapa de decidir...................................................................................................................24
Etapa de ejecutar................................................................................................................ 31
Etapa de controlar...............................................................................................................44
Etapa de Valorar.................................................................................................................. 56
ETAPA DE INFORMARSE
Introducción

Hay una empresa de tecnología llamada Electro Tech que se dedica a la venta de
computadoras que tiene un problema con su inventario está perdiendo dinero porque no
tiene una buena gestión de que productos tienen, cuales están agotados o estancados y
cuáles son los más vendidos nosotros ofrecemos una solución con un software que calcule y
avise los resultados como los promedios de ventas, productos agotados, producto más
popular, producto estancado.
Objetivo General

Desarrollar un programa en C++ para registrar el inventario, ventas, promedio más alto y
bajo de electrónicos

Objetivos específicos

Realizar una investigación documental sobre desarrollo de software s

Investigar sobre métodos y metodologías de ingeniería de software

Desarrollo del trabajo

Los equipos de trabajo seleccionan una situación problemática para desarrollar el


proyecto

La situación problemática que tiene una empresa que es que está perdiendo dinero al no
tener una cuenta de cuantos productos tienen, cuales están agotados, que se vende más o
que es lo que no vende

Cada equipo de estudiantes realiza una investigación documental sobre desarrollo de


software

Es un proceso estructurado que consiste en crear un programa informático, desde su


concepción hasta su implementación final. Este proceso implica una serie de etapas que
incluyen la planificación, diseño, documentación, codificación, pruebas, ejecución y
mantenimiento del software.

Etapas:

Planificación: Trabajar en el análisis de requisitos del cliente o de quien demanda la


creación del software.
Diseño: elaboración de la arquitectura del software, elección de las tecnología y definición
de las bases de datos

Implementación: los especialistas en ingeniería de software se encargan de la escritura del


código (programación), examinando que el proyecto avance en sintonía con las demandas
originales.

Pruebas: consiste en buscar posibles fallos, haciendo una revisión de código para detectar
errores y concretar la depuración necesaria

Documentación: se registran los pasos a modo de informe

Mantenimiento: incluye el mantenimiento para solucionar fallos, incorporar características


y optimizar el rendimiento

Ciclo iterativo: En la metodología ágil, estos pasos pueden repetirse para perfeccionar el
producto en cada iteración

Los estudiantes de cada equipo investigan sobre métodos de ingeniería de software


utilizados en el desarrollo de sistemas de información.

La ingeniería de software es una diciplina formada por un conjunto de métodos,


herramientas y técnicas que se utilizan en el desarrollo de los programas informáticos.

Por lo tanto, es un proceso que incluye el análisis previo de la situación, el diseño del
proyecto, el desarrollo de software, las pruebas necesarias para confirmar su correcto
funcionamiento y la implementación del sistema.

Ciclo de Vida del Software

Está formado por cuatro etapas: concepción, elaboración, construcción y transición.

La concepción fija el alcance del proyecto y desarrolla el modelo de negocio; la elaboración


define el plan del proyecto, detalla las características y fundamenta la arquitectura; la
construcción es el desarrollo del producto; y a transición es la transferencia del producto
terminado a los usuarios.

Una vez se completa este ciclo, entra en juego el mantenimiento del software. Se trata de
una fase donde se solucionan los errores descubiertos.

Metodología de cascada (Waterfall)

Es un enfoque lineal y secuencial en el que las etapas del desarrollo de software se llevan a
cabo de forma secuencial, como una cascada. Cada fase depende de la finalización exitosa
de la fase anterior y no permite cambios retrospectivos. Esta metodología es ideal para
proyectos con requisitos bien definidos y estables desde el principio.

Modelo en V

Es una metodología que enfatiza la realización de pruebas de manera temprana y


exhaustiva en el ciclo de desarrollo de software. Esta metodología se basa en un enfoque de
desarrollo descendente, donde las etapas de validación y verificación son cruciales. Es
especialmente útil en proyectos en los que la calidad y la confiabilidad son prioritarias.

Desarrollo Rápido de Aplicaciones (RAD)

Se centra en la entrega rápida de software funcional a través de ciclos iterativos cortos.


RAD se basa en la colaboración estrecha entre los desarrolladores y los usuarios finales
para acelerar el proceso de desarrollo y garantizar una mayor satisfacción del cliente.

Conceptos y técnicas clave de Desarrollo de software

Conceptos

Iterativo e Incremental: El proyecto se divide en pequeñas partes manejables (iteraciones


o Sprint) que suman valor funcional en cada entrega.

Colaboración Activa: Énfasis en la interacción entre los miembros del equipo y con el
cliente final para asegurar que se cumple con los requisitos.
Adaptabilidad: Capacidad para aceptar cambios en los requerimientos, incluso en etapas
avanzadas del desarrollo.

Equipos Autoorganizados: Los equipos tienen autonomía para decidir cómo abordar el
trabajo técnico.

Mejora Continua: Reflexión constante sobre el proceso para optimizarlo en el siguiente


ciclo.

El Manifiesto Ágil (2001): Cuatro valores fundamentales: individuos e interacciones sobre


procesos; software funcional sobre documentación exhaustiva; colaboración con el cliente
sobre negociación contractual; respuesta al cambio sobre seguir un plan.

Técnicas

Scrum: Es un marco de trabajo sencillo creado por Ken Schwaber y Jeff Sutherland,
utilizado para trabajar en proyectos complejos. Es un marco de gestión de proyectos de
metodología ágil que ayuda a los equipos a organizar y supervisar su trabajo mediante un
conjunto de valores, principios y prácticas. Scrum anima a los equipos a aprender a través
de la experiencia, a autoorganizarse mientras abordan un problema.

El trabajo se efectúa en sprint y los equipos que trabajan con Scrum se reúnen a diario para
analizar las tareas activas y los obstáculos.

Roles:

Product Owner: Define las prioridades y gestiona las pendientes (backlog)

Scrum Master: Es quien lidera el equipo, su función principal es la de despejar los


obstáculos para facilitar el proceso SCRUM

Equipo de desarrollo: Realiza el trabajo necesario para completar las tareas del sprint

Eventos clave:

Sprint Planning: planificación del trabajo a realizar en el sprint.

Daily Scrum: reunión diaria para sincronizar el trabajo y ajustar el plan.

Sprint Review: revisión del trabajo completado al final del sprint.


Sprint Retrospective: reflexión sobre el proceso para mejorarlo en el siguiente sprint.

Programación Extrema (XP): XP se centra principalmente en los aspectos técnicos del


proyecto. Es muy exigente con la forma en que trabajan los equipos, ya que su principal
objetivo es ayudarlos a entregar código de alta calidad a un ritmo sostenible. En resumen,
XP lleva las buenas prácticas al extremo. Por ejemplo, insiste en realizar pruebas incluso
antes de que se desarrolle el código para producción.

Desarrollo de Software Adaptativo (ASP): Desarrollado por Jim Highsmith y Sam Bayer,
ASP sigue el principio de adaptación continua, adaptándose al cambio sin resistencia. Hay
tres ciclos dinámicos en ASP:

Especular

Colaborar

Aprender

Estos ciclos se basan en el aprendizaje continuo y la sólida colaboración entre


desarrolladores y clientes para afrontar los constantes cambios del mundo empresarial.

Desarrollo Dirigido por Funcionalidades (FDD): FDD funciona principalmente para


equipos grandes con muchas personas. Desarrollado por Jeff De Luca y Peter Coad, FDD
se centra en iteraciones cortas que facilitan entregas de productos sostenibles rápidamente
(2 semanas). El Desarrollo Dirigido por Funcionalidades aborda problemas de
comunicación o proyectos en los que la comunicación representa un gran desafío.

Método de Desarrollo Dinámico de Software (DSDM): Desarrollado por un grupo de


profesionales expertos en desarrollo de software, DSDM se centra en proyectos con plazos
y presupuestos ajustados. Su principal objetivo es la entrega frecuente de productos con un
desarrollo progresivo.

Kanban: Kanban fue desarrollado por David Anderson como respuesta a algunos desafíos
que enfrentaban otras metodologías ágiles, en particular Scrum. Ofrece un enfoque visual
para la aplicación de las practicas agiles, las tareas se ven representadas en forma de tarjetas
dentro de un tablero y las etapas, en columnas. A medida que los distintos miembros del
equipo trabajan con esas tareas, las “tarjetas” pasan de la columna de trabajo pendiente a la
que representa a la nueva etapa en la que se encuentra la tarea.

Estas metodologías se volvían ineficaces al enfrentar los mismos desafíos que amenazaban
el enfoque tradicional en cascada. El ciclo de sprint de dos a tres semanas de Scrum se
volvió demasiado largo para los clientes debido a la presión que ejercía sobre la gestión y la
planificación del proyecto.

Informe de Desarrollo de software

Es el proceso de crear software funcional mediante codificación e integración. El proceso


incluye pruebas unitarias y de integración, aunque no incluye pruebas de nivel superior
como las pruebas de sistema.

La construcción es un aspecto del ciclo de vida del desarrollo de software y está integrada
en los diversos modelos de procesos de desarrollo de software, con distintos niveles de
enfoque en la construcción como una actividad independiente de las demás. En el modelo
en cascada, el desarrollo de software consta de fases secuenciales que incluyen el análisis
de requisitos, el diseño y la planificación, los cuales son prerrequisitos para comenzar la
construcción. En un modelo iterativo como Scrum, el prototipado evolutivo o la
programación extrema, la construcción se considera una actividad que ocurre
simultáneamente o superpuesta a otras actividades.

La planificación de la construcción puede incluir la definición del orden en que se crean e


integran los componentes, los procesos de gestión de la calidad del software y la asignación
de tareas a equipos y desarrolladores.

Para facilitar la gestión de proyectos, se pueden medir numerosos aspectos de la


construcción; estos incluyen la cantidad de código desarrollado, modificado, reutilizado y
destruido, la complejidad del código, las estadísticas de inspección del código, las tasas de
fallas corregidas y fallas encontradas, y el esfuerzo invertido. Estas mediciones pueden ser
útiles para aspectos como garantizar la calidad y mejorar el proceso.
compendio de información sobre los métodos de desarrollo de software en forma ágil

Definición: Las metodologías agiles en desarrollo de software son un conjunto de


principios y prácticas que buscan mejorar la gestión y la ejecución de proyectos en entornos
de alta incertidumbre. Nacidas a partir del Manifiesto en 2001, estas metodologías priorizan
la colaboración, la entrega continua de valor y adaptabilidad ante los cambios

Principios:

Individuos e interacciones sobre procesos y herramientas.

Software funcionando sobre documentación extensiva.

Colaboración con el cliente sobre negociación de contratos.

Responder al cambio sobre seguir un plan.

Métodos agiles más comunes: Kanban, Scrum, Extreme Programming (XP), Marco de
proyecto adaptativo (AFP), Gestión extrema de proyectos (XPM), Desarrollo adaptativo de
software (ASD), Método de desarrollo de sistemas dinámicas (DSDM) y Desarrollo en
funcionalidades (FDD)

Ventajas:

Entrega rápida: se divide el proyecto en fases pequeñas, permitiendo entregar


funcionalidades en menos tiempo.

Mayor Flexibilidad: es posible modificar el software en cualquier momento, sin afectar


todo el proyecto.

Mejor calidad del producto: las pruebas continuas ayudan a detectar errores temprano

Mayor satisfacción del cliente: el software se desarrolla según las necesidades reales del
usuario, no solo en base a un plan inicial-

Métodos ágiles

Stavru estudió el uso de métodos ágiles mediante estudios de encuestas industriales


publicadas entre 2011 y 2012. Determinaron los artículos que podían ser confiables y
recomendar que se pudiera mejorar el nivel de calidad de las investigaciones. El autor
concluyó que la mayoría de los estudios encuestados eran incompletos y no eran fiables.
Por otro lado, los autores ofrecieron algunas recomendaciones para elevar la calidad de la
investigación.

Las recomendaciones incluyen examinar la tasa de uso de métodos ágiles en comparación


con métodos alternativos; Examina la tasa de uso del método ágil a nivel organizacional.
Además, realizar investigaciones sobre el uso del método ágil por parte de académicos
además de la industria para reducir la brecha entre la industria y el ámbito académico,
además de aumentar la fiabilidad en la adopción generalizada del método ágil. Además,
proporcionar informes muy detallados en el futuro; por tanto, se eleva el nivel de confianza
y fiabilidad en los estudios reportados.

Campanelli y Parreiras presentaron aspectos de la investigación sobre la adaptación de


métodos ágiles en El término adaptación de métodos ágiles se refiere al problema de
seleccionar un método ágil que se adopte en la organización. Los autores analizan el
número total de artículos publicados en la zona y propusieron la que muestra el número de
artículos publicados sobre adaptación de métodos ágiles por año. Los autores clasificaron
los estudios seleccionados en dos grupos principales de categorías: categorías centradas en
aspectos de investigación como el tipo de investigación y validación de la investigación, y
categorías centradas en aspectos técnicos como el método ágil cubierto y los criterios para
la adaptación del método.

Métodos Ágiles Híbridos

Selleri Silva, et al. presentaron un estudio de revisión sobre las metodologías ágiles que
integran el Modelo de Integración de Madurez de Capacidades (CMMI), en el que se
identificaron 3193 estudios y se seleccionaron 81 para su evaluación y se clasificaron en
dos clases principales; beneficios para la organización en general y beneficios para el
proceso de desarrollo. Los resultados muestran que el uso de métodos ágiles fue útil para
alcanzar el nivel 2 y 3 de CMMI y, en algunos casos, incluso el nivel 5.
Torrecilla-Salinas et al. estudiaron la aplicabilidad de cumplir con el modelo CMMI-DEV
para empresas de desarrollo web que han seguido uno de los métodos ágiles. El estudio
repasó el estado actual de la técnica sobre este tema para responder a cinco preguntas que
posteriormente se utilizaron para analizar y evaluar los estudios seleccionados. Se
seleccionaron seis artículos para evaluación de más de 1453 estudios. Los resultados han
demostrado que en los últimos 5 años cada vez más empresas de desarrollo web se están
moviendo hacia la adopción de métodos ágiles para ayudar a certificarse frente a CMMI-
DEV.

Santana, et al. proporcionaron una revisión bibliográfica para identificar la mejora de


procesos de software (SPI) en entornos ágiles. Los autores clasificaron los artículos
revisados según los aspectos del SPI. Además, identificaron nuevos enfoques distintos para
el SPI ágil y han sugerido usar uno de los siguientes tres enfoques ágiles de SPI: enfoque de
arriba hacia abajo, el SPI ágil basado en mejorar el comportamiento y el SPI ágil basado en
mejorar las prácticas. Los autores también identificaron la diferencia entre el SPI
tradicional y el ágil, especialmente en sus objetivos. El objetivo de la SPI tradicional es
elaborar un proceso repetible que pueda mejorarse con las lecciones aprendidas. Por otro
lado, el proceso en SPI ágil debe estar listo para cambios y mejorar su capacidad para
hacerlo. Además, el autor mencionó otra diferencia relacionada con las políticas de
transferencia de conocimiento; el SPI tradicional dicta que el conocimiento debe
transmitirse a las personas basándose en algunas políticas y criterios organizativos como la
formación y el uso de documentos, mientras que el SPI ágil considera que la transferencia
de conocimiento a través de reuniones, informal y aprendizaje debe basarse en las
experiencias individuales de los miembros del equipo.

La literatura sobre la aplicación de diferentes prácticas ágiles en la Ingeniería Global de


Software (GSE) se resumió en. El término GSE se refiere a la distribución ágil a través de
fronteras culturales, temporales y geográficas. Los autores clasifican las investigaciones
según el tipo de investigación. Concluyen que la mayoría de los estudios son informes de
experiencia que contienen la experiencia en cuestiones concretas. Por otro lado, es
necesario proporcionar más validación y evaluación de la investigación. Otra conclusión
que los autores mencionaron es que es necesario analizar los desafíos y ventajas de
combinar Agile y GSE en forma de investigación de evaluación.

Una visión general del uso de métricas de software en el contexto ácil industrial es
proporcionada por. Este estudio hace tres aportaciones: primero, los autores categorizan las
métricas encontradas en los estudios empíricos ágiles y las comparan con las indicadoras
sugeridas por la literatura ágil, y concluyen que los equipos ágiles utilizan muchas métricas
sugeridas por la literatura ágil. En segundo lugar, el estudio destaca las razones de y

METODO Miscelánea

Sletholt y colaboradores realizaron una revisión bibliográfica para investigar los efectos del
uso de prácticas ágiles en los procesos de desarrollo científico de software, centrándose en
evaluar la agilidad de los proyectos científicos presentados en cinco artículos
cuidadosamente seleccionados. Los autores definieron y utilizaron un gráfico de mapeo
ágil, con elementos basados en modelos de referencia Scrum y XP para fines de evaluación
de agilidad. Los autores comparan sus hallazgos con las encuestas previamente
proporcionadas. Los resultados de estas comparaciones indicaron que los proyectos de
desarrollo de software científico que han adoptado el ágil tienen un proceso de pruebas
mejorado para comparar con los métodos tradicionales.

Un nuevo marco analítico desarrollado por Qumer y Henderson-Sellers llamado (4-DAT).


El marco propuesto se aplicó a seis métodos ágiles seleccionados, además de dos métodos
tradicionales para fines de comparación. El enfoque de evaluación se realiza en este marco
analítico para evaluar estos métodos a nivel de proceso y práctica desde cuatro
perspectivas. La evaluación tenía como objetivo seleccionar un método ágil adecuado para
un desarrollo concreto.

Rauf y Al Ghafees realizaron una encuesta industrial para estudiar el uso de prácticas ágiles
de scrum y XP en el desarrollo de aplicaciones informáticas; los autores publicaron un
cuestionario para investigar los beneficios de usar agile; se recogieron 79 respuestas de 45
empresas. Los resultados de la encuesta mostraron que el 57% de los encuestados utiliza
Scrum y, a su vez, es el método ágil más común, mientras que el 27% utiliza tanto XP como
Scrum y solo el 5% ha declarado usar solo XP. Además, los autores investigaron la
fortaleza de los beneficios frente a cada práctica ágil y exploraron los desafíos que se
enfrentan a cada práctica ágil.

Una encuesta web realizada por Begel y Nagappan a empleados que trabajan en los
procesos de producción de software. La encuesta investigó cómo los empleados de
Microsoft utilizan métodos ágiles de desarrollo de software y cómo penetran en las
prácticas ágiles de desarrollo de software y sus percepciones sobre por qué el ágil funciona
bien o mal en sus equipos de software. Las respuestas de los empleados indican que
alrededor de un tercio de los encuestados utiliza agile, y SCRUM es el método más popular,
con un 65% de los encuestados que lo usaban en su equipo, y la mayoría de los usuarios
ágiles tienen una opinión positiva al respecto.

Ficha para especificar el procedimiento de la ingeniería de software.

FICHA DE PROCEDIMIENTOS
Identificar las necesidades del cliente y la
Análisis funcionalidad del software

Elaboración de la arquitectura del software,


Diseño elección de las tecnologías y definición de
las bases de datos
Los desarrolladores escriben el código
Ejecución fuente siguiendo las especificaciones
establecidas
Consiste en buscar posibles fallos,
Pruebas haciendo una revisión de código para
detectar errores y concretar la depuración
necesaria.
Implementación de software para su
Entrega instalación y configuración.

Procesa y analiza los datos obtenidos de la ingeniería de software

Lo más relevante seria que la ingeniería de software es la diciplina que se encarga de


diseñar, desarrollar y mantener sistemas informáticos de forma organizada. Aplica
principios de ingeniería para crear programas confiables, eficientes y escalables.

Combinando metodologías y métodos de desarrollo de software, herramientas y buenas


practicas para transformas ideas en soluciones que resuelvan problemas reales.

Conclusiones

En conclusión, de todo lo que hemos investigado, investigar, y analizar de desarrollo de


software, ingeniería de software, metodologías y métodos de desarrollo nos acerca cada vez
más a nuestros objetivos

Bibliografía

Métodos de Desarrollo de Software — Diseño de Software


Desarrollo Ágil de Software【Qué es y Cómo Funciona】

Metodología Agile: TODO sobre esta forma de trabajo [2026] • Asana

¿Qué es la Ingeniería de Software? - Guía Completa

Ingeniería de software - Qué es, definición y concepto

Guía Completa sobre Metodologías Ágiles en Desarrollo de Software: Mejora la


Flexibilidad y Eficiencia de tu Equipo - TICNUS Technology Magazine

Desarrollo de software: ¿Qué es? ¿Cómo funciona?

Desarrollo de software - Qué es, características, tipos y ejemplos


Etapa de planificación
[Link] caracteriza por la elaboración del plan de trabajo, la estructuración del
procedimiento metodológico y la planificación de los instrumentos y medios de
trabajo.

El plan de trabajo es un documento que detalla los objetivos, estrategias, recursos, los
plazos y procesos para llevar a cabo el proyecto. Este mismo actúa como una guía para todo
el equipo de desarrollo de software a lo largo del proyecto, asegurando que se cumplan los
objetivos y que se entregue el producto final. Es esencial para garantizar la eficiencia de
cualquier proyecto pues al documentar de manera clara y detallada el plan, se facilita la
comunicación de los miembros del equipo. Por otro lado, la estructuración del
procedimiento metodológico implica seguir fases que guían a los desarrolladores en la
elección de técnicas y en la planificación, gestión, control y evaluación del proyecto.
Podemos usar metodologías de desarrollo de software, como el modelo cascada, modelo en
espiral, la metodología Ágil entre otras que ofrecen diferentes enfoque y beneficios para
cada etapa del ciclo de vida del desarrollo de software. Por último, la planificación de los
instrumentos y medio de trabajo se tratan de las herramientas que vamos a utilizar y los
recursos humanos como los integrantes y tecnológicos para crear y organizar el proyecto.

2. Forman equipos de tres o cuatro miembros y planifican las actividades del


proyecto; la estructura básica: el perfil del proyecto a ejecutarse para solucionar el
problema, el plan de trabajo y el cronograma.

Entre los miembros del equipo es importante tener un perfil de proyecto claro que detalle el
problema a abordar, debe incluir elementos como el nombre del proyecto, su propósito, el
plazo, objetivos y metas. Por otra parte, para plan de trabajo hay que realizar algunas
actividades en nuestro caso investigar sobre sistemas de inventario e identificar las
necesidades del usuario, diseñar el sistema etc. Por último, el cronograma es una
representación visual o textual que detalla las actividades y fechas de entrega de un
proyecto de software. Su objetico principal es planificar y controlar el tiempo, asegurar que
todas las fases se completen de manera ordenada y mantener alineado el equipo.

[Link] las alternativas de solución al problema propuesto mediante las técnicas


siguientes: lluvia de ideas, diagrama de Ishikawa, relaciones forzadas y técnica de los
grupos nominales, entre otros.

La lluvia de ideas es una buena herramienta que implica la


contribución espontanea de ideas de todos los miembros del
grupo para generar y explorar soluciones mediante mapas
mentales para nuestra problemática ayudando a superar
bloqueos mentales. El objetivo de esta es generar una gran
cantidad de ideas que luego se pueden ajustar y evaluar.

Otra técnica es el diagrama de Ishikawa también conocido


como diagrama de espina de pescado que es un método
visual para analizar las causas raíz de un problema para
nosotros en el desarrollo de software este diagrama ayuda a mostrar las posibles causas de
un problema de manera lógica. Asimismo, la relación de ideas forzada puede ayudar a
generar nuevas ideas se trata de relacionar nuestro problema con conceptos, palabras al azar
y elementos surgidos de manera aleatoria. Para finalizar la técnica de los grupos nominales
se empieza con cada miembro presentando sus ideas y luego cada uno vota por sus ideas
preferidas lo que asegura que todos tengan la misma voz.

4. Desarrollan en un diagrama de flujo la representación del proceso de solución de


problemas de la vida real y describen el procedimiento, tomando en cuenta algunas de
las siguientes actividades: recolección de requerimientos, análisis de requerimientos,
diseño de la aplicación, desarrollo de la aplicación, prueba e implantación de la
aplicación desarrollada.
Recolección de requerimientos:
se identifican las necesidades del
cliente

Análisis de requerimientos: se
verifica su viabilidad

Diseño de la aplicación:
elaboración de la arquitectura de
software

Desarrollo de la aplicación: se
escribe el código fuente
siguiendo las especificaciones

Prueba: verificación de la
calidad, identificación de errores

Implantación de la aplicación: se
lanza al entorno real y se pone a
disposición de los usuarios
5. Compara, analiza y evalúa las alternativas; luego, selecciona y justifica la
alternativa de solución.

Comparar las acciones poniéndolas lado a lado (como los distintos lenguajes de
programación que podemos usar) para identificar las diferentes similitudes y diferencias
como la facilidad de implementación, luego se estudia cada alternativa para revisar riesgos,
beneficios y recursos disponibles para evaluar ya sea el tiempo estimado o la facilidad de
mantenimiento para después seleccionar con base la evaluación la alternativa que mejor se
ajusta a nuestros objetivos en el proyecto y para finalizar justificar que se trata de
documentar la decisión explicando porque elegimos esa alternativa y no otra.

[Link] o hacen una representación de lo que piensan hacer e indican las


distintas fases del proyecto.
Fases de un proyecto

Análisis de sistemas y requisitos

Diseño y arquitectura de software

Programación e implementación

Pruebas y revisión

Mantenimiento y cuidado

Documentación
[Link] la secuencia de actividades a realizar, entre estas:

 Observación y análisis de la realidad en torno a la ingeniería de software.

La ingeniería de software se ha vuelto crucial en la sociedad moderna con un impacto en la


vida diaria ya que la mayoría de nuestras tareas tanto personales como profesionales, se
basan en software. En la actualidad se centra en crear soluciones eficientes y confiables
para problemas y desafíos tecnológicos que enfrentamos. Ya sea en desarrollo de
aplicaciones, sistemas de gestión empresarial.

 Búsqueda de información para describir el problema.

Las empresas se enfrentan a sistemas de control deficientes por estimaciones que llevan a
desabastecimiento o exceso de stock nuestro proyecto busca desarrollar un sistema de
inventario que registre las entradas, salidas y notifique cuando el stock este bajo.

 Selección de metodología de investigación.

Se decide que técnica de investigación se realizara como la entrevista, la observación, las


encuestas, y estudios de caso

 Elaboración de instrumentos para recolectar información.

Encuestas sobre dificultades del inventario, entrevista y formularlos para registrar errores
frecuentes

 Ordenamiento del material informativo.

Se organiza la información obtenida en tablas, gráficos o matrices de problemas se


clasifican las necesidades mas relevantes. Y las secundarias

 Organización de las actividades abiertas al exterior (visitas de campo y entrevistas,


entre otras).
Permiten recopilar datos directamente lo que es esencial para la toma de decisiones como
visitar bodegas para observar el proceso o entrevistar a empresas que ya usa sistemas de
inventario

 Análisis de la información.

Detectamos que el principal problema es la falta de actualización en tiempo real y se


concluimos que la empresa necesita un sistema accesible.

 Elaboración de informe.

Se redacta un documento los datos, las alternativas de solución y las ventajas y desventajas

 Presentación de resultados.

Exponemos la propuesta de solución una aplicación de inventario con reportes en tiempo


real

8. Elaboran la matriz de organización de actividades para determinar el proceso de


ejecución, las responsabilidades de cada miembro del equipo, el tiempo de ejecución y
los recursos a utilizar.

Integrantes problemática Tiempo de ejecución


Lus Ademir Desarrollo de un programa Del 27/03/26 hasta el
de inventario para una 24/04/2026
empresa
Demian Ernesto

Melvin Francisco
Cristian Antonio
Etapa de decidir
1. Analiza la factibilidad técnica y económica para la ejecución sobre el desarrollo
de aplicaciones de software para la solución de problemas.

evaluamos si nuestro equipo tiene la tecnología y las competencias técnicas requeridas y


para la factibilidad económica analizar los costos y beneficios, así como la rentabilidad del
proyecto. Consideramos que si es factible desarrollar el sistema utilizando C++ ya que
poseemos conocimientos básicos de programación y acceso a computadoras e internet y no
requiere una inversión significativa, ya que utilizaremos herramientas gratuitas. Por lo que
es viable económicamente.

2. Discute sobre los elementos siguientes: el tiempo asignado a las actividades, los
recursos requeridos, el diagrama organizacional y la programación de las
actividades entre otros; y valora el más eficaz de desarrollar para las
actividades planificadas y alcanza una decisión consensuada.

Ya discutimos que el tiempo estimado es de un mes y que cado uno tiene una semana para
terminar su actividad además del orden de cada actividad, sobre los recursos tenemos
computadoras, software de programación y conocimiento básico. El diagrama
organizacional es una buena herramienta grafica para visualizar como se estructura una
organización por ejemplo como se distribuyen las responsabilidades, puestos de trabajo y
funciones dentro de la organización. Nosotros ya programamos las actividades, el orden de
estas y las fechas de finalización. En conjunto elegimos que la programación de actividades
es la forma más eficaz para desarrollar las actividades que planificamos.

3. Utilizan las siguientes técnicas de toma de decisiones: método Delphi, campo de


fuerzas, evaluación de alternativas (pros y contras):

El método Delphi es una técnica de investigación estructurada e iterativa que busca obtener
un consenso fiable sobre decisiones complejas o inciertas basándose en la opinión anónima
de un panel expertos. A través de rondas de cuestionarios, el análisis de las respuestas,
rondas iterativas hasta alcanzar un consenso. El análisis de campo de fuerzas evalúa las
fuerzas impulsoras (a favor) y restrictivas (en contra) que afectan una situación para un
cambio. La evaluación de alternativas permite tomar decisiones al analizar y comparar
diferentes opciones para valorar sus características y consecuencias.

4. Realiza la toma de decisiones a partir de las siguientes preguntas: ¿Cuáles


actividades son factibles de realizar en función de los recursos?, ¿hay
coherencia entre las actividades y el problema?, ¿están explicitas las
especificaciones técnicas cuando son requeridas?, ¿el proyecto se adapta a los
recursos y oportunidades disponibles?, ¿Qué componentes del proyecto
podrían llevar a alteraciones ambientales?, ¿es adecuado el plazo para la
realización de las actividades?, entre otras.

¿Las actividades son factibles?

Si, todas tanto la realización del programa como las actividades para conseguirlo

¿Tiene coherencia con el problema?

sí, hay coherencia porque nuestra problemática es que una empresa tiene un problema de
gestión en su inventario y nuestras actividades son para diseñar y desarrollar el programa
para resolver el problema.

¿Las especificaciones están explicitas?

Si, las especificaciones están disponibles como el software de programación que usaremos,
así como los requisitos del programa

¿Se adapta a los recursos y oportunidades?

por supuesto podemos hacerlo con nuestros recursos, disponemos del software de
programación C++, de internet y estamos unidos como equipo

¿Lleva a alteraciones ambientales?

Como tal el software no genera residuos físicos, pero si puede tener efectos indirectos
como: el consumo energético de servidores y centro de datos. Al menos en nuestro proyecto
no alteraríamos el medio ambiente
¿Es adecuado el plazo?

Si, para nuestro objetivo lo es ya que el proyecto no es tan complejo tenemos un mes para
progresar y las actividades asignadas a cada integrante por semana

5. Distribuye las actividades con base en una responsabilidad personal

Actividades Integrantes Responsabilidad


Análisis de requisitos Luis Ademir Verificar su viabilidad
Diseño Demian Ernesto Elaborar la arquitectura de
software
Desarrollo Cristian Antonio Escribir el código de
acuerdo a las
especificaciones
Pruebas Melvin Francisco Verificar la calidad e
identificar los errores

6. Establecen reuniones de trabajo para verificar el avance del proyecto.

Nos reunimos cada tres días para revisar como vamos avanzando en las actividades
asignadas a cada miembro del equipo en estas reuniones compartimos si ya finalizamos la
actividad que se nos asignó si es así verificamos si esta contestada correctamente si no se
corregimos lo que este mal y si no termino la actividad se le avisa hasta que fecha tiene
para terminarla y entregar su parte

7. Discuten las estrategias de solución de solución propuestas, valorando los


problemas, riesgos y beneficios asociados a cada una de las alternativas.

Al analizar las alternativas que teníamos para resolver el problema de inventario


ineficiente de la empresa como usar un Excel para registrar todo manual, adquirir un
software ya hecho o por ultimo desarrollar uno propio, al usar estas técnicas para
plantear alternativa como elaborar un diagrama de Ishikawa que nos permitió identificar
las causas de la problemática con eso en mente discutimos cada opción que teníamos
para resolver la problemática y concluimos que Excel era limitado y propenso a fallos,
el software ya hecho no se adaptaba del todo a nuestras necesidades, mientras que
desarrollar nuestro propio sistema en C++ representaba más esfuerzo pero nos
garantizaba manejarlo de acuerdo a nuestras necesidades para resolver la problemática
de la empresa, capaz de calcular el stock, si el producto está agotado y el promedio de
venta.

8. Determina si la solución que se pretende tomar en realidad resuelve el


problema que se pretende solucionar.

Para determinar si la solución que proponemos realmente puede resolver el problema de


la empresa, verificamos que el sistema de inventario diseñado en C++ pueda cumplir
con estas funciones: calcular de manera precisa el stock disponible, también alertar cual
stock está agotado y calcular el promedio de ventas. Si estas funciones se implementan
correctamente, el sistema permitirá un control más eficiente del inventario, reducirá las
pérdidas económicas y facilitará la elección adecuada de los productos más vendidos.
Podemos concluir que la propuesta es viable y da solución a las necesidades de la
empresa.

9. Discuten la situación planteada y toman una decisión sobre cual metodología o


patrón de desarrollo de software utilizar.

como desarrolladores tomamos la decisión de que metodologías utilizaríamos para


desarrollar nuestro inventario, al final hemos seleccionado la metodología Scrum
debido a su enfoque iterativo e incremental, el cual es ideal para abordar la
problemática de saturación y errores en el almacenamiento e inventario de la empresa.
Dado que el sistema de inventario requiere una lógica precisa en C++ para evitar
discrepancias en los productos, Scrum nos permite dividir el desarrollo en ciclos cortos
denominados Sprints. Esto facilita la detección temprana de fallos en el código y
asegura que cada funcionalidad —como la validación de stock y el registro de entradas
— sea probada y corregida constantemente. Al implementar esta metodología,
garantizamos una organización eficiente entre las responsabilidades del equipo y una
capacidad de respuesta ágil ante los riesgos detectados. En nuestra discusión guiada
sobre factibilidad." Complementando esta organización, utilizaremos el patrón de
desarrollo MVC (Modelo-Vista-Controlador), el cual permite estructurar el código
separando la lógica del inventario de la interfaz de usuario, asegurando así que el
sistema sea robusto, fácil de mantener y libre de errores en la manipulación de datos."

10. Decide sobre las actividades definitivas, y organiza y distribuye las


responsabilidades entre sus componentes.

Para resolver la problemática del inventario y evitar la saturación en el almacenamiento,


el equipo ha definido las siguientes actividades definitivas y asignado roles específicos
basados en la estructura del proyecto
Actividad Entregable Técnico (C+ Duración
Responsable
Definitiva +) Estimada

Diseño del Estructura y persistencia


Luis Ademir 7 días
Modelo en archivos

Funciones de validación
Lógica del
Demian Ernesto de stock y reglas para 7 días
Controlador
evitar saturación.

Interfaz de menús por


Diseño de la Melvin Francisco,
consola y formato de 7 días
Vista Cristian Antonio
tablas de datos.

Programa final funcional y


Integración y
Todo el Equipo reporte de errores 7 días
Pruebas
corregidos.

11. Se pregunta: ¿Qué riesgos y peligros se corren?, ¿va a funcionar?, entre otras.

¿Qué puede salir mal?

La falta de tiempo si alguien no puede terminar su actividad, mala organización, el sistema


puede estar mal diseñado, el inventario puede no funcionar, dificultades en el trabajo en
equipo, falla de internet

¿Funcionara la solución?

Se evalúa si el proyecto es viable, es decir, si se cuenta con los recursos necesarios como
tiempo, herramientas, conocimientos y apoyo. Para nosotros es viable y puede funcionar,
pero, si no tenemos una buena planificación puede fallar

12. Pueden realizar las siguientes técnicas:


 Debate grupal.

Permite que todos los miembros del equipo participen dando sus opiniones e ideas. Lo que
ayuda a ver el problema desde diferentes puntos de vista y elegir la mejor solución de
manera conjunta.

 Diagrama espina.

Es una herramienta visual que se utiliza para identificar las causas de un problema. Se
organiza en forma de “espina de pescado”, donde el problema principal se coloca en la
cabeza y las posibles causas en las ramas. Esto facilita entender el origen del problema.

 Discusión guiada sobre factibilidad y pertinencia.

En esta técnica, un docente o líder orienta al grupo mediante preguntas o indicaciones. Su


objetivo es ayudar al equipo a analizar si la solución propuesta es:

Viable: que se puede realizar con los recursos disponibles

Pertinente: que es adecuada y soluciona al problema

En conclusión, el uso de estas técnicas favorece el trabajo en equipo, mejorar la


comunicación entre los integrantes, tomar decisiones fundamentadas además de apoyar al
éxito del proyecto, al ayudar a prevenir errores, organizar mejor el trabajo y asegurar que la
solución propuesta sea adecuada y posible de realizar.

Integrantes Trabajo Fecha de Fecha de entrega


asignación
Luis Ademir Análisis de requisitos 20/04/2026 26/04/2026
Demian Ernesto Diseño 27/04/2026 03/05/2026
Cristian Antonio Desarrollo 04/05/2026 10/05/2026
Melvin Francisco Pruebas 11/05/2026 17/05/2026
Etapa de ejecutar
[Link] fomenta la participación en el proceso sobre el desarrollo de aplicaciones de
software para la solución de problemas. Realiza la actividad de la cual es responsable,
tomando en cuneta el tiempo necesario para cada actividad.

[Link] la planificación definitiva del trabajo, determinando las tareas a realizar,


el tiempo y los responsables. El docente verifica que las competencias, los
conocimientos y resultados contemplados en el proyecto estén presentes durante la
ejecución.

Matriz

Equipo Actividades Descripción Fecha de Fecha de finalización


inicio
Luis Análisis de Identificar las 20/4/202 26/4/2026
requerimientos necesidades 6
Demian Diseño Crear diagramas 27/4/202 3/5/2026
6
Cristian Desarrollo Escritura del código 4/5/2026 10/5/2026
Melvin Pruebas Probar y corregir 11/5/202 17/5/2026
errores 6

[Link] las propuestas de trabajo tecnológico que definen los aprendizajes que
conllevan se realización y los métodos de trabajo para realizar las actividades del proyecto.

PROPUESTA: Como equipo de trabajo observamos que la empresa ElectroTech tiene


problemas Con su inventario por lo que está teniendo perdidas. Nuestro equipo tiene una
propuesta para solucionar el problema de inventario, nuestro

Problemas del inventario de empresas

Desabasto de productos o exceso de mercancía estancada.

Sistema que no es confiable, ineficiente o falta de software automatizado.

Pérdidas económicas.

Propuesta a solución:
Solución: Implementación de un sistema de gestión de inventario (software a medida).

Componentes: Base de datos en C++ para establecer una solución al problema de


inventario

Aprendizajes Esperados

Técnicos: desarrollo de software y automatización de procesos.

Logísticos: Métodos de evaluación de inventarios y cálculo de stock de seguridad.

Gestión: Trabajo en equipo, metodologías ágiles y resolución de problemas reales

Métodos de Trabajo

Metodología: Uso de Scrum para dividir el proyecto en tareas cortas de dos semanas.

Nuestra propuesta de trabajo es utilizar la metodología Scrum que es un marco de trabajo


ágil diseñado para gestionar proyectos de forma flexible en la cual se entrega el producto en
sprints iterativos y adaptables

Uso de Scrum para dividir el proyecto en tareas cortas de dos semanas.

Proceso

1. Análisis: Entrevistar al personal del almacén.

2. Diseño: Crear los diagramas del sistema.

3. Desarrollo: Programar o configurar la herramienta tecnológica.

4. Pruebas: Validar el sistema con datos reales.

5. Roles: Dividir el equipo en Líder de Proyecto, Diseñador, Programador y Analista de


Datos.

[Link] las actividades definidas en el plan de trabajo. El docente está a disposición


de los estudiantes que requieren asesoramiento y, en algunos casos, apoyo.
1. Introducción y Fundamentación Pedagógica

El modelo educativo contemporáneo prioriza el desarrollo de la autonomía en el estudiante,


transformando el aula en un espacio de construcción activa. La premisa de trabajar
mediante actividades definidas en un plan de trabajo, donde el docente se sitúa a
disposición de los alumnos para brindar asesoramiento y apoyo, rompe con la estructura
tradicional de la clase magistral. Este enfoque encuentra su sustento teórico en el
constructivismo social de Lev Vygotsky, específicamente en el concepto de la Zona de
Desarrollo Próximo. El plan de trabajo plantea un desafío que el alumno puede resolver por
sí mismo, mientras que el docente interviene de manera estratégica aportando el andamiaje
necesario cuando se detectan dificultades conceptuales o procedimentales.

2. El Plan de Trabajo como Guía de Ruta

El plan de trabajo es el instrumento didáctico maestro que hace posible la autonomía del
estudiante. No es un simple cronograma de entregas; es un mapa de aprendizaje detallado
que debe ser diseñado minuciosamente por el docente antes de iniciar la unidad. Para que
este documento permita al alumno trabajar de forma independiente sin caer en el caos, debe
contener los siguientes elementos esenciales:

 Objetivos claros: Enunciados que explican la competencia que se busca desarrollar.

 Secuencia de actividades: Tareas ordenadas de forma lógica y progresiva.

 Recursos seleccionados: Enlaces, lecturas o herramientas digitales validadas para


evitar la pérdida de tiempo en fuentes no confiables.

 Criterios de evaluación: Rúbricas transparentes que detallan los niveles de calidad


exigidos para cada entrega o avance.
Tabla de Actividades

Integrantes Responsabilidades Actividades para el


desarrollo del programa
Luis Ademir Identificar las necesidades y El menú y las opciones
definir las funciones del
sistema
Demian Ernesto Diseño Crear diagrama de flujo
Cristian Antonio Desarrollar el sistema Registrar artículos y
mostrar inventario
Melvin Francisco Realizar pruebas y corregir Buscar producto y valor
errores total

3. El Nuevo Rol Docente: Facilitador y Asesor

En este esquema, el profesor no desaparece ni disminuye su carga de trabajo; su función se


desplaza de la exposición de contenidos hacia la consultoría y la guía personalizada. Estar
"a disposición" de los alumnos implica una gestión del aula dinámica y flexible que se
ejecuta a través de tres acciones clave:

 Monitoreo Itinerante: El docente recorre el espacio de trabajo para observar los


avances, detectar bloqueos cognitivos y apoyar a los estudiantes que no se atreven a
externar sus dudas.

 Indagación Socrática: Ante una consulta, el facilitador no entrega la respuesta


correcta de inmediato. Utiliza preguntas guía para que el estudiante reflexione y
deduzca la solución por cuenta propia.

 Apoyo Integral: La asistencia docente atiende la dimensión cognitiva (aclarar


conceptos, corregir técnicas) y la dimensión socioemocional (gestionar la
frustración y reforzar la autoconfianza ante el error).
4. El Estudiante Autónomo y la Evaluación Formativa

El alumno deja de ser un receptor pasivo para convertirse en el responsable directo de su


proceso de aprendizaje. Este modelo le exige desarrollar habilidades de autorregulación y
gestión del tiempo, obligándolo a planificar sus jornadas formativas y a colaborar con sus
pares antes de recurrir al profesor.

Finalmente, la evaluación en este entorno es estrictamente formativa. Dado que el docente


interactúa de manera constante con quienes requieren asesoramiento, la retroalimentación
ocurre en tiempo real durante el proceso de ejecución. Esto permite al estudiante corregir
fallas y optimizar sus productos antes de la entrega final, garantizando un aprendizaje
significativo, duradero y adaptado a los ritmos individuales del aula.

[Link] las tareas asociadas a cada actividad del proyecto, especificando por lo
menos las siguientes acciones: análisis de requerimientos, análisis de sistemas de
información, diseño de la aplicación de software, desarrollo de la aplicación, prueba e
implantación.

Cronograma

Integrantes Role Actividades Semana 1 Semana 2 Semana 3 Semana 4


20/4/26- 27/4/26- 4/5/26- 11/5/26-
26/4/26 3/5/26 10/5/26 17/5/26
Luis Scrum Análisis de
Mastes requisitos
Demian Product Diseño
Owner
Cristian Equipo de Desarrollo
desarrollo
Melvin Equipo de Pruebas
desarrollo
[Link] los equipos, herramientas de software y materiales requeridos para
desarrollar las actividades relacionadas con la etapa desarrollo de software en ejecución.

Para que podamos desarrollar el sistema de inventario es necesario contar con


computadoras que tengan instalado C++ también podemos utilizar un servidor local o en la
nube también es necesaria la documentación del proyecto y diagramas de flujo basados en
los requisitos que definen como funcionara y se verá la estructura del programa en el diseño
de software, utilizaremos el programa c++ para convertir el diagrama en un código
funcional y desarrollar las tareas que se le asigno a cada integrante para coordinar el
trabajo.

7. Ejecutan las actividades de adquisición de destrezas asociadas con las siguientes


tareas: análisis de requerimientos, análisis de sistemas de información, diseño de la
aplicación de software, desarrollo de la aplicación, prueba e implantación.

Código
Diagrama de flujo
Actividad Nombre Fecha de Fecha de Observaciones
asignación entrega
Los estudiantes de cada equipo de trabajo Luis Maldonado 16/5/2026 22/5/2026 Entregado a
organizan los equipos, herramientas de software y tiempo y
materiales requeridos para desarrollar las estaba
actividades relacionadas con la etapa de bastante bien
desarrollo
de software en ejecución.
Los estudiantes de cada equipo ejecutan las
actividades de adquisición de destrezas asociadas
con las siguientes tareas: análisis de
requerimientos, análisis de sistemas de
información, diseño de la aplicación de software,
desarrollo de la aplicación, prueba e
implantación.
Se fomenta la participación de cada estudiante en Demian 16/5/2026 22/5/2026 Entregado sin
el Maldonado falta estaba
proceso sobre el desarrollo de aplicaciones de bueno el
software trabajo
para la solución de problemas. En esta etapa,
cada
estudiante realiza la actividad de la cual es
responsable,
tomando en cuenta el tiempo necesario para cada
actividad.
Los estudiantes de cada equipo establecen la
planificación definitiva del
trabajo, determinando las tareas a realizar, el
tiempo y
los responsables. El docente verifica que las
competencias, los conocimientos y resultados
contemplados en el proyecto estén presentes
durante la
ejecución.
Los estudiantes de cada equipo realizan las Cristian Santos 16/5/2026 22/5/2026 Entregado a la
actividades definidas en el plan de trabajo. El hora está bien
docente está a disposición de los estudiantes que
requieren asesoramiento y, en algunos casos,
apoyo.
Los equipos de trabajo desarrollan las propuestas Melvin Ortiz 16/5/2026 22/5/2026 Sin problema
de trabajo tecnológico que definen los estaba bueno
aprendizajes
que conllevan su realización y los métodos de
trabajo para realizar las actividades del proyecto.
Los equipos de estudiantes determinan las tareas
asociadas a cada actividad del proyecto,
especificando por los menos las siguientes
acciones: análisis de requerimientos, análisis de
sistemas de información, diseño de la aplicación
de
software, desarrollo de la aplicación, prueba e
implantación.
Etapa de controlar

1. verifica el desempeño en los resultados logrados con el desarrollo de cada actividad y


comprueba el logro de su aprendizaje a partir de las habilidades y conocimientos
aprendidos.

El equipo reviso los resultados de cada actividad realizada en el proyecto. Se


comprobó que cada integrante aplicamos nuestras habilidades técnicas como
programación en C++, análisis de sistemas, diseño de software y sus conocimientos
adquiridos en el desarrollo de la solución. Esto permitió confirmar el aprendizaje en
cada Sprint.

2. Los estudiantes utilizan técnicas como: positivo, negativo e interesante

Positivo: Se logro implementar un sistema en C++ que gestiona ordenes de


mantenimiento de manera funcional.
Negativo: Hubo limitaciones de tiempo y algunos retrasos en la ejecución de tareas,
lo que redujo el alcance de ciertas funciones.
Interesante: El uso de Scrum permitió organizar mejor el trabajo en equipo y
descubrir nuevas ideas para mejorar la aplicación.

[Link] equipo de estudiantes reflexiona sobre el alcance de los resultados y el tiempo


previsto para la ejecución de las siguientes actividades: análisis de requerimientos, análisis
de sistemas de información, diseño de la aplicación de software, desarrollo de la
aplicación, prueba e implantación.

El equipo se dio cuenta de que los resultados alcanzados fueron buenos en lo


esencial: logramos identificar las necesidades de la empresa diseñar un prototipo y
programar una aplicación en C++.
En cuanto al tiempo previsto, se cumplió en la mayoría de actividades, aunque en el
desarrollo y las pruebas se sintió que el tiempo era corto. Esto nos enseño que es
importante planificar mejor el tiempo de trabajo.
Análisis de requerimientos: se identificaron las necesidades principales de la
empresa.
Análisis de sistemas de información: Se reconocieron los procesos clave de
mantenimiento.
Diseño de la aplicación: Se elaboro un prototipo que refleja las necesidades básicas.
Desarrollo en C++: Se codifico una aplicación inicial que cumple con los objetivos.
Prueba e implantación: Se verifico el funcionamiento del sistema y se entregó.

[Link] equipo de trabajo de estudiantes reflexiona sobre los conocimientos aplicados a los
procesos tecnológicos implícitos en las actividades realizadas.

El objetivo es consolidar el aprendizaje significativo, el equipo valida que no solo ha


"escrito código" de forma mecánica, sino que comprende los conceptos de ingeniería de
software, las estructuras de datos y los paradigmas de programación que dan soporte a su
solución tecnológica.
La Retrospectiva Tecnológica
Al finalizar las correcciones del docente, el equipo de trabajo se reunirá internamente
durante una sesión de análisis para responder de forma colectiva y argumentada las
siguientes tres preguntas clave:

¿Qué conocimientos teóricos aplicamos con éxito? Identificación de patrones de diseño,


algoritmos, normalización de bases de datos, etc.

¿Qué vacíos de conocimiento identificamos y cómo los resolvimos? Falta de dominio en


librerías específicas, control de errores, y cómo se investigó la solución

¿Cómo mejoró nuestra lógica de programación tras esta etapa de control? Lecciones
aprendidas sobre optimización y legibilidad del código

El equipo reflexiono sobre como los conocimientos de Scrum, programación en C+


+, análisis de sistemas y gestión tecnológica se aplicaron en cada fase del proyecto.
Además, se fortalecieron competencias como:
 El trabajo colaborativo
 Metodología ágil
 Resolución de problemas
 Adaptación a cambios durante el desarrollo

5. El equipo de trabajo critica constructivamente acerca de la calidad de su trabajo de


otros equipos.
En el desarrollo de soluciones de software, la etapa de control garantiza que el producto
final no solo cumpla con los requerimientos técnicos básicos, sino que sea eficiente,
escalable y libre de errores lógicos. El presente documento técnico establece el marco
metodológico y las plantillas operativas para que cada equipo de trabajo evalúe
críticamente el progreso de los demás. Esta dinámica de coevaluación mitiga sesgos de
desarrollo y optimiza el diseño de los algoritmos propuestos para la empresa TecnoTech
2. Criterios de Evaluación y Reglas de Crítica Constructiva
 Mitigación del Control Manual: Evaluación de las interfaces y validaciones que
impidan la duplicidad de datos o fallos humanos en el ingreso del inventario.
 Sincronización en Tiempo Real: Verificación lógica de que los métodos o funciones
de descarga venta y bajas actualicen los arrays objetos o tablas de stock de forma
inmediata.
 Prevención de Pérdidas Financieras: Inclusión de triggers estructuras condicionales
de alerta para stock mínimo y reportes automáticos de valor totalizado

Matriz de Co-Evaluación entre Equipos


Observación /
Equipo Equipo Componente Propuesta de
Oportunidad de
Evaluador Evaluado Revisado Solución
Mejora

"Notamos que el
"Implementar
almacenamiento
Módulo de una estructura
de datos podría
Base de de control o
Equipo 1 Equipo 2 saturarse si
Datos / Lógica paginación para
aumentan los
de control mitigar la
registros en
carga."
simultáneo."

Una vez concluido el intercambio de matrices, cada equipo de trabajo asume la


responsabilidad de priorizar los fallos de lógica detectados.

6. El docente retroalimenta a los estudiantes acerca de la calidad de su trabajo, con el


fin de revisarlo y mejorarlo.

PROPOSITO DEL DOCENTE ANTE LA EVALUACION

La retroalimentación del docente tiene como objetivo principal elevar el estándar de calidad
del software en desarrollo antes de su liberación o entrega final. Este proceso garantiza que
los estudiantes:

 Identifiquen fallos arquitectónicos o de lógica que hayan pasado desapercibidos en


la revisión por pares.
 Comprendan el impacto técnico y funcional de sus decisiones de código.
 Implementen ciclos de iteración y refactorización (revisar, corregir y optimizar)
basados en estándares de la industria.
Criterios de Calidad Evaluados por el Docente
A diferencia de la revisión entre estudiantes, el docente evaluará el proyecto bajo una
perspectiva de Software.

 Viabilidad Arquitectónica: Si la estructura del código permite añadir nuevas


funciones en el futuro sin romper el sistema actual.
 Seguridad y Manejo de Excepciones: Robustez del código ante ingresos de datos
inválidos, ataques básicos (como inyecciones) o caídas del sistema.
 Optimización de Recursos: Eficiencia en las consultas a la base de datos y
algoritmos empleados

Etapa de controlar

7- nosotros reciben la retroalimentación, de su nivel de los resultados alcanzados.


"Nosotros recibimos retroalimentación como si fuera un sistema que compila nuestro
código: cada resultado alcanzado es como una salida del programa, y la retroalimentación
nos ayuda a depurar errores, optimizar funciones y mejorar la lógica. Así, nuestro
crecimiento no se mide solo en líneas de código escritas, sino en la calidad de las
soluciones que logramos construir."

De esta manera, la frase conecta con la experiencia de programar:

 Retroalimentación = depuración (debugging)

 Resultados alcanzados = ejecución del programa

 Nivel = calidad del código y aprendizaje continuo

La retroalimentación como un sistema que ejecuta pruebas unitarias sobre nuestro código.
Cada resultado alcanzado es como un test que pasa o falla, y la retroalimentación nos
muestra dónde debemos refactorizar, qué funciones necesitan optimización y qué
algoritmos ya están listos para producción. Así, nuestro nivel no se mide solo en la cantidad
de líneas escritas, sino en la capacidad de aprender de los errores, documentar las
soluciones y colaborar en equipo. La retroalimentación es como un commit revisado por
otros: nos ayuda a crecer, a mantener la calidad del proyecto y a que nuestro 'programa
humano' sea más robusto y escalable.

Elementos claves:

 Pruebas unitarias → representan los pequeños logros y aprendizajes.

 Refactorización → simboliza la mejora continua personal.

 Optimización de funciones → refleja cómo afinamos nuestras habilidades.

 Colaboración en equipo → como un code review, la retroalimentación no es solo


individual, sino colectiva.

 Escalabilidad humana → crecer en conocimiento y adaptabilidad, como un sistema


que puede manejar más usuarios o más datos.

8-organizare reuniones para revisar los resultados de aprendizaje y explican los


procesos logrados; Comparten lo que hemos hecho y lo que no.

"Organizar reuniones para revisar los resultados de aprendizaje es como hacer un code
review en equipo. Cada persona comparte lo que ha logrado —los módulos que funcionan
bien— y también lo que aún necesita ajustes —los bugs o funciones incompletas. Explicar
los procesos logrados es como documentar el flujo del programa: se muestra cómo se llegó
a la solución, qué algoritmos se usaron y qué decisiones se tomaron. Compartir lo que
hicimos y lo que no es como mantener un repositorio transparente, donde todos pueden ver
los commits, los avances y las tareas pendientes. Así, la retroalimentación se convierte en
un ciclo de mejora continua, donde cada reunión es una nueva iteración que nos acerca a un
sistema más robusto y humano."

Elementos claves:
 Reuniones = code reviews → espacios para revisar y aprender juntos.

 Resultados de aprendizaje = módulos del programa → lo que ya funciona.

 Procesos logrados = documentación del flujo → claridad en cómo se alcanzó cada


meta.

 Lo hecho y lo no hecho = commits y backlog → transparencia en avances y


pendientes.

 Retroalimentación = depuración y refactorización → mejora continua.

9- nosotros tenemos preparan presentaciones de avance, en términos de fortalezas y


debilidades

"Preparar presentaciones de avance es como mostrar el estado de un proyecto en GitHub.


Las fortalezas son los módulos que ya están funcionando correctamente, las funciones que
pasaron las pruebas y los algoritmos que demostraron eficiencia. Las debilidades son los
bugs que aún persisten, las funciones incompletas o el código que necesita refactorización.
Al compartir ambos aspectos, no solo mostramos lo que está listo para producción, sino
también lo que sigue en el backlog. Explicar los procesos logrados es como documentar el
flujo del programa: se detalla cómo llegamos a cada solución, qué decisiones de diseño
tomamos y qué aprendizajes obtuvimos. Así, las presentaciones se convierten en un tablero
Kanban humano, donde todos pueden ver avances, bloqueos y próximos pasos."

Elementos claves:

 Fortalezas = módulos estables / funciones que pasan pruebas.

 Debilidades = bugs, código pendiente de refactorización.

 Presentaciones = tablero Kanban / informe de estado del repositorio.

 Procesos logrados = documentación del flujo / commits explicativos.


 Compartir lo hecho y lo no hecho = transparencia en backlog y tareas pendientes.

10. El docente monitorea el trabajo individual y el de los equipos de trabajo.

Nuestro profesor revisa las actividades que realizamos, nos aconseja y corrige

[Link] sesiones semanales de reflexión sobre los avances, en función de la


revisión del proyecto.

En nuestro caso en cada semana verificamos los avances que logramos, lo que faltaba e
identificamos que podría ser un problema, contrastamos lo realizado contra lo que
planificamos

12. Recogen en un documento los resultados de cada etapa del proyecto, indicando las
decisiones que se han tomado.

Etapa de informarse

En esta etapa fue en la que recopilamos información, seleccionamos una situación


problemática, investigamos sobre las metodologías agiles todo nos ayudo para plantear las
bases del proyecto

Etapa de planificar

En esta etapa organizamos el trabajo y nos preguntamos como abordaríamos la solución,


elaboramos un cronograma de actividades de un mes como plazo y dividido en sprints
semanales, asignamos responsabilidades para cada integrante y usamos la metodología
scrum para desarrollar el programa

Etapa de decidir

En esta etapa valoramos las posibles alternativas y seleccionamos la más viable que para
nosotros fue realizar un programa de inventario en base a los requerimientos de la empresa.
También si teníamos los recursos y si el tiempo tenia coherencia con el problema,
aplicamos varias técnicas de toma de decisión y justificamos nuestra elección

Etapa de ejecutar

En esta etapa empezamos a desarrollar las tareas según el cronograma y los roles asignados,
lo que significo crear el programa de desde recopilar los requisitos, el diseño y la
estructura, escribir el código, realizar las pruebas para corregir los errores hasta llegar a la
implementación

[Link] verifican el correcto desarrollo de las actividades, a través de reuniones de


seguimiento, contrastando la situación del proyecto contra los hitos y resultados
establecidos en la planificación y Cronograma de actividades (lo realizado versus lo
planificado).

Como equipo nos reunimos para contrastar los que habíamos planificado contra lo que
realizamos

Los hitos en nuestro proyecto fueron el:

Análisis de requerimientos: se recopilo las necesidades de la empresa para hacer el


programa de inventario

El diseño: se creó el diagrama

El desarrollo: escribir el código siguiendo las especificaciones

Pruebas e implantación: Verificar si tiene errores, corregirlos y terminar con el programa

El cronograma

El plazo fue de un mes dividido en cuatro sprints semanales:

 Semana 1: Análisis de requisitos


 Semana 2: el diseño y la estructura
 Semana 3: Desarrollo
 Semana 4: Pruebas e implementación
Actividad Nombre Fecha de Fecha de Observaciones
asignación entrega
 calendarizan sesiones Luis 22/5/2026 07/6/2026 Lo entrego a
semanales de reflexión Maldonado tiempo y está bien
sobre los avances, en hecho y completo
función de la revisión del
proyecto.
 recogen en un documento
los resultados de cada
etapa del proyecto,
indicando las decisiones
que se han tomado.
 verifican el correcto
desarrollo de las
actividades, a través de
reuniones de seguimiento,
contrastando la situación
del proyecto contra los
hitos y resultados
establecidos en la
planificación y Cronograma
de actividades (lo realizado
versus lo planificado).

 verifica el desempeño en Demian 22/5/2026 07/6/2026 Lo entrego a


los resultados logrados con Maldonado tiempo y está bien
el desarrollo de cada hecho y completo
 actividad y comprueba el
logro de su aprendizaje a
partir de las habilidades y
conocimientos aprendidos.
 utilizan técnicas como:
positivo, negativo e
interesante
 reflexiona sobre el alcance
de los resultados y el
tiempo previsto para la
ejecución de las siguientes
actividades: análisis de
requerimientos, análisis de
sistemas de información,
diseño de la aplicación de
software, desarrollo de la
aplicación, prueba e
implantación.
 reflexiona sobre los
conocimientos aplicados a
los procesos tecnológicos
implícitos en las actividades
realizadas.
 organizan reuniones para Cristian 22/5/2026 07/6/2026 Lo entrego a
revisar los resultados de Santos tiempo y está bien
aprendizaje y explican los hecho y completo
progresos logrados;
comparten lo que han
hecho y lo que no.
 preparan presentaciones de
avance, en términos de
fortalezas y debilidades.
 El docente monitorea el
trabajo individual y el de los
equipos de trabajo.
Melvin Ortiz 22/5/2026 07/6/2026 Lo entrego a
 critica constructivamente el tiempo y está bien
progreso de trabajo de los hecho y completo
otros equipos.
 El docente retroalimenta a
los estudiantes acerca de la
calidad de su trabajo, con el
fin de revisarlo y mejorarlo.
 reciben la
retroalimentación, de su
nivel, de los resultados
alcanzados.
Etapa de Valorar

[Link] equipo de trabajo, con el apoyo del facilitador, da seguimiento a cada actividad
realizada, a través de la verificación de avances en el cronograma de actividades, los
resultados logrados y los conocimientos adquiridos, para realizar ajustes y/o fortalecer el
aprendizaje adquirido.

Con el apoyo del facilitador, el equipo fue revisando paso a paso lo que se hacia en el
cronograma. No solo se trataba de ver si las tareas estaban completas, sino también de
comprobar que tanto habíamos aprendido en el proceso. Cada avance nos hacia mejorar
cada vez mas y reforzábamos lo que necesitáramos mejorar lo que si nos ayudo a que el
aprendizaje fuera más sólido y practico.

[Link] otorga especial atención a la comprobación de que se han respetado los artículos del
reglamento de programación de software.

Durante el desarrollo, pusimos atención en que el código y las actividades respetaran las
normas básicas de programación de software. Esto significo cuidar la estructura del
programa, mantener orden en las funciones, usar buenas practicas y evitar errores comunes.
Al hacerlo, no solo cumplimos con lo que se pide en un reglamento, sino que también
aseguramos que el proyecto fuera más claro y fácil de comprender.

3. Los equipos evalúan cómo han comprendido la información recolectada y cómo la


utilizan para resolver los problemas planteados.

Al final, el equipo reflexiono sobre como entendimos la información que fuimos


recolectando y como la aplicación para resolver los problemas planteados. Nos dimos
cuenta de que algunas cosas las comprendimos rápido y mientras que en otros casos
necesitamos hacer más investigación y discutirlo. Esta evaluación nos ayudo a ver en qué
puntos estábamos fuertes y en cuales teníamos que mejorar, lo que hizo que el aprendizaje
fuera más completo en todo este proceso.
4. Al final de cada actividad, se reúnen para evaluar de manera crítica los resultados
obtenidos. Con esto, aprecian el progreso de su aprendizaje.

El Resultado Tecnológico Obtenido

Criticas resultados

A continuación, se detallan los hallazgos finales tras la puesta en marcha del sistema,
contrastando las expectativas del proyecto con la realidad técnica alcanzada:

 Resolución del Problema: Automatizar el 100% de los flujos de entrada y salida de


mercancía. El sistema procesa transacciones en milisegundos y actualiza el stock de
forma inmediata en la base de datos. Excelente. Se eliminó por completo el error
humano derivado del registro manual en papel.
 Rendimiento del Software: Generar reportes estadísticos complejos en un tiempo
menor a 5 segundos. Mediante la optimización de consultas SQL y vistas
indexadas, los reportes se despliegan en un promedio de 1.8 segundos. Muy Alto. El
cliente obtiene información estratégica de manera inmediata para la toma de
decisiones.
 Estabilidad y Seguridad Garantizar que el sistema no sufra caídas ante datos
inválidos. Se implementó un sistema estricto de manejo de excepciones y validación
de formularios en el frontend y backend Óptimo. El software es seguro y responde
de manera controlada ante intentos de uso incorrecto. |

Apreciación del Progreso del Aprendizaje

A través de la ejecución de esta actividad, el equipo ha realizado un ejercicio de


autoevaluación para medir la evolución de sus competencias técnicas y metodológicas

Antes de la actividad: El equipo poseía conocimientos teóricos sobre bases de datos y


estructuras de control, pero carecía de experiencia integrando múltiples capas de software
interfaz, lógica de negocio y persistencia de datos
Después de la actividad: Se consolidó el dominio en arquitectura de software, manejo de
librerías de terceros y técnicas de refactorización de código limpio (C++

La necesidad de superar las observaciones de la etapa de control obligó al equipo a mejorar


su comunicación interna. Se aprendió a recibir la crítica de los otros equipos de forma
madura y a delegar tareas complejas según las fortalezas individuales de cada programador
administración de bases de datos)

El equipo de estudiantes concluye de manera unánime que los resultados obtenidos superan
los estándares mínimos requeridos. La problemática original fue resuelta mediante una
solución tecnológica eficiente, escalable y segura.

5. Participan en la discusión para valorar el progreso de las actividades y el cumplimiento


de las responsabilidades asignadas dentro del equipo y el proyecto

El objetivo de este ejercicio es evaluar de manera crítica el rendimiento operativo del


equipo, analizando el avance de los cronogramas de trabajo, la efectividad de los canales de
comunicación y el nivel de cumplimiento de las responsabilidades individuales asignadas
para resolver la problemática del proyecto.

Contexto

Para solucionar la ineficiencia en el registro manual de datos de la problemática planteada,


el desarrollo del software requería una división estricta de funciones. La calidad del
producto final dependía directamente de un efecto dominó: si el encargado de la Base de
Datos se retrasaba, el programador del Backend no podía avanzar, lo que a su vez
paralizaba el diseño de la interfaz del Frontend.

Discusión Crítica del Progreso y Compromiso

Durante la mesa redonda de valoración, el equipo debatió los siguientes tres ejes
fundamentales

Cumplimiento de Responsabilidades por Rol


Cada integrante expuso el balance de sus tareas asignadas en la planificación inicial Sprint
Backlog. Se verificó que las asignaciones técnicas creación de tablas, programación de
controladores, diseño de vistas y pruebas de validación fueran completadas en su totalidad
antes del cierre de la actividad

Conclusión

El equipo determinó que, aunque surgieron fallos complejos en la lógica de conexión de la


base de datos, la comunicación asertiva permitió reasignar apoyo temporal para solucionar
el problema sin retrasar la fecha de entrega acordada.

6. Realizan una evaluación de la participación individual dentro del grupo.

El propósito de este último punto es garantizar la transparencia y la equidad en el proyecto,


midiendo el nivel de proactividad, colaboración y profesionalismo que cada estudiante
aportó para resolver de manera conjunta la problemática tecnológica del software

Evaluación Individual

Para evitar evaluaciones subjetivas o basadas en la afinidad personal, los estudiantes


debatieron y calificaron la participación de cada miembro utilizando los siguientes cuatro
criterios técnicos y actitudinales:

 Proactividad e Iniciativa: Disposición para asumir tareas complejas de


programación y proponer soluciones a los errores de lógica detectados.

 Trabajo Colaborativo: Capacidad para asistir a otros integrantes del equipo cuando
sufrieron bloqueos de código o problemas de integración en la base de datos.

 Puntualidad en las Entregas: Compromiso con los plazos establecidos


internamente para la integración de sus módulos de software.
 Comunicación y Respeto: Claridad para exponer sus ideas en las mesas redondas
y madurez al recibir retroalimentación del grupo o del docente

EQUIPO EVALUACION
Luis Desempeño muy excelente a
Maldonado trabajado muy bien
Demian Excelente, trabaja muy bien.
Maldonado Responsable
Cristian Muy bien trabajador , cumple con
Santos todo lo asignado
Melvin Excelente, trabaja muy bien ,
Orellana Entrega todo
7-Se autoevalúa para Detectar las fallas y los retrasos en la ejecución de las Actividades
relacionados con el análisis de requerimientos, el análisis de sistemas de información, el
Diseño de la Aplicación de software, el Desarrollo de la Aplicación, la prueba y la
implantación.

En nuestro trabajo como desarrolladores, no basta con escribir código: necesitamos


detenernos y mirarnos al espejo del proyecto. La autoevaluación es ese momento en que
revisamos con honestidad cómo estamos avanzando y dónde nos estamos quedando atrás.

 Análisis de requerimientos: ¿Entendimos realmente lo que el usuario necesita o


nos dejamos llevar por suposiciones?

 Análisis de sistemas de información: ¿Conectamos bien las piezas del sistema o


pasamos por alto dependencias críticas?

 Diseño de la aplicación: ¿El diseño es claro y sostenible, o estamos improvisando


soluciones que luego serán difíciles de mantener?

 Desarrollo: ¿Estamos cumpliendo los tiempos o nos encontramos corrigiendo


errores que pudieron evitarse antes?

 Pruebas: ¿Probamos lo suficiente o dejamos que los usuarios sean quienes


descubran los fallos?

 Implantación: ¿La entrega fue fluida o se sintió como un salto al vacío?

8-Realizamos un análisis del avance de las siguientes fases: análisis de requerimientos,


análisis de sistemas de información, diseño de la aplicación de software, desarrollo de la
aplicación, prueba e implantación.

Nuestro análisis del avance en programación


Cuando desarrollamos software, cada fase es como un peldaño en una escalera. Subirla
requiere atención, coordinación y honestidad para reconocer dónde estamos fuertes y dónde
nos falta impulso. Así lo vemos:

 Análisis de requerimientos: Es el momento de escuchar al usuario y preguntarnos:


¿realmente entendemos lo que necesita o solo lo que creemos que quiere?

 Análisis de sistemas de información: Aquí conectamos las piezas del


rompecabezas. Revisamos si los datos fluyen bien o si hay huecos que podrían
convertirse en problemas más adelante.

 Diseño de la aplicación: Dibujamos el mapa antes de construir la ciudad. Nos


preguntamos si el diseño será claro, escalable y fácil de mantener, o si estamos
levantando muros que luego nos costará derribar.

 Desarrollo: Escribir código es como construir ladrillo por ladrillo. Revisamos si


avanzamos al ritmo esperado o si nos detenemos demasiado corrigiendo errores que
pudieron evitarse.

 Pruebas: Aquí jugamos el papel de detectives. Buscamos fallas antes de que el


usuario las descubra. La pregunta clave es: ¿probamos lo suficiente o dejamos
cabos sueltos?

 Implantación: Es el salto final. Evaluamos si la entrega fue fluida, como aterrizar


suavemente, o si se sintió como un salto al vacío.

9- valoran el desarrollo de cada una de las actividades planeadas y en los periodos de


tiempo prefijados, es decir, si hay un ajuste entre la ejecución real y la planeación
diseñada.

Evaluar la ejecución en programación


En programación, planear es como dibujar un mapa antes de emprender un viaje. Pero el
verdadero reto está en comparar ese mapa con el camino que recorremos en la práctica.

 Planeación: Es el itinerario que diseñamos, con paradas y tiempos definidos.

 Ejecución real: Es el viaje mismo, con sus desvíos, atascos y sorpresas.

 Valoración: Es mirar atrás y preguntarnos: ¿seguimos la ruta como estaba prevista


o tuvimos que improvisar?

 La planeación es la lista de ingredientes y pasos que escribimos.

 La ejecución real es cuando estamos en la cocina, midiendo, mezclando y


ajustando.

 La valoración es probar el plato y decir: ¿salió como lo planeamos o tuvimos que


cambiar la sazón sobre la marcha?

En programación

Así, valorar el desarrollo de cada actividad y su tiempo es como revisar si el código que
escribimos, las pruebas que hicimos y la implantación que logramos se alinean con el plan
inicial. Cuando hay retrasos o ajustes, no es un fracaso: es una oportunidad para aprender
cómo mejorar la próxima vez y hacer que la planeación sea más realista.
11. Reflexionan sobre la adquisición de las habilidades y las exigencias propias de las
tareas realizadas.

Durante el desarrollo del proyecto, nosotros como equipo fortalecimos nuestras


habilidades técnicas y personales como en el trabajo en equipo y colaboración, la
comunicación en nuestras reuniones de seguimiento, en la organización y planificación de
nuestras actividades y responsabilidades, resolución de problemas, desarrollo de
programas en C++, también tuvimos problemas desde coordinación, trabajo en equipo y
en realizar algunas actividades. Para concluir la importancia de aprender, trabajar en
equipo y equivocarse y mejorar poco a poco

12. Valora la retroalimentación de la práctica de habilidades.

Al empezar a programar, hacer diagramas, ver que algo no funcionaba, iniciamos con un
programa básico y vimos que se podía mejorar. aprendimos bastante durante el desarrollo
del proyecto como que la programación no solo se trata de escribir código, sino de analizar
el problema, realizar pruebas, corregir errores y notar aspectos a mejorar, volver a
intentarlo. Esto fue útil para realizar ajustes, fortalecer nuestros conocimientos y mejorar
en el trabajo.

13. Al culminar el proyecto, reflexionan acerca de las competencias desarrolladas a través


del proyecto.

Desarrollamos varias competencias como el uso de la metodología Scrum, usar un


cronograma de trabajo, el desarrollo de soluciones, la planificación de un proyecto.
También competencias como la responsabilidad, colaboración, toma de decisiones,
resolución de problemas y capacidad de adaptación. Lo que aprendimos podemos
aplicarlo en futuros proyectos
.

Actividad Nombre Fecha de Fecha de Observaciones


asignación entrega

 reflexionan sobre la adquisición de las Luis 30/5/2026 07/6/2026 Lo entrego a


habilidades y las exigencias propias de Maldonado tiempo y está
las tareas realizadas. bien hecho y
 valora la retroalimentación de la completo
práctica de habilidades.
 al culminar el proyecto, reflexionan
acerca de las competencias
desarrolladas a través del proyecto.

 Cada equipo de trabajo, con el apoyo Demian 30/5/2026 07/6/2026 Lo entrego a


del facilitador, da seguimiento a cada Maldonado tiempo y está
actividad realizada, a través de la bien hecho y
verificación de avances en el completo
cronograma de actividades, los
resultados logrados y los
conocimientos adquiridos, para
realizar ajustes y/o fortalecer el
aprendizaje adquirido.
 Se otorga especial atención a la
comprobación de que se han
respetado los artículos del reglamento
de instalaciones eléctricas.
 evalúan cómo han comprendido la
información recolectada y cómo la
utilizan para resolver los problemas
planteados.

 se autoevalúa para detectar las fallas y Cristian 30/5/2026 07/6/2026 Lo entrego a


los retrasos en la ejecución de las Santos tiempo y está
actividades relacionadas con el análisis bien hecho y
de requerimientos, el análisis de completo
sistemas de información, el diseño de
la aplicación de software, el desarrollo
de la aplicación, la prueba y la
implantación.
 realiza un análisis del avance de las
siguientes fases: análisis de
requerimientos, análisis de sistemas
de información, diseño de la aplicación
de software, desarrollo de la
aplicación, prueba e implantación.
 valoran el desarrollo de cada una de
las actividades planeadas y en los
períodos de tiempo prefijados, es
decir, si hay un ajuste entre la
ejecución real y la planeación
diseñada.
Melvin Ortiz 30/5/2026 07/6/2026 Lo entrego a
 Los equipos de estudiantes, al final de tiempo y está
cada actividad, se reúnen para evaluar bien hecho y
de manera crítica los resultados completo
obtenidos. Con esto, aprecian el
progreso de su aprendizaje.
 participan en la discusión para valorar
el progreso de las actividades y el
cumplimiento de las responsabilidades
asignadas dentro del equipo y el
proyecto.
 realizan una evaluación de la
participación individual dentro del
grupo.

También podría gustarte