CEB 5/3 “José Vasconcelos”

MATERIA: Programación.
ACTIVIDAD: Documentación.
Quinto Semestre
Maestra: Susy Nohemí Gutiérrez Gómez.
Equipo:
 Axel Jesús Arellano Mora
 Abril Casimiro Pérez.
 Sharon Escobar González
 Ximena Lizbeth Fernández Godínez
 Edgar Uriel Hernández Aguilar
 Fredy Millán Chacón
 Fortunato Junior Salinas Huertas
 Marian Reyes Figueroa.

Grupo: 503
 REQUERIMIENTOS:
PROBLEMA:
La feria de la salud es un evento el cual tiene la finalidad de dar a conocer los
diferentes sistemas que conforman el cuerpo humano a alumnos de 1ero y 2ndo
grado, y cómo afectan las adicciones a dichos sistemas. Para complementar esta
información y los stands que serían realizados, el maestro de programación asignó
a los alumnos de la especialidad de TICs, un proyecto que se conjugara con dicha
feria y la materia de sistemas de la información, que además sería su proyecto final,
por lo que pidió un programa explicativo sobre el sistema urinario que nos ayudara
en la presentación de nuestro stand de la feria de la salud de forma eficiente,
completa y llamativa. Para hacer más entretenida la explicación, se debería
implementar un juego didáctico relacionado con el sistema urinario, que
complemente nuestro material físico y la explicación de nuestros compañeros.
CAPTURA DE REQUERIMIENTOS:
 Un software didáctico
 Un software eficiente y complementario
 Un software llamativo y sin errores
 Un software de fácil comprensión y accesos para los usuarios
ANÁLISIS DE REQUERIMIENTOS:
 Un software que capte la atención de los usuarios y sea didáctico con los
para su entretenimiento
 Un software que ya haya pasado por un proceso de pruebas y que su
temática se relacione con nuestro tema a exponer
 Un software que resulte llamativo a la vista y que no tenga errores en sus
escenarios o movimiento de los personajes.
 Un software que cuente con controles sencillos, que sea fácil de comprender
su funcionamiento y objetivo y que no resulte tedioso el usarlo para el
usuario.
ESPECIFICACIÓN DE REQUERIMIENTOS:
Como parte de dicho software, debía presentarse un juego entretenido, llamativo a
la vista de los usuarios, y sin errores que se relacionara con el sistema urinario. Este
debería cumplir con los siguientes requerimientos, además de todas las fases del
desarrollo de software que se presentarán más adelante.
 El juego tiene un fondo de rayas color rojo con salmón, al igual que una
paleta de colores que van de estos tonos durante todo el videojuego, como
el suelo del escenario y los obstáculos.
  Debe tener un botón para su inicio que diga “Play” y que, al dar clic en este,
comience a correr el juego.
 Debe tener un personaje principal o avatar que sea el que recorra el juego,
este deberá ser una especie de “pacman” color amarillo que responda al
control de salto y al saltar, de una vuelta de 360 grados sobre sí mismo.
 El movimiento del avatar debe tener la misma velocidad todo el tiempo
durante el juego.
 Mientras el avatar avance, debe encontrarse con manchas u hoyos en el
piso, de diferentes tamaños para hacerlo más vistoso.
 Si el avatar cae o choca con un hoyo, aparecerá una pantalla negra que
dirá: “PERDISTE” en letras grandes, y debajo de estas, en un menor
tamaño, la frase: “Te dio cáncer de uretra”.
 Si aparece dicha pantalla, el usuario deberá repetir el juego si quiere
intentar ganar otra vez.
 Los hoyos deben tener una cierta separación entre sí para dejar espacio al
avatar de avanzar sin caer en un hoyo, pero no tan separado como para
que sea demasiado fácil pasar el juego.
 Mientras el avatar avance, deberán aparecer diferentes hoyos (3 hoyos
desde que comienza), y en un momento del juego, después de los primeros
3 hoyos, debe aparecer una bola grande en el aire que sirva para distraer al
usuario y no sea tan sencillo ganar el juego, pero a la vez que esté a una
altura que permita al avatar avanzar sin chocar con ella.
 Después del obstáculo de la bola, deben aparecer 3 hoyos más durante el
