Especificación Caso de Uso

Administración de Cursos

Descripción Breve

Permite al administrador y al profesor, llevar un registro de cada curso y de sus integrantes además de controlar en tiempo real el avance de cada curso.

Actores

1.- Actor Primario – Administrador 2.- Actor Secundario – Sistema de Gestión

Flujo de eventos

1.  Flujo Básico
1.1. Iniciar Sesión	Este caso de uso inicia cuando un usuario accede al Sistema de gestión. El administrador ingresa su ID y contraseña, el sistema valida al usuario.
1.2. Crear curso	Iniciará un curso, para un determinado año, con los datos correspondientes y un profesor asignado.
1.3. Ingresar alumnos	En este caso el docente ingresa los alumnos que conformaran el curso, además de asignarle.
1.4. Guardar y enviar cambios en el curso	El usuario guarda el curso y el sistema lo valida.

2.  Flujos Alternativos
2.1. El usuario no puede ingresar al sistema	El sistema de gestión no reconoce al usuario y su password, en ese caso el docente debe solicitar al encargado de UTP su información.
2.2. El docente no puede ingresar al curso.	El sistema de gestión, no le permite al profesor visualizar la información de     un determinado curso, en este caso el docente debe solicitar que se le agregue dicho curso al encargado de UTP.
2.3. El administrador no puede crear un curso.	El sistema de gestión, no le permite al administrador modificar la información de un determinado curso, en este caso el docente debe solicitar que se le otorguen los permisos al encargado de UTP.

Especificación Caso de Uso

Administración de asignaturas

Descripción Breve

Permite al administrador y al profesor, llevar un registro de cada asignatura por curso y de sus integrantes además de controlar en tiempo real el avance de cada asignatura.

Actores

1.- Actor Primario – Docente 2.- Actor Secundario – Sistema de Gestión

Flujo de eventos

1.  Flujo Básico
1.1. Iniciar sesión.	Este caso de uso inicia cuando el encargado ingresa al Sistema de gestión. El   encargado ingresa su ID y contraseña, el sistema lo valida.
1.2. Crear asignatura.	El sistema le solicitara al profesor del ramo, crear la asignatura, con sus respectivos datos.
1.3. Ingresar calificaciones.	El profesor deberá crear una evaluación, en la cual deje claro que se evalúa y en qué fecha.
1.4. Editar asignatura.	Este caso de uso permite al docente modificar tanto los datos de la asignatura como las calificaciones.
1.5. Guardar asignatura.	El profesor del ramo deberá guardar los cambios ingresados a la asignatura, una vez haya concluido de ingresar o modificar dicha información.

2.  Flujos Alternativos
2.1. El usuario no puede ingresar al sistema	El sistema de gestión no reconoce al usuario y su password, en ese caso el docente debe solicitar al encargado de UTP su información.
2.2. El docente no puede ingresar a la asignatura.	El sistema de gestión, no le permite al profesor visualizar la información de     un determinado curso, en este caso el docente debe solicitar que se le agregue dicho curso al encargado de UTP.
2.3. El administrador no puede crear la asignatura.	El sistema de gestión, no le permite al administrador modificar la información de un determinado curso, en este caso el docente debe solicitar que se le otorguen los permisos al encargado de UTP.

Casos de uso planificacion anual

Especificación de Caso de Uso- Ingresar contenidos por profesor

Descripción Breve

Este caso de uso permite al docente ingresar las materias que se verán durante el año escolar, permite especificar también por semestre o trimestre el grupo de materia que este impartirá.

También es posible ingresar las fechas de pruebas y sus respectivos contenidos, relacionados con los que el docente haya ingresado.

Actores

1.- Actor Primario – Docente.

2.- Actor Secundario – Sistema de gestión.

Flujo de Eventos

1. FlujoBásico

1.1 Iniciar sesión docente

Este caso de uso inicia cuando un docente accede al Sistema de gestion. El docente ingresa su ID y contraseña, el sistema valida al docente.

1.2 Selecciona de curso y ramo

Después de identificarse el docente debe seleccionar la asignatura que imparte y los cursos que le corresponde en colegio.

1.3 Ingresar contenidos

En este caso el docente ingresa los contenidos que realizara durante el año (semestral o trimestral).

1.4 Ingreso de fecha evaluaciones

Ingreso de las respectivas fechas y las materias que abarcaran esas evaluaciones (controles, trabajos y pruebas).

1.4Guardar y enviar planificación anual

     El docente guarda la planificación y el sistema lo valida.

2. Flujo alternativo

