INSTITUTO TECNOLOGICO SUPERIOR CORDILLERA.

CARRERA:

ANÁLISIS DE SISTEMAS.

TEMA:
SISTEMATIZACIÓN DE LOS PROCESOS ACADÉMICOS MEDIANTE EL USO DE

CODE BLOCK.

INTEGRANTES:
CHUQUITARCO CRISTIAN.

GUACHICHULCA NELSON.

PARAMO JORDAN.

PERIODO ACADÉMICO:

ABRIL/SEPTIEMBRE 2017

1
Índice
1. Antecedentes. ............................................................................................................................... 4
1.1. El problema. ........................................................................................................................ 4

1.2. Objetivos. ............................................................................................................................. 4

1.2.1. Objetivo general. ..................................................................................................... 4

1.2.2. Objetivos específicos................................................................................................ 5

1.3. Justificación. ........................................................................................................................ 5

1.4. Alcance del proyecto. .......................................................................................................... 5

1.5. Marco teórico. ..................................................................................................................... 7

1.5.1. Introducción ............................................................................................................ 7

1.5.2. Sistemas de Información computarizados ............................................................. 7

1.5.3. Páginas web ............................................................................................................. 8

1.5.4. PHP ...................................................................................................................................... 9

1.5.5. HTML ................................................................................................................................ 10

1.5.6. Code Blocks ....................................................................................................................... 11

1.5.6.1. Características ....................................................................................................... 11

1.5.6.2. Soporte de Controladores ..................................................................................... 12

1.5.7. Proceso ............................................................................................................................... 13

1.5.8. Tarea .................................................................................................................................. 13

1.5.9. Requerimientos ................................................................................................................. 14

1.5.10. Requerimientos Funcionales................................................................................. 14

1.5.11. Requerimientos no funcionales............................................................................. 17

1.5.13. Flujograma ........................................................................................................................ 21

1.5.13.1. Características ....................................................................................................... 22

1.5.13.2. Símbolos a utilizar ................................................................................................. 23

1.5.13.3. Elaboración ............................................................................................................ 23

1.5.13.4. Construcción .......................................................................................................... 24

2
2. Análisis de requerimientos. ...................................................................................................... 31
2.1. Observación y/o entrevistas (ficha de observación o instrumentos utilizados). ............ 31

3. Diagramas de diseño. ................................................................................................................ 43

3.1. Diagramas de flujo de datos. ............................................................................................ 43

3.2. Matriz de trazabilidad de actividades. ............................................................................ 44

4. Desarrollo de Software ............................................................................................................. 57

4.1. Especificaciones de estándares de programación ........................................................... 57

4.2. Diseño de Interfaces de Usuario ....................................................................................... 57

5. Conclusiones y Recomendaciones ............................................................................................ 57

6. Bibliografía ................................................................................................................................ 57
7. Anexos ........................................................................................................................................ 58

3
 1. Antecedentes.

1.1. El problema.

En las instituciones educativas de Pichincha para el proceso de matriculación se detectaron

los siguientes problemas: exceso de papeleo esto se lo hace de forma manual verificando en

un gran número de fichas de matriculación, lo que genera pérdida de tiempo y de información

en dicho proceso.

Excesivo tiempo de espera los encargados de cada departamento tienen que llenar los datos

de los estudiantes en fichas, lo cual consume mucho tiempo en el proceso de matriculación,

largas filas, malestar de los representantes de estudiantes y para la institución genera un gasto

excesivo en materiales de oficina.

La institución no cuenta con un proceso eficiente de asignación de aulas a los estudiantes

matriculados, esto causa que los docentes tengan que hacer actividades extracurriculares para

poder establecer el número adecuado a cada paralelo o la creación de nuevos según los

alumnos registrados.

Cuenta con un registro de notas físico de los alumnos obtenidas en el año lectivo el cual al

momento de revisar se complica por la gran cantidad de datos registrados de los distintos

paralelos. En estos consta las notas finales, pases de niveles y promedios obtenidos.

1.2. Objetivos.

1.2.1. Objetivo general.

Desarrollar un sistema de matriculación para las instituciones educativas mediante un

software para mejorar la eficiencia del proceso.

4
 1.2.2. Objetivos específicos.

 Investigar el proceso actual de matriculación para identificar los distintos problemas a

solucionar.

 Identificar los usuarios que intervienen en el proceso.

 Desarrollar un sistema de fácil manejo para los distintos usuarios.

1.3. Justificación.

Con el avance de las tecnologías de la información la institución está consciente que debe

beneficiarse de estos avances para poder hacer el trabajo de forma eficiente, precisa y ágil.

El impacto tecnológico que se da cuando la institución cuando adapta nuevos procesos para el

bien común, ya que la tecnología avanza y necesitamos adaptarnos a ella, con este software

estaremos iniciando un cambio para en un futuro acceder a avances haciendo las cosas más

rápidas y eficaces para las personas.

También vamos a tener un mayor ahorro de papel ya que en tiempos anteriores se utilizaba

material de papel y esto causaba una pérdida económica a la institución.

Todos los usuarios que accedan a este sistema se beneficiaran de los procesos que se realizan

en la institución ya que será más ágil y no tendrán mayor problema en hacer largas filas,

perdida de documentos, etc. Mejorará totalmente el proceso de matriculación de sus

representados.

1.4. Alcance del proyecto.

5
El desarrollo del sistema de matriculación de fácil uso y manipulación, funcionando las 24

horas del día de una forma eficaz y precisa con los datos de los diferentes tipos de actores o

usuarios.

Este sistema cuenta con la respectiva seguridad que permitirá el acceso únicamente al

personal autorizado, los cuales poseerán de un usuario y su respectiva clave para acceder a

este sistema. Además, contará con un sistema de recuperación de clave en caso de ser

olvidada.

6
 1.5. Marco teórico.

1.5.1. Introducción

En este capítulo abordaremos algunos conceptos fundamentales para el desarrollo y

comprensión del presente tema de proyecto. Empezaremos dando un vistazo a los sistemas de

información computarizados, de tal forma de comprender su importancia en nuestra vida

cotidiana, luego de esto se verá algunas características y conceptos de las herramientas

estudiadas y utilizadas para el desarrollo del Sistema de Matriculación, como son el lenguaje

C++, el desarrollador CodeBlocks y la base de datos MySQL con el que interactúa el sistema

para el almacenamiento de datos. Finalmente veremos herramientas para el modelamiento y

diseño del sistema y sus datos.

1.5.2. Sistemas de Información computarizados

Las empresas necesitan tener un grado muy alto de competitividad para poder sobrevivir en el

mundo globalizado actual, y para lograrlo se ven en la necesidad de optimizar sus tareas, de

tal forma que estas se realicen de una forma rápida y efectiva. Si pensamos en el gran

volumen de información que maneja una empresa, la optimización de las tareas no es fácil de

realizar, por lo que se necesitan de sistemas bien diseñados que faciliten dicha labor.

En definitiva, los sistemas de información constituyen una herramienta fundamental para las

organizaciones tanto pequeñas como de mayor envergadura, ya que por medio de los mismos

se pueden receptar, almacenar, procesar, interpretar, y resumir grandes volúmenes de datos,