recorrido y una vez pasados estos, bajará del aire una figura de la uretra
color rosa y chocará con el avatar, indicando que el juego terminó y ha
ganado.
 Una vez que el avatar llegue al final del juego y gane la uretra rosada, debe
aparecer la pantalla color degradado de un naranja rojizo a rosa y en ella, la
frase: “!FELICIDADES!, debajo de esta, en un menor tamaño, la frase:
“HAZ CONSEGUIDO LA URETRA”.
 Una vez concluido el juego, debe poder reiniciarse si el usuario lo desea
 El juego no debe presentar errores de codificado en los que el avatar se
trabe o no haga lo establecido.
 El juego no debe seguir avanzando si el avatar choca con alguno de los
obstáculos.
 El avatar no debe responder a otro comando que no sea al de saltar.
TÉCNICAS Y MÉTODOS DEL ANÁLISIS DE REQUERIMIENTOS SEGÚN EL
PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE:
GESTIÓN DE REQUERIMIENTOS:
 Para la realización efectiva y dentro del tiempo dado del software requerido,
se designaron tareas a cada programador o módulos a realizar que llegarían
a juntarse para dar un producto final. La distribución fue la siguiente:
 INTEGRANTES DEL EQUIPO: TAREA:
+ Marian Diseño general del programa
+ Abril Programadora
+ Ximena Diseño de gráficos y objetos
+ Axel Programador
+ Edgar Programador
+ Sharon Programadora
+ Junior Testador o probador
+ Fredy Encargado del control de calidad

DISEÑO DEL SOFTWARE

Diseño de alto nivel:
El juego fue estructurado y diseñado para comprender dónde consta de un solo nivel
donde al dar click en inicio la bola amarilla empieza a rodar y tiene una meta que es
llegar a la uretra
este es de alto nivel ya que sostiene una meta un punto preciso para que funcione
correctamente donde se estructura de un punto medio hasta llegar a la meta
Diseño detallado:
Objeto1: Bola amarilla al presionar la tecla espacio esta salta de los demás
obstáculos para evitar chocar con ellos
Objeto 2: Botón de PLAY al darle click a este botón nos arrojará al juego para poder
disfrutar de él
Objeto 3,4,5,6,7,8,9:son manchas rojas que salen de forma aleatoria donde debes
de evitar chocar con ellas
Objeto 10:Cartel que dice “BAD ENDING te dio cáncer de uretra”, es lo que pasa
cuando la bola amarilla choca con las manchas rojas
Objeto 11: Este objeto es la Uretra donde al tocarla ganamos el juego
Objeto 12: El último objeto es un cartel que dice “¡FELICIDADES! Haz conseguido
la uretra” donde aparece cuando nosotros tocamos la uretra y logramos ganar y
conseguir así el fin de juego

-DIAGRAMA DE FLUJO DE DATOS

 EL DISEÑO ORIENTADO A OBJETOS
El diseño de estos objetos consta de que todos fueron usados y utilizados en un
mismo archivo creados por los programadores desde el más mínimo detalle hasta
el máximo y estos son:

Objeto1: Bola amarilla al presionar la tecla espacio esta salta de los demás
obstáculos para evitar chocar con ellos
Objeto 2: Botón de PLAY al darle clic a este botón nos arrojará al juego para poder
disfrutar de él
Objeto 3,4,5,6,7,8,9: son manchas rojas que salen de forma aleatoria donde debes
de evitar chocar con ellas
Objeto 10: Cartel que dice “BAD ENDING te dio cáncer de uretra”, es lo que pasa
cuando la bola amarilla choca con las manchas rojas
Objeto 11: Este objeto es la Uretra donde al tocarla ganamos el juego
Objeto 12: El último objeto es un cartel que dice “¡FELICIDADES! Haz conseguido
la uretra” donde aparece cuando nosotros tocamos la uretra y logramos ganar y
conseguir así el fin de juego

DESCOMPOSICIÓN JERÁRQUICA

· El juego tiene un fondo de rayas color rojo con salmón, al igual que una paleta
de colores que van de estos tonos durante todo el videojuego, como el suelo del
escenario y los obstáculos.