2.1El docente no puede ingresar.

El sistema de gestión no reconoce al usuario y su password, en ese caso el

docente debe solicitar al encargado de UTP su información.

2.2El docente no puede ingresar el curso.

El sistema de gestión, no le permite al profesor visualizar la información de     un determinado curso, en este caso el docente debe solicitar que se le agregue dicho curso al encargado de UTP.

2.3El docente no puede ingresar asignatura.

      El sistema de gestión, no le permite al profesor modificar la información de una determinada asignatura, en este caso el docente debe solicitar que se le otorguen los permisos al encargado de UTP.

2.3El docente no puede ingresar fechas.

      El sistema de gestión, no le permite al profesor ingresar información de las próximas evaluaciones de una asignatura, en este caso el docente debe solicitar que se le agregue dicho permiso al encargado de UTP.

Especificación de Caso de Uso- Validar contenidos anuales

Descripción Breve

Este caso de uso se controla y se validan los contenidos establecidos por el docente el cual son revisados por el encargado de UTP.

Actores

1.- Actor Primario – Encargado de UTP.

2.- Actor Secundario – Sistema de gestión.

Flujo de Eventos

1. Flujo Básico

1.1Iniciar sesión encargado de UTP

Este caso de uso inicia cuando el encargado ingresa al Sistema de gestión. El   encargado ingresa su ID y contraseña, el sistema valida al docente.

1.2 Solicita planificación del profesor

    El sistema le solicitara al profesor del ramo, ingresar la planificación anual como una forma de llevar un registro de lo que se está enseñando en dicha asignatura.

1.3 Validar planificación

    El encargado de UTP, deberá revisar y validar o rechazar la planificación que ingreso el profesor al sistema, y solicitar su modificación de ser necesario.

1.3 Guardar planificación

    El profesor de la asignatura deberá guardar los cambios ingresados a la planificación, una vez haya concluido de ingresar o modificar dicha información.

2. Flujo alternativo

2.1 no acepta planificación

    El profesor del ramo, deberá corregir la planificación del ramo, según se lo haya informado el encargado de UTP.

Especificación de Caso de Uso- Modificar contenidos por profesor

Descripción Breve

Este caso de uso permite al docente modificar tanto la planificación anual semanal o trimestral.

Actores

1.- Actor Primario – Docente.

2.- Actor Secundario – Sistema de gestión.

Flujo de Eventos

1. Flujo Básico

1.1.        Iniciar sesión docente

Este caso de uso inicia cuando un docente accede al Sistema de gestion. El     docente ingresa su ID y contraseña, el sistema valida al docente.

Diseño guiado por el dominio

INTRODUCCIÓN

Hoy en día, la complejida del desarrollo de software es una realidad, por lo que es necesario contar con herramientas que ayuden a los procesos mas importantes de la creación de algún tipo de aplicación, es por esto que en el siguiente informe se hablara de DDD( Diseño guiado por el dominio) que es un enfoque para el desarrollo de software.

Domain-driven design (Diseño guiado por el dominio)

Es un enfoque para el desarrollo de software con necesidades complejas, mediante una profunda conexión entre la implementación y los conceptos del modelo y núcleo del negocio, al referirse al dominio se refiere al negocio, por lo tanto es importante conocer muy bien el negocio al cual se dirige el software que se desarrollara.

Domain-Driven Design no es una tecnología o una metodología. Es una manera de pensar y de un conjunto de prioridades, encaminadas a acelerar los proyectos de software que tienen que ver con los dominios complicado.

Para lograr ese objetivo, los equipos necesitan un amplio conjunto de prácticas de diseño, técnicas y principios. La refinación y la aplicación de estas técnicas será objeto de discusión para este sitio, por lo general a partir del lenguaje de los patrones establecidos en Domain-Driven Design .

Cuando la complejidad va de las manos, el software no puede ser entendido lo suficientemente bien como para ser fácilmente modificado o ampliado. Por el contrario, un buen diseño puede hacer que las oportunidades de las características complejas, la complejidad más importante de muchas aplicaciones no es técnico. Es en el dominio de sí mismo, la actividad o negocio del usuario. Cuando esta complejidad de dominio no se trata en el diseño, no importa que la tecnología de infraestructura está bien concebido. Un diseño exitoso de manera sistemática debe hacer frente a este aspecto central del programa.

