REPÚBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN

E.T.C. “MADRE RAFOLS”
VALERA, ESTADO TRUJILLO

PLAN DE CONTINGENCIA PROGRAMA DE PASANTÍAS

Elaborado por:
Lcda. Marineila Butrón
Coordinadora de Pasantías
Docentes colaboradores:
MSc Mary Moreno
Lcdo Carlos Montilla

Marzo, 2020

1
 INTRODUCCIÓN

La pasantía es una vivencia profesional que realiza un estudiante para poner en práctica sus conocimientos y
facultades adquiridas durante su formación académica, siempre acompañado de un tutor que lo guía y lo orienta
para que comience a descubrir el mundo laboral. Sin embargo, surge la necesidad de flexibilizar esa condición de
presencial dadas las circunstancias que atraviesa el mundo actualmente ante la declaración de la Organización
Mundial de la Salud de una pandemia mundial por la emergencia sanitaria del COVID-19.

Es por este motivo que la E.T.C. “Madre Rafols” se ajusta a esta realidad y ofrece a sus estudiantes la
posibilidad de proponer como alternativa las Practicas Profesional Virtuales, la idea es permitir que los
estudiantes, de acuerdo con un plan inicial de prácticas, realicen su periodo de formación desde cualquier lugar y
bajo un enfoque de aprendizaje flexible, autónomo, auto organizado y supervisado por docente del área. Bajo
esta modalidad se garantiza un periodo de formación práctica de calidad, el cual se realizará mediante el diseño
de un procedimiento de tutoría integral en el que deben participar E.T Madre Rafols, representantes y
estudiantes, atendiendo así además a las orientaciones emanadas del Ministerio del Poder Popular para la
Educación.

Actividades Plan de Contingencia Pasantías Virtuales INFORMÁTICA

2
N° Descripción Objetivo Actividades Tutores Fecha
Análisis de requerimientos: Acá establece ¿Qué vas a Informe
Orientación para realizar? ¿Cómo será tu juego? Roles del equipo, ¿Cómo se preliminar
1 realizar un juego organizará el trabajo y el equipo? Planeamiento de la Lunes
cumpliendo con los Diseñar e interacción a realizar 13/4/2020
pasos a seguir en el Implementar un
Ciclo de Vida de un juego que sea
Sistema. Partiendo flexible y fácil Diseño En esta parte puedes realizar pantallas o prototipos Diseño
de una idea o de utilizar, de que realizaras. En un primer avancen deben plantearse Roger Rivero Miércoles
necesidad del equipo, presentando el propósito y alcance del trabajo, Establecer prototipo del Mary Moreno 24/4/2020
luego se establecerán una ayuda al juego, las Historia de usuarios e Indicar que software será José Santos
los requerimientos, usuario. utilizado y ¿Por qué?. Jenner Villa
Diseño, Desarrollo, En un segundo avance presentar el modelo del Diseño
Pruebas e Sistema a realizar (Sé sugiere Modelo en UML), establecer Viernes
implantación del los Requerimientos funcionales y Requerimientos no 8/5/2020
Sistema o Software a funcionales
implementar.
En este orden, se Desarrollo: La elección del programa o software a utilizar es Desarrollo
realizara un informe elección del equipo de trabajo. El desarrollo del juego será Viernes
cuya estructura esta en cualquier lenguaje de libre elección. Como propuesta le 15/5/2020
basada en las colocamos Gamemaker studio. Este avance debe llevar el
directrices dadas por Modelo, los requerimientos y debe enviar un avance o juego
el estándar IEEE de pantallas realizadas
Práctica Prueba de sistemas: Durante la prueba de sistemas, el Pruebas
Recomendada para equipo realizara de manera experimental pruebas al juego Viernes
Especificaciones para asegurarse de que el software no tenga fallas. Pruebas 22/5/2020
de Requisitos realizadas (al juego, ¿Qué estas validando?)
Software ANSI/IEEE
830, 1998. Implantación o Lanzamiento del Sistema: La implantación
es el proceso de verificar e instalar que ya el juego está listo Implantación
para ser evaluado. Debe enviar el informe completo; Equipo Viernes
de Trabajo, Planteamiento realizado, Prototipo realizado, 5/6/2020
Modelo del Sistema, Pantallas del Juego y Manual de ayuda
al usuario

3
 PARTICIPANTES DE INFORMATICA

Respetad@ participante:

   Se les agradece y hace de su conocimiento lo grato que es contar con su

participación en este contexto de aprendizaje en línea. Permítame indicarle que
estamos a tiempo de desarrollar en conjunto la actividad asignada para dar
cumplimiento a un aprendizaje entorno al proceso de Pasantías Profesionales. Es
bueno destacarle que actualmente estamos en un plan de contingencia a nivel nacional
y es conveniente NO SALIR DE CASA, evitemos propagar el COVID-19, si van a
trabajar en grupos (Máximo 3 por equipo y se evaluara el Caso) utilizar para estar
comunicados; videollamadas, llamadas normales, audios por Messenger o whatsapp,
fotos y mensajes a través de estos mismos. Además se entiende que tenemos
problemas en el servicio de fluido eléctrico, más la caída del servicio de internet que
obstaculiza el buen desarrollo del proceso enseñanza-aprendizaje. Sin perder nuestro
horizonte, recuerden que es necesario y pertinente el acceder a los recursos y material
suministrado por este equipo de la E.T.C Madre Rafols, para desarrollar cada una de
las actividades establecidas