de tal forma que su manejo se convierta en una tarea más efectiva y segura.

A nivel de instituciones educativas, muchas de ellas se han dado cuenta de la importancia que

el Web tiene en el desarrollo de sus potencialidades, ya que con ello pueden lograr una mejor

comunicación con personas o instituciones situadas en cualquier lugar del mundo. Gracias a

la conexión con la red mundial Internet, poco a poco, cada individuo o institución va teniendo

7
acceso a mayor cantidad de información de las diversas ramas de la ciencia con distintos

formatos de almacenamiento.

La mayor parte de información es presentada de forma estática a través de documentos

HTML, lo cual limita el acceso a los distintos tipos de almacenamiento en que ésta pueda

encontrarse, pero en la actualidad surge la posibilidad de utilizar aplicaciones que permitan

acceder a información de forma dinámica, tal como a bases de datos, con contenidos y

formatos muy diversos.

Una de las ventajas de utilizar el Web para este fin, es que no hay restricciones en el sistema

operativo que se debe usar, permitiendo la conexión entre sí, de las páginas Web desplegadas

en un browser del Web que funciona en una plataforma, con servidores de bases de datos

alojados en otra plataforma. Además, no hay necesidad de cambiar el formato o estructura de

la información dentro de las bases de datos.

1.5.3. Páginas web

Sitio web: Betty del Rosario Medrano Tirado y Maricely Villalba Buelvas, de la Fundación

Universitaria del Área Andina, lo definen de esta manera:

Es un sitio (localización) en la World Wide Web que contiene documentos (páginas web)

organizados jerárquicamente. Cada documento (página web) contiene texto y o gráficos que

aparecen como información digital en la pantalla de un ordenador. Un sitio puede contener

una combinación de gráficos, texto, audio, vídeo, y otros materiales dinámicos o estáticos.

Cada sitio web tiene una página de inicio (en inglés Home Page), que es el primer documento

que ve el usuario cuando entra en el sitio web poniendo el nombre del dominio de ese sitio

web en un navegador. El sitio normalmente tiene otros documentos (páginas web)

adicionales. Cada sitio pertenece y es gestionado por un individuo, una compañía o una

organización.

8
Como medio de comunicación, los sitios web son similares a las películas, a la televisión o a

las revistas, en que también crean y manipulan imágenes digitales y texto, pero un sitio web

es también un medio de comunicación. La diferencia principal entre un sitio web y los

medios tradicionales es que un sitio web está en una red de ordenadores (Internet) y está

codificado de manera que permite que los usuarios interactúen con él.

Los sitios web están escritos en HTML (Hyper Text Markup Language), o dinámicamente

convertidos a éste y se acceden usando un software llamado navegador web, también

conocido como un cliente HTTP. Los sitios web pueden ser visualizados o accedidos desde

un abanico de dispositivos con disponibilidad de Internet como computadoras personales,

computadores portátiles, PDAs y teléfonos móviles.

Un sitio web está alojado en una computadora conocida como servidor web, también llamada

servidor HTTP, y estos términos también pueden referirse al software que se ejecuta en esta

computadora y que recupera y entrega las páginas de un sitio web en respuesta a peticiones

del usuario. Apache es el programa más comúnmente usado como servidor web (según las

estadísticas de Netcraft) y el Internet Information Services (IIS) de Microsoft también se usa

comúnmente.

1.5.4. PHP

PHP: Para el grupo PHP (The PHP Group, 2001) “Es un acrónimo recursivo que significa

PHP HypertextPre- processor (inicialmente PHP Tools, o, Personal Home Page Tools)”.1

“Fue creado originalmente por Rasmus Lerdorf en 1994”8, sin embargo la implementación

principal de PHP es producida ahora por The PHP Group y sirve como el estándar de facto

para PHP al no haber una especificación formal.

Publicado bajo la “PHP License, la Free Software Foundation” 9considera esta licencia como

software libre.

9
El lenguaje PHP fue creado por Rasmus Lerdorf en 1994. Sin embargo al ser desarrollado en

política de código abierto, ha recibido muchas contribuciones de otros desarrolladores. PHP

se encuentra en la versión 4, que utiliza el motor Zend y cuenta con una extensa librería de

funciones de soporte a los programadores.

El código del lenguaje PHP se encuentra embebido en los documentos HTML. PHP puede

interactuar con los principales, y más comunes, gestores de Bases de Datos en servidores

Web. Se considera un lenguaje robusto y potente que está escrito en lenguaje C, con la gran

ventaja que es gratuito y su código fuente, como el LINUX, está a disposición de los

usuarios. PHP como todos los lenguajes creados pensando en Internet, soporta diversidad de

protocolos de comunicaciones entre ellos FTP, HTTP, IMAP, etc.

Una de las grandes virtudes del lenguaje es que su código puede ser ejecutado en diversos

sistemas operativos sin realizarle cambios; soportado por las versiones de Windows 95, 98,

Me, NT, 2000, Unix y Linux. Cuando PHP, se monta en servidores Linux u Unix, es más

rápido que muchos lenguajes como el caso de ASP y también aumenta la seguridad

comparado con ambientes Windows; PHP permite configurar el servidor de modo que puede

hacer al lenguaje más o menos seguro según necesidades específicas.

1.5.5. HTML

HTML: Sergio Luján Mora en su libro Programación en internet. Clientes Web hace

referencia a este término de la siguiente manera.

HyperText Markup Language Lenguaje compuesto de una serie de etiquetas o marcas que

permiten definir el contenido y la apariencia de las páginas web.

Las páginas web o páginas HTML son unos ficheros escritos en el lenguaje HTML. El

desarrollo de estas páginas abarca un amplio grupo de tecnologías, desde las páginas más

10
sencillas que sólo usan el lenguaje HTML hasta las más complejas que usan Dynamic HTML

(DHTML), JavaScript, applets realizados en Java o componentes ActiveX.

El lenguaje HTML se basa en Standard Generalized Markup Language (SGML), un sistema

mucho más completo y complicado de procesamiento de documentos que indica cómo

organizar y marcar (etiquetar) un documento. HTML define e interpreta las etiquetas de

acuerdo a SGML.

Las páginas HTML se pueden diseñar usando texto con distintos tipos de letras o colores,

imágenes, listas de elementos, tablas, etc. Su modo de empleo es muy sencillo: se basa en el

uso de etiquetas que indican que elementos contiene cada página, el formato que hay que

aplicar a cada uno de ellos y como se tienen que distribuir por la página.

1.5.6. Code Blocks

Code Blocks es un entorno de desarrollo integrado libre y multiplataforma para el desarrollo

de programas en lenguaje C y C++. Está basado en la plataforma de interfaces gráficas

WxWidgets, lo cual quiere decir que puede usarse libremente en diversos sistemas

operativos, y está licenciado bajo la Licencia pública general de GNU.

Debido a que Dev-C++ es un IDE para los lenguajes C y C++ y está creado en Delphi, surgió

la idea y necesidad de crear un IDE hecho en los lenguajes adecuados: C y C++. Con esta

motivación se creó Code Blocks.

1.5.6.1. Características

Code Blocks es un IDE construido como un núcleo altamente expansible mediante

