Plan de Desarrollo Final

UNIVERSIDAD AUTONOMA
GABRIEL RENE MORENO

FACULTAD INTEGRAL DEL NORTE “FINOR”
CARRERA INGENIERIA EN SISTEMAS
SOFTWARE WEB PARA GESTIONAR EL PAGO DE MENSUALIDADES

E INSCRIPCION DE ALUMNOS DE LA UNIDAD EDUCATIVA
“FE Y ALEGRIA -VIRGEN DE COTOCA ”
PRESENTADO POR: CARLOS EDUARDO FERNANDEZ PARADA
SAUL VILLARROEL ROJAS
ERWIN ELIAS BONIFACIO
SANTA CRUZ-MONTERO-BOLIVIA
0|Página
NUMERO SECCION Y/O DESCRIPCION DE LA FECHA DE
DE PAGINA MODIFICACION ENTREGA
REVISION
1 Todo el Versión inicial
documento
Control de Emisión
ELABORADO POR: REVISO APROBO
Carlos Eduardo Fernández Ing. José Alfredo Álvarez Ing. José Alfredo Álvarez Vega.
Parada Vega.
Saúl Villarroel Rojas
1|Página
TABLA DE CONTENIDO
1. INTRODUCCIÓN 4
1.1. ANTECEDENTES 4
1.2. DEFINICIÓN DEL PROBLEMA 6
1.3. SITUACIÓN PROBLEMÁTICA 6
2. VISTA GENERAL DEL PROYECTO 6
2.1. OBJETIVO GENERAL 6

2.2. OBJETIVOS ESPECÍFICOS 6
2.3. ALCANCE 7
2.3.1. REQUERIMIENTOS FUNCIONALES 7
2.3.2. REQUERIMIENTOS NO FUNCIONALES 9
2.3.3. SUPOSICIONES Y RESTRICCIONES 9
2.3.4. EXPECTATIVAS DE CALIDAD 10
2.4. FUNDAMENTOS DE LA METODOLOGÍA 10
2.4.1. MODELO DE PROCESO 11
2.4.2. ENTREGABLES 16
2.4.3. HITOS PRINCIPALES 16
2.4.4. PROCESOS DE DESARROLLO 16
3. ORGANIZACIÓN DEL PROYECTO 17
3.1. ORGANIZACIÓN INTERNA 18

3.2. ROLES Y RESPONSABILIDADES 19
4. PROCESO TECNICO 19
4.1. MÉTODOS HERRAMIENTAS Y TÉCNICAS 21

4.2. DOCUMENTACIÓN DEL PRODUCTO 22
5. ANALISIS DE REQUERIMIENTO 27
5.1. DOMINIO DE LA APLICACIÓN 28

5.2. IDENTIFICACIÓN DE ACTORES Y CASOS DE USOS 35
5.2.1. ACTORES 36
5.2.2. CASOS DE USOS 36
5.3. SUBSISTEMAS IDENTIFICADOS 51
VISTA DE CADA PAQUETE 52
2|Página
5.3.1. ARQUITECTURA DE DESPLIEGUE 56
5.3.2. TIPO DE APLICACIÓN 56
5.3.3. TIPO DE CONEXIÓN 57
6. ESTIMACION DE RECURSOS 57
6.1. MÉTRICAS 57
6.1.1. ORIENTADAS AL TAMAÑO (MOT1) 57
6.2. ESTIMACIONES 60
6.2.1. MODELO COCOMO 61
6.2.2. ANÁLISIS DE LAS ESTIMACIONES 61
7. ANALISIS Y MANEJO DE RIESGOS 63
7.1. VALORACIÓN 64
7.2. PLAN DE AVERSIÓN 68
8. GESTION DEL PROCESO 69
8.1. RECURSOS 69
8.1.1. RECURSOS HUMANOS 69
8.2. ESTIMACIONES DEL PROYECTO 70
8.2.1. ANÁLISIS DE COSTOS 70
3|Página
1. INTRODUCCIÓN
1.1. Antecedentes
Fe y Alegría es un Movimiento de Educación Popular y Promoción Social. Nació en un barrio

pobre de Caracas, Venezuela, en 1955, como respuesta a la situación de marginación y la
falta de oportunidades de educación de los pobladores de este lugar. Su fundador es el
sacerdote jesuita José María Vélaz.
Su llegada a Bolivia fue el 9 de mayo de 1966, se pusieron en marcha a la vez 7 unidades

educativas en La Paz (Copacabana y Corazón de Jesús), Santa Cruz (La Merced),
Cochabamba (El Salvador), Oruro (Virgen del Mar), Potosí (Fray Vicente Bernedo) y
Chuquisaca (Milagrosa Loyola). El primer Director Nacional fue Humberto Portocarrero.
Fue el 4 de febrero de 1971 cuando se funda en la Ciudad de Montero, comienzan las primeras
clases en el colegio que había sido creado con el nombre de HOLI CROSS con la nueva
orientación de la congregación de las hijas de Jesús quienes se isieron cargo de esta
Institución educativa bajo el nuevo nombre de Fe y Alegría “Virgen de Cotoca” que hoy en
día se sigue conservando. La primera directora fue la hermana Remedios García quien con
todo esmero dirigió a los ciclos Básicos e Intermedio con un total de 493 alumnos. En el año
1972 comenzó a funcionar el primer curso del ciclo medio bajo la dirección de la hermana
Maria Otaegui con un total de 28 alumnos. Prácticamente desde un inicio además del
bachillerato humanístico obtienen el certificado y también el título en Secretariado
Administrativo Comercial.
Actualmente la U.E. cuenta con todos los ciclos del nivel primario y secundario, con un total
de 1548 alumnos, 68 maestros (a), 7 administrativos y 3 directores. Fe y Alegría “Virgen de
Cotoca” funciona en dos turnos mañana y tarde; Bajo la dirección general de la hermana
Hung Hi Chai quien representa a la congregación de las Hijas de Jesús en Montero.
Lleva el nombre de Virgen de Cotoca cuando los padres Marknoll entregaron el colegio a la
Iglesia, el obispo de Santa Cruz Mons. Luis Rodríguez escribió una carta a la madre general
de la congregación Hijas de Jesús de que la Virgen de Cotoca si podía interceder para obtener
una respuesta positiva paso la carta y debajo la imagen de la virgen.
Al obtener una respuesta satisfactoria, el Obispo puso el nombre de “Virgen de Cotoca” en
agradecimiento a la patrona.
4|Página
Ubicación:
Departamento: Santa Cruz
Provincia: Obispo Santisteban
Ciudad: Montero
Barrio: Bolívar
5|Página
1.2. Definición del problema
-La unidad educativa “Fe y Alegría Virgen de Cotoca” no cuenta con un software de registros
de inscripción y control de notas propias para su propio colegio.
-La unidad educativa no posee conocimientos sobre los beneficios que les puede generar el
poseer un software que gestiones sus datos escolares.
-La unidad educativa no puede brindarnos información inmediata de los rankings

académicos, es decir no tiene eficiencia al determinar a los mejores alumnos en cuestión de
minutos, tampoco puede sacar estadísticas de conocimientos. A ello nos referimos con no se
puede determinar de forma general que estudiantes en que materia tienen más dificultad y de
esa manera poder implementar un nuevo método.
-La unidad educativa no cuenta con un registro digital por el pago de mensualidades de los
estudiantes.
1.3. Situación problemática

La Unidad Educativa no cuenta con un Software que controle los pagos de mensualidad,
módulos de inscripción ni notas. Además, existen mucho retardo en la elaboración de
informes y reportes esto ocasionando que la inscripción, control y supervisión no sean
efectivas al momento de requerir información.
2. VISTA GENERAL DEL PROYECTO
2.1. Objetivo General

Desarrollar un software para gestionar el pago de mensualidades e inscripción de la Unidad
Educativa Fe y Alegría “Virgen de Cotoca”.
2.2. Objetivos específicos

-Recolectar información de la unidad educativa Fe y Alegría mediante las entrevistas a las
personas adecuadas.
-Analizar la información de inscripción al colegio, registro y control de notas que será
manipulado por el sistema.
-Diseñar el diagrama de clases mediante el Lenguaje Unificado de Modelado (UML).
-Implementar la base de datos utilizando el Sistema de Gestor de Base de Datos MySQL
-Implementar la interfaz del software de acuerdo a los requerimientos de la empresa
utilizando HTML, PHP, etc incluidos en el Framework Laravel 7.30.
-Investigar sobre productos de software con objetivos similares para que puedan ser usados
en el cálculo de las estimaciones.
-Definir el alcance, requerimientos y restricciones del software para la gestión de inscripción
y control de notas.
-Desarrollar el software bajo criterios convenidos con el cliente, documentando cada fase del
proyecto y sus artefactos resultantes.
6|Página
2.3. Alcance
Nuestro software estará enfocado en las áreas de pago de mensualidades e inscripción de
los alumnos a sus respectivos cursos, paralelos, etc. De la Unidad Educativa Fe y Alegría
“Virgen de Cotoca” y también el control de notas.
2.3.1.Requerimientos Funcionales
Nro. NOMBRE DEL COMO PROBARLO DEPARTAMENTO

REQUERIMIENTO SECCION
RF 01 Administrar Gestión Registrar los datos de la Académica
Gestión Académica.
RF 02 Gestionar Loguin Gestionar a los Usuarios que Académica
estén usando el sistema en
tiempo real
RF 03 Administrar Curso Registrar, Modificar, Eliminar Académica
(eliminación lógica) Cursos.
RF 04 Gestionar Materias Gestionar la materia según el Académica

curso correspondiente.
RF 05 Verificar Cupo Verificar el cupo Académica

solicitado por el
postulante
RF 06 Gestionar Profesor es saber quiénes son los
docentes que están presentes
durante toda la gestión
académica actual
RF 07 Inscribir Alumnos Registrar la inscripción de los Académica
postulantes (alumnos nuevos)
en caso de haber presentado
todos los requisitos de forma
correcta y de alumnos
antiguos registrarlos en una
nueva gestión.
RF 08 Gestionar Nota Registrar, modificar las notas Académica
bimestrales que se asignan a
cada alumno de las materias
que lleva.
RF 09 Generar Boletín Genera un boletín para un Académica

alumno correspondiente, que
es un medio que informa el
7|Página
rendimiento académico que
obtuvo en sus materias.
RF 10 Visualizar Boletín Académica
RF 11 Gestionar Apoderado Esta opción permite Académica

introducir los datos de
la nueva persona
apoderada rellenando
las siguientes casillas:
Nombres
Carnet
Identidad
Teléfono
Parentesco
RF 12 Administrar Alumno Registra, Modifica y en Académica

algunos casos elimina datos
de un alumno dentro del
sistema
RF 13 Gestionar Administrativo Registrar los datos del Académica
administrativo
Nro. NOMBRE DEL COMO PROBARLO DEPARTAMENTO

