• Author / Uploaded
• FLORES CRUZ MELISSA MARÍA

Citation preview

FACULTAD DE CIENCIAS EINGENIERÍA INGENIERÍA DE SISTEMAS E INFORMÁTICA TEMA

“APLICACIÓN DE GESTIÓN ADMINISTRATIVA Y ACADÉMICA DEL COLEGIO 2048 JOSE CARLOS MARIATEGUI” CURSO: CALIDAD DE SOFTWARE

Propósito del trabajo: Trabajo Final Mg. Guevara Jiménez Jorge Alfredo ESTUDIANTES:  Polanco Santos Jair

código: 13101077

Los Olivos – Perú

2019- II

AGRADECIMIENTO A nuestras familias por hacer posible el estudio de nuestra carrera, para nuestro grupo de estudio, por fortalecer nuestras dificultades en algunas materias, a la dirección y comité del centro educativo, así mismo al Mg.

Guevara

Jiménez,

Jorge

Alfredo

por

su

asesoramiento haciendo posible la elaboración del presente proyecto de software de gestión administrativa y académica para un colegio y a nuestros compañeros

del VI ciclo de ingeniería de sistemas por su sugerencia y aprendizaje mutuo.

DEDICATORIA A nuestros padres por la gran formación que nos dieron, por hacernos las personas de bien que somos en la actualidad; muchos de nuestros logros se los

debemos

a

ellos.

Gracias

por

motivarnos

constantemente para alcanzar nuestros anhelos.

Tabla de contenido RESUMEN EJECUTIVO.............................................................................................8 ABSTRACT...................................................................................................................9 CAPITULO I. INTRODUCCION.............................................................................11 1.1.

Planteamiento y justificación del tema......................................................11

1.2.

Situación actual...........................................................................................11

1.3.

Problema......................................................................................................12

1.4.

Justificación.................................................................................................13

1.5.

Objetivos de la Investigación......................................................................13

1.5.1. Objetivo General.........................................................................................13 1.5.2. Objetivo Especifico......................................................................................13 1.6.

Metodología de la Investigación.................................................................13

1.7.

Limitaciones.................................................................................................14

1.8.

Alcance de la Investigación........................................................................14

CAPITULO II. MARCO TEORICO Y CONCEPTUAL........................................15 2.1.

Breve resumen de las herramientas...........................................................15

2.2.

Ventajas........................................................................................................19

2.3.

Desventajas..................................................................................................20

2.4.

Ciclo de vida del proyecto - PMBOK®.....................................................20

2.5.

Temáticas de las áreas de conocimiento de la dirección de proyectos. . .21

2.6.

Marco de trabajo ágil..................................................................................22

2.7.

Calidad de Software....................................................................................23

2.7.1. Calidad de los procesos...............................................................................23 2.7.2. Calidad del producto del software.............................................................24 2.8.

Ingeniería hacia el producto – técnica y herramienta.............................25

2.8.1. Enfoque cascada .........................................................................................26 2.8.2. Enfoque incremento....................................................................................26 CAPITULO III. INGENIERIA DEL PRODUCTO O DE DESARROLLO.........27 3.1.

Etapa de inicio.............................................................................................27

3.1.1. Descripción de la empresa..........................................................................27 3.2.

Etapa de planificación.................................................................................41

3.2.1. Desarrollo de principios de calidad de software.......................................42 Fecha: 25 de noviembre del 2019..........................................................................112 Componentes:.............................................................................................................115 Pruebas de regresión.................................................................................................116 Caso de prueba para el acceso a la aplicación -...........................................................118 Caso de prueba para la gestión de usuario-.................................................................119 Caso de prueba para la gestión de clases-...................................................................122 Las pruebas se llevarán a cabo de la siguiente forma:.................................................133 Secuencias de pasos para la generación de archivos para los módulos.......................133 Secuencias de pasos para la generación de datos para los tres módulos.....................133 1.

Convenciones......................................................................................................136

Capítulo IV Conclusiones y Recomendaciones.......................................................141 Conclusiones................................................................................................................141 Recomendaciones........................................................................................................143 Glosario.......................................................................................................................144 Prueba de caja negra. -.................................................................................................144 Prueba de caja blanca. -...............................................................................................144 Enfoque de pruebas. –.................................................................................................145 Recursos. -...................................................................................................................145 Herramienta de pruebas. -............................................................................................145 Referencias..................................................................................................................146

Índice de Tablas Tabla 1 Áreas de Conocimiento..............................................................................................22 Tabla 2: Requerimientos..........................................................................................................30 Tabla 3: Requerimientos de Matricula...................................................................................34 Tabla 4: Inscripciones de matricula........................................................................................36 Tabla 5: Gestión de Matricula.................................................................................................38 Tabla 6: Tabla de registro de Matriculas.................................................................................40 Tabla 7: Prueba 03...................................................................................................................51 Tabla 8 Versiones...................................................................................................................114 Tabla 9 Información del proyecto.........................................................................................114 Tabla 10 Aprobaciones..........................................................................................................114 Tabla 11 Pruebas....................................................................................................................117 Tabla 12 Pruebas - Estrategias..............................................................................................118 Tabla 13 Criterios..................................................................................................................119 Tabla 14 Lista de Entregables de Pruebas...........................................................................128 Tabla 15 Inserción de estudiante...........................................................................................128 Tabla 16 Tabla de porcentaje de cobertura.........................................................................129 Tabla 17 Recursos..................................................................................................................130 Tabla 18 Requerimientos de Entorno...................................................................................130 Tabla 19 Personal...................................................................................................................132 Tabla 20 Matriz de responsabilidades..................................................................................134 Tabla 21 Cronograma............................................................................................................135 Tabla 22 Premisas..................................................................................................................136 Tabla 23 Tabla de riesgos......................................................................................................136

Índice de Figuras Fig. 1 : Organizador SEQ Organizador \* ARABIC 1: Pasos del ciclo de un proyecto.........18 Fig. 2: XHTML y CSS: Estilos - Creación de una presentación de objetos.............................21 Fig. 3: Proceso de las capas: Comunicación entre capas.........................................................22 Fig. 4: Interacción de PHP: Como es el proceso de las peticiones..........................................23 Fig. 5: Organizador enfoque castada: (Almeida, 2015)...........................................................30 Fig. 6: Organizador enfoque Incremento: (Almeida, 2015)..................................................30 Fig. 7: Organigrama: Organización de la institución educativa 2048..................................32 Fig. 8: Privilegios del tipo de usuario administrador.............................................................34 Fig. 9: Diagrama Entidad relación..........................................................................................34 Fig. 10: Figura de Modelo de Base de Datos Relacional........................................................35 Fig. 11: Actores.........................................................................................................................35 Fig. 12: Casos de uso del usuario registrado..........................................................................36 Fig. 13: Casos de uso del Administrador..................................................................................36 Fig. 14: Caso de uso registro de estudiante............................................................................36 Fig. 15: Diagrama de estado de la matricula..........................................................................37 Fig. 16: Diagrama de secuencia...............................................................................................38 Fig. 17: Diagrama de Actividades...........................................................................................38 Fig. 18: Casos de uso de inscripciones de matrícula..............................................................39 Fig. 19: Diagrama de registro de alumnos..............................................................................39 Fig. 20: Diagrama de secuencia...............................................................................................40 Fig. 21: Diagrama de Actividades...........................................................................................40 Fig. 22: Gestión de matricula..................................................................................................41 Fig. 23: Diagrama de estado de Verificación de datos...........................................................41 Fig. 24: Diagrama de secuencia de Verificación de datos......................................................42 Fig. 25 Diagrama de Actividades de Verificación de datos...................................................42 Fig. 26: Caso de uso de Registro de matricula.......................................................................43 Fig. 27: Diagrama de Estado de registro de matriculas.........................................................43 Fig. 28: Diagrama de Secuencia de Ingreso de matricula.....................................................44 Fig. 29: Registro rápido de matricula.....................................................................................44 Fig. 30: EDT del software Escolar..........................................................................................45 Fig. 31: Nivel de calidad obtenida 01.....................................................................................46 Fig. 32: Nivel de calidad obtenida 02.....................................................................................47 Fig. 33: Nivel de calidad obtenida 03.....................................................................................48 Fig. 34: Nivel de calidad obtenida 04.....................................................................................49 Fig. 35: Nivel de calidad obtenida 05.....................................................................................50 Fig. 36: Nivel de calidad obtenida 06.....................................................................................51 Fig. 37: Nivel de calidad obtenida 07.....................................................................................52 Fig. 38: Nivel de calidad obtenida General............................................................................52 Fig. 39: Prueba 01....................................................................................................................53 Fig. 40: Prueba 02....................................................................................................................54

Fig. 41: Prueba 04....................................................................................................................55 Fig. 42: Prueba 05....................................................................................................................55 Fig. 43: Prueba 06....................................................................................................................56 Fig. 44: Prueba 07....................................................................................................................56 Fig. 45: Prueba 08....................................................................................................................56 Fig. 46: Prueba 09....................................................................................................................57 Fig. 47: Prueba 10....................................................................................................................57 Fig. 48: Prueba 11....................................................................................................................57 Fig. 49: Prueba 12....................................................................................................................58 Fig. 50: Prueba 13....................................................................................................................58 Fig. 51: Prueba 14....................................................................................................................58 Fig. 52: Prueba 15....................................................................................................................59 Fig. 53: Prueba 16....................................................................................................................59 Fig. 54: Prueba 17....................................................................................................................60 Fig. 55: Prueba 18....................................................................................................................60 Fig. 56: Prueba 19......................................................................................................................60 Fig. 57: Prueba 20....................................................................................................................61 Fig. 58: Prueba 21....................................................................................................................61 Fig. 59: Prueba 22....................................................................................................................61 Fig. 60: Prueba 23....................................................................................................................62 Fig. 61: Prueba 24 -1................................................................................................................62 Fig. 62: Prueba 24-2.................................................................................................................63 Fig. 63: Prueba 24-3.................................................................................................................63 Fig. 64: Prueba 25....................................................................................................................64 Fig. 65: Prueba 26....................................................................................................................64 Fig. 66: Prueba 27....................................................................................................................65 Fig. 67: Prueba 28....................................................................................................................65 Fig. 68: Prueba 29....................................................................................................................66 Fig. 69: Prueba 30....................................................................................................................66 Fig. 70: Prueba 31....................................................................................................................67 Fig. 71: Prueba 32....................................................................................................................67 Fig. 72: Prueba 33....................................................................................................................68 Fig. 73: Prueba 37....................................................................................................................68 Fig. 74: Prueba 38....................................................................................................................69 Fig. 75: Prueba 39....................................................................................................................69 Fig. 76: Prueba 40....................................................................................................................70 Fig. 77: Prueba 41....................................................................................................................70 Fig. 78: Prueba 42....................................................................................................................70 Fig. 79: Prueba 43....................................................................................................................71 Fig. 80: Código Fuente Nivel de calidad 01............................................................................72 Fig. 81: Código Fuente Nivel de calidad 02............................................................................73 Fig. 82: Código Fuente Nivel de calidad General...................................................................74 Fig. 83: Prueba 48....................................................................................................................75 Fig. 84: Prueba 49....................................................................................................................76 Fig. 85: Prueba 50....................................................................................................................76 Fig. 86: Prueba51.....................................................................................................................76 Fig. 87: Prueba 52....................................................................................................................77 Fig. 88: Prueba 54....................................................................................................................77