complementos (plugins). Actualmente la mayor parte de la funcionalidad viene provista por

los complementos incluidos predeterminadamente. No es un IDE autónomo que acepta

11
complementos, sino que es un núcleo abstracto donde los complementos se convierten en una

parte vital del sistema.

Esto lo convierte en una plataforma muy dinámica y potente, no solo por la facilidad con que

puede incluirse nueva funcionalidad, sino por la capacidad de poder usarla para construir

otras herramientas de desarrollo tan solo añadiendo complementos.

1.5.6.2. Soporte de Controladores

Debido a que en sí Code Blocks es sólo la interfaz del entorno de desarrollo, puede enlazarse

a una variedad de compiladores para poder desarrollar su trabajo. Por defecto, Code Blocks

buscará una serie de compiladores y configurará los que halle.

Algunos de los compiladores compatibles:

Microsoft Visual Studio Toolkit (una extensión de compilador de C++ de Microsoft)

GCC, en sus versiones para Microsoft (ya sea MinGW o Cygwin) y GNU/Linux.

 Borland C++ Compiler

 Digital Mars Compiler

 Intel C++ Compiler

 Open Watcom

 LLVM Clang

Todos estos compiladores pueden ser detectados automáticamente si están ya instalados al

iniciar Code Blocks.

Aunque no es oficialmente compatible (producto de su bajo nivel de adhesión a la norma de

C++), Microsoft Visual Studio 6 puede ser configurado y utilizado, aunque no con muy

buenos resultados.

También es posible añadir compatibilidad con otros compiladores.

12
1.5.7. Proceso

La palabra Proceso presenta origen latino, del vocablo processus, de procedere, que viene de

pro (para adelante) y cere (caer, caminar), lo cual significa progreso, avance, marchar, ir

adelante, ir hacia un fin determinado. Por ende, proceso está definido como la sucesión de

actos o acciones realizados con cierto orden, que se dirigen a un punto o finalidad, así como

también al conjunto de fenómenos activos y organizados en el tiempo. Según el diccionario

de la real academia española esta palabra es definida como la acción de ir hacia adelante, al

transcurso del tiempo, al conjunto de las fases sucesivas de un fenómeno natural o de una

operación artificial. El término proceso está relacionado a varios ámbitos con concepciones

diferentes, tenemos que en las ciencias para la biología, es el nombre dado a la prolongación

de un órgano, una estructura o un tejido que sobresale del resto.

Un proceso educativo es el proceso donde el ser humano aprende a vivir y a ser,

desarrollando sus conocimientos y valores. En la informática, un proceso es una serie de

operaciones lógicas y aritméticas ejecutadas por el computador para gestionar datos

suministrados y obtener resultados determinados.

1.5.8. Tarea

En gestión de proyectos una tarea es una actividad que debe ser completada dentro de un

período de tiempo definido. Una asignación o encargo es una tarea bajo la responsabilidad de

un encargado o assignee, la cual tiene una fecha definida de inicio y finalización. Una o más

asignaciones de una tarea inician la ejecución de la tarea. La terminación de todas las

asignaciones de una tarea específica declara completa la tarea. Las tareas pueden estar

conectadas entre sí para crear dependencias.

En la mayoría de proyectos, las tareas pueden sufrir uno de dos obstáculos principales:

13
Dependencia de tarea, lo cual es normal, ya que la mayoría de las tareas dependen de que se

realicen otras. Sin embargo, esto puede llevar al estancamiento de un proyecto cuando

muchas tareas no pueden iniciar a menos que otras terminen.

Comprensión confusa del término 'completo'. Por ejemplo, si una tarea se completa hasta el

90%, ¿significa que toma terminarla solamente 1/9 del tiempo ya gastado en esta tarea?

Aunque esto es matemáticamente razonable, rara vez sucede en la práctica.

1.5.9. Requerimientos

Requerimiento (sistemas):

Características que se desea que posea un sistema o un software. Requerimiento judicial:

acto judicial en que se pide a alguien que haga o deje de hacer determinada cosa. Ingeniería

de requerimientos: Tareas relacionadas con los requerimientos de un sistema.

1.5.10. Requerimientos Funcionales

Los requerimientos funcionales son declaraciones de los servicios que proveerá el sistema, de

la manera en que éste reaccionará a entradas particulares.

En algunos casos, los requerimientos funcionales de los sistemas también declaran

explícitamente lo que el sistema no debe hacer.

Muchos de los problemas de la ingeniería de software provienen de la imprecisión en la

especificación de requerimientos. Para un desarrollador de sistemas es natural dar

interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación.

Sin embargo, a menudo no es lo que el cliente desea. Se tienen que estipular nuevos

requerimientos y se deben hacer cambios al sistema, retrasando la entrega de éste e

incrementando el costo.

En principio, la especificación de requerimientos funcionales de un sistema debe estar

completa y ser consistente. La compleción significa que todos los servicios solicitados por el

14
usuario están definidos. La consistencia significa que los requerimientos no tienen

definiciones contradictorias.

En la práctica, para sistemas grandes y complejos, es imposible cumplir los requerimientos de

consistencia y compleción. La razón de esto se debe parcialmente a la complejidad inherente

del sistema y parcialmente a que los diferentes puntos de vista tienen necesidades

inconsistentes. Estas inconsistencias son obvias cuando los requerimientos se especifican por

primera vez. Los problemas emergen después de un análisis profundo. Una vez que éstos se

hayan descubierto en las diferentes revisiones o en las fases posteriores del ciclo de vida, se

deben corregir en el documento de requerimientos.

Los requerimientos funcionales de un sistema describen lo que el sistema debe hacer. Estos

requerimientos dependen del tipo de software que se desarrolle, de los posibles usuarios del

software y del enfoque general tomado por la organización al redactar requerimientos.

Cuando se expresan como requerimientos del usuario, habitualmente se describen de una

forma bastante abstracta. Sin embargo, los requerimientos funcionales del sistema describen

con detalle la función de éste, sus entradas y salidas, excepciones, etcétera. Los

requerimientos funcionales para un sistema software se pueden expresar de diferentes formas.

A continuación se presentan algunos ejemplos de estos requerimientos funcionales para un

sistema de biblioteca universitaria, denominada LIBSYS, utilizada por estudiantes y personal

docente que solicitan libros y documentos de otras bibliotecas.

1. El usuario deberá tener la posibilidad de buscar en el conjunto inicial de la base de datos o

seleccionar un subconjunto de ella.

2. El sistema deberá proporcionar visores adecuados para que el usuario lea documentos en el

almacén de documentos.

3. A cada pedido se le deberá asignar un identificador único (ID_PEDIDO), que el usuario

podrá copiar al área de almacenamiento permanente de la cuenta.

15
Estos requerimientos funcionales del usuario definen los recursos específicos que el sistema

debe proporcionar. Dichos requerimientos se toman del documento de requerimientos del

usuario, e ilustran los diferentes niveles de detalle en que se pueden redactar los

requerimientos funcionales (contraste los requerimientos l y 3).

El sistema LIBSYS es una interfaz única para diferentes bases de datos de artículos. Esto

permite a los usuarios descargar copias de artículos publicados en revistas, periódicos y