REQUERIMIENTO SECCION
Req01 Registrar Gestión El sistema permitirá registrar Administración
gestión con fecha de inicio y
fecha fin
Req02 Registrar Alumno El Alumno podrá ser Administración
registrado con todos sus datos
personales
Req03 Registrar Docente El docente podrá ser Administración
registrado con sus datos
personales y su especialidad
Req04 Registrar Secretaria La secretaria podrá registrarse Administración
con sus datos,
Req05 Registrar Materias El sistema permitirá registrar Administración

materia, buscar los datos de la
materia que se inscribieron
Req06 Gestionar Horario El sistema generara un Administración
horario de acuerdo a la
materia que se inscribió y al
turno.
Req07 Gestionar Notas El sistema gestionara las Administrador-
notas de los alumnos de Docente
8|Página
acuerdo a la materia y el
curso el que se encuentren
inscritos
Req08 Gestionar Pago Mensualidad El sistema gestionara los pago Administración
de mensualidades de los
alumnos que estén llevando
algún curso,
Req09 Registrar Factura El sistema podrá registrar las Administración
facturas por el pago de
mensualidad.
2.3.2.Requerimientos no Funcionales
1- Funcionalidad: el software debe ser seguro, es decir se le asignara una contraseña para el
uso exclusivo del usuario específico.
2- Usabilidad: el software de ser entendible, fácil de usar y aprender, las interfaces deben ser
claras y precisas.
3- Mantenibilidad: el código debe ser fácil de entender para poder hacer modificaciones o
mantenimiento en el futuro, definir variables de nombre preciso.
4- Eficiencia: el software debe ser eficiente en cuanto al uso de recursos de la computadora

en donde se lo implementara, debe de cumplir con su objetivo sin derrochar recursos del
equipo de cómputo.
5- Confiabilidad: el software debe ser confiable, seguro ante fallas del sistema o fallas
externas, debe de tener la capacidad de recuperar datos ante estos fallos.
2.3.3.Suposiciones y restricciones
1. La aplicación en desarrollo está orientada apropósitos específicos definidos por la U.E. Por
lo tanto, la implementación no requiere ser compatible con múltiples plataformas o
interfaces.
2. El tiempo de espera para realizar una inscripción, registro no deberá ser mayor a 10
minutos.
3. El software deberá ser capaz de atender más de 3 usuarios a la misma vez.
9|Página
2.3.4.Expectativas de calidad
Correctitud Crítico Debe ser una aplicación entendible y bien
estructurado para poder encontrar fácilmente
sus fallas.
Disponibilidad Crítico El sistema deberá estar disponible las 24 horas
del día los 7 días de la semana.
Usabilidad Crítico Deberá ser lo menos complejo posible.
Integridad Crítico Deberá ser seguro y discreto, con cálculos
exactos.
Eficiencia Crítico Deberá tratar de ocupar la menor cantidad de
recursos posibles para funcionar.
Reusabilidad Opcional
Interoperabilidad Opcional
Tabla 1: Requerimientos de Calidad
2.4. Fundamentos de la metodología

Habiendo recolectado la información requerida para el conocimiento de funcionamiento de
la Entidad a la cual se aplica el Sistema, y así lograr la creación del producto; el desarrollo
del Software tendrá un enfoque centrado en dos Herramientas de análisis y diseño: El
Proceso Unificado de Desarrollo de Software (PUDS) y el Lenguaje Unificado de
Modelado (UML).
• PUDS
Para el presente proyecto se empleará la metodología proceso unificado de desarrollo de
software, utilizando al ciclo de vida iterativo e incremental para el desarrollo del Software.
• UML
Para el presente proyecto se utilizará UML el cual nos permitirá visualizar, especificar y
documentar cada una de las partes que comprenderá el desarrollo de la herramienta.
Características del PUDS

El Proceso Unificado es un proceso de desarrollo de software.
Un proceso de desarrollo de software es el conjunto de actividades necesarias para
transformar los requisitos de un usuario en un Sistema Software. El Proceso Unificado es un
marco de trabajo genérico que puede especializarse para una gran variedad de sistemas
software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes
niveles de aptitud y diferentes tamaños de proyecto.
Los aspectos que definen al Proceso Unificado se resumen en tres frases clave:
10 | P á g i n a
•Dirigido por casos de uso
Un Caso de Uso es un fragmento de funcionalidad del Sistema que proporciona al Usuario n
resultado importante. Todos los Casos de Uso juntos constituyen el Modelo de Casos de Uso,
el cual describe la funcionalidad total del Sistema. Sin embargo, los Casos de Uso no son
solo una herramienta para especificar los requisitos de un Sistema, también guían su diseño,
implementación, y prueba, esto es, guían el proceso de desarrollo.
•Centrado en la Arquitectura
La Arquitectura surge de las necesidades de la empresa, y se refleja en los casos de Uso, sin
embargo, también se ve influida por muchos otros factores, como el Hardware, Sistema
Operativo, Sistema de Gestión de Base de Datos, los protocoles de Red, etc. La Arquitectura
es una vista del diseño completo con las características más importantes resaltas, dejando los
detalles de lado.
La relación entre los Casos de Uso y la Arquitectura se debe a que, cada producto tiene tanto
una función como una forma, ninguna es suficiente por sí misma. Estas dos fuerzas deben
equilibrarse para obtener un producto con éxito. A medida que los Casos de Uso se
especifican y maduran, se descubre más de la arquitectura. Esto, a su vez, lleva a la
maduración de más casos de uso. Este proceso continuo hasta que se considere que la
arquitectura es estable.
• Iterativo e incremental
Es práctico dividir el trabajo en partes más pequeñas o mini proyectos. Cada mini proyecto
es una iteración que resulta en un incremento. Las iteraciones hacen referencia a pasos en el
flujo de trabajo, y los incrementos al crecimiento del producto.
Estos tres conceptos son de igual importancia. La Arquitectura proporciona la estructura
sobre el cual guiar las iteraciones, mientras que los Casos de Uso definen los objetivos y
dirigen el trabajo de cada Iteración.
El Proceso Unificado se repite a lo largo de una serie de ciclos de constituyen la vida de un
Sistema, cada ciclo concluye una versión del producto. Cada ciclo consta de cuatro fases:
Inicio, Elaboración, Construcción, Transición.
2.4.1.Modelo de proceso
Para el desarrollo del presente proyecto, se utiliza el Proceso Unificado de Desarrollo de

Software (PUDS), ya que este presenta un conjunto de actividades necesarias para
transformar los requisitos de un usuario en un sistema de Software.
El Proceso Unificado se repite a lo largo de una serie de ciclos, donde cada ciclo consta de 4
fases: inicio, elaboración, construcción y transición en las cuales se realizan iteraciones que
abarcan los flujos de trabajo de captura de requisitos, análisis, diseño, implementación y
prueba. Este proyecto realizará un ciclo del Proceso Unificado, llevando a cabo las siguientes
fases:
11 | P á g i n a
● Inicio
● Elaboración
● Construcción
● Se omitirá la transición ya que conlleva actividades como la puesta en marcha del
producto terminado, formación del cliente y el proporcionar una línea de ayuda y
asistencia.
Dentro de cada fase se realizarán los seis: flujos de trabajo.

A) Captura de requisitos como caso de uso
• Actividades:
• Identificar actores y casos de uso.
• Priorizar casos de uso.
• Detallar casos de uso.
• Prototipos de caso de uso.
✓ Artefacto resultante:
• Modelos de caso de uso.
B) Análisis
• Actividades:
• Análisis de la arquitectura.
• Análisis de casos de uso.
• Análisis de clases.
• Análisis de paquetes.
• Modelo de análisis
C) Diseño
• Actividades:
• Diseño de la arquitectura.
• Diseñar casos de usos.
• Diseñar las clases.
• Diseñar subsistemas.
• Modelo de diseño.
D) Implementación
• Actividades:
• Implementación de la arquitectura.
• Implementar una clase e Implementar un subsistema.
• Realizar Pruebas de unidad.
• Integrar el sistema.
• Modelo de implementación.
12 | P á g i n a
E) Prueba
• Actividades:
• Planificar prueba
• Diseñar prueba.
• Implementar prueba.
• Realizar pruebas de integración.
• Realizar prueba y sistema.
• Evaluar prueba.
• Modelado de prueba.
Ilustración 1. 1: Diagrama de Fases y Flujos Fuente: IBM RUP

Rational Unified Process.
Durante la Fase de Inicio, se desarrolla una descripción del producto final a partir de una
buena idea y se presenta el análisis de negocio para el producto.
Durante la Fase de Elaboración, se especifican en detalle la mayoría de los casos de uso del
producto y se diseña la arquitectura del Sistema.
Durante la Fase de Construcción, se crea le producto. En esta fase, la línea base de la
arquitectura crece hasta convertirse en el sistema completo.
La Fase de Transición, cubre el periodo durante el cual el producto se convierte en versión
beta. Esta fase conlleva actividades como la fabricación, formación del cliente, el
proporcionar una línea de ayuda y asistencia, y la corrección de los defectos que se
encuentren tras la entrega.
• Las cuatro P en el desarrollo del software: persona, proyecto, producto, proceso

El resultado final de un Proyecto Software es un producto que toma forma durante su
desarrollo gracias a la intervención de muchos tipos distintos de personas.
Personas: Los principales autores de un proyecto Software son los arquitectos,
desarrolladores, ingenieros de prueba y el personal de gestión.
Proyecto: Elemento organizativo a través del cual se gestiona el desarrollo del software.
Producto: Artefactos que se crean durante la vida del proyecto.
13 | P á g i n a
Proceso: Un proceso de ingeniería de software es una definición del conjunto completo de
actividades necesarias para transformar los requisitos de usuario en un producto.
Herramientas: Software que se utiliza para automatizar las actividades definidas en el
proceso.
Una organización enfrenta una tarea esencial siempre que hace una persona pase de recurso
"latente" a un puesto de "trabajador". La palabra "trabajador" es usada para denominar a
los puestos, a los cuales se pueden asignar persona, el termino rol para hablar de los papeles
que cumple un trabajador. Un trabajador puede asumir roles en relación con otros
trabajadores en diferentes flujos de trabajos. Cada trabajador es responsable de un conjunto
de actividades necesarias para el diseño de un subsistema.
• El producto es más que código

