INSTITUTO TECNOLÓGICO SUPERIOR DE PUERTO VALLARTA LICENCIATURA EN INFORMÁTICA
ASIGNATURA CALIDAD DE SOFTWARE
DOCENTE MARIA DE LOS ANGELES LACES PLAN DE DESARROLLO DE SOFTWARE Grupo 6to ³A´
Contenido 1.
2.
3.
4.
Introducción 1.1 Propósito 1.2 Alcance 1.3 Definiciones, Acrónimos y Abreviaciones 1.4 Referencias 1.5 Vista General Vista General del Proyecto 2.1 Alcance y Objetivos del Proyecto 2.1.1 Objetivos del proyecto 2.1.2 Alcance del proyecto 2.2 Suposiciones y Restricciones 2.3 Modelo del Ciclo de Vida del Proyecto 2.4 Entregas del Proyecto Organización del Proyecto 3.1 Estructura Organizacional 3.2 Interfaces Externas 3.3 Roles y Responsabilidades Proceso Administrativo Administrativ o 4.1 Estimaciones del Proyecto 4.1.1 Técnica de estimación elegida 4.1.2 Metodología 4.1.3 Cuenta de Function Points 4.2 Plan del Proyecto 4.2.1 Plan de Fase 4.2.2 Objetivos de la Iteración 4.2.3 Calendario del Proyecto 4.3 Recursos del Proyecto 4.3.1 Recursos de Hardware 4.3.2 Recursos de Software 4.3.3 Recursos Humanos 4.3.4 Presupuesto 4.4 Control y Monitoreo del Proyecto 4.4.1 Introducción 4.4.1.1 Propósito 4.4.1.2 Descripción del documento 4.4.2 Procesos de Control y Monitoreo 4.4.2.1 Prerrequisitos 4.4.2.2 Definición del proceso y mediciones
5. 6.
4.4.2.3 Comunicar el análisis de resultados 4.4.2.4 Definir la estrategia a seguir 4.4.3 Plan de Reportes 4.5 Plan de Administración de Riesgos 4.5.1 Análisis del riesgo 4.5.2 Planeación y monitoreo del riesgo Plan de Procesos Técnicos 5.1 Métodos, Herramientas y Técnicas Planes de Soporte de los Procesos 6.1 Plan de la Calidad 6.1.1 Introducción 6.1.2 Responsabilidades del personal de calidad 6.1.3 Estándares y productos aplicables 6.1.4 Metas de la calidad del proyecto 6.2 Plan de Resolución de Problemas 6.2.1 Conflictos de intereses 6.2.2 Problemas técnicos 6.3 Plan de Comunicaciones 6.3.1 Introducción 6.3 .2 Matriz de comunicación
1. INTRODUCCION 1.1 PROPOSITO En este documento se expresan la información necesaria para el control y la administración del proyecto ³Sistema de Control Escolar de Bachillerato (SCEB)´. Además de describir el método de desarrollo de software, el plan para dirigir los esfuerzos durante el desarrollo facilitara todos los procesos que se realicen en ese departamento ya que este es realizado con bases generales del nivel bachillerato y esto le permite adaptarse a cualquier institución educativa de ese nivel. 1.2 ALCANCE El sistema facilita la gestión de algunos procesos tales como altas, bajas y calificaciones de los alumnos dentro del modulo de control escolar; contratación y horarios de los docentes, la asistencia y los movimientos del personal en general; y, posteriormente la emisión de los recibos de pago de semestre del alumno impresos de la forma en que el bachillerato los maneja. Hará respaldo seguros de la información que recaude durante su periodo de vida o uno determinado para facilitar la migración de esta a un nuevo sistema o consulta y manipulación de la misma.
1.3 DEFINICIONES, ACRÓNIMOS Y ABREVIACIONES SCEB: Sistema de Control Escolar de Bachillerato. DFD: Diseño del Sistema Propuesto. SBCA: Diseñar y desarrollar un software para un sistema de bachillerato de control de alumnos 1.4 REFERENCIAS RUP.- Documento de la metodología del Rational Unified Unified Process®. NOTA: El RUP es un proceso de desarrollo desarrollo de software software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. 2.
VISTA GENERAL DEL PROYECTO
2.1
Alcance y Objetivos del Proyecto
El proyecto consiste en la implementación implementación de un sistema de control escolar de bachillerato bachillerato para el CBTA 127 (Tomatlán, Jalisco), el cual será utilizado por el jefe de control escolar y asistentes de dicho departamento. El objetivo principal del documento es verificar que los requerimientos del sistema se hayan cumplido y que el sistema esté funcioncionando correctamente, apegándose a los estándares de calidad y funcionalidad que se especificó para el desarrollo del mismo. Esta evaluación se llevará a cabo mediante la realización de evaluaciones periódicas al sistema. 2.1.1 Metas y Objetivos del Proyecto METAS los requisitos 1. Determinar funcionales, no funcionales y de software; así como la administración de cambios en los mismos, que permitan determinar el propósito y alcance del proyecto.
1.1.
OBJETIVOS Realizar los documentos de: visión, requisitos de software y especificaciones complementarias en los cuales se detalla la problemática que se tiene, las soluciones propuestas, el
1.2.
2. Controlar los cambios en configuración del producto software, asegurando integridad y optimizando así evolución.
la de su su
3. Identificar los aspectos que necesita el cliente para su implementación, creando la interfaz adecuada y conveniente a sus necesidades.
2.1.
2.2.
3.1.
3.2. 3.3.
2.1.1
Alcance del proyecto
Dentro del alcance:
alcance, la funcionalidad, las características y las restricciones de diseño, cumpliendo en el tiempo determinado para esta etapa. Administrar los cambios en requisitos, determinando el procedimiento a seguir y la validación del mismo. Administrar y controlar la configuración y cambios, mediante un control de versiones. Auditar la configuración, verificando que las versiones actuales sean acordes a requerimientos específicos. Ayudar al proceso de registro de los datos de los alumnos, sin necesidad de hacerlo manualmente. Realizar en menos tiempo posible el registro de datos. Realizar la base de datos correspondiente a toda la información que se incluirá en el software.
y y y y
Análisis y desarrollo del Sistema Entrega de Sistema en tiempo al cliente. Entrega de Documento final y liberación Entrega del Sistema funcionando al termino de la materia.
Fuera del alcance: y y y y
2.2
Suposiciones y Restricciones
y y y y
2.3
La capacitación del personal de control escolar. Garantía del Sistema. Contacto Directo con los empleados del área de control escolar. Disposición del personal de control escolar a utilizar el sistema.
El Instituto CBTA 127 no cuenta con un sistema de control escolar. La administración del Instituto CBTA 127 será la encargada de proveer los recursos necesarios para el proyecto. No hay limitantes en cuanto a recursos económicos. El tiempo para el desarrollo del proyecto será 90 días a partir de su solicitud.
Modelo del Ciclo de Vida del Proyecto El modelo de ciclo de vida utilizado es el modelo en espiral.
El modelo espiral para la ingeniería de software ha sido desarrollado para cubrir las mejores características tanto del ciclo de vida clásico, como de la creación de prototipos, añadiendo al mismo tiempo un nuevo elemento: el análisis de riesgo. El modelo representado mediante la espiral de la figura 2.4, define cuatro actividades principales:
Planificación: determinación de objetivos, alternativas y restricciones. Análisis de riesgo : análisis de alternativas e identificación/resolución de riesgos.
Ingeniería : desarrollo del producto del "siguiente nivel", Evaluación del cliente : Valorización de los resultados de la ingeniería. Durante la primera vuelta alrededor de la espiral se definen los objetivos, las alternativas y las restricciones, y se analizan e identifican los riesgos. Si el análisis de riesgo indica que hay una incertidumbre en los requisitos, se puede usar la creación de prototipos en el cuadrante de ingeniería para dar asistencia tanto al encargado de desarrollo como al cliente. El cliente evalúa el trabajo de ingeniería (cuadrante de evaluación de cliente) y sugiere modificaciones. Sobre la base de los comentarios del cliente se produce la siguiente fase de planificación y de análisis de riesgo. En cada bucle alrededor de la espiral, la culminación del análisis de riesgo resulta en una decisión de "seguir o no seguir". Con cada iteración alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior), se construyen sucesivas versiones del software, cada vez más completa y, al final, al propio sistema operacional. El paradigma del modelo en espiral para la ingeniería de software es actualmente el enfoque más realista para el desarrollo de software y de sistemas a gran escala. Utiliza un enfoque evolutivo para la ingeniería de software, permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel evolutivo. Utiliza la creación de prototipos como un mecanismo de reducción de riesgo, pero, lo que es más importante permite a quien lo desarrolla aplicar el enfoque de creación de prototipos en cualquier etapa de la evolución de prototipos.
Secuencia de actividades para el modelo Espiral. El modelo espiral incorpora una estrategia de uso de prototipos como parte del manejo del riesgo. Las creencias del modelo Espiral son: Una actividad comienza cuando se entienden los objetivos y riesgos involucrados. Basado en la evaluación de soluciones alternas, se usan las herramientas que mejor reduzcan los riesgos. Todo el personal relacionado debe involucrarse en una revisión que determine cada actividad, planeando y comprometiéndose con las siguientes actividades. El desarrollo se incrementa en cada etapa, permitiendo prototipos sucesivos al producto.
2.4
Entregas del Proyecto
3. 3.1
ORGANIZACIÓN DEL PROYECTO ESTRUCTURA ORGANIZACIONAL
Mariana Plascencia Lider Gustavo Líder de implementación de electrónica
Cinthy
Encargado de la configuracion de la
Mabel Líder de Requisito s Norma Ayudante
Enrique Lider de Analisis y Diseño Angel Ayudante
Maritza Líder de implementación de software
Armando Líder de pruebas
Mauro Ayudante
3.2 3.3
ROL
Requisitos
RESPONSABILIDAD
Gabriel Encargado de Ambiente
INTERFACES EXTERNAS ROLES Y RESPONSABILIDADES RESPONSABLE
Realizar los documentos: MABEL Y NORMA Visión, Requisitos de Software, Requisitos complementarios, y Administración de requisitos. Administrar los requerimientos durante el desarrollo del proyecto. Actualizar los documentos en caso de actualizaciones. Análisis y Analizar y proponer la arquitectura ENRIQUE Y Diseño adecuada. ANGEL Desarrollo de los Casos de Uso Identificar e incorporar los Elementos de Diseño Estructurar el Modelo de Implementación Diseño de la Interfaz del Usuario Diseño de Clases Diseño de Base de Datos Realización Diagramas de Secuencia Implementación Planear y Desarrollar el Software, así como la interfaz electrónica simuladora de las plumas de ingreso al estacionamiento. Desarrollar el software para la administración del estacionamiento con base en lo establecido por el equipo de Análisis y
Diseño. Pruebas
Ambiente
Administración de la configuración
Líder del Proyecto
Patrocinador
Realizar el documento de Pruebas. Realizar las pruebas de requerimientos, Diseño y software. Garantizar el correcto funcionamiento del software y la correcta interpretación de los requisitos implementados en el software. Abastecer oportunamente las herramientas y ambientes necesarios para el desarrollo del proyecto, además de la configuración de la instalación de las herramientas. Crear el ambiente para la configuración Llevar el estricto control y monitoreo de las versiones de cada uno de los documentos entregables a los clientes y a los distintos grupos en las fases de desarrollo. Administrar el control de cambios y las líneas bases. Planear el proyecto Valida el proyecto y los cambios en los documentos que resulten durante el desarrollo del proyecto. Es el enlace entre el patrocinador y el equipo del proyecto Administra los recursos del proyecto. Determina junto con el cliente y el patrocinador los tiempos de entrega y sus condiciones. Cierra las fases y el proyecto. Explicar las necesidades y problemáticas actuales del negocio que permitan la correcta interpretación en requisitos. Proporcionar oportunamente de los recursos financieros que permitan contar en tiempo y forma al equipo de desarrollo con los
recursos necesarios para el cumplimiento del cronograma de trabajo.
4.2.1
Plan de Fase
Fase
No.Iteraciones
Días
Comienzo
Fin
Conceptualización E laboración Construcción T ransición
1 2 2 1
2 2 4 1
09/03/11 11/03/11 18/03/11 30/03/11
16/03/11 16/03/11 30/03/11 30/03/11
4.2.2
Objetivos de la Iteración
Fase Conceptualización Elaboración Elaboración Construcción Construcción Transición
Iteración
Descripción
1 1 2 1 2 1
Contar con todos los requisitos
Hitos Asociados
Surgieron confusiones
Entrega Satisfactoria al Cliente
4.2.3 Calendario del proyecto:
Id 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Nombre PROYECTO Ambiente Identificar las Plantillas requeridas Verificar el Ambiente Preparar las Plantillas Instalar las Herramientas en el Servidor Mantener las Plantillas Personalizar las Herramientas en el Servidor Ejecutar las Herramientas (probar) Proporcionar Herramientas a los Clientes Integrar Herramientas Administración de la Configuración Identificar los artefact de documentos, software, hardware Definir el método de nombramiento Definir el formato de control de versiones Establecer las líneas de Base Definir el procedimiento para el control de cambios Definir el repositorio donde se integraran los artefact Concentrar y registrar las transformaciones que se van teniendo en los artefact
Duración 3 semanas 1 día 1 día
Comienzo Fin 28/03/2011 28/03/2011 28/03/2011 28/03/2011 28/03/2011 28/03/2011
Asignado a Mauro Bartolo Zavalza Mauro Bartolo Zavalza Mauro Bartolo Zavalza
1 día 1 día 1 día
28/03/2011 28/03/2011 28/03/2011
28/03/2011 28/03/2011 28/03/2011
Mauro Bartolo Zavalza Mauro Bartolo Zavalza Mauro Bartolo Zavalza
1 día 1 día
28/03/2011 29/03/2011
28/03/2011 29/03/2011
Mauro Bartolo Zavalza Ángel Fernando Barraza
1 día
29/03/2011
29/03/2011
Angel Fernando Barraza
1 día
29/03/2011
29/03/2011
Angel Fernando Barraza
1 día 1 día
29/03/2011 29/03/2011
29/03/2011 29/03/2011
Angel Fernando Barraza Angel Fernando Barraza
1 día
29/03/2011
29/03/2011
Angel Fernando Barraza
1 día
29/03/2011
29/03/2011
Angel Fernando Barraza
1 día
30/03/2011
30/03/2011
Luis Enrique Amaral
1 día 1 día
30/03/2011 30/03/2011
30/03/2011 30/03/2011
Luis Enrique Amaral Luis Enrique Amaral
1 día
30/03/2011
30/03/2011
Luis Enrique Amaral
1 día
30/03/2011
30/03/2011
Luis Enrique Amaral
20
Mantenter actualizado el repositorio con las versiones actuales
1 día
30/03/2011
30/03/2011
Luis Enrique Amaral
21 22 23
Auditorias Realizar reporte de auditoria Realizar reuniones de Junta de Control de Cambios Realizar solicitudes de Control de Cambios Requisitos Planteamiento del problema Análisis del sistema modificación o me jora(Documento Visión) Descripción de los requisitos de software modificación o me jora(Documentos Requisitos de Software) Administración de requisitos Programa de administración de requisitos Capacitación y recursos Modificación o me jora (Documentos Plan de Administración de requisitos) Detallado de requisitos Modificación o me jora(Documento Matriz de Atributos de Requisitos ) Descripción de especificaciones complementarias Modificación o
1 día 1 día 1 día
30/03/2011 30/03/2011 31/03/2011
30/03/2011 30/03/2011 31/03/2011
Mariana Sánchez Mariana Sánchez Mariana Sánchez
1 día
31/03/2011
31/03/2011
Mariana Sánchez
1 día 1 día 1 día 1 día
31/03/2011 31/03/2011 31/03/2011 31/03/2011
31/03/2011 31/03/2011 31/03/2011 31/03/2011
Mariana Sánchez Mariana Sánchez Mariana Sánchez Angel Cabrera
1 día
31/03/2011
31/03/2011
Angel Cabrera
1 día
01/04/2011
01/04/2011
Angel Cabrera
1 día 1 día
01/04/2011 01/04/2011
01/04/2011 01/04/2011
Angel Cabrera Angel Cabrera
1 día 1 día
01/04/2011 01/04/2011
01/04/2011 01/04/2011
Angel Cabrera Angel Cabrera
1 día 1 día
01/04/2011 01/04/2011
01/04/2011 01/04/2011
Maritza Herrera Maritza Herrera
1 día
04/04/2011
04/04/2011
Maritza Herrera
1 día
04/04/2011
04/04/2011
Maritza Herrera
24 25 26 27 28 29 30 31 32 33 34 35 36 37 38
39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56
me jora(Documento de Especificaciones complementarias) Análisis y Diseño Recepción de Requisitos funcionales Análisis de casos de uso Realización de casos de uso Evaluar resultados casos de uso Crear un Diseño de clase inicial Crear un Diseño de diagrama de entrega Definir todos los elementos de la clase Evaluar resultados Diag. Entrega Evaluar resultados Diag. de clases Evaluar resultados diag. casos de uso Crear un Diseño de diagrama de componentes Evaluar resultados diag. Componentes Crear un Diseño de diagrama de secuencia inicial Propuesta Inicial de la Base de Datos Identificar eventos y señales de B.D. Evaluar resultados secuencia Identificar clases, clases
1 día 1 día
04/04/2011 04/04/2011
04/04/2011 04/04/2011
Maritza Herrera Maritza Herrera
1 día 1 día 1 día
04/04/2011 04/04/2011 04/04/2011
04/04/2011 04/04/2011 04/04/2011
Maritza Herrera Emilio Heraldes Emilio Heraldes
1 día
05/04/2011
05/04/2011
Emilio Heraldes
1 día
05/04/2011
05/04/2011
Emilio Heraldes
1 día
05/04/2011
05/04/2011
Emilio Heraldes
1 día
05/04/2011
05/04/2011
Emilio Heraldes
1 día
05/04/2011
05/04/2011
Emilio Heraldes
1 día
05/04/2011
05/04/2011
Rocio Carrillo
1 día
05/04/2011
05/04/2011
Rocio Carrillo
1 día
06/04/2011
06/04/2011
Rocio Carrillo
1 día
06/04/2011
06/04/2011
Rocio Carrillo
1 día
06/04/2011
06/04/2011
Rocio Carrillo
1 día
06/04/2011
06/04/2011
Rocio Carrillo
1 día 1 día
06/04/2011 06/04/2011
06/04/2011 06/04/2011
Rocio Carrillo Cinty Marlene Alvarado
57 58 59 60 61 62 63 64
65 66 67 68 69 70 71 72 73 74 75 76 77 78
activas y subsistemas Integración del paquete 1 y 2 Recomendaciones Generales Reuniones de revisión Asignación de responsabilidades para la resolución de defectos Electrónica Determinar herramientas de traba jo Medio físico y Protocolo de comunicación Generar el enlace bidireccional entre módulo electrónico y módulo software Integración módulo software y Pruebas y Validación Implementación Implementación del prototipo definir el plan de integración Establecer comunicación bidireccional mediante un proceso Implementación BD Entradas Login (Validación de Sktop y Login encargado) Login (Validación Web) Interfaces Web Salidas Locales Usuarios
1 día 1 día 1 día 1 día
06/04/2011 07/04/2011 07/04/2011 07/04/2011
06/04/2011 07/04/2011 07/04/2011 07/04/2011
Cinty Marlene Alvarado Cinty Marlene Alvarado Cinty Marlene Alvarado Cinty Marlene Alvarado
1 día 1 día
07/04/2011 07/04/2011
07/04/2011 07/04/2011
Cinty Marlene Alvarado Cinty Marlene Alvarado
1 día
07/04/2011
07/04/2011
Blanca Sanchez
1 día
07/04/2011
07/04/2011
Blanca Sanchez
1 día
08/04/2011
08/04/2011
Blanca Sanchez
1 día 1 día 1 día 1 día 1 día
08/04/2011 08/04/2011 08/04/2011 08/04/2011 08/04/2011
08/04/2011 08/04/2011 08/04/2011 08/04/2011 08/04/2011
Blanca Sanchez Blanca Sanchez Blanca Sanchez Blanca Sanchez Oswaldo Lopez
1 día 1 día 1 día
08/04/2011 11/04/2011 11/04/2011
08/04/2011 11/04/2011 11/04/2011
Oswaldo Lopez Oswaldo Lopez Oswaldo Lopez
1 día 1 día 1 día 1 día 1 día
11/04/2011 11/04/2011 11/04/2011 11/04/2011 11/04/2011
11/04/2011 11/04/2011 11/04/2011 11/04/2011 11/04/2011
Oswaldo Lopez Oswaldo Lopez Oswaldo Lopez Gustavo Garcia Gustavo Garcia
79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102
Numeración Descuentos
Eliminación de Registros Erróneos Informes Web
Informes Archivo Integración 1 Pruebas Internas Pruebas Analizar los requerimientos funcionales del sistema Planeación de casos de pruebas Analizar el funcionamiento del sistema Detectar funcionalidades no solicitadas en el documento de requerimientos Registro de resultados Elaboración de checklist de pruebas Reporte de resultados Realización de pruebas Análisis de reportes de resultados Registro de resultados Identificar el área correspondiente Reporte de resultados Solicitud de correcciones Realizar pruebas relacionadas con la funcionalidad corregida Registro de resultados Reporte de resultados
1 día 1 día 1 día
11/04/2011 11/04/2011 11/04/2011
11/04/2011 11/04/2011 11/04/2011
Gustavo Garcia Gustavo Garcia Gustavo Garcia
1 día 1 día 1 día 1 día 1 día 1 día
11/04/2011 11/04/2011 11/04/2011 11/04/2011 12/04/2011 12/04/2011
11/04/2011 11/04/2011 11/04/2011 11/04/2011 12/04/2011 12/04/2011
Gustavo Garcia Gustavo Garcia Armando Cabrera Armando Cabrera Armando Cabrera Armando Cabrera
1 día
12/04/2011
12/04/2011
Armando Cabrera
1 día
12/04/2011
12/04/2011
Armando Cabrera
1 día
12/04/2011
12/04/2011
Armando Cabrera
1 día 1 día
12/04/2011 12/04/2011
12/04/2011 12/04/2011
Mabel Bernabe Mabel Bernabe
1 día 1 día 1 día
13/04/2011 13/04/2011 13/04/2011
13/04/2011 13/04/2011 13/04/2011
Mabel Bernabe Mabel Bernabe Mabel Bernabe
1 día 1 día
13/04/2011 13/04/2011
13/04/2011 13/04/2011
Mabel Bernabe Mabel Bernabe
1 día 1 día 1 día
13/04/2011 13/04/2011 13/04/2011
13/04/2011 13/04/2011 13/04/2011
Norma Lazareno Norma Lazareno Norma Lazareno
1 día 1 día
14/04/2011 14/04/2011
14/04/2011 14/04/2011
Norma Lazareno Norma Lazareno
103 104 105 106 107 108 109 110 111 112 113
Entrega Describir
las actividades de entrega Describir las instalaciones para la prueba y entrega al cliente Identificar las responsabilidades del grupo de desarrollo Identificar el Hardware y Software para correr la aplicación Calendarizar Metas de las actividades de entrega Solicitar al área de Ambiente el Hardware y Software, y verificar que funcione Entrega del documento al cliente y cada uno de los productos generados Empaquetar Demostración Entrega al Cliente
1 día 1 día
14/04/2011 14/04/2011
14/04/2011 14/04/2011
Norma Lazareno Norma Lazareno
1 día
14/04/2011
14/04/2011
Gabriel Cervantes
1 día
14/04/2011
14/04/2011
Gabriel Cervantes
1 día
14/04/2011
14/04/2011
Gabriel Cervantes
1 día
14/04/2011
14/04/2011
Gabriel Cervantes
1 día
15/04/2011
15/04/2011
Gabriel Cervantes
1 día
15/04/2011
15/04/2011
Gabriel Cervantes
1 día 1 día 1 día
15/04/2011 15/04/2011 15/04/2011
15/04/2011 15/04/2011 15/04/2011
Gabriel Cervantes Fernando Concepción Fernando Concepción
4.3.2 Recursos de Software
Rubro
Nombre del producto
Cantidad
Precio unitario
licenciamiento
Visual Basic.Net 8.0
1
$16,000.00
Total de recursos de software:
4.3
$16,000.00
Recursos del Proyecto
4.3.1 Recursos de Hardware Especificación: Concretamente, los principales recursos de hardware en una PC son la Memoria (Ram principalmente, Rom, Cache, etc) , Servidor, PC, impresora
Descripción
Precio
Servidor
Computadora con Procesador Intel Dual Core a 4.4 Ghz (2.2 Ghz x 2), 4GB de Memoria RAM, Disco Duro de 320 GB SATA II, Monitor LCD 15 Pulgadas marca Acer, combo quemador y reproductor de DVDs y CDs - DVD RW 22X, Tarjeta de Red de 100 mbps (lista para navegar en internet), 8 Puertos USB y Tarjeta de Sonido de 6 Canales en Alta Definición.
$ 6,750.00
Computadora HP:
Computadora Intel Dual Core 1gb Ddr2 Quemador Dvd, cd´s, Lcd 15.6 Disco Duro 80GB Serial ATA II Procesador Intel Dual Core 4 GHz Tarjeta Madre 6 puertos USB, Tarjeta de Red Ethernet 10/100Mbps, Mouse óptico, teclado109 teclas. La impresora láser monocromática HP LaserJet
$ 4,999.00
Impresora
$ 3,450.00
2015, USB, memoria 32MB, color y escala grises, Switch Cnet 8 Puertos
Switch
Instalacin de Red Costo del sistema Mantto por visita Total
$ 249.00 $ 1,000.00 $ 40,000.00 $ 300.00 $ 57,458.00
4.3.3 Recursos humanos: Rol Requisitos
Análisis y Diseño Implementación Implementación electrónica Pruebas Ambiente Admon configuración Entrega
Personas
15 15 15 15 15 15 15 15
Total de horas:
12
Costo hora/hombre:
$400
Total:
$4800
4.4 CONTROL y MONITOREO del PROYECTO. 4.4.1 INTRODUCCIÓN. En el presente trabajo se hablará sobre el control y monitoreo del Sistema de Bachillerato Para el Control de Alumnos (SCEB) el cual es un software creado en Visual Basic.net pensado especialmente para escuelas de educación media superior, este tipo de software ya ha sido implementado logrando la agilidad en los procesos y el
control de la documentación tanto de los alumnos, docentes y administrativos.
4.4.1.1 PROPÓSITO. El software SCEB tiene el propósito de agilizar el manejo que manualmente se realiza en cada institución con opción de que los alumnos, docentes y administrativos obtengan un mayor rendimiento en el manejo de la información, siendo capaz de operar con mayor utilidad, velocidad y con una interfaz más entendible para los usuarios de este sistema. Los administrativos podrán realizar las operaciones de manera sistematizada en vez de hacerlas manualmente, también contara con una base de datos para tener la información respaldada y almacenada. Con el fin de cubrir ciertos tipos de requerimientos y necesidades en el control escolar, ya que estará integrado por distintos módulos para una mejor administración, los cuales son:
INSCRIPCIÓN Y REINSCRIPCIÓN: En este apartado se basará en el papeleo y elección de las materias correspondientes del alumno de acuerdo al grado que le toca así como también el horario asignado. ALUMNOS: En este apartado se ingresaran todos los datos del alumno, nombre, semestre a cursar. DOCENTES: En este apartado se llevara a cabo un control sobre los docentes que laboran en el Bachillerato, materias que cursan así como su horario. CALIFICACIONES: En este apartado se llevara el kardex del alumno, materias aprobadas, materias reprobadas, etc. En general esto permite el seguimiento de la ejecución del SCEB y la introducción de las correcciones que resultarán de la experiencia adquirida.
4.1.2 DESCRIPCIÓN DEL DOCUMENTO. El sistema de Control Escolar de Bachillerato ³SCEB´ deberá ser controlado y monitoreado por un integrante del equipo del sistema. Validando los procesos de ejecución de los diferentes módulos en cada uno de las etapas. Los resultados de este monitoreo quedaran registrados para su evaluación ya sea externa o interna con el fin validar el buen funcionamiento del sistema De Control Escolar de Bachillerato ³SCEB´ 4.4.2 PROCESOS DE CONTROL Y MONITORIEO. 4.4.2.1 PRERREQUISITOS.
Al implementarse el sistema es importante que antes y durante de su ejecución se encuentre en condiciones óptimas de operar, es por eso que el sistema ³SCEB´ se debe de encontrar en un lugar que este fuera de riesgo, y en condiciones favorables que garanticen la funcionabilidad del sistema a lo largo de su práctica.
4.4.2.2 DEFINICIÓN DEL PROCESO Y MEDICIONES. Proceso Medición del proceso Este botón de control de ALUMNOS es MODULO CONTROL DE ALUMNOS un enlace a otro modulo que solo tiene la funcionalidad de llevar al CONTROL DE ALUMNOS del bachillerato. CONTROL DE DOCENTE Este botón abre otra ventana donde permitirá controlar todo lo relacionado con el DOCENTE, en cuanto a las materias que impartirá, y algunos datos personales. INSCRIPCIÓN REINSCRIPCIÓN Este botón realiza un enlace a la venta de y INSCRIPCIONES REINSCRIPCIONES la cual permite dar de alta a alumnos ya inscritos en el bachillerato o a los de nuevo ingreso. CALIFICACIONES Este botón realiza un enlace a otra ventana la cual permitirá dar de alta las calificaciones de todos los alumnos del bachillerato. SALIR El botón SALIR nos permitirá salir de la pantalla de autentificación y poder regresar a la pantalla principal para ingresar a toro modulo si así lo desea. 4.4.2.3 COLECCIÓN DE DATOS. MODULO
ACCIÓN
FUNCIÓN
RESULTADO
CONTROL ALUMNOS
MODULO DOCENTE
INSCRIPICONES REINSCRIPICONES
DE Se da clic en la aplicación de Nos manda a una pantalla de login FUNCIONAN CORRECTAMENTE. CONTROL DE ALUMNOS el cual es el filtro que permite solo personal autorizado accedan al sistema. Se introdujeron los datos Automáticamente manda correspondientes USUARIO y siguiente aplicación que es donde CONTRASEÑA. está la información de los alumnos CONSULTAR, ACTUALIZAR y SALIR. INFORMACIÓN DEL ALUMNO Se guardan los datos registrados DATOS PERSONALES del docente, Se realiza la búsqueda por medio DATOS PROFESIONALES. de un ID del docente.
FUNCIONAN CORRECTAMENTE todas la las actividades.
Si ingresa un ID que no exista se DATOS PROFESIONALES muestra un mensaje. DOCUMENTOS ENTREGADOS. GUARDAR. BUSCAR.
NO SE ENCONTRO NINGUN REGISTRO. Guarda correctamente. Presenta problemas de búsqueda y no ARROJA NADA.
FUNCIONAN CORRECTAMENTE todas las actividades. LA BUSQUEDA HA SIDO UN EXITO No se presento ningún problema para el sistema y tampoco hacia el usuario. Se busca correctamente y no se presento ningún problema para el sistema y tampoco hacia el usuario.
ACTUALIZAR
NO ACTUALIZA y provoca problemas hacia el usuario y sistema.
Envía al modulo de INSCRIPCIÓN.
FUNCIONAN CORRECTAMENTE.
INSCRIPCION
Pregunta ¿que deseas hacer? INSCRIPCIÓN REINSCRIPCIÓN. GUARDAR.
PAPELEO
GUARDAR.
No se presento ningún problema para el sistema y tampoco hacia el usuario. Se produjo un error al realizar la operación: NO ES UN NOMBRE DE ARCHIVO VALIDO Se produjo un erro al realizar la operación: NO COINCIDEN LOS TIPOS DE DATOS EN LA EXPRESIÓN
y Se ingresa CONTRASEÑA Y
ACTUALIZAR CALIFICACIONES
VER SEMESTRE. VER KARDEX SUBIR CALIFICACIONES.
DE CRITERIOS EL RESGISTRO NO SE ENCUENTRA. No muestra las calificaciones ni por semestre, ni el kardex del alumno. Si hace el registro de calificaciones por alumno correctamente.
4.4.2.4 ANÁLISIS DE DATOS.
MODULO PANTALLA PRINCIAL
ALUMNOS CONSULTAR REINSCRIPCION
DOCENTES CALIFICACIONES
EJECUCION CONTRASEÑA ALUMNOS REINSCRIPCION DOCENTES CALFICACIONES CONSULTAR MOSTRAR MODIFICAR DESHABILITAR NO.CONTROL ALTA MODIFICACIÓN ESPECIALIDAD INGRESAR
ALTA MODIFICAR BAJA ALMUNO NO.CONTROL KARDEX IMPRIME KARDEX
RESULTADO
Pedir los datos al docente Actualizar Clave docente No. Docente Subir Calificaciones
4.4.2.5 COMUNICAR EL ANÁLISIS DE RESULTADOS. Al implementar el sistema de bachillerato se encontraron fallas en la conexión con la base de datos la cual se está manejando en Access 2007. Se elaboro un diagnostico general de los requisitos establecidos para el desarrollo del software. Contando con los siguientes puntos: 1.- Diagnostico del software 2.- Implementación. 3.- Prueba.
Algunos De Los Errores Que Se Presentaron Son Los Siguientes: Al momento de guardar los checkbox no los almacena en la base de datos. El modulo de calificaciones tiene valores erróneos que ocasionan no almacenarse en la base de datos.
Para La Solución De Las Fallas Del Sistema Se Hicieron Las Siguientes Modificaciones: Verificación del valor que almacenan los checkboxes y poner el correspondiente en la base de datos. Verificación de las variables que retornan algún valor en la BD. Establecimiento de una misma ruta de conexión hacia la BD. Además de evaluar los posibles errores que pudieran surgir.
4.4.3
"Stakeholder "
(Quien requiere)
Información Requerida
Razón del requerimiento
Frecuencia / Fecha Requerida
Método de Entrega
Responsable
(P orque lo requiere)
( Cuando lo requiere)
( Como lo requiere)
(Quien lo entrega)
Documento de Requisitos
Para poder realizar el diseño y arquitectura con los requisitos del cliente
Cada vez que sea actualizado
Equipo de requisitos
Solicitud de Cambio
Para contar que el cambio solicitado en que se fundamenta y quien lo solicita Para que se especifique las modificaciones así como quien lo solicita y el alcance de la misma Para implementar en software lo diseñado como solución para el cliente será la guía
Cada que se requiera un cambio
A través de archivo electrónico por medio del espacio Hotmail.com, o directamente Físicamente por el equipo solicitante
(Que
R equiere)
Diseño
JCC Requisitos
Solicitud de cambio autorizada
Documento de Diseño Implementación
Requisitos
Para verificar la congruencia entre lo solicitado entre el cliente y lo diseñado así como el diseño de pruebas
Diseño
Para verificar la congruencia entre lo
Pruebas
Pruebas
Análisis de comunicación
Cada que se requiera un cambio
Física
Equipo que solicita cambio Junta de Control de Cambios
Cada que se A través de modifique el Administración de documento diseño la configuración con el espacio que cuenta Hotmail.com Cuando se emitan A través de versiones o Administración de revisiones nuevas la configuración con el espacio que cuenta en Hotmail.com
Equipo de diseño
Cuando se emitan versiones o
Equipo de Diseño
A través de Administración de
Equipo de requisitos
diseñado y lo desarrollado en software y diseño de pruebas Pruebas
Software
Para realizar las pruebas diseñadas
Entrega
Todos los documentos
Para hacer la entrega formal al cliente del proyecto concluido
4.5
revisiones nuevas
la configuración con el espacio que cuenta en Hotmail.com Cuando se termine A través de una iteración Administración de la configuración con el espacio que cuenta en Hotmail.com Al contar con los A través de documentos finales Administración de la configuración con el espacio que cuenta en Hotmail.com
Equipo de Implementación
Todos los equipos (requisitos, diseño, implementación, pruebas, JCC)
Plan de Administración de Riesgos
4.5 .1 Plan de Riesgos Nbr. Descripción del Riesgo Mala Interpretación de Un requisito
P
I
C
M A I
Descripción del Impacto Fallas en el diseño e implementación del
Acciones de Prevención Revisar con los líderes de cada
Acciones de Mitigación Reuniones de revisión de
Sistema por interpretación de requisitos
disciplina de modelo de RUP los requisitos presentados
Que los requisitos planteados sean demasiado complejos para implementarlos
M A I
Retraso importante en los tiempos establecidos para cada uno de los requisitos, como consecuencia incrementa el costo del proyecto Doble trabajo
Revisar cada uno de los requisitos del proyecto con el equipo de Implementación y diseño, estimando tiempo y costo Tener cuidado al elaborar las pruebas para asegurarnos de tener la versión más actualizada Que existan fallas de Realizar pruebas de comunicación en la comunicación de la conexión de la aplicación aplicación con la con la base de datos base de datos
Hacer pruebas a versiones anteriores
B
M M
1
Integración de Herramientas
B
M M
1
Poco dominio de la tecnología Vb.net, A retraso por la necesidad de investigar cómo implementar requisitos muy específicos
B M
Se consumirá tiempo en la investigación y aprendizaje y los límites de tiempo para entrega son muy cortos
Compartir información y experiencias, tratar de mantener la comunicación con los miembros del equipo
4
Poca experiencia en la administración A
M A
El descontrol de las
Mantener atención
requisitos y revisión de los líderes y pruebas de su implementación Negociar con el cliente alguna propuesta alternativa o que el tiempo de entrega se prolongue Revisar detalladamente las pruebas realizadas Verificar compatibilidad de versiones de los drives con la aplicación final. Buscar la solución del problema presentado entre todos los miembros del equipo para eficiente el tiempo de investigación y aprendizaje El líder dejara de
de proyecto provocara que se salgan de control las actividades del desarrollo
8
Tiempo de desarrollo y pruebas muy corto, provocara Estrés sobre los programadores por cumplir metas y compromisos, dado su múltiples ocupaciones y trabajos adicionales, nadie trabaja bien, estresado
Conexión a la Base de Datos 1
actividades evitara concentrarse en el desarrollo del proyecto, por tratar de volver a tener control A
M A
M M A
Entregables
A
A I
Incumplimiento en los compromisos de entrega, entrega de actividades con un alto porcentaje de errores y falta comunicación entre los integrantes de diseño.
M A I
4
1
Descuidos en implementación, pocas pruebas para depuración, entregas erróneas e incompletas, Fala de las entregas
Error de conexión de la aplicación de escritorio a la Base de Datos Faltante de uno de los entregables.
Retraso grave en la entrega a implementación y por lo tanto retraso en la entrega del proyecto.
sobre el desarrollo de las actividades para detectar cualquier cambio brusco que pueda afectar el control Establecer un estándar en codificación , y una metodología de pruebas para detectar fallas antes de liberar versiones del producto Realizar las pruebas en diferentes equipos con el archivo de enlace Integrar y estar al pendiente de la entrega en la fecha según el cronograma Realizar reuniones con los integrantes de los equipos y comprometiéndolos con las tareas que se les asignaron. Haciéndoles comprender que de
lado su participación en el desarrollo y se concentra son lo en la administración y control Planificar la forma de corregir el error presentado
Checar el equipo que cumpla con los requerimientos Mostrar la versión anterior y presentar el plan de entrega con la corrección de lo que hizo falta Regresar el trabajo al integrante señalando los errores cometidos para que realice estas correcciones el más pronto posible (máximo
2
Cambios constantes en las versiones de requisitos y la incorrecta interpretación de estos en el área de diseño.
B
B B
nosotros dependen muchas personas. Decirles que tienen que pedir ayuda cuando no comprendan como realizar una tarea que se les ha asignado ya sea a los integrantes de diseño o fuera de este equipo e investigar acerca del tema. Provocaría una Preguntando todas implementación errónea las dudas que se y por lo tanto un tengan acerca de producto diferente al que los documentos de el cliente está requisitos. Evitando solicitando. inferir o deducir información que no está claramente escrita en los documentos de requisitos. Solicitar a requisitos que sus cambios sean lo menos posibles. Hacer una revisión interna en el área de diseño para detectar
siguiente día). Redoblar esfuerzos, es decir asignar más tareas a cada integrante en caso del incumplimiento de un integrante. Hablar con ellos. Y reportar el suceso al administrador del proyecto.
Realizar los cambios sugeridos por requisitos. Corregir lo que se interpretó y se representó de forma incorrecta en diseño.
3
Demasiados cambios solicitados por implementación a diseño.
M A I
Doble trabajo para los integrantes de diseño que puede llegar a causar que el diseño no logre incluir todos estos cambios para la fecha de entrega final del proyecto.
errores antes de que estos se trasladen a implementación. Avisar a implementación que ³no implemente´ hasta que diseño haya terminado. Pedirle que respete en lo más posible el diseño, a no ser que sea algo muy ³necesario´ (algo que no se pueda implementar o algo que les facilite a ellos mucho trabajo adicional) de cambiar. Solicitar a la junta de cambios que evite apoyar cambios no urgentes (que analice a quien afecta más el impacto del cambio si a diseño o a programación). No admitir cambio en la base de datos,
Asignar el doble trabajo a los integrantes del equipo, advirtiendo al administrador del proyecto que de ser enormes los cambios esto puede causar que no se puedan contrarrestar por falta de tiempo.
nombres de clase, atributos o métodos de preferencia.
Matriz de Clasificación de Riesgos P=Probabilidad, I= Impacto, C= Clasificación d a d i l i b a b o r p
Imapcto en el proyecto Bajo Medio Alto Alta medio alto Inaceptable Media bajo alto Inaceptable Baja bajo medio alto
4.5.2 descripción Conocer y difundir Mapa de riesgos del proceso
Planeación y monitoreo del riesgo Responsable de ejecutar
tiempo
Líder del proyecto
continuo
Definir estrategias para control del riesgo y monitoreo
Todos los equipos
Después de conocer y difundir el mapa de riesgo
Coordinar y Programar Las estrategias
Líder del proyecto junto con todos los equipos
Periodos prolongados
Dar a conocer las estrategias programadas
Líder del proyecto
Periodos prolongados
Aplicar las estrategias de plan de riesgo
Todos los equipos
Actualizar los estrategias de plan riesgo
Líder del proyecto
Cada semana continuo
5. PLAN DE PROCESOS TÉCNICOS 5.1.
Métodos, herramientas y técnicas
MÉTODO Determinar los requisitos funcionales, no funcionales y de software; así como la administración de cambios en los mismos, que permitan determinar el propósito y alcance del proyecto. Identificar los aspectos que necesita el cliente para su implementación, creando la interfaz adecuada y conveniente a sus necesidades.
Evaluación y prueba del sistema, generando reporte de resultados.
y y y
y
y
y y y
y
y
y
y
y
TÉCNICAS Entrevistas. Cuestionarios. Revisión de documentación del sistema. Análisis de la información obtenida. Pruebas al sistema. Entrevistas. Cuestionarios. Revisión de documentación del sistema. Análisis de la información obtenida. Visitas a la institucion para entrevistas personales. Pruebas físicas al sistema. Verificación sistemadocumentación. Redacción de reporte final de resultados.
y
y y
y
y y
y
y
HERRAMIENTAS Realizar entrevistas a las personas idicadas. Planificacion Realizar pruebas al sistema
Realizar entrevistas a las personas idicadas. Planificacion Verificacion y analisis
Realizacion de pruebas fisicas Realizacion de informe final y resultados
6. PLANES DE SOPORTE DE LOS PROCESOS 6.1. PLAN DE CALIDAD 6.1.1. INTRODUCCIÓN Una de las principales fases dentro de la elaboración de un proyecto es el Aseguramiento de la Calidad del Software (SQA), es decir, un modelo sistemático y planeado de todas las acciones necesarias para proveer la confianza adecuada, según los requerimientos técnicos establecidos de cada producto e ítem del proyecto. Un sinónimo del aseguramiento de la calidad del software es aseguramiento del producto de software. El plan de aseguramiento de la calidad del software (SQAP) define que tan cerca a estos estándares se debe monitorear. Para poder realizar una buena cercanía con los estándares se debe medir cuantitativamente, donde sea posible, los aspectos de calidad; como complejidad, confiabilidad, mantenimiento, seguridad, defectos, número de problemas, utilizando métricas bien establecidas. La actividad del aseguramiento de calidad es el proceso de verificación de que los estándares sean aplicados. En este proyecto se organizará un equipo de desarrollo, en el cual a cada individuo se le asignara una tarea específica para la mejora de la calidad del sistema SCEB. Por tal razón utilizaremos el SQA para la evaluación de calidad del sistema de bachillerato de control de alumnos (SCEB). Para comprobar que el software cubre las necesidades del usuario y de esta forma realizar un software de mejor calidad.
6.1.2. RESPONSABILIDADES DEL PERSONAL DE CALIDAD Para poder integrar el sistema SCEB (sistema de control escolar de bachillerato) con los estándares de calidad se debe medir cuantitativamente, donde sean posibles los aspectos de calidad utilizando métricas bien establecidas. Para cumplir con esto, se deben realizar las siguientes actividades:
FUNCIONES DE LOS RESPONSABLES DEL SISTEMA DE CALIDAD
Las funciones del Administrador de Calidad, son las siguientes:
y y
Velar por el óptimo funcionamiento del Sistema SCEB Asegurarse de que se establecen, implementan y mantienen los procesos necesarios
para el Sistema SCEB y
y
y
Informar a la alta dirección sobre el desempeño del sistema y de cualquier necesidad de mejora. Asegurarse de que se promueva la toma de conciencia de los requisitos del cliente en todos los niveles de la realización e implementación del sistema. Estar en permanente contacto con la Dirección de Calidad y procesos de la Empresa con el fin de tomar en conjunto decisiones que permitan el mejoramiento continuo del Sistema SCEB.
El Responsable de SQA debe: y
y y
y
y y
y y y
Asegurarse de que se desarrollen prototipos para probar y eliminar riesgos técnicos que hagan fracasar el Sistema SCEB así como también disminuir la calidad del mismo. Asegurarse de que se realicen estudios de factibilidad Realizar mediciones para comprobar la calidad que se va llevando en la realización del sistema SCEB Asegurarse de que se realice la actividad de implementación y se haga según los estándares de calidad propuestos. Debe conocer los requerimientos del sistema. Debe conocer los estándares o lineamientos del Sistema SCEB para asegurar la calidad. Revisar las Entregas Revisar el Ajuste al Proceso Realizar el Informe Final de Calidad
6.1.3. METAS DE LA CALIDAD DEL PROYECTO y
y
y
y y y
tener resultados satisfactorios, un software de calidad que cumpla con los requisitos que el cliente necesita, es decir que satisfaga las necesidades del usuario. operar con mayor rendimiento, velocidad y una interfaz más entendible para los usuarios de este sistema. realizar las operaciones de manera sistematizada en vez de hacerlas manualmente. ahorro de tiempo en la realización de las operaciones. controlar el buen funcionamiento del software. Monitoreo y revisión periódica de cada uno de los procesos del sistema.
6.1.4. MÉTODOS Y HERRAMIENTAS COLECCIÓN DE DATOS
PARA
EL
ANÁLISIS
Y
El principal mecanismo para realizar la verificación y control en cuanto a la calidad del software serán las revisiones, entrevistas y otros métodos y técnicas que se aplicarán para que de esta forma se puedan encontrar y corregir errores en cada una de las áreas del proyecto. Para aplicar la mejora de calidad en el SCEB se necesitara trabajar en base a los siguientes métodos y herramientas para el análisis y colección de datos:
Hoja de registro En esta hoja de recolección de datos se utilizara para reunir y clasificar las informaciones según determinadas categorías del sistema SCEB. Es importante recalcar que este instrumento se utiliza tanto para la identificación y análisis de problemas como de causas. Para este método se seguirá el siguiente procedimiento: 1. Identificar el elemento de seguimiento 2. Definir el alcance de los datos a recoger. 3. Fijar la periodicidad de los datos a recolectar. 4. Diseñar el formato de la hoja de recogida de datos, de acuerdo a la cantidad de información a escoger, dejando espacio para totalizar los datos, que permita conocer: las fechas de inicio y termino, las probables interrupciones, las personas que recoge la información, la fuente etc. y
Lluvia de ideas Se le dará la oportunidad, a todos los miembros con interacción al SCEB, de opinar o sugerir sobre la funcionalidad del sistema, ya sea un problema, un plan de mejoramiento u otra cosa, y así se aprovecha la capacidad creativa de los participantes. Se seguirá el siguiente procedimiento: 1. Nombrar a un moderador del ejercicio. 2. Cada miembro tiene derecho a emitir una sola idea por cada turno de emisión de ideas. 3. No se deben repetir las ideas. 4. No se critican las ideas. 5. El ejercicio termina cuando ya no existan nuevas ideas. 6. Terminada la recepción de las ideas, se les agrupa y preselecciona conforma a los criterios que predefina el equipo. y
Entrevistas Técnica que permitirá reunir información directamente con los involucrados del sistema. y
Se realizará el siguiente procedimiento:
1. Planear la entrevista. Determinar qué información se necesita recopilar. 2. Elaborar una guía para la entrevista (introducción, preguntas relacionadas con el sistema y uso de este). 3. Seleccionar las personas que más conozcan e interactúen con el sistema. 4. Programar la entrevista. Planear el tiempo necesario para realizar la entrevista. 5. Ubicar un lugar apropiado para realizar la entrevista sin interrupciones. 6. Invitar al entrevistado, informarle del objetivo, fecha y lugar donde se realizará la entrevista. 7. Realizar la entrevista (sea puntual, cordial y desarrolle la guía para la entrevista, luego resuma y permítale al entrevistado hacer comentarios. Dele las gracias.) y
Pruebas de Uso:
Se conseguirán usuarios que no estén familiarizados con el Sistema para probarlo por un tiempo determinado, ofrece retroalimentación a los desarrolladores acerca de las dificultades que encontraron. Esta es la mejor manera de realizar mejoras a la interfaz.
Inspecciones de código Cada desarrollador puede encontrar distintos tipos de defectos. No hay tiempo ni dinero para inspeccionar todo. Se suele centrar la inspección en los módulos más críticos. Es recomendable realizarla después de una prueba básica. y
6.2. PLAN DE RESOLUCIÓN DE PROBLEMAS 6.2.1. CONFLICTOS DE INTERESES Para prevenir algunas fallas en el sistema dentro de la empresa se llevara a cabo lo siguiente: y
y
y
revisión periódica del sistemas reuniones del equipo de trabajo para ver si existe algún fallo. realizar respaldos para evitar pedida de información.
Asimismo, se debe informar de cualquier otro conflicto de interés que estime el equipo de coordinación o el experto.
6.2.2. PROBLEMAS TÉCNICOS
1. 1.2
1.3 1.4 1.5 1.6 1.7 2. 2.2 2.3
2.4 2.5 2.6 2.7 2.8 2.9
Juntas de revisión Asigne revisiones por compañeros cada vez que se considere un cambio al sistema. Seleccione un documento riesgoso o una sección de código para las juntas semanales de revisión Cada semana identifique a los evaluadores y programe juntas de revisión Los evaluadores deberán estudiar el material de forma individual por 2 horas Los evaluadores deberán reunirse para revisar el material por 2 horas Incluya notas de las juntas de revisión en el repositorio y dé seguimiento a cualquier problema identificado en las juntas de revisión Pruebas al sistema Diseñe y especifique un manual detallado del conjunto de pruebas Revise el conjunto de pruebas al sistema para asegurarse de que cada pantalla de la interfaz del usuario o elemento es cubierto. Ejecute pruebas completas al sistema en cada candidato a entrega. Estas pruebas al sistema serán ejecutadas en un equipo dedicado de QA. Actualice las pruebas al sistema cada vez que los requerimientos cambien Actualice este plan de pruebas cada vez que los requerimientos cambien Documente los resultados de las pruebas y comuníquelos a equipo de de desarrollo completo Estime los defectos remanentes (aún no detectados) bañándose en los datos actuales de control de cambios, tasas de error, y métricas en el tamaño del código y el impacto de los cambios. Mantenga todos los reportes de errores actualizados en una base de datos de control de cambios. El sistema de control de cambios está disponible para todos los miembros del proyecto.
6.3. PLAN DE COMUNICACIONES 6.3.1. INTRODUCCIÓN. En esta institución se presentan problemas como pérdida de tiempo al realizar de forma manual o tradicional todo trabajo relacionado con el control de escolar y administrativo, término que en la actualidad seria traducido como inoperante e ineficiente de acuerdo a lo que se puede lograr en comparación con la tecnología y procedimientos actuales. Este sistema permitirá un ahorro de tiempo, reducción de trabajo con respecto al control escolar y registros de información sobre los docentes. Se pretende que los alumnos resuelvan los problemas para poder inscribirse en el periodo establecido, darse de alta, poder checar sus calificaciones de manera interactiva, etc. Además de que no solo los alumnos serán beneficiados con la elaboración del proyecto si no también los administrativos y docentes de la institución. Objetivo General Diseñar y desarrollar un software para un sistema de bachillerato de control de alumnos (SBCA).
Objetivos Específicos Identificar los aspectos que necesita el cliente para su implementación, creando la interfaz que sea conveniente a sus necesidades. Ayudar al proceso de registro de los datos de los alumnos, sin necesidad de serlo manualmente. Realizar en menos tiempo posible el registro de datos. Quienes y a quienes va dirigida el software. Realizar la base de datos, correspondiente a toda la información que se incluirá en el software. Alcances El sistema facilita la gestión de algunos procesos tales como altas, bajas y calificaciones sobre los alumnos dentro del modulo de control escolar; contratación y horarios de los docentes, la asistencia y los movimientos del personal en general; y, posteriormente la emisión de los recibos de pago de semestre del alumno impresos de la forma en que el bachillerato los maneja.
6.3.2. MATRIZ DE COMUNICACIÓN.
Descripción del entregable 1.requisitos 2analisis y diseño
3. implementación
Tipo (mandato, informativa, de mercado)
Dirigido a
Se implementar a especialment e en bachilleratos.
Método de entrega Las entregas se harán de forma física.
Frecuen Responsable cia de 1.mabel y norma entrega 2.enrique y ángel 3.Maritza ,mauro, Gustavo y Oswaldo 4.armando y Emilio 5.Rocio y Cinthy 6.Mariana Plasencia 7.SEP(secretaria de educación publica)
4.pruevas
5. Administración de la configuración. 6. Líder del proyecto. 7.patrocinador
6.4. PLAN DE CAPACITACIÓN Una vez haciendo las correcciones o mejoras necesarias al sistema SCEB, se le brindara una capacitación a todo el personal que interactúe con este. Guía para el chequeo de la capacitación:
Propósito 1 Criterios Entrada 2 Revisión
3
Criterios Salida
Guía el chequeo de la capacitación. de SPMP (Plan de la gestión del proyecto de software) Chequear que el staff de desarrollo del software haya sido capacitado para realizar sus tareas. Definir capacitaciones si es necesario. de Proceso de capacitación revisado. Capacitaciones si son necesarias.
REQUERIMIENTOS DE USUARIO 1. El sistema permitirá el inicio de sesión y para esto se pedirá: a. Login. Se introducirá el nombre de usuario. b. Contraseña. Se introducirá la contraseña del usuario, si la contraseña es incorrecta se mostrara un mensaje ³Datos incorrectos´ y si es correcta, dependiendo del tipo de usuario entrara al sistema. 2. Al iniciar el sistema se mostrara una pantalla de inicio la cual contendrá los siguientes datos: Un menú en la parte superior que tendrá el acceso a los módulos los cuales son: USUARIOS, CLIENTE, PRODUCTOS, PROVEEDORES, FACTURAS, VENTAS COTIZACIONES, COMPRAS, MOVIMIENTOS Y SALIR. Cada submenú tiene un icono al lado. La pantalla principal tendrá el logo del sistema. 3. El sistema contendrá el modulo usuarios donde se podrá: Cuando se ingrese al modulo se abrirá una pantalla en donde se muestren los usuarios existentes y sus datos. En esta misma pantalla se podrá hacer la consulta de los mismos por medio de una búsqueda del nombre. En la parte inferior de esta pantalla se tendrán cuatro botones que serán: ALTA, BAJA, MODIFICAR y SALIR con una imagen que represente la acción del botón. a. Dar de alta Se introducirán los siguientes datos en una pantalla que se mostrara cuando se da un clic en el botón ALTA de la pantalla de usuarios. I. Clave de usuario II. Nombre III. Apellido paterno IV. Apellido materno V. Domicilio VI. Teléfono VII. Tipo de usuario 2.1 el sistema permitirá elegir de una lista desplegable el tipo, para cada usuario. I. Administrador II. Empleado Así mismo esta pantalla contendrá los botones de GUARDAR, CANCELAR y SALIR. b. Dar de baja I. Se eliminara de forma lógica, no fisica. En la pantalla de usuarios se podrá elegir uno y de ahí mismo se eliminara dando clic en el botón ELIMINAR. c. Modificar
I.
Se podrá modificar todos los datos del usuario excepto la clave del usuario, se podrá elegir en la pantalla de usuarios y al dar clic en MODIFICAR se mostrara otra pantalla en la cual se mostraran los datos existentes del usuario y se podrán cambiar. También contendrá los botones GUARDAR, CANCELAR y SALIR.
4. Modulo productos: Al momento de abrir el sistema se podrá observar todos los módulos. Si se acciona el modulo de productos aparecerá una ventana en donde se podrá realizar una búsqueda y consultar los datos que se desean y se mostraran los datos. En esta pantalla también podremos observar que se encuentran los botones de alta, baja, modificar. a. Dar de alta Al presionar el botón de alta aparecerá una pantalla se podrá introducir los datos que serán mencionados a continuación, misma pantalla que contendrá los botones de aceptar, cancelar y guardar. I. Clave del producto II. Nombre del producto III. Cantidad existente IV. Costo compra V. Porcentaje de ganancia VI. Precio venta VII. Status b. Dar de baja I. Los datos seleccionados serán eliminados de manera lógica; esta acción se podrá realizar solo accionando el botón de eliminar. c. Modificar I. Se modificaran todos los datos del producto solo por el administrador, esta acción se podrá realizar mediante el botón de modificar. 5. Modulo clientes: Cuando se ingrese al modulo se abrirá una pantalla en donde se muestren los clientes existentes y sus datos. En esta misma pantalla se podrá hacer la consulta de los mismos por medio de una búsqueda del nombre. En la parte inferior de esta pantalla se tendrán cuatro botones que serán: ALTA, BAJA, MODIFICAR y SALIR con una imagen que represente la acción del botón. a. Dar de alta Se introducirán los siguientes datos en una pantalla que se mostrara cuando se da un clic en el botón ALTA de la pantalla de Clientes. I. II. III. IV.
Clave del cliente Nombre Apellidos Edad
V. Dirección VI. Teléfono VII. Fecha de alta VIII. Status En esta misma pantalla en la parte superior existirán tres botones los cuales son: GUARDAR, CANCELAR y SALIR.
b. Dar de baja I. Se eliminara de forma lógica, no física. En la pantalla de usuarios se podrá elegir uno y de ahí mismo se eliminara dando clic en el botón ELIMINAR aparecerá una pantalla para confirmar la eliminación del usuario cuando que la ventana de confirmación tendrá 2 botones mas para ACEPTAR la eliminación o CANCELAR la eliminación. Si selecciona ACEPTAR se eliminara con un mensaje de cliente eliminado correctamente y si se CANCELA volverá a la pantalla principal de clientes. c. Modificar I. Se podrá modificar todos los datos del Cliente excepto la clave del Cliente, se podrá elegir en la pantalla de Clientes y al dar clic en MODIFICAR se mostrara otra pantalla en la cual se mostraran los datos existentes del usuario y se podrán cambiar. También contendrá los botones GUARDAR, CANCELAR y SALIR. En la pantalla principal del modulo de clientes se podrá realizar la consulta de estos. 6. Modulo proveedores: Al momento de abrir el sistema se podrá observar todos los módulos. Si se acciona el modulo de proveedores aparecerá una ventana en donde se podrá realizar una búsqueda y consultar los datos que se desean y se mostraran los datos. En esta pantalla también podremos observar que se encuentran los botones de alta, baja, modificar. a. Dar de alta Al momento de accionar el botón de alta que se encontrara en la pantalla del modulo de proveedores aparecerá otra ventana donde se podrán observar los siguientes datos: I. Id proveedor II. Empresa III. Fecha alta IV. Dirección V. Teléfono VI. Celular VII. Status En esta pantalla se podrá observar que contendrá los botones de aceptar, guardar y cancelar.
b. Dar de baja Al momento de accionar el botón de baja el dato seleccionado se eliminara lógica mente. c. Modificar Al momento de accionar el botón de modificar el sistema permitirá modificar los datos seleccionados. 7.
Modulo facturas a. Registro I. folioFactura II. idUsuario III. idventa IV. cliente V. rfcCliente VI. Productos VII. Cantidad VIII. totalVenta b. Cancelar
c. Modulo ventas d. Registro I. idVenta II. cliente III. usuario IV. productos V. cantidad VI. totalVenta e. Consulta f. Cancelación 8. cotizaciones a. Crear b. imprimir 9. Modulo compras a. Registro de compra I. Id compra II. Factura III. Proveedor IV. Fecha de compra V. Total de compra 10. Modulo movimientos a. Se guardara las operaciones realizadas por los usuarios diariamente I. Idmovimiento