· Debe tener un botón para su inicio que diga “Play” y que, al dar clic en este,
comience a correr el juego.

· Debe tener un personaje principal o avatar que sea el que recorra el juego, este
deberá ser una especie de “pacman” color amarillo que responda al control de salto
y al saltar, de una vuelta de 360 grados sobre sí mismo.
· El movimiento del avatar debe tener la misma velocidad todo el tiempo durante el
juego.

· Mientras el avatar avance, debe encontrarse con manchas u hoyos en el piso, de

diferentes tamaños para hacerlo más vistoso.

· Si el avatar cae o choca con un hoyo, aparecerá una pantalla negra que dirá:
“PERDISTE” en letras grandes, y debajo de estas, en un menor tamaño, la frase:
“Te dio cáncer de uretra”.

· Si aparece dicha pantalla, el usuario deberá repetir el juego si quiere intentar ganar
otra vez.

· Los hoyos deben tener una cierta separación entre sí para dejar espacio al avatar
de avanzar sin caer en un hoyo, pero no tan separado como para que sea
demasiado fácil pasar el juego.

· Mientras el avatar avance, deberán aparecer diferentes hoyos (3 hoyos desde que
comienza), y en un momento del juego, después de los primeros 3 hoyos, debe
aparecer una bola grande en el aire que sirva para distraer al usuario y no sea tan
sencillo ganar el juego, pero a la vez que esté a una altura que permita al avatar
avanzar sin chocar con ella.

· Después del obstáculo de la bola, deben aparecer 3 hoyos más durante el recorrido
y una vez pasados estos, bajará del aire una figura de la uretra color rosa y chocará
con el avatar, indicando que el juego terminó y ha ganado.

· Una vez que el avatar llegue al final del juego y gane la uretra rosada, debe aparecer
la pantalla color degradado de un naranja rojizo a rosa y en ella, la frase:
“!FELICIDADES!, debajo de esta, en un menor tamaño, la frase: “HAZ
CONSEGUIDO LA URETRA”.

· Una vez concluido el juego, debe poder reiniciarse si el usuario lo desea

· El juego no debe presentar errores de codificado en los que el avatar se trabe o no

haga lo establecido.

· El juego no debe seguir avanzando si el avatar choca con alguno de los obstáculos.

· El avatar no debe responder a otro comando que no sea al de saltar.

El juego solo consta de un solo nivel, donde al darle play la bola amarilla empieza a

moverse y debe esquivar las manchas rojas para llegar a la urtera.

 LA CODIFICACIÓN
COMPILACIÓN

Esta serie de códigos sirven para el “arranque

de movimiento de nuestro avatar y del juego
mismo, y también para enlazar la acción de
salto a una tecla [espacio], permitiendo que el
usuario pueda mover el avatar y avanzar en el
juego.

Este código se encarga del movimiento del

avatar al saltar, haciéndolo girar 36°.

Estos códigos nos sirven para marcar la meta y los

obstáculos que delimitan y dan sentido al juego, haciendo
que en cuanto nuestro avatar toque el color rojo, color que
representa a los obstáculos(enfermedades) el juego se
detenga, oculte el avatar y nos marque que hemos perdido
con un fondo negro, mientras que si toca el objeto11 (la
vejiga) nos dará un fondo rosa y la leyenda de que hemos
ganado.
 Limitan el cuándo aparecerá y desaparecerá este
obstáculo (enfermedad) según avance nuestro
avatar.

Limitan el cuándo aparecerá y desaparecerá el

botón de <PLAY> según sea necesario, además de
su funcionalidad para poder dar comienzo al juego.

Limitan el cuándo aparecerá

y desaparecerá el botón de
<PLAY> según sea
necesario, además de su
funcionalidad para poder
dar comienzo al juego.
 Limitan el cuándo aparecerá y
desaparecerá este obstáculo
Limitan el cuándo aparecerá y
(enfermedad) según avance nuestro
desaparecerá este obstáculo
avatar.
(enfermedad) según avance nuestro
avatar.