publicaciones científicas. Una descripción más detallada de los requerimientos para el

sistema en el cual se basa LIBSYS se puede ver en mi libro con Gerald Kotonya sobre

ingeniería de requerimientos (Kontonya y Sommerville, 1998). La impresión en la

especificación de requerimientos es la causa de muchos de los problemas de la ingeniería del

software.

Para un desarrollador de sistema es natural dar interpretaciones de un requerimiento ambiguo

con el fin de simplificar su implementación. Sin embargo, a menudo no es lo que el cliente

desea. Se deben establecer nuevos requerimientos y hacer cambios en el sistema. Por

supuesto, esto retrasa la entrega de éste e incrementa los costes. En principio, la

especificación de requerimientos funcionales de un sistema debe estar completa y ser

consistente.

La completitud significa que todos los servicios solicitados por el usuario deben estar

definidos. La consistencia significa que los requerimientos no deben tener definiciones

contradictorias. En la práctica, para sistemas grandes y complejos, es prácticamente

imposible alcanzar los requerimientos de consistencia y completitud. Una razón de esto es

que es fácil cometer errores y omisiones cuando se redactan especificaciones para sistemas

grandes y complejos.

Otra razón es que losstakeholders del sistema tienen necesidades diferentes, ya menudo

contradictorias. Estas contradicciones pueden no ser obvias cuando los requerimientos se

16
especifican por primera vez, por lo que se incluyen requerimientos contradictorios en la

especificación. Es posible que los problemas surjan solamente después de un análisis más

profundo.

1.5.11. Requerimientos no funcionales

Son aquellos requerimientos que no se refieren directamente a las funciones específicas que

entrega el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta

en el tiempo y la capacidad de almacenamiento. De forma alternativa, definen las

restricciones del sistema como la capacidad de los dispositivos de entrada/salida y la

representación de datos que se utiliza en la interface del sistema.

Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las

restricciones en el presupuesto, a las políticas de la organización, a la necesidad de

interoperabilidad con otros sistemas de software o hardware o a factores externos como los

reglamentos de seguridad, las políticas de privacidad, entre otros.

Estos diferentes tipos de requerimientos se clasifican de acuerdo con sus implicaciones.

• Requerimientos del producto.

Especifican el comportamiento del producto; como los requerimientos de desempeño en la

rapidez de ejecución del sistema y cuánta memoria se requiere; los de fiabilidad que fijan la

tasa de fallas para que el sistema sea aceptable; los de portabilidad y los de usabilidad.

• Requerimientos organizacionales.

Se derivan de las políticas y procedimientos existentes en la organización del cliente y en la

del desarrollador: estándares en los procesos que deben utilizarse; requerimientos de

17
implementación como los lenguajes de programación o el método de diseño a utilizar, y los

requerimientos de entrega que especifican cuándo se entregará el producto y su

documentación.

• Requerimientos externos.

Se derivan de los factores externos al sistema y de su proceso de desarrollo. Incluyen los

requerimientos de interoperabilidad que definen la manera en que el sistema interactúa con

los otros sistemas de la organización; los requerimientos legales que deben seguirse para

asegurar que el sistema opere dentro de la ley, y los requerimientos éticos. Estos últimos son

impuestos al sistema para asegurar que será aceptado por el usuario.

En la práctica, la especificación cuantitativa de requerimientos es difícil. A los clientes no les

es posible traducir sus metas en requerimientos cuantitativos; para algunas de éstas, como las

de mantenimiento, no existen métricas que se puedan utilizar; el costo de verificar de forma

objetiva los requerimientos no funcionales cuantitativos es muy alto.

En principio, los requerimientos funcionales y no funcionales se diferencian en el documento

de requerimientos. En la práctica, esto es difícil. Si un requerimiento no funcional se declara

de forma separada a los funcionales, algunas veces es difícil ver la relación entre ellos. Si se

declaran con los requerimientos funcionales, es difícil separar las condiciones funcionales y

no funcionales e identificar los requerimientos que se refieren al sistema como un todo.

Se debe hallar un balance apropiado que dependa del tipo de sistema a especificar. Sin

embargo, los requerimientos que claramente se refieren a las propiedades emergentes del

sistema se deben resaltar. Esto se hace colocándolos en una sección aparte o

diferenciándolos, de alguna forma, de los otros requerimientos del sistema.

1.5.12. Diagrama de Flujo de Datos (DFD)

18
Un diagrama de flujo de datos o DFD (sus siglas en español e inglés), se utiliza para hacer

varias cosas entre ellas trabajos y tareas. Es una representación gráfica del flujo de datos a

través de un sistema de información. Un diagrama de flujo de datos también se puede utilizar

para la visualización de procesamiento de datos (diseño estructurado). Es una práctica común

para un diseñador dibujar un contexto a nivel de DFD que primero muestra la interacción

entre el sistema y las entidades externas.

Los diagramas de flujo de datos fueron inventados por Larry Constantine, el desarrollador

original del diseño estructurado, basado en el modelo de computación de Martin y Estrin:

"flujo gráfico de datos" . Los diagramas de flujo de datos (DFD) son una de las tres

perspectivas esenciales de Análisis de Sistemas Estructurados y Diseño por Método SSADM.

El patrocinador de un proyecto y los usuarios finales tendrán que ser informados y

consultados en todas las etapas de una evolución del sistema. Con un diagrama de flujo de

datos, los usuarios van a poder visualizar la forma en que el sistema funcione, lo que el

sistema va a lograr, y cómo el sistema se pondrá en práctica. El antiguo sistema de diagramas

de flujo de datos puede ser elaborado y se comparó con el nuevo sistema de diagramas de

flujo para establecer diferencias y mejoras a aplicar para desarrollar un sistema más eficiente.

Los diagramas de flujo de datos pueden ser usados para proporcionar al usuario final una idea

física de cómo resultarán los datos a última instancia, y cómo tienen un efecto sobre la

estructura de todo el sistema. La manera en que cualquier sistema es desarrollado, puede

determinarse a través de un diagrama de flujo de datos.

Los niveles de un DFD son:

Nivel 0: Diagrama de contexto

19
 Nivel 1: Diagrama de nivel superior

Nivel 2: Diagrama de detalle o expansión

1.5.12.1. Conexiones entre los elementos de un DFD

Conexiones permitidas

ENTIDAD - PROCESO

PROCESO - PROCESO

PROCESO - ALMACÉN

Conexiones prohibidas

ENTIDAD - ENTIDAD

ALMACÉN - ALMACÉN

ENTIDAD – ALMACÉN

1.5.12.2. Características de los Niveles de un DFD

 Diagrama de Contexto: Nivel 0

En el diagrama de contexto se caracterizan todas las interacciones que realiza un sistema con

su entorno (entidades externas), estas pueden ser otros sistemas, sectores internos a la

organización, o factores externos a la misma. Se dibuja un sólo proceso que representa al

sistema en cuestión y se escribe su nombre en dicha burbuja como un sustantivo común más

adjetivos. De él solamente parten los flujos de datos que denotan las interrelaciones entre el

sistema y sus agentes externos, no admitiéndose otros procesos ni almacenamientos en el

