SISTEMA DE INFORMACION PARA EL CONTROL DE NOTAS DE LOS ESTUDIANTES SICNE PLAN DE PROYECTO SICNE

Transcripción

1 SISTEMA DE INFORMACION PARA EL CONTROL DE NOTAS DE LOS ESTUDIANTES SICNE PLAN DE PROYECTO SICNE INGENIO Soluciones Integrales 20/09/20

2 REGISTRO HISTÓRICO DEL DOCUMENTO Nombre: Plan de Proyecto Ciclo: Inicio Código Fecha Elaboró Revisó Descripción Cambio Versión 00 28/0 /20 Natalia Herrera Lili Rozo /0 /202 Natalia Herrera Metodología 2.0

3 CONTENIDOS INTRODUCCIÓN... ERROR! MARCADOR NO DEFINIDO. DESTINATARIOS... ERROR! MARCADOR NO DEFINIDO. VISIÓN... ERROR! MARCADOR NO DEFINIDO. USUARIOS E INTERESADOS... ERROR! MARCADOR NO DEFINIDO. INTERESADOS... ERROR! MARCADOR NO DEFINIDO. USUARIOS... ERROR! MARCADOR NO DEFINIDO. ALCANCE... ERROR! MARCADOR NO DEFINIDO. DESCRIPCIÓN Y CARACTERÍSTICAS DEL PRODUCTO... ERROR! MARCADOR NO DEFINIDO. Descripción general de la solución a construir... Error! Marcador no definido. Características del producto... Error! Marcador no definido. REQUERIMIENTOS DE DOCUMENTACIÓN... 6 Manual de Usuario... 6 Ayuda Online... 6 Guías de instalación y Configuración... 6 EQUIPO DE TRABAJO... 7 ADMINISTRACIÓN DEL PROYECTO... ERROR! MARCADOR NO DEFINIDO. ORGANIZACIÓN... ERROR! MARCADOR NO DEFINIDO. ADMINISTRACIÓN DE RIESGOS... ERROR! MARCADOR NO DEFINIDO. ADMINISTRACIÓN DE LA CONFIGURACIÓN... ERROR! MARCADOR NO DEFINIDO. ADMINISTRACIÓN DE LA CALIDAD... ERROR! MARCADOR NO DEFINIDO. PLAN DE TRABAJO... ERROR! MARCADOR NO DEFINIDO. METODOLOGÍA... ERROR! MARCADOR NO DEFINIDO. TECNOLOGÍA... ERROR! MARCADOR NO DEFINIDO. Lenguaje... Error! Marcador no definido. Motor de base de datos... Error! Marcador no definido. Herramientas... Error! Marcador no definido. ESTIMACIONES Y PRESUPUESTO... ERROR! MARCADOR NO DEFINIDO. CRONOGRAMA... ERROR! MARCADOR NO DEFINIDO. ENTREGABLES... ERROR! MARCADOR NO DEFINIDO. APÉNDICES... ERROR! MARCADOR NO DEFINIDO.

4 INTRODUCCION En este documento Plan de Desarrollo del Software se describe la planificación general para la ejecución de del proyecto que consiste en la implementación de un sistema de información para el Colegio Tecnológico de Villavicencio. Cada uno de los aspectos del proceso de desarrollo, que se mencionan está sujeto a revisiones a lo largo del proyecto. La metodología seleccionada es la Rational Unified Process, el presente documento sigue los parámetros de esta. Enfocándose en las características del proyecto actual y definiendo los artefactos que serán generados. Este documento es a su vez uno de los artefactos de RUP. Es importante destacar esto puesto que utilizaremos la terminología RUP en este documento. Se incluirá el detalle para las fases de Inicio y Elaboración y adicionalmente se esbozarán las fases posteriores de Construcción y Transición para dar una visión global de todo proceso. DESTINATARIOS El presente Plan de Desarrollo de Software va destinado a los siguientes usuarios: El jefe del proyecto, quien lo utiliza para organizar la agenda y necesidades de recursos, y para realizar su seguimiento. Los miembros del equipo de desarrollo, quienes lo usan para entender lo qué deben hacer, cuándo deben hacerlo y qué otras actividades dependen de ello.. VISION El objetivo de este proyecto es proporcionar un sistema ágil, eficiente y seguro para la manipulación de los datos de cada uno de los estudiantes, proporcionando un ahorro de tiempo en el desempeño actual de las tareas comunes de los docentes, y los administrativos, y a su vez asegurando su eficacia y seguridad.

