Calidad de Software

INSTITUTO TECNOLÓGICO SUPERIOR DE PUERTO VALLARTA

LICENCIATURA EN INFORMÁTICA

ASIGNATURA

CALIDAD DE SOFTWARE

DOCENTEMARIA DE LOS ANGELES LACES

PLAN DE DESARROLLO DE SOFTWARE

Grupo 6to “A”

Contenido

1. Introducción1.1 Propósito1.2 Alcance1.3 Definiciones, Acrónimos y Abreviaciones 1.4 Referencias1.5 Vista General

2. Vista General del Proyecto2.1 Alcance y Objetivos del Proyecto

2.1.1 Objetivos del proyecto2.1.2 Alcance del proyecto

2.2 Suposiciones y Restricciones2.3 Modelo del Ciclo de Vida del Proyecto2.4 Entregas del Proyecto

3. Organización del Proyecto3.1 Estructura Organizacional3.2 Interfaces Externas3.3 Roles y Responsabilidades

4. Proceso Administrativo4.1 Estimaciones del Proyecto

4.1.1 Técnica de estimación elegida4.1.2 Metodología4.1.3 Cuenta de Function Points

4.2 Plan del Proyecto4.2.1 Plan de Fase4.2.2 Objetivos de la Iteración4.2.3 Calendario del Proyecto

4.3 Recursos del Proyecto4.3.1 Recursos de Hardware4.3.2 Recursos de Software 4.3.3 Recursos Humanos 4.3.4 Presupuesto

4.4 Control y Monitoreo del Proyecto4.4.1 Introducción

4.4.1.1 Propósito4.4.1.2 Descripción del documento

4.4.2 Procesos de Control y Monitoreo4.4.2.1 Prerrequisitos4.4.2.2 Definición del proceso y mediciones4.4.2.3 Comunicar el análisis de resultados4.4.2.4 Definir la estrategia a seguir

4.4.3 Plan de Reportes4.5 Plan de Administración de Riesgos

4.5.1 Análisis del riesgo4.5.2 Planeación y monitoreo del riesgo

5. Plan de Procesos Técnicos5.1 Métodos, Herramientas y Técnicas

6. Planes de Soporte de los Procesos6.1 Plan de la Calidad

6.1.1 Introducción6.1.2 Responsabilidades del personal de calidad6.1.3 Estándares y productos aplicables6.1.4 Metas de la calidad del proyecto

6.2 Plan de Resolución de Problemas6.2.1 Conflictos de intereses6.2.2 Problemas técnicos

6.3 Plan de Comunicaciones6.3.1 Introducción6.3 .2 Matriz de comunicación

1. INTRODUCCION

1.1 PROPOSITOEn 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 ABREVIACIONESSCEB: 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 REFERENCIASRUP.- Documento de la metodología del Rational Unified Process®.

NOTA: El RUP es un proceso de desarrollo de 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 de un sistema de control escolar de 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 OBJETIVOS1. 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.

1.1. 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 alcance, la funcionalidad, las características y las

restricciones de diseño, cumpliendo en el tiempo determinado para esta etapa.

1.2. Administrar los cambios en requisitos, determinando el procedimiento a seguir y la validación del mismo.

2. Controlar los cambios en la configuración del producto de software, asegurando su integridad y optimizando así su evolución.

2.1. Administrar y controlar la configuración y cambios, mediante un control de versiones.

2.2. Auditar la configuración, verificando que las versiones actuales sean acordes a requerimientos específicos.

3. Identificar los aspectos que necesita el cliente para su implementación, creando la interfaz adecuada y conveniente a sus necesidades.

3.1. Ayudar al proceso de registro de los datos de los alumnos, sin necesidad de hacerlo manualmente.

3.2. Realizar en menos tiempo posible el registro de datos.

3.3. Realizar la base de datos correspondiente a toda la información que se incluirá en el software.

2.1.1 Alcance del proyecto

Dentro del alcance:

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:

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.

