Universidad Nacional del Centro del Perú
Facultad de Ingeniería de Sistemas
Digitalización del proceso de “Licenciamiento del programa de pregrado de medicina” para la Dirección de Licenciamiento (DILIC) en la Superintendencia Nacional de Educación Superior
Universitaria (SUNEDU)
Yupanqui Quispe, Eduardo Manuel
Huancayo 2020
Esta obra está bajo licencia https://creativecommons.org/licenses/by/4.0/
Repositorio Institucional - UNCP
UNIVERSIDAD NACIONAL DEL CENTRO DEL PERÚ
FACULTAD DE INGENIERÍA DE SISTEMAS INFORME DE EXPERIENCIA PROFESIONAL
DIGITALIZACIÓN DEL PROCESO DE
“LICENCIAMIENTO DEL PROGRAMA DE
PREGRADO DE MEDICINA” PARA LA DIRECCIÓN DE LICENCIAMIENTO (DILIC) EN LA
SUPERINTENDENCIA NACIONAL DE EDUCACIÓN SUPERIOR UNIVERSITARIA (SUNEDU)
PRESENTADO POR:
YUPANQUI QUISPE, Eduardo Manuel
PARA OPTAR EL TÍTULO PROFESIONAL DE:
INGENIERO DE SISTEMAS
HUANCAYO – PERÚ
2020
ii
AGRADECIMIENTOS:
Deseo expresar mi agradecimiento:
A MI MADRE ELIZABETH
Por su ejemplo, amor y aliento constante para ser cada día mejor.
A MI ALMA MATER
Por sembrar en mí enseñanzas que condujeron a mi formación profesional.
A MI ASESOR
Por su gran apoyo y por compartir su vasto conocimiento.
A MIS MAESTROS DE LA FIS
Por su dedicación a la enseñanza a mi paso por la Universidad.
A LA SUPERINTENDENCIA NACIONAL DE EDUCACIÓN SUPERIOR UNIVERSITARIA Por darme la oportunidad de laborar en esta prestigiosa entidad por el desarrollo de la
calidad educativa del país.
iii
DEDICATORIA:
A mi familia, mi madre Elizabeth; quien en todo momento me ha acompañado alentándome para seguir mis objetivos. Son ellos el motor de mi vida.
iv
RESUMEN
El siguiente informe de experiencia profesional desarrolla todo el ciclo de vida del desarrollo del proyecto de digitalización del procedimiento de licenciamiento a los programas de pregrado de medicina de SUNEDU; el licenciamiento de programas de medicina nace a partir de la preocupación por la calidad de los programas universitarios de medicina desde hace más de 2 décadas. Por lo tanto, la SUNEDU después de avanzar en el proceso de licenciamiento institucional, se da comienzo al licenciamiento de los programas de pregrado de medicina PPM, como carreras priorizadas, ya que se considera necesario para que la sociedad garantice que las universidades enseñen este programa cumpliendo con las Condiciones Básicas de Calidad CBC, por tener una alta incidencia en la calidad de vida de las personas y que es de carácter de servicio público.
La necesidad de digitalizar dicho procedimiento nace debido a que la Dirección de Licenciamiento contaba con dos sistemas -Sistema de Registro de Solicitud de Licenciamiento Institucional (SIREPLI) y Sistema de Proceso de Licenciamiento Institucional (SIPLIC) que cumplían un propósito especifico limitado a las necesidades cambiantes que había, y en el caso de SIPLIC que constituía una única herramienta vigente con información de trazabilidad. Es así como nace la implementación de un nuevo módulo integral de licenciamiento que digitalizara todo el procedimiento basado en procesos que cumpla con las necesidades cambiantes que afronta la dirección de licenciamiento.
Para el desarrollo del proyecto de Desarrollo de Software se tomó como base la metodología basado en RUP propia de la Oficina de Tecnologías de Información OTI de SUNEDU, así como de las lecciones aprendidas y buenas prácticas de herramientas agiles (XP, Scrum, etc.) nacidas a partir de la experiencia propia en la SUNEDU. Esta metodología consta de 4 procesos las cuales son: Análisis de la solución, Construcción de Software, Calificación de Software, y Despliegue del proyecto, las cuelas de describen a lo largo del informe.
v
ABSTRACT
The following professional experience report develops the entire life cycle of the development of the project to digitize the licensing procedure for SUNEDU's medical undergraduate programs, this need arises from the concern for the quality of university medical programs from more than 2 decades ago. Thus, after advancing in the institutional licensing process, SUNEDU began licensing undergraduate medical programs, as the first prioritized program, as it is considered necessary for the society to ensure that universities teach this program in compliance with the basic conditions qualities CBC.
Because there were currently two systems -Institutional Licensing Application Registration System (SIREPLI) and Institutional Licensing Process System (SIPLIC) that fulfilled a specific purpose limited to the changing needs that existed, and in the case of SIPLIC that it constituted a single current tool with traceability information. This is how the need arises for the implementation of a new comprehensive licensing module that will digitize the entire procedure based on processes that meets the changing needs faced by the licensing department.
For the development of the Software Development project, the methodology was based on RUP of the SUNEDU OTI Information Technology Office, as well as the lessons learned and good practices of agile tools (XP, Scrum, etc.) born from their own experience at SUNEDU. This methodology consists of 4 processes which are: Solution Analysis, Software Construction, Software Qualification, and Project Deployment, all pf them described throughout the report.
vi
ÍNDICE
AGRADECIMIENTOS: ... ii
DEDICATORIA: ... iii
RESUMEN ... iv
ABSTRACT ... v
ÍNDICE DE TABLAS ... ix
ÍNDICE DE FIGURAS ... x
INTRODUCCIÓN ... 1
CAPÍTULO I ... 2
EL CONTEXTO Y LA ORGANIZACIÓN ... 2
1.1 EL CONTEXTO... 2
1.1.1 La ley universitaria N.º 30220 ... 2
1.1.2 Ministerio de Educación MINEDU ... 3
1.1.3 Modelo de la gestión documental ... 3
1.2 LA ORGANIZACIÓN ... 4
1.2.1 Superintendencia Nacional de Educación Superior Universitaria (SUNEDU) ... 4
1.2.2 Reseña Histórica ... 4
1.2.3 Estructura orgánica de la SUNEDU... 4
1.2.4 Funciones de la SUNEDU ... 5
1.2.5 Dirección de licenciamiento de la SUNEDU ... 5
1.2.6 Condiciones básicas de calidad - CBC) ... 6
1.2.7 Modelo de Licenciamiento ... 7
1.2.8 Licenciamiento institucional y licenciamiento de programas ... 8
1.2.9 Resultados de gestión sobre el Licenciamiento Institucional ... 9
CAPÍTULO II ...10
PROBLEMÁTICA Y OBJETIVO ...10
2.1 LA PROBLEMÁTICA...10
2.1.1 Contextualización del problema ...10
2.1.1 Problema General ...14
vii
2.1.1 Problema Especifico ...14
2.2 OBJETIVOS ...15
2.2.1 Objetivo general ...15
2.2.1 Objetivos específicos ...15
CAPÍTULO III ...16
METODOLOGÍAS, TÉCNICAS Y/O HERRAMIENTAS ...16
3.1 METODOLOGÍAS ...16
3.1.1 Metodología ágil de desarrollo de software ...16
3.2.2 Scrum ...18
3.2.3 Metodología de Desarrollo de Software de la Oficina de Tecnologías de la Información (OTI) de la SUNEDU ...26
3.2 HERRAMIENTAS ...40
3.1.1 Business Process Modeling Notation o BPMN 2.0 ...40
3.1.2 Sistema de Workflow ...41
3.1.3 Gestor de archivos ...41
3.1.4 Firma electrónica ...42
3.1.5 Notificación electrónica ...42
3.1.6 Microsoft SQL Server 2008 R2 ...43
3.1.7 Microsoft ASP.NET Core 2.2 ...43
CAPÍTULO IV ...45
IMPLEMENTACIÓN Y DESARROLLO ...45
4.1 ANÁLISIS DE LA SOLUCIÓN ...45
4.1.1 Acta de constitución del proyecto ...45
4.1.2 Matriz de requerimiento de usuario ...46
4.1.3 Modelado de Procesos...50
4.1.4 Requerimientos del sistema ...53
4.1.5 Prototipos funcionales ...65
4.1.6 Modelo de base de datos ...81
4.1.7 Arquitectura de software ... 100
viii
4.1.8 Arquitectura de tecnología de información ... 106
4.2 CONSTRUCCIÓN DEL SOFTWARE ... 112
4.2.1 Construcción de flujos de procesos ... 113
4.2.2 Construcción de los componentes funcionales ... 132
4.3 CALIFICACIÓN DEL SOFTWARE ... 135
4.3.1 Informe de Pruebas Integrales ... 136
4.4 DESPLIEGUE DEL PRODUCTO ... 143
4.4.1 Manual de instalación ... 143
4.4.2 Documento de pase ... 144
CAPÍTULO V ... 145
RESULTADOS ... 145
5.1 Resultados obtenidos luego de la implementación ... 145
5.1.1 Procedimiento de licenciamiento de PPM luego de la implementación ... 147
5.2 Análisis de resultados ... 149
CONCLUSIONES ... 151
RECOMENDACIONES ... 152
BIBLIOGRAFÍA ... 153
APÉNDICE ... 155
ix
ÍNDICE DE TABLAS
Tabla 1: Actores de negocio ...46
Tabla 2: Casos de uso de negocio ...47
Tabla 3: Requerimientos de usuario ...48
Tabla 4: Matriz de requerimientos de usuario ...49
Tabla 5: Requerimientos del sistema ...54
Tabla 6: Actores del sistema ...59
Tabla 7: Casos de uso del sistema ...61
Tabla 8: Trazabilidad de Casos de uso del sistema y requerimientos del sistema ...63
Tabla 9: Roles del sistema ...65
Tabla 10: Listado de categorías de tablas. ...94
Tabla 11: Listado de esquemas de la Base de Datos ...95
Tabla 12: Listado de definición de tablas de la Base de Datos ...95
Tabla 13: Nodos de la arquitectura de TI ... 107
Tabla 14: Integración a nivel Base de datos con los sistemas asociados ... 108
Tabla 15: Lista de Interfaces desarrolladas ... 133
Tabla 16: Listado de Casos de Pruebas Funcionales ... 137
Tabla 17: Estado de casos de prueba ... 142
Tabla 18: Conteo resumen de las pruebas ... 142
Tabla 19: Resumen de las pruebas no funcionales ... 142
x
ÍNDICE DE FIGURAS
Figura 1: Antecedentes de la ley universitaria. ... 3
Figura 2: Estructura orgánica de la SUNEDU. ... 5
Figura 3: Condiciones Básicas de Calidad. ... 6
Figura 4: Enfoque del Modelo de Licenciamiento. ... 7
Figura 5: Alcance matriz de las CBC institucional y de las CBS de programas de pregrado de medicina. ... 8
Figura 6: Sistemas actuales frente al Proceso de Licenciamiento. ...11
Figura 7: Flujo de trabajo Scrum. ...19
Figura 8: Procesos del ciclo de vida de la NTP 12207:2106. ...27
Figura 9: Procesos del ciclo de vida de la NTP 12207:2106. ...28
Figura 10: Visión general del proceso – Contenido VS. Tiempo. ...32
Figura 11: Visión general del proceso – Proceso cíclico. ...32
Figura 12: Fases e hitos importantes en el proceso. ...35
Figura 13: Ciclos y evolución. ...36
Figura 14: Descripción detallada de la metodología. ...37
Figura 15: Macroproceso del desarrollo de software de OTI – SUNEDU. ...38
Figura 16: Entregables de la metodología de desarrollo. ...39
Figura 17: Modelo de proceso bajo BPMN. ...40
Figura 18: Proceso de firma digital y verificación. ...42
Figura 19: Contexto de ASP.NET Core. ...44
Figura 20: Macroproceso del licenciamiento de PPM. ...52
Figura 21: Procesos del procedimiento de licenciamiento de PPM. ...52
Figura 22: Procesos del procedimiento de licenciamiento de PPM. ...53
Figura 23: Procesos del procedimiento de licenciamiento de PPM. ...53
Figura 24: Prototipo PROT_001 Interfaz de Menú Principal. ...66
Figura 25: Prototipo PROT-002 Interfaz de Solicitud...67
Figura 26: Prototipo PROT_002_1 Escenario de Registro de Representante legal. ...68
Figura 27: Prototipo PROT_002_2 Escenario de Selección de Filial. ...69
Figura 28: Prototipo PROT_002_3 Escenario de Listar Filiales. ...70
Figura 29: Prototipo PROT_002_4 Escenario de Formulario M1...71
Figura 30: Prototipo PROT_002_5 Escenario de Registrar Locales. ...73
Figura 31: Prototipo PROT_002_6 Escenario de Formulario M2...74
Figura 32: Prototipo PROT_002_7 Escenario de Registro de Curso. ...75
Figura 33: Prototipo PROT_002_8 Escenario de Registro de Horas Lectivas. ...76
Figura 34: Prototipo PROT_002_9 Escenario de Formulario M3...77
xi
Figura 35: Prototipo PROT_002_10 Escenario de Formulario M4...77
Figura 36: Prototipo PROT_002_11 Escenario de Formulario M5...78
Figura 37: Prototipo PROT_002_12 Escenario de Formulario M5.X. ...78
Figura 38: Prototipo PROT_002_13 Escenario de Formulario M6...79
Figura 39: Prototipo PROT_002_14 Escenario de Formulario M7...80
Figura 40: Prototipo PROT_002_15 Escenario de Formulario M8...80
Figura 41: Diagrama conceptual E-R de la solicitud ...81
Figura 42: Diagrama conceptual E-R del formato Curso ...81
Figura 43: Diagrama conceptual E-R del formato Docentes ...82
Figura 44:Diagrama conceptual E-R del formato laboratorio ...82
Figura 45: Diagrama conceptual E-R del formato campo clínico ...83
Figura 46: Diagrama conceptual E-R del formato aula ...83
Figura 47: Diagrama lógico de la base de datos ...84
Figura 48: Diagrama lógico de la base de datos ...85
Figura 49: Diagrama físico – Solicitud ...86
Figura 50: Diagrama físico – Campos clínicos ...87
Figura 51: Diagrama físico – Curso ...88
Figura 52: Diagrama físico – Docente ...89
Figura 53: Diagrama físico – Aula ...90
Figura 54: Diagrama físico – Laboratorio ...91
Figura 55: Diagrama físico – Tutores ...92
Figura 56: Diagrama físico – Workflow ...93
Figura 57: Diagrama físico – Configuración ...94
Figura 58: Diagrama integrado de Clean Architecture. ... 101
Figura 59: Arquitectura limpia; vista de cebolla. ... 102
Figura 60: Arquitectura limpia; vista de capas horizontal. ... 102
Figura 61: Diagrama de arquitectura de ASP.NET Core en el que se sigue la arquitectura limpia. ... 103
Figura 62: Ejemplo de arquitectura en tiempo de ejecución de la aplicación ASP.NET Core. ... 104
Figura 63: Estructura de la solución. ... 104
Figura 64: Diagrama de arquitectura de TI. ... 106
Figura 65: Sistemas asociados del sistema. ... 108
Figura N° 66 Registro de solicitud y evaluación preliminar. ... 113
Figura N° 67 Designación de equipo. ... 114
Figura N° 68 Revisión Documental. ... 115
Figura N° 69 Visita Presencial. ... 115
xii
Figura N° 70 ITL con proyecto de resolución. ... 116
Figura N° 71 ITL con requerimiento de PDA. ... 116
Figura N° 72 Informe complementario de Proyecto de RCD. ... 117
Figura N° 73 Diligencia de Actuación Probatoria. ... 117
Figura N° 74 Revisión Documental Complementaria. ... 118
Figura N° 75 Designación de Equipo. ... 118
Figura N° 76 Matriz de Observaciones. ... 119
Figura N° 77 Informe de Observaciones. ... 119
Figura N° 78 Inicio de trámite. ... 120
Figura N° 79 Inadmisibilidad por no presentar subsanación... 120
Figura N° 80 Inadmisibilidad por presentar subsanación incompleta o no responde a lo requerido. ... 121
Figura N° 81 Incorporación de documentos VP. ... 121
Figura N° 82 Incorporación de documentos DAP. ... 122
Figura N° 83 Subsanación de la solicitud. ... 122
Figura N° 84 Revisión preliminar UACTD. ... 123
Figura N° 85 Modificar solicitud de licenciamiento por IOBS. ... 124
Figura N° 86 Modificar solicitud de licenciamiento. ... 125
Figura N° 87 Modificar solicitud de licenciamiento por culminación PDA. ... 126
Figura N° 88 Modificar solicitud de licenciamiento por Requerimiento de Información Adicional. ... 127
Figura N° 89 Enviar documentos a notificar. ... 128
Figura N° 90 Enviar plan de adecuación. ... 129
Figura N° 91 Enviar información adicional. ... 130
Figura N° 92 Reemplazo de documentos... 130
Figura N° 93 Respuesta Solicitud de Ampliación. ... 131
Figura N° 94 Requerimiento de información adicional... 131
Figura N° 95 Enviar solicitud de ampliación. ... 132
Figura 96: Cronograma para los grupos de entidades. ... 146
Figura 97: Estatus de los Grupos 1 y 2 del licenciamiento de PPM ... 147
Figura 98:. Avance de las actividades del procedimiento ... 148
Figura 99: Comparativo de avance por Tipo de Gestión ... 148
Figura 100:. Estado de los flujos de una universidad ... 149
Figura 101: Actividades finalizadas por los usuarios del sistema ... 149
1
INTRODUCCIÓN
El licenciamiento se define como el procedimiento obligatorio cuyo objetivo es verificar que las universidades cumplan las Condiciones Básicas de Calidad (CBC) para ofrecer un servicio educativo superior universitario y puedan obtener una licencia que autorice su funcionamiento por un periodo de tiempo. El proceso de licenciamiento obligatoria se basa necesariamente en que la universidad funcione en la habilitación legal otorgada por el Estado Peruano para la prestación del servicio de educación superior universitario. La SUNEDU para ello realizará este procedimiento con enfoque institucional en una primera fase para las universidades y sus filiales, y en una segunda fase, la SUNEDU publicará los procedimientos y las Condiciones Básicas de Calidad (CBC) para el licenciamiento de programas, iniciando con el Programa de Pregrado de Medicina (PPM).
Sistematizar y digitalizar este procedimiento de Licenciamiento ayudara a la optimización basado en procesos del procedimiento de licenciamiento, ayudar a tener una mejor gestión de la documentación que la universidad presenta para luego organizarlas, para su uso en las posteriores actividades comenzando por el registro de la solicitud de licenciamiento, y tener una interacción digital con la universidad para que pueda consultar el estado de su solicitud con más información que le es útil.
En el capítulo I; se hace una introducción al entorno de la Ley Universitaria Nº 30220, así como el posicionamiento de la Superintendencia para reorganizar el sistema universitario peruano y promover uno basado en la calidad.
En el capítulo II, se describe la problemática que afronta la dirección de licenciamiento para llevar a cabo el procedimiento de licenciamiento de las universidades; también se describe el objetivo del proyecto.
En el capítulo III, se menciona los métodos, técnicas y herramientas empleados para el desarrollo de este proyecto.
En el capítulo IV, se describe las actividades realizadas durante el proyecto resaltando diferentes fases que se desarrollan de acuerdo con la metodología de utilizada.
En el capítulo V, se detallan los resultados obtenidos durante la ejecución del proyecto; así como un conjunto de conclusiones y sugerencias.
E.M.Y.Q.
2
CAPÍTULO I
EL CONTEXTO Y LA ORGANIZACIÓN
1.1 EL CONTEXTO
1.1.1 La ley universitaria N.º 30220
El 09 de julio de 2014, se publicó la Ley Universitaria N.º 30220, que reconoce el rol que cumplirá el para asegurar la calidad del servicio de educación superior universitaria; donde el Ministerio de Educación (MINEDU) llega a asumir la función primordial de elaborar de la Política de Aseguramiento de la Calidad de la Educación Superior Universitaria. Con ella, se da inicio a la creación de la Superintendencia Nacional de Educación Superior Universitaria (SUNEDU), y como parte de ella se introduce la obligatoriedad del licenciamiento a las universidades y por un plazo definido, no como el anterior marco legar que autorizaba el funcionamiento provisional y definitiva. (Ley Universitaria N° 30220, 2014)
Con la entrada de la Ley Universitaria se da inicio al proceso de modernización del sistema universitario peruano, se definió el marco legal para la creación, funcionamiento, supervisión y cese de las universidades peruanas, así como para orientar a la mejora continua de la calidad educativa de las universidades peruanas. Con ello, se deroga la Ley N.º 26439, que es la ley de creación del CONAFU que es el órgano autónomo de la Asamblea Nacional de Rectores (ANR), en consecuencia, se anulan las funciones donde una era el otorgamiento de autorizaciones provisionales y definitivas de las universidades, tal como se muestra en la figura 1.
3 Figura 1: Antecedentes de la ley universitaria.
Fuente: Modelo de Licenciamiento y su Implementación en el Sistema Universitario Peruano.
Elaboración: SUNEDU.
1.1.2 Ministerio de Educación MINEDU
Mediante el Decreto Supremo N.º 016-2015-MINEDU, se menciona la aprobación de la Política de Aseguramiento de la Calidad de la Educación Superior Universitaria. Donde se menciona que: “El Ministerio de Educación (MINEDU) es el ente rector que desarrolla y conduce las acciones que fomenta el Sistema de Aseguramiento de la Calidad SAC en todo el Sistema Universitario”. (pág. 9)
1.1.3 Modelo de la gestión documental
El 09 de agosto de 2017 se publicó la aprobación del Modelo de Gestión Documental (MGD) para su implementación obligatoria en todas las entidades públicas del estado, con el fin de modernizar los procedimientos y simplificación administrativa de la entidad pública. (Congreso de la República, 2017).,
En dicho modelo documental se menciona los siguientes puntos:
• El Modelo de Gestión Documental (MGD) que se basará en estándares y buenas prácticas.
• Definición de las políticas, objetivos y procesos que permitirán implementar y mantener flujos documentales óptimos, facilitando la trazabilidad e interoperabilidad con otras entidades públicas
• Gestiona documentos digitalizados, técnica y legalmente válidos por medio de la firma digital, en el marco de los documentos electrónicos para un gobierno digital.
4 1.2 LA ORGANIZACIÓN
1.2.1 Superintendencia Nacional de Educación Superior Universitaria (SUNEDU)
En la Ley Universitaria N° 30220 (2014) del Congreso de la República, se menciona que:
La SUNEDU se crea como un organismo adscrito al MINEDU, responsable del licenciamiento para poder ejercer el servicio educativo superior universitario. Según la Ley Universitaria, el licenciamiento se define como el procedimiento que tiene como objetivo contrastar el cumplimiento de las Condiciones Básicas de Calidad (CBC) para ofrecer el servicio educativo superior universitario y autorizar su funcionamiento.
Como tal, SUNEDU tiene entre sus funciones supervisar la calidad del servicio educativo y fiscalizar si los recursos públicos y los beneficios otorgados dentro del marco legal a las universidades peruanas y al mejoramiento de la calidad. (pág. 3)
1.2.2 Reseña Histórica
En la publicación de la Ley Universitaria, Ley N.º 30220, se crea la Superintendencia Nacional de Educación Superior Universitaria SUNEDU, cuya constitucionalidad fue ratificada por el Tribunal Constitucional el 26 de enero de 2016.
Ya en el 2015 mediante el Decreto Supremo N.º 016-2015-MINEDU, se aprueba la Política de Aseguramiento de la Calidad de la Educación Superior Universitaria, que establece el concepto de calidad para todo el sistema universitario peruano. Como también se establece que: “MINEDU es el ente rector que desarrolla y conduce el Sistema de Aseguramiento de la Calidad (SAC), así como las acciones para fomentar la calidad en todo el Sistema Universitario Peruano”. (pág. 3)
1.2.3 Estructura orgánica de la SUNEDU
La SUNEDU, para el desempeño de sus funciones, cuenta con la estructura orgánica básica siguiente: (Ley Universitaria N° 30220, 2014, págs. 3-4)
• Alta Dirección, que está compuesta por el Consejo Directivo, Superintendencia y Secretaria General.
• Los órganos de administración interna.
5
• Los órganos de línea.
En la figura 2 se muestra la estructura detallada de su organización.
Figura 2: Estructura orgánica de la SUNEDU.
Fuente: Portal SUNEDU https://www.sunedu.gob.pe/organigrama/.
Elaboración: SUNEDU.
1.2.4 Funciones de la SUNEDU
Dentro de las funciones más resaltantes de la SUNEDU según el artículo 15 de la Ley Universitaria son: (Ley Universitaria N° 30220, 2014, pág. 3)
• Aprobar o denegar las solicitudes de licenciamiento de universidades, tanto institucional y por programas.
• Determinar infracciones e imponer las sanciones.
• Supervisar la calidad de la prestación del servicio educativo.
• Supervisar los requisitos mínimos exigibles para el otorgamiento de grados y títulos (ley).
• Fiscalizar si los beneficios otorgados por el marco legal a las universidades han sido destinados a fines educativos.
1.2.5 Dirección de licenciamiento de la SUNEDU
Según el portal de la SUNEDU, se menciona que: “La Dirección de Licenciamiento es el órgano de línea que lleva a cabo el proceso de aprobación o denegación de las solicitudes de licenciamiento institucional y
6 programas de pregrados. Para luego, el Consejo Directivo decida aprobar o denegar dicha licencia”. (pág. 1)
Dentro de sus funciones, las más resaltantes son:
• Formular y proponer las Condiciones Básicas de Calidad (CBC) del servicio educativo requerido para la aprobación o denegación de la creación y funcionamiento de las universidades, filiales, facultades, escuelas y programas de estudios.
• Formular y proponer los documentos normativos.
• Llevar a cabo el proceso de aprobación o denegación de las solicitudes de licenciamiento de universidades.
1.2.6 Condiciones básicas de calidad - CBC)
Las Condiciones Básicas de Calidad (CBC) son un conjunto de estándares mínimos con los que la universidad peruana debe tener para obtener el licenciamiento. En la figura 3, la SUNEDU muestra las 8 CBC’s en la Universidad Peruana. (SUNEDU Condiciones basicas de calidad, s.f.)
Figura 3: Condiciones Básicas de Calidad.
Fuente: Portal SUNEDU https://www.sunedu.gob.pe/condiciones-basicas-de-calidad-2/.
Elaboración: SUNEDU.
7 1.2.7 Modelo de Licenciamiento
En el Modelo de licenciamiento y su implementación en el Sistema Universitario Peruano aprobado el 13 de noviembre de 2015 mediante Resolución N° 006-2015-SUNEDU/CD, se establece: “El licenciamiento institucional como el procedimiento obligatorio para la verificación del cumplimiento de las condiciones básicas de calidad (CBC), para proteger el bienestar individual y social”. (pág. 5).
Además, la SUNEDU define el Modelo de Licenciamiento como:
Dicho modelo de licenciamiento es parte de los cuatro pilares del Sistema de Aseguramiento de la Calidad (SAC), visto desde este punto, el licenciamiento y la acreditación se definen como procesos de evaluación de calidad diferentes, pero al mismo tiempo complementarios. Lo que lo diferencia lo uno del otro es que la acreditación es voluntaria, mientras el licenciamiento es de carácter obligatorio para las universidades peruanas. Como punto adicional, se puede decir que el licenciamiento es de primer nivel para ofrecer un servicio de calidad, mientras que la acreditación está en un nivel superior, ya que son condiciones que están por encima de las condiciones mínimas de calidad, y tiene una dinámica que se orienta hacia la excelencia académica (pág. 26)
La SUNEDU iniciara el proceso de licenciamiento con un enfoque institucional, para luego continuar con las 2 siguientes fases, como se muestra en la figura 4.
Figura 4: Enfoque del Modelo de Licenciamiento.
Fuente: Modelo de Licenciamiento y su Implementación en el Sistema Universitario Peruano.
Elaboración: SUNEDU.
8 1.2.8 Licenciamiento institucional y licenciamiento de programas
En el Modelo de Licenciamiento desarrollado por la SUNEDU, se establece que:
A medida que la SUNEDU implemente el Licenciamiento Institucional, diseñará y desarrollará el Licenciamiento de Programas para aprobar o denegar las solicitudes de licenciamiento de programas. Para esto, se elaborarán Condiciones Básicas de Calidad (CBC) aplicables a programas y se diseñarán procedimientos para cada una de ellas. Una vez aprobadas, dichas Condiciones Básicas de Calidad CBC y procedimientos se aplicarán tanto a los programas nuevos como a aquellos que sean parte de la oferta académica de la universidad en proceso de renovación de su licencia institucional. (pág. 31).
Es importante tener en cuenta que el licenciamiento se ha definido como un procedimiento obligatorio que verifique que todos los programas de pregrado de medicina cumplan con las condiciones básicas de calidad (CBC) para que luego se les pueda brindar su autorización de funcionamiento, en este sentido la SUNEDU ha aprobado el modelo de licenciamiento de los Programas de Pregrado de Medicina PPM, con el objetivo de dar a la universidades una autorización legal de funcionamiento, como se muestra en la figura 5 el alcance de esta matriz. (Zegarra, 2019)
Figura 5: Alcance matriz de las CBC institucional y de las CBS de programas de pregrado de medicina.
Fuente: Modelo de licenciamiento de los programas de pregrado de Medicina en el Perú.
Elaboración: Oswaldo Zegarra Rojas.
9 1.2.9 Resultados de gestión sobre el Licenciamiento Institucional
Entre el diciembre de 2015 y el diciembre de 2017, 141 universidades y 4 escuelas de posgrado ya han presentado su Solicitud de Licenciamiento Institucional ante la SUNEDU
A la fecha, al 14 de marzo del 2020, 91 universidades y dos Escuelas de Posgrado han recibido su Licencia de funcionamiento. (Avances y estatus del Licenciamiento, 2020)
10
CAPÍTULO II
PROBLEMÁTICA Y OBJETIVO
2.1 LA PROBLEMÁTICA
2.1.1 Contextualización del problema
a) Diagnóstico de los sistemas existentes SIREPLI Y SIPLIC
Mediante la Orden de Servicio N° 0001445 del 13 de Noviembre del 2018 realizado por la Dirección de Licenciamiento de la SUNEDU, cuyo título señala “SERVICIO PARA EL ANÁLISIS Y DISEÑO DE LAS ESPECIFICACIONES PARA EL DESARROLLO DEL MODULO DE LICENCIAMIENTO DEL SISTEMA DE INFORMACIÓN UNIVERSITARIA (SIU) DE LA DIRECCIÓN DE LICENCIAMIENTO” y que como uno de las actividades describe “Realizar informe de diagnóstico de los sistemas de información que ha implementado o se encuentra en etapa de desarrollo en la dirección de licenciamiento”, en la figura 6 se muestra el alcance de los sistemas existentes frente al procedimiento de licenciamiento desde el registro de la solicitud hasta la emisión resolutiva. (pág. 5)
11 Figura 6: Sistemas actuales frente al Proceso de Licenciamiento.
Fuente: Diagnostico de los sistemas SIREPLI Y SIPLIC.
Elaboración: Propia.
Serán parte del presente requerimiento de diagnóstico los siguientes sistemas de información:
• SIREPLI: Sistema de Registro de Solicitud de Licenciamiento Institucional.
Es un sistema de información desarrollado por encargo de la dirección de licenciamiento con el fin de reemplazar el llenado de información actualmente en formatos de Excel por formularios web que puedan ser accedidos mediante navegadores de internet tanto de forma local (SUNEDU) como remota (UNIVERSIDADES).
Diagnostico:
Es un sistema de información desarrollado por encargo de la dirección de licenciamiento con el fin de reemplazar el llenado de información actualmente en formatos de Excel por formularios web que puedan ser accedidos mediante navegadores de internet tanto de forma local (SUNEDU) como remota (UNIVERSIDADES).
• SIPLIC: Sistema de Proceso de Licenciamiento Institucional – Modulo de Trazabilidad.
Es un sistema de información que permite el registro y seguimiento de la trazabilidad de la información de licenciamiento institucional en el marco del Reglamento del procedimiento de licenciamiento institucional.
12 El insumo principal del sistema es la información del SLI (Solicitud de Licenciamiento Institucional). Cubre las diferentes etapas del procedimiento, gestionando en estas etapas sus estados, plazos y fechas.
Diagnostico:
El sistema SIPLIC ha sido diseñado con el fin de registrar información en la forma de metadata de las etapas, los estados, las fechas.
De las dos entidades de información identificadas tan solo Universidad se identifica como transversal de cara a servir como fuente de información para otros sistemas.
Es útil ante la ausencia de un sistema de información integral, la funcionalidad faltante seria:
▪ Registro de información contenida en los formatos A, C y B.
▪ Flujo de trabajo que desarrolle cada etapa del procedimiento.
▪ Notificación electrónica con el fin de interactuar indirectamente de manera más fluida en el intercambio de información.
▪ Herramienta para la gestión de los viáticos.
Conclusiones:
Como conclusión ambos esfuerzos (SIREPLI y SIPLIC) cumplen un propósito específico que en el caso de SIREPLI es bastante limitado y en el caso de SIPLIC constituye la única herramienta vigente con información de trazabilidad mientras no se cuente con un módulo integral de licenciamiento.
Recomendación:
• SIREPLI: Si bien es cierto nunca se llegó a implementar, al no desarrollar más mecanismos que solo el registro y al estar descontinuado debido a los cambios constantes en el proceso evolutivo del procedimiento de licenciamiento, no se recomienda como punto de inicio para cualquier nuevo esfuerzo que integre los registros de la información de los formatos como meta.
• SIPLIC: El sistema tiene claro su propósito que es el de trazabilidad. Se recomienda su uso mientras no se cuente con otro sistema de información que absorba la información que este sistema provee.
13 b) Gestión inadecuada de la documentación del administrado
(Universidad).
El procedimiento de licenciamiento inicia con el registro de la solicitud de licenciamiento por parte de la universidad, donde la universidad presenta toda la documentación necesaria para poder iniciar un proceso de evaluación por parte de SUNEDU, la documentación comprende información de la universidad, como locales, filiales, malla curricular, formatos M (archivos Excel que contiene información de aulas, equipos, docentes, etc.), medios de verificación que avalen el cumplimiento de los CBS, entre otros; dicha documentación comprende folios de documentos de manera física que la universidad deja en mesa de partes del área de atención al ciudadano de la SUNEDU, donde posteriormente serán agrupadas en cajas para las actividades posteriores de “Revisión preliminar de la documentación de la solicitud”.
Cuando se inician las actividades de Revisión documentaria preliminar, los revisores tienes formatos en archivos Excel donde colocan la información de cada documento como numeración, cantidad de folios, y evalúan si la documentación cumple según el modelo de licenciamiento, para luego emitir un informe con los resultados, actualmente con dichos archivos Excel.
c) Comunicación aislada de las áreas involucradas en el procedimiento de LPPM
Durante el procedimiento de licenciamiento, se ven involucrados diferentes áreas administrativas, oficinas, direcciones, gabinete, etc., dicha comunicación interna se hace mediante memorándums que es un documento que se hace cuando un área quiere hacer entrega de alguna documentación a otra. Una vez un área tenga en su poder un folio de documentos, la otra deja de tener conocimiento sobre su avance o proceso, hasta que la misma haga entrega a otra área o devolución al área de origen, esto imposibilita tener trazabilidad sobre lo que se está haciendo en el procedimiento de licenciamiento, y hace que siempre se desconozca el avance real del procedimiento de licenciamiento que es extenso.
d) Administración pública burocrática
Si bien todas las entidades del estado tienen definidas su procedimiento administrativo no podemos ignorar el hecho de que en algunas no se logra la efectividad en los resultados ni el cumplimiento de los objetivos
14 definidos. Una de las razones y la más evidente de las entidades públicas, es que no se cumple el nivel de eficiencia deseada por la comunidad porque no siguen los procesos administrativos o sus procesos no son óptimos para ello. Como también, falta un liderazgo que lleve a los funcionarios de la entidad a trabajar y preocuparse por alcanzar los objetivos institucionales cambiando sus procesos actuales.
Uno de los principales problemas es la enorme cantidad de personal en las entidades públicas. No está mal la contratación necesaria e idónea, pero se mira un número alto en contrataciones, lo que ocasiona los niveles de ineficiencia en las entidades públicas: lo que llamamos burocracia.
Hay que tener en cuenta que la burocracia como forma de gestión, es el modelo que más eficiente y efectivo ha habido en una entidad pública, aunque en estos tiempos tenga una imagen negativa porque frena la eficiencia que se espera. Los funcionarios deberían replantear y mejorar sus procesos para lo que realmente necesite su entidad de caras a la comunidad, sino será inevitable la burocracia e ineficiencia en su administración.
2.1.1 Problema General
Los sistemas (SIREPLI y SIPLIC) de la dirección de licenciamiento cumplen un propósito específico que en el caso de SIREPLI es bastante limitado según su alcance a solo el registro de archivos Excel de los formatos que la Universidad presenta y en el caso de SIPLIC constituye la única herramienta vigente que solo tiene información de trazabilidad a nivel macro por no tener un módulo integral del procedimiento de licenciamiento.
2.1.1 Problema Especifico
• Gestión inadecuada de la documentación que la universidad presenta, como la información de la institución, filiales, locales, mallas curriculares, formatos M y medios de verificación según CBC’s.
• Comunicación aislada de las áreas involucradas en el procedimiento de licenciamiento.
• No hay trazabilidad de las actividades del procedimiento, solo de forma macro.
15
• Mala gestión al realizar la evaluación de las solicitudes por parte de los evaluadores.
• Delegación manual de las solicitudes a los evaluadores de DILIC 2.2 OBJETIVOS
2.2.1 Objetivo general
Analizar, diseñar e implementar una solución basada en tecnologías de información, para sistematizar y digitalizar el proceso de “Licenciamiento del Programa de Pregrado de Medicina” para la Dirección de Licenciamiento (DILIC) de la Superintendencia Nacional de Educación Superior Universitaria (SUNEDU).
2.2.1 Objetivos específicos
• Optimización del procedimiento de licenciamiento orientado por procesos
• Gestión documental digital de la documentación que presenta el administrado (Universidad).
• Creación de la solicitud electrónica de licenciamiento de programas.
• Estandarización y automatización de los formatos P que presenta el administrado (Universidad).
• Interacción digital del administrado (Universidad).
• Implementación de notificación electrónica.
• Firma digital de documentos.
• Integración y comunicación con SIU.
16
CAPÍTULO III
METODOLOGÍAS, TÉCNICAS Y/O HERRAMIENTAS
3.1 METODOLOGÍAS
3.1.1 Metodología ágil de desarrollo de software
Las metodologías ágiles son métodos de desarrollo de software en los que las necesidades y las soluciones evolucionan a través de una estrecha colaboración entre equipos multidisciplinarios. Se caracterizan por enfatizar la comunicación sobre la documentación, el desarrollo evolutivo y la flexibilidad.
Estas metodologías surgieron a principios de 2001 en respuesta a los modelos de procesos clásicos existentes. La aparición de procesos ágiles se debe al hecho de haber encontrado estos supuestos clave en desarrollos anteriores:
• Es difícil predecir qué requisitos persistirán y cuáles cambiarán, así como las prioridades de los clientes.
• El diseño y desarrollo de software están intercalados. Por lo tanto, se llevarán a cabo conjuntamente, probando el diseño a medida que se crea, ya que es difícil predecir cuánto diseño es necesario antes de implementarlo realmente.
• El análisis, el diseño y la implementación no son predecibles desde el punto de vista de la planificación.
Teóricamente, la agilidad se puede aplicar a cualquier proceso de software, sin embargo, han surgido modelos de proceso propios con esta filosofía. En este tipo de modelo, según el Manifiesto Ágil publicado en 2001, se valora lo siguiente:
• A las personas sobre procesos y herramientas.
• Al software que se ejecuta en la documentación exhaustiva.
17
• La colaboración del cliente en la negociación de un contrato.
• La respuesta al cambio acerca de seguir un plan.
Además, para responder a los supuestos clave descritos anteriormente, los modelos de desarrollo ágil deben cumplir con lo siguiente:
• Sea progresivamente adaptable.
• Tener abundantes comentarios de los clientes.
• Basado en la entrega continua de incrementos.
3.2.1.1 El equipo de desarrollo
El proceso ágil requiere una serie de características sobre el equipo de desarrollo:
• Excelencia técnica.
• Objetivo común: entregar al cliente un incremento dentro del plazo.
• Colaboración entre todos los actores.
• Autonomía para la toma de decisiones.
• Capacidad de resolución de problemas complejos.
• Confianza y respeto mutuo en el equipo.
• Autoorganización.
3.2.1.2 Principios metodológicos
Según “Agile Alliance” se define los siguientes 12 principios para toda metodología ágil:
• Satisfacer al cliente con entregas tempranas y continuas de software funcionando.
• Los requisitos cambiantes son bienvenidos, incluso en las últimas etapas de desarrollo.
• Entregue software en funcionamiento con frecuencia, de dos semanas a dos meses, cuanto antes mejor.
• El cliente y los desarrolladores deben trabajar juntos a diario durante todo el proyecto.
• Individuos motivados. Bríndeles el entorno y el apoyo que necesitan, y confíe en ellos para hacer el trabajo.
• El método más eficiente y efectivo para transmitir información hacia y dentro del equipo es la conversación cara a cara.
• El funcionamiento del software es la medida principal del progreso.
18
• El desarrollo debe ser sostenible. Los participantes deben poder mantener un ritmo constante indefinidamente.
• Atención continua a la excelencia técnica y buen diseño.
• La simplicidad es esencial, maximizando el progreso del trabajo no realizado.
• Las mejores arquitecturas, los mejores requisitos y diseños surgen de equipos autoorganizados.
• A intervalos regulares, el equipo reflexiona sobre cómo puede ser más efectivo, por lo que su comportamiento se ajusta y se ajusta en consecuencia.
3.2.1.3 Principales metodologías agiles
A continuación, se listan las técnicas basadas en la metodología de desarrollo ágil más populares:
• Programación Extrema XP (Extreme Programming).
• Scrum.
• Dynamic Systems Development Method (DSDM).
• Proceso Unificado Ágil (Agile Unified Process).
• Desarrollo de Software Adaptativo (Adaptive software development).
• Modelado Ágil (Agile Modeling).
Las metodologías ágiles son en realidad una familia de modelos o técnicas, todas ellas comparten la característica de interpretar el desarrollo de software como una actividad en la que siempre hay un cierto grado de incertidumbre.
Incertidumbre que hace necesario poner énfasis en las personas, permitirles autoorganizarse e interactuar, siempre buscando satisfacer los requisitos del cliente, y planeando iteración por iteración, adaptándose flexiblemente a los cambios que seguramente ocurrirán durante la vida del proyecto. (Wikiversity, 2020)
3.2.2 Scrum
Scrum es un framework por el cual las personas pueden abordar problemas de adaptación complejos, mientras entregan productos de máximo valor de manera productiva y creativa, donde es:
• Ligero.
• Fácil de entender
19
• Extremadamente difícil de dominar.
Scrum es un framework que es utilizado para gestionar el desarrollo de productos complejos desde principios de la década de 1990. Scrum no es un proceso o técnica para construir productos; En cambio, es un framework dentro del cual se pueden emplear diversas técnicas y procesos. Scrum muestra la efectividad relativa de las prácticas de gestión de productos y las prácticas de desarrollo para que podamos mejorar. El marco de Scrum consta de equipos de Scrum, roles, eventos, artefactos y reglas asociadas. Cada componente dentro del marco cumple un propósito específico y es esencial para el éxito. Las reglas de Scrum relacionan eventos, roles y artefactos, y gobiernan las relaciones e interacciones entre ellos. La Figura 7 resume el ciclo de vida completo de un proyecto trabajado con Scrum. (Schwager &
Sutherland, 2017)
Figura 7: Flujo de trabajo Scrum.
Fuente: https://knowledge21.es/blog/que-es-el-scrum/.
Elaboración: Digital Transformation powered by The Agile.
3.2.2.1 Teoría de Scrum
Scrum se basa en la teoría de control de procesos empírico. Esto hace que el conocimiento venga de la experiencia y de la toma de decisiones basándose en lo que se conoce.
Scrum emplea un enfoque iterativo e incremental para optimizar la predictibilidad y el control del riesgo. A continuación, se mencionan los 3 pilares que sostienen la implementación del control de procesos
20 empírico: transparencia, inspección y adaptación. (Schwager &
Sutherland, 2017)
• Transparencia
Los aspectos significativos del proceso deben ser visibles para aquellos que son responsables del resultado. La transparencia requiere que dichos aspectos sean definidos por un estándar común (lenguaje común), de tal modo que los observadores compartan un entendimiento común de lo que se está viendo.
• Inspección
Los usuarios de Scrum deben inspeccionar frecuentemente los artefactos de Scrum y el progreso hacia un objetivo (Goal), para detectar variaciones. Su inspección no debe ser tan frecuente como para que interfiera en el trabajo. Las inspecciones son más beneficiosas cuando se realizan de forma diligente por inspectores expertos, en el mismo lugar de trabajo.
• Adaptación
Si un inspector determina que uno o más aspectos de un proceso se desvían de límites aceptables, y que el producto resultante no será aceptable, el proceso o el material que está siendo procesado deben ser ajustados. Dicho ajuste debe realizarse cuanto antes para minimizar desviaciones mayores.
Scrum prescribe cuatro eventos formales, contenidos dentro del Sprint, para la inspección y adaptación.
• Sprint Planning Meeting.
• Daily Scrum.
• Sprint Review.
• Sprint Retrospective 3.2.2.2 El equipo Scrum
El Equipo Scrum consta de un Product Owner, el Equipo de Desarrollo (Development Team) y un Scrum Master. Los equipos Scrum son autoorganizados y multifuncionales, que eligen la mejor manera de llevar a cabo su trabajo y no son dirigidos por personas ajenas al equipo y que tengan todas las habilidades necesarias para llevar a cabo el trabajo sin depender de otras personas que no forman parte del equipo. El modelo de equipo en Scrum está diseñado para optimizar la flexibilidad, la creatividad y la
21 productividad. Los equipos Scrum entregan productos de forma iterativa e incremental, maximizando las oportunidades de retroalimentación. Las entregas incrementales del producto
"terminado" aseguran que siempre esté disponible una versión potencialmente útil y funcional del producto. (Schwager &
Sutherland, 2017)
• Product Owner - El Dueño del Producto
El Product Owner es responsable de maximizar el valor del producto y el trabajo del equipo de desarrollo, y gestionar la el Product Backlog.
Para que el propietario del producto haga bien su trabajo, toda la organización debe respetar sus decisiones sobre el contenido y la priorización del Product Backlog.
• Development Team - Equipo de Desarrollo
El Equipo de Desarrollo está formado por los profesionales multidisciplinarios autoorganizados que realizan el trabajo de entregar un Incremento de producto "terminado".
• Scrum Master
El Scrum Master es un líder que está al servicio del Equipo Scrum, para que el Scrum sea comprendido y adoptado correctamente.
El Scrum Master también ayuda a las personas externas al Equipo Scrum, a comprender qué interacciones con el Equipo Scrum son necesarias y cuáles no. El Scrum Master facilita estas interacciones para maximizar el valor creado por el Equipo Scrum.
3.2.2.3 Eventos de Scrum
En Scrum hay eventos predefinidos con el fin de crear regularidad y minimizar la necesidad de reuniones no definidas en Scrum. Todos los eventos son time-boxes (bloques de tiempo), que tienen una duración máxima. Una vez que comienza un Sprint, su duración es fija y no se puede acortar o alargar. Otros eventos pueden finalizar siempre que se alcance el objetivo del evento, asegurando que se pase una cantidad de tiempo adecuada sin permitir desperdicio en el proceso.
Además del propio Sprint, que es un contenedor del resto de eventos, cada uno de los eventos Scrum constituye una oportunidad formal
22 para la inspección y adaptación de algún aspecto. Estos eventos están diseñados específicamente para permitir una transparencia e inspección vitales. La falta de cualquiera de estos eventos resulta en una reducción de la transparencia y constituye una oportunidad perdida para inspeccionar y adaptarse. (Schwager & Sutherland, 2017)
• El sprint
El corazón de Scrum es el Sprint, es un bloque de tiempo (timebox) de un mes o menos durante el cual se crea un incremento de producto "Finalizado" utilizable y potencialmente desplegable. Es más conveniente si la duración de los Sprints es consistente durante todo el esfuerzo de desarrollo. Cada nuevo Sprint comienza inmediatamente después de completar el Sprint anterior.
Los Sprints contienen y consisten en la Reunión de Planificación del Sprint (Sprint Planning Meeting), los Scrums Diarios (Daily Scrums), el trabajo de desarrollo, la Revisión del Sprint (Sprint Review), y la Retrospectiva del Sprint (Sprint Retrospective).
Cada Sprint puede considerarse un proyecto con un horizonte no mayor de un mes. Al igual que los proyectos, los Sprints se usan para lograr algo. Cada Sprint tiene una definición de qué se va a construir, un diseño y un plan flexible que guiará la construcción y el trabajo y el producto resultante.
• Sprint Planning Meeting - Reunión de planificación de Sprint
El trabajo para realizar durante el Sprint se planifica en la Reunión de Planificación de Sprint. Este plan se crea a través del trabajo colaborativo de todo el Equipo Scrum.
La reunión de planificación de Sprint tiene una duración máxima de ocho horas para un Sprint de un mes. Para Sprints más cortos, el evento suele ser más corto. El Scrum Master asegura que el evento se lleve a cabo y que los asistentes comprendan su propósito. El Scrum Master le enseña al Equipo Scrum a permanecer dentro del bloque de tiempo.
• Sprint Goal - Objetivo del Sprint
El Sprint Goal es una objetivo para que el Sprint sea alcanzada mediante la implementación de la Lista de Producto. Proporciona
23 orientación al Equipo de Desarrollo sobre lo que se está construyendo el incremento. Es creado durante el Sprint Planning Meeting. El objetivo del Sprint ofrece al equipo de desarrollo cierta flexibilidad con respecto a la funcionalidad implementada en el Sprint. Los elementos de la Product Backlog seleccionados ofrecen una función consistente, que puede ser el objetivo del Sprint. El objetivo del Sprint puede representar otro nexo de unión que haga que el Equipo de Desarrollo trabaje en conjunto y no en iniciativas separadas.
Mientras el equipo de desarrollo trabaja, se mantiene el objetivo del Sprint en mente. Con el fin de satisfacer el objetivo del Sprint se implementa la funcionalidad y la tecnología. Si el trabajo resulta ser diferente de lo que el Equipo de Desarrollo espera, ellos colaboran con el Product Owner para negociar el alcance del Sprint Backlog.
• Scrum Diario (Daily Scrum)
El Scrum Diario es una reunión con un bloque de tiempo de 15 minutos para que el Equipo de Desarrollo sincronice sus actividades y cree un plan para las próximas 24 horas. Esto se realiza inspeccionando el trabajo avanzado desde el último Scrum Diario y haciendo una proyección acerca del trabajo que podría completarse antes del siguiente.
El Scrum Diario se realiza a la misma hora y en el mismo lugar todos los días para reducir la complejidad.
El Equipo de Desarrollo usa el Scrum Diario para evaluar el progreso hacia el Objetivo del Sprint y para evaluar qué tendencia sigue este progreso hacia la finalización del trabajo contenido en la Lista del Sprint. El Scrum Diario optimiza las posibilidades de que el Equipo de Desarrollo cumpla el Objetivo del Sprint. Cada día, el Equipo de Desarrollo debería entender cómo intenta trabajar en conjunto como un equipo autoorganizado para lograr el Objetivo del Sprint y crear el Incremento esperado hacia el final del Sprint. El Equipo de Desarrollo o los miembros del equipo a menudo se vuelven a reunir inmediatamente después del Scrum Diario, para tener discusiones detalladas, o para adaptar, o replanificar el resto del trabajo del Sprint.
• Revision de Sprint (Sprint Review)
24 Al final del Sprint se lleva a cabo una Revisión de Sprint para inspeccionar el Incremento y adaptar la Lista de Producto si fuese necesario. Durante la Revisión de Sprint, el Equipo Scrum y los interesados colaboran acerca de lo que se hizo durante el Sprint.
Basándose en esto, y en cualquier cambio a la Lista de Producto durante el Sprint, los asistentes colaboran para determinar las siguientes cosas que podrían hacerse para optimizar el valor. Se trata de una reunión informal, no una reunión de seguimiento, y la presentación del Incremento tiene como objetivo facilitar la retroalimentación de información y fomentar la colaboración.
Se trata de una reunión restringida a un bloque de tiempo de cuatro horas para Sprints de un mes. Para Sprints más cortos, se reserva un tiempo proporcionalmente menor. El Scrum Master se asegura de que el evento se lleve a cabo y que los asistentes entiendan su propósito. El Scrum Master enseña a todos a mantener el evento dentro del bloque de tiempo fijado.
El resultado de la Revisión de Sprint es una Lista de Producto revisada, que define los elementos de la Lista de Producto posibles para el siguiente Sprint. Es posible además que la Lista de Producto reciba un ajuste general para enfocarse en nuevas oportunidades.
• Retrospectiva de Sprint (Sprint Retrospective)
La Retrospectiva de Sprint es una oportunidad para el Equipo Scrum de inspeccionarse a sí mismo y crear un plan de mejoras que sean abordadas durante el siguiente Sprint.
La Retrospectiva de Sprint tiene lugar después de la Revisión de Sprint y antes de la siguiente Reunión de Planificación de Sprint.
Se trata de una reunión restringida a un bloque de tiempo de tres horas para Sprints de un mes. Para Sprints más cortos se reserva un tiempo proporcionalmente menor. El Scrum Master se asegura de que el evento se lleve a cabo y que los asistentes entiendan su propósito. El Scrum Master enseña a todos a mantener el evento dentro del bloque de tiempo fijado. El Scrum Master participa en la reunión como un miembro del equipo ya que la responsabilidad del proceso Scrum recae sobre él. (Schwager &
Sutherland, 2017)
25 3.2.2.4 Artefactos de Scrum
Los artefactos de Scrum representan trabajo o el valor en diversas formas que son útiles para proporcionar transparencia y oportunidades para la inspección y adaptación. Los artefactos definidos por Scrum están diseñados específicamente para maximizar la transparencia de la información clave, lo cual es necesario para garantizar que todos tengan la misma comprensión del artefacto. (Schwager & Sutherland, 2017)
• Product Backlog - Lista de Producto
El Product Backlog es una lista ordenada de todo lo que podría ser necesario en el producto, y es la única fuente de requisitos para cualquier cambio que se realice en el producto por medio del Product Owner, sus principales características son:
▪ Nunca está completa. El desarrollo más temprano de la misma solo refleja los requisitos conocidos y mejor entendidos al principio.
▪ Evoluciona como también lo hacen el producto y el entorno en el que se utilizará.
▪ Es dinámica; cambiando constantemente para identificar lo que el producto necesita para ser adecuado, competitivo y útil. Mientras exista el producto, su Lista de productos también existe.
• Sprint Backlog - Lista de Pendientes del Sprint
El Sprint Backlog es el conjunto de elementos de la Lista de Producto seleccionados para el Sprint, más un plan para entregar el Incremento de producto y conseguir el Sprint Goal., sus principales características son:
▪ Es una predicción hecha por el Equipo de Desarrollo acerca de qué funcionalidad formará parte del próximo Incremento y del trabajo necesario para entregar esa funcionalidad en un Incremento “Terminado”.
▪ Hace visible todo el trabajo que el Equipo de Desarrollo identifica como necesario para alcanzar el Objetivo del Sprint.
26 3.2.3 Metodología de Desarrollo de Software de la Oficina de Tecnologías de
la Información (OTI) de la SUNEDU
Para el desarrollo de sistemas nuevos, así como el mantenimiento evolutivo de sistemas en producción, la Oficina de Tecnologías de la Información (OTI) se basará en la adaptación en el uso del Proceso Unificado de Desarrollo de Software (Rational Unified Process RUP®) desarrollado por Rational Software, el cual incluirá la ejecución de las actividades de Requerimientos, Análisis y Diseño, Implementación, Pruebas, Distribución y Despliegue. Los procesos relacionados a Administración del Proyecto y Gestión de Configuración deberán ser cubiertos en la Metodología de Gestión de Proyectos. Este marco metodológico está alineado al cumplimiento de la NTPISO/IEC 12207:2016 - Ingeniería de Software y Sistemas. Procesos del ciclo de vida del software seleccionados. (Wikipedia, 2020)
Para la notación se utilizará el Lenguaje de Modelamiento Unificado (UML), el cual es un lenguaje para especificar, visualizar, construir y documentar los artefactos del Proceso de Desarrollo de Software. (Metodologia de desarrollo de sistemas v1.0, 2018)
3.2.3.1 Norma técnica peruana 12207: 2016
El objetivo de esta norma es dar un conjunto definido de procesos para ayudar en la comunicación entre adquirientes, proveedores y otros interesados en el ciclo de vida de un producto software.
Esta norma agrupa las actividades que se pueden ejecutar durante el ciclo de vida de un sistema software en siete grupos de procesos, cada uno de los procesos del ciclo de vida dentro de estos grupos se describe en términos de su propósito y de los resultados que se buscan y listan las actividades y tareas que se deben realizar para alcanzar esos resultados.
Tener en cuenta que la norma también es adaptable, que dependiendo de las necesidades de la organización se podrá seleccionar un subconjunto apropiado de procesos.
Los procesos indicados en la Norma son lo que se muestran en las siguientes figuras 8 y 9:
27 Figura 8: Procesos del ciclo de vida de la NTP 12207:2106.
Fuente: Metodologías de desarrollo de sistemas v1.0.
Elaboración: Oficina de Tecnologías de la Información 2018 – SUNEDU.
28 Figura 9: Procesos del ciclo de vida de la NTP 12207:2106.
Fuente: Metodologías de desarrollo de sistemas v1.0.
Elaboración: Oficina de Tecnologías de la Información 2018 – SUNEDU.
Los procesos que se han mencionado guardan relación a la metodología de desarrollo que se describira en el presente informe para cubrir las necesidades del negocio de la OTI.
En esta sección se describirá todo lo relacionado al punto 7.1
“Procesos de Implementación del software”
3.2.3.2 Procesos de implementación del software
Los procesos de implementación definidos por la Oficina de Tecnologías de información son:
• Proceso de análisis de requisitos de software
Establecer y documentar los requisitos del software (incluyendo las especificaciones de las características de calidad) como especificaciones funcionales y no funcionales, servicios externos, requisitos de calificación, especificaciones de seguridad;
definición de datos y requisitos de la base de datos, requisitos de instalación, de documentación de usuario, de mantenimiento.
• Proceso de diseño arquitectural del software
29 Transformar los requisitos del elemento de Software en una arquitectura que describa de alto nivel e identifique los componentes de software. Se debe asegurar que todos los requisitos del elemento de software estén afinados a sus componentes de software y refinados para facilitar el diseño detallado. la arquitectura del elemento de software debe estar documentada.
• Proceso de diseño detallado del software
El propósito del Proceso de Diseño Detallado del Software es proveer un diseño para el software que implemente y se pueda verificar frente a los requisitos y a la arquitectura del software, y que esté suficientemente detallado para permitir la codificación y la prueba.
• Proceso de construcción del software
Desarrollar y documentar cada unidad de software y base de datos, probar cada unidad de software y base de datos asegurando la satisfacción de sus requisitos, evaluar el código y resultados de pruebas considerando la trazabilidad hasta los requisitos y diseño, consideración interna o externa, factibilidad de integración y operación y mantenimiento.
• Proceso de integración del software
Desarrollar un plan de integración para integran las unidades de software y los componentes de software en el elemento de software, y probar como los nuevos elementos se desarrollan de acuerdo con el plan de integración.
• Proceso de pruebas de calificación del software
Realizar la prueba de calificación según los requisitos de calificación para el elemento de software. Se debe evaluar el diseño, el código, las pruebas, los resultados de prueba y la documentación del usuario considerando la cobertura de requisitos, conformidad de resultados esperados. (SUNEDU, 2018)
3.2.3.3 Proceso unificado de desarrollo de software (RUP)
El Proceso Unificado de Desarrollo de Software provee una disciplina para la asignación de tareas y responsabilidades dentro de una organización de desarrollo. Sus metas son asegurar la producción de
30 software de alta calidad reuniendo las necesidades de los usuarios finales, dentro de cronogramas y presupuestos predecibles. El Proceso Unificado de Desarrollo de Software captura muchas de las mejores prácticas del desarrollo moderno de software de tal forma que es adaptable a un amplio rango de proyectos (como aplicaciones Web) y organizaciones.
El RUP soporta un enfoque de desarrollo iterativo e incremental, que permite iteraciones tempranas que se enfocan en validar y producir una arquitectura de software que facilita un desarrollo inicial que toma la forma de un prototipo ejecutable que gradualmente evoluciona convirtiéndose en el sistema final, teniendo además implícito en su proceso de desarrollo la evaluación continua de la calidad. Este enfoque posibilita el trabajo ágil del desarrollo de los productos de software. (Wikipedia, 2020)
El Proceso Unificado de Desarrollo de Software:
• Es un proceso iterativo, dada la sofisticación de los sistemas actuales, no es posible primero definir secuencialmente el problema completo, diseñar la solución completa, construir el software y probar el producto al final. Se requiere un enfoque iterativo que permita una comprensión progresiva del problema a través de refinamientos y el ensamblaje gradual de una solución efectiva en múltiples iteraciones. Un enfoque iterativo brinda una mayor flexibilidad al agregar nuevos requisitos o cambios tácticos a los objetivos del negocio y permite que el proyecto identifique y resuelva los riesgos de manera temprana.
• Es un proceso controlado. Este enfoque iterativo solo es posible a través de una gestión de requisitos y un control de cambios muy cuidadosos, para garantizar en cada punto una comprensión común de la funcionalidad esperada, el nivel de calidad esperado y permitir un mejor control de los costos y los cronogramas.
• Orienta sus actividades para crear y mantener modelos. En lugar de enfocarse en producir grandes cantidades de documentos, enfatiza el desarrollo y mantenimiento de modelos en representaciones semánticas del sistema de software en desarrollo.
• Se centra en el desarrollo de una arquitectura de software robusta, que facilita el desarrollo paralelo, minimiza el doble