El diseño del dominop propone una arquitectura, el cual nos muestra que, por lo menos, vamos a contar con una capa de dominio, una capa de infraestructura, una capa de aplicación y algún cliente o interfaz de usuario que consuma esa aplicación. Los nombres de las capas en las diferentes arquitecturas pueden variar, alguna capa puede estar o no estar, o se puede dividir en dos o más, pero lo importante es que nunca puede faltar la capa de Dominio o de Negocio. Esta capa se debe aislar del resto de las capas del sistema. Esta capa será la expresión final del negocio, la implementación limpia de un modelo guiado por el dominio. Domain-Driven Design requiere sólo la capa de negocio para existir. Los objetos de dominio deben quedar libres de la responsabilidad de mostrarse, guardarse y/o responder a tareas de la aplicación, para poder enfocarse en expresar el modelo de dominio.

Algunos de los pilares de DDD son:

·         Potenciar la colaboración con los interesados y expertos del dominio. Todo el mundo tiene que ayudar a definir el modelo (el modelo es la representación del dominio, el modelo son los elementos del dominio y sus relaciones).

·         Tiene que existir un leguaje ubícuo, es decir, tiene que haber un mismo lenguaje que esté en todas partes, tanto en los expertos del dominio, como en los técnicos, como en el modelo, como en el código

·         Cualquier programador, analista o lider de proyecto tiene que participar.

·         Cuando alguien codifica tambien participa en el modelo. El código es la implementación del modelo, pero es todo lo mismo. No tiene sentido definir un modelo y luego implementar otra cosa, en tal caso el modelo ha perdido todo su valor y hemos perdido el tiempo.

·         Como el código es el modelo, si cambiamos código habrá que avisar a los interesados y expertos del dominio.

Algunos conceptos definidos por DDD:

·         Entidad: Es un objeto que tiene un identificador único en el contexto que se este tratando. 

·         Value Object: Es un objeto que tiene atributos, pero no tiene identificador en el contexto. Pueden tener comportamiento y suelen ser inmutables. Sirven para describir cosas.

·         Servicio: Son los verbos del lenguaje ubícuo. Un servicio aparece cuando tenemos una funcionalidad que no pertenece a ningún objeto del dominio, en tal caso creamos un nuevo objeto que no es del dominio y que tendrá la responsabilidad de realizar esta funcionalidad. Esto es el patrón Fabricación Pura de GRASP. No tienen estado. Tienen que tener poco código, si hay mucho es que no se está haciendo bien la Orientación a Objetos. Normalmente se limitan a “sincronizar” operaciones entre varios objetos del dominio.

·         Agregado: Es una composición de objetos. Tiene una raíz que es una entidad. Lo normal es no poder acceder al contenido del Agregado, y todas las operaciones que se quieran hacer sobre el contenido siempre se harán a través de la entidad raíz.

·         Factoría: Crea objetos complejos (en muchos casos agregados). Crea objetos válidos (no devolverá nulos). Se parece mucho a los distintos patrones de creación de GOF.

·         Repositorio: Básicamente es el patrón DAO. Persiste entidades y agregados, no Value Objects (Los Value Object se persisten al persistir el Agregado correspondiente). La interfaz está en el dominio pero la implementación esta en la capa de infraestructura. Es muy importante el ver como en DDD hay que ser muy consciente de que los objetos es necesario guardarlos en algún sitio, y por ello la interfaz del repositorio está dentro del dominio.

·         Módulos: Paquetes, namespaces, ... Lo importante es que tienen que formar parte del lenguaje ubícuo (agrupación lógica). Es decir no tiene sentido hacer un módulo con todas las entidades, otro módulo con todos los repositorios, ...

·         Modelos anémicos. DDD no habla expresamente de modelos anémicos, pero sí lo hace de modelos “ricos” que sería el opuesto. Lo que está claro es que DDD intenta centrarse en el modelo de dominio para precisamente crear modelos ricos y evitar los modelos anémicos.

Conclusión

DDD no es una método, ni una técnica, ni una tecnología. Podríamos decir que es simplemente un conjunto de buenas prácticas especialmente pensadas para lidiar con dominios complejos o múltiples dominios, de forma que estas prácticas nos guíen en la toma de decisiones para elaborar nuestro diseño.

Acta de constitución de Proyecto 

Información general.-

Nombre del Proyecto: Creación de software para gestión de colegio Pedro Aguirre Cerda.
Fecha de inicio: marzo 2013
Fecha termino: junio 2013

Necesidades del proyecto.-

1. Sistema de registro de matrícula anual
2. Ficha personal del alumno y del profesor
3. Sistema de control de planificaciones clase a clase por profesor, asignatura y curso.
4. Sistema de control de asistencia por alumno.
5. Sistema de registro de entrevistas con apoderados.