dibujo, ya que estos son procesos estructurados y ordenados, además posee una cardinalidad

que varia según la función que desempeñe cada diagrama. Resulta de gran utilidad para los

niveles posteriores de análisis como herramienta de balanceo. Y es conocido como el

Diagrama de Flujo de Datos DFD de Nivel "0".

20
  Diagrama de Nivel Superior: Nivel 1

En el diagrama de nivel superior se plasman todos los procesos que describen al proceso

principal. En este nivel los procesos no suelen interrelacionarse directamente, sino que entre

ellos debe existir algún almacenamiento o entidad externa que los una. Esta regla de

construcción sirve como ayuda al analista para contemplar que en un nivel tan elevado de

abstracción (DFD Nivel 1) es altamente probable que la información que se maneja requiera

ser almacenada en el sistema aunque no esté especificado por un Requisito funcional, siendo

en realidad un requisito no-funcional.

 Diagrama de Detalle o Expansión: Nivel 2

En un diagrama de nivel 2 o mayor, comienzan a explotarse las excepciones a los caminos

principales de la información dado que aumenta progresivamente el nivel de detalle. De aquí

en adelante se permiten los flujos entre procesos.

El DFD (Diagrama De Flujo De Datos) nivel 2 puede considerarse el máximo para ser

validado en forma conjunta con el usuario dado que en los niveles posteriores el alto grado de

complejidad del diagrama puede resultar de muy difícil lectura para personas ajenas al equipo

de sistemas. También se recomienda el diagrama de nivel superior.

1.5.13. Flujograma

EL Flujograma o Diagrama de Flujo, consiste en representar gráficamente hechos,

situaciones, movimientos o relaciones de todo tipo, por medio de símbolos.

A continuación se observará de tres autores diferentes el concepto de Flujograma o

Diagramas de Flujo, características, tipos, simbología, diseño y elaboración.

21
Según Gómez Cejas, Guillermo. Año 1.997; El Flujograma o Fluxograma, es un diagrama

que expresa gráficamente las distintas operaciones que componen un procedimiento o parte

de este, estableciendo su secuencia cronológica.

Según su formato o propósito, puede contener información adicional sobre el método de

ejecución de las operaciones, el itinerario de las personas, las formas, la distancia recorrida el

tiempo empleado, etc.

Según Chiavenato Idalberto. Año 1.993; El Flujograma o Diagrama de Flujo, es una gráfica

que representa el flujo o la secuencia de rutinas simples. Tiene la ventaja de indicar la

secuencia del proceso en cuestión, las unidades involucradas y los responsables de su

ejecución.

Según Gómez Rondón Francisco. Año 1.995; El Flujograma o Diagrama de Flujo, es la

representación simbólica o pictórica de un procedimiento administrativo.

1.5.13.1. Características

 De uso, permite facilitar su empleo.

 De destino, permite la correcta identificación de actividades.

 De comprensión e interpretación, permite simplificar su comprensión.

 De interacción, permite el acercamiento y coordinación.

 De simbología, disminuye la complejidad y accesibilidad.

 De diagramación, se elabora con rapidez y no requiere de recursos sofisticados.

22
1.5.13.2. Símbolos a utilizar

1.5.13.3. Elaboración

Este se rige por una serie de símbolos, normas y pautas convencionales las cuales son:

1) El formato o esqueleto del flujograma debe dividirse en partes que representan a los

departamentos, secciones o dependencias involucradas en el procedimiento. Cada

departamento o sección debe mostrarse una sola vez en el flujograma y en el mismo

23
 orden o secuencia cronológica de su aparición en el procedimiento que se describe de

izquierda a derecha.

2) Se debe mostrar una misma dependencia más de una vez en el flujograma aun cuando

las acciones del procedimiento regresen a la misma.

3) Las líneas indicadoras del flujograma deben ser más delgadas que las líneas divisorias

del formato, rectas y angulares, dotadas de flechas en sus extremos terminales.

4) Cada paso o acción del procedimiento debe enumerarse con claridad y describirse

brevemente con muy pocas palabras.

5) Cuando algún documento queda retenido en alguna dependencia del flujograma se

indica según sea archivado: definitivamente, temporalmente o retenido por algunos

días ("D"), horas ("O") o minutos (´)

6) Cuando hay que destruir algún documento luego de ser utilizado en el procedimiento

se indica con una (X) grande.

7) Cuando en el procedimiento algún documento da origen a otro se indicará en el

flujograma mediante una flecha interrumpida.

8) Al igual que vimos en los organigramas en los flujogramas cuando varias líneas se

intercruzan sin tener relación se indica mediante una inflexión en cualquiera de ellas.

Siempre resultará mejor que el flujograma se muestre en una sola hoja, pero cuando en su

extensión se tenga que continuar en otra página, se señala mediante un símbolo cualquiera

dentro de un círculo, en la página donde se interrumpe y el mismo que suele llamarse

conector se colocará en otra página como sigue.

1.5.13.4. Construcción

 Debe de indicar claramente dónde inicia y dónde termina el diagrama.

 Cualquier camino del diagrama debe de llevarte siempre a la terminal de fin.

24
  Organizar los símbolos de tal forma que siga visualmente el flujo de arriba hacia

abajo y de izquierda a derecha.

 No usar lenguaje de programación dentro de los símbolos.

 Centrar el diagrama en la página.

 Las líneas deben ser verticales u horizontales, nunca diagonales.

 No cruzar las líneas de flujo empleando los conectores adecuados sin hacer uso

excesivo de ellos.

 No fraccionar el diagrama con el uso excesivo de conectores.

 Solo debe llegar una sola línea de flujo a un símbolo. Pero pueden llegar muchas

líneas de flujo a otras líneas.

 Las líneas de flujo deben de entrar a un símbolo pro la parte superior y/o izquierda y

salir de él por la parte inferior y/o derecha.

 Evitar que el diagrama sobrepase una página; de no ser posible, enumerar y emplear

los conectores correspondientes.

 Usar lógica positiva, es decir, realizar procesos cuando es verdadera la condición y

expresar las condiciones de manera clara (por ej., "no es a =/= de b" ==> "a=b").

 Comentar al margen únicamente cuando sea necesario.

1.5.14. Casos de Uso

Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para

llevar a cabo algún proceso. Los personajes o entidades que participarán en un caso de uso se

denominan actores. En el contexto de ingeniería del software, un caso de uso es una

secuencia de interacciones que se desarrollarán entre un sistema y sus actores en respuesta a

un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de

uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su

interacción con los usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la

25
relación entre los actores y los casos de uso en un sistema. Una relación es una conexión

entre los elementos del modelo, por ejemplo la especialización y la generalización son

relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requisitos del sistema al

mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.

Su uso es común para la captura de requisitos funcionales, especialmente con el paradigma de

la programación orientada a objetos, donde se originaron, si bien puede utilizarse con

resultados igualmente satisfactorios con otros paradigmas de programación.

1.5.14.1. Definición Actor

Se le llama actor a toda entidad externa al sistema que guarda una relación con éste y que le

demanda una funcionalidad. Esto incluye a los operadores humanos pero también incluye a

todos los sistemas externos, además de entidades abstractas, como el tiempo.