2.2 Suposiciones y Restricciones

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.

2.3 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. ORGANIZACIÓN DEL PROYECTO3.1 ESTRUCTURA ORGANIZACIONAL

Cinthy Encargado de la configuracion

de la Administracion

Mariana Plascencia Lider del proyecto

GustavoLíder de

implementación de electrónica

3.2 INTERFACES EXTERNAS

3.3 ROLES Y RESPONSABILIDADESROL RESPONSABILIDAD RESPONSABLERequisitos Realizar los documentos:

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.

MABEL Y NORMA

Análisis y Diseño

Analizar y proponer la arquitectura adecuada.Desarrollo de los Casos de UsoIdentificar e incorporar los Elementos de DiseñoEstructurar el Modelo de ImplementaciónDiseño de la Interfaz del UsuarioDiseño de ClasesDiseño de Base de DatosRealización Diagramas de Secuencia

ENRIQUE Y ANGEL

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

Gabriel Encargado

de Ambiente

Armando Líder de pruebas

Mabel Líder de Requisito

s

Norma Ayudante

Enrique Lider de Analisis y Diseño

MauroAyudante

Maritza Líder de

implementación de software

Angel Ayudante

administración del estacionamiento con base en lo establecido por el equipo de Análisis y Diseño.

Pruebas 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.

Ambiente 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.

Administración de la configuración

Crear el ambiente para la configuraciónLlevar 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.

Líder del Proyecto

Planear el proyectoValida 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 proyectoAdministra 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.Patrocinador 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 FinConceptualización 1 2 09/03/11 16/03/11

Elaboración 2 2 11/03/11 16/03/11

Construcción 2 4 18/03/11 30/03/11

Transición 1 1 30/03/11 30/03/11

4.2.2 Objetivos de la Iteración

Fase Iteración Descripción Hitos Asociados

Conceptualización 1Contar con todos los requisitos

Elaboración 1Elaboración 2 Surgieron confusiones

Construcción 1Construcción 2

Transición 1Entrega Satisfactoria al Cliente

4.2.3 Calendario del proyecto:Id Nombre Duración Comienzo Fin Asignado a1 PROYECTO 3 semanas 28/03/2011 28/03/2011 Mauro Bartolo Zavalza2 Ambiente 1 día 28/03/2011 28/03/2011 Mauro Bartolo Zavalza3 Identificar las Plantillas

requeridas1 día 28/03/2011 28/03/2011 Mauro Bartolo Zavalza

4 Verificar el Ambiente 1 día 28/03/2011 28/03/2011 Mauro Bartolo Zavalza5 Preparar las Plantillas 1 día 28/03/2011 28/03/2011 Mauro Bartolo Zavalza6 Instalar las Herramientas

en el Servidor1 día 28/03/2011 28/03/2011 Mauro Bartolo Zavalza

7 Mantener las Plantillas 1 día 28/03/2011 28/03/2011 Mauro Bartolo Zavalza8 Personalizar las

Herramientas en el Servidor

1 día 29/03/2011 29/03/2011 Ángel Fernando Barraza

9 Ejecutar las Herramientas (probar)

1 día 29/03/2011 29/03/2011 Angel Fernando Barraza

10 Proporcionar Herramientas a los Clientes


11 Integrar Herramientas 1 día 29/03/2011 29/03/2011 Angel Fernando Barraza12 Administración de la

Configuración1 día 29/03/2011 29/03/2011 Angel Fernando Barraza

13 Identificar los artefact de documentos, software, hardware


14 Definir el método de nombramiento


15 Definir el formato de control de versiones

1 día 30/03/2011 30/03/2011 Luis Enrique Amaral

16 Establecer las líneas de Base


17 Definir el procedimiento para el control de cambios


18 Definir el repositorio donde se integraran los artefact


19 Concentrar y registrar las transformaciones que se van teniendo en los artefact


20 Mantenter actualizado el repositorio con las versiones actuales


