ES (OPM2-01.I.TPL.v3.0.1) .Inyeccion A SQL. (20-05-2023) - (v3.0.) NCripto

Organización: NCripto
Departamento: TI
Acta de Constitución del Proyecto
Inyección de SQL
Fecha: 17/07/2023
Versión: 3.0
Versión de Plantilla: 3.0.1
Esta plantilla está basada en PM² V3.0

Para consultar la última versión de esta plantilla por favor visite el Wiki PM²
<La Metodología PM² tiene su origen en la Comisión Europea. Open PM² proporciona directrices y
plantillas para facilitar la gestión y documentación de sus proyectos.>
Inyección de SQL Acta de Constitución
Índice
1. INFORMACIÓN DE CONTROL DEL DOCUMENTO ................................................................................... 5
APROBACIÓN Y REVISIÓN DEL DOCUMENTO: ........................................................................................... 5
HISTORIAL DE DOCUMENTOS: .................................................................................................................. 5
GESTIÓN DE LA CONFIGURACIÓN: LOCALIZACIÓN DEL DOCUMENTO ....................................................... 6
2. RUTA CRITICA ....................................................................................................................................... 9
3. RESUMEN EJECUTIVO ......................................................................................................................... 10
4. CONSIDERACIONES SOBRE EL CASO DE NEGOCIO ............................................................................... 10
DESCRIPCIÓN DEL PROYECTO ................................................................................................................. 11
1.1 Alcance ............................................................................................................................................ 11
Incluido ("dentro del" alcance) .......................................................................................................... 11
1.2 Excluido ("fuera del" alcance) ......................................................................................................... 11
1.3 Criterios de Éxito ............................................................................................................................. 11
1.4 Necesidades de las Partes Interesadas y de los Usuarios ............................................................... 11
1.5 Entregables...................................................................................................................................... 11
1.6 Características ................................................................................................................................. 12
1.7 Restricciones ................................................................................................................................... 12
1.8 Supuestos ........................................................................................................................................ 12
1.9 Riesgos ............................................................................................................................................ 12
5. COSTE, TIEMPO Y RECURSOS .............................................................................................................. 12
1.10 Coste ............................................................................................................................................... 12
1.11 Plazos e hitos ................................................................................................................................... 14
1.12 Recursos Planificados ...................................................................................................................... 14
6. ENFOQUE ............................................................................................................................................ 15
1.13 Metodología .................................................................................................................................... 15
1.14 Gestión de Cambios ........................................................................................................................ 15
Cambio del Proyecto .......................................................................................................................... 15
Gestión de la Configuración ............................................................................................................... 15
7. GOBERNANZA Y PARTES INTERESADAS .............................................................................................. 16
1.15 Estructura ........................................................................................................................................ 16
1.16 Roles and Responsabilidades .......................................................................................................... 16
8. SOBRE EL MANUAL DEL PROYECTO ..................................................................................................... 17
9. VISIÓN GENERAL DEL PROYECTO ........................................................................................................ 17
9.1. Resumen del Proyecto ...................................................................................................................... 17
10. ENFOQUE DEL PROYECTO ................................................................................................................. 17
10.1. Ciclo de Vida del Proyecto .............................................................................................................. 17
10.2. Adaptación de PM² – Documentación Requerida del Proyecto ..................................................... 17
10.4. Otros Estándares ............................................................................................................................ 18
10.5. Reglas Específicas para la Gestión del Proyecto ............................................................................. 18
10.6. Resolución de Conflictos y Elevación a Niveles de Decisión Superiores ......................................... 18
11. PROCESOS DEL PROYECTO ................................................................................................................ 18
11.1. Gestión de Riesgos .......................................................................................................................... 18
Fecha: 17/07/2023 1/ 89 Versión: 3.0

11.2. Gestión de Incidencias .................................................................................................................... 19

11.3. Gestión de Requisitos ..................................................................................................................... 20
11.4. Gestión de Cambios del Proyecto ................................................................................................... 20
11.5. Gestión de la Calidad ...................................................................................................................... 21
11.6. Gestión de la Configuración ............................................................................................................ 21
11.7. Gestión de las Comunicaciones ...................................................................................................... 22
11.8. Gestión de la Aceptación de los Entregables .................................................................................. 23
11.9. Gestión de la Transición ................................................................................................................. 23
11.10. Gestión de la Implantación en el Negocio .................................................................................... 23
11.11. Gestión de Recursos ..................................................................................................................... 24
12. MEDICIÓN DEL PROGRESO DEL PROYECTO ....................................................................................... 24
12.1. Enfoque de Medición del Progreso del Proyecto ........................................................................... 24
12.2. Informes del Proyecto .................................................................................................................... 24
12.3. Listas de Control del Proyecto ........................................................................................................ 25
13. ROLES Y RESPONSABILIDADES DEL PROYECTO .................................................................................. 25
13.1. Matriz Consolidada de Asignación de Responsabilidades (RAM/RASCI) ........................................ 25
13.2. Descripción de Roles y Responsabilidades del Proyecto ................................................................ 26
Partes Interesadas.............................................................................................................................. 27
Comité de Dirección del Proyecto (CDP) ............................................................................................ 27
Grupo de Implementación en el Negocio (GIN) ................................................................................. 30
Equipo Central del Proyecto (ECP) ..................................................................................................... 31
Equipo de Soporte a Proyectos (ESP) ................................................................................................. 35
14. APÉNDICE 1: REFERENCIAS Y DOCUMENTOS RELACIONADOS ........................................................... 36
15. LISTA DE CONTROL DE PARTES INTERESADAS ................................................................................... 36
12.1 Resumen General ............................................................................................................................ 36
12.2 Inicio ................................................................................................................................................ 37
12.3 Planificación ..................................................................................................................................... 38
12.4 Ejecución .......................................................................................................................................... 38
12.5 Cierre................................................................................................................................................ 38
12.5 Seguimiento ..................................................................................................................................... 38
16. PLAN DE TRABAJO DEL PROYECTO .................................................................................................... 39
13.1 Introducción .................................................................................................................................... 39
13.1.2 Resumen del Proyecto ............................................................................................................ 39
13.1.3 Desglose del Trabajo .............................................................................................................. 39
13.1.4 Estructura de desglose del trabajo ........................................................................................ 40
13.2 Plantilla para el desglose del trabajo. ............................................................................................ 41
13.2.1 Plantilla para la descripción de los componentes del desglose del trabajo. ........................ 41
13.3Estimación de Recursos y Costes ...................................................................................................... 47
13.4Recursos Necesarios ......................................................................................................................... 47
13.4.1Plan de Recursos ............................................................................................................................ 48
13.4.2Disponibilidad de Recursos ............................................................................................................ 49
17. PLAN DE EXTERNALIZACION.............................................................................................................. 49
14.1ACTA DE CONSTITUCION DEL PROYECTO ......................................................................................... 49
14.1.1Introducción .................................................................................................................................. 49
14.2 Requisitos de Formación y Manuales ............................................................................................. 49
14.2.1 Derechos de Propiedad .......................................................................................................... 49
Fecha: 17/07/2023 2/ 89 Versión: 3.0
14.2.2. Requisitos de Compatibilidad ............................................................................................... 50

14.2.3. Otros Requisitos .................................................................................................................... 50
14.3Método de Contratación ................................................................................................................. 50
14.3.1Método .................................................................................................................................... 50
14.3.2. Programación de la Entrega .................................................................................................. 50
14.3.3. Gestión de la Calidad y Soporte Post Entrega ...................................................................... 51
14.4Criterios de Evaluación .................................................................................................................... 51
14.4.1Criterios ................................................................................................................................... 51
14.4.2Capacidades Técnicas .............................................................................................................. 51
14.5.1Interfaz del Contratista ........................................................................................................... 52
14.5.2Responsabilidad de la Firma ................................................................................................... 52
15.PLAN DE GESTION DE REQUISITOS ..................................................................................................... 52
15.1. Introducción.................................................................................................................................... 52
15.2Objetivos de la Gestión de Requisitos ............................................................................................. 52
18. 2.1Proceso de Gestión de Requisitos .......................................................................................... 53
15.3. El Ciclo de Vida de los Requisitos .................................................................................................. 54
19. 4.Roles y Responsabilidades en la Gestión de Requisitos ............................................................... 55
15.5. Herramientas y Técnicas ................................................................................................................ 56
15.6. Matriz de Trazabilidad de los Requisitos ...................................................................................... 57
15.7. Gestión de Cambios de los Requisitos........................................................................................... 58
16.PLAN DE GESTION DE CAMBIOS DEL PROYECTO ................................................................................ 59
16.1. Introducción ................................................................................................................................... 59
16.2. Objetivos de la Gestión de Cambios .............................................................................................. 59
16.3. Proceso de la Gestión de Cambios ................................................................................................ 59
16.4. Roles y Responsabilidades en la Gestión de Cambios .................................................. 61
16.5. Herramientas y Técnicas ................................................................................................................ 62
16.6. Registro de Cambios ...................................................................................................................... 63
16.6.1. FORMULARIO DE SOLICITUD DE CAMBIO .................................................................................... 64
16.7. Evaluación del Cambio y Actividades de Recomendación de Acción ........................................... 64
16.8. Decisiones de Aprobación de Cambios ......................................................................................... 65
16.9. Actividades de Implementación de Cambios ................................................................................ 65
16.10. Control de Cambios e Informes ................................................................................................... 65
20. ENGINEERING PROJECT CLOSEOUT REPORT ...................................................................................... 66
21. INFORME DE FIN DE PROYECTO ........................................................................................................ 69
Introducción ............................................................................................................................................ 69
22. ÉXITO DEL PROYECTO ....................................................................................................................... 69
Eficacia ..................................................................................................................................................... 69
Evaluación del Proyecto (Coste-Cronograma-Alcance-Calidad) .............................................................. 70
23. EVALUACIÓN DE LA GESTIÓN DEL PROYECTO ................................................................................... 71
General .................................................................................................................................................... 71
Gestión de Riesgos................................................................................................................................... 71
Gestión de Partes Interesadas ................................................................................................................. 72
Comunicaciones del Proyecto ................................................................................................................. 73
Incidencias y Resolución de Conflictos .................................................................................................... 73
Aceptación de Entregables ...................................................................................................................... 74
Fecha: 17/07/2023 3/ 89 Versión: 3.0

24. TRANSICIÓN DEL PROYECTO. ............................................................................................................ 74

25. IMPLEMENTACIÓN EN EL NEGOCIO .................................................................................................. 75
26. GOBERNANZA Y EVALUACIÓN DEL EQUIPO ...................................................................................... 76
Desempeño de la Organización Participante........................................................................................... 76
Desempeño del Equipo Central del Proyecto .......................................................................................... 77
27. LECCIONES APRENDIDAS Y MEJORES PRÁCTICAS .............................................................................. 78
28. RECOMENDACIONES POST-PROYECTO ............................................................................................. 79
29. LOGIN ............................................................................................................................................... 80
30. PANTALLA DE ACCESO ...................................................................................................................... 81
31. PROCESO DE REGUISTRO .................................................................................................................. 83
32. INTERFAZ .......................................................................................................................................... 84
33. CÁLCULO DE COSTOS ........................................................................................................................ 85
34. ACTA DE CIERRE DE PROYECTO ......................................................................................................... 86
35. RAZÓN DE CIERRE ............................................................................................................................ 88
36. ACEPTACIÓN DE LOS PRODUCTOS O ENTREGABLES ...................................................................... 88
37. APROBACIONES ................................................................................................................................ 89
Fecha: 17/07/2023 4/ 89 Versión: 3.0

1. INFORMACIÓN DE CONTROL DEL DOCUMENTO

Descripción Valor
Título del Documento: Acta de Constitución del Proyecto
Título del Proyecto: Inyección de SQL
Autor del Documento: Luis Fernando Licona Reyna
Jorge Montero Cruz
Francisco Javier Nicolas Ortiz
Daniela Parra Gutiérrez
Hugo Villalpando Montesinos
Propietario del Proyecto: Universidad Tecnológica de Nezahualcóyotl
Proveedor de Soluciones NCripto
Director de Proyecto: Francisco Javier Nicolas Ortiz
Versión del Documento: 3.0
Confidencialidad: Alta
Fecha: 17/07/2023
Aprobación y revisión del documento:

NOTA: Se requieren todas las aprobaciones. Se deben mantener registros de cada aprobación.
Todos los revisores de la lista se consideran necesarios a menos que se indiquen explícitamente como
Opcionales. El director del Proyecto (DP) se responsabiliza de este documento salvo indicación expresa de lo
contrario.
Nombre Rol Acción Fecha
Luis Fernando Licona Analista y documentador Investigación, Análisis y 08/05/2023
Reyna Revisa
Jorge Montero Cruz Administrador de Investigación, Análisis, 08/05/2023

servidores Configuración y Revisa
Francisco Javier Nicolas Diseñador y programador Investigación, Análisis, 08/05/2023
Ortiz Configuración, Aprueba y
Revisa
Daniela Parra Gutiérrez Diseñador y programador Investigación, Análisis, 08/05/2023
Configuración, Aprueba y
Revisa
Hugo Villalpando Analista y documentador Investigación, Análisis y 08/05/2023
Montesinos Revisa
Veronica Martinez Perez Representante legal Aprobación de documento 08/05/2023
final
Historial de documentos:
El Autor del Documento está autorizado a hacer los siguientes tipos de cambios al documento sin requerir que
el documento sea aprobado nuevamente:
Editorial, formato y ortografía.
Aclaraciones.
Fecha: 17/07/2023 5/ 89 Versión: 3.0

Para solicitar un cambio en este documento, póngase en contacto con el Autor del Documento o el Propietario
del Proyecto.
Las modificaciones de este documento se resumen en la siguiente tabla en orden cronológico inverso (primero
la última versión).
Revisión Fecha Creada por Breve descripción de los cambios

1 20/05/2023 Francisco Javier Nicolas Ortiz y Creación de documento
Gestión de la configuración: Localización del documento

La última versión de este documento está guardada en
https://drive.google.com/drive/folders/1QN8dZdMb_bJ7L4sefecL3jQf9aLg2t6o
Nombre del Proyecto: Inyección de SQL

Iniciador: Mitigar ataques a bases de Organización / Universidad
datos SQL. Unidad: Tecnológica de
Nezahualcóyotl
Propietario del Universidad Tecnológica de Fecha de Solicitud: 08/05/2023
Proyecto (PP): Nezahualcóyotl
Proveedor de NCripto Autoridad que Francisco Javier
Soluciones (PS): aprueba: Nicolas Ortiz
Esfuerzo Estimado (EE): Dirección, NCripto, Francisco Fecha objetivo de 31/07/2023
Javier Nicolas Ortiz entrega:
Tipo de Desarrollo
Interno Externalizado Mixto No conocido
Contexto / Situación (Necesidad de Negocio / Problema / Oportunidad)

La Inyección SQL que proporciona una visión general de la especificación de recursos sobre el ataque
de inyección booleana. Con el fin de conocer las principales funciones realiza, los datos asociados y los
factores, restricciones, supuestos y dependencias que afectan al desarrollo, así como también la
manera de mitigar dicho ataque.
Base legal
El inicio de proyecto Inyección de SQL tiene como fecha de inicio 08/05/2023 y su término 31/07/2023
se acuerda por ambas partes las fechas antes mencionadas para el cumplimiento del proyecto dando
como inicio 3000 dólares por parte de Universidad Tecnológica de Nezahualcóyotl para poder arrancar
con el proyecto y al finalizar se realizará un pago de 60mil pesos a NCripto proveedor que desarrollará
la implementación del proyecto Inyección de SQL.
Ambas partes se someten a las oficinas del Entado de México para cualquier incumplimiento legal del
proyecto Inyección de SQL.
Clausulas para cliente Universidad Tecnológica de Nezahualcóyotl
1.- Cancelación de proyecto por causa ajena a proveedor NCripto se penalizará con el pago completo
del proyecto que tiene como total 1000 dólares, por lo tanto, Universidad Tecnológica de
Nezahualcóyotl tendrá que cubrir la cantidad faltante a dicha cantidad.
Fecha: 17/07/2023 6/ 89 Versión: 3.0

2.- El atraso de cualquier pago penalizara con 10% de la cantidad no pagada a NCRIPTO.
3.- Realizar cualquier cambio a los objetivos que se requieren al azar en el proyecto Inyección de SQL
se penalizara con 10% de la cantidad total del proyecto más costos extra.
Clausulas para Proveedor NCripto
1.- No cumplir con las fechas estipuladas de inicio de proyecto 08/05/2023 y su término 31/07/2023 se
penalizará con 10% del total del proyecto por cada 10 días de atraso.
2.- No cumplir con los requerimientos solicitados por parte del cliente penalizara con 10% del total del
proyecto.
3.- Cancelación de Proyecto por parte de NCripto se penalizará con 50% del total del proyecto el cual
será pagado a Universidad Tecnológica de Nezahualcóyotl en una fecha no mayo a 10 días después de
la notificación de cancelación por alguna vía legal.
Resultados (importancia alta)

La disponibilidad del sistema debe ser continua con un nivel de servicio para los usuarios de 7 días por
24 horas por 365dias del año, garantizando la disponibilidad de sus bases de datos SQL.
Salvaguardar las Bases de Datos SQL de la Universidad Tecnológica de Nezahualcóyotl de
ataques internos y externos en su sitio web Manteniendo la disponibilidad, integridad y
confidencialidad de su información para prevenir daños, robo y vulnerabilidad ante un
ciberataque.
Impacto (importancia alta)

Mitigar los ataques SQL de nivel Booleano para poder solventar los riesgos que presente las bases de
datos SQL propiedad del cliente.
Criterios de Éxito
Ejecución de script mediante servidor de página web.
Respaldo de Base de datos SQL de Universidad Tecnológica de Nezahualcóyotl
Correcta sincronización de Base de datos SQL
Acceso a página Web vía Intranet para personal de Universidad Tecnológica de Nezahualcóyotl
Niveles de seguridad para usuarios de Portal WEB
Supuestos (importancia alta)

Garantizar la confiabilidad, la seguridad y el desempeño del sistema informático vía intranet a los
diferentes usuarios. En este sentido la información almacenada o registros realizados podrán ser
consultados y actualizados permanente y simultáneamente, sin que se afecte el tiempo de respuesta.
Garantizar la seguridad del sistema con respecto a la información y datos que se manejan tales sean
documentos, archivos y contraseñas.
Facilidades y controles para permitir el acceso a la información al personal autorizado a través de
Internet, con la intención de consultar y subir información pertinente para cada una de ellas.
Fecha: 17/07/2023 7/ 89 Versión: 3.0

Restricciones (importancia alta)

Será necesario equipo de cómputo en buen estado con las características siguientes:
Adaptadores de red.
Procesador de 1.66 GHz o superior
Memoria mínima de 8 Gb
Mouse
Teclado
Sistema operativo: Windows 10.
Riesgos (importancia alta)

Perdida de información o daño en Base de datos SQL.
Perdida de Gestión en página web
Fecha: 17/07/2023 8/ 89 Versión: 3.0

2. RUTA CRITICA
Fecha: 17/07/2023 9/ 89 Versión: 3.0

3. RESUMEN EJECUTIVO
NCripto empresa dedicada al desarrollo de nuevos proyectos manteniendo actualizada la infraestructura de TI
salvaguardando los activos críticos de las empresas.
Solución y mitigación a ataques SQL mediante el método de inyección Booleana proyectando el desarrollo de
un buen funcionamiento de las Bases de Datos SQL administradas y protegidas por la Universidad Tecnológica
de Nezahualcóyotl.
Se brindará conocimiento para administrar y mantener el correcto funcionamiento a los servicios SQL.
Se proporciona una visión general de la especificación de recursos sobre el ataque de inyección booleana. Con
el fin de conocer las principales funciones que éste realiza, los datos asociados, factores, restricciones,
supuestos y dependencias que afectan al desarrollo, así como también la manera de mitigar dicho ataque.
Utilizamos las herramientas informáticas más avanzadas que nos permiten estar conectados en todo momento
tanto con el cliente como entre nosotros para poder ofrecer el mejor servicio de calidad.
Mantenemos al cliente totalmente informado sobre las últimas leyes laborales.
Elaboramos dossier y nos desplazamos al centro de trabajo para explicar las últimas actualizaciones que nos
permitirán estar al día en materia de subvenciones y bonificaciones.
4. CONSIDERACIONES SOBRE EL CASO DE NEGOCIO

Una consulta de SQL es una solicitud enviada a una base de datos por algún tipo de actividad o función, como
consultas de datos o una ejecución de código SQL que se debe realizar. Un ejemplo es cuando la información
de inicio de sesión se envía a través de un formulario web para que el usuario pueda acceder al sitio.
Normalmente, este tipo de formulario web está diseñado para aceptar solo tipos muy específicos de datos,
como un nombre o una contraseña. Cuando se agrega esa información, esta se coteja contra una base de datos
y, si coincide, se otorga acceso al usuario. Si no coincide, se niega el acceso.
Los posibles problemas surgen porque la mayoría de los formularios web no tienen forma de detener el ingreso
de información adicional. Los atacantes pueden aprovechar esta debilidad y utilizar los cuadros de entrada del
formulario para enviar sus propias solicitudes a la base de datos. Esto podría permitirles llevar a cabo una
amplia gama de actividades maliciosas, desde el robo de datos confidenciales hasta la manipulación de la
información de la base de datos para sus propios fines.
Debido a la prevalencia de sitios web y servidores que utilizan bases de datos, las vulnerabilidades de inyección
de SQL son uno de los tipos de ciberataques más antiguos y generalizados. Varios avances en la comunidad
hacker aumentaron el riesgo de este tipo de ataques; en especial, la llegada de herramientas para detectar y
aprovechar la inyección de SQL. Disponibles de forma gratuita en desarrolladores de código abierto, estas
herramientas les permiten a los cibercriminales realizar ataques automáticamente en tan solo minutos, ya que
les permiten acceder a cualquier tabla o columna de la base de datos con tan solo un clic y un proceso de
ataque.
Fecha: 17/07/2023 10/ 89 Versión: 3.0

DESCRIPCIÓN DEL PROYECTO

1.1 Alcance
Incluido ("dentro del" alcance)

Mitigar ataques de Inyección a SQL BOOLEANO.
Limitar accesos a página web vía intranet.
Mantener servicio SQL activo.
Tener niveles de usuarios que permitirá limitar las modificaciones a Base de Datos SQL.
1.2 Excluido ("fuera del" alcance)

Cualquier otro ataque SQL que no entre como inyección a SQL BOOLEANO.
Caída de Servicio por falta de redundancia en servicios a internet
Caída de Servicio por falta de redundancia en servicios LAN
Caída de Servicio por falta de redundancia en servicios MPLS
1.3 Criterios de Éxito

Cumplir con las normas técnicas del programa.
Cumplir con el cronograma establecido por el gerente del proyecto, para la
construcción del programa.
Cumplir de manera eficaz y eficiente con el presupuesto establecido para el proyecto, el cual es de 14000 mil
dólares.
Cumplir con la normatividad.
1.4 Necesidades de las Partes Interesadas y de los Usuarios
ID Descripción de la Necesidad Prioridad

1.1 Usuario: El sistema SQL está enfocado a cubrir los requerimientos de la Universidad Alta
Tecnológica de Nezahualcóyotl. Por lo que se encargara de realizar las siguientes
funciones que solo podrán tener acceso los administradores: Acceder mediante un
inicio de sesión, consultar datos de un alumno y cerrar sesión.
1.2 Buscadores: Se pondrá especial cuidado en la construcción del sitio para facilitar la Alta
indexación en buscadores web.
1.3 Permitir el acceso vía intranet del sitio web Alta
1.5 Entregables
Informes: Se elaborarán informes de avance por la empresa administradora del proyecto, dirigidos al
interventor del Proyecto.
Contratos: Se entregará copia de los contratos con acta de inicio y liquidación al interventor del programa.
ID Nombre del Entregable Descripción del Entregable