Limitan el
cuándo
aparecerá y
desaparecerá
este obstáculo
Limitan el cuándo
(enfermedad)
aparecerá y desaparecerá
según avance
este obstáculo
nuestro avatar.
(enfermedad) según
avance nuestro avatar.
Limita cuando aparecer
y desaparece el fondo, Sirve para mostrar o Limita cuando aparecer
según reciba el mensaje esconder el objeto en el y desaparecer este
el fondo de BAD tiempo estimado de fondo según reciba el
ENDING que señala que duración del juego para mensaje, el fondo de
perdiste y debes volver que marque la meta al FELICIDADES que señala
a intentarlo. ser tocado por el avatar. que ganaste y
terminaste el juego.
REGLAS DE CODIFICACIÓN:
El programa elegido para la realización del juego es Scratch, y como cualquier otro
software, cuenta con ciertas reglas de codificación bajo las que se rige para su
correcto funcionamiento:
o + Con Scratch no se puede ir escribiendo como tal las líneas de código,
puesto que trabaja bajo bloques de código preestablecidos, pero también se
pueden crear propios, a diferencia de otros programas donde se debe
codificar todo desde cero.
o + Las opciones de programación de Scratch son para objetos y/o escenarios
o fondos, por lo que deben definirse para poder comenzar a programar
o + Se debe comenzar siempre con un evento para iniciar a ejecutar un código,
de lo contrario, este no hará nada.
o + A la hora de implementar audios, si se desea adjuntar uno, este debe ser
en formato mp3, de otra forma no será compatible para subirlo a Scratch y
utilizarlo.
o + Para parar el programa, se debe pulsar el botón rojo que está al lado de la
bandera verde
o + Para borrar un objeto no hay más que dar clic en el ícono de bote de basura
que aparece en la esquina superior derecha de la miniatura de dicho objeto

ASPECTOS CLAVE

 Convenciones para nombres de identificadores:

Variables: ganaste, perdiste, play, tecla de espacio, obstáculos, botones de
sensor. Constantes: bloques de código predeterminados en el programa.

 La declaración de identificadores:
Variables: ganaste, perdiste, play, tecla de espacio, obstáculos, botones de
sensor. Constantes: bloques de código predeterminados en el programa.

 La indentacion: Eventos, movimiento, sensores, apariencia, sonido.

 No se utilizaron reglas para el tamaño y partido de líneas.

 No se podían aplicar notas en la codificación.

 Utilización de espacios en blanco.

DEBUGGING
1.- Estabilización:

En el momento de poner a prueba nuestro sistema, los errores nunca faltaron, en el

personaje, los obstáculos, los escenarios, los movimientos, etc.… había problemas que en
ocasiones no podíamos solucionar, pero poco a poco fuimos solucionando cada uno de
ellos.

2.- Localización:

Cuando el personaje y el objeto interactuaron entre sí, captamos muchos errores,

por la cual hace que nuestro sistema no funcionara como queríamos, nuestro objeto
al ser color verde no detecto cuando perdíamos y la solución fue cambiar el color
rojo y cuando lo colocamos hizo funcionar todo correctamente y ahora cuando el
personaje lo tocaba y perdía; cuando cada objeto estaba por separado, funcionaba
bien, pero al momento de juntar estos, hubo muchas fallas.

3.- Corrección:
Una solución que pudimos encontrar fue cambiar los colores, es decir, de verde a
rojo y así poder darle una atracción al juego ya que el rojo podría referirse a peligro

4.- Verificación:

Al verificar si las modificaciones habían solucionado los buggs se comprobó que si

habían sido útiles y se solucionaron las fallas que se tenían anteriormente y no
alteraron ninguna otra función.

REFACTORIZACIÓN:
Como parte de la refactorización de nuestro código, se revisó meticulosamente cada uno de los
bloques de código del juego que desarrollamos para eliminar cualquier bloque cuya importancia era
relativamente nula o también llamado código muerto, pues el juego seguía funcionando de manera
óptima sin estos bloques extra. Por ejemplo, en algunas ocasiones se repetían bloque de código
para realizar acciones por separado, cuando podían juntarse y utilizar solamente una vez ese bloque
de código de inicio, eso entre otros bloques fueron cambiados para una utilización más efectiva.
Esto con la finalidad de modificar el código de tal forma que la lógica de funcionamiento quede
expresada lo más claramente posible, incluyendo una extensión menor y así más eficiente.