Es bueno reiterarles que aun están a tiempo de cumplir con la labor asignada,
recuerda cada uno de nosotr@s guía el proceso enseñanza-aprendizaje. Estamos
dispuestos a apoyarte en ese caminar. Nunca lo duden, con el favor de Dios y este
equipo de Docentes les apoyaremos en su andar.

    Estamos conectados. Esperamos su email o consulta por el grupo whatsapp .

ACTIVIDAD ASIGNADA N° 1

Realizar un Juego

OBJETIVO:
El participante adquirirá las competencias para diseñar e implementar un juego,
que presentara al usuario con reglas, originalidad y un atractivo único.
 Se han identificado pequeños objetivos para alcanzar este objetivo principal:

- Analizar el Contexto: es importante empezar el trabajo analizando el

contexto en el que se va a desarrollar, y para ello es necesario comenzar
planteándonos ¿Qué voy a diseñar? ¿cuál problemática dentro del campo
de las TIC quiero abordar desarrollando un juego?.¿Cuál es la idea del
juego a desarrollar? Una vez analizada la problemática pasamos a
analizar las características de los diferentes software para desarrollar el
juego. Finalmente veremos ¿cuáles son las principales técnicas que se
pueden usar?. ¿Cómo se organizará el trabajo y el equipo?

- Diseñar el Juego: para llevar a cabo el diseño de la aplicación

seguiremos y tendremos en cuenta un modelo que consiste en ¿Qué
queremos haga el juego? Además escogeremos qué técnicas
utilizaremos para nuestro juego.

- Implementar el Juego: una vez hecho el diseño, pasamos a la

implementación, y primero tenemos que ver qué tecnología es la más
adecuada para implementar el juego teniendo en cuenta las
características del diseño. ¿En qué software lo implementare? ¿Es fácil
de utilizar? ¿Soy capaz de aprenderlo autodidácticamente?

- Evaluar el Juego: una vez realizada la implementación del juego, el

participante realizara pruebas para asegurar que cumpla con las metas
establecidas por el equipo, presentara su informe escrito con el fin de dar
soporte del trabajo desarrollado pertinentes al juego, que nos servirán
también para analizar posibles líneas de trabajo futuro.

ELEMENTOS QUE CONSTITUYEN UN JUEGO

De acuerdo al trabajo presentado en Prensky(2001), existen seis elementos
estructurales que caracterizan a un juego:
• Reglas: que organizan el juego
• Metas, Duración y objetivos

5
• Resultado ("outcome") y retroalimentación ("feedback"): que permiten medir el
progreso ante las metas
• Desafío
• Interacción: como aspecto social
• La historia o representación

ROLES EN UN SISTEMA DE INFORMACIÖN

 Administrador de proyecto, El Rol de administrador de proyecto es un rol muy
importante, debido a que sus acciones y decisiones afectan al proyecto
completo. En un proyecto, siempre debe existir un administrador, pero se debe
tener en cuenta que un administrador puede dirigir más de un proyecto. Su
Objetivo es Controlar Avance del Proyecto (Diseño y desarrollo).
 Analista; El rol de analista es muy importante, debido a que el éxito del proyecto
dependerá de una buena especificación de requisitos. Debe;
• Analizar e Identificar
• Realizar el análisis de los requisitos
• Analizar la estructura básica del sistema
• Generar los diagramas de la arquitectura.
 Diseñador: El propósito del diseño es el de crear una estructura interna limpia y
relativamente simple, también llamada a veces una arquitectura. Este rol
desempeña las siguientes actividades:
• Generar prototipos rápidos del sistema.
• Diseñar el documento arquitectónico y mantenerlo actualizado durante el
proyecto.
• Velar por que el producto final se ajuste al diseño realizado.
 Programador, Los programadores deben convertir la especificación del sistema
en código fuente ejecutable utilizando uno o más lenguajes de programación, así
como herramientas de software de apoyo a la programación. El programador
debe:
• Menor cantidad de problemas de testeo.
• Aumento de la productividad de los programadores.
• Aumento de la eficiencia en la manutención del programa.
• Reducir el tiempo de codificación, aumentando la productividad del
programador.
• Disminuir el número de errores que ocurren durante el proceso de
desarrollo.
• Disminuir los costos del ciclo de vida del software.

6
 Téster, El objetivo principal de la labor de téster es el de diseñar test o pruebas
