Softclass horario

Sumativa 1

NOMBRE: Cristian Andrés Escobar Olguin

CARRERA: Ingeniería en informática.
ASIGNATURA: Ingeniería de Software
PROFESOR: VICTOR ALFONSO VALENZUELA RUZ
FECHA: 19-04-2022
 Introducción.
Frente a la problemática que ha sido detectada por el Centro de formación técnica mencionada
en el documento, se desarrollara un sistema que asista a los alumnos a poder decidir en que
sesión y asignaturas matricularse, tras el análisis realizado, es difícil poder encontrar una
combinación de secciones en que no haya solapamientos entre otras sesiones de las diferentes
asignaturas del CFT.
Para el comienzo del desarrollo de esta actividad se procederá a definir los alcances del
proyecto, objetivos, análisis de factibilidades, el estudio de los requerimientos y finalmente un
plan de mantención.
A continuación se analizarán con detalles los puntos establecidos para el desarrollo y entrega de
la actividad.

 Desarrollo
1. Descripción del proyecto:

1.1. Alcance del proyecto.

Construir un software que ayude a los alumnos a decidir en que asignaturas y en que
sesión de estas matricularse, evitando así solapamiento en asignatura que se
superponen en el semestre seleccionado.

El sistema permitirá identificar los solapamientos en asignaturas.

El sistema no está diseñado para trabajar con sistemas externos.
El sistema será capas de mitigar los solapamientos en la sesión de clases.
El sistema permitirá al alumno matricularse en cualquier sesión de cualquier asignatura,
sin prerrequisitos.

1.2. Objetivos del proyecto.

 Aumentar la facilidad en que los alumnos puedan decidir el mejor
horario de su jornada de estudios.
 Disminuir el tiempo que deben tomar los alumnos del centro de
formación técnica en elegir las sesiones de cada asignatura.
 Evitar solapamientos entre las distintas sesiones de cada asignatura.

1
 1.2.1. Objetivo general.
Entregar una solución informática que permita cubrir una necesidad existente
actualmente en un Centro de formación técnica, en donde hay una carencia de un
sistema que apoye la gestión, agilice la toma de sesiones y permita mantener un manejo
de información detallada de forma segura y adecuada correspondiente a las distintas
actividades que se requieren cumplir en la toma de sesión de asignatura para un horario
de clases de los alumnos del CFT. Así mismo, la creación de este software pretende
agilizar, modernizar la toma de Asignatura para el semestre que se cursara.

1.2.2. Objetivos específicos.

 Capturar y priorizar los requerimientos para el sistema que se implementara.
 Analizar y organizar con detalle la información recopilada para determinar las
necesidades reales del sistema.
 Realizar pruebas y correcciones periódicas de funcionamiento, con la finalidad
de verificar que se cumpla con las expectativas deseadas.
 Realizar estudios respecto a la factibilidad del proyecto.
 Elaborar una planificación de actividades, el cual nos guiará durante el
desarrollo de esta actividad.
 Utilizar una metodología de desarrollo eficiente.

1.3. Interesados en el proyecto.

El stakeholders interesado en el proyecto es el Centro de formación técnica junto a su
comunidad de alumnos
2. Estudio de factibilidad:
2.1. Factibilidad técnica:
El Centro de formación técnica debe contar con la siguiente infraestructura IT que permite
ejecutar el software de manera ininterrumpidamente
1. Infraestructura IT:
Software:
1. Computador: Laptop o Desktop
2. Sistema Operativo: Windows 10 64bits
Hardware:
3. Procesador Intel i3 o ADM Serie Ryzen de 4 núcleo o
mas
4. Memoria ram 8GB
5. Disco duro: HDD o SSD 60GB
 6. Pantalla: Estándar 2
7. Mouse y teclado: Estándar

Periféricos:
8. Servicios de red Internet: LAN O WAN

2.2. Factibilidad operativa:

El sistema que se desarrollará permitirá automatizar el proceso de toma de asignaturas que fue
mencionado anteriormente, lo cual generará aspectos positivos que son descritos a
continuación:

El sistema presentara un diseño amigable con el usuario con el objetivo de facilitar el uso y
comprensión del sistema, esta herramienta debe ser capaz de evitar que el usuario se tome un
tiempo largo en poder aprender su operación. El sistema debe ser capaz de automatizar el
tiempo que se toma un usuario en crear su horario de clases.

La capacitación de los usuarios ayudara a evitar errores de uso durante la implementación del
software.
Los webinarios será una excelente retroalimentación a lo cual los usuarios tendrán accesos a
revisar cuantas veces quieran