En el caso de los seres humanos se pueden ver a los actores como definiciones de rol por lo

que un mismo individuo puede corresponder a uno o más Actores. Suele suceder sin

embargo, que es el sistema quien va a tener interés en el tiempo. Es frecuente encontrar que

nuestros sistemas deben efectuar operaciones automáticas en determinados momentos; y

siendo esto un requisito funcional obvio, resulta de interés desarrollar alguna forma de

capturar dicho requisito en el modelo de caso de uso final.

1.5.14.2. Tipos de Relaciones

 Comunica (<<communicates>>): Relación (asociación) entre un actor y un caso de

uso que denota la participación del actor en dicho caso de uso.

 Usa (<<uses>>) (o <<include>> en la nueva versión de UML): Relación de

dependencia entre dos casos de uso que denota la inclusión del comportamiento de un

escenario en otro.

26
  Extiende (<<extends>>): Relación de dependencia entre dos casos de uso que denota

que un caso de uso es una especialización de otro. Por ejemplo, podría tenerse un caso

de uso que extienda la forma de pedir azúcar, para que permita escoger el tipo de

azúcar (normal, dietético o moreno) y además la cantidad en las unidades adecuadas

(cucharadas o bolsas).

Se utiliza una relación de tipo <<extends>> entre casos de uso cuando nos encontramos con

un caso de uso similar a otro pero que hace algo más que éste (variante). Por contra,

utilizaremos una relación tipo <<uses>> cuando nos encontramos con una parte de

comportamiento similar en dos casos de uso y no queremos repetir la descripción de dicho

comportamiento común.

En una relación <<extends>>, un actor que lleve a cabo el caso de uso base puede realizar o

no sus extensiones. Mientras, en una relación <<include>> el actor que realiza el caso de uso

base también realiza el caso de uso incluido.

En general utilizaremos <<extends>> cuando se presenta una variación del comportamiento

normal, e <<include>> cuando se repite un comportamiento en dos casos de uso y queremos

evitar dicha repetición.

Por último en un diagrama de casos de uso, además de las relaciones entre casos de uso y

actor (asociaciones) y las dependencias entre casos de uso (<<include>> y <<extends>>),

pueden existir relaciones de herencia ya sea entre casos de uso o entre actores.

27
Llamamos modelo de casos de uso a la combinación de casos de uso y sus correspondientes

diagramas. Los modelos de casos de uso se suelen acompañar por un glosario que describe la

terminología utilizada. El glosario y el modelo de casos de uso son importantes puntos de

partida para el desarrollo de los diagramas de clases.

Por último se debe tener en cuenta, que aunque cada caso de uso puede llevar a diferentes

realizaciones, es importante reflejar en cada representación el motivo que nos ha llevado a

descartarla, si es el caso.

1.5.14.3. Normas de Aplicación

Los casos de uso evitan típicamente el lenguaje técnico, prefiriendo la lengua del usuario

final o del experto del campo del saber al que se va a aplicar. Los casos del uso son a menudo

elaborados en colaboración por los analistas de requisitos y los clientes.

Cada caso de uso se centra en describir cómo alcanzar una única meta o tarea. Desde una

perspectiva tradicional de la ingeniería de software, un caso de uso describe una característica

del sistema. Para la mayoría de proyectos de software, esto significa que quizás a veces es

necesario especificar decenas o centenares de casos de uso para definir completamente el

nuevo sistema. El grado de la formalidad de un proyecto particular del software y de la etapa

del proyecto influenciará el nivel del detalle requerido en cada caso de uso.

Los casos de uso pretenden ser herramientas simples para describir el comportamiento del

software o de los sistemas. Un caso de uso contiene una descripción textual de todas las

maneras que los actores previstos podrían trabajar con el software o el sistema. Los casos de

uso no describen ninguna funcionalidad interna (oculta al exterior) del sistema, ni explican

28
cómo se implementará. Simplemente muestran los pasos que el actor sigue para realizar una

operación.

Un caso de uso debe:

 Describir una tarea del negocio que sirva a una meta de negocio.

 Tener un nivel apropiado del detalle.

 Ser bastante sencillo como que un desarrollador lo elabore en un único lanzamiento.

Situaciones que pueden darse:

 Un actor se comunica con un caso de uso (si se trata de un actor primario la

comunicación la iniciará el actor, en cambio si es secundario, el sistema será el que

inicie la comunicación).

 Un caso de uso extiende otro caso de uso.

 Un caso de uso utiliza otro caso de uso.

1.5.14.4. Ventajas

La técnica de caso de uso tiene éxito en sistemas interactivos, ya que expresa la intención que

tiene el actor (su usuario) al hacer uso del sistema.

Como técnica de extracción de requisito permite que el analista se centre en las necesidades

del usuario, qué espera éste lograr al utilizar el sistema, evitando que la gente especializada

en informática dirija la funcionalidad del nuevo sistema basándose solamente en criterios

tecnológicos.

29
A su vez, durante la extracción (elicitation en inglés), el analista se concentra en las tareas

centrales del usuario describiendo por lo tanto los casos de uso que mayor valor aportan al

negocio. Esto facilita luego la priorización del requisito.

Aunque comúnmente se asocian a la fase de Test de una aplicación, esta idea es errónea, y su

uso se extiende mayormente a las primeras fases de un desarrollo.

1.5.14.5. Limitaciones

Los casos de uso pueden ser útiles para establecer requisitos de comportamiento, pero no

establecen completamente los requisitos funcionales ni permiten determinar los requisitos no

funcionales. Los casos de uso deben complementarse con información adicional como reglas

de negocio, requisitos no funcionales, diccionario de datos que complementen los requisitos

del sistema. Sin embargo, la ingeniería del funcionamiento especifica que cada caso crítico

del uso debe tener un requisito no funcional centrado en el funcionamiento asociado.

30
2. Análisis de requerimientos.

2.1. Observación y/o entrevistas (ficha de observación o instrumentos utilizados).

Ficha de requerimientos.

1. Cuáles son los procedimientos que se realizan dentro de la institución?

2. ¿Cuántos empleados intervienen en los procesos generales de la institución

3. ¿Cuáles son los procedimientos que se realizan dentro de la institución?

4. ¿Cuántos empleados intervienen en los procesos generales de la institución?

5. ¿Qué tipo de información puede ser ingresada?

6. ¿Cuántos niveles deberá existir en el programa?

7. ¿Qué información no puede ser cambiada?

8. ¿Qué tipo de sistema operativo se maneja en la institución?

9. ¿En qué dispositivos además de computadoras puede existir acceso al sistema?

10. ¿Cuántos alumnos pueden ser ingresados en el sistema por aula?

2.2. Perfil de Usuarios

Este sistema estará basado en el uso de la secretaría del establecimiento a aplicar, lo cual,

facilitará la rapidez en el manejo de datos acerca de los estudiantes nuevos y antiguos de

dicha institución.

Este sistema usará internet, lo cual facilitará al estudiante acceder a sus datos sin necesidad de

acercarse a la institución para la verificación de los mismos.

31
2.3. Matriz de Requerimientos

MATRIZ DE REQUERIMIENTOS