En el contexto de proceso unificado, el producto que se obtiene es un sistema software. El
término producto aquí se hace referencia al sistema entero, y no solo al código que se entrega.
Un sistema son todos los artefactos que se necesitan para representarlos en una forma
comprensible para maquinas u hombres, para las maquinas, los trabajadores y los interesados.
• Artefactos
Es un término general para cualquier información creada, producida, cambiada o utilizada
por los trabajadores en el desarrollo del sistema.
Básicamente, hay dos tipos de artefactos: artefactos de ingeniería y artefactos de gestión.
14 | P á g i n a
Los de ingeniería creada durante las distintas fases de proceso (requisitos, análisis, diseño,
implementación y prueba). Los de gestión tienen un tiempo de vida corto, lo que dura la vida
del proyecto; A este conjunto pertenecen artefactos como el análisis de negocios, el plan de
desarrollo (incluyendo el plan de versiones e interacciones).
• Un sistema posee una recolección de modelos

Cada trabajador necesita una perspectiva diferente del sistema, las perspectivas recogidas de
todos los trabajadores se encuentran en unidades más grandes, es decir, modelos de modo
que un trabajador pueda tomar una perspectiva concreta del conjunto de modelos.
El Proceso Unificado proporciona un conjunto de modelos cuidadosamente seleccionando

con cual empezar. Este conjunto de modelos hace claro el sistema para todos los trabajadores,
incluyendo a los clientes, usuarios y jefes del proyecto.
• ¿Qué es un Modelo?
Es una abstracción del sistema, especificando el sistema modelado desde un punto de vista y
determinando el nivel de abstracción. Son abstracciones que construyen los arquitectos y
desarrolladores.
• Relación entre Modelos
Un sistema contiene todas las y restricciones entre los elementos incluidos entre diferentes
modelos. El hecho de que los elementos en dos modelos estén conectados no cambia en los
modelos que pertenecen
15 | P á g i n a
2.4.2.Entregables
Los elementos entregables del proyecto incluyen los artefactos de uso interno como los de
conocimiento del alumno, tales artefactos son:
• Internos
✓ Tarjetas CRC, describiendo el comportamiento y estructura de las diferentes clases.

✓ Especificación técnica, contenido de la documentación técnica del producto, su
arquitectura, interfaces, componentes y su distribución.
• Externos
✓ Producto backlog, un listado completo de todas las historias de usuario o

funcionalidades requeridas en el software.
✓ Historias de usuario, elaboradas en conjunto entre el equipo de desarrollo y los
alumnos, listando sus criterios de aceptación, prioridad, y estimación.
✓ Pizarra de tarjeta de historia, pizarras donde se organizan las diferentes historias de
usuario ordenadas por iteración y entregas.
✓ Calendario de entregas, calendario con fechas de reservación de las diferentes
reservaciones de máquinas.
✓ Pruebas de aceptación, complementan a la documentación y requerimientos al
proveer un conjunto de reglas de verificación de los diferentes componentes de la
aplicación.
2.4.3.Hitos principales
Se definen los siguientes hitos principales:
• Releaseplanning: En esta reunión o reuniones se definen las funcionalidades a implementar

para el producto.
• Definición de la arquitectura: Al finalizar este hito, se debe tener un bosquejo de
arquitectura de alto nivel, tal arquitectura será utilizada y modificada durante el desarrollo.
• Release candidatos: Estos releases se hacen cada cierto tiempo y se presentan como
paquetes entregables al usuario, generalmente engloban todas las funcionalidades de un
módulo.
2.4.4.Procesos de desarrollo
16 | P á g i n a
3. ORGANIZACIÓN DEL PROYECTO
Fundada el 9 de mayo de 1966, se pusieron en marcha a la vez 7 unidades educativas en La
Paz (Copacabana y Corazón de Jesús), Santa Cruz (La Merced), Cochabamba (El Salvador),
Oruro (Virgen del Mar), Potosí (Fray Vicente Bernedo) y Chuquisaca (Milagrosa Loyola).
El primer Director Nacional fue Humberto Portocarrero.
Fe y Alegría Bolivia está presente en los 9 Departamentos del país y atiende a unos 182.000
alumnos y alumnas y a 240.000 padres y madres de familia. Respecto a su equipo, cuenta
con el apoyo de 9.223 docentes y más de 100 técnicos y directivos a nivel nacional.
“U.E FE Y ALEGRIA -VIRGEN DE COTOCA”
Modulo de
Registros Modulo Notas Modulo Usuarios modulo de pagos
Reg. de Reg. de factura

Reg. de Alumnos Reg. Notas administrador
Reg. secretaria Reg. de

mensualidades
Reg. Cursos Registro de
Bimiestre
Reg. Paralelos Registro de Materias
Registro de
Reg. Docentes Matricula
17 | P á g i n a
3.1. Organización interna
Actualmente la Unidad Educativa cuenta con 1500 estudiantes en ambos turnos y un plantel
de 80 trabajadores entre docentes administrativos y personal de servicio. De aquí en más, la
Unidad Educativa Fe y Alegría- Virgen de cotoca, se proyectó a convertirse en una institución
educativa completa con todo lo necesario especialmente en lo que respecta a la infraestructura
y equipamiento.
En el año 2014 se inauguró el nuevo módulo moderno para la Unidad Educativa, este módulo
posee 2 plantas, cuenta con laboratorio de computación.
Está conformado de la siguiente manera:
• Adm. Director
• Plantel Docente
• Padres de Familia
• Nivel de Estudios
18 | P á g i n a
3.2. Roles y responsabilidades
Rol Responsabilidad
El Alumno • se registra en la página, para luego ingresar con usuario y contraseña a su
cuenta y posteriormente al menú donde seleccionara los ítems que desea
para luego confirmar su inscripción.
El Alumno • visualizará el listado de su inscripción y los atenderá de acuerdo al orden