2.1 Manual sobre software Se entregará la documentación el cual contendrá la información sobre
el programa.
2.2 Actualización de funciones Se hará una evaluación de actualización cada año.
2.3 Riesgos que prevenir Se hará entrega de un manual sobre hacking.
Fecha: 17/07/2023 11/ 89 Versión: 3.0

1.6 Características
Necesidad Característica Entregable

Relacionada
3.1 A medida que el modelo de caso de uso toma forma, Manual técnicas con
se recomienda actualizar su descripción para hacer descripción detallada de la
referencia a los casos de uso que lo detallan. implementación realizada
3.2 Entrega de documentos desarrollados para proyecto Respaldo de documentos por
medio de disco duro
3.3 Entrega de respaldo de script de configuración para Respaldo de script de
proyecto configuración por medio de
disco duro
1.7 Restricciones
Proporcionar accesos de administrador a directores de cada carrera.
Proporcionar accesos de usuario a profesores.
Crear niveles de usuarios en página web para restringir accesos.
1.8 Supuestos
Tener accesos de administrador en portal para poder modificar información en SQL
Tener accesos de usuario en portal para poder modificar información en SQL
Mitigar ataque de inyección booleano a SQL
Mantener el SQL sin riego a ataques o perdida de información
1.9 Riesgos
ID Descripción y Estado Dueño Estrategia de Detalles de la
Nivel de Riesgo3
Probabilidad1
Detalles del del Respuesta al Acción

Impacto2
Riesgo Riesgo Riesgo4
4.1 Perdida de Down 20% Alto Alto Cliente Tener Contar con
sitio web redundancia en servidor alterno
página web
4.2 Daño a Base Down 5% Alto Alto Cliente Respaldo de SQL Tener servidor de
de datos SQL Respaldo para
tener redundancia
en sincronización
de Base SQL
5. COSTE, TIEMPO Y RECURSOS

1.10 Coste
1 Valor numérico que indica la probabilidad de ocurrencia del riesgo.

2 Valor numérico que indica la severidad relativa del impacto del riesgo, en caso de ocurrir.
3 Nivel de riesgo. Es el producto de probabilidad e impacto (NR=P*I).
4 Las posibles estrategias de respuesta al riesgo son: Evitar / Aceptar / Reducir / Transferir para riesgos negativos (amenazas) y Explotar /
Aceptar / Mejorar / Compartir para riesgos positivos (oportunidades).
Fecha: 17/07/2023 12/ 89 Versión: 3.0

202a 202b 202c 202d 2020e
Gasto Línea Importe5 Línea Importe Línea Importe Línea Importe Línea Importe Coste Total
presupuestaria presupuestaria presupuestaria presupuestaria presupuestaria
Desarrollo de la US$500 US$500

US$500 US$600 US$500 US$2,000
Solución6 (k€)
Mantenimiento US$500 US$450
7 días de
de la Solución7 US$500 US$550 US$550 US$2,550
capacitación
(k€)
Servicio US$150 US$100
8 de
Asistencia (k€) US$150 US$150 US$200 US$800
asistencia
técnica
US$900 US$500 Personal
Formación9 (k€) US$1,000 US$500 US$1,000 de US$3,900
apoyo
2 US$1,000 US$700
Infraestructura10 2 días de
US$1,000 ordenadores US$1,000 US$1,000 $US4,700
(k€) capacitación
portátiles
Total, por año US$3,050 US$1,250
US$3,150 US$2,800 US$3,250
(k€)
EJC de personal 8 hrs por 5 6 hrs por 5
4 hrs por 5 6 hrs por 5 8 hrs por 5
interno por año días días
11 días días días
5 Si no puede proporcionar un importe, proporcione al menos una estimación cualitativa (p.ej., 20 días de capacitación, 2 ordenadores portátiles, etc.)
6 Desarrollo (recursos humanos): proporcionar el coste total (previsto) para el desarrollo de la solución.
7 Mantenimiento (recursos humanos): proporcionar el coste total (previsto) en k€ por año para mantener la solución.
8 Asistencia (recursos humanos): proporcionar el coste total (anticipado) en k€ por año para prestar asistencia a la solución (p.ej., sitio web, servicio de asistencia técnica, operaciones, etc.).
9 Formación (recursos humanos): proporcionar el coste total (previsto) para garantizar la formación de los usuarios, el personal de apoyo y de operaciones, etc.
10 Infraestructura: proporcionar el coste total (previsto) de la infraestructura necesaria para entregar, apoyar, operar y mantener la solución entregada.
11 Equivalente a Jornada Completa (EJC): proporcione el esfuerzo total (anticipado) que el personal interno empleará en el proyecto (en días-persona, personas-semana, personas-mes u personas-año).
Date: 17/07/2023 13 /89 Doc. Versión: 3.0

Inyección de SQL Manual del Proyecto
1.11 Plazos e hitos
Fecha objetivo de
ID Descripción del Hito
entrega
5.1 Inicio del proyecto 08/05/2023
5.2 Investigación de ataque BOOLEANO 10/05/2023
5.3 Revisión de script para página web 11/05/2023
5.4 Diseño de script para eliminar ataques de Inyección SQL BOOLEANO 11/06/2023
5.5 Realizar documentación de avances de proyecto 15/07/2023
5.6 Entrega de avances Fase 1 17/08/2023
5.7 Mejoras en documentación encontradas en revisión Fase 1 20/08/2023
5.8 Inicio Implementación de Proyecto. 25/08/2023
5.9 Entrega de Avances de Fase 1 30/08/2023
1.12 Recursos Planificados
ID Recurso Requerido Descripción
6.1 Asesora sobre un tema en específico, sobre todo

Consultor
de forma profesional.
6.2 Asesor legal También trabaja en el proyecto.
Fecha: 17/07/2023 14/ 89 Versión: 3.0

6. ENFOQUE
1.13 Metodología
Se desarrollara el proyecto mediante una metodología de Cascada con apoyo de las herramientas de PMBOK
para realizar buenas prácticas y lineamientos que nos dará el refuerzo necesario para el proyecto y elaborar
adecuadamente cada una de sus etapas, como lo es la iniciación que se definirá en qué consistirá este proyecto
y llevando de manera clara la justificación para la empresa ,la planificación que nos ayudara a analizar cómo
conseguir los recursos humanos ,materiales y financiación para llevar a cabo el proyecto, la ejecución que se
presentara con cada uno de los integrantes asi como los objetivos y responsabilidades que se dividirá entre el
equipo de trabajo previamente reunidos, el control nos ayudara a revisar como llegar a actuar en caso de que
se presente una problemática para esto nos apoyaremos en un manual de riesgos, establecido para estos casos
de emergencia y finalmente el cierre que es aquí donde se presentara ya el producto terminado sin ninguna
falla o problemática hacia el cliente, brindándole la solución solicitada hacia nosotros y actuando como los
expertos recomendados al cliente para la mejor solución al darnos su confianza para el proyecto.
1.14 Gestión de Cambios

• Con base en el Análisis y recomendaciones respecto a las solicitudes obtenidas durante la ejecución
del proyecto. Se realizarán los cambios previamente autorizados
Cambio del Proyecto

• Revisar, analizar y aprobar las solicitudes de cambio de forma rápida
• Gestionar los cambios aprobados
• Revisar, aprobar o rechazar todas las acciones preventivas y correctivas recomendadas
• Documentar el impacto total de las solicitudes de cambio
Gestión de la Configuración
Tabla de control de gestión de cambios del proyecto.
Cualquier interesado involucrado en el proyecto puede solicitar cambios. Aunque los cambios pueden iniciarse
verbalmente, siempre deben registrarse por escrito e ingresarse al sistema de tablas de control gestión de
cambios y/o al sistema de gestión de la configuración.
Entregables del alcance del producto Autorizo

No. Fase Entregable Firma de autorización
1. 1 Documentacion de inicios para proyecto Francisco Javier Nicolas Ortiz
Fecha: 17/07/2023 15/ 89 Versión: 3.0

7. GOBERNANZA Y PARTES INTERESADAS

1.15 Estructura

Reyna Revisa
Francisco Javier NicolasDiseñador y programador Investigación, Análisis, 08/05/2023
Revisa
Revisa
Montesinos Revisa
Veronica Martinez Perez Representante legal Aprobación de 08/05/2023
documento final
1.16 Roles and Responsabilidades

Reyna Revisa
Revisa
Revisa
Montesinos Revisa
documento final
Fecha: 17/07/2023 16/ 89 Versión: 3.0

8. SOBRE EL MANUAL DEL PROYECTO

El Manual del Proyecto documenta el enfoque seleccionado para implementar los objetivos del proyecto.
También se destacan los procesos clave de control que se utilizarán, las políticas y normas del proyecto y el
enfoque general de gestión.
El Manual de Proyecto es un documento importante que define los resultados de la planificación (es decir,
define los planes necesarios para la gestión del proyecto, así como en qué medida deben ser personalizados
y/o adaptados).
El Manual del Proyecto se convierte en la base para la gestión del proyecto a lo largo de su ciclo de vida y es un
punto de referencia importante para todos los miembros del proyecto y las partes interesadas. Este manual se
mantiene actualizado durante toda la vida del proyecto. Durante la Fase de Cierre, el Manual del Proyecto se
convierte en un punto de referencia importante para la Reunión de Revisión de Fin de Proyecto, y debe estar
debidamente cerrada y archivada.
9. VISIÓN GENERAL DEL PROYECTO

9.1. Resumen del Proyecto
Se realizó una introducción a inyección SQL y se proporciona una visión general de la especificación de recursos
de sobre el ataque de inyección booleana. Con el fin de conocer las principales funciones que éste debe realizar,
los datos asociados y los factores, restricciones, supuestos y dependencias que afectan al desarrollo, así como
también la manera de mitigar dicho ataque.
10. ENFOQUE DEL PROYECTO

10.1. Ciclo de Vida del Proyecto
Inicio: Esta especificación de requisitos está dirigida a la entrada del usuario que se realiza a través de un
formulario de acceso. Se consulta la base de datos SQL con los campos enviados por el usuario para
autentificarlos. La estructura es de la consulta a su base de datos. Abarcará las áreas de servicios escolares.
Planificación:
Ejecución:
Cierre de proyecto:
10.2. Adaptación de PM² – Documentación Requerida del Proyecto
Si no, breve
Plantilla Si/No Localización explicación de la
razón
Solicitud de Inicio del Proyecto  Pag 2
Caso de Negocio  Pag 13
Acta de Constitución del Pag 10


Proyecto
Manual del Proyecto (este Documento manual de Inyección a
documento)  SQL
Plan de Trabajo del Proyecto  Documento plan de trabajo
Plan de Transición  Pag 12
Fecha: 17/07/2023 17/ 89 Versión: 3.0

10.4. Otros Estándares

Adicionalmente a PM2, el proyecto seguirá otras metodologías como las que se describen a continuación:
• PM² Ágil para la gestión del desarrollo de TI.
Los siguientes estándares serán considerados cuando se definan los distintos elementos del proyecto:
• IEEE 830
10.5. Reglas Específicas para la Gestión del Proyecto

• -Entrega de reportes mensuales en tiempo y forma para el análisis del avance del proyecto
• -Asistencia puntual y vestimenta formal para las juntas previamente organizadas
• -Participación en cada junta y aportación hacia el proyecto
• -Prohibido los insultos de cualquier tipo hacia sus compañeros de trabajo
• -Llevar material previamente preparado de los avances del proyecto, si es posible en diapositivas
• -Impresiones solamente cuando haya confirmación de los superiores de trabajo correcto para
imprimir
• -Ideas claras y precisas al momento de redactar un reporte o cualquier otro documento que asi lo
requiera
• -Total comunicación en todo momento con el cliente del avance de su proyecto
• -Asistencia forzosa cuando el cliente visite la empresa para los avances del proyecto
• -Prohibido hablar con el cliente temas fuera de su proyecto
• -Asignar un numero de folder a la documentación correspondiente al proyecto para la ubicación
inmediata cuando se requiera
10.6. Resolución de Conflictos y Elevación a Niveles de Decisión Superiores
Los conflictos son situaciones en las que una o ambas partes perciben una amenaza. Se consideran temas
críticos y pueden ser planteados por cualquiera de las Partes Interesadas del proyecto. El equipo de
gestión del proyecto debe identificar, registrar y plantear de forma proactiva estos problemas para su
resolución. Cuando es necesario, los conflictos se discuten en las Reuniones Semanales de Situación
del Proyecto o, si es necesario, se elevan al Comité de Dirección del Proyecto (CDP).
Las actividades de resolución de conflictos se registran en el Registro de Incidencias, mientras que las decisiones
de resolución de conflictos se pueden registrar en el Registro de Decisiones.
El procedimiento de elevar a un nivel superior de decisión para este proyecto es el siguiente:
11. PROCESOS DEL PROYECTO

11.1. Gestión de Riesgos
El proceso de gestión de riesgos del proyecto define las actividades para identificar, evaluar, priorizar, gestionar
y controlar los riesgos que puedan afectar a la ejecución del proyecto y al logro de sus resultados. Este es un
proceso de cuatro pasos:
Identificación de Riesgos: Un ataque de inyección de SQL exitoso puede tener consecuencias graves para una
empresa. Esto se debe a que un ataque de inyección de SQL puede lograr lo siguiente: Exponer datos sensibles.
Los atacantes pueden extraer datos, lo que pone en riesgo la exposición de datos sensibles almacenados en el
servidor SQL.
Fecha: 17/07/2023 18/ 89 Versión: 3.0

Evaluación de Riesgos:
Nivel Impacto
Ataques de inyección de SQL Provoca daños graves a las empresas, como la
pérdida de confianza de los clientes si se
quebrantan datos confidenciales de los usuarios.
Daño a base de datos SQL El no tener servidor de Respaldo para tener
redundancia en sincronización de Base SQL y no
tener pedida de información.
Perdida de sitio web Debemos tener un servidor alterno para
protección de datos.
Control de Riesgos:
Capacitar al personal: Concientizar al equipo responsable de la aplicación web sobre los riesgos relacionados
con la SQLi y brindar la capacitación necesaria para todos los usuarios en función del puesto.
Mantener el control de la entrada de los usuarios: Cualquier entrada de usuario utilizada en una consulta de
SQL genera un riesgo. Aborda las entradas de los usuarios autenticados o internos de la misma manera que las
entradas públicas hasta que se verifiquen. Otórgales a las cuentas que se conectan a la base de datos SQL solo
los privilegios mínimos necesarios. Utilice listas blancas como práctica estándar en lugar de listas negras para
verificar y filtre la entrada de los usuarios.
Utilizar las versiones más recientes: Es importante usar la versión más reciente del entorno de desarrollo para
maximizar la protección, ya que es posible que a las versiones anteriores les falten funciones de seguridad.
Asegúrese de instalar el software y los parches de seguridad más recientes cuando estén disponibles.
Analizar de forma continua las aplicaciones web: Use herramientas integrales de administración del
rendimiento de las aplicaciones. Analizar regularmente las aplicaciones web permite identificar y abordar
posibles vulnerabilidades antes de que provoquen daños graves.
Usar un firewall: El firewall de una aplicación web (WAF) a menudo se usa para filtrar SQLi, así como otras
amenazas en línea. Un WAF confía utiliza una extensa lista de firmas que se actualiza con frecuencia y le permite
filtrar consultas de SQL maliciosas. Por lo general, la lista tiene firmas para abordar vectores de ataque
específicos y se corrige con regularidad en respuesta a vulnerabilidades recientemente descubiertas.
11.2. Gestión de Incidencias
El proceso de gestión de incidencias del proyecto define las actividades relacionadas con la
identificación, documentación, evaluación, priorización, asignación, resolución y control de
incidencias. Es un proceso de cuatro pasos que el director de Proyecto (DP) ejecuta siempre que sea
necesario a lo largo del ciclo de vida del proyecto:
• Identificación de Incidencias: las incidencias pueden ser identificadas por cualquier parte interesada
del proyecto a lo largo de su ciclo de vida, utilizando diferentes canales de comunicación como
reuniones, correos electrónicos e informes. Las incidencias se registran en el Registro de incidencias.
• Evaluación de la Incidencia y Recomendación de Acción: una primera evaluación informal considera la
categoría, el impacto, la urgencia y el tamaño de la incidencia, seguida de un análisis más detallado
para identificar la causa fundamental y recomendar una solución. Esta información se documenta en
el Registro de Incidencias y se utiliza como entrada para los responsables de la toma de decisiones (en
función del proceso de elevación). La decisión se documenta en el Registro de Decisiones.
• Implementación de Acciones: después de evaluar las incidencias y aprobar las acciones de corrección,
el director del Proyecto (DP) incorporará estas acciones en el Plan de Trabajo del Proyecto y actualizará
la documentación relacionada con el proyecto, como los planes y registros del proyecto.
• Control de Incidencias: las Reuniones de Situación del Proyecto se celebrarán semanalmente y se
utilizarán para revisar el estado de las incidencias y las acciones relacionadas, y para identificar nuevas
incidencias. Además, el director de Proyecto (DP) informará mensualmente sobre el estado de las
principales incidencias al Comité de Dirección del Proyecto (CDP) y, cuando sea adecuado, a otras
partes interesadas del proyecto.
Fecha: 17/07/2023 19/ 89 Versión: 3.0

11.3. Gestión de Requisitos

El proceso de gestión de requisitos comprende las actividades relacionadas con la especificación, evaluación,
aprobación, seguimiento y validación de los requisitos del proyecto. Este proceso consiste en los siguientes
pasos:
• Especificar los Requisitos: reúna los requisitos del proyecto junto con las Partes Interesadas del
proyecto y documéntelos sin ambigüedades en el Documento de Requisitos. Estructúrelos añadiendo
los metadatos pertinentes.
• Evaluar los Requisitos: el Equipo del Proyecto evalúa la viabilidad de los requisitos y estima los costes
para realizarlos. El director de Proyecto (DP) equilibra la lista de requisitos con las otras restricciones
del proyecto (presupuesto, tiempo, etc.) y las propone a los interesados en el proyecto.
• Aprobar Requisitos: el director de Proyecto (DP) negocia y acuerda los requisitos que se realizarán
durante el proyecto con las partes interesadas, como el Propietario del Proyecto (PP) o el responsable
de Negocio (RN). Los requisitos aprobados se convierten en la línea de base del alcance del proyecto.
• Supervisar la Implementación de los Requisitos: el director de Proyecto (DP) supervisa continuamente
la implementación de los requisitos por parte del Equipo Central del Proyecto (ECP), además de
detectar nuevos requisitos o cambios en los requisitos existentes.
• Validar los requisitos Implementados: cuando se implementan los requisitos, la solución es validada
por el usuario de negocio con el fin de evaluar si se satisface la necesidad inicial del negocio. La
aceptación formal de los entregables del proyecto debe cumplir con el proceso de Gestión de la
Aceptación de Entregables.
11.4. Gestión de Cambios del Proyecto

El proceso de gestión de cambios del proyecto define las actividades relacionadas con la identificación,
documentación, evaluación, aprobación, priorización, planificación y control de cambios, y su comunicación a
todas las partes interesadas pertinentes. Es un proceso de cinco pasos que el director de Proyecto (DP) ejecuta
siempre que sea necesario a lo largo del ciclo de vida del proyecto:
• Identificación de Cambios: una solicitud de cambio puede ser presentada formalmente a través de un
Formulario de Solicitud de Cambio, o puede ser identificada y planteada durante las reuniones como
resultado de decisiones, incidencias o riesgos. El Registro de Cambios contiene información para
identificar el cambio, como el solicitante, una breve descripción, fecha de identificación, etc.
• Evaluación del Cambio y Recomendación de Acción: se evalúa el tamaño y el impacto del cambio en
el alcance, cronograma, coste, calidad, riesgo y otros límites del proyecto, tras lo cual el director de
Proyecto (DP) documenta una acción recomendada en el Registro de Cambios. Esta información se
utiliza como entrada para la aprobación formal del cambio por parte de los tomadores de decisiones
apropiados.
• Aprobación de Cambios: la aprobación de un cambio del proyecto seguirá el proceso de elevación
definido para este proyecto. Para los cambios que no tienen un impacto significativo en el plazo de
entrega y el presupuesto, los cambios pueden ser aprobados durante las Reuniones de Situación del
Proyecto. Otros cambios (de tamaño L o XL) son aprobados por el Comité de Dirección del Proyecto
(CDP). Los detalles de la decisión se documentan en el Registro de Cambios.
• Implementación de Cambios: las actividades relacionadas con la implementación de los cambios
aprobados se documentarán en el Plan de Trabajo del Proyecto.
• Control de Cambios: los cambios nuevos o abiertos serán identificados/revisados semanalmente
durante las Reuniones de Situación del Proyecto y el director de Proyecto (DP) actualizará el Registro
de Cambios con los resultados del análisis/revisión. Para los cambios de tamaño Medio, Alto y Muy
Alto, el director de Proyecto (DP) informará mensualmente sobre su estado al Comité de Dirección del
Proyecto (CDP) y, cuando sea adecuado, a otras partes interesadas en el proyecto.
Fecha: 17/07/2023 20/ 89 Versión: 3.0

11.5. Gestión de la Calidad

El proceso de gestión de la calidad del proyecto comprende todas las actividades (relacionadas tanto con los
procesos como con los productos) que aumentarán la capacidad de alcanzar los resultados esperados del
proyecto identificados en el Acta de Constitución del Proyecto. El proceso consta de cinco pasos:
• Definir los Atributos de Calidad: identificar los objetivos, el enfoque, los requisitos, las actividades y
las responsabilidades del proceso de gestión de calidad del proyecto y cómo se implementará a lo
largo del mismo. Las actividades de gestión de calidad se añadirán al Plan de Trabajo del Proyecto. La
Lista de Control de Revisión de Calidad y la Lista de Control de Aceptación de Entregables se crean
durante la Fase de Planificación.
• Realizar el Aseguramiento de la Calidad: las actividades de aseguramiento de la calidad se llevarán a
cabo evaluando el diseño de los controles del proyecto, confirmando que están implementados y
evaluando su eficacia operativa.
Estas actividades considerarán los objetivos de calidad del proyecto junto con los riesgos de este.
Además, el aseguramiento de la calidad valida el cumplimiento de las normas y reglamentos de la
organización, así como de las normas, reglamentos y leyes gubernamentales y de la industria
pertinentes. Las actividades de garantía de calidad serán realizadas por una persona encargada de la
Garantía de Calidad del Proyecto (GCP) y por los roles correspondientes del proyecto (ECP, RN, PS).
• Realizar el Control de Calidad: la Lista de Control de Revisión de Calidad será utilizada por el director
de Proyecto (DP) para evaluar las actividades de control de calidad y validar el cumplimiento de los
planes en términos de alcance, tiempo, coste, calidad, organización del proyecto, comunicación,
riesgos, contratos y satisfacción del cliente. Además, el director del Proyecto (DP) resumirá y
documentará los hallazgos de la Lista de Control de Revisión de Calidad, su impacto, recomendaciones
junto con cualquier acción de corrección/mejora. Los registros del proyecto también se utilizarán para
documentar los riesgos, problemas, decisiones y cambios relacionados.
• Realizar la Aceptación de Entregables (consulte también sección 4.8): la Lista de Control de Aceptación
de Entregables da soporte al seguimiento de la situación de todas las actividades que son condición
previa para la entrega de los productos del proyecto al Propietario del Proyecto (PP) y su aceptación
formal. Los entregables del proyecto son aceptados si las actividades de aceptación se realizan con
éxito y dentro de las tolerancias preestablecidas. Los entregables del proyecto pueden ser aceptados
condicionalmente incluso con un conjunto de incidencias conocidas, siempre que estén
documentadas y que exista un plan para abordarlas.
• Realizar la Aceptación Final: el director de Proyecto (DP) informará sobre la ejecución del proyecto en
la Reunión de Revisión de Fin de Proyecto y elaborará el Informe de Fin de Proyecto. La documentación
y los registros del proyecto se actualizarán, revisarán y archivarán. La aceptación final se obtiene del
Propietario del Proyecto (PP), a través del Documento de Aceptación del Proyecto, que después de la
finalización del proyecto se comunica a todas las partes interesadas pertinentes.
11.6. Gestión de la Configuración
El procedimiento de gestión de la configuración del proyecto incluye la identificación de los elementos de
configuración del proyecto (EC), sus atributos y códigos de estado, el establecimiento de líneas de base, la
definición de funciones y responsabilidades para los cambios autorizados en los EC, así como el mantenimiento
y el control de un repositorio de proyectos.
Almacenamiento de Artefactos de Gestión del Proyecto
El director del Proyecto (DP) estructurará los artefactos de gestión de proyectos según las fases de PM2,
siguiendo la siguiente convención de carpetas:
• 01 inicio
• 02 planificación
• 03 ejecución
• 04 monitorización y control
• 05 cierre
Fecha: 17/07/2023 21/ 89 Versión: 3.0