Fig. 89: Prueba 53....................................................................................................................77 Fig. 90: Prueba 55....................................................................................................................78 Fig. 91: Prueba 56....................................................................................................................78 Fig. 92: Prueba 57....................................................................................................................78 Fig. 93: Prueba 58....................................................................................................................79 Fig. 94: Prueba 59....................................................................................................................79 Fig. 95: Prueba 60....................................................................................................................79 Fig. 96: Prueba 61....................................................................................................................80 Fig. 97: Prueba 62....................................................................................................................80 Fig. 98: Hoja de código 01........................................................................................................81 Fig. 99: Hoja de código 02 - Hoja de código 03......................................................................82 Fig. 100: Hoja de código General............................................................................................83 Fig. 101: Prueba 63..................................................................................................................84 Fig. 102: Prueba 64..................................................................................................................85 Fig. 103: Prueba 65..................................................................................................................85 Fig. 104: Prueba 66..................................................................................................................86 Fig. 105: Prueba 67..................................................................................................................87 Fig. 106: Prueba 68..................................................................................................................88 Fig. 107: Prueba 69..................................................................................................................88 Fig. 108: Prueba 70..................................................................................................................89 Fig. 109: Prueba 71..................................................................................................................89 Fig. 110: Prueba 72..................................................................................................................90 Fig. 111: Prueba 73..................................................................................................................91 Fig. 112: Prueba 74..................................................................................................................92 Fig. 113: Prueba 75..................................................................................................................92 Fig. 114: Hoja de Comprobación Software 01.......................................................................93 Fig. 115: Hoja de Comprobación Software 02.......................................................................94 Fig. 116: Hoja de Comprobación Software 03.......................................................................95 Fig. 117: Hoja de Comprobación Software General..............................................................96 Fig. 118: Prueba 76..................................................................................................................97 Fig. 119: Prueba 77..................................................................................................................98 Fig. 120: Prueba 78..................................................................................................................99 Fig. 121: Prueba 79................................................................................................................100 Fig. 122: Prueba 80................................................................................................................101 Fig. 123: Prueba 81................................................................................................................102 Fig. 124: Prueba 82................................................................................................................103 Fig. 125: Prueba 83................................................................................................................104 Fig. 126: Calidad de Uso 01...................................................................................................105 Fig. 127: Calidad de Uso 02...................................................................................................106 Fig. 128: Calidad de Uso 03...................................................................................................107 Fig. 129: Calidad de Uso General..........................................................................................108 Fig. 130: Prueba 84................................................................................................................109 Fig. 131 : Prueba 85...............................................................................................................109 Fig. 132 : Prueba 86.................................................................................................................110 Fig. 133: Prueba 87................................................................................................................110 Fig. 134: Prueba 88................................................................................................................111 Fig. 135: Prueba 89................................................................................................................111 Fig. 136: Prueba 90................................................................................................................112

Fig. 137: Prueba 91................................................................................................................112 Fig. 138: Prueba 92................................................................................................................112 Fig. 139: Medición del Proceso 01.........................................................................................114 Fig. 140: Medición del Proceso General...............................................................................115 Fig. 141: Prueba 93................................................................................................................115 Fig. 142: Prueba 94................................................................................................................115 Fig. 143: Prueba 95................................................................................................................115 Fig. 144: Pruebas de Caja Negra 01......................................................................................122 Fig. 145: Pruebas de Caja Negra 02......................................................................................123 Fig. 146: Pruebas de Caja Negra 03......................................................................................123 Fig. 147: Pruebas de Caja Negra 04......................................................................................124 Fig. 148: Pruebas de Caja Negra 05......................................................................................124 Fig. 149: Pruebas de Caja Negra 06......................................................................................125 Fig. 150: Pruebas de Caja Negra 07......................................................................................125 Fig. 151: Pruebas de Caja Negra 08......................................................................................126 Fig. 152: Pruebas de Caja Negra 09......................................................................................126 Fig. 153: Pruebas de Caja Negra 10......................................................................................127 Fig. 154: Pruebas de Caja Negra 11......................................................................................127 Fig. 155: Pruebas de Caja Negra 12......................................................................................128 Fig. 156: Pruebas de Caja Negra 13......................................................................................128 Fig. 157: Pruebas de Caja Negra 14......................................................................................129 Fig. 158: Pruebas de Caja Negra 15......................................................................................129 Fig. 159: Pruebas de Caja Negra 16......................................................................................130 Fig. 160: El SRC del Software...............................................................................................140 Fig. 161: phpUnit test.............................................................................................................141 Fig. 162: Testing 01 – Pruebas de Caja Blanca....................................................................141 Fig. 163: Testing 02 – Pruebas de Caja Blanca....................................................................142 Fig. 164: Testing 03 – Pruebas de Caja Blanca....................................................................142 Fig. 165: Testing 04 – Pruebas de Caja Blanca....................................................................143 Fig. 166: Testing 05 – Pruebas de Caja Blanca....................................................................144

CERTIFICADO DE REVISIÓN DE ESTILO Y REDACCIÓN Documento: G.P-001 Nosotros, Rivera Quispe David y Polanco Santos Jair, certificamos: que revisamos la redacción y ortografía del contenido del proyecto de investigación: “APLICACIÓN DE GESTIÓN ADMINISTRATIVA Y ACADÉMICA DEL COLEGIO 2048 JOSE CARLOS MARIATEGUI”– Plataforma web para toda la gestión administrativa de los estudiantes en general” del distrito de Comas 2019. Propuesta: Diseño y elaboración de material impreso para prevención y orientación, elaborada por el alumno Polanco Santos Jair. Para el efecto he procedido a leer y a analizar de manera profunda el estilo y la forma del contenido del texto: ● ● ● ● ● ● ● ● ●

Se denota la pulcridad en la escritura en todas sus partes. La acentuación es toda precisa. Se utilizan los signos de puntuación de manera acertada. En todos los ejes temáticos se evitan los vicios de dicción. Hay concreción y exactitud en las ideas. No incurre en errores en la utilización de las letras. La aplicación de la sinonimia es correcta. Se maneja con conocimiento y precisión la morfosintaxis. El lenguaje es pedagógico, académico, sencillo y directo, por lo tanto, de fácil comprensión.

Por lo expuesto, y en uso de nuestros derechos como estudiantes, recomendamos la VALIDEZ ORTOGRÁFICA del proyecto previo a la presentación y evaluación del profesor.

..……………………

..………………….

Rivera Quispe David

Polanco Santos Jair

DECLARACIÓN DE AUTENTICIDAD Y DE NO PLAGIO Nosotros, Polanco Santos, Jair identificado con D.N.I. 70984656 y Rivera Quispe David identificado con D.N.I. 63594389 estudiantes de la FCI-UCH, autor(a/es) del proyecto de investigación: “APLICACIÓN DE GESTIÓN ADMINISTRATIVA Y ACADÉMICA DEL COLEGIO 2048 JOSE CARLOS MARIATEGUI” – Plataforma web para toda la gestión administrativa de los estudiantes en general” DECLARAMOS QUE: 1. El presente trabajo de investigación, tema presentado para la aprobación del curso es original, siendo resultado de nuestro trabajo personal, el cual no hemos copiado de otro trabajo de investigación, ni utilizado ideas, fórmulas, ni citas completas “stricto sensu”; así como ilustraciones diversas, sacadas de cualquier tesis, obra, artículo, memoria, etc., (en versión digital o impresa). Caso contrario, menciono de forma clara y exacta su origen o autor, tanto en el cuerpo del texto, figuras, cuadros, tablas u otros que tengan derechos de autor. 2. Declaramos que el trabajo de investigación que ponemos en consideración para evaluación no ha sido presentado anteriormente para obtener algún grado académico o título, ni ha sido publicado en sitio alguno. Somos conscientes de que el hecho de no respetar los derechos de autor y hacer plagio, es objeto de sanciones universitarias y/o legales, por lo que asumimos cualquier responsabilidad que pudiera derivarse de irregularidades en la tesis, así como de los derechos sobre la obra presentada. Asimismo, nos hacemos responsable ante la universidad o terceros, de cualquier irregularidad o daño que pudiera ocasionar, por el incumplimiento de lo declarado. De identificarse falsificación, plagio, fraude, o que el trabajo de investigación haya sido publicado anteriormente; asumo las consecuencias y sanciones que de mi acción se deriven, responsabilizándonos por todas las cargas pecuniarias o legales que se deriven de ello sometiéndonos a la normas establecidas y vigentes de la UCH. Los Olivos, del 25 de Noviembre del 2019

..……………………

..………………….

Rivera Quispe David

Polanco Santos Jair

RESUMEN EJECUTIVO En la actualidad los sistemas de gestión administrativa y académica para las instituciones educativas son de gran necesidad y demanda por tener una característica particular en razón al servicio educativo donde los ingresos principales son las matrículas y pensiones. La gestión de la actividad administrativa y académica de una institución educativa particular es fundamental para su avance y logro de su misión y visión educativa

que permite a la alta dirección realizar proyecciones en la

planificación de su presupuesto anual y mejoras en su servicio educativo. Por lo tanto, este proyecto tiene como objetivo pasar el respectivo control de calidad en el sistema de gestión administrativa y académica para la institución particular “2018 José Carlos Mariátegui”. Hemos visto abordar los siguientes puntos; la gestión de proyecto y la ingeniería de producto que serán los ejes que permitirán tener una visión general del trabajo y plantear una determinada solución como: Tener en cuenta la situación actual, análisis de la problemática, la justificación, el establecimiento de los objetivos, definición de la metodología de investigación, limitaciones, desarrollar la gestión de alcances, tiempo, costo, calidad, RR.HH, comunicación, riesgos, adquisiciones, interesados, ejecución del proyecto, seguimiento control y cierre. Donde abordaremos controles de Caja Negra y Caja blanca a través de la herramienta para control de llamada Code Coverage que testea la utilidad de códigos y luego nos da porcentajes de su uso, conociendo así si hay códigos innecesarios o que simplemente deben ser cambiados. Esperamos que este proyecto sea de su agrado, pueda cumplir sus expectativas y contribuir a posibles desarrollos de investigación relacionados a este tipo de trabajo. Abriendo una ventana de discusión sobre la implementación de sistema de gestión administrativa y académica para colegios y no tuvimos como fin cerrar la forma como el grupo desarrollará este proyecto, sino más bien abrir nuevas interrogantes. Por consiguiente, estamos sujetos a las observaciones y sugerencias que permitan mejorar el trabajo.

Las palabras claves son: Gestión de proyecto, Ingeniería de producto, áreas de conocimientos y etapas del proyecto

ABSTRACT Currently, the administrative and academic management systems for educational institutions are of great need and demand for having a particular characteristic due to the educational service where the main income are tuition and pensions. The management of the administrative and academic activity of a particular educational institution is fundamental for its advancement and achievement of its educational mission and vision that allows senior management to make projections in the planning of its annual budget and improvements in its educational service. Therefore, this project aims to pass the respective quality control in the administrative and academic management system for the particular institution "2018 José Carlos Mariátegui". We have seen the following points addressed; project management and product engineering which will be the axes that will allow us to have a general vision of the work and propose a specific solution such as: Taking into account the current situation, analysis of the problem, justification, establishment of objectives, definition of the research methodology, limitations, developing the management of scopes, time, cost, quality, HR, communication, risks, acquisitions, interested parties, execution of the project, monitoring, control and closure. Where we will approach controls of Black Box and White Box through the control tool called Code Coverage that tests the usefulness of codes and then gives us percentages of their use, thus knowing if there are unnecessary codes or simply must be changed. We hope that this project is to your liking, can meet your expectations and contribute to possible research developments related to this type of work. Opening a window of discussion on the implementation of administrative and academic management system for schools and we did not aim to close the way the group will develop this project, but rather open new questions. Therefore, we are subject to observations and suggestions to improve the work. The key words are: Project Management, Product Engineering, Knowledge Areas and Project Stages.

CAPITULO I. INTRODUCCION 1.1. Planteamiento y justificación del tema Los sistemas de programación de acuerdo a su funcionalidad cumplen un rol muy importante en las diferentes gestiones que realiza una institución educativa. Por esta razón el proyecto que se implantará en la institución educativa particular “COLEGIO 2048 JOSE CARLOS MARIATEGUI” está relacionado a un sistema de gestión administrativa y académica que organice los procesos de control de pagos de la matrícula y pensiones que realizan los padres de familia o apoderados y la planificación del año escolar. Las estrategias, métodos, medios de lenguaje de programación en JavaScript y el análisis para implementación del sistema permitirán lograr un óptimo funcionamiento en el procesamiento y administración de la información que serán los medios necesarios para el logro del desarrollo de este sistema de gestión administrativa y académica con la finalidad de brindar información eficiente y eficaz para la toma de decisiones de alta dirección de la institución

educativa

particular

“COLEGIO

2048

JOSE

CARLOS

MARIATEGUI”. La institución educativa tiene dos niveles primarios y secundarios conformados por grados y secciones, la cantidad máxima de estudiantes es de 20 por sección. Los pagos que realizan son por concepto de matrícula y pensiones que durante el año son 10 cuotas. La implementación de este sistema para este proyecto será mediante el uso del MySQL, arquitectura en capas, el uso de la plataforma PHP para el desarrollo del backend, el uso de algunas librerías o framework de JavaScript para el desarrollo del frontend, aplicación del AJAX y JSON, la planificación de cronogramas del sistema de pagos, la funcionalidad en razón al manejo, usuarios y registros, análisis de funciones del sistema e implementación de módulos

1.2. Situación actual La institución educativa particular COLEGIO 2048 JOSE CARLOS MARIATEGUI se encuentra en la siguiente dirección con sus respectivos datos.  Jr. Eduardo Correa 156 – Comas  Lima Perú  Telf: (51) 5364993  E-mail: [email protected]  Contacto: Eric Gustavo Coronel Castillo La I.E.P. “COLEGIO 2048 JOSE CARLOS MARIATEGUI”, desea alcanzar el más alto nivel académico y formativo del distrito, propiciando proyectos y actividades que evidencien el carácter innovador y formativo de sus educandos contribuyendo de esta manera al desarrollo del país. Además, desarrolla al educando de manera integral, fomentando que se desenvuelva en todos los aspectos intelectual, social y culturalmente. Busca dar respuesta a las necesidades y expectativas que sus alumnos necesitan para forjarse un futuro mejor, teniendo en cuenta la adecuación de los contenidos, una infraestructura adecuada y el uso de la tecnología de primera. Los procesos principales de las actividades de gestión de la institución educativa son: la matrícula, las pensiones o pagos y la planificación del año escolar. Considerando esta situación actual podremos proponer a la institución la implementación de un software que permita optimizar los procesos de gestión de las diferentes actividades institucionales. 1.3.