que en forma sistemática, permita eliminar diferentes clases de errores,
realizando esto con la mínima cantidad de tiempo y esfuerzo. Para ello debe;
• Construir y aplicar los planes de prueba unitarios de modulo, de sistemas,
de aceptación parcial, manteniéndolos actualizados durante el proyecto.
• Velar por la amplitud y la exactitud de todos los documentos del proyecto.
• Coordinar las inspecciones y/o caminatas.
• Velar por el estándar adoptado para el desarrollo.
• Velar por la calidad del producto final.
 Asegurador de calidad, El asegurador de calidad debe ser una persona con
mucha experiencia en proyectos de desarrollo de software, con conocimientos
suficientes sobre técnicas que aseguren la calidad de un producto de software.
Entre las actividades del Asegurador de Calidad están:
• Participar en las revisiones técnicas formales (RTF). Documentos de
requisitos de Usuario y Software
• Plan de administración del proyecto.
• Plan de testeo.
• Fase de diseño .arquitectónico.
• Fase de diseño detallado.
• Políticas de control de cambios, control de errores y control de la
configuración.
• Documentación
 Documentador,; El objetivo principal de la documentación es de actuar como
medio de comunicación entre los miembros del equipo, incluyendo el cliente para
asegurar la gestión de la configuración. La documentación es necesaria para
informar a todos los miembros del equipo de desarrollo acerca del estado y
evolución del proyecto. Debe velrificar:
• La Estructura del Documento.
• Tipos de letra y colores a usar en cada Documento.
• Distribución de los elementos en el
• Mostrar en el informe Requisitos funcionales y no funcionales
• Características de las figuras, imágenes y dibujos consideradas en el
documento.
 Ingeniero de manutención, El mantenimiento de un sistema es a veces la
prioridad ignorada, el Ingeniero de manutención se encarga de actualizar los
sistemas, corregir los errores producido en el uso de éste y darle mantenimiento
al programa. Los objetivos que este rol tiene son:
• Modificar el software para adaptar nuevas funciones o modificar algunas
funciones existentes
• Modernizar el software por medio de cambios al sistema.

7
 • Asegurarse de que el equipo de desarrollo esté informado de los errores
encontrados en el sistema
 Ingeniero de validación y verificación, Deben tener las habilidades necesarias
para descubrir errores en funciones, lógica e implementación en cualquiera de
las representaciones del software.
 Ingeniero de Implementación La implementación es la última fase del proceso
de desarrollo de software. Sin embargo, la implementación toma una parte
importante del presupuesto destinado al desarrollo.
 Clientes: Un cliente comprometido se relacionará principalmente con el
administrador de proyecto y con los analistas en forma frecuente

¿Porque los roles son importantes?

Cuando iniciamos el desarrollo de un Sistema o Software de esta manera es que
se visualiza cada actor del proyecto

8
METODOLOGIA A UTILIZAR

En el diseño de un sistema interactivo es muy importante tener en cuenta al

usuario en todo momento para que sea el punto central del desarrollo, conocido como
Diseño Centrado en el Usuario (DCU). La finalidad de este diseño es que finalmente el
usuario tenga la impresión real de que ese sistema le ayudará a realizar sus tareas y a
alcanzar sus objetivos. Para el desarrollo del juego interactivo se propone utilizar el
Modelo de Proceso (MP), que integra los modelos y tareas específicas de la Usabilidad.
También puede utilizar la Metodología XP para seguir su proceso metodológico. En la
figura 1 se muestra el esquema de este modelo de proceso con sus diferentes fases:

Figura 1. Modelo de proceso de la ingeniería de usabilidad [32]

 Análisis de requerimientos: Es una tarea que cubre el hueco entre la

definición del software a nivel sistema y el diseño del mismo. En esta parte el
desarrollador como el cliente (usuario del juego) tienen un papel activo, pues
juntos definen en detalle los requisitos del sistema a desarrollar, la
planeación de lanzamientos del sistema (Historia de usuarios), los pasos a
seguir. Acá establece ¿Qué vas a realizar? ¿Cómo será tu juego? ¿ Cómo se
organizará el trabajo y el equipo ?¿Cómo se organizará el trabajo y el
equipo?
 Diseño El diseño de un sistema de información produce los detalles que
establecen la forma en la que el sistema cumplirá con los requerimientos

9
 identificados durante la fase de análisis. Los especialistas en sistemas se
refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la
del desarrollo del software, a la que denominan diseño físico. En esta parte
puedes realizar pantallas o prototipos de que realizaras. Se solicitara en el
Lenguaje Unificado de Modelado (UML), el UML fue creado para forjar un
lenguaje de modelado visual común y semántica y sintácticamente rico para
la arquitectura, el diseño y la implementación de sistemas de software
complejos, tanto en estructura como en comportamiento. UML tiene
aplicaciones más allá del desarrollo de software, p. ej., en el flujo de procesos
en la fabricación. Se utilizara los casos de usos solamente.
 Desarrollo: En esta parte los encargados de desarrollar software pueden