Convención de Nomenclatura de Artefactos de Gestión del Proyecto

Se empleará la siguiente convención en la nomenclatura de los artefactos:
(XX).(Nombredeldocumento).(NombredelProyecto).(aaaa-mm-dd).v(x.x), donde:
• (XX) (dos caracteres numéricos) número de artefacto único dentro de la carpeta que indica la
secuencia del documento.
• v(x.x) indica la versión del artefacto. Los números de versión como "0.x" significan que el documento
no ha sido aprobado todavía; los cambios menores se reflejarán en el decimal (número de
revisiones) y los cambios mayores (revisiones formales) en el número de versión.
Versiones de los Artefactos de Gestión del Proyecto
Todos los artefactos de gestión del proyecto están bajo control de versiones, exceptuando los registros del
proyecto y las listas de control.
11.7. Gestión de las Comunicaciones
Reunión Responsable Frecuencia

Comienzo de la Planificación Director de Proyecto (DP) Una vez
Comienzo de la Ejecución Director de Proyecto (DP) Una vez
Situación del Proyecto Director de Proyecto (DP) Semanalmente
Equipo de Ejecución del Proyecto Líder del Equipo (LE) Semanalmente
Revisión del Proyecto Director de Proyecto (DP) Cada 2 días
Comité de Dirección del Proyecto Propietario del Proyecto (PP) Cada 3 días
Control de Cambios Director de Proyecto (DP) Cada 3 días
Revisión de Fin de Proyecto Director de Proyecto (DP) Una vez
Los siguientes informes del proyecto serán preparados:
Informe Responsable Frecuencia

Informe de Situación del Proyecto Director de Proyecto (DP) En la Reunión de Situación
del Proyecto
Informe de Progreso del Proyecto Director de Proyecto (DP) Con la Reunión de Revisión
del Proyecto
Informe de Revisión de Calidad Director de Proyecto (DP) Cada 2 días
Informe de Situación de la Contratista ------
Externalización (Contratista)
Informe Fin de Proyecto Director de Proyecto (DP) Con la revisión del Final del
Proyecto
Fecha: 17/07/2023 22/ 89 Versión: 3.0

11.8. Gestión de la Aceptación de los Entregables

El proceso de gestión de calidad comprende las actividades relacionadas con la aceptación de los entregables,
con el fin de aumentar la capacidad de cumplir los criterios de aceptación del proyecto. Este proceso consta de
tres pasos:
• Definir los Criterios de Aceptación: defina los criterios de aceptación para cada uno de los entregables del
proyecto. Esta información se deriva del alcance, el enfoque, las necesidades del cliente, los resultados,
los beneficios esperados y los requisitos del proyecto (tal como se definen en el Caso de Negocio, el Acta
de Constitución del Proyecto, el Manual del Proyecto, el Plan de Trabajo del Proyecto, la documentación
de requisitos y otros documentos relevantes).
• Realizar las Actividades de Aceptación: verifique si los entregables cumplen con los criterios de aceptación.
Las actividades de aceptación de los entregables se detallan y programan en el Plan de Trabajo del
Proyecto.
• Aceptación de Entregables (provisional/final): obtenga la aprobación formal del Propietario del Proyecto
(PP) para cada uno de los entregables del proyecto. La aceptación provisional/final debe documentarse en
el Documento de Aceptación de Entregables. Los entregables del proyecto son aceptados si las actividades
de aceptación (tal como se describen en este plan) se llevan a cabo con éxito y dentro de las medidas,
tolerancias y plazos preestablecidos. Los entregables del proyecto pueden ser aceptados provisionalmente
por un experto/usuario perteneciente al ámbito concreto relacionado con la aceptación, incluso con un
conjunto limitado de incidencias no críticas, siempre que estén documentadas, sean acordadas por las
partes interesadas pertinentes y que exista un plan para abordarlas. El rechazo de los entregables se
gestionará mediante el proceso de gestión de incidencias del proyecto. Después de la resolución de las
incidencias, los entregables se vuelven a revisar y se vuelven a presentar para su aprobación.
11.9. Gestión de la Transición
El proceso de gestión de la transición comprende las actividades relacionadas con la transición sin problemas
del "modo proyecto" al "modo operación". Este proceso consiste en los siguientes pasos:
• Identificar los Objetivos de la Transición: identifique los objetivos a alcanzar al final de la transición. Defina
lo que se debe lograr para que la transición sea un éxito. Documente cualquier condición previa que deba
cumplirse antes de que pueda comenzar la transición.
• Identificar las Actividades de Transición: defina y estime todas las actividades de transición que deben
realizarse antes, durante y después de la transición para alcanzar los objetivos de la misma. Determine
quién es responsable de cada actividad. Integre estas actividades en el conjunto del Plan de Trabajo del
Proyecto y gestiónelas como parte de las actividades normales del proyecto. No olvide la coordinación, la
comunicación u otras actividades de transición más específicas, tales como: copias de seguridad,
conversión de datos, formación, desarrollo de un plan de retorno, etc.
• Elaborar un Calendario de Transición: determine el cronograma y los hitos de la transición. Calcule la
duración del período de transición y el grado de superposición con otras actividades del proyecto.
Desarrolle un cronograma de alto nivel para todas las actividades de transición.
11.10. Gestión de la Implantación en el Negocio
El proceso de gestión de la implementación en el negocio comprende las actividades relacionadas con la
preparación y gestión de los cambios en la organización que se producirán como resultado del proyecto. Este
proceso consiste en los siguientes pasos:
• Identificar el Impacto en los Procesos: evalúe cómo afectará el proyecto a los procesos de negocio ya
existentes en la organización. Defina los nuevos procesos de negocio. Minimice al máximo las
interrupciones en las operaciones normales durante la ejecución del proyecto.
• Identificar el Impacto en las Personas: evalúe cómo impactará el proyecto sobre las personas
utilizando los resultados del proyecto. Considere la resistencia al cambio, la comunicación, el apoyo
funcional, la formación, etc.
• Identificar el Impacto Cultural: evalúe cómo impactará el proyecto en la cultura de la organización.
Considere el comportamiento individual o grupal, las prácticas organizacionales o los valores
compartidos.
Fecha: 17/07/2023 23/ 89 Versión: 3.0

• Definir la Estrategia de Implementación: defina la estrategia de comunicación, las actividades de

promoción y otras actividades de cambio que se recogen dentro de las responsabilidades del proyecto
y que promoverán una implementación sin problemas de los resultados del proyecto en la
organización.
• Definir las Actividades de Cambio: defina las actividades de cambio necesarias que apoyen la
estrategia de implementación. Considere las actividades del proyecto, las actividades de cambio para
la organización y las actividades de cambio posteriores al proyecto.
• Seguimiento de Beneficios: Identifique, describa y recomiende actividades y medidas para evaluar los
beneficios que generará el proyecto en el futuro.
11.11. Gestión de Recursos
Método
Nivel de Nivel de Fecha de
ID del Formación/ de Impartido
Recurso habilidad habilidad finalizació
Recurso habilidad impartici por
actual deseado n prevista
ón
NCripto Programador Python Principiant Avanzado Curso Director de 28/05/202
H1.0 e interno proyecto 3
NCripto Programador Herramientas Principiant Avanzado Curso Director de 29/05/202
H 2.0 software e interno proyecto 3
NCripto Testeador Visual estudio Principiant Avanzado Curso Director de 30/05/202
H 3.0 e extremo 5 proyecto 3
días
12. MEDICIÓN DEL PROGRESO DEL PROYECTO

12.1. Enfoque de Medición del Progreso del Proyecto
Por la UTN, el Coordinador de Proyectos y el Líder de Proyecto designado, elaborarán el documento con las
principales características del progreso. Este documento se denomina medición de desempeño y prevenciones
del proyecto (EVM), el cual se le presentará al Gerente de Proyectos del NCripto en forma física
El Gerente de Proyectos de NCripto deberá elaborar una propuesta del plan de solución para el seguimiento y
control de las actividades. Podrá solicitar reuniones con las áreas usuarias involucradas y con los líderes de la
UTN con el propósito de aclarar o precisar los elementos que requiera para elaborar su estimación.
El Coordinador de Proyectos de UTN y el Gerente de Proyectos del NCripto deberán realizar las revisiones.
Una vez autorizada la estimación, el Gerente de Proyectos del NCripto, elaborará el Plan de Trabajo. Este plan
será de alto nivel y tendrá la formalidad requerida para sustentar los trabajos de desarrollo o mantenimiento
según corresponda.
El plan de trabajo no debe considerar actividades y tiempo invertidos en las reuniones con los usuarios para
conocer el detalle de sus requerimientos, ni las reuniones antes descritas con el Coordinador de Proyectos de
UTN.
12.2. Informes del Proyecto

El Gerente de Proyectos del NCripto y el Coordinador de Proyectos de la UTN, al inicio de actividades, de común
acuerdo, deberán firmar el documento que contenga la metodología a utilizar para presentar los informes del
proyecto.
En caso de que la UTN no llegue a un acuerdo con el NCripto sobre el método a utilizar en la estimación de los
informes para las actividades de cualquier plan de trabajo, la UTN no estará obligada a realizar el proyecto con
el método propuesto por el personal de NCripto, teniendo la posibilidad de implantar la que mejor crea
conveniente para la UTN.
Fecha: 17/07/2023 24/ 89 Versión: 3.0

La UTN se reserva el derecho de aplicar desde el inicio del servicio y durante la vigencia del contrato, la
evaluación de los proyectos a través de la metodología de puntos función, casos de uso, líneas de código o
cualquier otra que considere apropiada para determinar la dimensión de los proyectos. Dicha decisión será
presentada al NCripto para su debida implementación.
12.3. Listas de Control del Proyecto

El Coordinador de Proyectos de UTN convocará a una reunión con el Gerente de Proyectos del NCripto, ambas
personas listaran diferentes los controles a entregar a la, así como una explicación de las actividades generales
del listado, supervisando de la forma sana las actividades.
El programa de las sesiones de listado de control será presentado al Gerente de Proyectos del NCripto
adjudicado. Todas las sesiones se realizarán en las instalaciones de la UTN.
Una vez que se lleven a cabo las sesiones de listado de control, el personal del NCripto adjudicado se encontrará
en posibilidades de iniciar el desarrollo de los sistemas, siempre siguiendo el “Flujo de evaluación de las
actividades.
Se utilizarán las siguientes listas de control para supervisar y controlar el proyecto:
• Lista de Control de Salida de Fase.
• Lista de Control de Revisión de Calidad.
• Lista de Control de Aceptación de Entregables.
• Lista de Control de la Transición.
• Lista de Control de la Implementación en el Negocio.
• Lista de Control de Partes Interesadas.
13. ROLES Y RESPONSABILIDADES DEL PROYECTO

13.1. Matriz Consolidada de Asignación de Responsabilidades (RAM/RASCI)
Inicio OGP CDP PP RN GIN PS DP ECP

Solicitud de Inicio del Proyecto I n.a. A/S R S/C I n.a. n.a.
Caso de Negocio R C A A C S S n.a.
Acta de Constitución del Proyecto I A C S C S R C
Planificación OGP CDP PP RN GIN PS DP ECP
Reunión de Inicio de Planificación R A C S C C R C
Manual del Proyecto I I A S C I R C
Matriz de Partes Interesadas del Proyecto I I A S C I R C
Plan de Trabajo del Proyecto R A C S/C S C R S/C
Plan de Externalización A C C C I S R I
Plan de Aceptación de Entregables I A C S R C R n.a
Plan de Transición I A C C C C R C
Plan de Implementación en el Negocio R I A R C I S n.a
Planes de Gestión
Plan de Gestión de Requisitos I I A C C I R S
Plan de Gestión de Cambios I I A C I I R I
Plan de Gestión de Riesgos I C A C I I R I
Plan de Gestión de Incidencias I I A C C I R C
Plan de Gestión de Calidad I A C C C C R C
Plan de Gestión de las Comunicaciones I I A S C I R C
Ejecución OGP CDP PP RN GIN PS DP ECP
Reunión de Inicio de Ejecución I A C S/C C C R C
Coordinación del Proyecto I I A S I I R I
Control de Calidad I I I S C I A R
Fecha: 17/07/2023 25/ 89 Versión: 3.0

Informes del Proyecto I I A S/C I/C I/C R C

Distribución de la Información I I A C I I R C
Seguimiento y Control OGP CDP PP RN GIN PS DP ECP
Seguimiento del Progreso del Proyecto I I R C C I R C
Control del Cronograma I I A C C R R A
Control de los Costes I I A C C I R C
Gestión de las Partes Interesadas I I R S/C I C R I
Gestión de los Requisitos I I A C C R R S
Gestión de los Cambios del Proyecto I C A S I I R A
Gestión de los Riesgos I C A S/C C I R C
Gestión de las Incidencias y Decisiones I I R S C I R C
Gestión de la Calidad I I I S/C C R R C
Gestión de la Aceptación de Entregables I I A S C C R A
Gestión de la Implementación en el Negocio I I A R C I S I
Gestión de la Transición I A S C C C R C
Gestión de la Externalización A C C C I S R I
Cierre OGP CDP PP RN GIN PS DP ECP
Reunión de Revisión de Fin de Proyecto I A R S A C R A
Informe de Fin de Proyecto I A C S C C R C
Cierre Administrativo I C A C I C R I
OGP (Órgano de Gobernanza Pertinente) (Líder GIN (Grupo de Implementación en el Negocio)
de proyecto) (FRANCISCO) (JORGER, FERNANDO, DANIELA)
CDP (Comité de Dirección del Proyecto) (líder de PS (Proveedor de Soluciones) (JORGE)
proyecto) (FRANCISCO, DANIELA) DP (director de Proyecto) (FRANCISCO)
PP (Propietario del Proyecto) (FRANCISCO) ECP (Equipo Central del Proyecto) (FERNANDO,
RN (responsable de Negocio) (JORGE, HUGO) DANIELA, GORGE, HUGO)
Responsible (R), Accountable (A), Consulted

(C), Informed (I). Soporte (S-support)
13.2. Descripción de Roles y Responsabilidades del Proyecto

Reyna Revisa
Revisa
Revisa
Montesinos Revisa
documento final
Fecha: 17/07/2023 26/ 89 Versión: 3.0

Partes Interesadas
Descripción
NCripto
Responsabilidades
Reyna Revisa
Francisco Javier Nicolas Diseñador y programador Investigación, Análisis, 08/05/2023
Revisa
Revisa
Montesinos Revisa
Verónica Martínez Pérez Representante legal Aprobación de 08/05/2023
• documento final
Comité de Dirección del Proyecto (CDP)

Descripción
Los miembros permanentes del comité son: Luis Fernando Licona Reyna
Jorge Montero Cruz
Francisco Javier Nicolas Ortiz
Hugo Villalpando Montesinos
• El Propietario del Proyecto (PP), que preside el comité, es la persona clave en la toma de
decisiones y responsable del éxito del proyecto.
• Responsable de Negocio (RN) que es el delegado del Propietario del Proyecto (PP) y colabora
estrechamente con el director del Proyecto (DP).
• Proveedor de Soluciones (PS) que asume la responsabilidad general de los entregables del
proyecto.
• El director de Proyecto (DP), que es responsable del proyecto en su conjunto y de sus entregables.
Los miembros opcionales del comité son:
• Representantes de los Usuarios (RU) que representan los intereses de los usuarios del proyecto.
• Oficina de Soporte al Proyecto (OSP) que administra las reuniones del CDP y la documentación del
proyecto.
• Garantía de la Calidad del Proyecto (GCP), responsable del control de calidad y de la auditoría.
• El director del Proyecto del Contratista (DPC)
• El Coordinador de Protección de Datos (CPD) para consultar y asesorar sobre aspectos de
protección de datos.
Fecha: 17/07/2023 27/ 89 Versión: 3.0

Responsabilidades
• Abandera el proyecto y conciencia sobre el mismo en los niveles superiores.
• Guía y promueve a nivel estratégico la ejecución exitosa del proyecto, manteniendo el proyecto
centrado en sus objetivos.
• Garantiza el cumplimiento de las políticas y normas de la organización.
• Proporciona el seguimiento y control del proyecto a alto nivel.
• Al final de la Fase de Inicio, autoriza la continuación del proyecto, sobre la base del Caso de Negocio y
el Acta de Constitución del proyecto, a menos que lo haga el Órgano de Gobernanza Pertinente (OGP).
• Al final de la Fase de Planificación, autoriza al proyecto a continuar con la Fase de Ejecución,
basándose en el Manual del Proyecto y el Plan de Trabajo del Proyecto.
• Autoriza desviaciones y cambios de alcance de alto impacto en el proyecto y tiene la última palabra en
las decisiones.
• Se ocupa de las incidencias y conflictos que le son elevados.
• Impulsa y gestiona los cambios organizativos relacionados con los resultados del proyecto.
• Aprueba y autoriza los artefactos de gestión relativos a la calidad, la entrega y el cierre (Caso de
Negocio, Acta de Constitución del Proyecto, Plan de Trabajo del Proyecto, etc.).
13.2.1.1. Propietario del Proyecto (PP)

Descripción
Es la persona clave en la toma de decisiones del proyecto y responsable del éxito de este.
Responsabilidades
• Actúa como abanderado del proyecto, promoviendo el éxito del proyecto.
• Preside el Comité de Dirección del Proyecto (CDP).
• Ofrece liderazgo y dirección estratégica al responsable de Negocio (RN) y al director de Proyecto (DP).
• Establece los objetivos de negocio y acepta el Caso de Negocio del proyecto.
• Es el propietario de los riesgos de negocio y se asegura de que los resultados del proyecto estén
alineados con los objetivos y prioridades del negocio.
• Moviliza los recursos necesarios para el proyecto, de acuerdo con el presupuesto acordado.
• Supervisa regularmente el progreso del proyecto.
• Coordina la resolución de incidencias y conflictos que han sido elevados.
• Impulsa el cambio en la organización y supervisa su adecuada evolución e implementación.
• Aprueba y firma los artefactos clave vinculados con los hitos del proyecto (Manual del Proyecto, Plan
de Trabajo del Proyecto, Planes de Gestión del Proyecto, Plan de Implementación en Negocio, etc.).
Fecha: 17/07/2023 28/ 89 Versión: 3.0

13.2.1.2. Proveedor de Soluciones (PS)

Descripción
Asume la responsabilidad general de los entregables del proyecto.
Responsabilidades
• Representa los intereses de quienes diseñan, entregan, adquieren e implementan los productos del
proyecto.
• Puede ayudar al Propietario del Proyecto (PP) a definir el Caso de Negocio y el alcance, los
entregables, los hitos y el presupuesto requerido para el proyecto.
• Acuerda los objetivos de las actividades del proveedor y aprueba los entregables del contratista para
el proyecto (si procede).
• Asume la responsabilidad general de los productos y servicios del proyecto solicitados por el
Propietario del Proyecto (PP).
• Moviliza los recursos necesarios del lado del proveedor y nombra al director del Proyecto (DP).
13.2.1.3. Responsable de Negocio (RN)

Descripción
Representa al Propietario del Proyecto (PP) en el día a día del proyecto y colabora estrechamente con el
director del Proyecto (DP).
Responsabilidades
• Asiste al Propietario del Proyecto (PP) en la especificación del proyecto y los principales objetivos del
negocio.
• Establece y garantiza un canal eficiente de colaboración y comunicación con el director de Proyecto
(DP).
• Coordina el Grupo de Implementación en el Negocio (GIN) y actúa como enlace entre los
Representantes de Usuarios (RU) y la organización proveedora.
• Es responsable de la Solicitud de Inicio de Proyecto, Caso de Negocio y Plan de Implementación de
Negocio.
• Asegura que los productos entregados por el proyecto satisfacen las necesidades del usuario.
• Gestiona las actividades en la parte del negocio del proyecto y asegura que los recursos de la parte del
negocio que resulten necesarios estén disponibles.
• Decide la mejor manera de introducir los cambios en el negocio de la organización o las acciones de
reingeniería, cuando sea necesario.
• Asegura que la organización esté preparada para incorporar los entregables del proyecto cuando la
organización proveedora los ponga a disposición.
• Lidera la implementación de los cambios de negocio dentro de la organización a la que pertenecen
los usuarios.
• Coordina el cronograma y la realización de cualquier formación a los usuarios (y la producción de
material relacionado)
Fecha: 17/07/2023 29/ 89 Versión: 3.0

13.2.1.5. Director de Proyecto (DP)