Problema En la institución educativa particular “COLEGIO 2048 JOSE CARLOS MARIATEGUI” se observó que el proceso de matrícula, pensiones o pagos, planificación del año escolar y sistema de evaluación eran gestionadas mediante un registro en Excel, Word e incluso utilizando su cuaderno para realizar ciertos planificaciones, esto hacía que las ejecuciones de estos procesos de gestión no sean tan rápida para las diferentes necesidades que tiene la institución, provocando ciertos retrasos en sus funciones, además los proceso para la

obtención de información eran lentas y limitadas a una computadora o cuaderno de apuntes. Los procesos de gestión observados no están interconectados por medio de un sistema de software donde permita optimizar los procesos de gestión de la institución a tiempo real para garantizar de manera óptima los objetivos o metas que se traza la empresa a corto o mediano plazo. Por esta razón al identificar este problema hemos visto por conveniente implementar un sistema de gestiona administrativa y académica. 1.4.

Justificación Implementar un sistema de gestión administrativa y académica para el colegio con la finalidad de mejorar la automatización y los tiempos de proceso de la información y reportes para el área de la alta dirección, logrando sistematizar la información de manera digital y a tiempo, logrando aportar de manera asertiva en las tomas de decisiones con el objetivo de apoyar en la misión y visión de la institución educativa.

1.5.

Objetivos de la Investigación 1.5.1. Objetivo General Implementar un sistema de gestión administrativa y académica para el colegio con la finalidad de mejorar la automatización y los tiempos de procesos en su gestión educativa. 1.5.2. Objetivo Especifico  Asegurar la calidad del software.  Desarrolla nuestras habilidades personales y como equipo en aseguramiento de la calidad.  Reconocer y aplicar las normas y estándares de calidad.

Metodología de la Investigación

EJECUCI ÓN

Costo Costo yy nivel nivel de de dotación dotación de de personal personal

1.6.

Salid as de la direc ción de

INICIO DEL PROYE CTO

CIER RE

PLANIFICA CION

Acta de const itució n del

Plan para la direc ción Tie

CONTRO L Entre gable s acept

Docum entos de proyect o

ecto

1.7.

ecto

o ecto

dos

Fig. 1 : Organizador SEQ Organizador \* ARABIC 1: Pasos del ciclo de un proyecto

Limitaciones

Las limitaciones que presenta el proyecto vendría hacer el nivel de calidad exigido de acuerdo a las posibles necesidades que se pueden presentar en la implementación del software, el tiempo disponible para las reuniones de equipo, limitaciones con respecto a situaciones tecnológicas (computadoras para hacer trabajos en equipo y disponibilidad de los laboratorios de la universidad en nuestros horarios libres) y apoyo económico para la implementación del sistema. 1.8. Alcance de la Investigación El alcance del presente trabajo tiene como finalidad implementar un sistema de gestión administrativa y académica para la institución educativa pública 2048 “José Carlos Mariátegui”. Este proyecto abarca diferentes módulos entre ello tenemos: La planificación del año escolar, los módulos de pagos, módulos de roles, módulo de seguridad, módulo de profesores, módulo de cursos, módulo de consulta y reportes de notas.

CAPITULO II. MARCO TEORICO Y CONCEPTUAL 2.1. Breve resumen de las herramientas 

ASP.NET ASP.NET es un modelo de desarrollo Web unificado que incluye los servicios necesarios para crear aplicaciones Web empresariales con el código mínimo. ASP.NET forma parte de .NET Framework y al codificar las aplicaciones ASP.NET tiene acceso a las clases en .NET Framework. El código de las aplicaciones puede escribirse en cualquier lenguaje compatible con el Common Language Runtime (CLR), entre ellos Microsoft Visual Basic, C#, JScript .NET y J#. Estos lenguajes permiten desarrollar aplicaciones ASP.NET que se benefician del Common Language Runtime, seguridad de tipos, herencia, etc ASP.NET incluye:  Marco de trabajo de página y controles  Compilador de ASP.NET  Infraestructura de seguridad  Funciones de administración de estado  Configuración de la aplicación  Supervisión de estado y características de rendimiento  Capacidad de depuración  Marco de trabajo de servicios Web XML  Entorno de host extensible y administración del ciclo de vida de las aplicaciones  Entorno de diseñador extensible



Microsoft SQL Server

Microsoft SQL Server es un sistema de manejo de bases de datos relacionales que le permitirá programar en entornos híbridos, ya sea de forma local o en la nube de Microsoft. En combinación con Microsoft Azuze, los elementos incorporados a SQL Server le proporcionan una fácil creación de soluciones ante problemas con las revisiones, los desastres y las copias de seguridad. Podrá, además, transferir bases de datos de una forma muy sencilla e intuitiva entre su entorno local y la nube. Es considerada como una de las bases de datos más seguras del mundo, por no decir la mejor, y su sistema de almacenamiento permite un rendimiento en las consultas muy superior al habitual. Todos los procesos de análisis, consulta, limpieza, formateo de datos y acceso se realizan a una velocidad que le sorprenderá. 

AJAX AJAX (Asynchronous Javascript and XML) es una técnica de desarrollo web que, al combinar una serie de tecnologías independientes, nos permite intercambiar información entre el servidor y el cliente (un navegador web) de forma asíncrona. Como resultado, obtenemos una navegación ágil, rápida y dinámica; y también la posibilidad de realizar cambios sobre una web sin necesidad de actualizarla. Las tecnologías independientes que lo hacen posible son:  JAVASCRIPT: Es la base fundamental que une estas tecnologías  XMLHttpRequest: Intercambio asíncrono  XML: Manipulación e intercambio de información  JSON: Alternativa de XML (Actualmente más usado que XML)  DOM: Document Object Model

Fig. 2: XHTML y CSS: Estilos - Creación de una presentación de objetos



Arquitectura de N Capas La programación por capas es una arquitectura cliente-servidor en el que el objetivo primordial es la separación de la lógica de negocios de la lógica de diseño; un ejemplo básico de esto consiste en separar la capa de datos de la capa de presentación al usuario. La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que sobrevenga algún cambio, sólo se ataca al nivel requerido sin tener que revisar entre código mezclado. Un buen ejemplo de este método de programación sería el modelo de interconexión de sistemas abiertos. Además, permite distribuir el trabajo de creación de una aplicación por niveles; de este modo, cada grupo de trabajo está totalmente abstraído del resto de niveles, de forma que basta con conocer la API que existe entre niveles. En el diseño de sistemas informáticos actual se suelen usar las arquitecturas multinivel o Programación por capas. En dichas arquitecturas a cada nivel se le confía una misión simple, lo que permite el diseño de arquitecturas escalables (que pueden ampliarse con facilidad en caso de que las necesidades aumenten). El diseño más utilizado actualmente es el diseño en tres niveles (o en tres capas). La Arquitectura en Tres Capas divide la aplicación en tres partes lógicas, con un grupo de interfaces perfectamente definidas. La Primera Capa o Capa de Presentación, consiste en una interfaz gráfica que reúne los aspectos de software enfocados a la interacción con los diferentes tipos de usuarios. Es decir, incluye el manejo y aspecto de las ventanas, la autentificación, el formato de los reportes, menús, gráficos y demás elementos multimedia. La Segunda Capa o Capa Intermedia, reúne los aspectos de software que automatizan los procesos de negocio. Conocida también como capa de la Lógica de la Aplicación. Recibe la entrada de la capa anterior, interactúa con los

servicios de datos para ejecutar las operaciones y envía el resultado procesado a la capa de presentación. La Tercera Capa o Capa de Datos, contiene los datos necesarios para la aplicación. Es la encargada de almacenarlos, recuperarlos y mantener su integridad. Estos datos consisten en cualquier fuente de información, incluido una base de datos de empresa como Oracle o MySQL, un conjunto de documentos XML o incluso un servicio de directorio como LDAP. Además del tradicional mecanismo de almacenamiento relacional de base de datos, existen muchas fuentes diferentes de datos de empresa a las que pueden acceder las

Fig. 3: Proceso de las capas: Comunicación entre capas

aplicaciones.



PHP PHP Es un lenguaje de programación del lado del servidor gratuito e independiente de plataforma, rápido, con una gran librería de funciones y mucha documentación. Un lenguaje del lado del servidor es aquel que se ejecuta en el servidor web, justo antes de que se envíe la página a través de Internet al cliente. Las páginas que se ejecutan en el servidor pueden realizar accesos a bases de datos, conexiones en red, y otras tareas para crear la página final que verá el cliente. El

cliente solamente recibe una página con el código HTML resultante de la ejecución de la PHP. Como la página resultante contiene únicamente código HTML, es compatible con todos los navegadores

Fig. 4: Interacción de PHP: Como es el proceso de las peticiones



MYSQL MYSQL es un sistema de gestión de base de datos relacional o SGBD. Este gestor de base de datos en multihilo y multiusuario, lo que le permite ser utilizado por varias personas al mismo tiempo, e incluso, realizar varias consultas a la vez, lo que lo hace sumamente versátil. Nació como una iniciativa de Software Libre y aún sigue ofreciéndose como tal, para usuarios particulares. Pero si se desea utilizarlo para promover datos en una empresa, se puede comprar una licencia, como un software propietario, que es autoría de la empresa patrocinante (Actualmente Oracle Corporation). La mayor parte del código se encuentra escrito en lenguaje C/C++ y la sintaxis de su uso es bastante simple, lo que permite crear bases de datos simples o complejas con mucha facilidad. Además, es compatible con múltiples plataformas informáticas y ofrece una infinidad de aplicaciones que permiten acceder rápidamente a las sentencias del gestor de base de datos.

2.2. Ventajas 

Fácil acceso a información requerida por el usuario (empleado) según su categoría.



Fiabilidad de gestión de las citas de acuerdo al día.



Optimización de recursos (tiempo de operaciones)



Portabilidad y usabilidad (permite realizar una petición de datos al servidor y recibirla sin necesidad de cargar la página entera)



Rapidez y ahorro de tiempo hacer más fluido el proceso.

2.3. Desventajas 

Temor, desconfianza: es normal que ante una nueva medida, en especial aquellas que necesitan la implementación de nueva tecnología (que puede ser desconocida por parte del personal) se ofrezca resistencia inicial.



Costos: un diseño de aplicación web se requiere de una cierta cantidad de dinero, por lo consiguiente algunas empresas no están dispuestas a pagar.



Algunas funciones a las que estamos acostumbrados en la navegación web pueden no funcionar como esperamos. Por ejemplo, el botón de atrás, guardar marcador o actualizar la página web en cualquier momento debido a que JavaScript debe estar activado en el navegador web para funcionar.

2.4. Ciclo de vida del proyecto - PMBOK® En todo desarrollo de un proyecto es importante considerar metodologías de trabajos, y para ello el equipo de investigación ha visto por conveniente trabajar con el ciclo de vida del proyecto considerando el PMBOK®. Por ello, en la guía para examen de jefes de proyectos Barato manifiesta que: El ciclo de vida del proyecto es un conjunto de fases del mismo, generalmente secuenciales y en ocasiones superpuestas, cuyo nombre y número se determinan por las necesidades de gestión y control de la organización u organizaciones que participan en el proyecto, la naturaleza propia del proyecto y su área de aplicación”, (Barato, 2015. p. 15)

Consideramos que todo proyecto tiene procesos que le permite poder realizar una adecuada gestión, control y evaluación de los resultados obtenidos en la aplicación de un proyecto. Además es necesario tener en cuenta las fases del proyecto porque permite direccionar adecuadamente el trabajo, observando los diferentes procesos que se van dando en el camino de la ejecución del proyecto. Por esta razón Barato sostiene que: Las fases del proyecto son divisiones dentro del mismo proyecto, donde es necesario ejercer un control adicional para gestionar eficazmente la conclusión de un entregable mayor. Las fases del proyecto suelen completarse de manera secuencial, pero en determinadas situaciones de un proyecto pueden superponerse. (Barato, 2015. p. 17)