instalar software comprobando a terceros o escribir programas diseñados a la
medida del solicitante. La elección del programa o software a utilizar es
elección del equipo de trabajo. El desarrollo del juego será en cualquier
lenguaje de libre elección. Como propuesta le colocamos Gamemaker
studio: es una aplicación de software de desarrollo de videojuegos, escrito
por Mark Overmars en el lenguaje de programación Delphi. Está diseñado
para permitir a los usuarios diseñar videojuegos fácilmente sin tener que
aprender un lenguaje de programación complejo como C++ o Pascal. (Ver
Referencias tienen enlaces de interés)

 Prueba de sistemas: Durante la prueba de sistemas, el equipo realizara de

manera experimental pruebas al juego para asegurarse de que el software no
tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en
la forma en que los usuarios esperan que lo haga. En esta fase el equipo se
preguntarà; ¿Qué quiero validar?, ¿Qué resultado se obtendrá si se da una
tecla en blanco?, ¿Qué quiero se ejecute?, ¿Hace lo que quiero?
 Implantación o Lanzamiento del Sistema: La implantación es el proceso de
verificar e instalar que ya el juego está listo para ser evaluado, se debe
entrenar a los usuarios, instalar la aplicación y construir todos los archivos de
datos necesarios para utilizarla (Ayuda al Usuario).

Es importante hacer una planificación del proyecto donde se establezcan las

metas y objetivos de éste. Para ello es necesario listar las diferentes tareas que se
llevarán a cabo en el proceso de desarrollo y ordenarlas según la prioridad que deben
tener, según nuestro criterio inicial y en vistas del futuro juego a implementar. La
planificación siempre esta propensa a sufrir algunos cambios durante el desarrollo del
proyecto por motivos diversos que han forzado una mayor dedicación de tiempo a unos

10
temas concretos, así como la finalización de otros temas en un tiempo menor del
planificado inicialmente.

Se propone estas etapas para realizar esta actividad agrupadas en tres fases: la
parte teórica del proyecto (3 semana aproximadamente), la parte práctica que engloba
todos los pasos del aprendizaje del lenguaje o software y la implementación del juego
(4 semanas aproximadamente), y la parte final de evaluación del juego y la redacción
de la versión final de la memoria del trabajo (2 semana aproximadamente).

Las fases de la metodología se resumen en esta figura, todo surge de una idea
de emprender o realizar un juego, luego el equipo interactuara y debatirá sobre las
ideas en el desarrollo, para realizar mejoras constantes y finalmente presentar el
producto.

11
ENTREGA DE AVANCES

Nro Actividad a Desarrollar Contenido Informe Fecha TUTORES

1 Informe preliminar.  Portada Lunes
 ¿Qué juego piensan hacer?  Roles del Equipo de trabajo 13/4/2020
 ¿ Cómo se organizará el  Historia de usuarios ROGER RIVERO
trabajo y el equipo ?  Planteamiento de Juego a rogerrivero727@gmail.com
 Historia de usuarios realizar (su propuesta)
 Planeamiento de la interacción
a realizar ALEJANDRO SANTOS
2 Fase Diseño  Portada Miércoles josealejandrosantos@yahoo.es
 Propósito y alcance  Equipo de trabajo 24/4/2020
 Establecer prototipo del juego  Propósito y Alcance del Juego
MARY MORENO
 Historia de usuarios  Historia de usuarios mrml72858@gmail.com
 Indicar software utilizado y ¿Por  Prototipos o pantallas
qué? JENNER VILLA
3 Fase Diseño  Perspectiva del producto Viernes ueserristaj92@gmail.com
 Modelo UML  Modelo en UML 8/5/2020
 Presentar requerimientos  Requerimientos funcionales
 Requerimientos no funcionales
4 Desarrollo del Software  Modelo en UML Viernes
 Realizar captures  Requerimientos funcionales 15/5/2020
 Requerimientos no
funcionales
 Enviar un avance o juego de
pantallas realizadas
5  Pruebas al Sistema  Portada Viernes
 Pruebas realizadas (al juego, 22/5/2020
¿Qué estas validando?)
6  Implantación y Informe Final  Portada Viernes
listo  Equipo de Trabajo 5/6/2020
 Planteamiento realizado
 Prototipo realizado
 Pantallas del Juego
 Manual de ayuda al usuario

Cuadro Nº1. Historia de usuario

Código Historia Usuario Fecha Responsable

¿Qué realizaron? ¿Quiénes ¿Cuándo? ¿Quién es el

¿Qué plantearon hacer? ¿Lograron lo participaron? responsable?
establecido?
¿Qué es lo que el software debe de resolver
para que este genere valor al juego?
¿Qué debe ser hecho en primer lugar?
¿Cómo se organiza el trabajo y el equipo?

12
ENLACES DE INTERES

Blog con todos los programas que se pueden usar para crear videojuegos
con sus respectivos link de descarga: https://blog.uptodown.com/programas-crear-
videojuegos/

REFERENCIA BIBLIOGRAFICA

 Prensky , (2001). Digital Game-based Learning. McGraw-Hill, New York. (2001)

 Granollers, Toni (2010). “La Ingeniería de la Usabilidad: concepto y principales