Identificador Descripción Fuente Prioridad Tipo Estado Usuarios

Involucrados

REQUERIMIENTOS FUNCIONALES

ESCU01 Registro Secretaría Ingreso de Funcional Revisión Área de

como de la personal secretaría,

usuarios de la Institución Dirección

institución General

ESCU02 Inscripción de Secretaría Registro de Funcional Revisión Área de

Usuario y de la los Usuarios secretaría,

Contraseña Institución pertenecientes Dirección

del nuevo a la General

estudiante Institución

ESCU03 Recuperación Secretaría Recuperación Funcional Revisión Área de

de Usuario y de la de usuario y secretaría,

contraseña Institución contraseña vie Dirección

almacenados e-mail General

en el sistema

ESCU04 Verificación Secretaría Ingreso Funcional Revisión Área de

de Usuario y de la mediante secretaría,

su función en Institución usuario para Dirección

el sistema determinar a General

qué va a tener

acceso

32
ESCU05 Registro de Secretaría El estudiante Funcional Revisión Área de

datos, de la registrará el secretaría,

módulos, Institución módulo y Dirección

horarios horario que General

asignados escoja para

asignar una

aula

ESCU07 Actualización Secretaría Los usuarios Funcional Revisión Área de

de datos cada de la de la secretaría,

cierto tiempo Institución Institución Dirección

deberán General

actualizar su

información

personal con

datos reales

ESCU08 Ingreso de Secretaría Los usuarios Funcional Revisión Área de

usuarios que de la no secretaría,

no pertenecen Institución pertenecientes Dirección

a la a la institución General

institución podrán

acceder como

“invitados”

REQUERIMIENTOS NO FUNCIONALES

ESCU06 Ingreso de Dispositivo La aplicación Funcional Revisión Lugar donde

usuarios a la Móvil de permitirá acceda

institución cada acceder al mediante

mediante usuario sistema y conexión a

33
aplicativo poder revisar internet en

móvil daos sin un

necesidad de dispositivo

estar en la móvil

institución

34
2.4. Especificación de Requerimientos

N° 1

N°. Requerimiento Nombre Fecha

El sistema deberá

permitir el ingreso a

los diferentes

ESCU01 usuarios que deseen Primario

registrarse como

usuarios de la

Institución.

Entradas Procesos Restricciones Mensajes

El ingreso será para

Para que el usuario
cualquier otro
pueda ingresar al
usuario pero solo se
Ingresar como sistema deberá ir al
registrara si los Ingreso para
participante de la inicio de la página
parámetros después empleados.
Institución de sistema e ingresar
mencionados
al portal de
constan en la base de
empleados.
datos de la empresa.

35
 N°2

N°. Requerimiento Nombre Fecha

El sistema deberá

permitir el registro

de los diferentes
ESCU02 Primario
usuarios que

pertenecen a la

Institución.

Entradas Procesos Restricciones Mensajes

Nombres

Apellidos
Verificación de C.I.
C.I.
Verificación
Números
Para que el usuario mediante un correo Los datos no
telefónicos.
pueda registrarse enviado a su cuenta. coinciden con
Numero celular.
deberá coincidir su Las letras deberán ningún usuario
Dirección.
información con la ser solo en registrado.
Correo.
base de datos de la minúsculas. El registro ha sido
Clave de correo.
empresa. No debe existir completado.
Ocupación en la
caracteres especiales
Institución.
excepto en el correo.

36
 N°3

N°. Requerimiento Nombre Fecha

El sistema deberá

asignar un usuario y

ESCU03 clave de acceso al Primario

sistema para cada

empleado registrado.

Entradas Procesos Restricciones Mensajes

Para que el usuario

El correo y la clave
pueda obtener su
debe ser el mismo
clave y usuario Su usuario y clave
Correo. ingresado en el
deberá acceder a su son *******y
Clave del correo. proceso de registro.
correo para la *******

verificación del

proceso de registro.

37
 N°4

N°. Requerimiento Nombre Fecha

El sistema deberá

dividir en módulos

de ingreso para las

ESCU04 Primario
diferentes categorías

de la Institución.

Entradas Procesos Restricciones Mensajes

Verificar el usuario y Nombre de usuario o

Para que el usuario contraseña que contraseña

pueda ingresar a su ingrese el empleado incorrectos o no

Nombre de Usuario módulo respectivo y asignar su registrados.

Contraseña deberá ingresar su respectivo módulo Mostar el cargo que

nombre de usuario y de categoría en la tiene en Institución y

contraseña. empresa. a lo que tiene acceso.

38
 N°5

N°. Requerimiento Nombre Fecha

ESCU05 El sistema deberá Primario

permitir el ingreso

de datos de

productos para

conocer lo que existe

en la Institución.

Entradas Procesos Restricciones Mensajes

Nombre de Para que el usuario Verificar el usuario y Usuario o clave

Usuario(debe ser pueda ingresar la contraseña que incorrectos.

parte de la categoría información de los ingrese el usuario y El registró de todos

de Secretaria o estudiantes deberá constar pertenece a los estudiantes

Dirección) ingresar a su módulo la categoría de inscritos o por

Contraseña e ingresar en registro Dirección o matricularse.

estudiantil. Secretaria.

Registrar la El registró de los

matricula en caso de estudiantes inscritos

ser nuevos. o por matricularse.

39
 N°6

N°. Requerimiento Nombre Fecha

El sistema deberá

permitir el ingreso a

los diferentes

usuarios que

ESCU06 pertenecen en la Primario

Institución por

medio de una App

en sus dispositivos

móviles.

Entradas Procesos Restricciones Mensajes

Para que el usuario

pueda ingresar al

sistema deberá

ingresar su usuario

Nombre de Usuario asignado, clave de

Contraseña acceso y su número

Numero celular celular.

Podrá visualizar el

contenido de la

Institución y acceso

a su área permitida.

40
 N°7

N°. Requerimiento Nombre Fecha

El sistema deberá

permitir que el
ESCU07 Primario
usuario actualice sus

datos si es necesario

Entradas Procesos Restricciones Mensajes

Para que el usuario

pueda actualizar sus

datos deberá ingresar

Los datos ingresados
a su módulo y
Nombre de Usuario deben cumplir con Sus datos han sido
dirigirse a cuenta y
Contraseña los parámetros de actualizados.
actualización de
caracteres
datos.
permitidos.
Deberá ingresar los

nuevos datos y hacer

clic en actualizar.

41
 N°8

N°. Requerimiento Nombre Fecha

El sistema deberá

permitir el ingreso a

ESCU08 usuarios no Primario

pertenecientes a la

Institución.

Entradas Procesos Restricciones Mensajes

La información que Ha ingresado datos

Para que el usuario
sea permitida ser sobre estudiantes
tiene que ingresar el
vista por otros antiguos.
número determinado
usuarios deberá ser Ha ingresado datos
Registro de docentes de estudiantes que
solo de carácter sobre estudiantes
y matriculados. han sido aprobados
básico sobre la matriculados.
el año y los que se
Institución y su Conozca más sobre
hayan matriculado
alumnado. nosotros.

42
3. Diagramas de diseño.
3.1. Diagramas de flujo de datos.
Nivel 0

Banco Senescyt