2.3. Factibilidad económica.

 Costo de hardware Desktop:
Componente Especificaciones mínimas Valor
Procesador Intel celeron G5905 $47.990
Memoria Ram 4 GB $27.990
Disco duro SSD 250GB $28.000
Mouse Estándar $5.990
Teclado Estándar $7.990
Monito Full HD $54.990
Total $ $172.950 pesos Chilenos

El costo de desktop puede quedar nulo siempre y cuando el CFT ya cuente con un equipo de
escritorio disponible.
  Costo de Hardware Laptop recomendado:
o Laptop HP Elitebook 830 G5 businnes 3
o Pantalla 14”
o Intel Core I5 8ta Generaciòn
o 8 GB Memoria Ram
o 256 GB SSD
o Costo total: $422.000 pesos Chilenos

 Costo de Software:
o Sistema Operativo: Windows 10 Profesional 64 Bits 21GAC/H2
o Costo total: $9.990
El costo de software generalmente se encuentra incluido en los costos finales de un Laptop lo
cual el costo de software no debe ser tomado en cuenta en esta ocasión.

Actividad Duración (Hrs) Costo por Hora Total

Deño 36 $2.500 $90.000
Desarrollo 86 $3.100 $266.600
Implementaciòn 50 $3.000 $150.000
Pruebas 15 $2.800 $42.000
Total $548.600

 Costos finales recomendado:

Ítem Valor
Costo Hardware: Laptop $ 422.000
Costo Software: Sistema operativo $ 9.990
Costo RR. HH $ 548.600
Totales $ 980.590

2.4. Resultado del estudio.

En el estudio de factibilidad técnica se analizo y se considero que los requisitos necesarios son
tanto software como hardware.
Teniendo en cuenta que el CFT cuenta con el software y hardware disponible para realizar el
proyecto, evitando el costo asociado a ellos.
Mientras tanto en la factibilidad operativa los resultados son buenos ya que se estima trabajar
mediante un sistema de webinarios que les ayudará a obtener un feedback a cada usuario sobre
el uso del sistema y la vez también la posibilidad de capacitar al personal que usará el software.
4
El estudio de factibilidad económica es viable ya que el centro de formación técnica cuenta con
la factibilidad técnica, de todas maneras podemos recomendar el uso de un dispositivo laptop
mucho mas actualizado que a su vez cumple y sobrepasa con lo requerido por un valor de
$422.000, la mayoría de los proveedores de servicios computacionales incluyen en el costo final
el valor del sistema operativo: costo de software: Proveedor Lechner.

3. Levantamiento de requerimientos:
3.1. Planificación.
3.1.1. Descripción de técnicas a utilizar.
En este punto se utilizará la técnica de Análisis de documentación o Estudio de documentación
en la cual consiste en obtener la información sobre los requerimientos funcionales y no
funcionales
3.1.2. Involucrados en el levantamiento.
Involucrado principal: Jefe de proyecto
Sera encargado de utilizar la técnica descrita en el punto 3.1.1 la cual facilitará la documentación
de cada tipo de requerimiento necesario.
3.1.3. Planificación temporal de las actividades.
En esta etapa del proyecto vamos a describir en un listado las actividades que se realizarán para
la construcción de la solución
 Propuesta de proyecto
 Objetivo general del proyecto
 Objetivos específicos del proyecto
 Propuesta Justificación del proyecto
 Historias de usuarios
 Recopilación, especificación y selección de los requerimientos
 Estudios de factibilidades
 Realización de diagramas
 5
3.2. Análisis de requerimientos.
3.2.1. Requerimientos no funcionales.

ID requerimiento Nombre Descripción

RNF-01 Evitar solapamientos El sistema debe ser capaz
de evitar solapamientos en
las sesiones
RNF-02 Matricula en sesión sin El alumno se podrá
prerrequisitos matricula en cualquier
sesión de cualquier
asignatura
RNF-03 Sesión y profesores Cada sección tiene
asignado uno o más
profesores, un horario, y un
aula o quizá aulas distintas,
aunque en una misma
sesión ésta debe ser la
misma.
RNF-04 Sesión múltiple en Puede haber varias
asignatura secciones de cada
asignatura, dependiendo
de la estimación del
número de alumnos que se
matricularán para ésta

3.2.2. Requerimientos funcionales.

ID requerimiento Nombre Descripción
RF-01 Seleccionar asignaturas Seleccionar sesión en
donde se desea matricular
RF-02 Propuesta de combinación Mostrar propuesta de
horario que minimiza el
 solapamiento.