referencias”. Último acceso el 05 de Diciembre de 2010 desde
http://www.innova.euskadi.net/v62-
0022/es/contenidos/informacion/boletin_enero_2010/es_enero/images/foto08.jpg
 Especificación de Requisitos Software (ERS) basándose en las directrices dadas por el
estándar IEEE Práctica Recomendada para Especificaciones de Requisitos Software
ANSI/IEEE 830, 1998.
 Enlaces para descargar gamemaker:
http://www.mediafire.com/file/977l7uk68bptcrh/gamemaker_1.4_por_ilogic_2.rar/file
 https://mega.nz/#!Hl40EYra!xmgN8lu3493m_c6YC9cRDABus-YN4cmDqLHfvNu_W9Q )
 Blog con todos los programas que se pueden usar para crear videojuegos con sus
respectivos link de descarga: https://blog.uptodown.com/programas-crear-
videojuegos/

Descargas de juegos online

 https://codecombat.com/
 http://code.org/
 https://www.playcodemonkey.com/
 https://www.codehunt.com/
 https://www.codingame.com/
 https://pilas-engine.com.ar/

Aprender Python

 https://www.infotechnology.com/online/Aprender-Python-gratis-donde-estan-los-mejores-
cursos-y-como-acceder-20190606-0004.html
 https://codigofacilito.com/cursos/Python
 https://www.azulweb.net/curso-completo-python-totalmente-gratis/

13
CRITERIOS A EVALUAR DEL JUEGO

ACTIVIDAD SOBRESALIENTE NOTABLE APROBADO INSUFICIENTE

Conocimiento Los estudiantes Los estudiantes La mayor parte Algunos
ganado pueden pueden de los estudiantes en
fácilmente y fácilmente y estudiantes el grupo NO
correctamente correctamente pueden pudieron
explicar varios explicar 1-2 fácilmente y correctamente
aspectos sobre aspectos sobre correctamente explicar
el software el software explicar 1-2 aspectos sobre
usado para usado para el aspectos sobre el tema usado
realizar el juego juego el tema usado para el juego
para el juego
Precisión del El o la El o la El o la El o la
Contenido participante participante participante participante No
explica a detalle explica explica poco al explica al
al usuario los someramente al usuario los usuario los
tiempos usuario los tiempos tiempos
establecidos y tiempos establecidos y establecidos y
requerimientos establecidos y requerimientos requerimientos
para jugar requerimientos para jugar para jugar
para jugar
Reglas del Juego Las reglas Las reglas Las reglas Las Reglas no
fueron escrita lo fueron escrita fueron escrita fueron escritas
suficientemente pero una parte pero los
claras para que del juego usuarios tienen
todos puedan necesita un poco dificultad para
fácilmente más de entender el
comprender explicación juego
como jugar el
juego
Creatividad El grupo puso El grupo puso El grupo trató de Poco esfuerzo
mucho esfuerzo mucho esfuerzo hacer un juego fue puesto para
en hacer un en hacer eln interesante y hacer el juego
juego juego divertido, pero interesante y
interesante y interesante y algunas cosas divertido,
divertido para divertido para hicieron el juego
jugar, como fue jugar, usando difícil de
demostrado por textura, escritura entender y/o
las preguntas elegante y/o disfrutar.
creativas, personajes
piezas, o el interesantes
juego mismo
Atractivo Colores Colores Colores Poco o no color
contrastantes, contrastantes o contrastantes o o menos de 2
gráficos o un gráfico dan al al menos un gráficos fueron
imágenes dan al juego un gráfico dan al incluidos
juego un atractivo visual juego un
atractivo visual atractivo visual

14
 ANEXO

Informe de Especificaciones de Requisitos de

Software

El equipo desarrollador del juego o software debe realizar el informe

de especificaciones de requisitos de software, parte fundamental en el
desarrollo de cualquier sistema de información. Por lo cual se les anexa los
ítems que tendrá el informe para que se adapte a la realidad de cada
equipo de trabajo. El cual será presentado y reportado según el
cronograma de avances solicitado por el equipo docente.

Las Especificación de Requisitos Software (ERS) para el Juego

Desarrollado por Ustedes. Esta estructurado basándose en las directrices
dadas por el estándar IEEE Práctica Recomendada para Especificaciones
de Requisitos Software ANSI/IEEE 830, 1998.

15
 REPÚBLICA BOLIVARIANA DE VENEZUELA
MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN
E.T.C. “MADRE RAFOLS”
VALERA, ESTADO TRUJILLO

Informe de Especificaciones de Requisitos de Software

NOMBRE DEL Juego “Combatiendo con cultura el COVID-19”

Equipo:
Apellido Nombre
Apellido Nombre
Apellido Nombre
Docente Asesor:
Apellido Nombre

Marzo, 2020

16
Informe de Especificaciones de Requisitos de Software

1. Introducción