de llegada.
El Alumno • Una vez inscrito el alumno de turno pasará el detalle del pedido al área de
Producción donde se elaborará el pedido.
área académica • Elaborada la inscripción, del área académico donde se lleva a cabo la
inscripción
área de • Una vez inscrito el alumno se emite el recibo y se efectúa la misma
Distribución
4. PROCESO TECNICO
Laravel es uno de los frameworks de código abierto más fáciles de asimilar para PHP. Es
simple, muy potente y tiene una interfaz elegante y divertida de usar. Fue creado en 2011 y
tiene una gran influencia de frameworks como Ruby on Rails, Sinatra y ASP.NET MVC.
El objetivo de Laravel es el de ser un framework que permita el uso de una sintaxis refinada
y expresiva para crear código de forma sencilla, evitando el «código espagueti» y
permitiendo multitud de funcionalidades. Aprovecha todo lo bueno de otros frameworks y
utiliza las características de las últimas versiones de PHP.
La mayor parte de su estructura está formada por dependencias, especialmente de Symfony,
lo que implica que el desarrollo de Laravel dependa también del desarrollo de sus
dependencias.
Características Generales
Sistema de ruteo, también RESTful
Blade, Motor de plantillas
Peticiones Fluent
Eloquent ORM
Basado en Composer
Soporte para el caché
Soporte para MVC
Usa componentes de Symfony
Adopta las especificaciones PSR-2 y PSR-4
19 | P á g i n a
Cambios, mejoras y añadidos en la versión 5
Rutas. Almacenamiento en caché de rutas y middleware, son dos de las nuevas
funcionalidades añadidas a esta versión.
Inyección de dependencias en rutas y controladores. Ahora se puede escribir cualquier
dependencia en tus métodos.
Authentication Scaffolding. Por defecto, ahora el flujo de autenticación está preinstalada y
ejecutada para ti, y se han introducido dos nuevas características:
AuthenticatesAndRegistersUsers y ResetsPasswords.
Socialite. Con este paquete opcional te permitirá controlar OAuth de forma más óptima.
Estructura de carpetas. Se ha cambiado la estructura del directorio y se han movido fuera de
la aplicación, como config, la base de datos, almacenamiento y recursos. Dentro se
encuentran divididas en carpetas adicionales como comandos, consola, eventos, excepciones,
manejadores, http, proveedores, servicios.
Cambios en Blade. En el conocido sistema de plantillas ha habido un cambio significativo.
Antes teníamos dos estilos: {{{para escapar y {{si no se deseaba escapar la información.
Ahora tanto {{{como {{se escapan/purifican y se utiliza {!! $var !!} si no se desea escapar
la información.
Contracts. Para que sirvan como documentación, este conjunto de interfaces define los
servicios elementales suministrados por Laravel.
Comandos y eventos. Nuevos cambios en los siguientes recursos:
Fachadas y ayudas. Existen nuevas funciones de ayuda que reemplazan algunos de los items
más frecuentes.
Uso Layouts con Blade
Los Layouts en Blade, son archivos de texto plano que contiene todo el HTML de la página
con etiquetas que representan elementos o zonas a incluir en el Layout, o vistas parciales
como se conocen en otros Frameworks en PHP.
Sin embargo, en Blade estos elementos incrustados se organizan en un sólo archivo. Esta es
una idea muy interesante de Laravel que mejora la organización de las vistas y su
rendimiento. Sobre todo, cuando las vistas pueden llegar a ser muy complejas incluso con
elementos anidados.
En el render de una Vista completa en Lavarel se usan dos (2) archivos:
El Layouts definiendo el HTML global y las zonas a incluir.
Un sólo archivo, la Vista, con los elementos (partial views).
Modelo
Laravel incluye un sistema de mapeo de datos relacional llamado Eloquent ORM que facilita
la creación de modelos. Este ORM se funda en patrón active récord y su funcionamiento es
muy sencillo. Es opcional el uso de Eloquent, pues también dispone de otros recursos que
nos facilitan interactuar con los datos, o específicamente la creación de modelos.
Vista
Laravel incluye de paquete un sistema de procesamiento de plantillas llamado Blade. Este
sistema de plantillas favorece un código mucho más limpio en las Vistas, además de incluir
un sistema de Caché que lo hace mucho más rápido. El sistema Blade de Laravel, permite
una sintaxis mucho más reducida en su escritura.4 Por ejemplo, en vez pintar la vista usando
el código PHP:
20 | P á g i n a
4.1. Métodos herramientas y técnicas
Blade
Blade es un sistema de plantillas para crear las vistas en Laravel. Con él puedes crear
plantillas, y secciones que puedes reutilizar en diferentes vistas. Además de tener accesible
las variables de PHP, pero no solo eso, podrás utilizar código de PHP en la misma plantilla
con una nomenclatura más simple.
Blade es el motor de plantillas simple pero potente provisto con Laravel. A diferencia de
otros motores de plantillas PHP populares, Blade no le impide usar código PHP simple en
sus vistas. De hecho, todas las vistas de Blade se compilan en código PHP simple y se
almacenan en caché hasta que se modifican, lo que significa que Blade agrega esencialmente
cero sobrecargas a su aplicación. Los archivos de vista Blade usan la extensión de archivo y
generalmente se almacenan en el directorio...blade. phpresources/views
Eloquent
Eloquent es el sistema que trae Laravel para la base de datos, para escribir y sacar los datos.
Lo que hace es transformar el código de eloquent a consultas SQL, de forma que nos es más
sencillo trabajar con objetos y no con código SQL directamente.
Routing
Laravel también tiene un sistema de rutas, no es más que poder controlar de forma organizada
que rutas tendrá nuestra aplicación. Si son get, post, puedes hacer grupos de rutas con un
mismo prefijo, rutas con permisos, sin permisos, todo lo necesario para gestionar las rutas de
nuestra aplicación.
Middlewares
Estos son controladores que se ejecutan antes o después de una petición, por ejemplo, para
validar cosas antes de pasar a la petición, como por ejemplo que ese usuario que está pidiendo
el recurso tiene permisos para acceder. De esta manera solo programamos una vez el checkeo
y luego se les aplica a todas las rutas que sea necesario.
Controller
En lugar de definir toda su lógica de manejo de solicitudes como Cierres en archivos de ruta,
es posible que desee organizar este comportamiento utilizando las clases de Controlador. Los
controladores pueden agrupar la lógica de manejo de solicitudes relacionadas en una sola
clase. Los controladores se almacenan en el directorio.app/Http/Controllers.
Paginación
En otros marcos, la paginación puede ser muy dolorosa. El paginador de Laravel está
integrado con el generador de consultas y el ORM Eloquent y proporciona una paginación
conveniente y fácil de usar de los resultados de la base de datos listos para usar. El HTML
generado por el paginador es compatible con el framework CSS Bootstrap.
21 | P á g i n a
Migraciones
Las migraciones son como el control de versiones de su base de datos, lo que permite a su
equipo modificar y compartir fácilmente el esquema de la base de datos de la aplicación. Las
migraciones generalmente se combinan con el generador de esquemas de Laravel para
construir fácilmente el esquema de la base de datos de su aplicación. Si alguna vez ha tenido
que decirle a un compañero de equipo que agregue manualmente una columna a su esquema
de base de datos local, se enfrenta al problema que resuelven las migraciones de la base de
datos.
La Schema fachada de Laravel proporciona soporte agnóstico de base de datos para crear y
manipular tablas en todos los sistemas de bases de datos compatibles de Laravel.
4.2. Documentación del producto
public function up() public function up()

{ {
Schema::create('alumno', Schema::create('gestion',
function (Blueprint $table) { function (Blueprint $table) {
$table->id(); $table->id();
$table- $table-
>string('nombre',40); >string('codGestion',4);
$table- $table-
>string('apellidos',40); >date('fechaInicio');
$table->date('fechaNac'); $table->date('fechaFin');
$table->string('dni',10); $table->boolean('estado')-
$table- >default(1);
>string('matricula',20); });
}); }
}
class InscripcionGestion extends

Model
class Alumno extends Model {
{ protected
protected $table = 'alumno'; $table='inscripcion_gestion';
protected $fillable = [ protected $fillable=[
'id', 'id_inscripcion',
'nombre', 'id_gestion_curso',
'apellidos', 'paralelo'
'fechaNac', ];
'dni', public $timestamps=false;
'matricula' }
];
public $timestamps = false;
}
22 | P á g i n a
class AlumnoController extends Controller
{
public function index(Request $request){
$buscar = $request->buscar;
$criterio = $request->criterio;
if($buscar==''){
$alumno= Alumno::orderBy('alumno.id','desc')->paginate(10);
}
else{
$alumno= Alumno::where('alumno.'.$criterio, 'like', '%'.$buscar.'%')
->orderBy('alumno.id','desc')->paginate(10);
}
return $alumno;
}
public function listarAlumno(Request $request){

if($buscar==''){
$alumno= Alumno::all();
}
else{
$alumno= Alumno::where('alumno.'.$criterio, 'like', '%'.$buscar.'%')->get();
}
return $alumno;
}
public function guardar(Request $request){

$alumno = new Alumno();
$alumno->nombre=$request->nombre;
$alumno->apellidos=$request->apellidos;
$alumno->fechaNac=$request->fechaNac;
$alumno->dni=$request->dni;
$alumno->matricula=$request->matricula;
$alumno->save();
}
public function guardar2(Request $request){

$alumno = new Alumno();
23 | P á g i n a
$alumno->save();
$obj= Alumno::select('id','nombre','apellidos')->where('id','=',$alumno->id)-
>get();
return $obj;
public function modificar(Request $request){

$alumno= Alumno::findOrFail($request->id);
$alumno->save();
}
public function eliminar(Request $request){

$alumno= Alumno::findOrFail($request->id);
$alumno->delete();
}
}
class InscripcionController extends Controller

{
public function index(Request $request){
if($buscar == ''){
$inscripcion = DB::table('inscripcion as i')
->join('alumno as a', 'i.id_alumno', '=', 'a.id')
->join('usuario as u', 'i.id_usuario', '=', 'u.id')
->join('inscripcion_gestion as ig', 'i.id', '=', 'ig.id_inscripcion')
->join('gestion_curso as gc', 'gc.id', '=', 'ig.id_gestion_curso')
->join('curso as c', 'gc.id_curso', '=', 'c.id')
->join('gestion as g', 'gc.id_gestion', '=', 'g.id')
24 | P á g i n a
->select('i.id','a.matricula','a.nombre as
alumno','i.fecha_inscripcion','i.estado','u.login as secretaria','c.nombre as
curso','g.codGestion','ig.paralelo')
->paginate(20);
}
else{
$inscripcion = DB::table('inscripcion as i')
->join('alumno as a', 'i.id_alumno', '=', 'a.id')
->join('usuario as u', 'i.id_usuario', '=', 'u.id')
->join('inscripcion_gestion as ig', 'i.id', '=', 'ig.id_inscripcion')
->join('gestion_curso as gc', 'gc.id', '=', 'ig.id_gestion_curso')
->join('curso as c', 'gc.id_curso', '=', 'c.id')
->join('gestion as g', 'gc.id_gestion', '=', 'g.id')
->select('i.id','a.matricula','a.nombre as
alumno','i.fecha_inscripcion','i.estado','u.login as secretaria','c.nombre as
curso','g.codGestion','ig.paralelo')
->where($criterio,'LIKE' , '%' . $buscar . '%')
->paginate(20);
}
return $inscripcion;
}
public function guardar(Request $request){

try{
DB::beginTransaction();
$inscripcion=new Inscripcion();
$inscripcion->fecha_inscripcion=$request->fecha_inscripcion;
$inscripcion->estado='1';
$inscripcion->id_alumno=$request->id_alumno;
$inscripcion->id_usuario=\Auth::user()->id;
$inscripcion->save();
$inscrip_gest=new InscripcionGestion();
$inscrip_gest->id_inscripcion=$inscripcion->id;
$inscrip_gest->id_gestion_curso=$request->id_gestion_curso;
$inscrip_gest->paralelo=$request->paralelo;
$inscrip_gest->save();
DB::commit();
return[
'id'=>$inscripcion->id
];
} catch (Exception $e){
DB::rollBack();
25 | P á g i n a
}
}
public function desactivar(Request $request) {

$inscripcion = Inscripcion::findOrFail($request->id);
$inscripcion->estado = '0';
}
public function activar(Request $request){

$inscripcion = Inscripcion::findOrFail($request->id);
$inscripcion->estado = '1';
}
}
26 | P á g i n a
5. ANALISIS DE REQUERIMIENTO
Software: el sistema se desarrollará bajo las siguientes herramientas:
• La aplicación se desarrollará utilizando el lenguaje PHP versión 5.6
• Gestor de base de datos: MYSQL
• El servidor será: Apache/2.4.32(Win32)
• Microsoft Windows 10.
• Cualquier navegador web de preferencia Google Chrome.
Hardware: las características mínimas en hardware del ordenador son las siguientes.
• Processor Core i3 2.20 GHz
• Memoria RAM de 4 Gb.
• Memoria de Video 512 Mb.
Espacio en el Disco Duro 20Gb.
5.1. Dominio de la aplicación

class Modelo de diseño
factura secretaria
- cod_factura: int - cod_secretaria: int

- descripcion: varchar - nombres: varchar
- fecha: date - apellidos: varchar
- fecha_nac: varchar
- direccion: varchar
1
1 1..*
mensualidad
Usuario
- id_mensualidad: int
- monto: money - id_usuario
- fecha: date - login
- password
- rol_usuario
1 Gestion
InscripcionGestion
1..*
- Paralelo - cod_gestion: int
- fecha_inicio: date
0..* - fecha_final: date
1
Alumno Inscripcion
1..*
1 CursoGestion
- id_alumno: int - cod_inscripcion: int
- nombres: varchar - fecha_inscripcion: date
- apellidos: varchar
- sexo: char 1 1..*
1..*
- direcion: varchar
- fecha_nac: date
1..* curso
- cod_curso: int
1..* CursoMateria - grado: varchar
- nivel: varchar
- cod_curso
- paralelo: char
1..* - cod_materia
- turno: varchar
- cupo: int
1..*
1..* 1..*
AlumnoMateria
materia
- nota
CursoParalelo - cod_materia: int
- nombre: varchar
- area: varchar
1..*
1 1..*
1
Paralelo
periodo 1
- id_paralelo
- cod_periodo - nombre docente
- nombre_periodo
- periodo_inicio - cod_docente
- periodo_final - nombres
- apellidos
1..*
- sexo
- direccion
horario
- fecha_nac
- cod_horario - telefono
- dia
- hora_inicio
- hora_fin
- aula
27 | P á g i n a
Modelo de Dominio
Historia de Usuario
Usuario: ALUMNO (registros de
Numero:1 alumno)
Nombre historia: Registro del aluno
Prioridad en negocio: Riesgo en desarrollo:
Alta Baja
Programador responsable: Carlos Eduardo Fernández Parada
Descripción:
Registro del alumno, que se inscribirá en la U. E.
Validación:
El administrador registra al alumno.
Historia de Usuario
Usuario: administrador (inscripción
Numero:2 de alumno)
Nombre historia: Registro de inscripción
Alta Baja
Programador responsable: Saul Villaroel Rojas
Descripción:
Registro del alumno que se inscribirá en la UE
Validación:
El administrador registra el curso para el cual se realizará la inscripción del alumno.
Además, debe impedir registrar una inscripción en una gestión distinta a la actual.
28 | P á g i n a
Historia de Usuario
Usuario: administrador (inscripción
Numero:3 de materia)
Nombre historia: Registro Materia
Alta Baja
Programador responsable: Elias Erbin Bonifacio
Descripción:
Registro de la materia del alumno que se inscribió en la UE.
Validación:
El administrador registra la materia, permita habilitar y desactivar materias que no poseen
docente quien la dicte.
Historia de Usuario
Usuario: administrador (registro del
Numero:4 docente)
Nombre historia: Registro del docente
Alta Baja
Programador responsable: Carlos Eduardo Fernández Parada
Descripción:
Registro del docente que dictara la materia en la UE.
Validación:
El administrador registra el docente.
29 | P á g i n a
Historia de Usuario
Usuario: Administrador (registro de
Numero:5 la secretaria)
Nombre historia: Registro de Secretaria

Alta Baja
Programador responsable: Saul Villaroel Rojas
Descripción:
Registro de la secretaria que utilizara el software en la UE
Validación:
El administrador registrará a la secretaria en el sistema y le dará acceso al mismo.
Historia de Usuario
Usuario: secretaria (registro pago de
Numero:6 mensualidad)
Nombre historia: Registro Pago de Mensualidad

Alta Baja
Programador responsable: Elias Erbin Bonifacio
Descripción: La secretaria registrara en el sistema
los pagos que realicen los alumnos
Validación: La secretaria registra los pagos de
mensualidad
5.2. Identificación de actores y casos de usos
30 | P á g i n a
Diagrama de Actividades
act Registro de Notas
PROFESOR SECRETARIA
Inicio
Elaboracion
Nota
Bimestre
Enviar nota Recibe Notas

Bimestre
Verifica
NO SI
Valida
Recibe
Notificacion Notificar Error Registrar Notas
fin
act Entrega Boletin
APODERADO PROFESOR SECRETARIA

31 | P á g i n a
Inicio
32 | P á g i n a
act Gestionar Inscripcion
ALUMNO ADMINISTRATIVO
Inicio
Solicita Inscribirse Recibe Solicitud
Verifica Requisitos Solicita Requisito
SI
VALIDA
Entrega
Recibe Requisitos
Requisito
VALIDA
Consulta Cupo
Verifica Cupos
valida
Verifica si Alumno
Cancelar Inscripcion Anrtiguo
ES?
Registra
Registrar Rude
Inscripcion
Recibe Notificacion Notificar Alumno
Final
33 | P á g i n a
class Modelo de dominio
Secretaria Alumno
inicio
genera solicitud
solicitud pago recibe solicitud

mensualidad
v erifica solicitud cancela solicitud
valida
verificar periodo
entrega factura recibe factura
env ia notificacion recibe notificacion
fin
34 | P á g i n a
Identificación de casos de Usos
Es una técnica para la captura de requisitos potenciales de un nuevo sistema o una

actualización de software. Cada caso de uso proporciona uno o más escenarios que indican
cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un
objetivo específico. Normalmente, en los casos de usos se evita el empleo de jergas técnicas,
prefiriendo en su lugar un lenguaje más cercano al usuario final. En ocasiones, se utiliza a
usuarios sin experiencia junto a los analistas para el desarrollo de casos de uso.
En otras palabras, 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 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 requerimientos del sistema al mostrar cómo reacciona a eventos que se
producen en su ámbito o en él mismo.
CU1 Administrar Gestión

CU2 Gestionar Loguin
CU3 Administrar Curso
CU4 Gestionar Materias
CU5 Verificar Cupo
CU6 Gestionar Profesor
CU7 Inscribir Alumnos
CU8 Gestionar Nota
CU9 Generar Boletín
CU10 Visualizar Nota
CU11 Gestionar Apoderado
CU12 Administrar Alumno
CU13 Administrar Postulante
CU14 Gestionar Administrativo
CU15 Registrar Grupo
Identificación de Actores
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.
35 | P á g i n a
Apoderado(A1)
Alumno(A2)
Administrativo(A3)
Docente(A4)
5.2.1.Actores
Durante la captura se pude identificar los siguientes actores:
- Apoderado(A1): Es la persona responsable o la que está a cargo de uno o más estudiantes
que estudian en el Centro Educativo, el tutor tiene la capacidad de visualizar las notas de
un estudiante.
- Alumno(A2): Es la persona que ya estudia en la Centro Educativo, por lo tanto, sus datos
ya están registrados en el sistema, se registra también para cada alumno las notas que
obtiene en cada materia durante el bimestre.
- Administrativo(A3): Es la persona que se encarga de decepcionar y registrar los datos del
alumno, plantel docente, apoderado y registro de notas. Lleva a cabo las instrucciones
que involucran al sistema que el director efectúa, como ser habilitar más cupo para un
respectivo curso. Registra en el sistema las notas de todas las materias que lleva cada
alumno, las cuales se las proporciona el profesor designado para dictar la respectiva
materia. Además de imprimir boletines.
- Docente(A4): Encargado del control de avance académico y modificaciones en el registro
de notas.
5.2.2. Casos de usos

uc CU1: Administrar Gestion
CU6 Gestionar
Profesor
CU3 Administrar
Curso
CU4 Gestionar
CU1 Administrar Materia
Gestion
CU7 Inscribir Alumno
A5 Director
36 | P á g i n a
Nombre de
CU1 ADMINISTRAR GESTIÓN
Caso de Uso
Propósito Registrar los datos de la Gestión Académica.
Se debe conocer el año, la fecha de inicio y finalización de la gestión y su
Descripción
estado.
Actores Director
Actor Iniciador Director
Precondición Ninguna
1 NUEVA GESTION
Esta opción pone en blanco todos los campos excepto el ID que es
generado automáticamente, por tal razón este dato no necesita ser
introducido por teclado.
Ingresar los datos a partir de:
El año.
Fecha de Inicio de la Gestión
Fecha de Finalización de la Gestión
Estado de la Gestión
1.1 GUARDAR
Seleccione guardar para registrar los datos de la nueva Gestión.
2. EDITAR GESTION
Flujo principal Se introduce el año de la gestión ya ingresada como nueva gestión, luego
se selecciona el botón “Rellenar Datos”; este botón procede a rellenar los
campos, es aquí donde se puede editar, fechaInicio, fechaCierre o
estadoGestion
2.1 Guardar
Seleccione guardar para registrar los datos que se editaron de la
gestión.
3. ELIMINAR GESTION
Se introduce los campos, año, fechaInicio, fechaCierre y estadoGestion la
cual se desea eliminar.
3.1 Eliminar
Se procede a eliminar la gestión introducida en los campos
Excepción 1.1 La Gestión ya existe.
Post condición
Administrar Curso, Gestionar Profesor, Gestionar Materia, Inscribir
Alumno.
37 | P á g i n a
Caso de uso: Gestionar Loguin
uc CU2: Gestionar Login
CU14 Gestionar
Administrativo
CU12 Administra
«include» Alumno
«include»
CU2 Gestionar
Login
«include» CU6 Gestionar
Profesor
A6 Administrador
Sistemas
38 | P á g i n a
Nombre de Caso de
CU2 GESTIONAR LOGIN
Uso
Propósito Gestionar a los Usuarios que estén usando el sistema en tiempo real
Los Alumnos, Profesores y Administrativos ya deben estar registrados
Descripción
en el sistema.
Actores Administrador
Actor Iniciador Administrador
Precondición Administrar Alumno, Gestionar Administrativo, Gestionar Profesor.

1 ACEPTAR
El usuario utilizara esta opción para Acceder a su perfil, habiendo escrito previamente
su código y contraseña en el campo especificado.
El estado del Usuario se cambiara automáticamente a V
1.1 CERRAR SESION
Seleccione esta opción para cerrar su sesión dentro del Sistema en las pestañas
del lado izquierdo de la pantalla.
El estado del Usuario se cambiara automáticamente a F
1.1.1SI
Para confirmar y proceder al cierre de sesión.
Flujo 1.1.2 NO
principal Para cancelar el cierre de sesión.
2. CAMBIAR CONTRASEÑA
El usuario tendrá en esta nueva ventana tendrá la opción de cambiar su contraseña
realizando los siguientes pasos:
• Colocar su nombre de usuario actual
• Introducir su contraseña actual
• Introducir la nueva contraseña que desea el usuario
• Repetir la contraseña nueva
• Dar en el botón aceptar para guardar los cambios o caso contrario en
cancelar para cancelar la operación
Excepción 1.1 El Nombre de Usuario o la Contraseña son incorrectas
Post Ninguna
condición
39 | P á g i n a
Caso de uso: Administrar Curso
uc CU3: Administrar Curso
CU3 Administrar
Curso
A5 Director
Nombre de
Caso de Uso CU3 ADMINISTRAR CURSO
Propósito Registrar, Modificar, Eliminar (eliminación lógica) Cursos.
Descripción Se debe conocer el Código del Curso, Nombre del Curso y el Nivel.
Actor Director
1. NUEVO CURSO
Esta opción pone en blanco todos los campos para ser introducidos por
teclado.
1.1 Ingresa los datos a partir de
Nivel
Nombre Curso
Código de Curso
1.2 Guardar
Seleccione guardar para registrar los datos del Curso.
2. EDITAR CURSO
Seleccione editar para realizar alguna modificación sobre los datos del
Curso.
Se introduce el codigoCurso se “busca” los datos y luego estos son
Flujo principal
rellenados. Estos datos rellenados pueden ser modificados por el usuario que
ejecute esta acción.
2.1Guardar
Seleccione guardar para registrar los datos modificados del
Curso.
3. ELIMINAR CURSO
Se introduce el codigoCurso se “busca” los datos y luego estos son
rellenados. Estos datos rellenados pueden ser eliminados por el usuario que
ejecute esta acción
3.1 Eliminar
Seleccione el botón ‘eliminar’ para poder eliminar el
Curso
40 | P á g i n a
Excepción 1.1 El Curso ya existe.
Post condición Ninguna
Caso de uso: Gestionar Materia

uc CU4: Gestionar Materias
CU3 Administrar
Curso
CU6 Gestionar
Profesor
CU4 Gestionar
Materia
A6 Administrador
Sisstemas
Nombre de
CU4 GESTIONAR MATERIA
Caso de Uso
Propósito Gestionar la materia según el curso correspondiente.
El administrador visualizará las materias del curso seleccionado para la
Descripción
formulación de notas por materias
Actores Director
Precondición Administrar Curso

1. NUEVA MATERIA
1.1 Esta opción pone en blanco todos los campos para ser introducidos
por teclado.
1.2 Ingresa los datos de
Nombre de la materia
Sigla (Sigla de la Materia)
Nivel
Curso
Flujo principal
1.3 Guardar
Seleccione guardar para registrar los nuevos datos de la
Materia.
2. EDITAR MATERIA
Se introduce la sigla de la materia en el campo “sigla”, luego se procede a
‘rellenar datos’. Estos datos rellenados pueden ser modificados por el
usuario que ejecute esta acción.
2.1 Editar
41 | P á g i n a
Seleccione editar para registrar los datos modificados de la Materia.
3. ELIMINAR MATERIA
Se introduce la sigla de la materia en el campo “sigla” y luego se procede a
eliminar
3.1 Eliminar
Seleccione el botón ‘eliminar’ para poder eliminar el
Materia
Excepción 1.2 Datos no válidos.
Post condición Gestionar Profesor
Caso de uso: Verificar Cupo

uc CU5: Verificar Cupo
CU13 Administrar
Postulante
CU5 Verificar Cupo
A3 Secretaria A7 Postulante
Nombre de
CU5 VERIFICAR CUPO
Caso de Uso
Propósito Verificar el cupo solicitado por el postulante
Se permite a la secretaria verificar la existencia de un cupo para la inscripción
Descripción
del postulante
Actores Secretaria, Postulante
Actor Iniciador Secretaria
Precondición Administrar Postulante

VERIFICAR CUPO
La secretaria selecciona esta opción que le permitirá conocer el saldo de cupos
Flujo principal existentes en el curso al cual el postulante solicita la inscripción.
NOTIFICACIÓN
El sistema emitirá un mensaje con el saldo de cupos.
Excepción Ninguna

Caso de uso: Gestionar Profesor
42 | P á g i n a
uc CU6: Gestionar Profesor
CU6 Gestionar
Profesor
A6 Administrador A7 Postulante
Sistemas
Nombre de
CU6 Gestionar Profesor
Caso de Uso
El objetivo de este C.U. es saber quiénes son los docentes que están
Propósito
presentes durante toda la gestión académica actual
Este C.U., nos da a conocer la o las materias que se asignaron a un
Descripción
profesor, que días pasa clases, cuantas horas pasa clases.
Actores Administrador del Sistema, Profesor
Actor Iniciador Administrador del Sistema
1. REGISTRAR NUEVO PROFESOR
1.1. Seleccione nuevo para Registrar un Nuevo Profesor
Esta opción pone en blanco las casillas de:
Nombre
Apellido Paterno
Apellido Materno
CI
Genero
FechaNacimiento
Dirección
Deberá ingresar dichos datos.
1.2. Guardar
Flujo Principal
Seleccione guardar para registrar los datos del nuevo profesor.
1.3. Cancelar
Seleccione salir para Terminar o cancelar la operación y retornar
al formulario anterior.
2. MODIFICAR
Se introduce el cód. de Profesor del cual se quiere modificar los datos,
luego se procede a ‘buscar’, esta acción rellena los siguientes datos:
Nombre, Apellido Paterno, Apellido Materno, CI, Genero,
FechaNacimiento, Dirección
2.1Guardar
43 | P á g i n a
Seleccione guardar para registrar los datos que se modificaron del
Profesor.
2.2Cancelar
Seleccione cancelar para Terminar o cancelar la operación y
retornar al formulario anterior.
2.ELIMINAR
Se introduce el cód. de Profesor el cual se quiere eliminar los datos del
sistema, luego se procede a ‘buscar’, esta acción rellena los siguientes
datos:
Nombre, Apellido Paterno, Apellido Materno, CI, Genero,
FechaNacimiento, Dirección
2.1Guardar
Seleccione guardar para eliminar los datos que se mostraron de
dicho Profesor.
2.2Cancelar
Seleccione cancelar para Terminar o cancelar la operación y
retornar al formulario anterior.
Excepción Ninguna
Caso de uso: Inscribir Alumno
uc CU7: Inscribir Alumno
CU13 Administrar
Postulante
SECRETARIA
ALUMNO
44 | P á g i n a
Nombre de
CU7 INSCRIBIR ALUMNO
Caso de Uso
Registrar la inscripción de los postulantes (alumnos nuevos) en caso de haber
Propósito presentado todos los requisitos de forma correcta y de alumnos antiguos
registrarlos en una nueva gestión.
Actores Secretaria, Alumno
Actor
Alumno
Iniciador
Precondición Administrar Postulante

1. SELECCIONAR
1.1 Se selecciona en la interfaz una de las opciones existentes, si el alumno
es nuevo o es alumno antiguo.
2. Alumno Nuevo
2.1 Si se trata de un alumno nuevo se procede a buscarlo con su C.I.
Para que se generen automáticamente de acuerdo a los datos de
postulante.
2.1 Inscribir Alumno
Efectúa la acción de registrar la inscripción del alumno. El cual asignara
el curso al cual le tocara, en que turno, más particularmente
disminuyendo un cupo al curso correspondiente.
3. Alumno Antiguo
Flujo de 3.1 Si se trata de un alumno antiguo se verifica primeramente los cupos
trabajo disponibles en el curso que el alumno indica en los campos disponibles
y se lo busca con su código de alumno para el rellenado automático de
sus datos.
4. CANCELAR
Cancela el proceso de inscripción de dicho estudiante.
Excepciones 3.1 No existen cupos
Caso de uso: Gestionar Nota

uc CU8: Gestionar Nota
CU4 Gestionar
Materia
CU9 Generar Boletin
CU8 Gestionar Nota
Profesor
45 | P á g i n a
Nombre Caso de CU8 GESTIONAR NOTA
Uso
Registrar, modificar las notas bimestrales que se asignan a cada alumno de
Propósito las materias que lleva.
Se ingresarán al sistema las notas de las materias que lleva cada uno de los
alumnos. Para el registro de estas notas se tomó en cuenta la Valoración
Descripción Cuantitativa y Valoración Cualitativa dentro de esto se valoran cuatro
parámetros que son: Ser valor asignado 20 puntos, Saber valor asignado 30
puntos, Hacer valor asignado 30 puntos y Decidir valor asignado 20 puntos.
Actores Profesor
Actor Iniciador Profesor
Precondición Gestionar Materia
Generar Libreta
Post Condición
1.-REGISTRAR NOTAS
1.1.-Seleccione nueva para Registrar una nueva nota según los parámetros
establecidos en un alumno
1.2 Guardar
Seleccione guardar para registrar los datos nueva nota
correspondiente de una de las N materias que lleva un alumno.
1.3 Cancelar
Seleccione salir para Terminar o cancelar la operación y retornar al
formulario anterior.
Flujo Principal 2. MODIFICAR NOTAS
Seleccione editar para realizar alguna modificación sobre los datos de
la nota de un determinado bimestre de una de las materias que lleva
un alumno.
2.1Guardar
Seleccione guardar para registrar los datos corregidos de la nota de
una materia que lleva un alumno
2.2 Cancelar
Seleccione salir para Terminar o cancelar la operación y retornar al
formulario anterior.
No puede modificar la nota final del bimestre, sin modificar las notas que la
Excepción
determinaron.
46 | P á g i n a
Caso de uso: Gestionar Boletín
uc CU9: Generar Boletin
CU9 Generar Boletin
Administrativo Alumno
Nombre Caso
CU9 GENERAR BOLETÍN
de Uso
Genera un boletín para un alumno correspondiente, que es un medio

Propósito
que informa el rendimiento académico que obtuvo en sus materias.
Una vez terminado el Bimestre y al haber obtenido sus notas con sus
Descripción respectivos exámenes de cada materia se comienza el llenado del
boletín bimestral para cada alumno de la unidad educativa
Actores Administrador del Sistema, Alumno
Actor Iniciador Alumno
Pre condición Ninguna
1. NUEVO
Para Registrar un nuevo boletín se deberá se deberá indicar:
Código del alumno
Proceso o Flujo Nro de Bimestre
Introduciendo esta información se generara automáticamente la
de Suceso información sobre los datos personales del alumno y la de sus
respectivas notas.
2. IMPRIMIR
3.1 Imprime el reporte generado del boletín.
1. No puede modificar el promedio final, sin modificar la(s) nota(s)

Excepción
que determinaron este valor.
47 | P á g i n a
Caso de uso: Visualizar Nota
uc CU10: Visualizar Nota

CU2 Gestionar Login
Alumno Apoderado
Nombre de Caso
de Uso
Propósito Visualizar las notas del alumno por materias
El alumno podrá ver las notas registradas por materia, previamente debe ser
Descripción autenticado en el sistema, es decir, debe haber ingresado su nombre de
usuario y su contraseña.
Actores Alumno y Tutor
Actor Iniciador Alumno
Precondición Gestionar Loguin
1. INTRODUCIR DATOS
Se introduce el código del alumno del cual se quiere visualizar la nota.
2. Buscar
Se rellenan todos los campos de los alumnos, habiendo antes introducido el
Flujo principal
codAlumno.
3. MOSTRAR
Se muestra un texto con la nota del respectivo bimestre y materia del
alumno
Excepción Alumno no esté inscrito.
48 | P á g i n a
Caso de uso: Gestionar Apoderado
uc CU11: Gestionar Apoderado

CU11 Gestionar
Apoderado
Apoderado Secretaria
Nombre de Caso
de Uso
CU11 Gestionar Apoderado
Recabar los requisitos personales necesarios del Tutor para el manejo
Propósito
eficiente de información.
El tutor es la persona que está a cargo o se hace responsable del alumno.
Descripción
Éste podrá ver las notas de un alumno.
Actores Secretaria, apoderado
Actor Iniciador Apoderado
Precondición Inscribir Alumno
PostCondicion Ninguna
1. Gestionar Datos Tutor
1.1 Registrar Datos
Esta opción permite introducir los datos de la nueva persona
apoderada rellenando las siguientes casillas:
Nombres
Carnet Identidad
Teléfono
Parentesco
1.2 Guardar
Seleccione guardar para registrar los datos del apoderado.
Flujo principal
1.3 Cancelar
Seleccione cancelar para Terminar o cancelar la operación
y retornar al formulario anterior.
1. Modificar Apoderado
1.1 Se introduce el CI del apoderado en el campo “carnet de
identidad” y se procede a ‘buscar tutor’, esta acción rellenara los
siguientes campos: Nombres, Carnet Identidad, Teléfono,
Parentesco.
1.2 Modificar
Se selecciona modificar para guardar los cambios realizados en
el apoderado.
49 | P á g i n a
1.3 Cancelar
Seleccione cancelar para Terminar o cancelar la operación
y retornar al formulario anterior.
Excepción Ninguna
Caso de uso: Administrar Alumno

uc CU12: Administrar Alumno
CU12 Administrar
Alumno
Administrador Sistemas
Secretaria
Nombre de
Caso de Uso
CU12 ADMINISTRAR ALUMNO
Registra, Modifica y en algunos casos elimina datos de un alumno dentro del
Propósito
sistema
Actores Secretaria, Administrador de Sistema
Actor
Administrador del Sistema
Iniciador
Precondición Inscribir Alumno

1. EDITAR ALUMNO
Se Procede a buscar al alumno con su código si este se encuentra entonces se
muestran sus datos disponibles a editar y se procede a realizar dicha acción.
1.1 Editar Alumno
Selecciona la opción de guardar los nuevos datos modificados
Del alumno.
2. ELIMINAR ALUMNO
Se Procede a buscar al alumno con su código si este se encuentra entonces
podrá hacer la eliminación lógica del alumno en el sistema
2.1 Eliminar
Flujo de
Para confirmar y proceder a la eliminación del Alumno del sistema.
trabajo
aceptar
1.1 El alumno no está inscrito en la presente gestión o no esté inscrito como

Excepciones
alumno
5.3. Subsistemas Identificados

50 | P á g i n a
Paquete Gestión Académica:
Descripción: Este paquete Gestiona la Información necesaria
para el inicio de una Gestión académica. En este se podrá
Administrar la Gestión Académica, Administrar Curso, Gestionar
Materia y Gestionar Profesor.
Paquete Filiación:
Descripción: En este paquete se registrará la información
necesaria para inscribir tanto a los postulantes a ser alumnos del
colegio, como a los que actualmente ya son alumnos, tomando en
cuenta los cupos disponibles dentro del centro educativo.
Paquete Notas:
Descripción: En este paquete se registrará la información
necesaria para Gestionar la Nota de los alumnos, como gestionar
nota, generar boletín y generar libreta.
51 | P á g i n a
VISTA DE CADA PAQUETE
uc Filiacion
CU5 Verificar Cupo
CU13 Administrar
Postulante
Paq Filiacion
CU12 Administrar
Alumno
52 | P á g i n a
uc Notas
CU8 Gestionar Nota
Notas CU9 Generar Boletin
uc Actores
CU15 Registrar Grupo
Adm. de Usuario
CU2 Gestionar Login
53 | P á g i n a
ENCAPSULAMIENTO
uc Gestion Academica
Gestion Academica
CU3 Administrar CU4 Gestionar

Curso Materia
CU1 Administrar
Gestion
Director
CU6 Gestionar
Profesor
Administrador
Profesor
54 | P á g i n a
uc Paquete Notas
Notas
CU8 Gestionar Nota

CU9 Generar Boletin
Administrativo
Alumno
Profesor
Apoderado
uc Paq. Admi Usuario
Adm Usuario
CU2 Gestionar Login
Administrador
55 | P á g i n a
5.3.1.Arquitectura de despliegue
Estos diagramas se utilizarán para modelar la vista de despliegue estática en un sistema. La

mayoría de los casos, esto implica modelar la parte de hardware sobre el que se ejecuta el
sistema.
5.3.2.Tipo de aplicación
En este tipo de aplicación vamos a ocupar la arquitectura (diag. de componentes)

se hace una breve descripción de los distintos componentes que forman parte de la solución en
general.
• La carpeta CLASES: Permite hacer la conexión al motor de base de datos de MySQL, dentro
de esta biblioteca se encuentra la clase llamada clsConexion.inc.php, en esta clase están definidos
los métodos principales para las operaciones al momento de manipular datos en la base de datos,
estos métodos son: conectar, desconectar, consultar, etc., también se encuentra el script de inicio
y cierre de Sesión para Cliente y Empleados.
• La carpeta IMG e IMGINSCRIPCION: Encontramos todas las imágenes usadas en el sistema.
• La carpeta INICIO: encontramos las diferentes barras de navegación incluyendo el pie de
página también la página principal del sistema (index.php).
• La carpeta MODALS: se encuentra los módulos de Ayuda, detalle de los pedidos del cliente,
información de productos y el módulo de Ubicación.
• La carpeta SECCIONES: Encontramos el detalle de los diferentes pedidos vistos desde la
Cocina y la factura de los pedidos.
• La carpeta VISTAS: Se encuentra los diferentes formularios de interacción con el profesor y los
alumnos (Login, Perfil, Historial de pedidos, Mapa etc.).
• En el Archivo “PizzeriaBG.sql” encontramos el script de la base de datos.
56 | P á g i n a
5.3.3. Tipo de conexión
Arquitectura de la solución basada en la tecnología .NET

La programación por capas es un estilo de programación en la que le objetivo primordial es la
separación de la lógica de negocios de la lógica de diseño, un ejemplo básico de esto es separar la
capa de datos de la de presentación al usuario.
6. ESTIMACION DE RECURSOS
6.1. Métricas
Es cualquier medida o conjunto de medidas destinadas a conocer o estimar el tamaño u otra

característica de un software o un sistema de información, generalmente para realizar comparativas o
para la planificación de proyectos de desarrollo.
Las métricas a usar para la estimación de recursos se basarán en dos enfoques diferentes para tener
una visión más certera del tamaño y complejidad del sistema, las métricas basadas en el tamaño y las
métricas basadas en la función.
Debido al mercado laboral actual, a la arquitectura y tipo de aplicación (además de las restricciones
definidas), las métricas deben estar en el dominio de las tecnologías php.
6.1.1. Orientadas al tamaño (MOT1)
Son medidas indirectas del software y del proceso por el cual se desarrolla. En lugar de calcularlas
las LDC, las métricas orientadas a la función se centran en la funcionalidad o utilidad del programa.
Las métricas orientadas a la función fueron el principio propuestas por Albercht quien sugirió un
acercamiento a la medida de la productividad denominado método del punto de función. Los puntos
de función que obtienen utilizando una función empírica basando en medidas cuantitativas del
dominio de información del software y valoraciones subjetivos de la complejidad del software.
57 | P á g i n a
REGISTRAR ALUMNOS
Cuenta b Cuenta m Cuenta a

Entradas 2 0 0
Salidas 0 0 0
Consultas 3 0 0
Archivos Internos 1 0 0
Archivos Externos 0 0 0
REGISTRAR INSCRIPCION

Entradas 1 0 0
Salidas 1 0 0
Consultas 4 0 0
REGISTRAR MATERIA

Entradas 0 2 0
Salidas 0 0 0
Consultas 3 0 0
REGISTRAR DOCENTE

Entradas 0 1 0
Salidas 0 0 0
Consultas 1 0 0
58 | P á g i n a
REGISTRAR SECRETARIA

Entradas 0 1 0
Salidas 0 0 0
Consultas 0 0 0
REGISTRAR PAGO DE MENSUALIDAD

Entradas 0 1 0
Salidas 1 0 0
Consultas 0 2 0

Entradas 3 5 0
Salidas 2 0 0
Consultas 11 2 0
PUNTOS DE FUNCION SIN AJUSTAR
SIMPLE MEDIA COMPLEJA TOTAL

Cantidad peso Cantidad peso cantidad peso
Entradas 3 3 5 4 0 6 29
Salidas 2 4 0 5 0 7 8
Consultas 11 3 2 4 0 6 41
Archivos 5 7 0 10 0 15 35
internos
Archivos 0 5 0 7 0 10 0
externos
113
59 | P á g i n a
N° de
N° de factor valor 0…5
factor
1 Comunicación de Datos 5
2 Proceso Distribuido 3
3 Objetivos de rendimientos 5
4 Configuración de operacional Compartida 2
5 Tasa de Transacciones 4
6 Entrada de Datos en Línea 5
7 Eficiencia con el Usuario Final 3
8 Actualizaciones en Linea 0
9 Lógica de Proceso Interno Compleja 1
10 Reusabilidad del Código 2
11 Conversión e Instalación Contempladas 3
12 Facilidad de Operación 4
13 Instalación Múltiples 0
14 Facilidad de Cambios 3
Ajuste de complejidad Tecnicas (ACT) 40
FA 40
PFSA*(0.65+(0.01*fa)) 0.65
PFA 113*(0.65+(0.01*40)) 0.01
PFA 118.65
6.2. Estimaciones
A partir de las métricas anteriores hemos deducido los siguientes datos:

Tamaño esperado en KLDC:
Modelo empíricos
Esfuerzo calculado en base a MOT:
𝐸 = 5,2 ∗ 𝐾𝐿𝐷𝐶0,91 =< 𝐸𝑚𝑜𝑡 >4
Esfuerzo calculado en base a MOF:

𝐸 = −13,39 + 0,0545 ∗ 𝑃𝐹 =< 𝐸𝑚𝑜𝑓 >5
60 | P á g i n a
6.2.1 Modelo COCOMO
Proyecto de ab bb cb db
software
Orgánico 2,4 1,05 2,5 0,38
Semi-acoplado 3,0 1,12 2,5 0,35

Empotrado 3,6 1,20 2,5 0,32
6.2.2 Análisis de las estimaciones
factores de costos
atributos valor
extra
muy bajo bajo nominal Alto muy alto alto
atributos de software
fiabialidad 1
tamaño de base de datos 1
complejidad 1,15
atributos de hardware
restricciones de tiempo de
ejecucion 1
restricciones de memoria
virtual 1,06
volatilidad de la maquina
virtual 1
tiempo de respuesta 1
atributos de personal
capacidad de analisis 1
experiencia en la aplicación 1
calidad de los
programadores 1
experiencia en la maquina
virtual 1,1
experiencia en el lenguaje 1
atributos del proyecto
61 | P á g i n a
tecnicas actualizadas de
programacion 1,24
utilizacion de herramientas
de software 1
restricciones de tiempo de
desarrollo 1,04
CONVIRTIENDO DE LOC A TOTAL

KLOC PFA CORRELACION LOC KLOC
KLOC = PFA *
Correlación/LOC 118.65 51 1000 5.387
COCOMO BASICO
tipo de
proyecto a b c d
Organico 2.4 1,05 3.0 0,38
Semiacoplado 3 1,12 3.0 0,35
Empotrado 3,6 1,2 3.0 0,32
FORMULA a KLOC ^b Total

30,00763060 hombre-
E = a * KLOC^b 2,4 5.387 1,05 mes
formula c e ^d Total
D = c * E^d 2,5 30 0,38 9.10429010764 meses
Formula E D total
3
N=E/D 30 9 personas
tipo de
proyecto a b
Organico 3.2 1.05
Semiacoplado 3.0 1.12
Empotrado 2.8 1.20
7. ANALISIS Y MANEJO DE RIESGOS
62 | P á g i n a
Una vez estimados los valores probables del proyecto: tamaño, esfuerzo necesario y
duración. Además de los datos empíricos, se debe sacar una conclusión usando el criterio
personal y la experiencia. En este caso se tomarán los valores más altos, ya que su variación
con respecto al valor mínimo no es exuberante.
Estimaciones resultantes:
DURACION =9 MESES.
Descomposición en tareas (WBS)
Work Breakdown Structure (WBS).
Método de representar de forma jerárquica los componentes de un proceso para la
gestión de notas e inscripción.
UE FE Y ALEGRIA "VIRGEN
DE COTOCA"
1 (Inicio) 2 (Elaboracion) 3 (Construccion) 4 (Transicion) 5 (Prueba)
1.1 IDENTIFICAR LOS

EQUIPOS 5.2 PRUEBA MODULO
2.1 ANALISIS DEL 3.1 DISEÑO DEL 4.1 IMPLEMENTACION
PARA GESTIONAR
SOFTWARE SOFTWARE MODULO INSCRIPSION
Inscripsion
1.2 ANALIZAR
3.2 DISEÑO DEL
2.2 DISEÑO DE LA BASE 4.2 IMPLEMENTACION 5.3 PRUEBA MODULO
FORMULARIO
DE DATOS MODULO DE Notas PARA GESTIONAR Notas
inscripsion
1.3 LEVANTAR
REQUISITOS
3.3 DISEÑO DEL
FORMULARIO de notas
1.4 ESTIMACIONES
Representación en lista (WBS)

0. UE FE Y ALEGRIA “VIRGEN DE COTOCA”
63 | P á g i n a
1. (Inicio)
1.1. Identificar equipos
1.2. Analizar
1.3. Levantar requisitos
1.4. Estimaciones
2.0 (Elaboración)
2.1. Análisis del software
2.2 Diseño de la base de datos
3. (Construcción)
3.1 Diseño del Software
3.2 Diseño del formulario inscripción
3.3 Diseño del formulario de notas
4. (Transición)
4.1. Implementación del módulo de Inscripción
4.2. Implementación del módulo de notas
5.0. Prueba
5.1. Prueba del módulo de Inscripción
5.2. Prueba del módulo de Notas
7.1. Valoración
Especificación de tarea
Número: 1.1.
Nombre: Identificar los equipos
Descripción: se identificará al equipo que ira hacer el estudio para recaudar la
información de la unidad educativa FE Y ALEGRIA.
Esfuerzo Estimado: 2 semanas/hombre
Entregables:
Número: 1.2
Nombre: Analizar.
Descripción: Se analizará el colegio para hacer el levantamiento de requisitos
Entregables:
64 | P á g i n a
Número: 1.3.
Nombre: levantar Requisitos.
Descripción: se hará una lista de requisitos funcionales.
Entregables:
Número: 1.4
Nombre: Identificar las prioridades del Cliente
Descripción: El cliente presenta al equipo la lista de requisitos priorizada del
producto o proyecto, pone nombre a la meta de la iteración
Entregables: Estructura de implementación de la B.D.
Número: 2.1.
Nombre: análisis del software
Descripción: se analizará el software para la búsqueda de errores o defectos
encontrados por el cliente.
65 | P á g i n a
Número: 2.2.
Nombre: diseño de la base de datos
Descripción: Se diseñará la base de datos, partiendo del modelo entidad-
relación propuesto en el análisis y con el objetivo de tener un sistema
funcionando sobre DB2.
Número: 3.1.
Nombre: Diseño Del Software.
Descripción: Se diseñará el software que sea de mucha confiabilidad hacia el
cliente.
Número: 3.2.
Nombre: Diseño del formulario de Inscripción
Descripción: Se diseñara el formulario de Inscripción de los alumnos para que
el docente registre en la gestión y curso correspondiente
66 | P á g i n a
Número: 3.3.
Nombre: Diseño del formulario de Notas
Descripción: Se diseñará el formulario de Notas de los alumnos para que el
docente registre la nota del alumno en la materia correspondiente.
Número: 4.1.
Nombre: Implementación del módulo de Inscripción
Descripción: En el módulo de inscripción se hará la transición que el encargado
administrativo inscribirá al alumno
Número: 4.2.
Nombre: Implementación del módulo de Notas
Descripción: En el módulo de notas se hará la transición que el sistema genere
las notas de acuerdo a la materia y al curso que se encuentra inscrito
67 | P á g i n a
Número: 5.2.
Nombre: Prueba módulo de inscripción.
Descripción: Se probará el módulo de inscripción de acuerdo con lo establecido
si es alumno nuevo o antiguo
Número: 5.3.
Nombre: Prueba módulo de notas.
Descripción: Se probará el módulo de notas de acuerdo a la materia y al curso
inscrito
7.2. Plan de aversión
El plan de aversión muestra los riesgos, su impacto y sus tareas preventivas y reactivas.
ID RIESGO EXPRESION
RI-01 Que existan frecuentes media
cambios de los requerimientos
por parte de los alumnos
RI-02 No tiene experiencia en media
proyectos anteriores de
similares características
RI-03 No tiene Tiempo para una Alta
especificación formal de los
requerimientos
RI-04 No entiende el ciclo de vida de Media
producto.
RI-05 Están los gestores y Baja

desarrolladores formados
RI-06 Existen plantillas y modelos media

para todos los documentos
resultado del proceso
68 | P á g i n a
RI-07 Se aplican revisiones técnicas Media
de la especificación de
requerimientos diseño y
codificación
RI-08 Se aplican revisiones técnicas Alta
de los procedimientos de
revisión y prueba
RI-09 Hay algunos mecanismos Media
para asegurar que un proceso
de desarrollo sigue los
estándares
RI-10 Hay mecanismos para Alta
controlar los cambios en los
requerimientos que tienen
impacto en el software 1
RI-11 Se usan métodos específicos Media
para análisis de software
RI-12 Está el 90% del código en Media

lenguajes de alto nivel
RI-13 Hay estándares de media

documentación de código
8. GESTION DEL PROCESO

8.1. Recursos
Los recursos se calcularán en base a las estimaciones previas, dado que las estimaciones
especifican variables específicas se usarán variables indirectas para obtener los demás
valores. Para la distribución de personal se utilizará el criterio de distribución de trabajo
multi-tarea por persona (Braude, 2000).
8.1.1.Recursos Humanos
NOMBRE DESCRIPCIÓN CANTIDAD

Gerencia y Personal encargado de velar por el progreso constante
administración del proyecto.
Gestor/líder de proyecto Encargado del proyecto en la parte contratista. 1
Gestiona, coordina, planifica y resuelve problemas
dentro del equipo.
Secretaria Encargada de facilitar tareas administrativas y asuntos 1
varios.
Desarrollo
Desarrolladores senior Encargados del proceso de desarrollo y líderes de 2
equipo, cumplen múltiples funciones dentro del
proyecto: arquitectos, expertos en pruebas, gestores de
calidad.
69 | P á g i n a
Desarrolladores (medios, Encargados del desarrollo de la aplicación, 7
junior) coordinados por los líderes de equipo.
Diseñadores Encargados del diseño de interfaces de usuario para la 2
aplicación.
Sistemas y redes Expertos en redes y telecomunicaciones, encargados 1
de la instalación, configuración y mantenimiento de
todo equipo de hardware.
Total 16
8.2. Estimaciones del proyecto

El costo total del proyecto requiere un sumario de todos los factores previamente listados:
estimaciones, métricas, cálculo de recursos. A continuación, se especifica el costo esperado
del proyecto en base a todos los factores mencionados.
8.2.1.Análisis de costos
Primero se debe tabular el costo del personal en sueldos, tomando en cuenta la base media
nacional y el promedio de sueldos proveídos por el INE (INE, 2010). Además, se debe
tomar en cuenta que no todo el equipo trabaja durante el tiempo de vida del proyecto,
algunos miembros trabajan durante ciertas fases.
Cargo Factor Sueldo(bs) Monto Tiempo Monto

Mensual(bs) Empleado Total
Secretaria 250 250 4 1000
Gestor de 2000 2000 8 16000
Proyecto
Desarrollador 1200 4800 8 38400
Senior
Desarrollador 500 7000 8 56000
Diseñador 700 1400 8 11200
Experto en 1300 3900 3 11700
Redes
Total por mes
Total 134300
70 | P á g i n a
71 | P á g i n a
72 | P á g i n a
73 | P á g i n a

Plan de Desarrollo Final

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Plan de Desarrollo Final

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD AUTONOMA

GABRIEL RENE MORENO

SOFTWARE WEB PARA GESTIONAR EL PAGO DE MENSUALIDADES

PRESENTADO POR: CARLOS EDUARDO FERNANDEZ PARADA

SAUL VILLARROEL ROJAS

ERWIN ELIAS BONIFACIO

2. VISTA GENERAL DEL PROYECTO 6

2.1. OBJETIVO GENERAL 6

3. ORGANIZACIÓN DEL PROYECTO 17

3.1. ORGANIZACIÓN INTERNA 18

4.1. MÉTODOS HERRAMIENTAS Y TÉCNICAS 21

5.1. DOMINIO DE LA APLICACIÓN 28

7. ANALISIS Y MANEJO DE RIESGOS 63

8. GESTION DEL PROCESO 69

Fe y Alegría es un Movimiento de Educación Popular y Promoción Social. Nació en un barrio

Su llegada a Bolivia fue el 9 de mayo de 1966, se pusieron en marcha a la vez 7 unidades

Departamento: Santa Cruz

Provincia: Obispo Santisteban

-La unidad educativa no puede brindarnos información inmediata de los rankings

1.3. Situación problemática

2. VISTA GENERAL DEL PROYECTO

2.1. Objetivo General

2.2. Objetivos específicos

Nro. NOMBRE DEL COMO PROBARLO DEPARTAMENTO

RF 04 Gestionar Materias Gestionar la materia según el Académica

RF 05 Verificar Cupo Verificar el cupo Académica

RF 09 Generar Boletín Genera un boletín para un Académica

RF 11 Gestionar Apoderado Esta opción permite Académica

RF 12 Administrar Alumno Registra, Modifica y en Académica

Nro. NOMBRE DEL COMO PROBARLO DEPARTAMENTO

Req05 Registrar Materias El sistema permitirá registrar Administración

4- Eficiencia: el software debe ser eficiente en cuanto al uso de recursos de la computadora

2.4. Fundamentos de la metodología

Características del PUDS

Para el desarrollo del presente proyecto, se utiliza el Proceso Unificado de Desarrollo de

Dentro de cada fase se realizarán los seis: flujos de trabajo.

Ilustración 1. 1: Diagrama de Fases y Flujos Fuente: IBM RUP

• Las cuatro P en el desarrollo del software: persona, proyecto, producto, proceso

• El producto es más que código

• Un sistema posee una recolección de modelos

El Proceso Unificado proporciona un conjunto de modelos cuidadosamente seleccionando

✓ Tarjetas CRC, describiendo el comportamiento y estructura de las diferentes clases.

✓ Producto backlog, un listado completo de todas las historias de usuario o

• Releaseplanning: En esta reunión o reuniones se definen las funcionalidades a implementar

“U.E FE Y ALEGRIA -VIRGEN DE COTOCA”

Reg. de Reg. de factura

Reg. secretaria Reg. de

Reg. Paralelos Registro de Materias

El Alumno • visualizará el listado de su inscripción y los atenderá de acuerdo al orden

Uso Layouts con Blade

4.2. Documentación del producto

public function up() public function up()

class InscripcionGestion extends

public function listarAlumno(Request $request){

public function guardar(Request $request){

public function guardar2(Request $request){

public function modificar(Request $request){

public function eliminar(Request $request){

class InscripcionController extends Controller

public function guardar(Request $request){

public function desactivar(Request $request) {

public function activar(Request $request){

5.1. Dominio de la aplicación