5 USUARIOS E INTERESADOS INTERESADOS NOMBRE DESCRIPCION TIPO Rector de la Institución Otros Colegios Es el representante legal del colegio y cliente con el cual se firma el contrato. Es de gran conocimiento el interés que tienen los rectores de instituciones escolares en el mejoramiento de los servicios que ofrecen a sus estudiantes. Cliente Externo Administradores Son los principales usuarios que manipulan el sistema. Lili Rozo Ingeniera de Sistemas Supervisor externa del Proyecto Desarrolladores Los miembros del equipo de desarrollo del software. Usuario Externo Equipo del proyecto Natalia Herrera Gestora del proyecto y miembro del equipo de desarrollo. Gerente del proyecto ALCANCE El proyecto a desarrollar cumplirá tres tareas principales, las cuales son: ) capturar y almacenar la información relacionada al perfil de los estudiantes, 2) capturar y almacenar los cursos en los que se inscribe cada estudiante y 3) capturar y almacenar las notas de cada estudiante que recibe por parte de los docentes. Las primeras dos tareas mocionadas las realizara la secretaria, mientras que la tercera tarea solo la podrá realizar el docente.

6 Por otra parte los docentes solo tendrán permisos para ver los estudiantes inscritos en sus cursos, y para ingresarles la nota correspondiente; mientras que la secretaria y el rector o coordinador, tendrá permisos para: ingresar, modificar y ver los perfiles de los estudiantes, ver las notas reportadas por cursos, ver las notas reportadas por estudiante, ver los cursos a los que esta inscrito un estudiante, y los estudiantes inscritos en un curso; además tendrá permisos para ingresar o eliminar un estudiante de un curso, y asignar el docente a un curso; de la misma forma no podrá realizar modificaciones sobre las notas reportadas por los docentes. EL proyecto se realizara para funcionar exclusivamente sobre la Web, permitiendo funcionar exitosamente sobre los navegadores explorer, firefox y chorme. DESCRIPCIÓN Y CARACTERISTICAS DEL PRODUCTO Descripción General de la Solución a Construir INGENIO Soluciones Integrales pretende desarrollar un software orientado a la web con el cual los docentes podrán ingresar las notas de sus estudiantes desde cualquier lugar, y en tiempos reducidos. Por otra parte el personal administrativo, ya sea el rector o las secretarias del colegio podrá acceder a la información, y de esta forma hacer consultas en línea el perfil académico de los estudiantes, así como también podrán ingresar, modificar o eliminar datos relacionados con el estudiante. Características del Producto. El proyecto está orientado a la Web. 2. Reduce el tiempo de captura de las notas de los estudiantes de un colegio. 3. Es amigable con los usuarios. 4. Permite al colegio entrar en la nueva era digital. 5. Permite a los docentes realizar su trabajo desde cualquier lugar. 6. Evita la transmisión de información errónea de notas 7. Permite ver de forma completa el perfil académico de los estudiantes.