Este documento es una Especificación de Requisitos Software (ERS) para el Juego Desarrollado
por Ustedes. Esta especificación se ha estructurado basándose en las directrices dadas por el
estándar IEEE Práctica Recomendada para Especificaciones de Requisitos Software ANSI/IEEE 830,
1998.

Propósito

El presente documento tiene como propósito definir las especificaciones funcionales, no

funcionales para el desarrollo del sistema a desarrollar su Juego que permitirá gestionar distintos
procesos propuesto por el equipo. Éste será utilizado por los estudiantes (creadores del juego),
profesores y usuarios.

Alcance

Esta especificación de requisitos está dirigida al usuario del sistema, para definir el alcance de un
proyecto, debemos comenzar por establecer un plazo de tiempo para el sistema a
realizar, estudiar y establecer los objetivos del mismo y la distribución estratégica de recursos
requeridos.

Personal involucrado
El hecho de que en un grupo de desarrollo no se tengan claro los roles y sus responsabilidades y
actividades asociadas, hace que se produzcan problemas. El equipo debe indicar los roles a desempeñar
cada uno en el proceso del desarrollo del software, para ello se le presentan los roles en el área de
sistemas se tienen:

 Administrador de proyecto
 Analista;
 Diseñador
 Programador
 Téster,
 Asegurador de calidad
 Documentador
 Ingeniero de manutención
 Ingeniero de validación y verificación
 Ingeniero de Implementación
 Clientes

El equipo debe presentar el personal involucrado en el proyecto de la siguiente manera por

ejemplo:

17
 Nombre
Rol
Categoría Profesional
Responsabilidad
Información de contacto
Juan Rodríguez
Analista, diseñador y programador
TSU-Informática
Análisis de información, diseño y programación del SIS-I
Elgranjuan138@hotmail.com

Definiciones, acrónimos y abreviaturas

En este apartado deben indicar las definiciones, acrónimos y abreviaturas a utilizar en el informe.
Por ejemplo se le indican:

Nombr Descripción
e
Usuario Persona que usará el sistema para gestionar procesos
SIS-I Sistema de Información Web para la Gestión de Procesos
Administrativos y Académicos
ERS Especificación de Requisitos Software
RF Requerimiento Funcional
RNF Requerimiento No Funcional
FTP Protocolo de Transferencia de Archivos

Referencias

Titulo del Documento Referencia

Standard IEEE 830 - 1998 IEEE

Resumen

POR EJEMPLO SE PROPONE COLOCAR LO SIGUIENTE:

Este documento consta de tres secciones. En la primera sección se realiza una introducción al
mismo y se proporciona una visión general de la especificación de recursos del sistema.

En la segunda sección del documento se realiza una descripción general del sistema a desarrollar
(El Juego), con el fin de conocer las principales funciones que éste debe realizar, los datos
asociados y los factores, restricciones, supuestos y dependencias que afectan al desarrollo, sin
entrar en excesivos detalles.

Por último, la tercera sección del documento es aquella en la que se definen detalladamente los
requisitos que debe satisfacer el sistema.

18
Descripción general
Esta parte permite identificar las necesidades del producto a desarrollar mediante la
obtención de los requisitos funcionales y no funcionales, ayudando al desarrollador a
comprender la naturaleza del producto a construir, así como detectar las
funcionalidades requeridas. El desarrollo de este apartado comenzará con la
perspectiva del producto ¿Qué queremos hacer? ¿Los objetivos planteados? Para
luego presentar la extracción y análisis detallado de los casos de uso y concluirá con la
extracción de los requisitos software, funcionales y no funcionales que se han extraído
del análisis del sistema.
Perspectiva del producto
En este apartado el equipo definirá las perspectivas del producto o juego a realizar, son una
colección de vistas que visualizan los datos en un modo coherente. Además los objetivos
planteados para desarrollar el Producto. Recuerden que diferentes perspectivas pueden
proporcionar diferentes vistas en los datos almacenados. Por ejemplo, una perspectiva
de Empresa visualizará una barra de menús y varias vistas de detalle y vistas de colección que
utilizan todas ellas terminología coherente que es significativa para un analista de sistema. Una
perspectiva de Desarrollo visualizará una barra de menús diferente, vistas de detalle y vistas de
colección que probablemente utilizarán terminología más técnica que es significativa para un
desarrollador de servicio.

Por ejemplo colocar:

El sistema NOMBRE será un producto diseñado para trabajar en entornos WEB, lo que permitirá
su utilización de forma rápida y eficaz, además se integrara conjuntamente con una interfaz
(Dinámica) para lograr entretener al usuario.

Funcionalidad del producto

En esta sección se van a detallar los diferentes casos de uso que se han definido durante la fase
de análisis del proyecto. Los casos de uso cubren las distintas funcionalidades que podrán
realizar los distintos usuarios que interactúen con el producto. Construir funcionalidades en
un producto no garantiza que tus usuarios las utilicen. Funcionalidad es lo que un producto puede
hacer. En este apartado el equipo se pregunta   ¿qué funcionalidades debe ofrecerte un
buen software que desarrollara el Juego XXX? ¿qué escenarios serán planteados en el
juego? ¿Cómo explico que hará el juego?. Se utilizara para el Modelado del Sistema a desarrollar
el Lenguaje de Modelado Unificado (UML) y realizaran Casos de uso general.