Descripción
Gestiona el día a día del proyecto y es responsable de la entrega de productos de calidad en el marco de
las restricciones impuestas.
Responsabilidades
• Propone y ejecuta los planes del proyecto según lo aprobado por el Comité de Dirección del Proyecto
(CDP).
• Gestiona y coordina el día a día de las actividades del Equipo Central del Proyecto (ECP), haciendo un
uso óptimo de los recursos asignados.
• Asegura que el alcance del proyecto se realice dentro de los límites de calidad, tiempo y costo,
tomando medidas preventivas o correctivas cuando sea necesario.
• Gestiona las expectativas de las partes interesadas.
• Es responsable de crear todos los artefactos (excepto la Solicitud de Inicio del Proyecto, el Caso de
Negocio y el Plan de Implementación en el Negocio) y los propone para su aprobación al Propietario
del Proyecto (PP) o al Comité de Dirección del Proyecto (CDP.
• Asegura una evolución controlada de los productos bajo control de versiones, mediante la
implementación del Plan de Gestión de Cambios del Proyecto.
• Compara la evolución del presupuesto real del proyecto respecto a lo planificado e informa sobre el
progreso del proyecto al Comité de Dirección del Proyecto (CDP).
• Realiza la gestión de riesgos relacionados con el proyecto.
• Eleva los asuntos del proyecto que no puede resolver al Comité de Dirección del Proyecto (CDP)
• Sirve de enlace entre las capas de Dirección y de Ejecución del proyecto.
Grupo de Implementación en el Negocio (GIN)

Descripción
Está formado por representantes de la empresa y de los grupos de usuarios. El Grupo de Implementación
en el Negocio (GIN) es responsable de planificar e implantar los cambios organizacionales necesarios para
que la organización integre eficazmente los resultados del proyecto en su labor diaria.
Responsabilidades
• Bajo la coordinación del responsable de Negocio (RN), el Grupo de Implementación en el Negocio
(GIN) planifica e implementa las actividades necesarias para lograr los cambios organizacionales
deseados, tal y como se describe en el Caso de Negocio y en el Plan de Implementación en el
Negocio.
• Analiza el impacto de la implementación del proyecto en las operaciones y en los procesos de
negocio existentes, en las personas y en la cultura de la organización.
• Participa en el diseño o actualización de los procesos de negocio afectados.
• Prepara al área de negocio afectada para los cambios previstos.
• Asesora al responsable de Negocio (RN) sobre la preparación de la organización para el cambio.
• Incorpora los entregables del proyecto en las operaciones de la organización e implementa
actividades de cambio organizacional que caen dentro del alcance del proyecto.
Fecha: 17/07/2023 30/ 89 Versión: 3.0

13.2.1.7. Representantes de los Usuarios (RU)

Descripción
Representa los intereses de los usuarios finales en el proyecto. Los Representantes de los Usuarios
(RU) forman parte del Grupo de Implementación en el Negocio (GIN). Es importante involucrar a los
representantes de los usuarios a lo largo de todo el proyecto, ya que así adquieren visibilidad de las
actividades del proyecto, sentido de pertenencia y motivación, lo que garantiza que los resultados
sean adecuados para los fines de la organización.
Responsabilidades
• Ayudan a definir las necesidades y requerimientos del negocio.
• Aseguran que las especificaciones del proyecto y los entregables satisfagan las necesidades de
todos los usuarios.
• Aprueban en nombre de los usuarios la especificación del proyecto y los criterios de aceptación.
• Comunica y prioriza las opiniones de los usuarios en las decisiones del Comité de Dirección del
Proyecto (CDP) sobre la implementación o no de las recomendaciones sobre los cambios
propuestos.
• Participa en demostraciones y fases piloto según sea necesario.
• Realiza las pruebas de aceptación de los entregables.
• Firma los documentos relacionados con los usuarios (documentación, requisitos, etc.).
• Garantiza la estabilidad del negocio durante la transición hacia el nuevo estado operativo.
Equipo Central del Proyecto (ECP)
Descripción
Lo conforma el equipo responsable de funciones especializadas necesarias para la creación de los
entregables del proyecto. La composición y estructura del Equipo Central del Proyecto (ECP)
depende del tamaño y tipo de proyecto (p.ej., proyecto de TI, proyecto de desarrollo de políticas,
etc.) y es definido por el director del Proyecto (DP).
Responsabilidades
Bajo la coordinación del director del Proyecto (DP), el Equipo Central del Proyecto (ECP):
• Contribuye en la elaboración del alcance del proyecto y en la planificación de las actividades
del proyecto.
• Realiza las actividades del proyecto de acuerdo con el plan de trabajo y el cronograma del
proyecto.
• Produce los entregables del proyecto.
• Proporciona información al director de Proyecto (DP) sobre el progreso de las actividades.
• Participa en las reuniones del proyecto según sea necesario y contribuye a la resolución de
incidencias.
• Participa en la Reunión de Fin de Proyecto para generar y documentar lecciones útiles
aprendidas para la organización.
Fecha: 17/07/2023 31/ 89 Versión: 3.0

13.2.1.9. Director del Proyecto del Contratista (DPC)

Descripción
Dirige al personal del contratista que trabaja en el proyecto.
Responsabilidades
• Colabora estrechamente con el director de Proyecto (DP).
• Planifica, controla e informa sobre la producción de entregables.
• Asegura que todo el trabajo se realiza a tiempo y de acuerdo con los estándares y la calidad
acordados.
• Garantiza el éxito en la realización y entrega de las actividades subcontratadas.
13.2.1.10. Adjunto al director de Proyecto (ADP)

Descripción
En proyectos de gran envergadura, el director de Proyecto (DP) puede encontrar útil delegar una
parte de las tareas de gestión de proyectos a un adjunto. Este Adjunto del director de Proyecto
(ADP) trabaja en estrecha colaboración con el director de Proyecto (DP) en la realización del alcance
del proyecto y actúa como su apoyo. Aunque el director de Proyecto (DP) puede delegar ciertas
tareas al Adjunto al director de Proyecto (ADP), el DP sigue siendo responsable de la correcta
ejecución de estas tareas.
Responsabilidades
• Informa y recibe instrucciones del director de Proyecto (DP).
• Asiste en el desarrollo y ejecución de planes de proyecto y de equipo (o partes de ellos).
• Comunica los planes, decisiones e instrucciones al Equipo Central del Proyecto (ECP) o a
contratistas externos.
• Participa en la coordinación del Equipo Central del Proyecto (ECP) y del Equipo de Soporte a
Proyectos (ESP).
• Proporciona orientación a los participantes del proyecto en relación con la ejecución del trabajo.
• Ayuda en la organización de las reuniones del proyecto y en la elaboración de las actas.
• Reúne información de situación, datos reales y previsiones de todos los paquetes de trabajo y
pone en conocimiento del director de Proyecto (DP) cualquier discrepancia.
• Detecta proactivamente problemas de calidad o de plazos y propone acciones preventivas.
• Prepara o contribuye a los informes sobre la situación del proyecto de manera oportuna.
• Apoya el proceso de gestión de riesgos y cambios, actualiza los Registros de Riesgos y Cambios.
• Coordina la aceptación de los resultados con los usuarios internos y externos y las partes
interesadas.
• Establece las comunicaciones rutinarias del proyecto para informar a las partes interesadas del
proyecto.
13.2.1.11. Agregar funciones específicas en otros ámbitos (o eliminar esta sección)

Descripción
Ejemplos: Oficina de Arquitectura, Analista de Negocio, Personal de Soporte de Sistemas…
Responsabilidades
•
Fecha: 17/07/2023 32/ 89 Versión: 3.0

13.2.1.12. Coordinador de Equipo (CoE)

Descripción
Actúa como un facilitador y orientador del equipo y su propósito principal es crear y mantener las
condiciones (p.ej., recursos, resolución de incidencias) para permitir que el equipo se concentre en
lograr objetivos específicos y tener éxito.
Responsabilidades
• Garantiza la eficacia y la mejora continua del funcionamiento del Equipo Central del Proyecto (ECP).
• Facilita el entorno de trabajo colaborativo y cooperativo dentro del Equipo Central del Proyecto (ECP).
• Coordina las actividades de planificación y estimación, así como el informe de progreso del trabajo con
el director del Proyecto (DP).
• Asegura que el Equipo Central del Proyecto (ECP) pueda dedicarse plenamente a las actividades
relacionadas con la entrega y al logro de los objetivos específicos definidos.
• Facilita la toma de decisiones dentro del Equipo Central del Proyecto (ECP).
• Trabaja activamente para identificar y eliminar todos los obstáculos que impiden que el equipo logre
los objetivos de la iteración.
13.2.1.13. Propietario del Producto (PPr)

Descripción
Representa principalmente los intereses de los clientes y usuarios finales.
Responsabilidades
• Prioriza continuamente los requisitos que debe cumplir el Equipo Central del Proyecto (ECP) en
consonancia con los comentarios de la comunidad de partes interesadas y del ECP.
• Aclara las cuestiones relacionadas con el dominio que el Equipo Central del Proyecto (ECP) pueda
tener o asegura que un canal con las partes interesadas pertinentes esté abierto para la colaboración
y la aclaración.
• Facilita las sesiones de recopilación de requisitos y modelado.
• Asegura que la comunidad de las partes interesadas esté representada en ellos.
• Facilita la presentación de los resultados intermedios del proyecto a la comunidad de partes
interesadas (demos).
• Garantiza que las partes interesadas comprendan los beneficios que aporta el enfoque ágil seguido
por el Equipo Central del Proyecto (ECP)
Fecha: 17/07/2023 33/ 89 Versión: 3.0

13.2.1.15. Propietario de la Arquitectura (PA)

Descripción
Es el responsable de la arquitectura y de las decisiones al respecto ante el Equipo Central del
Proyecto (ECP).
Responsabilidades
• Guía la creación y evolución de la arquitectura del Sistema de Información (SI) en el que el
equipo está trabajando, en favor de un enfoque colaborativo y de equipo.
• Dirige el esfuerzo inicial de definición de la arquitectura al principio del proyecto y apoya el
esfuerzo inicial de previsión de requisitos (especialmente cuando se trata de comprender y
evolucionar los requisitos no funcionales para el SI), centrándose en el ciclo de vida del proyecto
y también en la evolución y la capacidad de mantenimiento del SI.
• Asegura la alineación de la arquitectura del Sistema de Información (SI) con las directrices y
recomendaciones de la Oficina de Arquitectura (OA) y el apoyo a los principios establecidos a
nivel de arquitectura empresarial.
• Aprovecha las inversiones en Tecnologías de la Información (TI) existentes o previstas en la
organización mediante la promoción continua de una cultura de reutilización e interoperabilidad
dentro del Equipo Central del Proyecto (ECP).
• Contribuye al conjunto de activos de TI reutilizables de la organización considerando el dominio
general al que dará soporte el Sistema de información (SI) y la estrategia de TI de la
organización.
• Informa al Coordinador de Equipo (CoE) y al director de Proyecto (DP) de los principales riesgos
relacionados con la arquitectura del sistema y contribuye a definir la estrategia adecuada de
gestión de riesgos.
13.2.1.16. Miembros del Equipo Ágil (MEA)

Descripción
Se centran en la producción del Sistema de Información específico que es parte de la solución del
proyecto a las necesidades de las partes interesadas.
Responsabilidades
• Participa en la planificación y estimación de iteraciones, versiones.
• Participa en el diseño de la arquitectura de la solución.
• Desarrolla parte del sistema de información, colaborando en el diseño de la arquitectura de la
solución.
• Prueba los desarrollos.
• Proporciona información sobre el progreso al Coordinador del Equipo (CoE).
• Se comunica y colabora con el resto del Equipo Central del Proyecto (ECP).
Fecha: 17/07/2023 34/ 89 Versión: 3.0

Equipo de Soporte a Proyectos (ESP)
Descripción
Son los responsables de dar apoyo al proyecto. La composición y estructura del Equipo de Soporte a Proyectos
(ESP) depende del tamaño del proyecto y es definido por el director de Proyecto (DP). El papel del Equipo de
Soporte a Proyectos (ESP) puede ser asumido por los miembros del equipo, un equipo específico o ser prestado
por la organización como servicios horizontales.
Responsabilidades
• Proporciona apoyo administrativo al proyecto.
• Define los requisitos para la presentación de informes y comunicaciones.
• Administra las reuniones del Comité de Dirección del Proyecto (CDP) y emite informes.
• Apoya al director de Proyecto (DP) en la planificación, seguimiento y control del proyecto.
• Asesora sobre herramientas de gestión de proyectos y servicios administrativos.
• Gestiona la documentación del proyecto (versionado, archivo, etc.).
Algunos ejemplos de los roles que forman parte del Equipo de Soporte a Proyectos (ESP) son: Oficina de Soporte
a Proyectos (OSP), Garantía de Calidad del Proyecto (GCP), Oficina de Arquitectura (OA).
13.2.1.17. Oficina de Soporte a Proyectos (OSP)

Descripción
Proporciona apoyo al director de Proyecto (DP) y al Equipo Central del Proyecto (ECP).
Responsabilidades
• Asesora sobre herramientas de gestión de proyectos, orientación y servicios administrativos.
• Administra las reuniones del Comité de Dirección del Proyecto (CDP).
• Elabora informes para el Comité de Dirección del Proyecto (CDP).
• Gestiona la comunicación interna.
• Establece estándares, herramientas, procedimientos y métodos para su uso en el proyecto.
• Administra aspectos de la gestión de proyectos como el control de cambios en los documentos, la línea
base de los planes, etc.
• Puede desempeñar el papel de custodio y guardián de todas las copias maestras de los productos del
proyecto.
13.2.1.18. Garantía de Calidad del Proyecto (GCP)

Descripción
Asegura la calidad del proyecto y sus entregables, independientemente del director de Proyecto (DP).
Responsabilidades
• Asegura la adhesión a las políticas, directrices y procesos de gestión de proyectos predefinidos de la
organización.
• Establece estándares de garantía de calidad.
• Apoya al director de Proyecto (DP) en la planificación, seguimiento y control de la calidad del proyecto.
• Revisa los procesos de gestión de proyectos y artefactos (p.ej., el Acta de Constitución y los Planes de
Gestión de Proyectos) como parte de la garantía de calidad.
• Identifica las no conformidades u oportunidades de mejora y recomienda acciones al Comité de Dirección
del Proyecto (CDP) para que tome una decisión.
• Reporta al Comité de Dirección del Proyecto (CDP)
Fecha: 17/07/2023 35/ 89 Versión: 3.0

14. APÉNDICE 1: REFERENCIAS Y DOCUMENTOS RELACIONADOS
ID Referencia o Documento Relacionado Fuente o Enlace/Ubicación

1 Carpeta del Proyecto https://drive.google.com/drive/folders/1QN8dZdMb
_bJ7L4sefecL3jQf9aLg2t6o
2
3
15. LISTA DE CONTROL DE PARTES INTERESADAS

12.1 Resumen General
Fecha: 17/07/2023 36/ 89 Versión: 3.0

12.2 Inicio
Fecha: 17/07/2023 37/ 89 Versión: 3.0

12.3 Planificación
12.4 Ejecución
12.5 Cierre
12.5 Seguimiento
Fecha: 17/07/2023 38/ 89 Versión: 3.0

16. PLAN DE TRABAJO DEL PROYECTO
13.1 Introducción
El Plan de Trabajo del Proyecto documenta todas las actividades del proyecto necesarias para alcanzar los objetivos
del proyecto, junto con sus estimaciones detalladas de esfuerzo/coste, su calendario y la duración del proyecto
resultante, así como las necesidades de recursos. El Plan de Trabajo del Proyecto será utilizado como base para
supervisar el progreso y controlar el proyecto.
El Plan de Trabajo del Proyecto incluye el esfuerzo/coste estimado y el cronograma de TODAS las actividades del
proyecto, incluyendo las identificadas y descritas en otros planes del proyecto (p.ej., el Plan de Transición, el Plan
de Implementación del Negocio), así como las actividades de gestión del proyecto relacionadas con la Gestión de
Riesgos, la Gestión de la Calidad (p.ej., la evaluación o auditorías programadas del proyecto) y la Aceptación de
Entregables.
Tenga en cuenta que este documento siempre contendrá el último plan de referencia. En el Apéndice 1: Referencias
y documentos relacionados, se encuentran referencias a versiones anteriores de este documento (con el fin de
identificar los cambios) junto con los informes de situación pertinentes.
13.1.2 Resumen del Proyecto

La inyección SQL, o SQLi, es un tipo de ataque a una aplicación web que permite a un atacante insertar sentencias
SQL maliciosas en la aplicación web, obteniendo potencialmente acceso a datos sensibles en la base de datos o
destruyendo estos datos.
La Universidad Tecnológica de Nezahualcóyotl requiere salvaguardar su información SQL ante este tipo de ataque
por tal estos requisitos están dirigida a la entrada del usuario que se realiza a través de un formulario de acceso. Se
consulta la base de datos SQL con los campos enviados por el usuario para autentificarlos. La estructura es de la
consulta a su base de datos, que solo abarcará las áreas de servicios escolares.
13.1.3 Desglose del Trabajo

Esta sección presenta el desglose del proyecto en componentes más pequeños y manejables tales como
entregables, paquetes de trabajo, actividades y tareas. Cada nivel inferior de la representación ofrece un nivel más
fino de detalle de los entregables y del trabajo que, en conjunto, definen los productos del proyecto y el trabajo
necesario para producirlos.
La UTN podrá solicitar a NCripto la evaluación de cualquier tipo de desarrollo de sistema, a fin de que tenga la
posibilidad de entrevistarse con las áreas usuarias (esto se da en acompañamiento con un representante de la
Dirección de Informática -Líder de la UTN-), e identificar y determinar los requerimientos y presentar el avance del
proyecto para el desarrollo, implementación y las funcionalidades solicitadas (esta actividad no deberá tener costo
para la UTN).
Cada una de las iniciativas de desarrollo del sistema se considerará, por lo que se deberá ejecutar de forma
simultánea sin que se afecte el tiempo de realización entre ellos. El número de desarrollos de sistemas totales
durante la vigencia del contrato no se establece, debido a que esto dependerá de los requerimientos formulados
por las unidades administrativas de la UTN. Esto quiere decir que será responsabilidad de NCripto, asignar el
personal adecuado en calidad y cantidad para cumplir con los planes de trabajo que correspondan a cada orden de
trabajo de desarrollo de sistemas que sea formalizada.
Cada componente del desglose del trabajo es de un tipo determinado Entregable.
Fecha: 17/07/2023 39/ 89 Versión: 3.0

13.1.4 Estructura de desglose del trabajo
Los entregables se determinan de acuerdo con el servicio proporcionado y como se describe en el Anexo X “Control
de Entregables”, serán definidos para cada tipo de actividad al inicio y fin del proyecto. Se determina, además, la
formalidad que debe darse a cada uno de ellos.
Toda la información asociada a los proyectos y servicios otorgados por NCripto, como son código fuente generado
y/o modificado, documentos generales de y para el proyecto, así como todos los entregables establecidos, serán
considerados como propiedad exclusiva de la UTN sin excepción alguna, desde el formato hasta el contenido. Para
el caso del servicio de asignación fija, la documentación a entregar será el artefacto (Reporte de Actividades) y
aquella que sea definida específicamente para cada asignación de común acuerdo entre el Coordinador de
Proyectos de la UTN y el Gerente de Proyectos de NCripto. Los trabajos de documentación y el tiempo que tome el
personal para elaborar la documentación también serán contabilizados en las horas mensuales de servicio.
Project Management de NCripto implementará el seguimiento de los proyectos, para lo cual deberá documentar.
El Project Management del NCripto presentará un reporte semanal al Coordinador de Proyectos de la UTN con el
avance de cada uno de los proyectos en donde deberá incluir sección de riesgos y plan para mitigarlos, resolverlos
y aceptarlos, según sea el caso. La UTN cuenta con un formato ejecutivo, para mostrar el estatus del Proyecto,
donde se plasman, los avances de actividades relevantes de la semana, riesgos identificados, próximas actividades,
entre otros. Dicho formato de reporte será presentado únicamente al NCripto Adjudicado; sin embargo, el formato
del reporte es perfectible, por lo tanto, el NCripto podrá hacer sugerencias para mejorarlo o bien presentar alguno
que cubra lo mencionado anteriormente, quedando la decisión final a cargo del Coordinador de Proyectos de la
UTN sobre el formato que se utilizará durante la vigencia del contrato.
NCripto deberá contar con un sistema/herramienta de Administración de Proyectos que permita, en forma
automatizada, al menos lo siguiente:
• Generar un reporte de avance de actividades.
• Monitoreo de los niveles de servicio (relacionados al proyecto).
• Alta y seguimiento de garantías (relacionado al proyecto).
NCripto deberá proporcionar al Coordinador de Proyectos de la UTN, durante la vigencia del contrato, acceso a su
sistema/herramienta para dar seguimiento a:
a) Plan de trabajo de cada uno de los proyectos y el avance de estos.
b) Entregables para cada avance, fechas compromiso, responsables y esfuerzo estimado en horas.
c) Principales riesgos e issues.
d) Tareas de ruta crítica.
e) Líneas base de cada proyecto.
f) Monitoreo de indicadores de productividad de desempeño.
Fecha: 17/07/2023 40/ 89 Versión: 3.0

13.2 Plantilla para el desglose del trabajo.
1 Inyección de SQL.
1.1 Documentación de la Administración de los Proyectos.
1.1.1 Reporte Semanal.
1.1.2 Reporte de actividad que hayan sido cerrados en el mes.
1.1.3 Evidencia documental de los trabajos realizados.
1.2 Control de versiones.
1.2.1 Validación de Software.
1.3 Diagramación de los procesos.
1.3.1 Realizar diagramas de procesos.
1.4 Arquitectura de los sistemas.
1.4.1 Respaldo y manejo de información.
1.5 Implementación del proyecto.
1.5.1 Inicio de actividades.
1.5.2 Confidencialidad de la información.
1.5.3 Ejecución del proyecto.
1.5.4 Entrega del proyecto.
1.6 Garantía del proyecto.
1.6.1 Protocolo de pruebas de validación.
1.6.2 Entrega de garantía válida.
1.7 Capacitación.
1.7.1 Capacitación del personal de NCripto en los sistemas actuales de la UTN.
13.2.1 Plantilla para la descripción de los componentes del desglose del trabajo.
1 Inyección de SQL.
1.1 Documentación de la Administración de los Proyectos.
1.1.1 Reporte Semanal.
Fecha: 17/07/2023 41/ 89 Versión: 3.0

Al final de cada mes calendario, el Gerente de Proyectos del NCripto deberá entregar
al Coordinador de Proyectos de la UTN, los reportes impresos del avance de proyectos
en proceso o bien que se hayan cerrado durante el mes. El reporte se hará con base en
el plan de trabajo autorizado donde se muestre el avance de cada actividad y el avance
total del proyecto. Se deberá incluir un resumen de las actividades realizadas en el mes
y de las próximas a ejecutarse.
La documentación deberá incluir las minutas de todas las reuniones con la firma
1.1.1.1
autógrafa de todos los involucrados.
1.1.2 Reporte de actividad que hayan sido cerrados en el mes.
Para el caso de las actividades que hayan sido cerrados en el mes, el Gerente de
Proyectos del NCripto deberá elaborar una carpeta con toda la documentación
1.1.1.2
impresa que corresponda al tipo de avance que se trate (mantenimiento o desarrollo),
de acuerdo con el servicio proporcionado.
1.1.3 Evidencia documental de los trabajos realizados.
Esta documentación será la evidencia documental de los trabajos realizados por

NCripto, y será útil para revisar la contabilidad de Horas/Hombre ejecutadas en todos
1.1.1.3
los avances como base de cálculo de pago de servicios a NCripto y en su caso, aplicar
las penalizaciones correspondientes.
1.2 Control de versiones.
1.2.1 Validación de Software.
Esta documentación será la evidencia documental de los trabajos realizados por

NCripto, y será útil para revisar la contabilidad de Horas/Hombre ejecutadas en todos
1.2.1.1
los avances como base de cálculo de pago de servicios a NCripto y en su caso, aplicar
las penalizaciones correspondientes.
1.3 Diagramación de los procesos.
1.3.1 Realizar diagramas de procesos.
Para la diagramación de los procesos, la UTN establece la utilización de software

(herramienta de diagramación de procesos open source). Será obligación del NCripto
1.3.1.1 hacer uso de dicho software para todos los mantenimientos o desarrollos que realice
durante la vigencia del contrato. El software se mantendrá en equipos con
licenciamiento.
Fecha: 17/07/2023 42/ 89 Versión: 3.0