21 Auditorias 1 día 30/03/2011 30/03/2011 Mariana Sánchez22 Realizar reporte de

auditoria1 día 30/03/2011 30/03/2011 Mariana Sánchez

23 Realizar reuniones de Junta de Control de Cambios

1 día 31/03/2011 31/03/2011 Mariana Sánchez

24 Realizar solicitudes de Control de Cambios

1 día 31/03/2011 31/03/2011 Mariana Sánchez

25 Requisitos 1 día 31/03/2011 31/03/2011 Mariana Sánchez26 Planteamiento del

problema1 día 31/03/2011 31/03/2011 Mariana Sánchez

27 Análisis del sistema 1 día 31/03/2011 31/03/2011 Mariana Sánchez28 modificación o

mejora(Documento Visión)1 día 31/03/2011 31/03/2011 Angel Cabrera

29 Descripción de los requisitos de software

1 día 31/03/2011 31/03/2011 Angel Cabrera

30 modificación o mejora(Documentos Requisitos de Software)


31 Administración de requisitos


32 Programa de administración de requisitos


33 Capacitación y recursos 1 día 01/04/2011 01/04/2011 Angel Cabrera 34 Modificación o mejora

(Documentos Plan de Administración de requisitos)


35 Detallado de requisitos 1 día 01/04/2011 01/04/2011 Maritza Herrera36 Modificación o

mejora(Documento Matriz de Atributos de Requisitos )

1 día 01/04/2011 01/04/2011 Maritza Herrera

37 Descripción de especificaciones complementarias


38 Modificación o mejora(Documento de Especificaciones complementarias)


39 Análisis y Diseño 1 día 04/04/2011 04/04/2011 Maritza Herrera40 Recepción de Requisitos

funcionales1 día 04/04/2011 04/04/2011 Maritza Herrera

41 Análisis de casos de uso 1 día 04/04/2011 04/04/2011 Maritza Herrera

42 Realización de casos de uso 1 día 04/04/2011 04/04/2011 Emilio Heraldes 43 Evaluar resultados casos de

uso1 día 04/04/2011 04/04/2011 Emilio Heraldes

44 Crear un Diseño de clase inicial

1 día 05/04/2011 05/04/2011 Emilio Heraldes

45 Crear un Diseño de diagrama de entrega


46 Definir todos los elementos de la clase


47 Evaluar resultados Diag. Entrega


48 Evaluar resultados Diag. de clases


49 Evaluar resultados diag. casos de uso

1 día 05/04/2011 05/04/2011 Rocio Carrillo

50 Crear un Diseño de diagrama de componentes


51 Evaluar resultados diag. Componentes


52 Crear un Diseño de diagrama de secuencia inicial


53 Propuesta Inicial de la Base de Datos


54 Identificar eventos y señales de B.D.


55 Evaluar resultados secuencia


56 Identificar clases, clases activas y subsistemas

1 día 06/04/2011 06/04/2011 Cinty Marlene Alvarado

57 Integración del paquete 1 y 2


58 Recomendaciones Generales


59 Reuniones de revisión 1 día 07/04/2011 07/04/2011 Cinty Marlene Alvarado60 Asignación de

responsabilidades para la resolución de defectos


61 Electrónica 1 día 07/04/2011 07/04/2011 Cinty Marlene Alvarado62 Determinar herramientas

de trabajo1 día 07/04/2011 07/04/2011 Cinty Marlene Alvarado

63 Medio físico y Protocolo de comunicación

1 día 07/04/2011 07/04/2011 Blanca Sanchez

64 Generar el enlace bidireccional entre módulo electrónico y módulo software


65 Integración módulo software y


66 Pruebas y Validación 1 día 08/04/2011 08/04/2011 Blanca Sanchez67 Implementación 1 día 08/04/2011 08/04/2011 Blanca Sanchez68 Implementación del

prototipo1 día 08/04/2011 08/04/2011 Blanca Sanchez

69 definir el plan de integración


70 Establecer comunicación bidireccional mediante un proceso