CALIDAD
El sistema está enfocado a lo que el usuario nos está pidiendo, es decir; está para
satisfacer los requerimientos funcionales especificados, expectativas y necesidades
del usuario. Los atributos de calidad estarán principalmente formados por la
reutilización, seguridad y usabilidad, con estos nos permitiremos un menor tiempo
de trabajo y una mejor comprensión por parte de los usuarios, con esto ya hecho,
abriremos paso a las pruebas.

1.GARANTIA DE CALIDAD:
Los estándares que debíamos cumplir eran:
 -Que sea interactivo
 -Que sea didáctico
 -Que sea atractivo
 -Que no tenga errores
2 planificación de calidad
1 el producto nos debe de mostrar el sistema urinario y como este puede contraer
enfermedades, 2 para esto debemos de hacer un escenario basado en cómo se ve
el sistema urinario por dentro y como la orina (el personaje) pasa por esta zona para
finalizar su recorrido, en este caso consiguiendo la victoria.

1.Primeramente empezamos con el fondo, este se hizo con 2 rectángulos de misma

anchura pero de diferente tamaño, su color se hizo difuminado para que no se vea
monótono, y las líneas se consiguieron gracias a la letra c, esta se modificó de tal
forma que su tamaño concordaba con el fondo, y así mismo su color se diferencia
del resto

2.el personaje se hizo con 5 círculos de diferentes tamaños y los pequeños detalles
se hicieron a mano, tomando como referencia una gota de orina, así mismo los
colores que ocupa, son para mostrarse de una manera interesante al público.

3. En total fueron 12 objetos a los que se le dieron codificaciones, de estos 7 son

para hacer perder al jugador y en cuanto a los demás:
el objeto 1(personaje) tenía como tarea esquivar los obstáculos (objetos 3,4,5,6,7,8
y 9) y en cuanto los pasará a todos, su objetivo atrapar el objeto 11 dando así la
victoria y como resultado lanzándonos la pantalla del fin del juego (objeto 12), de lo
contrario si pierdes, se te mostrará la pantalla de perdedor (objeto 10) por último,
pero no menos importante tenemos al objeto 2, que tiene como fin iniciar el juego.

PRUEBAS
Para las pruebas está planeado que en cuanto se junten todas las partes que cada
uno hará para formar el sistema, iremos analizando, corrigiéndolo y mejorándolo,
para así, darle una mejor presentación y una buena jugabilidad al momento de que
el usuario lo pruebe (básicamente haciendo un prueba y error). con esto también
nos ayuda a que el usuario (en este caso los maestros) también sean parte de las
pruebas, corrigiendo o señalando las cosas que quiera dentro o fuera del sistema.

En los requerimientos del usuario estaban bien, lo que no estaba bien eran los bugs
y errores del programa.

Pruebas de caja blanca:

❖ Error 1.1:
nuestro juego contaba con algunos obstaculos por el cual el usuario no tenía que tocar,
estos estaban de color verde, pero al momento de colocarlos al juego estos no eliminaban
al jugador.
★ Solución 1.1:
Una solución que pudimos encontrar fue cambiar los colores, es decir, de verde a rojo y así
poder darle una atracción al juego ya que el rojo podría referirse a peligro.

❖ Error 1.2:
 el personaje cometía el error de doblarse a unos cuantos grados más de lo correspondido.

★ Solución 1.2: la posible solución que le dimos, fue cambiar los grados del personaje para
que así pudiera acoplarse con el funcionamiento del juego.

❖ Error 1.3:
En el momento que el juego se llevará a cabo, si el
usuario llegara a saltar la meta es decir el órgano, este ya no tenía o contenía un fin y el
personaje se seguía sin parar. l

Solución 1.3: se le cambiaron los códigos que tenía ese error y al momento de cambiarlos aunque
te pasaras de la meta esto hacía que perdieras y volvías al inicio por haberte pasado.
PRUEBAS UNITARIAS, DE INTEGRACIÓN Y DE SISTEMA:

❖ Pruebas unitarias:
➢ 1.1 El principal objeto que tiene nuestro sistema es el
personaje, es decir, que este es el que conforma nuestro
juego para que el usuario pueda interactuar con él. Los
códigos que contiene este personaje son tecla, espacio y
presionada; repetir sumar a y, tocando el color rojo,
detener todos los sonidos. estos códigos hacían que
nuestro personaje tuviera un funcionamiento
correctamente.

➢ 1.2 los obstáculos era uno de los objetos que contenía nuestro juego, este
contenía códigos que aparecían en un tiempo correspondido y así el usuario
pudiera pasar y superar cada nivel. Unos de los códigos que contenía eran
los siguientes.

 Pruebas de integración:

 1.2 cuando el personaje y el objeto interactuaron entre sí, captamos muchos

errores, por la cual hace que nuestro sistema no funcionara como
queríamos, nuestro objeto al ser color verde no detecto cuando perdíamos y
la solución fue cambiar el color rojo y cuando lo colocamos hizo funcionar
 todo correctamente y ahora cuando el personaje lo tocaba y perdía; cuando
cada objeto estaba por separado, funcionaba bien, pero al momento de
juntar estos, hubo muchas fallas.

 Pruebas de sistema:
o 1.3 En el momento de poner a prueba nuestro sistema, los errores nunca
faltaron, en el personaje, los obstáculos, los escenarios, los movimientos,
etc.… había problemas que en ocasiones no podíamos solucionar, pero
poco a poco fuimos solucionando cada uno de ellos.
CONTROL DE CAMBIOS:

➔ INICIACIÓN
◆ Nombre del Proyecto: Nombre con el que se identifica el proyecto.
◆ Fecha: Fecha en la que se solicita el cambio.
◆ Solicitado Por: Nombre de la persona que realiza la solicitud de cambio.
◆ Cambio Solicitado: Descripción del requerimiento sobre el cual se realizará
el cambio o del nuevo requerimiento a desarrollar.
◆ Tipo de Cambio: Se clasificará el cambio solicitado en alguno de los
siguientes tipos:
● Justificación del Cambio: Se deberá dar una descripción de la razón
que origina la solicitud del cambio.

➔ EVALUACIÓN
◆ En esta etapa se revisa la solicitud para obtener toda la información necesaria, es

decir que nuestra líder revisará la información sobre el cambio que debemos darle
a nuestro software, Si la solicitud de cambio pasa la etapa de evaluación inicial,
comienza la fase de análisis en donde se tomará una decisión.
➔ ANÁLISIS
◆ El equipo llegará a un acuerdo en la cual deberá ser afirmada para así poder
continuar con el resto de las fases del proceso. posteriormente debe
tomarse en cuenta a todos los integrantes del equipo para así llegar a una
conclusión.
➔ IMPLEMENTACIÓN
 ◆ Aquí es donde los involucrados del proyecto trabajarán para aplicar los cambios del
software. Esto implica volver a revisar el proyecto sobre los problemas que
reportaron, y poder llevarlo a un buen funcionamiento mejor, al igual que se
podrá aprovechar para poder llevar a cabo un mantenimiento preventivo
para así poder evitar tragedias que puedan presentarse más adelante. Es
importante evaluar el alcance del proyecto para garantizar que los ajustes
no tengan un impacto significativo en los objetivos propuestos.
➔ CIERRE
◆ Una vez que la solicitud haya sido documentada, compartida e
implementada, la solicitud está lista para cerrarse. También es
recomendable almacenar el formulario de cambio original y el plan de
proyecto revisado que hayas creado durante el proceso; Una vez que los
documentos estén almacenados en el lugar apropiado, podrás finalizar las
tareas relacionadas y trabajar para finalizar con éxito tu proyecto.
SOPORTE TÉCNICO Y MANTENIMIENTO:

Antes de comenzar o mostrar nuestro proyecto es necesario poder llevar a cabo

un mantenimiento y un soporte técnico, así como a nuestros juegos y como los
dispositivos, por esa razón comparto una lista de lo que se realizará:

 Analizar qué riesgos existen

 identificar si el lenguaje es entendible
 Da oportunidad al aprendizaje
 Verificar si el dispositivo que va a ser utilizado está en buen estado
 Realizar un mantenimiento preventivo antes de presentar el sistema
 Poder hacer una copia de seguridad en caso de que ocurra una tragedia.