1.4 Arquitectura de los sistemas.
1.4.1 Respaldo y manejo de información
NCripto deberá estimar que la transferencia de datos se realice sobre canales seguros
en donde se favorezca el cifrado y la integridad de los datos críticos, confidenciales
sensibles, en concordancia con lo establecido en el MAAGTICSI en lo referente a
seguridad de la información. Asimismo, deberá considerar que los aplicativos de
1.4.1.1 cómputo deben ser construidos de forma modular, basados en una Arquitectura
Orientada a Servicios (SOA), con el propósito de generar aplicaciones reutilizables e
interoperables entre las diversas áreas de la UTN. El desarrollo de aplicativos de
cómputo deberá contar, por lo menos, con un modelo de tres capas: de datos, del
negocio y de presentación.
1.5 Implementación del proyecto.

1.5.1 Inicio de actividades.
A partir del primer día de vigencia del contrato firmado entre la UTN y NCripto
Adjudicado, este último debe presentarse en las instalaciones de la UTN, con el
siguiente Personal:
• Gerente de Proyecto.
• Líder de Proyecto.
• Auxiliar de líder de Proyecto.
Así mismo el Gerente de Proyectos de NCripto adjudicado deberá de establecer una

reunión de kick-off con el Coordinador de proyectos de UTN, para el inicio de
1.5.1.1 actividades donde se especifiquen los siguientes puntos:
• Condiciones generales del proyecto.
• Estructura Organizacional y Plan de Comunicación.
• Políticas de Trabajo.
• Metodología de Trabajo.
• Entregas y Vo.Bo.
• Equipos y usuarios.
• Mecanismos de Control de Cambios.
• Estándares aplicables a los proyectos.
1.5.1 Confidencialidad de la información.
Fecha: 17/07/2023 43/ 89 Versión: 3.0

NCripto se debe comprometer a que mantendrá absoluta confidencialidad de la
información a la cual tenga acceso desde la recepción de este Anexo Técnico, siendo
responsable de que cada uno de los integrantes del personal asignado para la
prestación de los servicios derivados del contrato que se celebre, respetará el manejo
correcto de la información.
Toda la información a la que tenga acceso el personal contratado por el NCripto

adjudicado, es considerada de carácter confidencial, por lo que el NCripto deberá
garantizar que por ningún motivo se viole en ninguno de los casos:
1.5.1.1
I. Ser copiada o respaldada en ninguno de los equipos del personal del NCripto.
II. Por ningún motivo salir de las instalaciones de la UTN en ningún medio físico o
electrónico e incluso impreso.
De no cumplir con esta premisa, se considerará como una falta al acuerdo de

confidencialidad que aceptó el NCripto. Cualquier requerimiento relacionado a los
anteriores puntos tiene que ser consensuado y autorizado por el director de
Informática de la UTN.
1.5.1 Ejecución del proyecto.
Ejecución del 100% de las actividades del plan de trabajo autorizado sin exceder la
1.5.1.1 fecha límite. Ninguna actividad según plan de trabajo establecido puede exceder el 5%
de retraso en tiempo en la finalización del 100% de las actividades.
1.5.1 Entrega del proyecto.
El NCripto se obliga a colaborar en la entrega de los servicios al final del contrato,

haciendo los compromisos siguientes:
I. Entregar un reporte del estado que guarda el servicio que ofreció a la UTN. Este
reporte deberá ser entregado al menos 30 días antes de la finalización del contrato o
en la fecha que resulte de la negociación que realice la UTN con NCripto de acuerdo
1.5.1.1 con las condiciones existentes al final de contrato.
II. Participar en las reuniones que le solicite la UTN con NCripto al final del contrato. En
caso de rescisión del contrato, el NCripto se obliga a cumplir además de lo especificado
en el párrafo anterior de este Anexo Técnico, a mantener la totalidad del personal
hasta que la UTN contrate a un nuevo NCripto para proporcionar el mismo servicio y
se efectúe la transición correspondiente.
Fecha: 17/07/2023 44/ 89 Versión: 3.0

1.6 Garantía del proyecto.
1.6.1 Protocolo de pruebas de validación
A NCripto se le dará pleno acceso al ambiente de Desarrollo para que realice la

implementación del código y se ejecute el protocolo de pruebas necesarias antes y
después de la entrega al líder de proyecto de la UTN, quien se encargará de instalar el
aplicativo en el ambiente de calidad (QA) para pruebas y en su caso, liberación y
1.6.1.1
entrega al ambiente de Producción. La administración de los 3 ambientes será
responsabilidad de la UTN (soporte al hardware, administración del sistema operativo,
ejecución de respaldos, proporcionar e instalar licencias de software, el
mantenimiento de estas, entre otras tareas de infraestructura).
1.6.2 Entrega de garantía válida.
Todas las actividades, sean de mantenimiento o de desarrollo, deberán contar con una
garantía válida por NCripto durante la vigencia del contrato, y una vez finalizado éste,
los proyectos tendrán una garantía de hasta 12 meses posteriores. En caso de
detectarse alguna falla (defectos) o falta en los trabajos del proyecto, se solicitará la
aplicación de la garantía. Dichas actividades no serán contabilizadas como trabajos
1.6.2.1 Hora/Hombre que la UTN deba cubrir. Las mencionadas actividades de garantía serán
por cuenta del NCripto. La garantía aplica siempre y cuando el código entregado no
haya sido modificado o alterado en una fecha posterior al término de la solicitud.
Al término del contrato, se establecerá un proceso de atención de garantías que servirá
como base para la resolución de cualquier falla o defecto detectado una vez que se
haya terminado la participación del NCripto.
1.7 Capacitación.
1.7.1 Capacitación del personal de NCripto en los sistemas actuales de la UTN.
Durante los primeros 30 días naturales anteriores al término del proyecto, NCripto
llevará a cabo sesiones de Inducción para el personal de la UTN adjudicado podrá
asignar al personal que crea conveniente (se sugiere sean los líderes). Dichas sesiones
1.7.1.1 de Inducción tratarán sobre los sistemas que tiene la UTN en producción y
actualización, con la intención de que se familiaricen con las tecnologías, las reglas de
negocio, las áreas usuarias que los utilizan y demás temas relacionados para llevar a
cabo los proyectos de mantenimiento.
Fecha: 17/07/2023 45/ 89 Versión: 3.0

Fecha: 17/07/2023 46/ 89 Versión: 3.0
13.3Estimación de Recursos y Costes
Esta sección documenta la justificación y el coste final de todas las actividades del proyecto. El desglose del trabajo
de la Sección 2 es el insumo para la estimación.
Las Horas/Hombre que se destinen para mantenimiento y desarrollos, tendrán el mismo manejo y valor, es decir,
no habrá distinción en el tipo de servicio en el que se utilicen las Horas/Hombre, todas con previa autorización de
parte de la UTN dependiendo de la actividad de que se trate.
Si durante el transcurso del contrato, se presenta la necesidad de desarrollar algún sistema cuya tecnología no se
haya listado o comentado en este documento, NCripto deberá conseguir, bajo el esquema de mejor esfuerzo, el
personal para llevar a cabo el desarrollo del sistema solicitado, sin que esto represente un cambio en el precio por
Hora/Hombre que se oferto.
El personal que se considera fijo para la UTN será el Gerente de Proyectos líder de proyecto y el Auxiliar del líder
del proyecto de NCripto, durante la vigencia del contrato y sin importar el tipo de tecnología de que se trate.
El NCripto deberá proporcionar su servicio para cubrir los requerimientos de la UTN, con el precio establecido por
Hora/Hombre antes de IVA en Moneda Nacional para la atención de Mantenimiento de los sistemas existentes y
Desarrollo de sistemas que aplicará para todos los proyectos y durante la vigencia del contrato, el cual deberá ser
fijo y no podrá variar, incluso en caso de extensiones del presente contrato, de acuerdo a lo que establece la Ley
de Adquisiciones, Arrendamientos y Servicios del Sector Público (LAASSP) vigente. Tanto el Gerente de Proyectos
como el Auxiliar de NCripto, no tendrán un costo adicional para la UTN y deberán de ser considerados en el precio
del trabajo por Hora/Hombre que se oferte.
Dentro de todos los planes de trabajo que se revisen y en su caso, autoricen por parte de la UTN, se podrán
contabilizar las actividades del personal del NCripto: Líderes de Proyecto, Programadores, Arquitecto de software
y Diseñador Gráfico como Horas/Hombre para efectos de Facturación a pagar por UTN; cualquiera otra actividad
no será contabilizada como trabajo Hora/Hombre. Las actividades del Gerente de Proyectos y el Auxiliar del
Gerente, no serán contabilizadas como Horas/Hombre para efectos de facturación.
Para el caso del servicio de asignación de personal fijo, de NCripto es deberán utilizar el precio fijo por hora. Este
precio será bajo el siguiente esquema según el tipo de personal del que se trate:
13.4Recursos Necesarios
• Personas
• Software
• Hardware
• Equipos
• Edificios e instalaciones
• Suministros
• Materiales
• Otro...>
Fecha: 17/07/2023 47/ 89 Versión: 3.0

Los recursos que se requiere para este rubro se consideran solventar con conformidad a lo establecido en los criterios
de evaluación en el ACUERDO por el que se emiten diversos lineamientos en materia de adquisiciones,
arrendamientos y servicios relacionados paya el éxito del proyecto.
Recursos humanos:
Project Manager
Líder de proyecto
Auxiliar de proyecto
Programadores (Al menos 2 candidatos)
13.4.1Plan de Recursos
Recursos Humanos
ID del Fecha Fecha Nivel de la
Recurso Habilidad Cantidad
Recurso Inicial Final Habilidad
H.1 10/01/17 20/08/17 Consultor Seguridad Avanzada 2
H.2 10/05/17 20/09/17 Asesor Legal Legislación Intermedia 1
H.3 10/05/17 20/06/17 Formador PM2 Experimentado 2
Otros Recursos
ID del Fecha Fecha
Recurso Características Cantidad
Recurso Inicial Final
M.1 10/01/17 20/08/17 Licencia Dedicada 100
M.2 02/05/17 22/09/17 Ordenador Office 2010 3
M.3 02/05/17 22/09/17 Sala de 30 asientos 1
Formación
Todos los Recursos

ID del
Recurso Coste Unitario Nº Unidades Coste Total
Recurso
H.1 Consultor 500€ por día-persona 40 días-persona 20.000
H.2 Asesor legal 400€ por día-persona 20 días-persona 8.000
M.1 Licencias 800€ por usuario 100 usuarios 80.000
H.3 Formador 500€ por día-persona 10 días-persona 5.000
Fecha: 17/07/2023 48/ 89 Versión: 3.0

13.4.2Disponibilidad de Recursos
ID Recurso Recurso No disponible desde No disponible hasta Razón

H.1 Consultor 01/07/17 01/08/17 vacaciones
H.2 Asesor legal 15/07/17 25/07/17 formación
M.3 Sala de formación 1/07/17 15/07/17 reformas
ID
Recurso Disponibilidad Comentarios
Recurso
H.1 Consultor 100% Dedicación a tiempo completo.
H.2 Asesor legal 50% Trabaja también en el proyecto xyz.
Contingencias
ID Recurso Recurso Contingencia Comentarios
H.1 Consultor 5 días-persona Contabilizar los riesgos de ejecución.
H.2 Asesor legal 5 días-persona En caso de que haya retrasos en la recepción de una
respuesta del organismo xyz.
M.1 Licencia 10 unidades Para garantizar que nunca se acaben las licencias
para las pruebas.
17. PLAN DE EXTERNALIZACION
14.1ACTA DE CONSTITUCION DEL PROYECTO
14.1.1Introducción
Introducción a inyección SQL, se proporciona una visión general de la especificación de recursos sobre el ataque de
inyección booleana. Con el fin de conocer las principales funciones que éste realiza, los datos asociados, factores,
restricciones, supuestos y dependencias que afectan al desarrollo, así como también la manera de mitigar dicho
ataque
14.2 Requisitos de Formación y Manuales

Manuales: Usuario y Administrador del sistema
14.2.1 Derechos de Propiedad

Los entregables de la planificación del proyecto serán propiedad de NCripto entregables que podrán ser utilizados
por el equipo de planificación del proyecto dentro del marco anteriormente referido, con la autorización pertinente
para la utilización de su información por parte de NCripto
Fecha: 17/07/2023 49/ 89 Versión: 3.0

14.2.2. Requisitos de Compatibilidad
NCripto deberá Proveer los recursos necesarios para la entrega de resultados de la planificación del proyecto el
equipamiento necesario.
14.2.3. Otros Requisitos

Acceso a las copias de seguridad: Es importante establecer claramente quién será responsable de mantener y
acceder a las copias de seguridad de los datos.
Actualizaciones de programas informáticos: Para protegerse contra las vulnerabilidades conocidas y las
correcciones de seguridad, es necesario definir la responsabilidad de mantener actualizados los programas
informáticos utilizados en la aplicación.
Acceso a aplicaciones: El contrato debe abordar el acceso a las aplicaciones relacionadas con el proyecto y establecer
las responsabilidades del proveedor del software y del cliente en cuanto a la protección de estas contra la inyección
SQL.
Acceso a copias de seguridad de datos: Además del acceso a las copias de seguridad, también es importante definir
quién tiene acceso a los datos almacenados en las copias de seguridad. Esto puede incluir restricciones de acceso y
la implementación de medidas de seguridad adecuadas para proteger la confidencialidad e integridad de los datos
almacenados.
Estos puntos deben ser discutidos y negociados al firmar el contrato, y es recomendable contar con la asesoría de
expertos en seguridad informática y asuntos legales para garantizar que se aborden adecuadamente en los términos
del contrato.
14.3Método de Contratación
14.3.1Método
Se han identificado las siguientes actividades para que el proceso de contratación sea desarrollado de manera
eficiente
Revisar la metodología de evaluación, así como los procedimientos de prueba para asegurar que cada fase de
prueba es correctamente preparada
Ayudar a asegurar que cada requisito se implementa de forma correcta
Colaborar en la preparación de actividades de pruebas del sistema para asegurar que se adecuan a los planes y
procedimientos de prueba.
14.3.2. Programación de la Entrega

Cada entregable estará detallado dentro de la planificación del proyecto deberá ser revisado por uno de los
miembros del equipo de calidad, para verificar su conformidad con los estándares definidos.
Fecha: 17/07/2023 50/ 89 Versión: 3.0

14.3.3. Gestión de la Calidad y Soporte Post Entrega
En este plan de aseguramiento de calidad, se definen los procedimientos y reglas fundamentales para asegurar una
correcta colaboración, y se aplicará a todos los procedimientos y entregables del proyecto. Los principales objetivos
del aseguramiento de calidad para el proyecto son los siguientes:
Descubrir desviaciones del plan en cuanto se originan y facilitar la gestión de forma que se puedan tomar acciones
correctoras, si es necesario, tan pronto como sea posible
Mejorar la calidad del producto entregado monitoreando apropiadamente tanto los productos de la inyección sql
como el proceso de desarrollo que los procesos.
Asegurar el cumplimiento de los estándares y procedimientos establecidos para el proyecto de inyección sql y el
proceso de software establecidos. Hay que asegurar que cualquier desviación en el producto, el proceso, o los
estándares o elevados a la gerencia para poder resolverlas
14.4Criterios de Evaluación
14.4.1Criterios
Las evaluaciones que se realizara, a los procedimientos que deben seguirse para la confección de los entregables y
los procedimientos para comunicar a los responsables de los defectos detectados en los entregables y del
seguimiento que se debe ser realizado para lograr la corrección de estos. Las actividades definidas corresponden a:
- Revisión de Entregables.
- Revisión al ajuste del Proyecto.
- Revisión Técnica.
- Documentación crítica
14.4.2Capacidades Técnicas
1.Capacidad de implementar medidas de seguridad: Los contratistas deben tener experiencia y conocimientos en
la implementación de medidas de seguridad efectivas para prevenir la inyección SQL. Esto implica la capacidad de
desarrollar aplicaciones con filtrado y validación de datos, uso de consultas parametrizadas o sentencias
preparadas, y adopción de buenas prácticas de codificación segura.
2.Conocimiento de las mejores prácticas de seguridad: Es importante que los contratistas estén familiarizados con
las mejores prácticas de seguridad relacionadas con la inyección SQL. Esto incluye la comprensión de las técnicas
de ataque y las contramedidas correspondientes, así como la capacidad de mantenerse actualizados sobre las
últimas tendencias y amenazas en materia de seguridad.
3.Experiencia en pruebas de seguridad: Los contratistas deben tener habilidades y experiencia en la realización de
pruebas de seguridad, incluidas pruebas de penetración y pruebas de inyección SQL. Esto les permitirá identificar
posibles vulnerabilidades y debilidades en el sistema y tomar medidas para corregirlas antes de la implementación.
Fecha: 17/07/2023 51/ 89 Versión: 3.0

En cuanto a las necesidades de escalabilidad del sistema, es importante considerar el crecimiento esperado en
términos de usuarios y volúmenes de datos. Algunos aspectos a tener en cuenta son:
1.Escalabilidad en el manejo de usuarios: El sistema debe tener la capacidad de manejar un número creciente de
usuarios concurrentes. Esto implica evaluar la capacidad de carga, la optimización del rendimiento y la escalabilidad
horizontal o vertical del sistema.
2.Escalabilidad en el manejo de datos: El sistema debe estar preparado para manejar un volumen creciente de datos
a lo largo del tiempo. Esto implica evaluar la capacidad de almacenamiento, la eficiencia de las consultas y el diseño
de la base de datos para garantizar un rendimiento óptimo incluso con grandes volúmenes de datos.
14.5.1Interfaz del Contratista
Todas las reuniones o tratos que se realizarán durante la elaboración del proyecto estarán a cargo del proyecto
mánager de NCripto.
14.5.2Responsabilidad de la Firma
El equipo NCripto de con el proyecto de inyección SQL confirma que toda aprobación revisión y alteración del
contrato queda a cargo del proyecto manager para que sea formalmente responsable del cumplimiento del mismo
por ambas partes.
15.PLAN DE GESTION DE REQUISITOS

15.1. Introducción
• Describir el proceso de gestión de requisitos que se implementará para abordar y mitigar los riesgos asociados
con la inyección SQL.
• Definir los roles y responsabilidades clave relacionados con la gestión de requisitos en este contexto.
• Especificar la metodología, los estándares, las herramientas y las técnicas utilizadas para respaldar la gestión de
requisitos y prevenir la inyección SQL.
• Presentar las plantillas y los recursos relevantes que se utilizarán para documentar y monitorear los requisitos
relacionados con la seguridad de la inyección SQL.
La inyección SQL es una vulnerabilidad crítica en los sistemas de software que puede permitir a los atacantes
manipular y comprometer bases de datos, acceder a información sensible y ejecutar acciones no autorizadas. Para
proteger los sistemas y los datos contra este tipo de ataques, es esencial implementar una gestión efectiva de
requisitos que aborde específicamente este problema de seguridad.
15.2Objetivos de la Gestión de Requisitos

Identificar y comprender los requisitos de seguridad: El objetivo principal es identificar y comprender los requisitos
de seguridad relacionados con la prevención de la inyección SQL.
Definir medidas de protección: Se deben establecer medidas de protección efectivas para prevenir la inyección SQL.
Esto puede incluir la implementación de mecanismos de validación y filtrado de entrada de datos, la adopción de
prácticas de codificación segura, el uso de consultas parametrizadas o el empleo de marcos de desarrollo que
ofrezcan protección automática contra la inyección SQL.
Fecha: 17/07/2023 52/ 89 Versión: 3.0

Establecer controles de acceso y privilegios: Es fundamental definir los controles de acceso y los privilegios de
usuario adecuados para limitar el acceso no autorizado a la base de datos.
Mantener la capacitación y concientización: La gestión de requisitos también implica capacitar al personal sobre las
mejores prácticas de seguridad y concientizar sobre los riesgos asociados con la inyección SQL. Esto ayudará a
garantizar que todos los miembros del equipo sean conscientes de las prácticas de seguridad adecuadas y estén
preparados para mitigar los riesgos asociados con este tipo de vulnerabilidad.
18. 2.1Proceso de Gestión de Requisitos

El proceso de gestión de los requisitos del PM2 define las actividades relacionadas con la identificación,
documentación, evaluación, priorización, aprobación, validación de los requisitos, y la comunicación del estado de
los requisitos a todas las partes interesadas relevantes.
El proceso de gestión de requisitos es fundamental para abordar la prevención de la inyección SQL de manera
efectiva.
1.Identificación de requisitos de seguridad:

a. Realizar un análisis exhaustivo del sistema y las aplicaciones para identificar posibles puntos vulnerables a la
inyección SQL.
b. Identificar los requisitos de seguridad específicos relacionados con la prevención de la inyección SQL.
c. Documentar y priorizar los requisitos identificados.
Fecha: 17/07/2023 53/ 89 Versión: 3.0

2.Definición de medidas de protección:
a. Establecer medidas de protección técnicas y prácticas para prevenir la inyección SQL.
b. Considerar el uso de mecanismos de validación y filtrado de entrada de datos para garantizar la integridad de las
consultas.
c. Promover el uso de consultas parametrizadas o el uso de ORM (Mapeo Objeto-Relacional) que proporcionen
protección automática contra la inyección SQL.
d. Definir prácticas de codificación segura, como la evitación de la concatenación de consultas SQL y el uso de
funciones de escape adecuadas.
e. Investigar y adoptar frameworks y bibliotecas de desarrollo que ofrezcan protección integrada contra la inyección
SQL.
3.Establecimiento de controles de acceso y privilegios:

a. Definir políticas de seguridad y controles de acceso adecuados para limitar el acceso no autorizado a la base de
datos.
b. Asignar roles y privilegios de usuario de manera apropiada, asegurándose de que solo los usuarios autorizados
tengan permisos para realizar operaciones de lectura, escritura o modificación de datos.
c. Implementar técnicas de autenticación y autorización robustas para proteger el acceso a las funciones de
administración de bases de datos.
4.Pruebas de seguridad:
a. Realizar pruebas de seguridad regulares para identificar posibles vulnerabilidades de inyección SQL.
b. Utilizar herramientas y técnicas de pruebas de penetración para simular ataques de inyección SQL y evaluar la
resistencia del sistema.
c. Realizar pruebas de estrés y pruebas de caja negra para evaluar la seguridad y la respuesta del sistema frente a
diferentes escenarios de inyección SQL.
3.Mantenimiento continuo:
a. Mantenerse actualizado sobre las últimas amenazas y técnicas de inyección SQL, y ajustar continuamente las
medidas de protección en consecuencia.
b. Realizar revisiones periódicas de los requisitos de seguridad y actualizarlos según sea necesario.
15.3. El Ciclo de Vida de los Requisitos

Un requisito puede pasar por las etapas del ciclo de vida siguientes:
• Especificado: El requisito se especifica en un documento o en un sistema de documentación y gestión de
requisitos.
• Propuesto: El requisito ha pasado la evaluación, pero aún no ha sido aprobado por el cliente. Si no pasa la
evaluación obtendrá el estatus de "Por Resolver" o "Rechazado".
• Aprobado: El requisito es aprobado formalmente por el cliente. Si no es aprobado, obtendrá el estatus de
"Por Resolver" o "Rechazado".
Fecha: 17/07/2023 54/ 89 Versión: 3.0