Al tener en cuenta la importancia del ciclo de vida del proyecto, y de cómo tiene una alta incidencia, considerando de manera correcta las fases del proyecto, nos permitirá tener mayores posibilidades de una gestión eficaz, donde los resultados sean óptimos y reflejados en cada uno de los entregables. 2.5. Temáticas de las áreas de conocimiento de la dirección de proyectos Las áreas de conocimiento se centran principalmente a todo los procesos de gestión del proyecto entre las cuales se mencionan a las 10 áreas de conocimiento, para ello según (Barato, 2015) menciona los siguientes: Tabla 1 Áreas de Conocimiento

Gestión de la

Implica la toma de decisiones referidas a la asignación de los

integración

recursos, balancear los objetivos y entre las áreas de conocimiento manejar sus interdependencias.

Gestión del

Garantiza que el proyecto cuente con todo lo necesario para

alcance

completarlo, incluyendo los procesos requeridos en el proyecto. Su principal objetivo es definir y controlar qué se incluye y no se incluye en el proyecto

Gestión del

Administra los procesos necesarios para la finalización del proyecto a

tiempo

tiempo. Los procesos que incorpora son: Definición de las actividades, establecer las secuencias de las actividades, estimar los recursos de las actividades, programar la duración de las actividades, y desarrollar y controlar el cronograma.

Gestión de los

Contiene los procesos de estimar, presupuestar y controlar los costos,

costos

con la finalidad de que el proyecto ejecute con el presupuesto aprobado.

Gestión de la calidad

Aquí se determinan responsabilidades, objetivos y políticas de calidad, para que el proyecto ejecute satisfactoriamente.

Gestión de los

Aquí está la organización, gestión y conducción del equipo del

recursos

proyecto. Este equipo está conformado por personas a quienes se les

humanos

asigna sus roles y responsabilidades para completar el proyecto.

Gestión de las

Aquí se busca que la generación, recopilación, distribución,

comunicaciones

almacenamiento, recuperación y disposición final de la información del proyecto sean oportunos y adecuados.

Gestión de los

Se desarrolla la planificación de la gestión, la identificación, el

riesgos

análisis, la planificación de respuestas a los riesgos, así como su monitoreo, control y minimización en un proyecto.

Gestión de las

Se abarca los procesos de compra o adquisición de los insumos,

adquisiciones

bienes y servicios que se requiere para hacer realidad el proyecto.

Gestión de los

Se desarrollan los procesos que hacen posible la identificación de las

interesados

personas, grupos u organizaciones que puedan ser afectados o no en el proyecto. Se busca conocer y evaluar las expectativas de los interesados y su impacto en el proyecto.

2.6. Marco de trabajo ágil En estos tiempos el desarrollo de las habilidades personales y el trabajo ágil nos permite optimizar los diferentes procesos del área gestión de un proyecto, por tener un carácter de relación directa e indirecta con el equipo de trabajo y

personas interesadas en el desarrollo del proyecto, por tal razón, según la especialista en metodologías ágiles (Villan, Vanessa 2019) se puede decir que: Las metodologías ágiles son aquellas que permiten adaptar la forma de trabajo a las condiciones del proyecto, consiguiendo flexibilidad e inmediatez en la respuesta para amoldar el proyecto y su desarrollo a las circunstancias específicas del entorno. Las habilidades dentro del trabajo ágil que van teniendo las personas están en constante progreso por la razón que el ser humano en sus diferentes actividades de trabajo pasa experiencias que debe aprender a manejar. El comportamiento del ser humano por su naturaleza en dinámica ya que está en constante cambio es por ello la importancia de las habilidades de comunicativas y el trabajo ágil que permite fortalecer las trabajo en equipo y tener excelente resultados en los objetivos. 2.7. Calidad de Software Es el grado en el que producto SW incorpora un conjunto de características, definidas por la industria, de tal manera que se garantiza su eficiencia de uso, respecto a los requerimientos de los clientes. Las implicaciones de la calidad del software son:  Métricas  Inspecciones  Pruebas  Procesos. Estos son aplicados en el ciclo de desarrollo de un proyecto. Es decir calidad de software, implica evaluar dos ámbitos: el producto final y los procesos. 2.7.1. Calidad de los procesos Es el conjunto estructurado de actividades requeridas para desarrollar un sistema de software, los cuales son: especificaciones, diseño, validación, evolución, desarrollo y mantenimiento. Los procesos que se desarrollan son:

a)

Proceso de implementación y cambios

 Infraestructura de procesos  Ciclo de gestión de los procesos de software  Modelos para el proceso de implementación y cambio  Consideraciones prácticas b)

Definición de procesos

 Modelos de ciclo de vida del software  Procesos de ciclo de vida del Software  Modelos para el proceso de implementación y cambio  Adaptaciones y automatización c)

Evaluación de procesos

 Modelos de evaluación de los procesos  Métodos de evaluación del proceso d)

Medidas de productos y procesos

 Medición del proceso  Medición de productos de software  Calidad de los resultados de la medición  Modelos de información de software 2.7.2. Calidad del producto del software El modelo de calidad de producto que se destaca es: el ISO 25000, que especifica diferentes dimensiones de calidad de producto. El estándar está dividido en cuatro partes las cuales dirigen, realidad, métricas externas, métricas

internas y calidad en las métricas de uso y expendido. La calidad de software es un conjunto estructurado de características las cuales son las siguientes: A) Funcionalidad: complejidad, corrección e idoneidad. B) Rendimiento: comportamiento en el tiempo y utilización de recursos. C) Usabilidad: Inteligibilidad, aprendizaje, operabilidad, protección a errores de usuario, atractividad y accesibilidad. D) Fiabilidad: madurez, disponibilidad, tolerancia a fallos y capacidad de recuperación. E) Seguridad: confidencialidad, integridad, no repudio, autenticidad y responsabilidad. F) Mantenibilidad: modular, reusabilidad, analizabilidad, cambiabilidad y capacidad de ser probado. G) Portabilidad: Adaptabilidad, facilidad de instalación e intercambiabilidad. H) Compatibilidad: coexistencia e interoperabilidad. 2.8.

Ingeniería hacia el producto – técnica y herramienta Para el proceso del desarrollo en la ingeniería del producto tendremos 2 enfoques tomados como

técnicas y herramientas,

para el desarrollo del

producto del software, que lo detallaremos a continuación:

Fig. 5: Organizador enfoque castada: (Almeida, 2015)

2.8.1. Enfoque cascada 2.8.2. Enfoque incremento

CAPITULO III. INGENIERIA DEL PRODUCTO O DE DESARROLLO 3.1. Etapa de inicio 3.1.1.

Descripción de la empresa A. Antecedentes Los sistemas de programación de acuerdo a su funcionalidad cumplen un rol muy importante en las diferentes gestiones que realiza una institución educativa. Por esta razón el proyecto que se implantará en la institución educativa particular “COLEGIO 2048 JOSE CARLOS MARIATEGUI”

está

relacionado

a

un

sistema

de

gestión

administrativa y académica que organice los procesos de control de

pagos de la matrícula y pensiones que realizan los padres de familia o apoderados y la planificación del año escolar. Las estrategias, métodos, medios de lenguaje de programación en JavaScript y el análisis para implementación

del

sistema

permitirán

lograr

un

óptimo

funcionamiento en el procesamiento y administración de la información que serán los medios necesarios para el logro del desarrollo de este sistema de gestión administrativa y académica con la finalidad de brindar información eficiente y eficaz para la toma de decisiones de alta dirección de la institución educativa particular “COLEGIO 2048 JOSE CARLOS MARIATEGUI”. La institución educativa tiene dos niveles primarios y secundarios conformados por grados y secciones, la cantidad máxima de estudiantes es de 20 por sección. Los pagos que realizan son por concepto de matrícula y pensiones que durante el año son 10 cuotas. La implementación de este sistema para este proyecto será mediante el uso del MySQL, arquitectura en capas, el uso de la plataforma PHP para el desarrollo del backend, el uso de algunas librerías o framework de JavaScript para el desarrollo del frontend, aplicación del AJAX y JSON, la planificación de cronogramas del sistema de pagos, la funcionalidad en razón al manejo, usuarios y registros, análisis de funciones del sistema e implementación de módulos. Las palabras claves son: sistema de gestión administrativa y académica, MySQL, PHP, JavaScript, AJAX y JSON. B. Dirección Jr. Eduardo Correa 156 – Comas C. Ruc 20519347254 D. Apodera principal

Lic. Elizabeth Cardenas Rabinez como principal directora de la institución y encargada de velar por la educación y bienestar de los alumnos. E. Organigrama

Nº 1. 2. 3.

Requisitos El sistema deberá contar con un Hosting y Dominio El sistema deberá contar con una Base de Datos en mysql El sistema deberá contar con un usuario administrador

TIPO NO FUNCIONAL NO FUNCIONAL NO FUNCIONAL

4.

El sistema deberá registrar una sección.

FUNCIONAL

5.

El sistema deberá manipular el estado de la sección

FUNCIONAL

Fig. 7: Organigrama: Organización de la institución educativa 2048

6.

El sistema deberá mostrar las secciones registradas

El sistema deberáglobal manejar de búsqueda para 3.1.2. Descripción el filtros sistema 7. 8.

las secciones. El sistema deberá registrar, eliminar y actualizar los A) Requerimientos menús a los tipos de usuarios.

FUNCIONAL FUNCIONAL FUNCIONAL

9.

El sistema deberá manejar un login para usuarios

FUNCIONAL

10.

El sistema deberá registrar usuarios

FUNCIONAL

11.

El sistema deberá manejar tipos de usuario

FUNCIONAL

12.

El sistema deberá registrar apoderados

FUNCIONAL

13.

El sistema deberá registrar estudiantes

FUNCIONAL

14.

El sistema deberá manejar módulos

FUNCIONAL

15.

El sistema deberá registrar pagos

FUNCIONAL

16.

El sistema deberá manejar tipos de pago

FUNCIONAL

17. 18.

El sistema deberá calcular la hora de entrada, salida y tiempo en la sesión El sistema deberá manejar filtros de búsqueda para usuarios en el log

FUNCIONAL FUNCIONAL

19.

El sistema deberá registrar las matrículas

FUNCIONAL

20.

El sistema deberá calcular la mora que tiene un pago

FUNCIONAL

Tabla 2: Requerimientos

Nº 1. 2. 3.

El sistema deberá contar con un Hosting y Dominio El sistema deberá contar con una Base de Datos en mysql El sistema deberá contar con un usuario administrador

TIPO NO FUNCIONAL NO FUNCIONAL NO FUNCIONAL

4.

El sistema deberá registrar una sección.

FUNCIONAL

5.

El sistema deberá manipular el estado de la sección

FUNCIONAL

6.

El sistema deberá mostrar las secciones registradas

FUNCIONAL

7. 8.

El sistema deberá manejar filtros de búsqueda para las secciones. El sistema deberá registrar, eliminar y actualizar los menús a los tipos de usuarios.

FUNCIONAL FUNCIONAL

9.

El sistema deberá manejar un login para usuarios

FUNCIONAL

10.

El sistema deberá registrar usuarios

FUNCIONAL

11.

El sistema deberá manejar tipos de usuario

FUNCIONAL

12.

El sistema deberá registrar apoderados

FUNCIONAL

13.

El sistema deberá registrar estudiantes

FUNCIONAL

14.

El sistema deberá manejar módulos

FUNCIONAL

15.

El sistema deberá registrar pagos

FUNCIONAL

16.

El sistema deberá manejar tipos de pago

FUNCIONAL

17. 18.

3.1.3.

Requisitos

El sistema deberá calcular la hora de entrada, salida y tiempo en la sesión El sistema deberá manejar filtros de búsqueda para usuarios en el log

FUNCIONAL FUNCIONAL

19.

El sistema deberá registrar las matrículas

FUNCIONAL

20.

El sistema deberá calcular la mora que tiene un pago

FUNCIONAL

Diagramas de casos de uso

Fig. 8: Privilegios del tipo de usuario administrador

Fig. 9: Diagrama Entidad relación

Actores

Fig. 11: Actores

Los usuarios son todas aquellas personas que acceden al portal web a través de Internet sin necesidad de autentificarse. Los usuarios registrados son los alumnos y profesores del centro educativo y el administrador, que acceden a la intranet de la aplicación mediante un nombre de usuario y contraseña.

Casos de uso del usuario registrado

Fig. 12: Casos de uso del usuario registrado

Este tipo de usuario sólo puede realizar la acción de cerrar su sesión porque es la única funcionalidad que tiene en común los administradores.

Casos de uso del administrador

Fig. 13: Casos de uso del Administrador

Este tipo de usuario representa al administrador de la aplicación. Podrá realizar las acciones de registrar nuevos estudiantes, listar asignaturas, buscar asignaturas, editar asignaturas, combinar asignaturas, listar clases, editar clases, buscar clases, agregar estudiantes, listar estudiantes, buscar estudiantes y editar datos del estudiante.