7 8. Por medio de este software los profesores podrán ingresar las notas de sus estudiantes, clasificados por cursos y materias. 9. Existirán dos tipos de usuarios dentro del sistema. Un usuario será de tipo Administrador, y el otro de tipo Docente. 0. El usuario de tipo Administrador tendrá acceso a la manipulación total de los datos existentes en el software, es decir, podrá ingresar, borrar o cambiar notas o datos personales de los estudiantes.. El usuario docente solo podrá ingresar las notas y consultar información académica acerca de los estudiantes. Requerimientos de documentación Manual de Usuario Al finalizar la realización del proyecto INGENIO Soluciones Integrales como parte del producto final se encargará de entregar un documento (Manual de Usuario) en el cual se especifican todos y cada uno de los pasos a realizar por parte del usuario al enfrentarse por primera vez al aplicativo. Ayuda Online INGENIO Soluciones Integrales proporcionara ayuda online al usuario, cuando este lo solicite, con el cual se espera dar respuesta oportuna a las inquietudes que se presenten. Hay que aclarar que el cobro de estas ayudas online estarán restringidas por las clausulas implantadas en el contrato del proyecto. Guías de instalación y Configuración Al ser el proyecto una aplicación que está montado en la Web nuestra compañía no ve necesario que los usuarios y el cliente conozcan la configuración interna realizada por nosotros para proporcionarles el servicio solicitado, así como tampoco es necesario entregar una guía de instalación del producto, pues como se ha mencionado el proyecto a realizar estará montado sobre la Web.

8 Equipo de Trabajo NOMBRE Julián David Varela Prieto Clara Natalia Herrera Rico Laura Constanza Osorio Ovalle Zulma Julieth Peña ROL Desarrollador de Software Gestor del proyecto Analista Testing PLAN DE TRABAJO METODOLOGIA La metodología que será utilizada para la realización del este proyecto será la metodología RUP, por ser la más completa en cuanto a documentación se refiere, permitiendo así un mayor control sobre el avance del proyecto al proporcionarnos más conocimiento acerca de cada una de las fases de desarrollo en la que va el proyecto. Al ser un software orientado a la web, el desarrollo se complementara con NDT Técnica de Desarrollo de Navegación, la cual plantea un proceso de desarrollo dividido en tres flujos de trabajo: captura y definición de requisitos, análisis de la navegación y diseño de la navegación de un entorno web los cuales se complementan con las fases de RUP. TECNOLOGIA A continuación se detalla cada uno de las tecnologías y herramientas que serán utilizadas para la realización del proyecto SICNE: LENGUAJE: El modulo será implementado en Flex, un lenguaje orientado a desarrollo de páginas web. Motor de base de datos: Sera utilizado la base de datos con la que cuente el colegio, en este caso será Oracle 0g.

9 Herramientas: Una herramienta que será de gran utilidad durante el proyecto será Gant Project, para definir los tiempos de ejecución de cada una de las tareas. ESTIMACIONES Y PRESUPUESTO La totalidad de presupuesto con la que se debe contar para realizar el proyecto, es de $ pesos colombianos m/cte. Esta suma asegura los costos que genera el desarrollo de software, soporte y aspectos a tener en cuenta en el desarrollo del proyecto. El plan de soporte ampliado, en caso de ser adquirido tiene un costo de $ pesos colombianos m/cte. CRONOGRAMA El cronograma se ha desarrollado teniendo en cuenta la metodología NDT, sin embargo, como esta metodología se centra sobre todo en las fases de inicio y diseño, se ha decidido tomar como base la metodología RUP, por lo tanto las actividades se desarrollaran en una combinación de ambas metodologías. El desarrollo se llevará a cabo en base a Fases con una o más iteraciones en cada una de ellas, existiendo, para el caso de este proyecto, 2 iteraciones o módulos. El primero, por ser el más crítico, será la construcción del Módulo de usuario Administrador, el segundo será la implementación de Módulo de usuario Docente. A continuación se describe con más detalle lo anteriormente citado. La siguiente tabla muestra la distribución de tiempos y el número de iteraciones de cada fase: Fase Nro. Iteraciones Duración Fase de Inicio 2 semanas Fase de Diseño semanas Fase de 2 3 semanas