• Incorporado: El requisito se incorpora en el Plan de Trabajo del Proyecto (PTP). Si durante la incorporación
se descubre un problema, el estado puede cambiar a “Por Resolver”.
• Implementado: El requisito se implementa en uno o más de los entregables del proyecto y se prueba con
arreglo a los criterios de aceptación por el Equipo de Desarrollo del Proyecto (EDP), pero aún no ha sido
aceptado formalmente por el cliente. Si durante la implementación se descubre un problema, el estado
puede cambiar a “Por Resolver”.
• Validado: El requisito implementado se valida formalmente según los criterios de aceptación y es aceptado
por el cliente. Si durante la validación y aceptación se descubre un problema, los requisitos pueden ser
aceptados parcialmente y el estado puede cambiar a “Por Resolver”.
Además, los requisitos pueden tener los estados especiales siguientes:
• Por Resolver: Si hay un problema, un requerimiento puede pasar al estado "Por Resolver" en cualquier
etapa del ciclo de vida de los requisitos. Las razones de este estado pueden ser: que el requisito no esté
bien documentado, o que sea inconsistente con otro requisito. Otra razón es que el requisito sólo pasó la
validación parcialmente. Después de resolver los problemas, un requisito puede volver al estado
Especificado. Si no se puede resolver un problema, un requisito puede pasar al estado de Rechazado.
• Rechazado: Un requisito puede ser rechazado por diferentes razones. Algunos ejemplos son: El requisito
es obsoleto, está fuera de alcance, no es factible, se ha pospuesto (a una fase posterior del proyecto, o
para otro proyecto), se ha fusionado con otro requisito, y un requisito puede ser identificado como un
requisito duplicado y, por lo tanto, ser rechazado.
19. 4.Roles y Responsabilidades en la Gestión de Requisitos

Los principales roles y responsabilidades del proceso de gestión de los requisitos son:
• Propietario del Proyecto (PP): es quien aprueba todos los requisitos y tiene la responsabilidad de aprobar
o rechazar la documentación de los requisitos, incluidas las prioridades de cada uno de ellos.
• Comité de Dirección del Proyecto (CDP): se le informa sobre el estado del proceso de recopilación de
requisitos y sobre los cambios en la documentación y prioridades de los requisitos aprobados.
• Responsable de Negocio (RN): se le consulta para la adaptación y elaboración de la documentación de
requisitos y las prioridades. El responsable de Negocio (RN) se encarga de identificar a los Representantes
de Usuarios (RU) relevantes que pueden proporcionar información en el proceso de recopilación de
requisitos como, por ejemplo, la participación en talleres y entrevistas. Además, el responsable de Negocio
(RN) identifica a los Representantes de Usuarios (RU) que participarán en las pruebas durante el proceso
de aceptación de los entregables.
• Proveedor de soluciones (PS): se le informa sobre el estado de los procesos de recopilación y gestión de
requisitos.
• Director de Proyecto (DP): es responsable de gestionar, monitorear, controlar e informar sobre el estado
de la documentación y de los procesos de los requisitos, incluida la identificación, documentación,
evaluación, priorización, aprobación y validación de los requisitos. El DP puede asignar tareas específicas
a un miembro del Equipo de Desarrollo del Proyecto (EDP) o a otra parte interesada del proyecto como,
por ejemplo, un analista de negocio.
• Equipo Central del Proyecto (ECP): se le informa sobre el estado de los procesos de recopilación y gestión
de requisitos. Algunos miembros del equipo pueden apoyar al DP en las actividades relacionadas con la
gestión de los requisitos. Un analista de negocio puede formar parte del EDP.
• Órgano de Gobernanza Pertinente (OGP): se le informa sobre el estado de los procesos de recopilación y
gestión de requisitos.
• Otras partes interesadas: <añada otros interesados si fuese relevante.>
Fecha: 17/07/2023 55/ 89 Versión: 3.0

La tabla RASCI siguiente define las responsabilidades de aquellos que están involucrados en la gestión de requisitos:
RAM (RASCI) OGP CDP PP RN RU PS DP ECP
Planificar la Gestión de Requisitos I I A C C I R S
Gestionar Requisitos I I A C C I R S
*OGP: Órgano de Gobernanza Pertinente.
Los datos de contacto de cada una de las partes interesadas mencionadas están documentados en la Matriz de
Partes Interesadas del Proyecto.
15.5. Herramientas y Técnicas