1 día 08/04/2011 08/04/2011 Oswaldo Lopez

71 Implementación BD 1 día 08/04/2011 08/04/2011 Oswaldo Lopez72 Entradas 1 día 11/04/2011 11/04/2011 Oswaldo Lopez73 Login (Validación de Sktop

y Login encargado)1 día 11/04/2011 11/04/2011 Oswaldo Lopez

74 Login (Validación Web) 1 día 11/04/2011 11/04/2011 Oswaldo Lopez75 Interfaces Web 1 día 11/04/2011 11/04/2011 Oswaldo Lopez76 Salidas 1 día 11/04/2011 11/04/2011 Oswaldo Lopez77 Locales 1 día 11/04/2011 11/04/2011 Gustavo Garcia78 Usuarios 1 día 11/04/2011 11/04/2011 Gustavo Garcia79 Numeración 1 día 11/04/2011 11/04/2011 Gustavo Garcia

80 Descuentos 1 día 11/04/2011 11/04/2011 Gustavo Garcia81 Eliminación de Registros

Erróneos1 día 11/04/2011 11/04/2011 Gustavo Garcia

82 Informes Web 1 día 11/04/2011 11/04/2011 Gustavo Garcia83 Informes Archivo 1 día 11/04/2011 11/04/2011 Gustavo Garcia84 Integración 1 1 día 11/04/2011 11/04/2011 Armando Cabrera85 Pruebas Internas 1 día 11/04/2011 11/04/2011 Armando Cabrera86 Pruebas 1 día 12/04/2011 12/04/2011 Armando Cabrera87 Analizar los requerimientos

funcionales del sistema1 día 12/04/2011 12/04/2011 Armando Cabrera

88 Planeación de casos de pruebas

1 día 12/04/2011 12/04/2011 Armando Cabrera

89 Analizar el funcionamiento del sistema


90 Detectar funcionalidades no solicitadas en el documento de requerimientos


91 Registro de resultados 1 día 12/04/2011 12/04/2011 Mabel Bernabe92 Elaboración de checklist de

pruebas1 día 12/04/2011 12/04/2011 Mabel Bernabe

93 Reporte de resultados 1 día 13/04/2011 13/04/2011 Mabel Bernabe94 Realización de pruebas 1 día 13/04/2011 13/04/2011 Mabel Bernabe95 Análisis de reportes de

resultados1 día 13/04/2011 13/04/2011 Mabel Bernabe

96 Registro de resultados 1 día 13/04/2011 13/04/2011 Mabel Bernabe97 Identificar el área

correspondiente1 día 13/04/2011 13/04/2011 Mabel Bernabe

98 Reporte de resultados 1 día 13/04/2011 13/04/2011 Norma Lazareno99 Solicitud de correcciones 1 día 13/04/2011 13/04/2011 Norma Lazareno

100 Realizar pruebas relacionadas con la funcionalidad corregida

1 día 13/04/2011 13/04/2011 Norma Lazareno

101 Registro de resultados 1 día 14/04/2011 14/04/2011 Norma Lazareno

102 Reporte de resultados 1 día 14/04/2011 14/04/2011 Norma Lazareno103 Entrega 1 día 14/04/2011 14/04/2011 Norma Lazareno104 Describir las actividades de

entrega1 día 14/04/2011 14/04/2011 Norma Lazareno

105 Describir las instalaciones para la prueba y entrega al cliente

1 día 14/04/2011 14/04/2011 Gabriel Cervantes

106 Identificar las responsabilidades del grupo de desarrollo


107 Identificar el Hardware y Software para correr la aplicación


108 Calendarizar Metas de las actividades de entrega


109 Solicitar al área de Ambiente el Hardware y Software, y verificar que funcione


110 Entrega del documento al cliente y cada uno de los productos generados


111 Empaquetar 1 día 15/04/2011 15/04/2011 Gabriel Cervantes112 Demostración 1 día 15/04/2011 15/04/2011 Fernando Concepción113 Entrega al Cliente 1 día 15/04/2011 15/04/2011 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: $16,000.00