Escenario N° 1: Requerimiento de registro del estudiante a) Caso de uso

Fig. 14: Caso de uso registro de estudiante

b) Especificación:

Tabla 3: Requerimientos de Matricula

Nombre:

Requerimiento de matrícula.

Actores:

Padre, secretaria.

Descripción:

Excepciones:

El Padre de familia hace su requerimiento de Matrícula a la secretaria. El formato debe estar diligenciado correctamente Por los estudiantes. La secretaria recepciona el requerimiento de Matrícula. Ninguna.

Subflujos:

Ninguna.

Postcondiciones:

Ninguna.

Precondiciones: Flujo:

c) Diagrama de Estado :

Fig. 15: Diagrama de estado de la matricula

d) Diagrama de secuencia:

Fig. 16: Diagrama de secuencia

e) Diagrama de Actividades:

Fig. 17: Diagrama de Actividades

Escenario N° 2: Llenar formato de Inscripción de Matrícula a) Casos de Uso

Fig. 18: Casos de uso de inscripciones de matrícula.

b) Especificaciones: Tabla 4: Inscripciones de matricula

Nombre: Actores: Descripción: Precondiciones: Flujo: Excepciones: Subflujos: Postcondiciones:

Llenar formato de inscripción de matrículas. Padre, secretaria. El Padre debe llenar el formato de inscripción o actualización de matrícula que contiene información personal. La inscripción o actualización de matrículas debe serEste llenada con información 1. formato es entregadoreal. al coordinador. Ninguna. Ninguna. Ninguna.

c) Diagrama de Estado:

Fig. 19: Diagrama de registro de alumnos

d) Diagrama de secuencia:

Fig. 20: Diagrama de secuencia

e) Diagrama de Actividades:

Fig. 21: Diagrama de Actividades

Escenario N° 3: Gestionar Matrícula. a) Casos de Uso

Fig. 22: Gestión de matricula

b) Especificaciones:

Tabla 5: Gestión de Matricula

Nombre: Actores:

Gestionar Matrícula. Secretaria, padre

Descripción:

La secretaria actualiza datos alumno, verifica la conformidad de la Información.

Precondiciones: Flujo:

La información académica implica el rendimiento académico del estudiante, observaciones. La secretaria debe llevar el orden de la información.

Excepciones:

Ninguna.

Subflujos:

Ninguna.

Postcondiciones:

Ninguna.

c) Diagrama de Estado

Fig. 23: Diagrama de estado de Verificación de datos

d)

Diagrama

Fig. 24: Diagrama de secuencia de Verificación de datos

de secuencia:

e) Diagramas de Actividad:

Fig. 25 Diagrama de Actividades de Verificación de datos

Escenario N° 4: Registra Matrícula. a) Casos de Uso

Fig. 26: Caso de uso de Registro de matricula

b) Especificación: Tabla 6: Tabla de registro de Matriculas

Nombre:

Registrar Matrículas.

Actores: Descripción:

Secretaria, Sistema. Secretaria Registra matrícula de Estudiante al Sistema. Tener acceso al sistema.

Precondiciones: Flujo: Excepciones: Subflujos:

La secretaria ingresa los datos en el sistema como administradora. Ninguna. Ninguna.

Postcondiciones:

Ninguna.

c) Diagrama de Estados:

Fig. 27: Diagrama de Estado de registro de matriculas

Diagrama de secuencia: d)

Fig. 28: Diagrama de Secuencia de Ingreso de matricula e) Diagrama de Actividades:

3.2.

Etapa de planificación

Fig. 30: EDT del software Escolar

3.2.1. Desarrollo de principios de calidad de software A) PRINCIPIOS DE INGENIERIA DE SOFTWARE

Fig. 31: Nivel de calidad obtenida 01

Fig. 32: Nivel de calidad obtenida 02

Fig. 33: Nivel de calidad obtenida 03

Fig. 34: Nivel de calidad obtenida 04

Fig. 35: Nivel de calidad obtenida 05

Fig. 36: Nivel de calidad obtenida 06

Fig. 37: Nivel de calidad obtenida 07 Fig. 38: Nivel de calidad obtenida General

1.1 ¿Se ha realizado los casos de uso del sistema? 1.2 ¿Se ha encontrado los actores del negocio?  Como se aprecia en la imagen tenemos el caso de uso general donde aparecen todos los actores que comprenden el negocio. 1.3 ¿Se

Fig. 39: Prueba 01

ha encontrado los trabajadores y entidades del negocio?  Como se aprecia en la imagen tenemos el caso de uso general donde aparecen todos los trabajadores y entidades que comprenden el negocio.

Fig. 40: Prueba 02

1.4 ¿Se han detallado los casos de uso del negocio?  Se puede apreciar el detalle del CUS para registrar la matricula. Tabla 7: Prueba 03

Nombre:

Registrar Matrículas.

Actores: Descripción:

Secretaria, Sistema. Secretaria Registra matrícula de Estudiante al Sistema. Tener acceso al sistema.

Precondiciones: Flujo: Excepciones: Subflujos:

La secretaria ingresa los datos en el sistema como administradora. Ninguna. Ninguna.

Postcondiciones:

Ninguna.

1.5 ¿Se han construido el modelo de análisis del negocio?  Si esta detallada en la documentación de los casos de uso. 1.6 ¿Se realizo el modelo del negocio cumpliendo las reglas?  Si en la documentación se aplica, el cumplimiento de reglas del negocio para la creación del sistema 1.7 ¿Se Mantiene un vocabulario en común en la documentación?  En la documentación hay palabras entendibles para cualquier profesional que aborde el sistema de colegio.

Fig. 41: Prueba 04

1.8 ¿Se han definido las actividades a automatizar?  Como podemos observar se va automatizo el proceso de la secretaria utilizando el sistema.

Fig. 42: Prueba 05

2.1 ¿Existe un equipo de software?  Como podemos apreciar el equipo del software

Fig. 43: Prueba 06

2.2 ¿El equipo cuenta con un líder de proyecto?  Como vemos el primero del equipo de trabajo es el líder del proyecto

Fig. 44: Prueba 07

2.3 ¿El equipo de ingeniería de software está capacitado para llevar a cabo las actividades de administración de requerimientos? 2.4 ¿Se han establecido una sola persona para agregar, eliminar, modificar los requerimientos del proyecto? 2.5 ¿El equipo de ingeniera de software se encargan de ubicar los requerimientos en el área que le corresponde? 2.6 ¿el equipo de ingeniería de software sigue un proceso documentado para la administración de los requerimientos? 2.7 ¿Existe un plan de requerimiento inicial desarrollado por el equipo de ingeniería de software? 2.8 ¿Se sigue un proceso documentado para realizar los cambios en el plan de los requisitos? 2.9 ¿El plan de requerimientos fue revisado formalmente por todo el equipo?

 Como se explica en el argumento de antecedentes del documento

Fig. 45: Prueba 08

3.1 ¿Hay una identificación de la necesidad de los problemas realizados  Como podemos apreciar en la problemática de la documentación

Fig. 46: Prueba 09

3.2 ¿Hay la necesidad de priorizar entre varios inconvenientes y necesidades?

Fig. 47: Prueba 10

3.3 ¿se han delimitado o descrito el problema o necesidad?

 Como se aprecia en las siguientes líneas de texto del documento haciendo énfasis en limitaciones.

Fig. 48: Prueba 11

3.4 ¿se ha analizado la información relacionada con el proyecto?

Fig. 49: Prueba 12

3.5 ¿se ha descrito y justificado el proyecto?

Fig. 50: Prueba 13

3.6 ¿se ha llevado a cabo un análisis de riesgo?  Se ha planteado una definición de riesgo tomadas en cada actividad

Fig. 51: Prueba 14

3.7 ¿se generó un plan de riesgo en base al análisis hecho?  como se puede apreciar se hizo un análisis de acuerdo a estos procesos

Fig. 52: Prueba 15

3.8 ¿se han hecho una valoración de la rentabilidad económica del proyecto? 3.9 ¿Se han realizado un análisis de Riesgo? 4.1 ¿Se ha realizado el diagrama de Caso de uso general?  Observamos el CUS general del administrado

Fig. 53: Prueba 16

4.2 ¿la implementación de las actividades de aseguramiento de calidad de software sigue una política organizada escrita?

Fig. 54: Prueba 17

4.3 ¿Existe un modelo de análisis y diseño? Como podemos apreciar tenemos diseño del modelo que usa el colegio.

Fig. 55: Prueba 18

4.4 ¿el sistema registra y actualiza a sus estudiantes?  Como se puede apreciar el sistema si registra y actualiza los datos de los estudiantes

Fig. 56: Prueba 19

4.5 ¿el sistema registra y actualiza a sus docentes?  Como se puede apreciar el sistema si registra y actualiza los datos en los docentes

Fig. 57: Prueba 20

4.6 ¿el sistema cumple con el otorgamiento de privilegios al software dependiendo el tipo de usuario al logearse?

Fig. 58: Prueba 21

4.7 ¿el sistema muestra un reporte detallado de las notas de los alumnos?  Como se puede apreciar muestra el reporte de notas del alumno jair 4.8 ¿El sistema posee base de datos relación

Fig. 59: Prueba 22

Fig. 60: Prueba 23

4.9 ¿Se ha validado las pruebas del sistema?  Como se puede apreciar se ha validado si el sistema agrega tarifas, agrega bancos, agrega clases

Fig. 62: Prueba 24-2

Fig. 63: Prueba 24-3

5.1 ¿Se realizo el proceso de Pruebas definido para el proyecto de software? 5.2 ¿el software satisface los requerimientos? 5.3 ¿Hay consistencia entre los procesos del software?

5.4 ¿Las actividades y productos de la ingeniería de software del producto están siendo verificadas por el equipo de aseguramiento de calidad de software? 5.5 ¿la documentación usada para operar y mantener el producto de software es desarrollada y mantenida de acuerdo al proceso establecido? 5.6 ¿Se han asignado la cantidad de recursos y herramientas necesarias para realizar las actividades de ingeniería de software? 6.1 ¿Han recibido orientación de los aspectos técnicos del proyecto los administradores del software? 6.2 ¿Hay Manual de Usuario?  Como se puede apreciar si existe el manual de usuario

Fig. 64: Prueba 25

6.3 ¿Hay manual de administración?  Como se puede apreciar se cuenta con el manual para la administración del sistema de colegio

Fig. 65: Prueba 26

7.1 ¿El equipo de ingeniería de software se encarga de asegurar que los cambios en los requerimientos estén documentados, planeados, que hayan sido comunicados a los afectados y darle un seguimiento hasta su culminación?  Como se puede apreciar el equipo de trabajo realiza los cambios siguiendo esta secuencia para el proceso de administración de requerimientos

Fig. 66: Prueba 27

7.2 ¿Hay alguien encargado de mantener distintas versiones del proyecto cada vez que se realiza un cambio en los procesos?  Como se puede apreciar el encargado de dirigir el proyecto es el scrum master

Fig. 67: Prueba 28

7.3 ¿Se sigue un proceso documentada para realizar cambios en el plan de requerimiento inicial?  Como se puede apreciar que se trabaja con la planificación de los sprint

Fig. 68: Prueba 29

7.4 ¿Los cambios realizados al plan de requerimientos son revisados e incorporados al proyecto de software? Se siguió el siguiente plan de tareas para el proyecto de software

Fig. 69: Prueba 30

7.5 ¿Los acuerdos realizados y cambios a los acuerdos establecidos por el equipo de ingeniería de software con grupos externos han sido evaluados por la administración de acuerdo a un procedimiento documentado?  Como se puede apreciar se siguió las siguientes fases para la administración de procedimientos documentados

8.1 ¿Existen actividades de seguimiento para las actividades de ingeniería de software y se llevan a cabo acciones correctivas cuando hay problemas?

Fig. 71: Prueba 32

8.2 ¿Existen actividades de seguimiento para las fechas de entrega y se llevan a cabo acciones correctivas cuando hay problemas?

Fig. 72: Prueba 33

8.3 ¿El equipo de aseguramiento de calidad de software revisa periódicamente?

8.4 ¿Han sido documentadas y guardadas las métricas de desempeño y los datos usados para los cambios de la planeación?

Fig. 74: Prueba 38

8.5 ¿El plan de desarrollo de software ha sido documentado?

Fig. 75: Prueba 39

9.1 ¿Existe un equipo o gente encargada de llevar a cabo las actividades de aseguramiento de calidad de software?

9.2 ¿La organización debe contar con una red de computadoras con una capacidad mayor de 8GB RAM?

Fig. 76: Prueba 41

9.3 ¿EL sistema trabaja con múltiples frameworks en el entorno de desarrollo?

Fig. 77: Prueba 42

9.4 ¿Existe un entorno coherente de programación orientada a objetos?

B) PRINCIPIOS DE CODIGO FUENTE