Se utilizarán las siguientes técnicas para la gestión de los requisitos:
• Entrevistas.
• Tormenta de ideas.
• Talleres.
• Observación.
• Prototipado.
• Priorización MoSCoW.
• …
Entrevistas: Realizar entrevistas con los stakeholders relevantes, como desarrolladores, administradores de bases
de datos y expertos en seguridad, para comprender sus perspectivas y necesidades en relación con la prevención
de la inyección SQL.
Tormenta de ideas: Organizar sesiones de tormenta de ideas con el equipo de desarrollo para generar ideas y
soluciones creativas para prevenir la inyección SQL.
Talleres: Realizar talleres de trabajo con el equipo de desarrollo y los stakeholders para identificar y definir
requisitos específicos relacionados con la seguridad y la prevención de la inyección SQL.
Observación: Observar el funcionamiento del sistema y las prácticas de desarrollo existentes para identificar
posibles puntos vulnerables a la inyección SQL y recopilar requisitos basados en esas observaciones.
Prototipado: Crear prototipos de funcionalidades o interfaces relacionadas con la prevención de la inyección SQL
para obtener retroalimentación y validar los requisitos con los stakeholders.
Priorización MoSCoW: Utilizar la técnica MoSCoW (Must have, Should have, Could have, Won't have) para priorizar
los requisitos relacionados con la prevención de la inyección SQL, definiendo qué funcionalidades son
imprescindibles, importantes o pueden posponerse.
Análisis de riesgos: Realizar un análisis de riesgos específico para la inyección SQL, identificando y evaluando los
riesgos asociados con diferentes escenarios y requisitos de seguridad.
Fecha: 17/07/2023 56/ 89 Versión: 3.0

Revisión de literatura y mejores prácticas: Investigar y revisar literatura especializada, estándares y mejores
prácticas en relación con la prevención de la inyección SQL para obtener conocimientos y requisitos relevantes.
Análisis de casos de uso: Utilizar el análisis de casos de uso para identificar los diferentes escenarios en los que se
podrían producir ataques de inyección SQL y, a partir de ahí, establecer requisitos específicos para prevenirlos.
Evaluación de herramientas y tecnologías: Realizar una evaluación de herramientas y tecnologías disponibles que
ayuden a prevenir la inyección SQL, considerando requisitos técnicos y de seguridad para la selección adecuada.
Se utilizarán las siguientes herramientas para la gestión de los requisitos:
• Documentación de requisitos
• Matriz de trazabilidad de los requisitos.
• …
Documentación de requisitos: Documentar de manera clara y concisa los requisitos relacionados con la prevención
de la inyección SQL, incluyendo los requisitos de seguridad, validación de entrada de datos y prácticas de codificación
segura.
Matriz de trazabilidad de los requisitos: Crear una matriz de trazabilidad que muestre la relación entre los requisitos
identificados y las medidas de protección implementadas para prevenir la inyección SQL. Esto permite rastrear y
validar la implementación efectiva de los requisitos en el sistema.
Revisión de código: Realizar revisiones de código enfocadas en identificar posibles vulnerabilidades de inyección SQL
y garantizar que se sigan las mejores prácticas de codificación segura en el desarrollo de software.
Auditorías de seguridad: Realizar auditorías regulares de seguridad que incluyan pruebas específicas para detectar
y prevenir la inyección SQL en el sistema. Estas auditorías pueden ser realizadas por equipos de seguridad internos
o por expertos externos en seguridad de aplicaciones.
Modelado de amenazas: Realizar un análisis de modelado de amenazas específico para la inyección SQL,
identificando los diferentes escenarios de ataque y las posibles contramedidas para prevenirlos. Esto ayuda a
establecer requisitos de seguridad sólidos.
La documentación de los requisitos y la matriz de trazabilidad pueden formar parte de un sistema de

documentación y gestión de los Requisitos.
15.6. Matriz de Trazabilidad de los Requisitos
Puede ser necesario efectuar la trazabilidad de los requisitos y de los atributos de los requisitos, a partir desde las
necesidades de negocio de alto nivel hasta los requisitos detallados, y finalmente, hasta los entregables.
Para mantener estas relaciones, se utiliza una matriz de trazabilidad. Esta matriz puede ser un archivo de Excel con
atributos como los propuestos a continuación, o un sistema que puede formar parte de un sistema de gestión de
necesidades más amplio.
La matriz de trazabilidad de requisitos puede tener la siguiente estructura:
Fecha: 17/07/2023 57/ 89 Versión: 3.0

15.7. Gestión de Cambios de los Requisitos
El proceso para gestionar el cambio de los requisitos relacionados con la prevención de la inyección SQL puede
adaptarse de la siguiente manera:
Identificación del cambio:
Realizar un seguimiento continuo de los avances y cambios en el campo de la seguridad y la prevención de la
inyección SQL.
Mantenerse actualizado sobre nuevas amenazas, vulnerabilidades y mejores prácticas en relación con la inyección
SQL.
Identificar cualquier necesidad de cambio en los requisitos existentes debido a cambios en el entorno o nuevos
conocimientos adquiridos.
Evaluación del cambio:
Evaluar el impacto del cambio propuesto en los requisitos existentes.
Analizar los riesgos y beneficios asociados con el cambio propuesto.
Determinar si el cambio es necesario y justificado en función de los requisitos de seguridad y las mejores prácticas
de prevención de la inyección SQL.
Análisis de impacto:
Analizar cómo el cambio propuesto afectará a otros requisitos, funcionalidades o componentes del sistema.
Evaluar los recursos necesarios, como tiempo, esfuerzo y costos adicionales, para implementar el cambio.
Priorización y aprobación:
Priorizar el cambio propuesto en función de su importancia y urgencia en relación con otros cambios y requisitos
del sistema.
Presentar el cambio propuesto a los stakeholders relevantes, como el equipo de desarrollo, los expertos en
seguridad y los responsables de la toma de decisiones.
Obtener la aprobación necesaria para implementar el cambio.
Implementación y validación:
Implementar el cambio en el sistema, siguiendo las prácticas de desarrollo y seguridad adecuadas.
Realizar pruebas exhaustivas para validar la efectividad del cambio en la prevención de la inyección SQL.
Verificar que los requisitos modificados se hayan implementado correctamente y cumplan con los criterios de
aceptación establecidos.
Comunicación y documentación:
Comunicar el cambio a todas las partes interesadas relevantes, asegurándose de que estén informadas sobre los
cambios realizados en los requisitos relacionados con la prevención de la inyección SQL.
Actualizar la documentación de requisitos existente para reflejar los cambios realizados y mantener un registro
actualizado de los requisitos modificados.
Fecha: 17/07/2023 58/ 89 Versión: 3.0

16.PLAN DE GESTION DE CAMBIOS DEL PROYECTO
16.1. Introducción
• Aprovechar las capacidades de nuestros colaboradores. Al estandarizar los procesos, podemos dividir las tareas
y capacitar a cada empleado en su puesto específico, así como determinar nuevas tareas que cada uno pueda
realizar de acuerdo con sus capacidades.
• Edifica la metodología, los estándares, las herramientas y las técnicas utilizadas para apoyar la gestión de
cambios del proyecto.
16.2. Objetivos de la Gestión de Cambios

El objetivo de la gestión de cambios del proyecto es aportar transparencia, responsabilidad y trazabilidad a todos
los cambios del proyecto implementados, una vez definidas las líneas de base del alcance y los planes del proyecto.
Asegura que los cambios con un impacto significativo en cualquiera de las dimensiones del proyecto (es decir,
alcance, tiempo, coste, calidad o riesgo) sean evaluados, acordados y aprobados adecuadamente por el nivel de
autoridad pertinente.
Un cambio de proyecto puede provenir, p.ej., de un cambio de alcance, un nuevo requisito, un problema
identificado, una acción preventiva para reducir el nivel de riesgo o una decisión tomada para cambiar cualquiera
de las líneas de base del proyecto (programación o presupuesto).
16.3. Proceso de la Gestión de Cambios

El proceso de gestión de cambios para este proyecto es un proceso de cinco pasos y forma parte de las
responsabilidades del director de Proyecto, quien debe ejecutar el proceso cuando sea necesario en cualquier
momento del ciclo de vida del proyecto.
Paso 1: Identificación del Cambio

El propósito de este paso es facilitar la identificación y documentación de las solicitudes de cambio a las líneas de
base del proyecto tales como alcance, requisitos, entregables, recursos, costes, cronograma o características de
calidad.
Una solicitud de cambio puede presentarse formalmente a través de un Formulario de Solicitud de Cambio o puede
identificarse y proponerse durante las reuniones, como resultado de decisiones, incidencias o riesgos. El Registro
de Cambios contiene información que debe cumplimentarse en esta etapa, como el identificador del cambio, el
nombre del solicitante, la fecha de identificación, la categoría, los detalles y su impacto, así como el estado del
cambio.
Paso 2: Evaluación del Cambio y Recomendación de Acción

El propósito es evaluar:
- Si esta solicitud es realmente un cambio del proyecto.
- Definir las diferentes opciones para cumplir con esta solicitud.
- Evaluar la magnitud del cambio identificado para cada opción definida en términos del impacto en los
objetivos, calidad, riesgo, programación, coste y esfuerzo del proyecto y el acuerdo con el contratista.
- Decidir la prioridad que tiene la implementación de la solicitud de cambio.
El diseño de la implementación del cambio (la acción) también impactará en los costes, el cronograma y los recursos
asignados al proyecto, por lo que se evaluarán todas estas dimensiones antes de la aprobación del cambio. Si un
contratista está involucrado, se considerará el impacto en el contrato. Cualquier cambio en un contrato conlleva
una cantidad considerable de trabajo administrativo que es costoso y puede retrasar el proyecto. Debe tenerse en
cuenta que la magnitud del cambio en un contrato puede estar limitada por las normas europeas de licitación.
Fecha: 17/07/2023 59/ 89 Versión: 3.0
Paso 3: Aprobación del Cambio
Alcanzar una decisión con respecto a la aprobación o rechazo del cambio, de acuerdo con el procedimiento de
escalado definido para el proyecto (es decir, revisado por decisores pertinentes en los Niveles de Gestión / Dirección
/ Rectora. Los cambios clasificados como de gran magnitud siempre se comunicarán al Nivel de dirección o al Nivel
rector. Además, los cambios en el alcance del proyecto se informarán anualmente a los Órganos de Gobernanza
Corporativa.
Paso 4: Implementación del Cambio

Para cambios aprobados o fusionados, el director de Proyecto incorporará las acciones relacionadas con estos
cambios en el Plan de Trabajo del Proyecto y actualizará la documentación relacionada como planes, registros y
listas de control.
Paso 5: Control de Cambios

Supervisa y controla los cambios del proyecto para poder comunicarlos fácilmente a los distintos Niveles de decisión
del proyecto, para su aprobación o actualización de estado. El director de Proyecto recopilará cualquier cambio en
el proyecto o acciones relacionadas y controlará el estado de cada actividad de gestión de cambios.
Se utilizarán las reuniones de situación del proyecto para revisar el estado de los cambios y las acciones relacionadas
e identificar nuevos cambios. El director de Proyecto es responsable de actualizar el Registro de Cambios, lo que
puede incluir añadir cambios adicionales, actualizar el estado del cambio, actualizar la estimación del esfuerzo,
modificar los niveles de magnitud y/o prioridad en función de los cambios en el entorno del proyecto, etc.
Además, el director de Proyecto informará periódicamente (mensualmente) del estado de los cambios del proyecto
al Comité de Dirección del Proyecto (CDP) y, cuando sea adecuado, a otras partes interesadas del proyecto (según
el Plan de Gestión de las Comunicaciones).
Fecha: 17/07/2023 60/ 89 Versión: 3.0

LpP (Listo para Planificación)
Change
Formulario
deRequest
Solicitud
1. Identificación del Cambio delForm
Cambio
RegistroLog de
Change
Cambios
2. Evaluación del Cambio y Registro de

Cambios
Recomendación de Acción
Registro de
3. Aprobación del Cambio Cambios
No
Sí
Plan de Trabajo
del Proyecto!
4. Implementación del Cambio Registros
del Proyecto Otros
Planes del
Proyecto.
Registro de
5. Control del Cambio Cambios
Informes
Change Log de
Proyecto
LpC (Listo para Cierre)
16.4. Roles y Responsabilidades en la Gestión de Cambios

Los principales roles y responsabilidades para el proceso de gestión de cambios del proyecto son:
• Comité de Dirección del Proyecto (CDP): Se le consulta para la aprobación de cambios y se le informa
mensualmente sobre el estado de los cambios. Este comité puede volver a evaluar los cambios y modificar
la prioridad, identificar nuevos cambios, perfeccionar el enfoque de acción y escalar las solicitudes de
cambio a otras partes interesadas.
• Propietario del Proyecto (PP): Es responsable de todas las actividades relacionadas con los cambios y tiene
la responsabilidad de aprobar o rechazar los cambios o escalarlos de acuerdo con el procedimiento de
escalación.
• Comité de Control de Cambios (CCC) o Comité Asesor de Cambios (CAC): El PP y/o el CDP pueden delegar
su autoridad para aprobar o rechazar cambios en el Comité de Control de Cambios (CCC) o en el Comité
Asesor de Cambios (CAC).
Fecha: 17/07/2023 61/ 89 Versión: 3.0

• Responsable de Negocio (RN): Se le consulta para evaluar y aprobar los cambios y para validar los pasos
recomendados de acción, el impacto, y el esfuerzo y el tiempo estimados desde la perspectiva del
solicitante.
• Proveedor de Soluciones (PS): Se le consulta para evaluar y aprobar los cambios y para validar los pasos
recomendados de acción, el impacto, y el esfuerzo y el tiempo estimados desde la perspectiva del
proveedor de soluciones (en el Comité de Dirección del Proyecto).
• Director de Proyecto (DP): Es responsable de la gestión, el seguimiento, control e información de los
cambios del proyecto y de la consolidación y su documentación en los documentos relacionados con el
proyecto. El DP puede asignar tareas específicas al Equipo Central del Proyecto (ECP) o a otras partes
interesadas del proyecto. El Registro de Cambios se revisa semanalmente en las reuniones de estado del
proyecto y cualquier nuevo cambio identificado o re-evaluado debe comunicarse al CDP (cambios de gran
y mediano alcance) para su aprobación.
• Equipo Central del Proyecto (ECP): Apoya al director de Proyecto en las actividades relacionadas con la
gestión de cambios del proyecto e identifica y evalúa los cambios del proyecto durante todo el ciclo de
vida del proyecto.
• Grupo de Implementación en el Negocio (GIN): se le informa de los cambios del proyecto y puede solicitar
nuevos cambios.
La siguiente tabla RASCI define las responsabilidades de todos aquellos involucrados en la gestión de cambios del
proyecto.
RAM (RASCI) OGP* CDP PP RN RU PS DP ECP
Plan de Gestión de Cambios del Proyecto I C A C I I R I
Gestión de Cambios del Proyecto I C A S I I R C
*OGP: Órgano de Gobernanza Pertinente.

16.5. Herramientas y Técnicas
Se pueden utilizar las siguientes técnicas para la gestión de cambios del proyecto:
• Análisis de Impacto.
• Manejar la Satisfacción del Cliente.
• Cambios de transición (adquisiciones, fusiones, relanzamientos)
• Gestión de implementación de TI
Se pueden utilizar estas herramientas para la gestión de cambios del proyecto:
• Registro de Cambios.
• Formulario de Solicitud de Cambios.
Fecha: 17/07/2023 62/ 89 Versión: 3.0

16.6. Registro de Cambios
Registro de Cambios
Identificación y descripción del cambio

ID 1.0
Categoría Mejora de negocio.
Título Cambio de interfaz de usuario
- Permite que el usuario interactúe con el producto de manera natural para

que su experiencia sea cómoda y agradable.
- Permitir que cualquier dispositivo se pueda usar, ya sea un móvil, una
tableta o una computadora.
Descripción
- Cada elemento incluido en una interfaz puede contar con una etiqueta, ya
sea un título, imagen o texto.
- Las etiquetas deben ser claras para que los usuarios puedan encontrar lo
que necesiten rápidamente y navegar a través de la interfaz sin problema.
En evaluación: use este estado para iniciar una evaluación.
Estado Esperando aprobación: use esto para iniciar la aprobación. Antes de hacer esto,
asegúrese de que la investigación está completa y que las estimaciones mostradas
son correctas.
Solicitado por Universidad Tecnológica de Nezahualcóyotl
Fecha de identificación (o
27/06/2023
fecha de envío)
Evaluación del cambio y descripción de la acción
Magnitud 4=Alto
Prioridad 5=Muy alto
Fecha de entrega objetivo 05/07/2023
Aprobación del cambio
Escalado ¿Es necesario el escalado al Nivel de Dirección o Rector? Sí
Decisión Decisión tomada.
Decidido por Francisco Nicolas Ortiz

Fecha de decisión 27/06/2023
Implementación del cambio

Fecha de entrega real 01/06/2023
Fecha: 17/07/2023 63/ 89 Versión: 3.0

Trazabilidad y comentarios N/A
Su ubicación se encuentra en el Apéndice 1.
16.6.1. Formulario de Solicitud de Cambio
– Formulario de Solicitud de Cambio
Solicitud de Cambio
Nombre del cambio Cambio de interfaz de usuario
ID del cambio 1.0
Nombre del cambio Cambio de interfaz de usuario

Fecha de identificación 27/06/2023
Solicitado por Universidad Tecnológica de Nezahualcóyotl
Clasifica los cambios en nuevos requisitos, relacionados con incidencias o riesgos,

Categoría
mejoras de negocio, etc.
Prioridad 4 = Alto
Descripción del Cambio y Detalles
Permitir que cualquier dispositivo se pueda usar, ya sea un móvil, una tableta o una
Situación actual
computadora.
El usuario pueda interactuar con el producto de manera natural para que su
Situación deseada
experiencia sea cómoda y agradable.
La interfaz es el nexo que facilita la comunicación entre el humano y la
computadora.
Impacto o riesgos Es el conjunto de todos los componentes de un sistema interactivo que
proporcionan información y controles para que el usuario realice tareas específicas
con el sistema.
Fuera de alcance – N/A
Referencias y Documentos Relacionados
Enlace – Ubicación de los documentos relevantes (o de apoyo).
16.7. Evaluación del Cambio y Actividades de Recomendación de Acción

Las actividades y herramientas utilizadas son:
• Análisis de impacto
• Análisis de riesgos
• Registro de Riesgos.
Fecha: 17/07/2023 64/ 89 Versión: 3.0

Los cambios serán revisados y evaluados durante las reuniones de control de cambios, como se describe en el Plan
de Gestión de las Comunicaciones. Durante las reuniones de control de cambios, las actividades de
recomendación se proponen, discuten, priorizan y registran en el Registro de Cambios, junto con los comentarios
del director de Proyecto o de otras partes interesadas.
16.8. Decisiones de Aprobación de Cambios

Las acciones recomendadas para los cambios de tamaño significativo se discutirán durante la reunión del Comité de
Dirección del Proyecto (CDP), que habitualmente se realiza mensualmente. El Comité de Dirección del Proyecto
(CDP) desempeña el papel de lo que generalmente se conoce como el Comité de Control de Cambios (CCC) o
el Comité Asesor de Cambios (CAC). Para cambios sustanciales de alcance, cronograma y costes, el CDP o CCC /
CAC revisará el Acta de Constitución del Proyecto para asegurarse de que el cambio solicitado no vaya más allá de
los límites definidos. Para cambios sustanciales en los costes, el CDP o CCC / CAC revisará el caso de negocio para
asegurarse de que la justificación del negocio siga siendo válida.
Para cada cambio, el Registro de Cambios debe tener en este punto la siguiente información:
• Descripción y evaluación del cambio.
• Acción recomendada, pasos principales, entregables y estimación de tiempo, recursos y coste.
• Cambio aprobado por los cambios que no tienen un impacto significativo en el tiempo de entrega y el
presupuesto, pueden aprobarse durante las Reuniones de Control de Cambios.
16.9. Actividades de Implementación de Cambios

Las actividades relacionadas con la implementación de cambios y su estado se documentarán en:
• Plan de Trabajo del Proyecto.
• Registro de Decisiones.
16.10. Control de Cambios e Informes

Los cambios nuevos o abiertos se identificarán / reevaluarán cada 3er dia durante las Reuniones
de Estado del Proyecto, y el director de Proyecto actualizará el Registro de Cambios con los resultados del análisis
/ revisión.
Para los cambios de magnitud media alta o muy alta, el director de Proyecto informará, con periodicidad mensual,
de su estado al Comité de Dirección del Proyecto (CDP), el Comité de Control de Cambios (CCC) o Comité Asesor de
Cambios (CAC) y, cuando sea adecuado, a otras partes interesadas.
Fecha: 17/07/2023 65/ 89 Versión: 3.0

20. ENGINEERING PROJECT CLOSEOUT REPORT
Fecha: 17/07/2023 66/ 89 Versión: 3.0

Fecha: 17/07/2023 67/ 89 Versión: 3.0
Fecha: 17/07/2023 68/ 89 Versión: 3.0
21. INFORME DE FIN DE PROYECTO
Introducción
El propósito de este informe es analizar y resumir la eficacia de las diversas dimensiones y actividades relacionadas
con el tema de inyección SQL en el proyecto. La inyección SQL es una vulnerabilidad común y peligrosa que puede
comprometer la seguridad de las aplicaciones y los datos. Este informe tiene como objetivo proporcionar una visión
general de las medidas implementadas para prevenir y mitigar los riesgos asociados con la inyección SQL, así como
destacar las lecciones aprendidas y las mejores prácticas identificadas a lo largo del proyecto.
Durante la vida del proyecto, se llevaron a cabo análisis de riesgos, planificación y diseño de la arquitectura,
desarrollo de código seguro, pruebas exhaustivas de seguridad, monitorización y detección de intrusiones, y
campañas de concientización y capacitación. Estas actividades se centraron en prevenir la inyección SQL, identificar
posibles vulnerabilidades y establecer medidas de mitigación efectivas.
Al finalizar el proyecto, es fundamental documentar las lecciones aprendidas y las mejores prácticas identificadas.
Esto permitirá que los futuros proyectos y equipos de proyecto se beneficien de la experiencia adquirida y eviten
cometer los mismos errores. Además, se buscará proporcionar recomendaciones post-proyecto relacionadas con
las operaciones del producto/servicio para mejorar la seguridad y prevenir la inyección SQL en el futuro.
El informe finalizará con una visión general de las lecciones generales aprendidas del proyecto en su conjunto,
destacando la importancia de la planificación, el diseño seguro, las pruebas exhaustivas, la monitorización en
tiempo real y la educación para prevenir eficazmente la inyección SQL. Estas elecciones serán valiosas tanto para el
equipo de proyecto actual como para proyectos futuros, y ayudarán a fortalecer la seguridad de las aplicaciones y
proteger los datos sensibles contra este tipo de amenazas.
22. ÉXITO DEL PROYECTO

Eficacia
El cliente: El producto o servicio ha demostrado ser altamente eficaz para satisfacer las necesidades del cliente en
términos de seguridad. Se implementaron medidas robustas para prevenir y mitigar la inyección SQL, lo que ha
llevado a una disminución significativa en el riesgo de ataques y vulnerabilidades. La satisfacción del cliente se
refleja en la reducción de incidentes de seguridad y en la protección de la integridad de los datos.
La organización ejecutora: El producto o servicio ha sido efectivo en fortalecer la postura de seguridad de la
organización ejecutora. Se ha logrado una mayor confianza en la protección de los sistemas y la información frente
a la inyección SQL. Además, la implementación exitosa ha mejorado la reputación de la organización en términos
de seguridad y ha demostrado su compromiso con la protección de los datos sensibles.
Los requisitos: El producto o servicio ha cumplido satisfactoriamente con los requisitos establecidos para prevenir
y mitigar la inyección SQL. Se implementaron medidas técnicas y procesos sólidos para garantizar la seguridad de
las aplicaciones y los datos. La funcionalidad y la capacidad de respuesta del sistema se han mantenido sin
comprometer la seguridad, lo que demuestra una solución efectiva y compatible con los requisitos del proyecto.
El negocio según el Caso de Negocio: El producto o servicio ha generado un impacto positivo en el negocio, tal como
se especificó en el Caso de Negocio. Se han reducido los riesgos asociados con la inyección SQL, lo que ha llevado a
una mayor confianza de los clientes y ha mejorado la reputación de la organización. Además, se ha evitado la
pérdida de datos y los posibles daños a la imagen de la empresa, lo que ha resultado en beneficios tangibles y un
retorno de la inversión satisfactorio.
Fecha: 17/07/2023 69/ 89 Versión: 3.0

Métricas específicas de rendimiento del proyecto:
Reducción del número de vulnerabilidades de inyección SQL detectadas en las pruebas de seguridad.
Disminución en el número de incidentes de seguridad relacionados con la inyección SQL.
Aumento de la confianza de los clientes en la seguridad de los sistemas y datos.
Mejora en la reputación de la organización en términos de seguridad.
Cumplimiento de los requisitos técnicos y de seguridad establecidos.
Evitación de pérdidas de datos y daños a la imagen de la empresa.
Evaluación del Proyecto (Coste-Cronograma-Alcance-Calidad)

Alcance: El alcance inicial del proyecto fue estable y se gestionaron suficientemente los requisitos. Se realizó un
análisis exhaustivo de los requisitos de seguridad y se definieron claramente las funcionalidades necesarias para
prevenir y mitigar la inyección SQL. A lo largo del proyecto, se llevaron a cabo revisiones periódicas del alcance para
garantizar que se cumplieran los requisitos y se abordaran los cambios necesarios.
Gestión de cambios: Los cambios del proyecto se gestionaron de acuerdo con el plan de gestión de cambios
establecido. Se estableció un proceso formal para solicitar, evaluar y aprobar los cambios en el alcance, el
cronograma y el presupuesto. Los cambios se evaluaron cuidadosamente en términos de su impacto en la seguridad
y se tomaron decisiones informadas para minimizar los riesgos y garantizar el cumplimiento de los objetivos del
proyecto.
Importancia de los cambios de alcance: Los cambios de alcance aprobados desempeñaron un papel crucial en el
proyecto. A medida que se identificaron nuevas amenazas y vulnerabilidades, se realizaron cambios en el alcance
para abordarlos de manera efectiva. Estos cambios permitieron mejorar la robustez de las medidas de seguridad
implementadas y garantizar un nivel adecuado de protección contra la inyección SQL.
Comparación de las versiones de la línea base de programación y presupuesto: Las estimaciones iniciales fueron
precisas en términos generales, pero se produjeron algunas discrepancias durante la ejecución del proyecto. Hubo
un ligero retraso en la programación debido a la complejidad de algunas tareas de desarrollo y pruebas de
seguridad. Sin embargo, se realizaron ajustes y se implementaron medidas para minimizar el impacto en el
cronograma general del proyecto. En cuanto al presupuesto, se mantuvo dentro de los límites establecidos, aunque
hubo algunos costos adicionales asociados con la contratación de expertos en seguridad y herramientas
especializadas.
Cumplimiento de las normas de calidad: Los entregables del proyecto cumplieron con las normas de calidad
definidas. Se realizaron revisiones exhaustivas de los entregables para garantizar que cumplieran con los estándares
de seguridad y las mejores prácticas establecidas. Además, se llevaron a cabo pruebas rigurosas de seguridad para
validar la eficacia de las medidas implementadas contra la inyección SQL.
Cuestiones específicas relacionadas con la gestión del coste, programación, alcance y calidad: Algunas cuestiones
específicas incluyeron la necesidad de ajustar el cronograma para abordar desafíos técnicos, la asignación adecuada
de recursos y presupuesto para garantizar la implementación efectiva de las medidas de seguridad, y la necesidad
de una estrecha colaboración con expertos en seguridad para garantizar la calidad y efectividad de las soluciones
implementadas.
Fecha: 17/07/2023 70/ 89 Versión: 3.0

23. EVALUACIÓN DE LA GESTIÓN DEL PROYECTO
General
Aspectos que podrían haberse hecho mejor en la gestión general del proyecto:
Comunicación y colaboración: Aunque se estableció una comunicación regular entre los miembros del equipo y las
partes interesadas, podría haberse mejorado la comunicación en términos de claridad y transparencia. Además, la
colaboración entre los diferentes equipos podría haber sido más estrecha para maximizar la eficacia del proyecto.
Gestión de riesgos: Aunque se realizaron análisis de riesgos y se implementaron medidas de mitigación, la gestión
de riesgos podría haber sido más proactiva. Se podría haber realizado un monitoreo continuo de los riesgos
identificados y se podrían haber implementado estrategias adicionales para minimizar su impacto.
Gestión del cambio: Si bien se gestionaron los cambios del proyecto según el plan de gestión de cambios
establecido, podría haberse mejorado la anticipación y la respuesta a los cambios. Una mayor flexibilidad y agilidad
en la gestión de los cambios habría permitido adaptarse de manera más eficiente a las nuevas necesidades y
desafíos que surgieron durante el proyecto.
Eficacia del nivel de adaptación y personalización de la Metodología PM2, la aplicación de los procesos y el uso de
los análisis posteriores:
La adaptación y personalización de la Metodología PM2, junto con la aplicación de los procesos establecidos y el
uso de análisis posteriores, fueron eficaces en la gestión del proyecto de inyección SQL. La Metodología PM2
proporcionó un marco sólido y estructurado para el proyecto, y los procesos establecidos permitieron un enfoque
sistemático en la planificación, ejecución y control. Los análisis posteriores, como las lecciones aprendidas,
ayudaron a identificar áreas de mejora y a aplicar mejoras en futuros proyectos.
Sin embargo, se reconoce que podría haberse realizado una adaptación y personalización más exhaustiva de la
Metodología PM2 para abordar específicamente los desafíos y las necesidades del proyecto de inyección SQL. Una
mayor adaptación habría permitido una mayor alineación con los requisitos y las características únicas del proyecto,
lo que podría haber mejorado aún más la eficacia de la gestión del proyecto.
Gestión de Riesgos
Riesgos significativos identificados y que se produjeron realmente:
Vulnerabilidades desconocidas: Se identificaron y se tuvo en cuenta la posibilidad de que surgieran nuevas
vulnerabilidades a lo largo del proyecto. Durante la ejecución, se descubrieron algunas vulnerabilidades que no se
habían previsto inicialmente, pero se logró abordarlas de manera efectiva mediante ajustes en el alcance y la
implementación de soluciones de seguridad adicionales.
Falta de experiencia en seguridad: Se reconoció la falta de experiencia en seguridad en el equipo y se identificó
como un riesgo potencial. Durante el proyecto, se enfrentaron desafíos relacionados con la implementación de
medidas de seguridad adecuadas. Sin embargo, se logró superar este riesgo al contratar expertos en seguridad y
recibir capacitación adicional para fortalecer los conocimientos y habilidades del equipo.
Riesgos significativos que se produjeron, pero no se identificaron:
Impacto de la interdependencia: Aunque se tuvo en cuenta la interdependencia de las diferentes partes del sistema,
se produjeron algunos retrasos y complicaciones debido a factores inesperados. Este riesgo no se había identificado
explícitamente y, como resultado, hubo cierta falta de preparación para abordar estos problemas. Sin embargo, se
tomaron medidas correctivas para minimizar el impacto en el proyecto.
Fecha: 17/07/2023 71/ 89 Versión: 3.0

Cambios en los requisitos de seguridad: A medida que se desarrollaba el proyecto, surgieron nuevos requisitos de
seguridad que no se habían anticipado inicialmente. Estos cambios no se identificaron como riesgos potenciales y
se requirió una adaptación rápida para cumplir con los nuevos requisitos. Aunque esto generó cierta presión
adicional en términos de tiempo y recursos, se pudo abordar de manera efectiva mediante la reasignación de tareas
y la colaboración cercana con los stakeholders.
Eficacia de las estrategias y planes de acción seleccionados para los riesgos que se produjeron:
Las estrategias y planes de acción seleccionados para los riesgos que se produjeron fueron en general efectivos. Se
implementaron medidas correctivas y se asignaron recursos adicionales cuando fue necesario. Hubo una respuesta
rápida a los riesgos identificados, lo que permitió minimizar su impacto en el proyecto.
Gestión de Partes Interesadas

Principales partes interesadas no identificadas al inicio del proyecto:
Equipos de seguridad y auditoría interna: No se identificó inicialmente la necesidad de involucrar a los equipos de
seguridad y auditoría interna en el proyecto. Sin embargo, durante la ejecución se reconoció su importancia para
la revisión y validación de las medidas de seguridad implementadas. Se tomó acción para incluir su participación y
se obtuvieron valiosos aportes y recomendaciones.
Actividades de gestión de las partes interesadas particularmente eficaces:
Comunicación regular y transparente: Se estableció una comunicación abierta y regular con las partes interesadas
a lo largo del proyecto. Esto incluyó reuniones periódicas, informes de estado y la provisión de información
actualizada sobre los avances y los riesgos. Esta actividad fue efectiva para mantener a las partes interesadas
informadas y comprometidas con el proyecto.
Participación activa de los usuarios finales: Se involucró a los usuarios finales en el proceso de definición de
requisitos y en las pruebas de aceptación. Su participación permitió obtener retroalimentación temprana y valiosa,
asegurando que las soluciones implementadas cumplieran con sus necesidades y expectativas.
Actividades de gestión de las partes interesadas que podrían haberse hecho mejor o que deberían evitarse:
Identificación tardía de las partes interesadas: Hubo casos en los que algunas partes interesadas relevantes no
fueron identificadas hasta etapas avanzadas del proyecto. Esto resultó en una falta de participación o en la
necesidad de adaptar rápidamente las estrategias de gestión de las partes interesadas para incluir a estas partes
interesadas clave. Se debería haber realizado un esfuerzo más proactivo para identificar a todas las partes
interesadas relevantes desde el inicio del proyecto.
Falta de enfoque en la gestión de expectativas: En algunos casos, no se dio suficiente énfasis en la gestión de las
expectativas de las partes interesadas. Esto llevó a situaciones en las que las expectativas no se alinearon con la
realidad del proyecto, lo que generó frustración o insatisfacción. Se debería haber dedicado más atención a la
comunicación clara sobre los límites y las limitaciones del proyecto desde el principio, y establecer expectativas
realistas.
Fecha: 17/07/2023 72/ 89 Versión: 3.0

Comunicaciones del Proyecto
Actividades de comunicación particularmente efectivas:
Reuniones regulares: La celebración de reuniones regulares, tanto internas como con las partes interesadas
externas, fue una actividad de comunicación efectiva. Estas reuniones permitieron compartir información
actualizada, discutir el progreso del proyecto, abordar posibles problemas y tomar decisiones conjuntas. La
comunicación en tiempo real promovió la alineación y el compromiso de todas las partes involucradas.
Informes de estado: La creación y distribución de informes de estado periódicos fue una actividad efectiva para
mantener a las partes interesadas informadas sobre el progreso del proyecto. Estos informes proporcionaron una
visión general clara de las actividades, los hitos alcanzados y los problemas identificados. La transparencia en la
comunicación contribuyó a la confianza y la comprensión mutua entre el equipo del proyecto y las partes
interesadas.
Actividades de comunicación que podrían haberse hecho mejor o deberían haberse evitado:
Falta de comunicación proactiva sobre cambios y desafíos: En algunos casos, hubo una falta de comunicación
proactiva sobre los cambios en el alcance, los desafíos técnicos y los posibles impactos en el proyecto. Esto generó
incertidumbre y desconcierto entre las partes interesadas y podría haberse evitado con una comunicación más
anticipada y transparente.
No adaptarse a las preferencias de comunicación de las partes interesadas: No todas las partes interesadas tienen
las mismas preferencias de comunicación. Algunas pueden preferir reuniones cara a cara, mientras que otras
pueden preferir comunicación por correo electrónico o mensajería instantánea. No adaptarse a estas preferencias
puede llevar a una comunicación menos efectiva y dificultar la colaboración. Se debería haber realizado un esfuerzo
para identificar y adaptarse a las preferencias de comunicación de las partes interesadas.
Incidencias y Resolución de Conflictos

Incidencias y conflictos significativos:
Identificación de vulnerabilidades adicionales: A lo largo del proyecto, se identificaron nuevas vulnerabilidades que
no se habían anticipado inicialmente. Estas incidencias representaron desafíos adicionales en términos de
seguridad y requerían una acción inmediata para mitigar los riesgos asociados.
Desacuerdos sobre la implementación de medidas de seguridad: Se produjeron conflictos entre el equipo del
proyecto y las partes interesadas en relación con la implementación de medidas de seguridad específicas. Estos
conflictos surgieron debido a diferentes perspectivas y prioridades, lo que generó tensiones y dificultades en la
toma de decisiones.
Eficacia del proceso de gestión de incidencias:
El proceso de gestión de incidencias fue efectivo para abordar los problemas identificados. Se estableció un proceso
formal para reportar, evaluar y abordar las incidencias de seguridad, lo que permitió una respuesta rápida y
coordinada. Las incidencias se documentaron adecuadamente y se tomaron medidas para mitigar los riesgos antes
de que fueran necesarios cambios formales en el alcance.
Eficacia en la resolución de conflictos:
La resolución de conflictos fue efectiva en la mayoría de los casos. Se llevaron a cabo discusiones abiertas y se buscó
el consenso entre las partes involucradas para encontrar soluciones viables y satisfactorias. Sin embargo, en algunos
Fecha: 17/07/2023 73/ 89 Versión: 3.0

casos, los conflictos persistieron y fue necesario un mayor esfuerzo para llegar a un acuerdo mutuamente
beneficioso.
Resolución de incidencias antes de que se necesitase el control de cambios:
En general, se logró resolver la mayoría de las incidencias antes de que fuera necesario recurrir al control de
cambios formal. El proceso de gestión de incidencias permitió una respuesta oportuna y efectiva para abordar las
situaciones problemáticas y tomar medidas correctivas. Esto ayudó a minimizar el impacto en el alcance y a
mantener el proyecto dentro de los límites establecidos.
Aceptación de Entregables
Entregables significativos:
Sistema de seguridad implementado: El principal entregable significativo fue el sistema de seguridad implementado
para prevenir y mitigar la inyección SQL. Este entregable incluyó la implementación de medidas de seguridad
técnicas y procesos específicos para garantizar la protección de los sistemas y datos contra este tipo de
vulnerabilidad.
Informes de pruebas de seguridad: Otro entregable significativo fueron los informes de pruebas de seguridad
realizadas para evaluar la efectividad de las medidas implementadas. Estos informes proporcionaron una
evaluación detallada de las fortalezas y debilidades del sistema en términos de seguridad, y ayudaron a identificar
posibles áreas de mejora.
Eficacia del plan de aceptación de los entregables:
El plan de aceptación de los entregables fue en su mayoría eficaz en asegurar que los entregables cumplieran con
los requisitos y estándares establecidos. Se estableció un proceso de aceptación formal que involucraba a las partes
interesadas clave, como los usuarios finales y los equipos de seguridad. Se definieron criterios claros de aceptación
y se realizaron pruebas y revisiones exhaustivas para verificar el cumplimiento de los requisitos.
Cuestiones específicas identificadas y discutidas:
Requisitos adicionales identificados durante la aceptación: Durante la aceptación de los entregables, se
identificaron algunos requisitos adicionales que no se habían considerado inicialmente. Estos requisitos surgieron
como resultado de la evaluación de los entregables y la retroalimentación de las partes interesadas. Se tuvo que
adaptar el plan de aceptación y realizar ajustes en los entregables para abordar estos nuevos requisitos.
Evaluación subjetiva de los entregables: En algunos casos, la evaluación de los entregables implicaba cierto grado
de subjetividad. Esto generó discrepancias de opinión entre las partes interesadas y dificultó la toma de decisiones.
Se debería haber establecido un proceso más objetivo para evaluar y aceptar los entregables, utilizando criterios
claros y medibles.
24. TRANSICIÓN DEL PROYECTO.

Hitos significativos de la transición:
Implementación del sistema de seguridad: Uno de los hitos más significativos fue la implementación exitosa del
sistema de seguridad para prevenir y mitigar la inyección SQL. Este hito marcó el final del desarrollo e inicio de la
fase de transición, donde el sistema se puso a disposición de los usuarios finales.
Capacitación y documentación: Otro hito importante fue la capacitación de los usuarios finales y la finalización de
la documentación necesaria para la operación y mantenimiento del sistema. Estas actividades eran fundamentales
para garantizar una transición suave y exitosa hacia la etapa de operaciones.
Eficacia de las actividades planeadas y ejecutadas para esos hitos:
Las actividades planeadas y ejecutadas para los hitos de transición fueron en su mayoría efectivas.
Fecha: 17/07/2023 74/ 89 Versión: 3.0

Implementación del sistema de seguridad: Se siguieron los planes establecidos para la implementación del sistema
de seguridad. Las pruebas y validaciones finales se llevaron a cabo de manera exhaustiva, lo que garantizó que el
sistema estuviera listo para su despliegue. Se logró un despliegue exitoso y se cumplieron los requisitos técnicos y
de seguridad establecidos.
Capacitación y documentación: Se diseñaron e impartieron sesiones de capacitación adecuadas para los usuarios
finales, lo que les permitió comprender y utilizar el sistema de seguridad de manera efectiva. Además, se creó
documentación clara y completa para respaldar la operación y el mantenimiento del sistema. Esto aseguró que los
usuarios finales tuvieran los recursos necesarios para utilizar y mantener el sistema después de la transición.
Respaldo y soporte continuo: Se identificó la necesidad de un respaldo y soporte continuo después de la transición.
Esto incluía la provisión de recursos y personal adecuado para abordar cualquier problema o consulta que surgiera
en las etapas iniciales de operación. La falta de un respaldo sólido podría afectar la confianza de los usuarios finales
en el sistema.
Ajustes posteriores a la transición: En algunos casos, se identificaron ajustes y mejoras necesarios después de la
transición. Estos ajustes podrían haberse previsto y planificado de manera más efectiva, lo que habría facilitado su
implementación y evitado interrupciones en la operación normal.
25. IMPLEMENTACIÓN EN EL NEGOCIO

Impactos significativos en la gestión del cambio organizacional:
Mejora de la seguridad de los datos: La implementación del sistema de seguridad tuvo un impacto significativo en
la gestión del cambio organizacional al mejorar la seguridad de los datos y mitigar los riesgos de la inyección SQL.
Esto implicó cambios en los procesos y procedimientos existentes para garantizar el uso adecuado y seguro del
sistema.
Adopción de nuevas prácticas y procedimientos: La implementación también requirió que los usuarios finales
adoptaran nuevas prácticas y procedimientos en relación con la seguridad de los datos y la prevención de la
inyección SQL. Esto implicó un cambio en la forma en que se realizaban ciertas tareas y la adopción de medidas
adicionales para garantizar la protección de los sistemas y datos.
Eficacia de las actividades de implementación en el negocio:
Las actividades planeadas y ejecutadas para los impactos en la gestión del cambio organizacional fueron en su
mayoría efectivas.
Capacitación y concienciación: Se diseñaron e impartieron sesiones de capacitación y concienciación adecuadas
para los empleados, lo que les permitió comprender los cambios y adaptarse a las nuevas prácticas y
procedimientos relacionados con la seguridad de los datos. Esto ayudó a fomentar la adopción exitosa de las nuevas
medidas de seguridad y la prevención de la inyección SQL.
Alineación con la cultura organizacional: Se tuvo en cuenta la cultura organizacional existente al implementar los
cambios. Las actividades de implementación se adaptaron para garantizar que estuvieran alineadas con los valores
y la forma de trabajo de la organización, lo que facilitó la aceptación y adopción por parte de los empleados.
Resistencia al cambio: En algunos casos, se identificó resistencia al cambio por parte de algunos empleados. Esto
puede haberse debido a la falta de comprensión o temor a lo desconocido. Se requirió un mayor esfuerzo para
abordar esta resistencia y brindar el apoyo necesario para que los empleados se sintieran cómodos y confiados en
los nuevos procesos y prácticas.
Fecha: 17/07/2023 75/ 89 Versión: 3.0

Comunicación efectiva: La comunicación efectiva y oportuna sobre los cambios y su impacto fue clave para la
implementación exitosa en el negocio. En algunos casos, la comunicación pudo haberse mejorado, lo que resultó
en una falta de comprensión o confusión por parte de los empleados. Una comunicación clara y constante puede
ayudar a abordar estas cuestiones.
26. GOBERNANZA Y EVALUACIÓN DEL EQUIPO

Desempeño de la Organización Participante
Responsabilidades significativas de la organización participante:
Desarrollo e implementación del sistema de seguridad: La organización participante tuvo la responsabilidad
principal de desarrollar e implementar el sistema de seguridad necesario para prevenir y mitigar la inyección SQL.
Esto incluyó la planificación, el diseño, la programación y las pruebas del sistema, así como la garantía de su
integración con los sistemas existentes.
Colaboración y participación en la gestión del proyecto: La organización participante también tuvo la
responsabilidad de colaborar y participar activamente en la gestión del proyecto. Esto incluyó la comunicación
regular con el equipo del proyecto y otras partes interesadas, la identificación y gestión de riesgos, la toma de
decisiones y el seguimiento del progreso del proyecto.
Eficacia de la organización participante en el cumplimiento de sus responsabilidades:
En general, la organización participante demostró eficacia en el cumplimiento de sus responsabilidades.
Desarrollo e implementación del sistema de seguridad: La organización participante cumplió con éxito con las tareas
relacionadas con el desarrollo e implementación del sistema de seguridad. Se diseñó y programó un sistema eficaz,
y se llevaron a cabo pruebas y validaciones exhaustivas para garantizar su funcionamiento adecuado.
Colaboración y participación en la gestión del proyecto: La organización participante se mantuvo involucrada y
comprometida a lo largo del proyecto. Colaboró estrechamente con el equipo del proyecto y otras partes
interesadas, compartiendo información relevante, tomando decisiones oportunas y contribuyendo activamente a
la resolución de problemas y la mitigación de riesgos.
Coordinación con otras organizaciones: Se identificó la necesidad de una mayor coordinación y comunicación con
otras organizaciones que también estaban involucradas en el proyecto. La falta de una coordinación efectiva puede
haber generado retrasos o dificultades en la ejecución de ciertas tareas. Se debe prestar una atención especial a la
coordinación entre las organizaciones participantes.
Gestión de cambios y requisitos adicionales: A lo largo del proyecto, surgieron cambios y requisitos adicionales que
requerían una adaptación y una respuesta ágil por parte de la organización participante. Se logró una gestión
efectiva de estos cambios en su mayoría, pero hubo casos en los que se requirió un mayor esfuerzo para evaluar y
abordar adecuadamente los cambios y requisitos adicionales.
Fecha: 17/07/2023 76/ 89 Versión: 3.0

Desempeño del Equipo Central del Proyecto
Responsabilidades significativas del equipo central del proyecto:
Planificación y gestión del proyecto: El equipo central del proyecto tuvo la responsabilidad de planificar y gestionar
todas las actividades del proyecto, incluyendo la definición de los objetivos, la elaboración del cronograma, la
asignación de recursos y la supervisión del progreso.
Coordinación de las partes interesadas: El equipo central del proyecto fue responsable de coordinar y gestionar las
relaciones con todas las partes interesadas involucradas en el proyecto. Esto incluyó la comunicación regular, la
identificación y gestión de las expectativas de las partes interesadas, y la resolución de cualquier conflicto o
problema que surgiera.
Eficacia del equipo central del proyecto en el cumplimiento de sus responsabilidades:
En general, el equipo central del proyecto demostró eficacia en el cumplimiento de sus responsabilidades.
Planificación y gestión del proyecto: El equipo central del proyecto realizó una planificación sólida y estableció un
cronograma realista para el proyecto. Se llevaron a cabo un seguimiento regular y una supervisión adecuada para
asegurar que el proyecto se mantuviera dentro de los plazos establecidos. Se asignaron y gestionaron
eficientemente los recursos necesarios para la ejecución del proyecto.
Coordinación de las partes interesadas: El equipo central del proyecto mantuvo una comunicación abierta y regular
con las partes interesadas, lo que permitió la alineación de expectativas y la gestión de cualquier conflicto o
problema de manera oportuna. Se tomaron medidas para garantizar que las partes interesadas estuvieran
informadas y comprometidas en todo momento.
Gestión del alcance: Se identificaron desafíos en la gestión del alcance del proyecto, particularmente en relación
con la identificación y gestión de cambios y requisitos adicionales. Se requirió un mayor enfoque en la evaluación y
la toma de decisiones para garantizar que los cambios y requisitos adicionales se abordaran de manera adecuada y
oportuna.
Distribución de responsabilidades: Hubo casos en los que la distribución de responsabilidades dentro del equipo
central del proyecto no fue óptima. Algunos miembros del equipo podrían haber asumido una carga de trabajo
desequilibrada o puede haber habido superposiciones en las responsabilidades. Una distribución de
responsabilidades más equitativa y clara habría mejorado la eficacia del equipo central del proyecto.
Fecha: 17/07/2023 77/ 89 Versión: 3.0

27. LECCIONES APRENDIDAS Y MEJORES PRÁCTICAS
Técnica:
Realizar una evaluación exhaustiva de las vulnerabilidades: Es importante realizar una evaluación completa de las
vulnerabilidades y riesgos potenciales relacionados con la inyección SQL antes de iniciar el proyecto. Esto ayuda a
comprender la magnitud del problema y a diseñar soluciones adecuadas.
Implementar medidas de seguridad multicapa: En lugar de depender únicamente de una solución de seguridad, se
recomienda implementar medidas de seguridad multicapa. Esto puede incluir la validación de entradas, el uso de
consultas parametrizadas y la adopción de mecanismos de autenticación y autorización adecuados.
Gobernanza:
Establecer una estructura de gobernanza clara: Es esencial establecer una estructura de gobernanza clara desde el
inicio del proyecto. Esto implica definir roles y responsabilidades, establecer procesos de toma de decisiones y
garantizar una comunicación efectiva entre todas las partes interesadas.
Involucrar a las partes interesadas relevantes: Asegurarse de que todas las partes interesadas relevantes estén
identificadas y participen activamente en el proyecto. Esto garantiza que se consideren diferentes perspectivas y
se tomen decisiones informadas.
Gestión de proyectos:
Planificar adecuadamente la gestión del alcance: La gestión del alcance debe ser una prioridad desde el inicio del
proyecto. Esto implica definir claramente los objetivos, los requisitos y los límites del proyecto, y establecer un
proceso sólido para gestionar los cambios y requisitos adicionales.
Establecer una comunicación efectiva: La comunicación clara y regular es fundamental para el éxito del proyecto.
Mantener a todas las partes interesadas informadas sobre el progreso, los hitos alcanzados y cualquier problema o
cambio en el proyecto. Utilizar múltiples canales de comunicación según las preferencias de las partes interesadas.
Gestión de riesgos:
Identificar y evaluar los riesgos de manera proactiva: Es importante realizar una identificación y evaluación
proactiva de los riesgos desde el inicio del proyecto. Esto permite la implementación de estrategias y planes de
mitigación adecuados para abordar los riesgos identificados.
Monitorear y revisar continuamente los riesgos: La gestión de riesgos es un proceso continuo a lo largo del
proyecto. Se debe establecer un mecanismo para monitorear y revisar regularmente los riesgos identificados, y
ajustar las estrategias y planes de mitigación según sea necesario.
Pasos siguientes para implementar mejoras:
Identificar oportunidades de mejora: Realizar una revisión exhaustiva del proyecto para identificar áreas donde se
pueden realizar mejoras. Esto puede incluir aspectos técnicos, de gobernanza, de gestión de proyectos y de gestión
de riesgos.
Priorizar las mejoras identificadas: Evaluar y priorizar las mejoras identificadas en función de su impacto potencial
y viabilidad de implementación.
Desarrollar un plan de implementación: Desarrollar un plan detallado que incluya los pasos específicos necesarios
para implementar cada mejora identificada. Establecer plazos, asignar responsabilidades y establecer métricas para
medir el éxito de la implementación.
Implementar las mejoras: Llevar a cabo la implementación de acuerdo con el plan desarrollado. Asegurarse de
realizar un seguimiento y una evaluación continua para verificar la efectividad de las mejoras implementadas.
Fecha: 17/07/2023 78/ 89 Versión: 3.0

28. RECOMENDACIONES POST-PROYECTO
Oportunidades de mejora y recomendaciones para el trabajo post-proyecto relacionadas con las operaciones del
producto/servicio en el contexto de la inyección SQL:
Sugerencias de actividades de seguimiento:
Auditoría de seguridad periódica: Realizar auditorías de seguridad periódicas para evaluar la efectividad y la
robustez del sistema implementado. Esto ayudará a identificar posibles brechas de seguridad y áreas de mejora.
Monitoreo continuo de la actividad de inyección SQL: Implementar un monitoreo continuo de la actividad de
inyección SQL para identificar y mitigar rápidamente cualquier intento de explotación. Esto puede incluir el uso de
herramientas de detección y análisis de registros.
Sugerencias de proyectos de seguimiento:
Mejora continua del sistema de seguridad: Realizar proyectos de seguimiento para mejorar y fortalecer aún más el
sistema de seguridad implementado. Esto puede incluir la implementación de nuevas tecnologías y prácticas de
seguridad, así como la actualización periódica de las defensas existentes.
Capacitación y concienciación en seguridad: Desarrollar proyectos de seguimiento enfocados en la capacitación y
concienciación de los usuarios finales y el personal de la organización en relación con la seguridad y la prevención
de la inyección SQL. Esto garantizará una comprensión continua de las mejores prácticas de seguridad y ayudará a
prevenir incidentes futuros.
Sugerencias de actividades de seguimiento relacionadas específicamente con la implementación en el negocio y el
cambio organizacional, y para verificar que se realizarán los beneficios previstos:
Evaluación periódica de los procesos de negocio: Realizar evaluaciones periódicas de los procesos de negocio
relacionados con la seguridad y la prevención de la inyección SQL. Identificar y abordar cualquier ineficiencia o área
de mejora en la implementación de estos procesos.
Medición y verificación de los beneficios previstos: Establecer métricas y realizar seguimiento para medir y verificar
los beneficios previstos de la implementación del sistema de seguridad. Esto puede incluir la comparación de los
datos de seguridad antes y después de la implementación, así como la evaluación de la eficacia de las medidas
preventivas implementadas.
Fecha: 17/07/2023 79/ 89 Versión: 3.0

29. LOGIN
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs"
Inherits="SQLINYECCION.Default" %>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<title></title>
</head>
<body>
<form id="form1" runat="server">
<div>
<input id="usuario" runat="server" type="text" placeholder="Usuario" />
<br />
<input id="password" runat="server" type="password" placeholder="Password" />
<br />
<asp:Button ID="btnIngresar" runat="server" Text="Ingresar" OnClick="btnIngresar_Click" />
</div>
</form>
</body>
</html>
Fecha: 17/07/2023 80/ 89 Versión: 3.0

30. PANTALLA DE ACCESO
<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Intranet.aspx.cs"
Inherits="SQLINYECCION.Intranet" %>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<title></title>
</head>
<body>
<form id="form1" runat="server">
<div>
<h1>BIENVENIDOOOOOOOOOOOOOOOOO</h1>
</div>
</form>
</body>
</html>
CONEXIÓN BASE DE DATOS Y CONDICIONES
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Data.SqlClient;
using System.Data;
namespace SQLINYECCION
{
public partial class Default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
protected void btnIngresar_Click(object sender, EventArgs e)

{
string user = usuario.Value, pass = password.Value;
using (SqlConnection cn = new
SqlConnection(System.Configuration.ConfigurationManager.ConnectionStrings["conDevelofer"].ConnectionString
.ToString()))
{
cn.Open();
string query = "Select * from Usuarios where Usuario='" + user + "'and Pass='" + pass + "'";
SqlCommand cmd = new SqlCommand(query, cn);
SqlDataReader dr = cmd.ExecuteReader();
Fecha: 17/07/2023 81/ 89 Versión: 3.0

bool userExist = false;
if (dr.Read())
{
userExist = true;
}
if (userExist)
{
Response.Redirect("Intranet.aspx", true);
}
else
{
ScriptManager.RegisterStartupScript(this, this.GetType(),
"alert",
"alert('Usuario o password incorrectos.');",
true);
return;
}
cn.Close();
}
}
}
}
<?xml version="1.0" encoding="utf-8"?>

<configuration>
<system.web>
<compilation debug="true" targetFramework="4.7.2" />
<httpRuntime targetFramework="4.7.2" />
</system.web>
<system.codedom>
<compilers>
<compiler language="c#;cs;csharp" extension=".cs"
type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider,
Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=2.0.1.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default
/nowarn:1659;1699;1701" />
<compiler language="vb;vbs;visualbasic;vbscript" extension=".vb"
type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider,
Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=2.0.1.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default /nowarn:41008
/define:_MYTYPE=\"Web\" /optionInfer+" />
</compilers>
</system.codedom>
<connectionStrings>
<add name="conDevelofer" connectionString="Data Source=DESKTOP-4B0EHJR;Initial
Catalog=Develofer;Integrated Security=true;"/>
</connectionStrings>
</configuration>
Fecha: 17/07/2023 82/ 89 Versión: 3.0

31. PROCESO DE REGUISTRO
Fecha: 17/07/2023 83/ 89 Versión: 3.0

32. INTERFAZ
Fecha: 17/07/2023 84/ 89 Versión: 3.0

33. CÁLCULO DE COSTOS
Costo del Proyecto= $10,000

Tempo total de Proyecto=12 Semanas
Semana 9
% Execution de Proyecto 80% de avance
AC=$4,800
Costo de Valor Ganado

EV=%Ejecución*Costo
EV=.80*$10,000
EV=$8,000
Costo de Valor Planeado

PV=%Plan*Presupuesto
PV=.74*$10,000
PV=$7,400
Costo de Valor de la Varianza

CV=EV-AC
CV=$8,000-$4800
CV=$3200
Calculo de Varianza de Cronograma

SV=EV-PV
SV=$8,000-$4,800
SV=$600
Es favorable para el Proyecto
Calculo de indices de desempeño de Costo

CPI=EV/AC
CPI=$8,000/$4,800
CPI=1.6
Calculo de Indices de Desempeño

SPI=EV/PV
SPI=$8,000/$7,400
SPI=1
Calculo de pronóstico estimado a la conclusion

EAC=BAC/CPI
EAC=$10,000/1.6
EAC=$6,250
Fecha: 17/07/2023 85/ 89 Versión: 3.0

34. ACTA DE CIERRE DE PROYECTO
Nombre del Proyecto
INYECCIÓN DE SQL
Justificación o Propósito
En este proyecto tiene como propósito definir las especificaciones funcionales, no funcionales para el
desarrollo de ataque de ciberseguridad que permitirá gestionar y autenticar al usuario. Desarrollado por
Ingenieros en formación de la carrera de Ingeniería en Redes Inteligentes y Ciberseguridad dirigido a la alta
dirección de la Universidad Tecnológica de Nezahualcóyotl.
Objetivo
Implementar un software para que mitigar ataques de inyección SQL booleano, limitar accesos a página web
vía intranet, mantener servicio de SQL activo, tener niveles de usuarios que permitirá limitar las
modificaciones a BD SQL.
Fecha: 17/07/2023 86/ 89 Versión: 3.0

Descripción
La inyección SQL que proporciona una visión general de la especificación de recursos sobre
el ataque de inyección booleana. Con el fin de conocer las principales funciones realiza, los
datos asociados y los factores, restricciones, supuestos y dependencias que afectan al
desarrollo, así como también la manera de mitigar dicho ataque.
Datos
Empresa / Organización NCrypto
Proyecto INYECCIÓN SQL
Fecha de inicio 10/07/2023
Cliente Universidad Tecnológica de Nezahualcóyotl
Patrocinador principal
Gerente de Proyecto Francisco Nicolas Ortiz
Patrocinador / Patrocinadores
Nombre Cargo Departamento /

División
Gerente Proyecto Administrativa
Subgerente Proyecto Administrativa
Ingeniero de Proyectos Ingeniería
Date: 17/07/2023 87 / 89 Version: 3.0

35. RAZÓN DE CIERRE
1) Fase 1: Inicio proyecto