4.3 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.

$ 4,999.00

Impresora La impresora láser monocromática HP LaserJet 2015, USB, memoria 32MB, color y escala grises,

$ 3,450.00

Switch Switch Cnet 8 Puertos $ 249.00

Instalacin de Red $ 1,000.00

Costo del sistema $ 40,000.00

Mantto por visita $ 300.00

Total $ 57,458.00

4.3.3 Recursos humanos: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 procesoMODULO CONTROL DE ALUMNOS Este botón de control de ALUMNOS es

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 INSCRIPCIONES y 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 RESULTADOCONTROL DE ALUMNOS

Se da clic en la aplicación de CONTROL DE ALUMNOS

Nos manda a una pantalla de login el cual es el filtro que permite solo personal autorizado accedan al sistema.

FUNCIONAN CORRECTAMENTE.

Se introdujeron los datos correspondientes USUARIO y CONTRASEÑA.

Automáticamente manda la siguiente aplicación que es donde está la información de los alumnos

FUNCIONAN CORRECTAMENTE todas las actividades.

CONSULTAR, ACTUALIZAR y SALIR.

FUNCIONAN CORRECTAMENTE todas las actividades.

INFORMACIÓN DEL ALUMNO LA BUSQUEDA HA SIDO UN EXITOMODULO DOCENTE Se guardan los datos registrados

del docente,DATOS PERSONALES No se presento ningún problema para

el sistema y tampoco hacia el usuario.Se realiza la búsqueda por medio de un ID del docente.

DATOS PROFESIONALES. Se busca correctamente y no se presento ningún problema para el sistema y tampoco hacia el usuario.

Si ingresa un ID que no exista se muestra un mensaje.

DATOS PROFESIONALES NO SE ENCONTRO NINGUN REGISTRO.

DOCUMENTOS ENTREGADOS. GUARDAR. Guarda correctamente.BUSCAR. Presenta problemas de búsqueda y no

ARROJA NADA.

ACTUALIZAR NO ACTUALIZA y provoca problemas hacia el usuario y sistema.

INSCRIPICONES y REINSCRIPICONES

Se ingresa CONTRASEÑA Y Envía al modulo de INSCRIPCIÓN. FUNCIONAN CORRECTAMENTE.

Pregunta ¿que deseas hacer?INSCRIPCIÓN REINSCRIPCIÓN.

No se presento ningún problema para el sistema y tampoco hacia el usuario.

INSCRIPCION GUARDAR. Se produjo un error al realizar la operación: NO ES UN NOMBRE DE ARCHIVO VALIDO

PAPELEO GUARDAR. Se produjo un erro al realizar la operación: NO COINCIDEN LOS TIPOS DE DATOS EN LA EXPRESIÓN DE CRITERIOS

ACTUALIZAR EL RESGISTRO NO SE ENCUENTRA.CALIFICACIONES VER SEMESTRE.

VER KARDEXNo muestra las calificaciones ni por semestre, ni el kardex del alumno.

SUBIR CALIFICACIONES. Si hace el registro de calificaciones por alumno correctamente.

4.4.2.4 ANÁLISIS DE DATOS.MODULO EJECUCION RESULTADO

PANTALLA PRINCIAL CONTRASEÑAALUMNOS

REINSCRIPCIONDOCENTES

CALFICACIONESALUMNOS CONSULTAR

MOSTRARCONSULTAR MODIFICAR

DESHABILITARNO.CONTROL

REINSCRIPCION ALTAMODIFICACIÓNESPECIALIDAD

INGRESAR

DOCENTES ALTAMODIFICAR

BAJA

Pedir los datos al docenteActualizarClave docente

CALIFICACIONES ALMUNONO.CONTROL

KARDEXIMPRIME KARDEX

No. DocenteSubir 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.

"Stakeholder" Información Requerida Razón del requerimiento

Frecuencia / Fecha Requerida