Fig. 79: Código Fuente Nivel de calidad 01

Fig. 80: Código Fuente Nivel de calidad 02

Fig. 81: Código Fuente Nivel de calidad General

1.1.1.

Todas las variables el programa se inician antes de usar sus valores

Fig. 82: Prueba 48

1.1.2. 1.1.3.

todas las constantes tienen nombre? el tamaño de los arreglos es superior a 1?

1.1.4.

si se usan cadenas de caracteres ¿se asigna explícitamente un delimitado?

1.1.5.

¿Existe alguna posibilidad de desbordamiento de buffer?

Fig. 83: Prueba 49

Fig. 84: Prueba 50

Fig. 85: Prueba51

1.1.6.

para cada enunciado convencional ¿la condición es correcta?

1.1.7.

¿hay certeza de que termine cada ciclo en la variable?

1.1.8.

¿Los enunciados compuestos están correctamente colocados entre paréntesis?

Fig. 86: Prueba 52

Fig. 87: Prueba 54

Fig. 88: Prueba 53

1.1.9.

¿en caso de enunciados se justifican todos los casos posibles?

Fig. 89: Prueba 55

1.1.10. ¿si después de cada caso en los enunciados se requiere un paréntesis, este se incluyó?

Fig. 90: Prueba 56

1.1.11. ¿Se usan todas las variables de entrada 1.1.12. a todas las variables de salida se les asigna un valor antes de que se

Fig. 92: Prueba 58

Fig. 91: Prueba 57

produzca

1.1.13. ¿Entradas inesperadas pueden causar corrupción?

Fig. 93: Prueba 59

1.1.14. Se usan todas las variables de entrada

Fig. 94: Prueba 60

1.1.15. a todas las variables de salida se les asigna un valor antes de que se produzca

Fig. 95: Prueba 61

1.1.16. ¿Entradas inesperadas pueden causar corrupción?

Fig. 96: Prueba 62

C) HOJA DE CODIGO

Fig. 97: Hoja de código 01

Fig. 98: Hoja de código 02 - Hoja de código 03

1. ¿Qué proporción de los requerimientos del tipo Administrador se realizan correctamente en el software?

Fig. 100: Prueba 63

2. ¿Qué proporción de los requerimientos del tipo Encargado personal se realizan correctamente en el software?

Fig. 101: Prueba 64

3. ¿Cuál es la frecuencia de errores en la Base de datos (Subida de archivos) en el módulo de Datos del software? 4. ¿Cuál es la frecuencia de errores en la Disponibilidad (Conexión: ¿Servidor-Internet) del software? 5. ¿Los datos de los estudiantes son registrados con normalidad?

Fig. 102: Prueba 65

6. ¿La información registrada está totalmente relacionada con sus participantes?

Fig. 103: Prueba 66

7. ¿Es fiable la información mostrada de los estudiantes realizados?

Fig. 104: Prueba 67

8. ¿El porcentaje es fiable gracias al proceso de la información de datos registrados por estudiante?  El sistema cuenta con información detalla la cual mejora la fiabilidad de los procesos en el sistema

Fig. 105: Prueba 68

9. ¿En el módulo de docentes se registra, actualiza y lista correctamente la información?

Fig. 106: Prueba 69

10. ¿Las cuentas de los usuarios están guardadas y protegidas en la base de datos con un cifrado de seguridad?

Fig. 107: Prueba 70

11. ¿El módulo de estudiantes está cumpliendo el 100% de las necesidades del cliente?  como se puede apreciar el sistema cuenta incluso con el módulo de impresiones para los reportes de estudiantes

Fig. 108: Prueba 71

12. ¿Las funcionalidades del registro de Datos del colegio están bien detallados y fáciles de manipular?  Interface amigable con el usuario

Fig. 109: Prueba 72

13. ¿Cuál es la incidencia de daño económico?

14. 15. 16. 17. 18. 19. 20.

¿El software permitió reducir los gastos administrativos realizado manualmente? ¿Cuál es la frecuencia de problemas de salud de los usuarios que utilizan el producto? ¿Cuál es la incidencia de la corrupción del software? ¿Cuál es la incidencia de riesgo para las personas que utilizan el sistema? ¿El software afecta de manera directa o indirecta al medio ambiente? ¿Cuenta con planes de contingencias para reducir o evitar riesgos ambientales? ¿El software cumple con los objetivos especificados (Seguridad Informática las 24 horas y 7 días a la semana) sin ningún riesgo en el contexto de Aplicación Web en Celulares?

Fig. 110: Prueba 73

21. ¿El software cumple con los objetivos especificados (Disponibilidad de uso las 24 horas y 7 días a la semana) sin ningun riesgo en el contexto de Aplicación Web en Celulares?

22. ¿El software es flexible a las posibles integraciones o cambios de funcionalidad del módulo de estudiantes?  El sistema es fiable a todos los posibles cambios que se requieran en posteriores requerimientos

Fig. 111: Prueba 74

23. ¿El software es flexible a su implementación en una nueva plataforma (Smart Tv)?  El sistema es responsive

Fig. 112: Prueba 75

D) HOJA DE COMPROBACIÓN SOFTWARE

Fig. 113: Hoja de Comprobación Software 01 Fig. 114: Hoja de Comprobación Software 02

1. ¿Las funcionalidades de los módulos del software han sido completadas para su uso, según el tipo de usuario?

Fig. 116: Hoja de Comprobación Software General

Fig. 117: Prueba 76

2. ¿Las funcionalidades de los módulos del software brindan los reportes y resultados esperados?

Fig. 118: Prueba 77

3. ¿El software cumple con todos los privilegios para cada tipo de usuario?

Fig. 119: Prueba 78

4. ¿El software cumple con los tiempos de respuesta, procesamiento y ratios de rendimientos que se han establecido? 5. ¿El software tiene los recursos necesarios parar realizar sus funciones bajo las condiciones determinadas? 6. ¿El software puede compartir recursos comunes con otro software independiente en un mismo entorno? 7. ¿El software tiene la capacidad de intercambiar información con otros softwares y usarla en sus procesos? 8. ¿El software tiene la capacidad para permitir al usuario entender si es adecuado para sus necesidades? 9. ¿El software tiene la capacidad de ser entendido por sus usuarios(intuitiva)? 10. ¿El software tiene la capacidad de permitir al usuario operarlo y controlarlo con facilidad?

Fig. 120: Prueba 79

11. ¿El software tiene la capacidad de proteger a los usuarios de cometer errores(intuitivo)? 12. ¿Los módulos de interfaz para cada usuario resulta agradable y satisface la iteración con el mismo?

13. ¿El software tiene la facilidad para ser utilizado por personas con determinadas discapacidades?

Fig. 121: Prueba 80

14. ¿Los resultados brindados por el software son totalmente fiables? 15. ¿los datos secundarios de (datos de curso, tipos de usuario, etc.) que se necesitan para los procesos del software, son mostrados para su inserción de datos? 16. ¿el software presenta la capacidad para operar según la presencia de fallos de hardware y software? 17. ¿el software tiene la finalidad de guardar copias de seguridad de manera automática? 18. ¿El software tiene la protección necesaria contra el acceso a datos e información no autorizada? 19. ¿El software tiene la capacidad para prevenir accesos o modificaciones no autorizados a datos o programas de ordenador? 20. ¿El software permite probar la participación de las diferentes partes de una comunicación teniendo en cuenta el origen y el destino de dichas acciones? 21. ¿el software cuenta con log de sesiones?

Fig. 122: Prueba 81

22. ¿el software cuenta con corrección de datos erróneos? 23. ¿El software está compuesto de componentes discretos que permitan cambios y tengan un impacto mínimo en los demás? 24. ¿El software puede ser utilizado en otros sistemas o construcción de la base? 25. ¿El software presenta facilidad para ser evaluado ante determinados cambios y tener diagnósticos de deficiencia o causas de fallos? 26. ¿El software permite ser modificado de forma efectiva y eficiente sin introducir defectos y grados de desempeño? 27. ¿El software permite establecer criterios de prueba para un sistema o componentes? 28. ¿El Software es responsive desing en cualquier ordenador y compatible con cualquier hardware? 29. ¿El software se puede instalar y desinstalar de manera fácil y rápido sin ningún problema?

Fig. 123: Prueba 82

30. ¿El software puede remplazar de manera óptima otro software cumpliendo el mismo objetivo?  El sistema fue realizado con le extensión php y puedo migrar a otros entornos de dasrollo

E) Calidad de Uso

Fig. 125: Calidad de Uso 01

Fig. 126: Calidad de Uso 02

Fig. 127: Calidad de Uso 03

Fig. 128: Calidad de Uso General

1. ¿Qué proporción de los requerimientos del tipo Administrador se realizan correctamente en el software de colegio? Como apreciamos en la imagen, uno de los requerimientos principales de tipo administrador es registrar a los estudiantes de la I.E.

Fig. 129: Prueba 84

2. ¿Qué proporción de los requerimientos del tipo Encargado personal se realizan correctamente en el software de colegio? Las sesiones que funciones muy bien para los estudiantes es el requerimiento encargado del personal para el software

Fig. 130 : Prueba 85

3. ¿Cuál es la frecuencia de errores en la Base de datos (Subida de archivos) en el módulo de registros de notas? 4. ¿Cuál es la frecuencia de errores en la Disponibilidad (Conexión: ¿Servidor-Internet) del software de colegio? 5. ¿Los datos de los participantes son registrados con normalidad según la campaña realizada por los centros? Todos los datos son registrados y para probar eso podemos visualizar el registro de los estudiantes registrados.

Fig. 131 : Prueba 86

6. ¿La información registrada de datos de estudiantes está totalmente relacionada con sus participantes? Todo registro de un estudiante está relacionado con otros campos colmo apoderado y clases que lleva.

Fig. 132: Prueba 87

7. ¿El porcentaje de riesgo parar los datos de los escolares es fiable gracias al proceso de seguridad en información de datos registrados por el software de colegio? Los datos del software están encriptados con MD5 para una mayor seguridad.

Fig. 133: Prueba 88

8. ¿En el módulo de registros de estudiantes, se registra, actualiza y lista correctamente la información?

Fig. 134: Prueba 89

9. ¿Las cuentas de los usuarios están guardadas y protegidas en la base de datos con un cifrado de seguridad?

Fig. 135: Prueba 90

10. ¿El módulo de registros de estudiantes está cumpliendo el 100% de las necesidades del cliente?

Fig. 136: Prueba 91

11. ¿Las funcionalidades del registro de estudiantes están bien detallados y fáciles de manipular?

Fig. 137: Prueba 92

12. ¿Cuál es la incidencia de daño económico? 13. ¿El software permitió reducir los gastos administrativos realizado manualmente? 14. ¿Cuál es la frecuencia de problemas de salud de los usuarios que utilizan el producto? 15. ¿Cuál es la incidencia de la corrupción del software? 16. ¿Cuál es la incidencia de riesgo para las personas que utilizan el sistema? 17. ¿El software afecta de manera directa o indirecta al medio ambiente? 18. ¿Cuenta con planes de contingencias para reducir o evitar riesgos ambientales? 19. ¿El software cumple con los objetivos especificados (Seguridad Informática las 24 horas y 7 días a la semana) sin ningún riesgo en el contexto computacional? 20. ¿El software cumple con los objetivos especificados (Disponibilidad de uso las 24 horas y 7 días a la semana) sin ningún riesgo en el contexto computacional? 21. ¿El software es flexible a las posibles integraciones o cambios de funcionalidad del módulo de Registros de Estudiantes? 22. ¿El software es flexible a su implementación en Tablet?

Fig. 138: Medición del Proceso 01

F) Medición de proceso

Fig. 139: Medición del Proceso General

Fig. 140: Prueba 94

Fig. 141: Prueba 93

Fig. 142: Prueba 95

G) Plan de pruebas de software

JOSE CARLOS MARIATEGUI– SISTEMA DE ADMINISTRACION DE COLEGIO

Fecha

Autor

Organización

Descripción

25-11-2019

Versi ón 1

David Rivera Quispe

Calidad de Software

Desarrollo del plan de pruebas

25-11-2019

2

David Rivera Quispe

Calidad de Software

Desarrollo del plan de pruebas

Fecha: 25 de noviembre del 2019

Tabla 8 Versiones

Tabla 9 Información del proyecto

Empresa / Organización

Colegio Mundo Infantil

Proyecto

Sistema de administración escolar

Fecha de preparación

25-11-2019

Cliente

Colegio José Carlos Mariátegui

Patrocinador principal

Olga Arguedas Segura

Gerente / Líder de proyecto

Olga Arguedas Segura

Gerente / Líder de pruebas de software

David Rivera Quispe

Tabla 10 Aprobaciones

Nombre y Apellido

Cargo

Departamento u organización

Fecha