RF-03 Repetir proceso El alumno podrá repetir la
creación de horario

6
3.2.3. Priorización de requerimientos.
En esta etapa de la actividad proyecto, se definirán cada uno de los requerimientos identificados
en los puntos mencionados anteriormente.
El numero ayuda a identificar el orden que se crearan los requerimientos representando así el “1”
como el primero que se desarrollara y “7” el ultima que se desarrollara.
Por otro lado, se encuentra el nivel de la prioridad “Alta” representa que debe ser visto con
máxima prioridad, “Media” definirá que el requerimiento puede ser visto con mucho mas tiempo y
“Baja” quien será definido y creado durante el transcurso del proyecto, cada destacar que cada
uno de los requerimientos tienen exactamente la misma importancia.

Nombre Prioridad
Evitar solapamiento 1 - Alta
Matricula en sesión sin 3 - Alta
prerrequisitos
Sesión y profesores 4 - Media
Sesión múltiple en asignatura 7 - Baja
Seleccionar asignaturas 2 - Alta
Propuesta de combinación 5 - Alta
Repetir proceso 6 - Alta
 7
4. Diseño, pruebas y mantención:
4.1. Diagramas del sistema.
4.1.1. Caso de uso general.

4.1.2. Diagrama de funcionamiento.

 8
4.2. Descripción de pruebas.
En este punto de la actividad proyecto, se describirá cada una de las pruebas que ayuden a
identificar las funcionales que ofrece el desarrollo de las actividades proyecto.

 Se realizará la prueba de asignar sesiones de asignatura a alumnos, es decir,

agregar una sesión al horario
o Característica: funcionalidad
o Objetivo: agregar sesión de clases a alumnos sin interrupción.
o Enfoque: Caja negra
o Criterios de cumplimiento: identificar que la sesión pueda ser agregada
al horario
 Se probará que el sistema permita combinar sesión de cualquier asignatura, es
decir, asignar sesión de cualquier asignatura.
o Característica: funcionalidad
o Objetivo: Combinar sesiones de cualquier asignatura.
o Enfoque: Caja negra
o Criterios de cumplimiento: Cada alumno pueda combinar sesión de
cualquier asignatura.

 Se probará que el sistema permita definir la sesión al alumno que considere

oportunas.
 o Característica: funcionalidad
o Objetivo: Permitir al alumno elegir las sesiones que más acomoden para
su horario
o Enfoque: Caja negra
o Criterios de cumplimiento: El requerimiento planteado sea cumplido

 Se probará que el sistema permita ofrecer propuestas de combinaciones de

sesiones, permitir que
o Característica: funcionalidad
o Objetivo: Permitir al alumno elegir la propuesta creada por el sistema.
o Enfoque: Caja negra
o Criterios de cumplimiento: Permitir al alumno verificar y ver la propuesta
creada por el sistema.
 Se probará que el sistema no permite generar solapamientos
o Característica: Defecto
o Objetivo: Evitar que el sistema genere solapamientos. 9
o Enfoque: Caja negra
o Criterios de cumplimiento: permitir cumplir el requerimiento establecido.
 Se probará que el sistema no sufra caídas por ingreso de datos.
o Característica: Error
o Objetivo: Evitar caídas de sistema
o Enfoque: Caja negra
o Criterios de cumplimiento: el usuario debe ingresar o seleccionar las
sesión que necesite y luego definir en el horario.

4.3. Plan de mantención del sistema.

La elaboración del plan de mantenimiento se llevará a cabo de manera Preventiva con la opción
de poder realizar mantenciones correctivas, adaptativas y preventivas. en donde nos permitirá
definir cuales son las falencias, errores o defectos del software antes de entregar un reléase de
la versión anterior, esta etapa nos ayudará a mejorar constantemente las propiedades y los
distintos entornos del software.

Mantención correctiva:
 Será ejecutada cada vez que el usuario detecte errores o defectos en la aplicación
Tiempo de ejecución: Se realizará cada vez que el usuario comunique a través de los canales
oficiales mediante un ticket que la aplicación sufre un defecto
Una vez comprobado con el equipo especialista, se informará al desarrollador del defecto
reportado.

Tiempo real de ejecución: Una vez que el desarrollador determine los métodos, variables,
módulos, componentes afectados, tendrá 5 días hábiles para dar una solución definitiva o una
alternativa (Workaround) manteniendo la disponibilidad del sistema.

10