Método de Entrega

Responsable

(Quien requiere) (Que Requiere) (Porque lo requiere) (Cuando lo requiere)

(Como lo requiere)

(Quien lo entrega)

Diseño

Documento de Requisitos Para poder realizar el diseño y arquitectura con los requisitos del cliente

Cada vez que sea actualizado

A través de archivo

electrónico por medio del espacio

Hotmail.com, o directamente

Equipo de requisitos

JCC

Solicitud de Cambio Para contar que el cambio solicitado en que se fundamenta y quien lo

solicita

Cada que se requiera un cambio

Físicamente por el equipo solicitante

Equipo que solicita cambio

Requisitos Solicitud de cambio autorizada Para que se especifique las modificaciones así

como quien lo solicita y el alcance de la misma

Cada que se requiera un cambio

Física Junta de Control de Cambios

Implementación

Documento de Diseño Para implementar en software lo diseñado

como solución para el cliente será la guía

Cada que se modifique el

documento diseño

A través de Administración de la configuración con el espacio

que cuenta Hotmail.com

Equipo de diseño

Pruebas

Requisitos Para verificar la congruencia entre lo

solicitado entre el cliente y lo diseñado así como el

diseño de pruebas

Cuando se emitan versiones o

revisiones nuevas

A través de Administración de la configuración con el espacio que cuenta en Hotmail.com

Equipo de requisitos

PruebasDiseño Para verificar la

congruencia entre lo Cuando se emitan

versiones o A través de

Administración de Equipo de Diseño

4.4.3 Análisis de comunicación

diseñado y lo desarrollado en software

y diseño de pruebas

revisiones nuevas la configuración con el espacio que cuenta en Hotmail.com

Pruebas Software Para realizar las pruebas diseñadas

Cuando se termine una iteración


Equipo de Implementación

Entrega Todos los documentos Para hacer la entrega formal al cliente del proyecto concluido

Al contar con los documentos finales


Todos los equipos

(requisitos, diseño,

implementación, pruebas, JCC)

4.5 Plan de Administración de Riesgos

4.5 .1 Plan de Riesgos

Nbr. Descripción del Riesgo P I C Descripción del Impacto

Acciones de Prevención

Acciones de Mitigación

Mala Interpretación de Un requisito M A I Fallas en el diseño e Revisar con los Reuniones de

implementación del Sistema por interpretación de requisitos

líderes de cada disciplina de modelo de RUP los requisitos presentados

revisión de requisitos y revisión de los líderes y pruebas de su implementación

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

Revisar cada uno de los requisitos del proyecto con el equipo de Implementación y diseño, estimando tiempo y costo

Negociar con el cliente alguna propuesta alternativa o que el tiempo de entrega se prolongue

Hacer pruebas a versiones anteriores B M M Doble trabajo Tener cuidado al elaborar las pruebas para asegurarnos de tener la versión más actualizada

Revisar detalladamente las pruebas realizadas

1 Integración de Herramientas B M M Que existan fallas de comunicación en la conexión de la aplicación con la base de datos

Realizar pruebas de comunicación de la aplicación con la base de datos

Verificar compatibilidad de versiones de los drives con la aplicación final.

1 Poco dominio de la tecnología Vb.net, retraso por la necesidad de investigar cómo implementar requisitos muy específicos

A 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

Buscar la solución del problema presentado entre todos los miembros del equipo para eficiente el tiempo de investigación y aprendizaje

4 Poca experiencia en la administración de proyecto provocara que se salgan de control las actividades del desarrollo

A M A El descontrol de las actividades evitara concentrarse en el desarrollo del proyecto, por tratar de volver a tener control

Mantener atención sobre el desarrollo de las actividades para detectar cualquier cambio brusco que pueda afectar el control

El líder dejara de lado su participación en el desarrollo y se concentra son lo en la administración y control

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

A M A Descuidos en implementación, pocas pruebas para depuración, entregas erróneas e incompletas,Fala de las entregas