10 Construcción Fase Transición de.5 Semana Los hitos que marcan el final de cada fase se describen en la siguiente tabla: Descripción Hito Fase de Inicio En esta fase se recopilaran los requisitos del producto desde la perspectiva del usuario, los cuales serán establecidos en el Documento de Requerimientos. Los principales casos de uso serán identificados y se hará un refinamiento del Plan de Desarrollo del Proyecto. La aceptación del cliente / usuario del Documento de Requerimientos y el Plan de Desarrollo marcan el final de esta fase. Fase de Diseño En esta fase se analizaran los requisitos y se desarrollara un prototipo de arquitectura (incluyendo las partes más relevantes y / o críticas del sistema). Analizando las especificaciones realizadas para obtener asi, un modelo de navegación coherente y sin errores Al final de esta fase, todos los casos de uso correspondientes a requisitos, que serán implementados en la primera iteración de la fase de Construcción, deben estar analizados y diseñados (en el Modelo de Análisis / Diseño). La revisión y aceptación del Prototipo de la Arquitectura del Sistema marca el final de esta fase. La primera iteración tendrá como objetivo la identificación y especificación de los principales casos de uso ( siempre teniendo en cuenta la navegación útil y facil dentro del sistema), así como su realización preliminar en el Modelo de Análisis / Diseño, también permitirá hacer una revisión general del estado de los artefactos hasta este punto y ajustar si es necesario la planificación para asegurar el cumplimiento de los objetivos. Se hará una segunda iteración para otro modulo del proyecto. Ambas iteraciones tendrán una duración de dos semanas.

11 Fase de Construcción Fase de Transición En esta fase, se parte del resultado del análisis para obtener lo que se conoce como modelo de navegación. También se terminan de analizar y diseñar todos los casos de uso, refinando el Modelo de Análisis / Diseño. El producto se construye en base a 2 iteraciones, cada una produciendo una release a la cual se le aplican las pruebas y se valida con el cliente / usuario. Se comienza la elaboración de material de apoyo al usuario. El hito que marca el fin de esta fase es la versión de la release.0, con la capacidad operacional parcial del producto que se haya considerado como crítica, lista para ser entregada a los usuarios para pruebas beta. En esta fase se prepararán dos releases para distribución, asegurando una implantación y cambio del sistema previo de manera adecuada, incluyendo el entrenamiento de los usuarios. El hito que marca el fin de esta fase incluye, la entrega de toda la documentación del proyecto con los manuales de instalación y todo el material de apoyo al usuario, la finalización del entrenamiento de los usuarios y el empaquetamiento del producto. El Cronograma de Actividades y Diagrama de Gantt se describe con mas detalle : NOMBRE INICIO 2 DURACION FECHA FECHA INICIO FIN 6/0/2 /02/2 ANTECESORA Iteración : Análisis de Requerimientos Definir entorno de trabajo y objetivos Definir e identificar requisitos de almacenamiento 2 Clasificar y definir los actores del sistema Definir e identificar requisitos funcionales 3 Definir e identificar requisitos de interacción 3 2 6/0/2 6/0/2 /02/2 7/0/2 7/0/2 9/02/2 9/0/2 20/02/2 20/0/2 25/0/2 20/0/2 25/0/2 Definir e identificar requisitos no funcionales 3 26/0/2 3/0/2

12 Hito: Documento de Requerimientos 3/0/2 /02/2 DISEÑO [todo lo siguiente con base en el documento de Requerimientos] 23 /02/2 3/03/2 Iteración : Modulo del usuario Administrador [perfil de estudiantes, y docentes] Definir los actores en el estudio Definir los nodos Definir los enlaces básicos Definir los índices menú Definir los índices de consulta y selección Elaboración del diseño de prototipo(mer, UML) (Definir el modelo de clases navegacionales) /02/2 /02/2 24/02/2 /02/2 2/02/2 /02/2 2/02/2 /02/2 2/02/2 2/02/2 4/02/2 2/02/2 4/02/2 4/02/2 Elaboración de prototipos (Definir los contextos navegacionales) 5 4/02/2 2/02/2 Pruebas e interrogantes 2 2/02/2 23/02/2 Hito: Documento Especificación 24/02/2 23/02/2 de requerimientos V.0 Iteración 2: Modulo del usuario Docente 20 6/02/2 3/03/2 Definir los actores en el estudio 6/02/2 Definir los nodos 6/02/2 Definir los enlaces básicos Definir los índices menú Definir los índices de consulta y selección Elaboración del diseño de prototipo(mer, UML) (Definir el modelo de clases navegacionales) 6/02/ /02/2 7/02/2 7/02/2 7/02/2 8/02/2 0/02/2 0/02/2 4/02/2 22/02/2 Elaboración de prototipos (Definir los contextos navegacionales) 5 22/02/2 29/02/2