Jair Polanco

Calidad de Software

25/11/19

David Rivera

Jefe de Proyecto

Desarrollo y Calidad de Software Desarrollo y Calidad de Software

Firma

25/11/19

Resumen Ejecutivo De acuerdo con el equipo de trabajo y desarrollo, las pruebas de caja negra, están enfocadas en los requisitos funcionales del software para el colegio José Carlos Mariátegui permitiendo al desarrollador centrarse en la relación de las entradas y salidas del sistema sin preocuparse de la estructura interna de la aplicación examinada. Este tipo de pruebas se aplicó con la finalidad de localizar fallas funcionales en el sistema, al identificar situaciones en las que las respuestas de este a determinadas acciones del usuario no se apegan a las especificaciones establecidas durante el diseño del software. Las pruebas se enfocaron: acceso a la aplicación, registro de estudiantes, búsqueda y consultas, gestión de clases, gestión de usuario (Administrador), gestión de asignaturas, gestión de combinación de asignaturas.

Alcance de las pruebas Elementos de pruebas Mediante los siguientes listados se describen todos los módulos, componentes que se van a Probar:

Módulos:     

Módulo Usuario Módulo de reportes Módulo de asignaturas Módulo de estudiantes Módulo de clases

Componentes:    

Registros Actualizaciones Tablas Búsquedas

Nuevas funcionalidades a probar 1. Módulo de clases: Validar la búsqueda y actualización de los datos. 2. Módulo de gestión de asignatura: Validar la búsqueda y combinación de asignaturas. 3. Módulo de estudiantes: Validar la búsqueda, el ingreso de nuevos estudiantes y actualización de datos.

Pruebas de regresión Tabla 11 Pruebas

ID CUP1

Casos de Prueba Casos de prueba para el Acceso a la aplicación

Descripción En este caso se harán las pruebas de ingreso a la aplicación, validando el login.

CUP3

Casos de prueba para la Gestión de clases

En este caso se harán pruebas para la gestión de clases, para el reporte y actualización de datos.

CUP4

Casos de prueba para la Gestión de asignaturas

En este caso se harán pruebas para la gestión de asignaturas, para el reporte y actualización de datos.

CUP6

Casos de prueba para la Gestión de estudiantes

En este caso se harán pruebas para la Gestión de Estudiantes para agregar, actualización, reporte.

Enfoque de pruebas (estrategia) Estrategia de pruebas funcionales: Tabla 12 Pruebas - Estrategias

Id

Caso de Prueba

Descripción

Fecha

C U P 1

Casos de prueba para el Accesoa la

04-062019

C U P 2 C U P 3

Caso de prueba para la Gestión del Usuario

En este caso se harán las pruebas de ingresoa la aplicación, validando el login. En este caso se harán las pruebas para la gestión de usuario administrador para Actualizar contraseña. En este caso se harán pruebas para la gestión de clases, para el reporte y actualización de Datos.

aplicación

Casos de prueba para la Gestión de Clases

C U P 4

Casos de prueba para

C U P 5

Casos de prueba para

C U P 6

la Gestión asignaturas

la gestiónde combinación de asignaturas

de

En este caso se harán pruebas para la gestiónde asignaturas, para el reporte y actualización de datos.

En este caso se harán pruebas para la gestiónde combinación de asignaturas para el reporte, edicióny añadir combinación de asignaturas.

Casos de prueba para

En este caso se harán pruebas

la

para la gestión de Estudiantes para

gestiónde

Estudiantes

Área Funcional / Sub proceso Autenticación de ingresoa la aplicación

04-062019

Actualización de contraseña

04-06-

Listado de clases

2019 04-062019 04-062019 04-06-

Actualización de Datos Búsqueda de clases Listado

2019 04-062019 04-062019 04-06-

asignaturas Búsqueda de asignaturas Actualización de datos Registrar

2019

04-062019 04-062019 04-06-

combinación de asignatura Lista de combinación de asignatura Actualización de datos Búsqueda por clase o curso Registrar Nuevos

2019

estudiantes

04-06-

Lista de

04-062019

agregar, reporte.

actualización,

2019 04-062019 04-062019

estudiantes Actualización de Datos Búsqueda de estudiantes

Criterios de aceptación o rechazo Hemos establecidos el porcentaje de pruebas unitarias con una medida de 90%, en caso el software cumpla esta medida establecida entonces será aceptado, es decir los casos de pruebas definidos tiene que ser aprobados en un porcentaje de 90% a más. Los casos de prueba en total no superen el 90% serán rechazados y pasaran a ser evaluados por otro criterio. Tabla 13 Criterios

Id CUP1

Caso de Prueba Casos de prueba para el Acceso a la aplicación

CUP2 CUP3 CUP4

Caso de prueba para la Gestión del Usuario Casos de prueba para la Gestión de Clases Casos de prueba para la Gestión de asignaturas

CUP5

Casos de prueba para la Gestión de combinación de asignaturas Casos de prueba para la Gestión de Estudiantes

CUP6

Caso de prueba para el acceso a la aplicación -

Fig. 143: Pruebas de Caja Negra 01

Fig. 144: Pruebas de Caja Negra 02

Caso de prueba para la gestión de usuario-

Fig. 145: Pruebas de Caja Negra 03

Fig. 146: Pruebas de Caja Negra 04

Fig. 147: Pruebas de Caja Negra 05

Fig. 148: Pruebas de Caja Negra 06

Fig. 149: Pruebas de Caja Negra 07

Caso de prueba para la gestión de clases-

Fig. 150: Pruebas de Caja Negra 08

Fig. 152: Pruebas de Caja Negra 10

Caso de prueba para la gestión las asignaturas

Fig. 153: Pruebas de Caja Negra 11

Fig. 154: Pruebas de Caja Negra 12

Caso de prueba para la combinación de asignaturas para el estudiante

Fig. 155: Pruebas de Caja Negra 13

Fig. 156: Pruebas de Caja Negra 14

Caso de prueba para la gestión de estudiantes

Fig. 157: Pruebas de Caja Negra 15

Fig. 158: Pruebas de Caja Negra 16

Criterios de suspensión Si el software ha sido evaluado por las pruebas de caja negra y no han superado el 90% entonces el proceso de aceptación del software quedará en suspensión hasta superar o corregir los fallos encontrados. Si en caso tuviéramos fallos al realizar la evaluación en los casos de prueba principales, se realizará la suspensión.

Criterios de reanudación Terminando con los fallos corregidos, entonces se pasará a realizar la reanudación de la

evaluación de los casos de prueba, teniendo en cuenta que es necesario que se alcance el porcentaje de aprobación definido el cual es 90%. Se procederá a realizar la evaluación a todo el software y a todos los casos de pruebas.

Entregables Tabla 14 Lista de Entregables de Pruebas

Entregable Rendimiento de la libreta de direcciones

Descripción La presente prueba revisa que cada uno de los elementos que conforman la aplicación funcionen correctamente, se revisan detalladamente uno a uno lo componentes y si es necesario hacer correcciones se reportan al departamento correspondiente para que haga la corrección de los errores aquí encontrados.

Ficha de escenario por caso de uso Tabla 15 Inserción de estudiante

Inserción de Nuevo estudiante ID Escenario 1

Flujo Básico El administrador accede al sistema, selecciona la opción de agregar y se procede al llenado de la información solicitada por el sistema, para después almacenarla en la Base de Datos

Modificar datos del estudiante ID Escenario Flujo Básico 2

El administrador accede al sistema, busca el estudiante a modificar y selecciona la opción de acción para entonces proceder al cambio de información, para posteriormente actualizar la Base de Datos

Eliminar estudiante ID Escenario Flujo Básico 3

El administrador accede al sistema, busca el estudiante a eliminar y selecciona la opción de modificar para entonces proceder a la eliminación del estudiante, para posteriormente actualizar la Base de Datos

Ficha de escenario por caso de uso ID del Proyecto/ Nombre: Jose Carlos Mariátegui ID del Ciclo de Prueba: Módulo del administrador Fechas para el Ciclo de Prueba: Desde: 25/11/2019 Hasta: 25/12/2019 Tabla 16 Tabla de porcentaje de cobertura.

ID Caso de Uso 1

ID Caso de Pruebas

Resultados Esperados

1

90%

2

1

90%

3

1

90%

Resultado s Obtenidos 100 % 100 % 100 %

Observación

No se encontraron errores No se encontraron errores No se encontraron errores

Resultados/Observaciones para el Ciclo de Prueba: El resultado que se obtuvo estuvo a la altura de los resultados que se esperaban, todo funcionó en base a lo que se tenía planeado en el diseño, cada uno de los botones, cuadros de texto, etiquetas, combos, etc. funcionaron conforme a su respectiva acción que debían realizar. Aprobado Ciclo de Prueba por:

CLIENTE

ORGANIZACIÓN

PROBADOR

Recursos Se hicieron una serie exhaustivas pruebas de hardware, software, y de herramientas de pruebas requeridas que se describen más adelante. Tabla 17 Recursos

Recurso

Cantidad.

Descripción

Servidor

1

Sisrest.mqsac.com

Sistema Operativo Base de datos

1 1

Windows, linux MySQL, reside en CPanel

Requerimientos de entornos – Software En cuanto al software se utilizaron una serie de programas usados a menudo para realizar auditorías que se describen a continuación: Tabla 18 Requerimientos de Entorno

Nombre

Descripción

GRS (Global Reporting System)

Es un completo sistema de soporte a decisiones (DSS), que proporciona visibilidad y control del proceso de desarrollo de software JKing QA es una herramienta de análisis estático, pensada para facilitar y automatizar el proceso de adopción de los estándares de calidad. Está centrada en los entornos de preproducción, que proporciona la garantía del rendimiento de principio a fin de las aplicaciones.

JKing QA de ALS IPS Performance Optimizer de Hyperformix QACenter de Compuwa re gaKing de ALS checking de ALS TrackRecord de Compuware TestPartner de Compuware

Es una Suite de productos de Compuware, para probar aplicaciones bajo condiciones de producción, pero sin que las máquinas estén atendidas por los usuarios. gaKing de ALS es la herramienta de análisis estático, pensada para facilitar y automatizar el proceso de certificación del cumplimiento de los estándares de codificación. checKing es la una herramienta de monitorización del proceso de desarrollo de software y sus resultados. TrackRecord se ajusta a cualquier proceso de desarrollo y pruebas, ofreciendo un sistema de rastreo que ayuda en la identificación y resolución de defectos de software. TestPartner es una herramienta que automatiza las pruebas funcionales y de regresión. Ha sido especialmente diseñada para complejas aplicaciones basadas en Microsoft, Java y tecnologías Web

TEST de Parasoft

.TEST es una unidad de pruebas automatizada y productos de análisis de código estándar, que trabaja sobre clases escritas en la plataforma Microsoft .NET, sin requerir que los desarrolladores realicen un solo caso de prueba.

Security Tester Fortify

Fortify Security Tester, proporciona las pruebas de seguridad eficaces a los equipos de desarrollo y de aseguramiento de calidad (QA), permitiéndoles verificar la adecuación a los estándares de seguridad, y posibles vulnerabilidades en el código de sus aplicaciones antes de su despliegue.

QALoad

Es una herramienta de pruebas de carga que ayuda a los equipos de pruebas, desarrolladores y jefes de proyecto a realizar pruebas de carga efectivas a aplicaciones distribuidas. Enterprise Architect provee soporte para integrar los procedimientos de prueba con el modelo base.

Enterprise Architect

Herramientas de pruebas requeridas Pruebas Funcionales Se establece el diseño y ejecución de casos de pruebas a requerimientos funcionales.

Pruebas de sistemas Requerimientos no funcionales: Carga Rendimiento Volumen Seguridad Usuario Tensión Según la metodología utilizada para verificar y conocer a fondo el funcionamiento de la aplicación de dos casos:

-

Test basado en un guion de casos de pruebas o comúnmente llamado Scripted Testing. Test basado en pruebas exploratorias también llamado Exploratory

Testing. Según la accesibilidad que se tenga sobre los elementos del sistema a evaluar: -

Pruebas de caja blanca Pruebas de caja negra

También podrían clasificarse según nivel al que llega cada test, y en este caso se hablaría de: -

Pruebas de caja blanca Pruebas de caja negra

H) Herramientas de gestión de pruebas

Tabla 19 Personal

Roles

Líder del plan de pruebas Analista de pruebas Usuarios de prueba

Recurso s Necesari os 1

Estado

Asignado

1

Asignado

1

Asignado

Responsabilidades Comentarios

Específicas

Coordinar que el plan de pruebas se lleve a cabo y hacer la planeación de éste. Analiza que el software este realizado conforme a los estándares de calidad. Probar el sistema como si fueran los usuarios de la aplicación.