Establecer un estándar en codificación , y una metodología de pruebas para detectar fallas antes de liberar versiones del producto

Planificar la forma de corregir el error presentado

1Conexión a la Base de Datos

M M AError de conexión de la aplicación de escritorio a la Base de Datos

Realizar las pruebas en diferentes equipos con el archivo de enlace

Checar el equipo que cumpla con los requerimientos

4Entregables A A I Faltante de uno de los

entregables.Integrar y estar al pendiente de la entrega en la fecha según el cronograma

Mostrar la versión anterior y presentar el plan de entrega con la corrección de lo que hizo falta

1Incumplimiento 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 Retraso grave en la entrega a implementación y por lo tanto retraso en la entrega del proyecto.

Realizar reuniones con los integrantes de los equipos y comprometiéndolos con las tareas que se les asignaron. Haciéndoles

Regresar el trabajo al integrante señalando los errores cometidos para que realice estas correcciones el más pronto

comprender que de 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.

posible (máximo 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.

2Cambios constantes en las versiones de requisitos y la incorrecta interpretación de estos en el área de diseño.

B B B Provocaría una implementación errónea y por lo tanto un producto diferente al que el cliente está solicitando.

Preguntando todas las dudas que se tengan acerca de los documentos de requisitos. Evitando 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

Realizar los cambios sugeridos por requisitos. Corregir lo que se interpretó y se representó de forma incorrecta en diseño.

diseño para detectar errores antes de que estos se trasladen a implementación.

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.

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

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.

base de datos, nombres de clase, atributos o métodos de preferencia.

4.5.2 Planeación y monitoreo del riesgo

descripción Responsable de ejecutar tiempoConocer y difundir Mapa de

riesgos del procesoLíder del proyecto continuo

Matriz de Clasificación de RiesgosP=Probabilidad, I= Impacto, C= Clasificación

Bajo Medio AltoAlta medio alto Inaceptable

Media bajo alto InaceptableBaja bajo medio altoprob

abilid

ad

Imapcto en el proyecto

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 equiposCada semana

Actualizar los estrategias de plan riesgo

Líder del proyecto continuo

5. PLAN DE PROCESOS TÉCNICOS

5.1. Métodos, herramientas y técnicas

MÉTODO TÉCNICAS HERRAMIENTASDeterminar 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.

Entrevistas. Cuestionarios. Revisión de

documentación del sistema.

Análisis de la información obtenida.

Pruebas al sistema.

Realizar entrevistas a las personas idicadas.

Planificacion Realizar pruebas al

sistema

Identificar los aspectos que necesita el cliente para su implementación, creando la interfaz adecuada y conveniente a sus necesidades.

Entrevistas. Cuestionarios. Revisión de

documentación del sistema.

Análisis de la información obtenida.

Visitas a la institucion para entrevistas personales.

Realizar entrevistas a las personas idicadas.

Planificacion Verificacion y analisis

Evaluación y prueba del sistema, generando reporte de resultados.

Pruebas físicas al sistema.

Verificación sistema-documentación.

Redacción de reporte final de resultados.

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:

Velar por el óptimo funcionamiento del Sistema SCEB Asegurarse de que se establecen, implementan y mantienen los procesos necesarios

para el Sistema SCEB

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:

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

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 PARA EL ANÁLISIS Y COLECCIÓN DE DATOS

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.

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.

EntrevistasTécnica que permitirá reunir información directamente con los involucrados del sistema.

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.)

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.

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:

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. Juntas de revisión

1.2 Asigne revisiones por compañeros cada vez que se considere un cambio al sistema.

1.3 Seleccione un documento riesgoso o una sección de código para las juntas semanales de revisión

1.4 Cada semana identifique a los evaluadores y programe juntas de revisión1.5 Los evaluadores deberán estudiar el material de forma individual por 2

horas1.6 Los evaluadores deberán reunirse para revisar el material por 2 horas1.7 Incluya notas de las juntas de revisión en el repositorio y dé seguimiento