El actor o Rol representa el rol jugado por una persona o cosa que actúa con el sistema. Un

actor se representa a entes externos al sistema, además un actor intercambia señales y

datos con el sistema

19
Según Martin Fowler, un caso de uso es un conjunto de escenarios que tienen una meta de
usuario en común. Es decir, es una descripción de un proceso fin a-fin, relativamente largo, que
incluye varias etapas o transacciones. Además describe un grupo de actividades de un sistema
que produce un resultado concreto y tangible, es decir, son los servicios prestados por el
sistema. El nombre de un caso de uso debe indicar acción, ser claro y conciso (verbo +
predicado). Un caso de uso se representa mediante elipses con el nombre del caso.

Registrar

¿Què es un Escenario?: Es una secuencia de acciones e interacciones (pasos) entre los usuarios
(actores) y el sistema por ejemplo: “El usuario introduce su nombre de usuario y su contraseña.
El sistema verifica la validez del nombre de usuario y de la contraseña y permite al usuario el
acceso al sistema. Elsistema muestra la pantalla principal del sistema. El usuario selecciona la
opción de añadir nuevo empleado. El sistema muestra...”

Actualmente, mucha gente considera que los casos de uso son de vital importancia en los
proyectos de software (Procesos Guiados por Casos de Uso), en virtud, que describen bajo la
forma de acciones y reacciones el comportamiento de un sistema desde el punto de vista de un
usuario. Se puede considerar que hasta cierto punto, cada caso de uso es independiente de los
demás. Deben presentar el caso de uso general del Juego como este ejemplo

20
 Caso de Uso General de un Sistema de Gestión de Evaluaciones

Caso de Uso desde la Pantalla Inicial del Jugador

Características de los Actores u usuarios

En este apartado debe llenar el cuadro por cada actor o usuario que participará en el Sistema a
desarrollar. Por ejemplo se presentan estos:

Tipo de usuario Administrador

Formación Técnico Medio en Informática

21
 Actividades Control y manejo del sistema en general

Tipo de usuario Profesor

Formación Educador
Actividades Facilitar el proceso de aprendizaje

Restricciones
Las combinaciones de restricciones en un sistema y sus configuraciones que se pueden
realizar son muy extensas y variadas. Por ejemplo; Siempre existirá un usuario que tenga
acceso a todo el sistema, en este caso, corresponde al Administrador del Sistema. También
habrá usuarios que sólo tengan acceso a ciertas aplicaciones o módulos del sistema.
Algunas restricciones pueden ser por ejemplo:

 Interfaz para ser usada con internet.

 Uso de Dominio (X)
 Lenguajes y tecnologías en uso: HTML, JAVA.
 Los servidores deben ser capaces de atender consultas concurrentemente.
 El sistema se diseñará según un modelo cliente/servidor.
 El sistema deberá tener un diseño e implementación sencilla, independiente de la
plataforma o del lenguaje de programación.
.

Suposiciones y dependencias

 Se asume que los requisitos aquí descritos son estables

 Los equipos en los que se vaya a ejecutar el sistema deben cumplir los requisitos antes
indicados para garantizar una ejecución correcta de la misma

Requisitos específicos
 Requerimientos funcionales.- Son declaraciones de los servicios que proveerá el sistema, de
manera en que éste reaccionará en situaciones particulares

 Requerimientos no funcionales.- Son restricciones de los servicios o funciones ofrecidos por el

sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estándares, etc.

En este apartado se va a detallar el formato de las tablas utilizadas para definir los diferentes casos de
uso que se extraen de la aplicacion desarrolladas. Para ello se hará uso de la siguiente tabla:

Identificación del requerimiento: Coloca una abreviatura RF (Req. Funcional)

RNF (Req. No Funcional)
Código que identifica de forma unívoca cada caso
de uso.
Nombre: Nombre descriptivo del caso de uso.
Actores: tipo de usuario de la aplicación.

22
Descripción: Explicación clara y concisa del caso de uso que se está
especificando.
Actividad: El cliente realiza una compra de algún producto y proporciona los datos si el
cliente quiere ser registrado y la cantidad de productos
Pasos:
Ejecución del caso de uso paso a paso con un orden determinado.
Indicar de manera secuencial cada uno de los pasos para ejecutar una
determinada operación.

Precondiciones: Condiciones que se deben cumplir previamente para poder

realizar una determinada operación.
Prioridad: Alta – Media – Baja para el desarrollo del Sistema
Riesgo: Medio – Alto – Bajo

Algunos ejemplos visuales de Requerimientos deben identificarlos por tipo

Requerimientos Funcionales

Identificación del requerimiento: RF01