Entrenamiento Las necesidades de entrenamiento según el sistema están relacionadas a: 1. Preparar personal para la ejecución inmediata de las diversas tareas peculiares de la organización. 2. Proporcionar al personal oportunidades para el continuo desarrollo en sus cargos actuales, como en otras funciones para las cuales la persona puede ser considerada. 3. Cambiar la actitud de las personas, para crear un clima más satisfactorio entre los colaboradores, aumentar la motivación y hacerlos más receptivos a las técnicas de supervisión y gerencia. El entrenamiento asegura la ejecución satisfactoria del trabajo, e igualmente constituye una herramienta para los cambios originados por nuevas tecnologías, también permite al personal de la empresa desempeñar sus actividades con el nivel de eficiencia requerido por sus puestos de trabajo, lo que consecuentemente, contribuye a su autorrealización y al logro de los objetivos organizacionales; como beneficios específicos para la organización, el entrenamiento ofrece: 1. Mejorar los sistemas y métodos de trabajo 2. Mejorar el proceso de comunicación entre los colaboradores 3. Reducir los rechazos y desperdicios en la producción y/o servicios

o

4. 5. 6. 7.

Disminuir ausencias y rotación de personal Reducir costos por mantenimiento de las maquinarias, equipos, etc. Reducir el tiempo de aprendizaje Aminorar la carga de trabajo de los responsables asignados

8. Reducir los costos para trabajos extraordinarios 9. Reducir los accidentes de trabajo.

Herramientas de pruebas

Planificación y organización Procedimientos para las pruebas Se planificarán las pruebas específicas a ser aplicadas, para lo cual se incluye la definición de las pruebas, las estrategias, lo recursos y las estimaciones de tiempo. Esta planificación deberá realizarse para cada subsistema en forma separada. -

Se definen las pruebas a aplicar. Se especifican las técnicas a utilizar. Se establece el tiempo para la ejecución de cada una de las pruebas. Uso de herramientas. Criterios de aceptación. Recursos involucrados.

Resultado de la planificación: Se deberán definir los siguientes puntos: - Cronograma detallado de la ejecución de las pruebas; donde se especifica qué prueba se realiza, cuánto tiempo se estima para su ejecución, recursos a utilizar (humanos y tecnológicos). Formatos a utilizar para el diseño de las pruebas. Formatos a utilizar para el registro y análisis de los resultados de las pruebas. Herramientas a utilizar para la gestión de incidencias. Procedimientos para el control de cambios. Herramientas a utilizar para la ejecución de las pruebas.

Las pruebas se llevarán a cabo de la siguiente forma: Secuencias de pasos para la Configuración -

Configuración de los Equipos Cliente y del Servidor de Aplicación Web y de Base de Datos.

Secuencias de pasos para la generación de archivos para los módulos. -

Ejecución de proceso (manual) de generación de archivos de entrada con la información de los datos clínicos para alimentar al sistema.

Secuencias de pasos para la generación de datos para los tres módulos. -

Ejecución del proceso (manual) de generación de datos, donde las tablas y campos a utilizar serán llenados manualmente.

Tabla 20 Matriz de responsabilidades

TAREAS

Organizar el plan de pruebas Realizar el análisis de software Realizar las pruebas del software Uso del sistema

ROLES Líder del proyecto R A A A

Analista pruebas I R R I

Usuario de pruebas I I R I

Interesados

C

Tabla 21 Cronograma

FASE – SEMANA Planificación de las pruebas Estudio preliminar Planificación del proyecto Ciclo Prueba 1 Ciclo Prueba 2 Evaluación Planificación Real de las pruebas Estudio Preliminar Planificación del proyecto Ciclo Prueba 3 Ciclo Prueba 4 Evaluación

1

2

3

4

x

x

x

5 6

7

8 9

x x

x

x

1 0

1 1

1 2

1 3

1 4

1 5

1 6

1 7

18

x x

x

x x

x x

x

x x x

x

x x

x x

x

x

X

x x

Tabla 22 Premisas

Proyecto

Organizació n

Calidad

Mejora

Premisa s - Nivel 1 Premisa s -Nivel 2

Repetible

Seguimiento y control de proyectos. Planeación de los proyectos.

Definido

Premisa s -Nivel 3 Premisa s -Nivel 4

Administrativ o

Revisión de las pruebas entre los integrantes de equipo. Ingeniería de producto de software. Manejo integrado del software. Definición del proceso de software Foco del proceso de software. Control de calidad. Administración cuantitativa del proyecto.

Optimizado

Administración de cambios del proceso Administración de las diferentes herramientas de pruebas del software. Prevención de defectos

Dependencias y Riesgos Tabla 23 Tabla de riesgos

Riesgos

Plan de Contingencia

Impacto

Alguna de las personas no está debidamente capacitada

Capacitar al personal Todas las áreas pueden Reemplazar al personal por nuevo verse afectadas por una personal capacitado mala capacitación

Tiempo de prueba mayor al previsto

Mejorar el plan de prueba Capacitar mejor al personal Utilizar mayor número de personas en el plan de pruebas Iniciar nuevamente con el plan de pruebas

El área de la alta gerencia es la más afectada por la inconformidad que el cliente pueda manifestar

Errores a la hora de hacer la ejecución del plan de pruebas

Volver a hacer cada una de las pruebas e identificar los errores.

En el área de pruebas y el área de desarrollo y mantenimiento de software.

Pruebas de cobertura 1. Convenciones PHP Unit posee algunas cuantas convenciones y antes de comenzar con nuestro test, vamos a poner las que serán convenientes seguir de forma más o menos estricta. Cada archivo tiene que tiene su equivalente en el test suite, y toda la estructura de carpetas:

Fig. 159: El SRC del Software

2. 57 tests y 74 asserts, esta es la suite completa en el terminar con phpunit del sistema

Fig. 160: phpUnit test

escolar. 3. Reporte del code coverage Tenemos un 97.58% de las líneas testeadas y un 93.98% de las funciones y los métodos testeados.

Fig. 161: Testing 01 – Pruebas de Caja Blanca

Fig. 162: Testing 02 – Pruebas de Caja Blanca

Aquí podemos ver un reporte de la clase add-subjectcombination, de todos sus métodos y su % de coverage.

Fig. 163: Testing 03 – Pruebas de Caja Blanca

Aquí podemos ver un reporte de la clase add-students, de todos sus métodos y su % de coverage.

Fig. 164: Testing 04 – Pruebas de Caja Blanca

Aquí podemos ver un reporte de la clase add-students, de todos sus métodos y su % de coverage.

Fig. 165: Testing 05 – Pruebas de Caja Blanca

Aquí podemos ver un reporte de la clase connection, de todos sus métodos y su % de coverage.

Capítulo IV Conclusiones y Recomendaciones Conclusiones 

La calidad se ha convertido en un aspecto trascendental dentro de las organizaciones en los últimos años, por lo que su importancia ha sido reconocida y sus directrices han sido aplicadas en gran cantidad de empresas alrededor del mundo,



La calidad ha venido evolucionando en la búsqueda de aspectos que permitan mayor crecimiento de las instituciones, así como, mayor satisfacción del cliente.



La Normalización dentro de una empresa fija las bases para el presente y el futuro con el propósito de establecer un orden para el beneficio de todos los interesados.



Esta normalización puede ser aplicada a cualquier empresa y puede ser adaptada a los requerimientos particulares de cada organización.



La aplicación de normas busca la mejora del funcionamiento y la eficiencia en la utilización de los recursos, lo que bien llevado puede conducir a la reducción de costos.



Las Normas ISO son un referente de calidad a nivel mundial y permiten a las organizaciones la estandarización y mejoramiento de sus procesos, su funcionamiento y reconocimiento, lo cual es de vital importancia para la sobrevivencia de las empresas en un mundo globalizado.



Del uso de los Estándares de Calidad ISO 9000 que describe un sistema de garantía de calidad en términos genéricos que se aplican a cualquier negocio sin importar los productos o servicios, ofreciendo un sistema de garantía de calidad, bien estructurado, organizacional, con responsabilidades y procedimientos.



La adopción de una buena política contribuye en gran medida a lograr la calidad del software, pero no la asegura. Para el aseguramiento de la calidad es necesario su control o evaluación.



La calidad de un producto no es algo que se añade al final como si se pintara de un color su exterior, es algo que se cuida a lo largo de todo el proyecto de construcción. Y la falta de calidad puede causar problemas graves al producto.



Para conseguir una buena calidad del software es esencial establecer un programa de medidas a tomar con respecto a los proveedores. Es también importante utilizar los modelos y métodos apropiados para controlar el proceso de desarrollo del mismo.

Recomendaciones 

Satisfacer los requerimientos del negocio; lograr una experiencia de usuario satisfactoria.



El equipo de desarrollo de aplicaciones no debe llenarse de expectativas demasiado perfectas. Por el contrario, deben estar alineados con una definición de la calidad que se ajusta a los tiempos establecidos, los recursos y las limitaciones presupuestarias.



Difundir métricas simples de calidad que sean altamente visibles y de esta manera mantener la calidad en la mente de todo el equipo y que este refleje cuándo los esfuerzos se quedan cortos.



Ir afinando las metas individuales y del equipo para incluir la calidad.



Hacer que los miembros del equipo tengan un desempeño de acuerdo a sus incentivos, hacer de la mejora de la calidad parte de sus metas refuerza la conducta deseada.



Procurar que la obtención los requisitos se lleve adecuadamente



Cumplir con los requerimientos del negocio y así lograr una experiencia de usuario satisfactoria.



Realizar pruebas más inteligentes para efectuar menos pruebas



Diseños más simples y limpios producen código que es más simple, más limpio y más fácil de evaluar y volver a trabajar, lo cual significa que el código tendrá menos errores y que esos bugs serán más fáciles de diagnosticar y reparar.



La calidad debe ir más allá del alcance de solo los profesionales de control de calidad para convertirse en una parte integrada del ciclo completo de vida del desarrollo de software.

Glosario Plan de prueba. Es un producto formal que define los objetivos de la prueba de un sistema, establece y coordina una estrategia de trabajo, y provee del marco adecuado para elaborar una planificación paso a paso de las actividades de prueba.

Prueba de caja negra. Es una técnica de pruebas de software en la cual la funcionalidad se verifica sin tomar en cuenta la estructura interna de código, detalles de implementación o escenarios de ejecución internos en el software. En las pruebas de caja negra, nos enfocamos solamente en las entradas y salidas del sistema, sin preocuparnos en tener conocimiento de la estructura interna del programa de software. Para obtener el detalle de cuáles deben ser esas entradas y salidas, nos basamos en los requerimientos de software y especificaciones funcionales.

Prueba de caja blanca. Es el testing sobre el código fuente de la aplicación, y en consecuencia, sobre los diferentes algoritmos y estructuras de datos utilizados. Básicamente, el tester selecciona distintos valores de entrada para examinar cada uno de los posibles flujos de ejecución del programa y cerciorarse de que se devuelven los valores de salida adecuados. Al estar basadas en una implementación concreta, si ésta se modifica, por regla general las pruebas también deberán rediseñarse

Enfoque de pruebas. – Enfoque de pruebas es la implementación de la estrategia de pruebas definida para un proyecto específico. En general ésta incluye las decisiones tomadas en función de los objetivos del proyecto (desde el punto de vista del proceso de pruebas) y la evaluación de riesgo llevada a cabo, puntos de entrada respecto del proceso de pruebas, las técnicas de diseño de pruebas a aplicar, criterios de salida y tipos de pruebas a ejecutar.

Recursos. Se denomina recursos a todos aquellos elementos que pueden utilizarse como medios a efectos de alcanzar un fin determinado

Herramienta de pruebas. Permite analizar sin la necesidad de ejecutar el software. Detecta cosas como código duplicado, y código muerto. Analizar el cumplimiento de reglas de estilo o código, la gestión de la métrica del software y realizar informes sobre métricas.

Referencias Axis

Technical Group. (14 de Octubre de 2014). Axis. Obtenido de http://www.axistechnical.com/importance-testingsoftware-development/

Chhillar, D. R., & Dalal, S. (2012). Case Studies of Most Common and Severe Types of Software. International Journal of Advanced Research in Computer Science and Software Engineering. López-Asúnsolo, A. M. (2017). Cobertura de código: más información para TESTAR. Valencia: Universidad Politecnica de Valencia. Marquez,

A. (13 Obtenido negra/

de de

Marzo de 2018). Tester moderno. https://testermoderno.com/caja-blanca-vs-caja-

Software Engineering Ethics Research institute. (2016). Ingeniería de software código de etica y práctica profesional. Tennessee: ETSU.

Sommerville, I. (2011). Ingeniería de software. México: Pearson. Terrera,

G. (26 de Febrero de 2017). Testing Baires. Obtenido de https://testingbaires.com/2017/02/26/pruebas-cajanegra-enfoque-practico/