a cualquier problema identificado en las juntas de revisión2. Pruebas al sistema 2.2 Diseñe y especifique un manual detallado del conjunto de pruebas2.3 Revise el conjunto de pruebas al sistema para asegurarse de que cada

pantalla de la interfaz del usuario o elemento es cubierto.2.4 Ejecute pruebas completas al sistema en cada candidato a entrega.

Estas pruebas al sistema serán ejecutadas en un equipo dedicado de QA.

2.5 Actualice las pruebas al sistema cada vez que los requerimientos cambien

2.6 Actualice este plan de pruebas cada vez que los requerimientos cambien2.7 Documente los resultados de las pruebas y comuníquelos a equipo de de

desarrollo completo2.8 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.

2.9 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 GeneralDiseñ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.

AlcancesEl 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

4.pruevas

5. Administración de la configuración.

6. Líder del proyecto.

7.patrocinador

Tipo (mandato, informativa,de mercado)

Se implementara especialmente en bachilleratos.

Dirigido a Método de entrega

Las entregas se harán de forma física.

Frecuencia de

entrega

Responsable1.mabel y norma2.enrique y ángel

3.Maritza ,mauro, Gustavo y

Oswaldo

4.armando y Emilio

5.Rocio y Cinthy

6.Mariana Plasencia7.SEP(secretaria de educación publica)

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 Guía el chequeo de la capacitación.1 Criterios de

Entrada SPMP (Plan de la gestión del proyecto

de software)2 Revisión Chequear que el staff de desarrollo del

software haya sido capacitado para realizar sus tareas.

Definir capacitaciones si es necesario.3 Criterios de

Salida 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 usuarioII. NombreIII. Apellido paternoIV. Apellido maternoV. DomicilioVI. TeléfonoVII. Tipo de usuario

2.1 el sistema permitirá elegir de una lista desplegable el tipo, para cada usuario.

I. AdministradorII. Empleado

Así mismo esta pantalla contendrá los botones de GUARDAR, CANCELAR y SALIR.

b. Dar de bajaI. 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 productoII. Nombre del productoIII. Cantidad existenteIV. Costo compraV. Porcentaje de gananciaVI. Precio ventaVII. Status

b. Dar de bajaI. 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 altaSe 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. Clave del clienteII. NombreIII. ApellidosIV. Edad

V. DirecciónVI. TeléfonoVII. Fecha de altaVIII. Status

En esta misma pantalla en la parte superior existirán tres botones los cuales son: GUARDAR, CANCELAR y SALIR.

b. Dar de bajaI. 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. ModificarI. 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 altaAl 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 proveedorII. EmpresaIII. Fecha altaIV. DirecciónV. TeléfonoVI. CelularVII. Status

En esta pantalla se podrá observar que contendrá los botones de aceptar, guardar y cancelar.

b. Dar de bajaAl momento de accionar el botón de baja el dato seleccionado se eliminara lógica mente.

c. ModificarAl momento de accionar el botón de modificar el sistema permitirá modificar los datos seleccionados.

7. Modulo facturas a. Registro

I. folioFacturaII. idUsuarioIII. idventaIV. clienteV. rfcClienteVI. ProductosVII. CantidadVIII. totalVenta

b. Cancelar

c. Modulo ventas d. Registro

I. idVentaII. clienteIII. usuarioIV. productosV. cantidadVI. totalVenta

e. Consultaf. Cancelación

8. cotizacionesa. Crearb. imprimir

9. Modulo comprasa. Registro de compra

I. Id compraII. FacturaIII. ProveedorIV. Fecha de compraV. Total de compra

10.Modulo movimientosa. Se guardara las operaciones realizadas por los usuarios diariamente

I. Idmovimiento

II. IdusuarioIII. OperaciónIV. fechaMovimiento

Date post:	04-Jul-2015
Category:	Documents
Upload:	schumii-garcia
View:	2,129 times
Download:	2 times

Calidad de Software

Documents