13 Pruebas e interrogantes 2 Hito: Documento Especificación de requerimientos V2.0 CONSTRUCCION Iteración : Modulo del usuario Administrador [perfil de Estudiantes y Docentes] /02/2 2/03/2 2/03/2 3/03/2 24/02/2 2/03/2 24/02/2 8/03/2 Análisis de Requerimientos y Documento de Especificación de Requerimientos 24/02/2 25/02/2 Diseño Final del Sistema Implementación del Código Pruebas e interrogantes Hito: Entregable del Proyecto v /02/2 28/02/2 24/02/2 6/03/2 6/03/2 7/03/2 7/03/2 8/03/2 Iteración 2: Modulo del usuario Docente 9 8/03/2 2/03/2 Análisis de Requerimientos y del Documento de Especificación de Requerimientos Diseño Final del Sistema Implementación del Código Pruebas e interrogantes Hito: Entregable del Proyecto v2. TRANSICION Iteración Análisis de Requerimientos /03/2 9/03/2 8/03/2 0/03/2 8/03/2 7/03/2 9/03/2 20/03/2 20/03/2 2/03/2 22/03/2 5/04/2 22/03/2 5/04/2 Diseño Completo del Sistema Implementación Versión Final del Entregable 3 23/03/2 24/03/2 26/03/2 29/03/2 Pruebas e interrogantes Hito: Proyecto Final Hito: Manual de Usuario 29/03/2 30/03/2 2/04/2 3/04/2 4/04/2 5/04/2

14 ENTREGABLES A continuación se indican y describen cada uno de los artefactos que serán generados y utilizados por el proyecto y que constituyen los entregables. Esta lista constituye la configuración de RUP desde la perspectiva de artefactos, y que proponemos para este proyecto. Es preciso destacar que de acuerdo a la filosofía de RUP (y de todo proceso iterativo e incremental), todos los artefactos son objeto de modificaciones a lo largo del proceso de desarrollo, con lo cual, sólo al término del proceso podríamos tener una versión definitiva y completa de cada uno de ellos. Sin embargo, el resultado de cada iteración y los hitos del proyecto están enfocados a conseguir un cierto grado de completitud y estabilidad de los artefactos.. Plan de Desarrollo de Software Es el presente Documento 2. Modelo de Casos de Uso del Negocio Es un modelo de las funciones de negocio vistas desde la perspectiva de los actores externos (Agentes de registro de notas, solicitantes finales, otros sistemas etc.). Este modelo se representa con un Diagrama de Casos de Uso usando estereotipos específicos para este modelo. 3. Modelo de Objetos del Negocio Es un modelo que describe la realización de cada caso de uso del software, estableciendo los actores internos, la información que en términos generales manipulan y los flujos de trabajo asociados al caso de uso del software. Para la representación de este modelo se utiliza un Diagrama de Clases para mostrar gráficamente las entidades del sistema y sus relaciones, y Diagramas de Actividad para mostrar los flujos de trabajo. 4. Glosario Es un documento que define los principales términos proyecto. usados en el 5. Modelo de Casos de Uso