Nombre: Emitir Factura
Actores: Cliente, Empleado u Usuario
Descripción: Permite Registrar la compra efectuada por un cliente
Actividad: El cliente realiza una compra de algún producto y proporciona los datos si el
cliente quiere ser registrado y la cantidad de productos
Pasos:
-Se verifica que el producto exista
-Se verifica si está disponible la cantidad solicitada
-Se calcula el total a pagar
-Emite Factura
-Se registra la cancelación del cliente
-Se actualiza el Inventario del producto
Precondiciones: Que hay producto en existencia
Prioridad: Alta
Riesgo: Medio

23
 Requerimientos No Funcionales.

Identificación del RNF01

requerimiento:
Nombre del Ayuda en el uso del sitema.
Requerimiento:
Características: La interfaz del usuario deberá de presentar un sistema de ayuda para
que los mismos usuarios del sistema se les faciliten el trabajo en cuanto
al manejo del sistema.

Descripción del La interfaz debe estar complementada con un buen sistema de ayuda
requerimiento:
(la administración puede recaer en personal con poca experiencia en el
uso de aplicaciones informáticas).

Prioridad del requerimiento:

Alta

Requisitos de Software
A continuación se describen los requisitos software del juego y de la aplicación
desarrollada, estos requisitos se han concretado en las diferentes reuniones que se han tenido
con el equipo y tutor del proyecto. Con el fin de facilitar la tarea de compresión por parte del
equipo, en primer lugar se propone explicar la estructura de cada uno de los requisitos así como
los campos por los que está compuesta su definición, y posteriormente mostrar la manera en la
que están agrupados. Cada requisito estará representado por una tabla de la siguiente forma:

Donde cada campo significa lo siguiente:

 Identificación: Código que identifica de forma unívoca cada uno de los requisitos.
 Título: Título descriptivo del requisito.
 Descripción: Explicación clara y concisa del requisito que se está especificando.
 Prioridad: Orden de cumplimiento de un requisito. A mayor prioridad, mayor urgencia
para realizarlo.

24
  Estabilidad: Probabilidad de cambio de un requisito. A mayor estabilidad, menor
posibilidades de que dicho requisito se vea modificado.
 Claridad: Cataloga la no ambigüedad de un requisito. Cuanta mayor claridad tenga,
menor ambigüedad contendrá.
 Verificabilidad: Facilidad para comprobar que el sistema cumple un requisito.
 Necesidad: Esencialidad. Interés del cliente en la realización de un requisito.
 Fuente: Origen del requisito ya sea una persona o documentación

Por otro lado, con ánimo de ofrecer una estructura que facilite la realización y comprensión
de los requisitos, se van a organizar en dos categorías:

 Requisitos software funcionales: especifican qué tiene que hacer el software. Definen el
propósito del software.
 Requisitos software no funcionales: especifican como el software debe hacer las cosas y
que debe cumplir

Requisitos funcionales
Ejemplo

Requisitos No funcionales
Ejemplo

25
 3.2. Requisitos comunes de las interfaces

3.2.1 Interfaces de usuario

La interfaz con el usuario consistirá en un conjunto de ventanas con

botones, listas y campos de textos. Ésta deberá ser construida
específicamente para el sistema propuesto y, será visualizada desde un
navegador de internet.

3.2.2. Interfaces de hardware

Será necesario disponer de equipos de cómputos en perfecto estado con

las siguientes características:

 Adaptadores de red.
 Procesador de 1.66GHz o superior.
 Memoria mínima de 256Mb.
 Mouse.
 Teclado.

3.2.3. Interfaces de software

 Sistema Operativo: Windows XP o superior.

 Explorador: Mozilla o Chrome.

3.2.4. Interfaces de comunicación

Los servidores, clientes y aplicaciones se comunicarán entre sí, mediante

protocolos estándares en internet, siempre que sea posible. Por ejemplo,
para transferir archivos o documentos deberán utilizarse protocolos
existentes (FTP u otros convenientes).

4.- Manual de Ayuda del Sistema de Juego XXX

En este apartado el equipo indicara al usuario ¿Cómo se juega?¿Teclas a

usar? ¿Retos del juego?. Se evaluara la originalidad.

5.- CONCLUSIONES

Que importante es llegar a conclusiones en el trabajo de investigación, es el

respiro profundo que abre las puertas a la parte final del estudio donde se
presentara sin argumentación y en forma resumida, los resultados del trabajo
26
 realizado efectuado por el equipo en torno al desarrollo del Sofware, derivado del
tratamiento de los datos y de las interrogantes planteadas. Es decir, para llegar
hacer una conclusión debemos de partir de los objetivos que nos planteamos en
nuestra investigación.

6.- RECOMENDACIONES
Las recomendaciones, en un estudio de investigación están dirigidas a
proporcionar sugerencias a la luz de los resultados, en este sentido las
recomendaciones están dirigidas:
 Sugerir, respecto a la forma de mejorar los métodos de estudio
 Sugerir acciones especificas en base a las consecuencias
 Sugerencias para futuras investigaciones

27