Objetivos del Proyecto

·         Facilitar el uso de los sistemas de información del colegio
·         Mejorar  la gestión de la toma de información de alumnos
·         Crear una base de datos con los datos de alumnos y funcionarios del colegio

Alcance del proyecto

·         Elaborar Plan de gestión del proyecto
·         Utilizar un framework en común con todos los grupos del curso
·         Una vez creado todos los requerimientos por los grupos del curso, unir todos los programas en un solo software el cual será gestionado por una persona capacitada para administrar el software.
·         El software debe cubrir distintas áreas del colegio.

Descripción del producto

El proyecto comprende la construcción de un software el cual ayudará a la gestión de los sistemas de información del colegio y la administración de las distintas áreas del colegio como son el sistema de libro de clases, Planificación anual, Fichas por alumno, Fichas por trabajador, administración de colaciones.
El software será creado en un framework común en los grupos con el fin de la unión de los distintos requerimientos en un solo software, para la entrega al colegio y la posterior capacitación para un encargado del área de computación e informática del colegio.

Fechas del proyecto

·         Inicio: 28 de marzo del 2013
·         Finalización: Final de semestre académico.

Restricciones del proyecto

·         Utilización de un solo firmware
·         No hay un cobro por parte de los desarrolladores del producto hacia el cliente.
·         Tiempo: lo que dura el semestre académico de los alumnos de la Universidad Central

Suposiciones del proyecto

·         El software debiera estar terminado a fines de semestre
·         El colegio implementará el software

Criterios de adaptación

El proyecto terminara cuando los software y la unión de estos estén listos, y se haga un análisis de los software comprobando la funcionalidad de estos.
Los Funcionarios del colegio se verán beneficiados por el software y a que facilitara la administración de las distintas áreas del colegio, principalmente los datos de los funcionarios y los alumnos.

School Manager

Es una solución de sistemas orientado a resolver las necesidades de información Académica y Administrativa de las instituciones Educativas.

Razones para implementarlo

•Disminuye el riesgo de fraudes en cajas y control escolar.
•Integración de la Información y confiable.
•Agilidad en Cajas de cobro.
•Control de Ingreso y Cobranza.
•Reportes académicos acorde a las necesidades del plantes.
•Mejora el servicio a los alumnos y padres de familia.
•Ahorro de tiempo y esfuerzo.
•Vanguardia tecnológica para el plantel.

Características Principales


Control de Cobranza Inventarios y Egresos

• Control de colegiaturas y otros pagos.
• Recordatorio de pagos por mail y SMS.
• Emite estados de cuenta.
• Emisión de Recibos Internos y Fiscales.

Inventarios y Egresos

• Puede manejar cuantos artículos se desee vender, comprar o controlar en inventario.
• Compatible con lectores de Código de barras, Miniprinters y cajones de dinero.
• Puede realizar comprar de artículos y clasificarlas por proveedor.
• Reporte de utilidades de ventas.

Control de Asistencia

• Para el control de Asistencia de Alumnos y Personal Administrativo-Docente.
• Asignación de permisos , días festivos y faltas Justificadas.
• Uso de Sensores de huella y código de barras para el registro de Asistencias.
• Completo Reporte de Asistencias (Dia , Semana, Período).

Control Académico

• Manejo de Planes de estudio interno y oficial.
• Expedientes de los alumnos.
• Generación de listas con calificaciones.
• Concentrado de calificaciones.

Requerimientos

•Procesador Dual Core 1.8 Ghz o Superior.
•Memoria RAM 2 GB .
•Disco duro con 10 GB libres para instalación e información.(Puede ser mas dependiendo de su Uso)
•Sistema operativo Windows® XP
Professional, Windows® Vista(Business o Ultimate), Windows® 7 (Business o Ultimate) , Windows 8 en 32 o 64 bits.
•NetFramework 3.5 sp1
•Conexión de Internet (1 MB o superior) para uso en Red

Consultas pre-requerimientos

·         Tecnología que se ocupa actualmente en el uso administrativo.

·         Que es lo que necesita

·         Cuenta con algún presupuesto para lo que necesita

·         Procesos que conllevan esos usos administrativos.

·         Tipo de usuarios y cuantos usan sistemas de administración.

·         Conocimientos tecnológicos de los usuarios.

·         Plataformas existentes (si es que hay) en el colegio.

·         Misión y visión del colegio Pedro Aguirre Cerda.

·         Que área especifica del colegio se espera ayudar con un sistema informático.

·         Que se espera lograr con el nuevo sistema informático.