o Inicio proyecto
o Diseño y revisión
2) Fase 2: Ejecución del proyecto
o Suministro de procura
o Montaje de sistema eléctrico
o Montaje sistema refrigeración
o Montaje de sistema seguridad
o Montaje de cableado estructurado
o Montaje, configuración y migración
o Adecuación del centro de control de red NOC
o Puesta en marcha
3) Fase 3: Entrega
o Pruebas y ajustes
Por medio de la presente, se da cierre formal al proyecto, por las razonesespecificadas en la siguiente
ficha:
Marcar con una “X” la razón de cierre:
Entrega de todos los productos de conformidad con losrequerimientos del cliente.

X
Entrega parcial de productos y cancelación de otros deconformidad con los

requerimientos del cliente. X
Cancelación de todos los productos asociados con el proyecto.

X
36. ACEPTACIÓN DE LOS PRODUCTOS O ENTREGABLES

A continuación, se establece cuales entregables de proyecto han sido aceptados:
Entregable Aceptación Observaciones

(Si o No)
Diseño y revisión Sí N/A
Montaje de sistema eléctrico Sí N/A
Montaje sistema refrigeración Sí N/A
Montaje de sistema seguridad Sí N/A
Montaje de cableado estructurado Sí N/A
Montaje, configuración y migración Sí N/A
Adecuación del centro de control de red NOC Sí N/A
Date: 17/07/2023 88 / 89 Version: 3.0

Para cada entregable aceptado, se da por entendido que:
• El entregable ha cumplido los criterios de aceptación establecidos en la

documentación de requerimientos y definición de alcance.
• Se ha verificado que los entregables cumplen los requerimientos.
• Se ha validado el cumplimiento de los requerimientos funcionales y decalidad
definidos.
• Se ha realizado la transferencia de conocimientos y control al áreaoperativa.
• Se ha concluido el entrenamiento que se definió necesario.
• Se ha entregado la documentación al área operativa.
Se autoriza al Gerente de Proyecto a continuar con el cierre formal del proyecto ofase, lo cual deberá
incluir:
• Evaluación post-proyecto o fase.

• Documentación de lecciones aprendidas.
• Liberación del equipo de trabajo para su reasignación.
• Cierre de todos los procesos de procura y contratación con terceros.
• Archivo de la documentación del proyecto.
Una vez concluido el proceso de cierre, el Patrocinador (Sponsor) del proyectodeberá ser notificado
para que el Gerente de Proyectos sea liberado y reasignado.
37. APROBACIONES
Fecha Firma
Patrocinador
Universidad Tecnológica de Nezahualcóyotl 11/07/2023
Date: 17/07/2023 89 / 89 Version: 3.0

ES (OPM2-01.I.TPL.v3.0.1) .Inyeccion A SQL. (20-05-2023) - (v3.0.) NCripto

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

ES (OPM2-01.I.TPL.v3.0.1) .Inyeccion A SQL. (20-05-2023) - (v3.0.) NCripto

Cargado por

Copyright:

Formatos disponibles

Organización: NCripto

Acta de Constitución del Proyecto

Esta plantilla está basada en PM² V3.0

Fecha: 17/07/2023 1/ 89 Versión: 3.0

11.2. Gestión de Incidencias .................................................................................................................... 19

14.2.2. Requisitos de Compatibilidad ............................................................................................... 50

Fecha: 17/07/2023 3/ 89 Versión: 3.0

24. TRANSICIÓN DEL PROYECTO. ............................................................................................................ 74

Fecha: 17/07/2023 4/ 89 Versión: 3.0

1. INFORMACIÓN DE CONTROL DEL DOCUMENTO

Aprobación y revisión del documento:

Jorge Montero Cruz Administrador de Investigación, Análisis, 08/05/2023

Fecha: 17/07/2023 5/ 89 Versión: 3.0

Revisión Fecha Creada por Breve descripción de los cambios

Gestión de la configuración: Localización del documento

Nombre del Proyecto: Inyección de SQL

Contexto / Situación (Necesidad de Negocio / Problema / Oportunidad)

Fecha: 17/07/2023 6/ 89 Versión: 3.0

Resultados (importancia alta)

Impacto (importancia alta)

Supuestos (importancia alta)

Fecha: 17/07/2023 7/ 89 Versión: 3.0

Restricciones (importancia alta)

Riesgos (importancia alta)

Fecha: 17/07/2023 8/ 89 Versión: 3.0

Fecha: 17/07/2023 9/ 89 Versión: 3.0

4. CONSIDERACIONES SOBRE EL CASO DE NEGOCIO

Fecha: 17/07/2023 10/ 89 Versión: 3.0

DESCRIPCIÓN DEL PROYECTO

Incluido ("dentro del" alcance)

1.2 Excluido ("fuera del" alcance)

1.3 Criterios de Éxito

1.4 Necesidades de las Partes Interesadas y de los Usuarios

ID Descripción de la Necesidad Prioridad

ID Nombre del Entregable Descripción del Entregable

Fecha: 17/07/2023 11/ 89 Versión: 3.0

Necesidad Característica Entregable

Detalles del del Respuesta al Acción

Riesgo Riesgo Riesgo4

5. COSTE, TIEMPO Y RECURSOS

1 Valor numérico que indica la probabilidad de ocurrencia del riesgo.

Aceptar / Mejorar / Compartir para riesgos positivos (oportunidades).

Fecha: 17/07/2023 12/ 89 Versión: 3.0

Desarrollo de la US$500 US$500

Date: 17/07/2023 13 /89 Doc. Versión: 3.0

1.11 Plazos e hitos

5.1 Inicio del proyecto 08/05/2023

5.2 Investigación de ataque BOOLEANO 10/05/2023

5.3 Revisión de script para página web 11/05/2023

5.5 Realizar documentación de avances de proyecto 15/07/2023

5.6 Entrega de avances Fase 1 17/08/2023

5.7 Mejoras en documentación encontradas en revisión Fase 1 20/08/2023

5.8 Inicio Implementación de Proyecto. 25/08/2023

5.9 Entrega de Avances de Fase 1 30/08/2023

1.12 Recursos Planificados

ID Recurso Requerido Descripción

6.1 Asesora sobre un tema en específico, sobre todo

6.2 Asesor legal También trabaja en el proyecto.

Fecha: 17/07/2023 14/ 89 Versión: 3.0

1.14 Gestión de Cambios

Cambio del Proyecto

Entregables del alcance del producto Autorizo

Fecha: 17/07/2023 15/ 89 Versión: 3.0