15 El modelo de Casos de Uso presenta las funciones del sistema y los actores que hacen uso de ellas. Se representa mediante Diagramas de Casos de Uso. En este caso, se diferencia del anterior, pues ahora se ven desde el punto de vista de los desarrolladores del software. 6. Visión Este documento define la visión del producto desde la perspectiva del cliente, especificando las necesidades y características del producto. Constituye una base de acuerdo en cuanto a los requisitos del sistema. También llamado Documento de Requerimientos, pero en el caso de la metodología RUP, Visión es el nombre que se le otorga. 7. Especificaciones de Casos de Uso Para los casos de uso que lo requieran,es decir aquellos funcionalidad no sea evidente o que no baste con una simple descripción narrativa, se realiza una descripción detallada utilizando una plantilla de documento, donde se incluyen: precondiciones, post-condiciones, flujo de eventos, requisitos nofuncionales asociados. También, para casos de uso cuyo flujo de eventos sea complejo podrá adjuntarse una representación gráfica mediante un Diagrama de Actividad. 8. Especificaciones Adicionales Este documento capturará todos los requisitos que no han sido incluidos como parte de los casos de uso y se refieren requisitos NO-funcionales globales. Dichos requisitos incluyen: requisitos legales o normas, aplicación de estándares, requisitos de calidad del producto, tales como: confiabilidad, desempeño, etc., u otros requisitos de ambiente, tales como: sistema operativo, requisitos de compatibilidad, etc. 9. Prototipos de Interfaces de Usuario Se refiere a los prototipos que permiten al usuario hacerse una idea más o menos precisa de las interfaces que proveerá el sistema y así, conseguir un aporte de su parte respecto a los requisitos del sistema. Estos prototipos serán realizados como: dibujos a mano en papel, dibujos con alguna herramienta gráfica, siguiendo ese orden de acuerdo al avance del proyecto. Sólo los de este último tipo serán entregados al final de la fase de Elaboración, los otros serán desechados. Asimismo, este artefacto, será desechado en la fase de Construcción en la medida que el resultado de las iteraciones vayan desarrollando el producto final. 0. Modelo de Datos

16 Teniendo en cuenta que la información del sistema será soportada por una base de datos relacional, este modelo describe la representación lógica de los datos, de acuerdo con el enfoque para modelado relacional de datos. Para expresar este modelo se utiliza un Diagrama de Clases (donde se utiliza UML para Modelado de Datos).. Casos de Prueba Cada prueba es especificada mediante un documento que establece las condiciones de ejecución, las entradas de la prueba, y los resultados esperados. Estos casos de prueba son aplicados como pruebas de regresión en cada iteración. Cada caso de prueba llevará asociado un procedimiento de prueba con las instrucciones para realizar la prueba, y dependiendo del tipo de prueba dicho procedimiento podrá ser automatizable mediante un script de prueba. 2. Solicitud de Cambio Los cambios propuestos para los artefactos se formalizan mediante este documento. Mediante este documento se hace un seguimiento de los defectos detectados, solicitud de mejoras o cambios en los requisitos del producto. Así se provee un registro de decisiones de cambios, de su evaluación e impacto, y se asegura que éstos sean conocidos por el equipo de desarrollo. 3. Evaluación de Iteración Este documento incluye le evaluación de los resultados de cada iteración, el grado en el cual se han conseguido los objetivos de la iteración, las lecciones aprendidas y los cambios a ser realizados. 4. Lista de Riesgos Este documento incluye una lista de los riesgos conocidos y vigentes en el proyecto, ordenados en orden decreciente de importancia y con acciones específicas de contingencia o para su mitigación. 5. Material de Apoyo al Usuario Final Corresponde a un conjunto de documentos y facilidades de uso del sistema, incluyendo: Guías del Usuario, Guías de Operación, Guías de Mantenimiento y Sistema de Ayuda en Línea. 6. Producto

17 Los ficheros del producto empaquetados y almacenadas en un CD con los mecanismos apropiados para facilitar su instalación. El producto, a partir de la primera iteración de la fase de Construcción es desarrollado incremental e iterativamente, obteniéndose un nuevo módulo al final de cada iteración.