Confirmación Notas Lista de

Envía Listado De Listados Obtenidas Alumnos
de Alumnos

Confirmación de Datos
Envía Listado de Alumnos
Sistema Proceso de Matriculación Secretaria
Ministerio de
Educacion Confirma Listados Almacena los Datos

Recibe Envía Recibe Envía

Datos Datos Datos Datos

Envía
Matriculacion Información Admisión
Personal

Estudiante

43
Nivel 1

Banco Senescyt

Inscripción

Envía Información Personal

Correo de Confirmación

Notificación de Correo de Aprobación Pagos Pago de

Aprobación Aranceles
Envía Notas
Confirmar el Correo Recibo de Pagos
Admisión

Listado de Envía la Selección

Entrega de Evaluación
Alumnos De Alumnos

Recibe Evaluaciones
Selección Academicas Evaluación
de Alumnos Académica
Acudir a Rendir la
Evaluación en el Lugar Asignado

Envía Datos Infamativos

Información de Admisión
Sistema Proceso
de Matriculación Información De Matriculación

Estudiante
Envía Datos Informativos

Recibe el Carnet Estudiantil Pagos Varios Pago de

Carneticacion Matriculacion Aranceles
Recibos de Pagos
Presentar Documentacion
Listas de
Confirma
Alumnos

Llena los Parámetros Recibe

Solicitados Información

Matricula

Ministerio de
Educacion

3.2. Matriz de trazabilidad de actividades.

44
ADMISIÓN
INSCRIPCIÓN

INICIO

Prender el computador

Inscripción en línea

Entra en el sitio web de la institución y buscar

proceso de inscripción

Llenamos el registro y
procedemos a la inscripción

No Si
Revisión

Llenamos y aceptamos el
formulario de inscripción

Recibimos correo de
confirmación y pago de
arancel

FIN

45
PAGO DE ARANCELES

INICIO

Acudimos a un establecimiento bancario

Hacemos fila y nos dirigimos a una ventanilla

Solicitamos el servicio necesitado

Realizamos el pago del arancel

Retiramos el Boucher de
comprobación de pago

Salimos del establecimiento bancario

FIN

46
EVALUACIÓN ACADÉMICA

INICIO

Nos dirigimos al establecimiento de la institución

Ingresamos al establecimiento

Acudimos al curso seleccionado para la prueba

Recibimos las instrucciones para evaluación

Llenamos la evaluación

Entregamos la evaluación

Salimos del establecimiento

Esperar correo de aprobación

FIN

47
SELECCIÓN DE ALUMNOS

INICIO

El sistema recibe las pruebas rendidas

Califica cada una de las pruebas

Realiza un conteo de aciertos

No Si
Da un resultado y
selecciona las
mejores notas
Reprobado Aprobado

Se seleccionan a los aspirantes

FIN

48
 NOTIFICACION DE APROBACIÓN

INICIO

Se envía un correo de aprobación

Abrimos el correo de resultado

Leemos toda la información

No Si
Aceptamos el
cupo asignado

Rechazo del cupo

asignado Ingresamos al siguiente proceso

FIN

49
MATRICULACIÓN
PAGO DE ARANCEL

INICIO

Acudimos a un establecimiento bancario

Ingresamos al banco

Hacemos fila y nos dirigimos a una ventanilla

Solicitamos el servicio necesitado

Realizamos el pago del arancel

Recibimos el Boucher de
comprobación de pago

Salimos del establecimiento

Realizamos el próximo proceso

FIN

50
MATRICULA

INICIO

Mediante un cronograma nos matriculamos

En el computador ingresamos a la página del instituto

Hacemos clic en el enlace de matriculación

Seleccionamos el curso al que asistiremos

Aceptamos los
parámetros
establecidos
Imprimimos los papeles
solicitados

Realizamos el próximo proceso

FIN

51
CARNETIZACIÓN

INICIO

Ingresar al área de Carnetización

Recibir un turno de atención

Presentar documentos para

Carnetización

Ubicarse en sitio para fotografía

Legalizar documento de Carnetización

Recibir Carnet estudiantil

Salir del sitio de Carnetización

FIN

52
3.3. Diagramas de Casos de Uso

Evaluación académica

Aspirante
Acudir a las instalaciones del
ITSCO
Recibir
Confirmar la aprobación para el indicaciones
examen

Acudir al examen

Analizar y responder las preguntas

Verificar el
tiempo

Finalizar examenes

53
Selección de alumnos

Aspirante

Recibir evaluación del aspirante

Calificar las pruebas

Obtener notas de los exámenes

Verificar
promedio
Verificar notas para la aprobación
minimo

Listado de
Seleccionar aspirantes
aprobados

54
Inscripción

Aspirante Sistema ITSCO

Ingresar al sitio wed ITSCO

Nos dirigimos a la opción

inscripción

Llenamos los datos solicitados

Verificamos los datos

Guardamos la información y
enviamos el formulario
Revisamos el correo de
confirmación

55
Pago de aranceles

Aspirante Banco

Acudir al banco

Acercarse a la ventanilla

Indicar el tramite a realisarse

Entregar el deposito Verificar monto

Confirmar el deposito Imprimir recibo

Retirar el recibo

56
4. Desarrollo de Software

4.1. Especificaciones de estándares de programación

4.2. Diseño de Interfaces de Usuario

5. Conclusiones y Recomendaciones

6. Bibliografía

http://www.informaticamilenium.com.mx/es/temas/que-son-los-sitios-web.html

https://es.wikipedia.org/wiki/Code::Blocks

https://es.wikipedia.org/wiki/C%2B%2B

https://es.wikipedia.org/wiki/Tarea_(gesti%C3%B3n_de_proyectos)

http://conceptodefinicion.de/proceso/

http://www.hipertexto.info/documentos/html.htm

http://php.net/manual/es/intro-whatis.php

http://searchdatacenter.techtarget.com/es/definicion/Servidor-Web

https://es.wikipedia.org/wiki/MySQL

https://sites.google.com/site/metodologiareq/capitulo-ii/tecnicas-para-identificar-requisitos-

funcionales-y-no-funcionales

https://es.scribd.com/doc/37187866/Requerimientos-funcionales-y-no-funcionales

http://www.monografias.com/trabajos53/diagrama-de-flujo/diagrama-de-flujo.shtml

http://www.monografias.com/trabajos53/diagrama-de-flujo/diagrama-de-flujo2.shtml

http://www.monografias.com/cgi-bin/search.cgi?query=flujograma

http://www.monografias.com/trabajos14/flujograma/flujograma.shtml

https://es.wikipedia.org/wiki/Diagrama_de_flujo_de_datos

https://es.wikipedia.org/wiki/Caso_de_uso

57
7. Anexos

Ilustración 1 - Páginas web

Ilustración 3 – php

Ilustración 4 - Logo HTML

58
Ilustración 5 - Ejemplo Código HTML

Ilustración 6 - Logo CodeBlocks

Ilustración 7 - Interfaz CodeBlocks

59
 Ilustración 8 - Ejemplo flujograma

Ilustración 9 - Ejemplo de Conectores en Flujograma

60
Ilustración 10 - Uso incorrecto de conectores

61