Tesis Upeu

UNIVERSIDAD PERUANA UNIN
ESCUELA DE POSGRADO
UNIDAD DE POSGRADO DE INGENIERA
UN MODELO PARA EL DESARROLLO DE

APLICACIONES WEB SEGURAS
Tesis presentada para optar el grado de Magster en Ingeniera de

Sistemas con mencin en Ingeniera de Software
Por:
Abel ngel Sulln Macalup
LIMA, PER
2014
DEDICATORIA
A mi amada esposa, Milva Gutierrez Quispe, por motivarme

constantemente en la investigacin y superacin acadmica.
A mi adorado hijo, Jarib, por su comprensin.
ii
AGRADECIMIENTOS
A Dios, por haberme conducido en la elaboracin de este proyecto.

A mi familia que es el motor de mi vida;
A mi asesor y a todas aquellas personas, quienes contribuyeron con sus aportes
relevantes en el desarrollo de la presente investigacin.
iii
NDICE GENERAL
DEDICATORIA ......................................................................................................... ii
AGRADECIMIENTOS .............................................................................................. iii
NDICE GENERAL .................................................................................................. iv
NDICE DE TABLAS ................................................................................................ ix
NDICE DE FIGURAS ............................................................................................... x
NDICE DE ANEXOS ............................................................................................... xi
RESUMEN............................................................................................................. xiii
ABSTRACT ........................................................................................................... xiv
CAPTULO 1 ..................................................................................................... 1
INTRODUCCIN ..................................................................................................... 1
CAPTULO 2 ..................................................................................................... 4
REVISIN BIBLIOGRFICA ................................................................................... 4
2.1
Marco conceptual .................................................................................................... 4
2.1.1
Modelo de procesos del software ................................................................... 4
2.1.2
Taxonoma de la seguridad .............................................................................. 4
2.1.3
Software ........................................................................................................... 7
2.1.4
Ingeniera del software .................................................................................... 7
2.1.5
Software como un servicio (SaaS) .................................................................... 7
2.1.6
Seguridad del software .................................................................................... 8
2.1.7
Aplicaciones web.............................................................................................. 8
2.1.8
Desarrollo web ................................................................................................. 8
2.1.9
Anlisis de riesgo.............................................................................................. 9
2.2
Revisin del estado del arte ..................................................................................... 9
2.2.1
Modelos de calidad del software en sintona con la Seguridad ...................... 9
2.2.2
Modelo de McGraw con la construccin de software seguro ....................... 12
2.2.3
SSE-CMM/ISO 21827, COBIT e ITIL en relacin a la seguridad del software . 13
2.2.4
Gua OWASP ................................................................................................... 19
2.2.5
Vulnerabilidades OWASP Top 10 ................................................................... 21
2.2.6
Microsoft SDL ................................................................................................. 23
2.2.7
SDL-Agile ........................................................................................................ 24
2.2.8
Sustainable software security process (S3P) ................................................. 25
2.2.9
Controles de seguridad de ISO 27001 ............................................................ 26
2.3
Procesos giles de desarrollo de software ............................................................ 29
2.3.1
Manifiesto gil................................................................................................ 29
iv
2.3.2
Marco general MSF-Agile ............................................................................... 30
2.3.3
Artefactos agile UP ......................................................................................... 32
2.3.4
Prcticas XP y TDD.......................................................................................... 33
2.3.5
Prcticas Scrum .............................................................................................. 36
CAPTULO 3 ....................................................................................................40
MATERIALES Y MTODOS ...................................................................................40
3.1
Lugar de ejecucin ................................................................................................. 40
3.2
Equipos y materiales .............................................................................................. 40
3.2.1
Equipos ........................................................................................................... 40
3.2.2
Software ......................................................................................................... 40
3.2.3
Servicios ......................................................................................................... 41
3.2.4
Material bibliogrfico ..................................................................................... 41
3.3
Tipo de investigacin ............................................................................................. 41
3.4
Indicadores de evaluacin de la propuesta ........................................................... 42
3.5
Diagrama de flujo de las actividades de la Investigacin....................................... 44
3.6
Cronograma de actividades ................................................................................... 46
3.7
Presupuesto y financiamiento del proyecto de tesis ............................................. 48
CAPTULO 4 ....................................................................................................50
CONSTRUCCIN DEL MODELO PARA EL DESARROLLO .................................50
DE APLICACIONES WEB SEGURAS ....................................................................50
4.1
Introduccin ........................................................................................................... 50
4.2
Diseo grfico del modelo propuesto.................................................................... 50
4.3
Principios de seguridad .......................................................................................... 51
4.3.1
Defensa en profundidad ................................................................................ 51
4.3.2
Privilegios especficos .................................................................................... 51
4.3.3
Estilo de codificacin simple pero robusto .................................................... 51
4.3.4
Seguimiento ................................................................................................... 52
4.4
Backend web seguro .............................................................................................. 52
4.5
Artefactos del backend web seguro ...................................................................... 54
4.5.1
Requisitos del sistema (o requisitos para el mdulo backend) ..................... 54
4.5.2
Registro de riesgos de seguridad (amenazas y vulnerabilidades). ................ 54
4.5.3
Registro de componentes de seguridad. ....................................................... 55
4.5.4
Arquitectura de la aplicacin ......................................................................... 55
4.5.5
Estndares de desarrollo................................................................................ 55
4.5.6
Mtodo de trabajo del equipo ....................................................................... 56

v
4.5.7
Prototipos principales .................................................................................... 56
4.5.8
Diseo del sistema (para la iteracin)............................................................ 57
4.6
Anlisis de riegos de seguridad .............................................................................. 57
4.7
Artefactos del anlisis de riesgos de seguridad ..................................................... 59
4.8
Implementacin de los componentes de seguridad .............................................. 59
4.9
Artefactos de la implementacin de los componentes de seguridad ................... 61
4.9.1
Producto funcional seguro ............................................................................. 61
4.10
Demostracin y validacin de la seguridad ........................................................... 61
4.11
Artefactos de la demostracin y validacin de la seguridad ................................. 62
4.11.1
4.12
Formulario de lecciones aprendidas .............................................................. 62
Resumen ................................................................................................................ 62
CAPTULO 5 ....................................................................................................64
VALIDACIN DEL MODELO PROPUESTO...........................................................64
WSM-DEV PARTE 1............................................................................................64
5.1
Introduccin ........................................................................................................... 64
5.2
Acerca del proyecto ............................................................................................... 64
5.2.1
Grupo InnOp Per .......................................................................................... 64
5.2.2
Proyecto UPeU-CONCYTEC 2013 ................................................................... 64
5.2.3
Qualpaca 1.0 .................................................................................................. 65
5.2.4
Materiales y mtodos .................................................................................... 65
5.3
Backend web seguro y la definicin del proyecto Qualpaca ................................. 66
5.4
Anlisis de riesgos de seguridad ............................................................................ 67
5.5
5.5.1
SQL inyection.................................................................................................. 68
5.5.2
Prdida de autenticacin y gestin de sesiones .................................... 68
5.5.3
Secuencia de comandos en sitios cruzados (XSS) ............................... 69
5.5.4
Referencia directa insegura a objetos ..................................................... 69
5.5.5
Configuracin de seguridad incorrecta .................................................... 71
5.5.6
Exposicin de datos sensibles .................................................................. 72
5.5.7
Ausencia de control de acceso a las funciones...................................... 73
5.5.8
Falsificacin de peticiones en sitios cruzados (CSRF) ......................... 74
5.5.9
Uso de componentes con vulnerabilidades conocidas ......................... 75
5.5.10
Redirecciones y reenvos no validados .......................................................... 75
5.5.11
Registro de sucesos incompletos ................................................................... 76
5.5.12
Datos incompletos ......................................................................................... 77

vi
5.5.13
Permisos inconsistentes................................................................................. 77
5.6
5.7
Resumen ................................................................................................................ 81
CAPTULO 6 ....................................................................................................82
VALIDACIN DEL MODELO PROPUESTO...........................................................82
WSM-DEV PARTE 2............................................................................................82
6.1
Introduccin ........................................................................................................... 82
6.2
Anlisis de riegos de seguridad .............................................................................. 82
6.3
6.4
6.5
Resumen ................................................................................................................ 84
CAPTULO 7 ....................................................................................................85
RESULTADOS Y DISCUSIN ...............................................................................85
7.1
Nuevo modelo prctico para desarrollar aplicaciones web seguras en el menor
tiempo. ............................................................................................................................... 85
7.2
Mdulo backend de administracin y configuracin de aplicaciones web tipo SaaS
con Django. ........................................................................................................................ 86
CAPTULO 8 ....................................................................................................87
CONCLUSIONES Y RECOMENDACIONES ..........................................................87
8.1
Conclusiones .......................................................................................................... 87
8.2
Recomendaciones .................................................................................................. 88
REFERENCIAS ......................................................................................................90
GLOSARIO .............................................................................................................94
ANEXOS..........................................................................................................96
Anexo 1 Matriz de consistencia del proyecto ................................................................. 96
Anexo A1 Requisitos del sistema .................................................................................... 97
Anexo A2 - Registro de riesgos de seguridad (amenazas y vulnerabilidades) ................... 98
Anexo A3 - Registro de componentes de seguridad .......................................................... 99
Anexo A4 Arquitectura de la aplicacin ........................................................................ 100
Anexo A5 Estndares de desarrollo .............................................................................. 101
Anexo A6 Mtodo de trabajo del equipo...................................................................... 102
Anexo A7 Prototipos principales ................................................................................... 104
Anexo A8 Diseo del sistema ........................................................................................ 105
Anexo A9 Formulario de lecciones aprendidas............................................................. 106
Anexo B1 Requisitos del Sistema (mdulo backend web seguro) ................................ 107
vii
Anexo B2 - Registro de riesgos de seguridad (amenazas y vulnerabilidades) ................. 109

Anexo B3 - Registro de componentes de seguridad ........................................................ 110
Anexo B4 Arquitectura de la aplicacin ........................................................................ 111
Anexo B5 Estndares de desarrollo .............................................................................. 112
Anexo B7 Prototipos principales ................................................................................... 113
Anexo B8 Diseo del sistema ........................................................................................ 140
Anexo B9 Formulario de lecciones aprendidas ............................................................. 169
Anexo B10 Lista de tareas de desarrollo del backend .................................................. 170
Anexo C1 Product backlog (requisitos del sistema) ...................................................... 172
Anexo C2 - Registro de riesgos de seguridad (amenazas y vulnerabilidades) ................. 174
Anexo C3 - Registro de componentes de seguridad ........................................................ 175
Anexo C4 Arquitectura de la aplicacin ........................................................................ 176
Anexo C5 Estndares de desarrollo .............................................................................. 177
Anexo C6 Mtodo de trabajo del equipo ...................................................................... 178
Anexo C7 Prototipos principales ................................................................................... 180
Anexo C8 Diseo del sistema ........................................................................................ 182
Anexo C9 Formulario de lecciones aprendidas ............................................................. 187
Anexo C10 Acta de constitucin del proyecto .............................................................. 188
Anexo C11 Sprint backlog ............................................................................................. 190
Anexo C12 Acta de conformidad del servicio o entrega ............................................... 193
Anexo C13 Manual del usuario ..................................................................................... 194
viii
NDICE DE TABLAS
Tabla 1 Taxonoma de requisitos de seguridad con ejemplos ................................ 5
Tabla 2 Sintona de la seguridad con los modelos de calidad .............................. 10
Tabla 3 Seguridad y SSE-CMM ........................................................................... 14
Tabla 4 Seguridad y COBIT, dominio planear y organizar ................................... 15
Tabla 5 Seguridad y COBIT, dominio adquirir e implementar............................... 16
Tabla 6 Seguridad y COBIT, dominio entrega y soporte ...................................... 16
Tabla 7 Seguridad e ITIL ..................................................................................... 17
Tabla 8 Los diez riesgos ms importantes en aplicaciones web 2013 ................. 21
Tabla 9 - Indicadores de evaluacin para el modelo propuesto .............................. 42
Tabla 10 - Cronograma de actividades ................................................................... 46
Tabla 11 - Presupuesto del proyecto ...................................................................... 48
Tabla 12 - Financiamiento del proyecto .................................................................. 49
ix
NDICE DE FIGURAS
Figura 1 Aspectos coincidentes entre SSE-CMM, COBIT e ITIL en relacin a la
seguridad del software ............................................................................................ 18
Figura 2 Ciclo de desarrollo seguro de OWASP .................................................. 20
Figura 3 Modelo de madurez de aseguramiento de software Open SAMM .......... 21
Figura 4 - Vista general del mtodo SDL ............................................................... 24
Figura 5 Ciclo de vida de SDL-Agile .................................................................... 24
Figura 6 - Vista general del mtodo S3P ................................................................. 25
Figura 7 Proceso de la norma ISO/IEC 27001:2005 ............................................ 26
Figura 8 Dominios de la norma ISO/IEC 27001:2005 .......................................... 27
Figura 9 Proceso de implementacin del SGSI utilizando la norma ISO/IEC
27001:2005 en el centro de cmputo de la ONP..................................................... 28
Figura 10 Principales tareas y actividades de MSF Agile ...................................... 31
Figura 11 Ciclo de vida Agile-UP ......................................................................... 32
Figura 12 Flujo para aplicar TDD ......................................................................... 35
Figura 13 Proceso Scrum .................................................................................... 38
Figura 14 Esquema de elaboracin de la propuesta ............................................ 41
Figura 15 Diagrama de flujo de las actividades de la investigacin ...................... 44
Figura 16 Diseo del modelo WSM-DEV ............................................................. 50
Figura 17 Modelo de autorizacin de usuarios ..................................................... 78
Figura 18 Modelo de autorizacin de usuarios de aplicaciones SaaS .................. 79
NDICE DE ANEXOS
Anexo 1 Matriz de consistencia del proyecto......................................... 96
Anexo A1 Requisitos del sistema........................................................... 97
Anexo A2 - Registro de riesgos de seguridad .. 98
Anexo A3 - Registro de componentes de seguridad ................................ 99
Anexo A4 Arquitectura de la aplicacin ................................................. 100
Anexo A5 Estndares de desarrollo ..................................................... 101
Anexo A6 Mtodo de trabajo del equipo ............................................... 102
Anexo A7 Prototipos principales ........................................................... 104
Anexo A8 Diseo del sistema ............................................................... 105
Anexo A9 Formulario de lecciones aprendidas .................................... 106
Anexo B1 Requisitos del Sistema (mdulo backend web seguro) ....... 107
Anexo B2 - Registro de riesgos de seguridad ... 109
Anexo B3 - Registro de componentes de seguridad ............................... 110
Anexo B4 Arquitectura de la aplicacin ................................................ 111
Anexo B5 Estndares de desarrollo ..................................................... 112
Anexo B7 Prototipos principales ........................................................... 113
Anexo B8 Diseo del sistema ............................................................... 140
Anexo B9 Formulario de lecciones aprendidas .................................... 169
Anexo B10 Lista de tareas de desarrollo del backend ......................... 170
Anexo C1 Product backlog (requisitos del sistema) ............................. 172
Anexo C2 - Registro de riesgos de seguridad .. 174
Anexo C3 - Registro de componentes de seguridad ................................ 117
Anexo C4 Arquitectura de la aplicacin ................................................ 176
Anexo C5 Estndares de desarrollo ..................................................... 177
Anexo C6 Mtodo de trabajo del equipo .............................................. 178
xi
Anexo C7 Prototipos principales............................................................. 180

Anexo C8 Diseo del sistema ................................................................ 182
Anexo C9 Formulario de lecciones aprendidas .................................... 187
Anexo C10 Acta de constitucin del proyecto........................................ 188
Anexo C11 Sprint backlog .................................................................... 190
Anexo C12 Acta de conformidad del servicio o entrega ........................ 193
Anexo C13 Manual del usuario .............................................................. 194
xii
RESUMEN
El propsito de esta investigacin es obtener un modelo prctico para el desarrollo

de aplicaciones web seguras y en el menor tiempo, basados en los procesos del
SSE-CMM/ISO 21827, las caractersticas de seguridad web de la OWASP 2013 y
experiencias vividas personalmente en el mbito de la seguridad web. El modelo
propuesto se basa en cuatro principios y cuatro prcticas de seguridad como son: la
implementacin preliminar de los componentes de seguridad para cada
vulnerabilidad ms recurrentes en aplicaciones web, el anlisis de riesgos de
seguridad en torno al negocio, la implementacin y pruebas de los componentes de
seguridad para recurrentes o nuevas vulnerabilidades y, la demostracin y validacin
de la seguridad. El modelo propuesto fue refinado y validado mediante la aplicacin
en el Proyecto QUALPACA patrocinado por CONCYTEC y la UPeU, mitigando las
vulnerabilidades al 92.30%, con una velocidad de 20 puntos mensual y una cobertura
del estilo de codificacin de un 90%.
Palabras claves: Seguridad web, SSE-CMM/ISO 21827, OWASP, Riesgo de
seguridad, Ataque, Vulnerabilidad.
xiii
ABSTRACT
The purpose of this research is to obtain a practical model for the development of
secure web applications in the shortest time, based on the processes of SSE-CMM /
ISO 21827, the characteristics of web security OWASP 2013 and experiences in
person at the field of web security. The proposed model is based on four principles
and four security practices such as: preliminary implementation of safety components
for increasingly recurrent vulnerability in web applications, analysis of security risks
around the business, implementation and testing safety components for recurrent or
new vulnerabilities, demonstration and validation of safety. The proposed model was
refined and validated by applying the QUALPACA Project sponsored by CONCYTEC
and UPeU, mitigating the vulnerabilities by 92.30% and a monthly velocity of 20 points
and a coding style coverage of 90%.
Keys words: Web Security, SSE-CMM/ISO 21827, OWASP, Security risk, Attack,
Vulnerability.
xiv
CAPTULO 1
INTRODUCCIN
En los ltimos aos, el inters en la seguridad del software se ha ido

incrementando, surgiendo muchas investigaciones sobre el tema, pero an falta
lograr la aplicacin e implementacin de estas investigaciones, lo cual deja abiertos
mbitos de trabajo en torno al tema (Tovar E y colaboradores, 2006).
Los errores de software representan una constante amenaza para los sistemas
de informacin, ya que provocan prdidas incontables en cuanto a la productividad.
La complejidad de los requisitos y el tamao cada vez mayores de los programas,
aunados a las exigencias de una entrega oportuna en los mercados, han contribuido
al incremento de fallas o vulnerabilidades de software (Laudon K y Laudon J, 2012).
La tendencia marcada de las plataformas de software como un servicio en lnea
(SaaS, por sus siglas en ingls) basado en la nube est desplazando a las
plataformas de software tradicionales. En el 2010, las empresas estadounidenses
invirtieron $29 millones de dlares (10 por ciento de la inversin total en software) en
SaaS (BEA National Income and Product Accounts, 2010 y Gartner Group, 2010
citado por Laudon K y Laudon J, 2012).
Siendo la seguridad de software, un aspecto que debe tener en cuenta tantos
mecanismos de seguridad como el diseo de la seguridad que dificulten los ataques
al software, debe ser considerada como una propiedad emergente de un sistema de
software e incorporarse desde el principio (Gasca G, 2006)
Estas vulnerabilidades se incrementan para las aplicaciones web debido al
entorno donde se ejecutan. Para alcanzar una aplicacin web segura es necesario
tener fundamentos slidos y la experiencia para la aplicacin de buenas prcticas de
seguridad desde las primeras etapas del ciclo de vida del desarrollo.
Por su parte, los frameworks de programacin web tradicionales, y an los
giles solo consideran la seguridad para vulnerabilidades bsicas como la proteccin
de recursos o carpetas del sistema basados en roles, dejando sueltos los problemas
de seguridad ms comunes de la web y de la nube, siendo necesaria un modelo
prctico que integre las buenas prcticas de seguridad en componentes de
1
seguridad, proporcionando un estilo de codificacin que muestre el uso de los

componentes de seguridad y otros utilitarios para el trabajo inicial y repetitivo de toda
aplicacin web enmarcados en un mdulo inicial, comnmente denominado el
mdulo backend, para as contrarrestar los riegos de la informacin que una
aplicacin maneja sobre la Internet. Esta estrategia permite asignar directamente las
tareas de desarrollo que el negocio requiere de modo que resulte simple, de menos
a ms y natural para el desarrollador.
El propsito de esta investigacin es elaborar un modelo de trabajo prctico
para desarrollar aplicaciones web seguras (menores vulnerabilidades) y en el menor
tiempo basadas en los procesos de la metodologa SSE-CMM/ISO 21827, el
Proyecto OWASP y experiencias vividas, proporcionando las plantillas de los
entregables para cada fase del modelo. La implementacin de los Componentes de
seguridad se desarroll para el lenguaje de programacin gil Python, liberndose la
primera versin de un backend de administracin de aplicaciones web totalmente
responsivas denominada Backengo (versin actual). Este mdulo integra los
recursos de seguridad y otros componentes necesarios para desarrollar una
aplicacin web moderna, confiable y en el menor tiempo.
A fin de ilustrar la contribucin del modelo propuesto, se presenta el caso de
su aplicacin en el Desarrollo del proyecto denominado Desarrollo de plataforma
tecnolgica en la web para la competitividad de la cadena productiva de alpacas en
la regin puno (Qualpaca) patrocinado por el Consejo Nacional de Ciencia,
Tecnologa e Innovacin del Per (CONCYTEC) y por la Universidad Peruana Unin
(UPeU) Filial Juliaca. Se determina si el equipo ejecut el modelo definido
correctamente y en qu medida se mejor la seguridad de la aplicacin.
Con un modelo de trabajo definido para el Desarrollo de Aplicaciones Web
Seguras permitir al equipo de desarrollo construir aplicaciones confiables y entregar
durante el primer mes funcionalidades importantes del negocio a los clientes junto
con la documentacin necesaria del proyecto.
El informe de tesis est compuesta por 8 captulos: en el captulo 1, se describe
la problemtica, la justificacin, el objetivo del trabajo de investigacin y la estructura
del documento de tesis. En el captulo 2, se revisa los antecedentes y se explica
brevemente la teora de las partes principales de esta tesis. En el Captulo 3, se
describe el mtodo utilizado y las herramientas para el desarrollo de la presente
investigacin. En el Captulo 4, se disea y se desarrolla el modelo de seguridad
propuesto. En el Captulo 5 y 6, se valida el modelo mediante el desarrollo de una
2
aplicacin web tipo SaaS. En el captulo 7 se presentan y se discuten los resultados

y en el Captulo 8, se detallan las conclusiones y recomendaciones realizadas al
presente trabajo de investigacin.
CAPTULO 2
REVISIN BIBLIOGRFICA
En este captulo se presenta los conceptos relativos a la calidad y seguridad

del software como premisas para la elaboracin de la propuesta de esta tesis. Otros
conceptos generales puede revisarse en el Glosario. Seguidamente se revisa las
investigaciones o modelos respecto a la seguridad del software y de aplicaciones
web entre ellos SSE-CMM y OWASP. Finalmente, se explica los mtodos giles de
desarrollo de software.
2.1
Marco conceptual
2.1.1
Modelo de procesos del software

Segn Somerville (2005), un modelo de procesos del software es una
descripcin simplificada de un proceso del software que presenta una visin de ese
proceso. Estos modelos pueden incluir actividades que son parte de los procesos y
productos de software y el papel de las personas involucradas en la ingeniera del
software.
2.1.2
Taxonoma de la seguridad
Bashir (citado por Vega V y otros 2006), clasifica el concepto de seguridad en
mltiples dimensiones, entre las que destacan:
Autentificacin: Verificar la identificacin de los usuarios, es decir, que quien

se est conectando sea quien dice ser.
Control de Acceso: Regulacin de los privilegios de los usuarios, que cada

usuario pueda realzar slo las tareas que le corresponden.
Auditoria: Capacidad de registrar los eventos que afectan al sistema, para que
posteriormente se pueda reconstruir los estados pasados del sistema.
Confidencialidad: Evitar que ciertas entidades no autorizadas puedan acceder

a informacin confidencial.
Integridad: Que la informacin no pueda ser modificada mediante

mecanismos no permitidos.
Disponibilidad: Asegurar que el sistema estar disponible cuando el usuario

lo requiera.
No repudiacin: Asegurar que alguna entidad que ha participado en una

comunicacin, no pueda negar su intervencin en ella.
Viega y McGraw (citado por Vega V y otros 2006), plantean los siguientes
objetivos de la seguridad:
Prevencin. Siempre se debe anticipar a las posibles fallas de seguridad.
Trazabilidad y Auditora. Una de las formas de recuperarse de un ataque es

conocer quin fue el atacante, qu hizo y cundo lo hizo.
Monitoreo.
Observar
monitorear
constantemente
el
software
en
funcionamiento, que permite detectar intrusiones.
Privacidad y confidencialidad. Mantener en secreto y bien resguardada la

informacin que maneja el sistema.
Multiniveles de seguridad. No toda la informacin requiere los mismos niveles

de seguridad, pero manejar esta diferencia no es una tarea difcil.
Administrar el anonimato. Este punto puede ser visto de dos aspectos, en

ocasiones es necesario que se mantenga el anonimato de los usuarios, pero
en otras ocasiones es primordial asegurar que no pueda existir anonimato en
las transacciones del sistema.
Autentificacin. Este objetivo, junto a la confiabilidad y la integridad, son

considerados los ms importantes. Al autentificacin es un aspecto crucial
para la seguridad, dado que permite identificar con certeza quin realiza qu
en un sistema.
Integridad. Esta meta busca controlar los cambios realizados en la

informacin
Una taxonoma sirve como herramienta de educacin y puede usarse como
lista de comprobacin para tomar decisiones preventivas de la seguridad. Una

aproximacin ms completa del concepto de seguridad est dada por la combinacin
de cuatro atributos principales: confidencialidad, integridad, disponibilidad y el no
repudio. La tabla 1 muestra una taxonoma de requisitos de seguridad
Tabla 1 Taxonoma de requisitos de seguridad con ejemplos
Nivel 1
Nivel 2
Ejemplo de requisito de seguridad
No repudio
No repudio
El sistema debe conocer al cliente

antes de realizar una compra.
Confidencialidad Encriptacin
Encriptar
usuarios
5
la
contrasea
de
los
Autenticacin
No se permite retirar dinero de su

cuenta
sin
que
este
se
haya
identificado.
Agregacin
No se permite que los cajeros

accedan al registro de ventas diarias.
Atribucin
El sistema deber registrar los datos

del usuario y los cambios cada vez
que actualice el registro de notas.
Deber
registrarse
realizados
en
los
cambios
el
acuerdo
previamente aprobados.
Consentimiento
No se permitir a los mdicos del

centro mdico a tener acceso a los
informes mdicos de un paciente a
menos que el paciente ha aprobado
el acceso
Concurrencia
No
se
permite
ms
de
dos
conexiones simultneos para un

usuario
Seguimiento
No
se
proveer
informacin
aquellos usuarios que previamente

han accedido a informacin de otra
organizacin del mismo conflicto de
inters.
Integridad
Edicin
La actualizacin del precio de venta

solo lo hace el contador
Eliminacin
El sistema no debe permitir la

eliminacin de artculos
Validacin de datos
Aceptar
solo
datos
numricos
positivos para el precio de venta de

los artculos
Manejo de
El sistema no deber mostrar el
excepciones
detalle del error al usuario.
Pre-requisitos
No se permite al usuario sacar dinero

de su cuenta antes de que el sistema
comprueba
la
disponibilidad
de
fondos
Separacin de roles
No permitir que el comprador utilice

la opcin de pagos del sistema
Disponibilidad
Tiempo de respuesta
Se
deber
proporcionar
la
informacin del estudiante para el

99% de sus solicitudes
Expiracin
Reducir el tiempo de solicitud de

conexin para tener tiempo de
espera de 1 minuto cuando el
nmero de solicitud de conexin es
superior a 10,000 por hora
Asignacin de
El tamao lmite de un archivo debe
recursos
ser de 10MB.
Fuente: Caldern M (2007)
2.1.3
Software
Segn Pressman (2004), el software es un elemento del sistema que es lgico,
como son las instrucciones (programas) quienes sern el medio de interaccin entre
el factor humano y el hardware correspondiente a un sistema de informacin.
2.1.4
Ingeniera del software

Segn Somerville (2005), la ingeniera del software es una disciplina de la
ingeniera que comprende todos los aspectos de la produccin del software desde
las etapas iniciales de la especificacin del sistema, hasta el mantenimiento de ste
despus de que se utiliza. En sntesis, la ingeniera de software no solo est dedicada
al desarrollo del software, sino tambin hacia diferentes etapas durante su ciclo de
vida.
2.1.5
Software como un servicio (SaaS)

Un software as a service, es un modelo de distribucin de software donde el
soporte lgico y los datos que maneja se alojan en servidores de una compaa de
tecnologas de informacin y comunicacin (TIC), a los que se accede va Internet
desde un cliente. La empresa proveedora TIC se ocupa del servicio de
mantenimiento, de la operacin diaria y del soporte del software usado por el cliente.
Regularmente el software puede ser consultado en cualquier computador, se
encuentre presente en la empresa o no. Se deduce que la informacin, el
7
procesamiento, los insumos, y los resultados de la lgica de negocio del software,

estn hospedados en la compaa de TIC.
2.1.6
Seguridad del software

Tovar E y colaboradores, 2006, afirma que la seguridad del software es una
idea de la Ingeniera de Software que busca que un producto desarrollado contine

funcionando correctamente ante ataques maliciosos, y puede ser vista como una
medida de robustez de un sistema de software, respecto a una poltica de seguridad.
Es decir, que la raz de muchos problemas de seguridad est en que el software falla
de forma inesperada.
La seguridad de un software es una combinacin de su capacidad para
asegurar la disponibilidad de la aplicacin, la integridad y confidencialidad de los
Datos. De esta forma, una falla del software en proteger cualquiera de esas
caractersticas implica una violacin de seguridad o vulnerabilidad (M-Tech Identity
Management Suite 2008).
2.1.7
Aplicaciones web
Las aplicaciones web son generalmente vistas en un browser. Una aplicacin
tiene 2 partes:
FrontEnd (Browser), es con lo que se encontrar el usuario final, esta interfaz
es el browser. El browser/navegador es clave ya que este nos puede dar la
posibilidad de crear aplicaciones complejas como tambin restringirnos (Internet
Explorer
6/7).
Las
aplicaciones
debern
estar
escritas
en
HTML/JS/CSS/AJAX/JQUERY/etc., o Flash/Flex, o Java FX, o Silverlight etc.

BackEnd (Server), es el motor de estas aplicaciones web y casi siempre utilizan
una base de datos para el almacenaje de datos. Los lenguajes de programacin son
variados en el backend, si el lenguaje de programacin puede generar un script
HTML entonces ya puede ser considerado un lenguaje web. Ejemplos: PHP, MySQL,
XML, JSON, etc.
2.1.8
Desarrollo web
Desarrollo Web es un trmino utilizado para definir todo el trabajo de creacin
de una pgina web. Desarrollo Web puede abarcar desde una simple pgina esttica
hasta aplicaciones web bastante ms complejas, tales como redes sociales como
facebook, pginas de e-commerce como ebay, aplicaciones mviles como google
maps, entre otros.
2.1.9
Anlisis de riesgo
El anlisis de riesgos, consiste en identificar los riesgos de seguridad en la
organizacin, determinar su magnitud e identificar las reas que requieren implantar

salvaguardas (INTECO, 2014).
El anlisis de riesgo, tiene como propsito determinar los componentes de un
sistema que requieren proteccin, sus vulnerabilidades que los debilitan y las
amenazas que lo ponen en peligro, con el fin de valorar su grado de riesgo. El anexo
A2 se muestra un ejemplo de la matriz de riesgos con sus principales caractersticas.
El anlisis del riesgo, es el uso sistemtico de la informacin para identificar las
fuentes y calcular o evaluar el riesgo (ISO 27001:2005)
Evaluacin del riesgo, es el proceso de comparar el riesgo estimado con un
criterio de riesgo dado para determinar la importancia del riesgo (ISO 27001:2005)
Amenaza, es una causa potencial de un incidente no deseado, el cual resulta
en dao a un sistema u organizacin (ISO 17799:2005)
Vulnerabilidad, es la debilidad de un activo que puede ser explotada por una o
ms amenazas (ISO 17799:2005)
Controles (o contramedidas o salvaguardas), son medios para manejar el
riesgo, incluyendo polticas, procedimientos, lineamientos, prcticas o estructuras
organizacionales, las cuales pueden ser administrativas, tcnicas, de gestin o de
naturaleza legal (ISO 17799:2005)
2.2
2.2.1
Revisin del estado del arte

Modelos de calidad del software en sintona con la Seguridad
La calidad es el grado en el que un conjunto de caractersticas inherentes
(propio) cumple con los requisitos o expectativa establecida (ISO 9000:2005).

La calidad total no es tan solo realizar las cosas bien hechas sino que es
mejorarlas constantemente, as el aseguramiento de calidad del software viene a ser
el conjunto de actividades de supervisin del desarrollo del software y de su
rendimiento (en distintas oportunidades durante cada fase del ciclo de vida) para
satisfacer los requisitos dados de calidad, siendo el equipo de desarrollo el
responsable por el resultado de calidad del software.
Gasca G, 2006, afirma que los modelos de calidad permiten precisar conceptos
dada la utilidad para planificar y obtener ndices de calidad, puesto que ayudan en la
puesta en prctica los conceptos generales por medio de definiciones de tipo
9
operacional. Considerando los diferentes enfoques de varios modelos de calidad, la

tabla 2 resume las caractersticas bajo los parmetros de la seguridad del software
de cada uno de ellos.
Tabla 2 Sintona de la seguridad con los modelos de calidad
Modelo de
Dimensin con la seguridad
Objetivos de seguridad
Modelo de
Comprendido por tres ejes, dentro
Aunque dentro de sus
McCall
de los que se encuentra la
objetivos la calidad del
operacin del producto, para el
software prima sobre
cual est establecido el factor
cualquier otro, la seguridad
integridad, nico factor dentro del
del software no se tiene en
modelo, que superficialmente
cuenta como un factor o
toma este concepto de seguridad.
caracterstica de la calidad
calidad o
estndar
que permita asegurar que

dicho modelo contempla de
forma efectiva la seguridad
del software.
Modelo de
La principal caracterstica del
Su objetivo est orientado
Boehm
modelo es su orientacin de la
al desarrollador, sin
calidad, sin embargo dentro de los
embargo dentro de los
siete factores definidos la
factores definidos la
seguridad est mnimamente
seguridad no se encuentra
mencionada, pero se resalta la
mencionada como un factor
definicin de un factor de la
de calidad aunque dentro
Facilidad de Pruebas ya que esta
de las caractersticas se
caracterstica es recomendable
plantea dentro de los
como una buena prctica del
conceptos bsicos como
desarrollo del software seguro.
confidencialidad e
integridad
Modelo de
Aunque es un modelo orientado a
El modelo no tiene definido
Gilb
la calidad industrial, los aspectos
dentro de sus objetivos y
que proponen son pasos amplios
fines la seguridad del
y con cierta flexibilidad para
software de forma
encontrar su aplicabilidad dentro
especfica, sin embargo;
10
de la seguridad y aplicarla al
por la generalidad de su
software.
propuesta, los aspectos

definidos permiten enfocar
la seguridad del software.
Paradigma
La valoracin de defectos es uno
El paradigma introduce
GQM
de los fines de este modelo, por lo
conceptos y aspectos tiles
tanto la seguridad est
sobre la seguridad del
involucrada desde una dimensin
software, sin embargo; esta
posterior a la que se quiere
caracterstica est siendo
plantear, la medicin dentro de
utilizada a posteriori y los
este paradigma se plantea
conceptos bajo los cuales
posterior a los defectos
se estudia la seguridad en
producidos.
este documento, invitan a

contemplar la seguridad en
etapas tempranas de ciclo
de vida de desarrollo de un
producto
Estndar ISO
El modelo define la calidad del
La seguridad del software
9126
software bajo caractersticas
est contemplada en el
como la funcionalidad dentro de la
modelo dentro de las
cual el concepto de seguridad se
caractersticas de
tiene en cuenta como un atributo
funcionalidad y la filosofa
importante para impedir acceso
del modelo canaliza el
no autorizado, fortuito o
planteamiento de calidad
deliberado, a programas y datos;
con una perspectiva de
que aunque no trasciende a los
seguridad ms amplia que
conceptos de seguridad
los modelos hasta ahora
relevantes para garantizar un
mencionados, de forma que
desarrollo de software seguro, el
este estndar apoya la
estndar involucra la seguridad
implementacin de buenas
dentro de su estructura.
prcticas dentro del

desarrollo de software
seguro.
Modelo CMM
La representacin por etapas del
Es un modelo que
modelo permite tener una
suministra a las
representacin continua y flexible
organizaciones una
11
de acercamiento a la mejora de
orientacin eficaz para
procesos. Esta representacin
establecer el proceso de
organiza las reas de proceso en
mejora de sus programas,
cinco niveles de madurez para
pero dentro de su filosofa;
apoyar y guiar el proceso de
el aspecto de seguridad
mejora; sin embargo
est levemente inmerso
especficamente el manejo de la
como una sub-
seguridad se encuentra
caracterstica de la calidad.
diseminado en todas las etapas y

carece de la profundidad
necesaria para garantizar los
procesos de desarrollo de
software seguro.
Modelo
Contiene una estructura
El modelo contempla los
SPICE
compuesta por nueve partes y su
procesos de software y
filosofa es determinar la
considera las iniciativas de
capacidad de los procesos y
estandarizacin existentes
mejora de los mismos en el marco
como el caso de CMM,
de las caractersticas de calidad,
construido por especialistas
por lo cual la seguridad est
que han trabajado con
dentro de este concepto, sin
mtodos y normas
embargo como los dems
existentes, pero dentro de
modelos, su enfoque no define
su objetivo general; no se
dimensiones de seguridad
encuentra la seguridad del
necesarias para el desarrollo de
software especficamente.
software seguro.
Fuente: Gasca G (2006)
2.2.2
Modelo de McGraw con la construccin de software seguro

McGraw (citado por Vega V y otros 2006), indica que la base de los problemas
de seguridad son la conectividad, la complejidad y la extensibilidad de los sistemas

actuales. La afirmacin anterior se refiere a que actualmente la mayora de los
productos de software estn disponibles en un medio tan abierto como internet
(conectividad), y adems estos mismos productos son parte de sistemas complejos
que apoyan objetivos de negocios que no son simples ni aislados (complejidad) y que
al mismo tiempo estos objetivos de negocios deben irse adecuando a los constantes
cambios que exigen los mercados actuales (extensibilidad). Como resultado de lo
12
anterior, los problemas de seguridad del software se han ido incrementando, llegando
en ocasiones, incluso a poner en riesgo el xito y sobrevivencia de las
organizaciones.
Los aspectos de seguridad en la ingeniera de software, van ms all de la
construccin del producto y trascienden dentro del proceso de software, de ah que
la preocupacin de diferentes organizaciones expresen el inters por crear y
proponer estndares, metodologas y mtodos que contemplan la seguridad desde
el punto de vista del proceso y la enmarquen como una caracterstica de calidad del
software importante para su desarrollo, es el caso del planteamiento de la norma ISO
9126, un estndar internacional para la evaluacin de la calidad de productos de
software, con el nombre Information Technology Software Product Evaluation
Quality Characteristics and Guidelines for their use.
Bajo esta misma perspectiva, y teniendo en consideracin que los productos
software son parte del inventario de tecnologa de la informacin que las
organizaciones poseen, el presente trabajo analiza el modelo SSE-CMM y OWASP
para determinar un modelo base y las vulnerabilidades existentes para el desarrollo
de aplicaciones web seguras.
2.2.3
SSE-CMM/ISO 21827, COBIT e ITIL en relacin a la seguridad del

software
Tovar E y colaboradores, 2006, analizaron los modelos SSE-CMM, COBIT E
ITIL para determinar cmo se enlazan y reafirman las propuestas existentes para el
desarrollo de productos de software seguro.
Systems Security Engineering Capability Maturity Model (SSE-CMM/ISO
21827), es un modelo de referencia para la incorporacin de la Ingeniera de
Seguridad en las organizaciones. SSE-CMM divide la ingeniera de seguridad en tres
reas bsicas: riesgo, ingeniera y aseguramiento. La relacin de estas reas con el
objetivo del presente artculo est dada por los siguientes argumentos:
Riesgo, busca identificar y priorizar los peligros asociados al desarrollo de

productos o sistemas.
Ingeniera, trabaja con otras disciplinas para implementar soluciones a los

peligros identificados, en este caso, se relaciona con la Ingeniera de
Software.
13
Aseguramiento,
tiene
como
objetivo
certificar
que
las
soluciones
implementadas son confiables.

El modelo se estructura en dos dimensiones: Dominios y capacidades. Un
dominio es un conjunto de prcticas bsicas que definen la ingeniera de seguridad,
mientras que una capacidad se refiere a las prcticas genricas que determinan la
administracin del proceso e institucionalizan la capacidad. Existen veintids reas
de proceso que contienen ciento veintinueve prcticas bsicas. La tabla 3 destaca
las reas de procesos que apoyan el desarrollo de software seguro.
Tabla 3 Seguridad y SSE-CMM
rea de proceso
Aporte a la seguridad del software
PA03. Valoracin de
El conocimiento adquirido en esta rea de proceso
riesgos de seguridad
puede ser utilizado para el desarrollo del anlisis de

riesgos que pueden afectar al software, prctica
recomendada para el desarrollo de productos seguros
PA10. Especificar
Esta rea de proceso puede ser utilizada en la
necesidades de
Ingeniera de Requerimientos de Seguridad, para
seguridad
determinar los aspectos de seguridad que deben ser

incorporados al nuevo producto
PA11. Verificacin y
Puede utilizarse para la generacin de pruebas de
Validacin de la
seguridad que deben aplicarse a los productos
Seguridad.
software
PA17. Definir el Proceso
Aporta en la definicin de procesos claros que
de Ingeniera de Sistemas
incorporan la seguridad en todas las dimensiones
organizacional.
PA18. Mejorar el Proceso
SSE-CMM define 5 niveles de madurez, por lo cual, la
de Ingeniera de Sistemas
mejora de los procesos debe ser continua para
organizacional.
alcanzar el siguiente nivel, lo que puede ser un aporte

en la incorporacin gradual de prcticas de desarrollo
de software seguro
Fuente: Tovar E y colaboradores (2006)

Control Objetives for Information and related Technology (COBIT). El objetivo
de este framework es organizar y armonizar distintos estndares internacionales,
relacionados con la administracin de la Tecnologa de la Informacin en las
14
organizaciones. COBIT presenta un conjunto de mejores prcticas, enfocadas en el

control ms que en la ejecucin, que permiten optimizar la inversin en TI que una
organizacin realiza. Este modelo define un conjunto de criterios de control, en base
a requisitos de calidad, confianza y seguridad.
Dado que los sistemas de informacin, y sus productos software asociados,
son parte de los bienes tecnolgicos que una organizacin posee, por lo tanto, existe
una relacin y aporte entre la administracin de la TI y las propuestas de desarrollo
para software seguro.
Este modelo se organiza en funcin de cuatro dominios, los que a su vez se
dividen en procesos formados de actividades especficas, que definen los objetivos
de control que una organizacin debera implementar. Las tablas 4, 5 y 6 (Una por
cada dominio de inters) muestran los procesos especficos a considerar durante la
implementacin de software.
Tabla 4 Seguridad y COBIT, dominio planear y organizar
rea de proceso
PO6. Comunicar las
Dado que la incorporacin de prcticas especficas para
aspiraciones y
el desarrollo de software seguro debe ser un compromiso
directrices de la
de todo el equipo, este proceso puede ayudar a que la
Administracin.
Administracin defina explcitamente polticas de

seguridad y su compromiso con la calidad
PO8. Administrar la
Este conocimiento es un aporte, dado que la seguridad
Calidad.
es un atributo de calidad de los productos software, por lo

cual deben existir estndares de desarrollo que
incorporen los objetivos de seguridad desde etapas
tempranas
PO9. Valoracin y
Es un aporte para la aplicacin de la prctica de anlisis
administracin de
de riesgo, recomendada para la seguridad del software
riesgos.
15
Tabla 5 Seguridad y COBIT, dominio adquirir e implementar

rea de proceso
AI2. Adquirir y
Todo el conocimiento y experiencia de este proceso puede
mantener
ser utilizado y complementado con las nuevas propuestas de
aplicaciones
desarrollo de software seguro
software.
AI7. Instalacin y
Relacionado con los procedimientos de aceptacin de los
acreditacin de
nuevos productos, puede aportar a explicitar las pruebas de
soluciones y
seguridad
cambios.
Tabla 6 Seguridad y COBIT, dominio entrega y soporte
rea de proceso
DS2.Administracin Este punto puede ser complementado con normas y

de servicios
controles explcitos para el momento exteriorizar el
prestados por
terceros.
DS5. Garantizar la
Es muy importante que se declare explcitamente la
seguridad de los
preocupacin por la seguridad, lo cual es un aporte a todas
sistemas.
las nuevas propuestas de seguridad del software.
DS10.
Los problemas de fallas de seguridad de software son parte
Administracin de
del conocimiento histrico que todos los desarrolladores de
problemas.
software de la organizacin deberan tener a su disposicin,

de manera tal, de evitar la repeticin de errores cometidos,
en este aspecto, se debe aprovechar este proceso COBIT

Information Technology Infraestructure Library (ITIL), ofrece un marco comn
para todas las actividades del departamento TI, como parte de la provisin de
servicios, basado en la infraestructura tecnolgica. Estas actividades se dividen en
procesos, que proporcionan un marco eficaz para lograr una Gestin de Servicios de
Tecnologas de la Informacin ms madura. Proporciona una descripcin detallada
de una serie de buenas prcticas, a travs de una amplia lista de roles, tareas,
16
procedimientos y responsabilidades que pueden adaptarse a cualquier organizacin

de TI.
Los procesos que esta librera describe, bajo los cuales muestra que son
requeridos para el manejo eficiente y efectivo de la infraestructura tecnolgica,
existen aquellos que velan por la disponibilidad de los activos de informacin como
requiere la organizacin y los dems que apoyan y facilitan la gestin de funciones y
actividades de seguridad como el tratamiento y solucin de problemas,
implementacin de controles y polticas necesarias dentro de la organizacin. Por lo
tanto la Tabla 7, de forma general, se presentan la relacin entre el modelo que
plantea ITIL y los aspectos que se consideran ms relacionados con la seguridad,
teniendo en cuenta que ITIL suministra un conjunto extenso y coherente de buenas
prcticas para la direccin del servicio de informtica y los procesos relacionados,
promoviendo un enfoque de calidad para conseguir la eficacia de la empresa y la
eficiencia en el uso de TI, por lo tanto dentro de dicha calidad hacia la eficacia se
encuentra contemplada la seguridad.
Tabla 7 Seguridad e ITIL
Librera
Soporte del Servicio: En
Permiten la implementacin de controles de
los aspectos
seguridad con el fin de mantener los aspectos
relacionados con la
tecnolgicos de la organizacin, lo cual podra ser
Gestin de Incidentes y
adaptado para el desarrollo de software
Gestin de Problemas
Provisin del Servicio: En
Influyen de forma directa con los objetivos de
cuanto a los aspectos de
seguridad, cuando se definen dentro de la
Gestin de Disponibilidad
organizacin y se asegura la demanda que requiere
y Gestin de Continuidad
el negocio en cuanto a los activos tecnolgicos que
de Servicios.
tiene y requiere para el desempeo de sus

actividades. Esto es un aporte dado que los
productos software son un activo tecnolgico.
Tanto como SSE-CMM, COBIT e ITIL, incorporan la seguridad desde distintas

perspectivas, algunas de las cuales son coincidentes y otras complementarias. A
partir de estas singularidades y similitudes se puede determinar una definicin
multidimensional de la seguridad en relacin al desarrollo de software.
17
Tovar E y colaboradores (2006), concluyen que los problemas de seguridad no

se solucionan incorporando mecanismos de proteccin externos al producto de
software, ms bien, para conseguir que un producto de software sea seguro durante
su explotacin y vida til, se deben considerar durante su desarrollo las siguientes
dimensiones:
Proceso utilizado para el desarrollo del producto.
Factores humanos relacionados con las habilidades y conocimientos que

deben poseer los equipos desarrolladores.
Prcticas organizacionales declaradas e instauradas que deben respetarse y

aplicarse, y
Productos obtenidos, para cada uno de los cuales se debe realizar una
rigurosa validacin y verificacin que cumple con los estndares y requisitos
de seguridad declarados
La figura 1 esquematiza los puntos coincidentes entre los modelos en relacin
al desarrollo de software seguro y las dimensiones identificadas.
Definicin prcticas de
seguridad
Necesidad de
definicin
Modelos software
Niveles de madurez
SSE-CMM
COBIT
ITIL
Administracin
productos software
Definicin explcita
requerimientos de
seguridad
Figura 1 Aspectos coincidentes entre SSE-CMM, COBIT e ITIL en relacin a

la seguridad del software.
18
El aspecto coincidente en todos los modelos, es el planteamiento de lo

importante que es que las organizaciones declaren explcitamente los requerimientos
de seguridad que apoyarn el logro de sus objetivos de negocio. Esto debe ir
acompaado de prcticas de seguridad bien definidas, conocidas, respetadas y
aplicadas por todos los integrantes de la organizacin.
Los modelos COBIT y SSE-CMM definen un conjunto de prcticas que
deberan tenerse en consideracin. Este aspecto aporta a la dimensin de Prcticas
Organizacionales definida previamente. Tanto SSE-CMM como COBIT plantean la
necesidad que existan procesos de desarrollo de software que estn claramente
definidos. Este aspecto ayuda a la dimensin Proceso mencionada previamente. Las
organizaciones interesadas en incorporar esta dimensin, deben aplicar las
propuestas existentes respecto al desarrollo de software seguro.
Los modelos COBIT e ITIL, aportan a la dimensin Producto, desde la
perspectiva que ambos definen cmo administrar los productos correspondientes a
TI. La dimensin de Factores Humanos, se ve beneficiada por el modelo SSE-CMM,
donde se presentan una serie de procesos que deberan ser desarrollados en las
organizaciones para incorporar la seguridad, justificando la necesidad de que existan
Ingenieros de Seguridad, que trabajen en conjunto a los otros dominios de la
Ingeniera, en especial con los Ingenieros de Sistemas e Ingenieros de Software.
El modelo SSE-CMM, plantea la existencia de distintos niveles de madurez que
puede alcanzar una organizacin en relacin a sus prcticas de seguridad, aspecto
que influye en las cuatro dimensiones de seguridad planteadas.
2.2.4
Gua OWASP
El proyecto abierto de seguridad en aplicaciones web (OWASP por sus siglas
en ingls) ofrece un punto de partida para identificar riesgos en el desarrollo de

sistemas y asegura que aplicaciones hechas a medida o adquiridas complementen
con COBIT. Los controles de OWASP corresponden a los objetivos COBIT y de la
ISO 17799 (OWASP, 2005).
OWASP ofrece dos publicaciones base: la Gua para construir aplicaciones
Web seguras y OWASP Top 10, as mismo ofrece los software WebGoat basada en
Java diseada para ensear lecciones de seguridad en aplicaciones Web a travs
de lecciones en las que se simulan vulnerabilidades en un servidor, WebScarab
escrito en Java diseada para analizar aplicaciones web que se comunica usando
los protocolos HTTP y HTTPS, oLabs Projects, y el .Net Projects. Tambin provee un
conjunto de libreras de seguridad empresariales en Java denominada OWASP
19
ESAPI, en total para la versin del 2008 provee 49 proyectos de ms de 300 pginas
cada una de ellas (OWASP, 2008).
Fernndez J. (2006), explica el ciclo de desarrollo de aplicaciones y servicios
Web seguras con OWASP mediante la figura 2.
Figura 2 Ciclo de desarrollo seguro de OWASP

Fuente: Fernndez J (2006)
OWASP se basa en la ISO 17799 y COBIT para disear los controles de

seguridad que debe ser incluido en la aplicacin, estos requisitos de seguridad los
modela como casos de abuso como se muestra en la figura 4, desligndolo de los
procesos de negocio. Luego se realiza un anlisis de riesgos junto a los planes de
pruebas. Luego de disear la seguridad se procede a la codificacin. Una vez
construida se ejecutan las pruebas y se realiza nuevamente un anlisis de riesgos
identificando nuevos problemas de seguridad antes del despliegue.
Por su parte, el modelo abierto de madurez para el aseguramiento del software
(SAMM por sus siglas en ingls) es una gua ms de OWASP para integrar la
seguridad en el desarrollo de software. Como modelo de madurez, provee recursos
para evaluar las prcticas de seguridad en software existentes en la organizacin
entre otros recursos relacionados a la seguridad del software. El modelo SAMM se
muestra en la figura 3.
20
Figura 3 Modelo de madurez de aseguramiento de software Open SAMM

Fuente: Open SAMM (2010)
El modelo consta de tres niveles de madurez definidos para cada una de las
doce prcticas de seguridad. Estas definen una amplia variedad de actividades a las
que una organizacin se puede adherir para reducir los riesgos de seguridad e
incrementar el aseguramiento del Software. Se incluyen detalles adicionales para
medir el desempeo exitoso de las actividades, entender los beneficios del
aseguramiento asociado, estimar los costos de personal y otros costos.
2.2.5
Vulnerabilidades OWASP Top 10

OWASP (2013), public las 10 vulnerabilidades ms frecuentes de las
aplicaciones y servicios Web, estas se muestran en la tabla 8.

Tabla 8 Los diez riesgos ms importantes en aplicaciones web 2013
Vulnerabilidad
A1 Inyeccin
Descripcin
Las fallas de inyeccin, tales como SQL, OS, y LDAP,
ocurren cuando datos no confiables son enviados a un
intrprete como parte de un comando o consulta. Los datos
hostiles del atacante pueden engaar al intrprete en
ejecutar comandos no intencionados o acceder datos no
autorizados.
A2 Prdida de
Las funciones de la aplicacin relacionadas a autenticacin
autenticacin y
y gestin de sesiones son frecuentemente implementadas
gestin de sesiones
incorrectamente, permitiendo a los atacantes comprometer

contraseas, llaves, token de sesiones, o explotar otras
fallas de implementacin para asumir la identidad de otros
usuarios.
21
A3 Secuencia de
Las fallas XSS ocurren cada vez que una aplicacin toma
comandos en sitios
datos no confiables y los enva al navegador web sin una
cruzados (XSS)
validacin y codificacin apropiada. XSS permite a los

atacantes ejecutar secuencia de comandos en el navegador
de la vctima los cuales pueden secuestrar las sesiones de
usuario, destruir sitios web, o dirigir al usuario hacia un sitio
malicioso.
A4 Referencia
Una referencia directa a objetos ocurre cuando un
directa insegura a
desarrollador expone una referencia a un objeto de
objetos
implementacin interno, tal como un fichero, directorio, o

base de datos. Sin un chequeo de control de acceso u otra
proteccin,
los
atacantes
pueden
manipular
estas
referencias para acceder datos no autorizados.

A5 Configuracin de
Una
buena
seguridad
implementada una configuracin segura para la aplicacin,
incorrecta(defectuosa
marcos de trabajo, servidor de aplicacin, servidor web,
configuracin de
base de datos, y plataforma.
seguridad, 2010)
Todas
estas
seguridad
requiere
configuraciones
tener
deben
ser
definida
definidas,
implementadas, y mantenidas ya que por lo general no son

seguras por defecto. Esto incluye mantener todo el software
actualizado, incluidas las libreras de cdigo utilizadas por la
aplicacin.
A6 Exposicin de
Muchas aplicaciones web no protegen adecuadamente los
datos sensibles
datos
(almacenamiento
credenciales de autenticacin con mecanismos de cifrado o
criptogrfico
hashing. Atacantes pueden modificar o robar tales datos
inseguro, 2010)
protegidos inadecuadamente para conducir robos de
sensibles,
tales
como
tarjetas
de
crdito
identidad, fraudes de tarjeta de crdito u otros crmenes.

A7 Ausencia de
Muchas aplicaciones web verifican los privilegios de acceso
control de acceso a
a URLs antes de generar enlaces o botones protegidos. Sin
las funciones (falla de
embargo, las aplicaciones necesitan realizar controles
restriccin de acceso
similares cada vez que estas pginas son accedidas, o los
a URL, 2010)
atacantes podrn falsificar URLs para acceder a estas

pginas igualmente.
A8 Falsificacin de
Un ataque CSRF obliga al navegador de una vctima
peticiones en sitios
autenticada a enviar una peticin HTTP falsificado,
cruzados (CSRF)
incluyendo la sesin del usuario y cualquier otra informacin

22
de autenticacin incluida automticamente, a una aplicacin

web vulnerable. Esto permite al atacante forzar al navegador
de la vctima para generar pedidos que la aplicacin
vulnerable piensa son peticiones legtimas provenientes de
la vctima.
A9 Uso de
Algunos componentes tales como las libreras, los
componentes con
frameworks y otros mdulos de software casi siempre
vulnerabilidades
funcionan con todos los privilegios. Si se ataca un
conocidas
componente vulnerable esto podra facilitar la intrusin en el

servidor o una perdida seria de datos. Las aplicaciones que
utilicen
componentes
con
vulnerabilidades
conocidas
debilitan las defensas de la aplicacin y permiten ampliar el

rango de posibles ataques e impactos.
A10 Redirecciones y
Las aplicaciones web frecuentemente redirigen y reenvan a
reenvos no validados
los usuarios hacia otras pginas o sitios web, y utilizan datos

no confiables para determinar la pgina de destino. Sin una
validacin apropiada, los atacantes pueden redirigir a las
vctimas hacia sitios de phishing o malware, o utilizar
reenvos para acceder pginas no autorizadas.
Fuente: OWASP Top 10 (2013)
2.2.6
Microsoft SDL
El mtodo de Microsoft, denominado Ciclo de Vida de Desarrollo Seguro [SDL]
del 2004, es un proceso para el desarrollo de software que tiene que resistir el ataque
malvolo de un intruso. El proceso consiste de una serie de actividades de seguridad:
El desarrollo de modelo de amenaza durante el diseo de software.
El empleo de instrumentos de exploracin de cdigo de anlisis estticos.
Las pruebas de seguridad durante la integracin de seguridad.
La revisin final de seguridad por un equipo independiente.
La integracin de las medidas de seguridad descritas por el mtodo SDL se

muestra en la Figura 4.
23
Security training
Security
Security
design
Kickoff
best
Create
development
security
Prepare
Security
tools &
documenta
security
push
security best
tion an
response
Threat
dev, test
tools for
plan
modeling
practices
product
Security
Architecture
practices
Requirements
Use security
Design
Implementation
Security
service
and
response
Pen
execution
testing
Verification
Release
Support
Figura 4 - Vista general del mtodo SDL

Fuente: Ardi S y Shahmehri N (2008)
En este proceso, durante la fase de requerimientos, el equipo de proyecto y el
de seguridad colaboran en la planificacin del proceso. En el diseo dividen en fases:
Diseo de la seguridad, la arquitectura de seguridad y el modelado de amenaza. En
la implementacin, se aplican los estndares de codificacin y pruebas. En la
verificacin, incluyen revisiones de cdigo de seguridad, as como la realizacin de
pruebas de seguridad. En la fase de lanzamiento, el software es sujeto a una
seguridad final y luego estar listo a ser entregado. Segn el SDL, despus del
despliegue, el equipo debe estar preparado para responder a vulnerabilidades recin
descubiertas en el producto de software. Esto es no siempre una solucin aceptada
por organizaciones. SDL recomienda el apoyo de seguridad a la fase de
mantenimiento pero no es claro como este apoyo es realizado y como nuevas
vulnerabilidades son descubiertas y mitigadas. En otras organizaciones requiere el
reemplazo completo del proceso de desarrollo. (Ardi S y Shahmehri N, 2008).
2.2.7
SDL-Agile
A diferencia del SDL clsico, donde todos estos requisitos deben ser
completados antes de que el producto sea liberado, en SDL Agile slo uno de los
requisitos de cada cubo se debe completar en cada sprint. Esta es la concesin que
SDL Agile hace a los horarios de liberacin ms corto de los proyectos de desarrollo
Agile. Como se suele decir, no puede caber diez libras de harina en una bolsa de
cinco libras, y los requisitos del cubo son los cinco kilos de ms que se ha sacado.
La figura 5 muestra el flujo de de trabajo del mtodo SDL Agile.
The every-sprint requirements
Security verification bucket
Design review bucket
Response planing bucket
Threat model
Fuzz file inputs
Review crypto design
Disaster recovery plan
Use validate request
Run AppVerif
Privacy review
Update response contacts
And so on
And so on
And so on
And so on
Figura 5 Ciclo de vida de SDL-Agile

Fuente: Microsoft (2011)
24
Sin embargo, a pesar de que los equipos de producto no son necesarios para
completar todos los requisitos del cubo en cada sprint, eso no significa que se puede
omitir de forma indefinida. De hecho, los equipos tienen que completar cada uno de
los requisitos del cubo por lo menos una vez al ao. Adems, los equipos se les
prohbe completar el requisito de mismo cubo en dos carreras en una fila. Por
ejemplo, si el equipo del proyecto X elige para completar un anlisis de la superficie
de ataque para satisfacer sus requisitos de verificacin de seguridad para su cubo
de marzo de sprint, que no puede completar otro anlisis de la superficie de ataque
en abril. Ms concretamente, se podra completar otro anlisis de la superficie de
ataque en abril si de verdad quera, sin embargo, simplemente no podra satisfacer
su compromiso de SDL.
Aparte de esas dos limitaciones, los equipos son libres de elegir lo que quieren
los requisitos del cubo para completar en cualquier sprint dado. SDL Agile no obliga
a ningn tipo de orden de seleccin de requerimiento. Este producto ofrece a los
equipos la mxima flexibilidad en la eleccin de las actividades de seguridad que se
encuentran ms tiles.
2.2.8
Sustainable software security process (S3P)

Ardi S y Shahmehri N (2008) desarrollaron el mtodo denominado proceso
sostenible de software seguro [S3P], creando un plug-in para integrar la seguridad

en el proceso de desarrollo de software para el OpenUP/Basic. Este proceso provee
criterios para la identificacin de las causas de las vulnerabilidades y tcnicas de
mitigacin que previenen estas vulnerabilidades. La integracin del S3P con el
OpenUP se muestra en la figura 6.
Figura 6 - Vista general del mtodo S3P

Fuente: Ardi S y Shahmehri N (2008)
El S3P consiste en tres pasos principales: comienza con el modelo de
vulnerabilidades basadas en un anlisis cuidadoso de vulnerabilidades de software
para identificar las causas. Los resultados de este anlisis son usados en el segundo
25
paso para identificar las tcnicas de mitigacin que eliminan las causas de las
vulnerabilidades. Las tcnicas de mitigacin entonces son usadas en el tercer paso
para definir componentes de proceso de desarrollo en forma de actividades para ser
aplicadas en el desarrollo. El S3P mejora el proceso de desarrollo previniendo la
repeticin de problemas de seguridad y vulnerabilidades, almacenndolos en una
base de datos de vulnerabilidades que proporciona la informacin sobre las clases
de vulnerabilidades y tipos de errores generales; el S3P puede ser aplicado en el
proceso OpenUP
2.2.9
Controles de seguridad de ISO 27001

La ISO/IEC 27001 es la nica norma internacional auditable que define los
requisitos para un sistema de gestin de la seguridad de la informacin (SGSI). La

norma se ha concebido para garantizar la seleccin de controles de seguridad
adecuados y proporcionales. Ello ayuda a proteger los activos de informacin y
otorga confianza a cualquiera de las partes interesadas, sobre todo a los clientes. La
norma adopta un enfoque por procesos para establecer, implementar, operar,
supervisar, revisar, mantener y mejorar un SGSI (ISO 27001, 2005).
Para la implementacin del SGSI, la ISO 27001 adopta la metodologa PDCA
mostrado en la figura 7.
Figura 7 Proceso de la norma ISO/IEC 27001:2005

Fuente: ISO 27001 (2005)
El objetivo de la fase de planificacin (Plan) es establecer las polticas,
objetivos, los procedimientos y los controles de seguridad descrito en la ISO/IEC
27001 previo anlisis y gestin de riesgos de los activos de informacin. En fase de
ejecucin (Do), bsicamente se manejan los recursos asignados para el SGSI para
llevar a cabo la gestin de riesgos y la puesta en marcha los controles de seguridad
de la informacin seleccionados en la fase de planificacin. En fase de monitoreo
(Check), se miden la efectividad y el xito de los controles implantados para verificar
26
que se hayan cumplido los requerimientos de seguridad. Por ello, es muy importante
contar con registros e indicadores que provengan de estos controles. En esta fase
tambin se identifican nuevos riesgos, se evala la efectividad de la poltica, costes
y cambios tecnolgicos. La ltima fase, es la fase de mejora (Act), donde se llevan a
cabo las labores de mantenimiento del sistema. Si durante la fase anterior se ha
detectado algn punto dbil, este es el momento de corregirlo o mejorarlo a travs
de la implementacin de medidas correctoras, preventivas y de mejora identificada
en el SGSI.
Puyo R. (2009), Oficial de seguridad de la Oficina de Normalizacin Previsional
[ONP] del Per, afirma que la buena aplicacin de la norma requiere una adaptacin
a la organizacin. Consecuentemente, la figura 8 y la figura 9 muestran la adaptacin
de la metodologa ISO 27001 a la ONP.
Figura 8 Dominios de la norma ISO/IEC 27001:2005

Fuente: Puyo R. (2009)
27
Figura 9 Proceso de implementacin del SGSI utilizando la norma ISO/IEC

27001:2005 en el centro de cmputo de la ONP
Fuente: Puyo R. (2009)
La implementacin y certificacin del SGSI del centro de cmputo de la ONP
basado en la norma ISO/IEC 27001 se llev a cabo en ms de dos aos (564 das
tiles): del 07 de enero del 2007 hasta el 09 de febrero del 2009. Un ao para la
implementacin y operacin, un ao para el mantenimiento y mejora y ms de medio
ao para la auditora interna y el logro de la certificacin por parte de la BSI. Se
necesit el esfuerzo directo de 3 personales de la ONP y 6 consultores, y de la
participacin indirecta de 15 personales de la ONP y 14 consultores externos.
Logrando sobre todo un sistema de gestin de seguridad de la informacin alineado
a los objetivos institucionales. Cabe mencionar que los principales factores de xito
fueron la disponibilidad del personal de ONP, una rpida accin ante las
observaciones del auditor, el constante compromiso de los responsables directos del
proyecto SGSI, la metodologa de implementacin personalizada a ONP y la
dedicacin de 100% del equipo consultor al proyecto.
Piero B. (2009), asegura que la serie ISO 27000 reemplaza a la ISO 17799 y
a UNE 71502. Al mismo tiempo define la serie 27000 como sigue:
27000: Definiciones y trminos de seguridad de la informacin
27001: Implantacin del SGSI (Certificable) evolucin de BS-7799-2 y

equivale a UNE 71502
27002: Transcripcin de ISO 17799:2005, catlogo de buenas

prcticas.
27003: Gua de implementacin.

28
2.3
27004: Indicadores y mtricas.
27005: Gestin y evaluacin de riesgos.
Procesos giles de desarrollo de software

Este apartado se describe los mtodos de desarrollo gil de software MSF Agile
las prcticas de la programacin extrema (XP, por sus siglas en ingls), las prcticas
del Desarrollo dirigido por pruebas (TDD, por sus siglas en ingls) y los principios,
conceptos y prcticas de Scrum.
2.3.1
Manifiesto gil
Beck K y Colaboradores (2001), definieron los principios sobre los que se basan
los mtodos alternativos, de desarrollo gil de software en cuatro postulados o

valores, lo que ha quedado denominado como manifiesto gil:
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentacin extensiva
Colaboracin con el cliente sobre negociacin contractual
Respuesta ante el cambio sobre seguir un plan

Juntamente con estos valores se redactaron los siguientes principios derivados
de estos valores:
Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana

y continua de software con valor.
Aceptamos que los requisitos cambien, incluso en etapas tardas del

desarrollo. Los procesos giles aprovechan el cambio para proporcionar
ventaja competitiva al cliente.
Entregamos software funcional frecuentemente, entre dos semanas y dos

meses, con preferencia al periodo de tiempo ms corto posible.
Los responsables de negocio y los desarrolladores trabajamos juntos de

forma cotidiana durante todo el proyecto.
Los proyectos se desarrollan en torno a individuos motivados. Hay que darles

el entorno y el apoyo que necesitan, y confiarles la ejecucin del trabajo.
El mtodo ms eficiente y efectivo de comunicar informacin al equipo de

desarrollo y entre sus miembros es la conversacin cara a cara.
El software funcionando es la medida principal de progreso.

29
Los procesos giles promueven el desarrollo sostenible. Los promotores,

desarrolladores y usuarios debemos ser capaces de mantener un ritmo
constante de forma indefinida.
La atencin continua a la excelencia tcnica y al buen diseo mejora la

agilidad.
La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es

esencial.
Las mejores arquitecturas, requisitos y diseos emergen de equipos autoorganizados.

A intervalos regulares el equipo reflexiona sobre cmo ser ms efectivo para a
continuacin ajustar y perfeccionar su comportamiento en consecuencia.

2.3.2
Marco general MSF-Agile

Microsoft solution framework (MSF) es la metodologa empleada por Microsoft
para el desarrollo de software. Esta es una metodologa flexible e interrelacionada

con una serie de conceptos, modelos y prcticas de uso, que controlan la
planificacin, el desarrollo y la gestin de proyectos tecnolgicos.
MSF se centra en los modelos de proceso y de equipo dejando en un segundo
plano las elecciones tecnolgicas. El marco MSF se asienta sobre unos principios
fundamentales que definen la cultura del entorno de desarrollo:
1. Fomentar la comunicacin abierta.
2. Trabajar en torno a una visin compartida.
3. Motivar a los integrantes del equipo.
4. Establecer responsabilidades claras y compartidas.
5. Centrar el objetivo en la entrega de valor para el negocio.
6. Permanecer giles y esperar al cambio.
7. Invertir en calidad.
8. Aprender de la experiencia.
El MSF es un conjunto integrado y configurable de procesos de desarrollo de
software, principios y prcticas probadas. En el Microsoft Visual Studio 2005 Team
System proporciona por defecto 2 plantillas configurables de la metodologa MSF:
MSF for Agile Software Development, MSF for CMMi Process Improvement.
30
Meier J y Colaboradores (2007), afirman que la plantilla gil de MSF-Agile

contienen las ideas claves del movimiento gil de software, junto con los principios y
prcticas de MSF clsico para CMMI. El proceso apoya una estrategia de ingeniera
de software gil que utiliza mltiples iteraciones y un enfoque basado en escenarios
para la creacin de aplicaciones. La plantilla proporciona la automatizacin y la
orientacin necesaria para apoyar a su equipo de desarrollo, incluida la gestin de
configuracin, gestin de proyectos, seguimiento de elementos de trabajo, y un portal
del proyecto para la comunicacin.
La plantilla de MSF-Agile define un conjunto de tareas a realizar durante las
iteraciones de los roles que intervienen en un ciclo de vida de desarrollo de software
incluyendo analistas de negocio, arquitectos, jefes de proyecto, desarrolladores y
probadores. La figura 10 muestra las principales actividades asociadas a cada una
de las tareas definidas.
Figura 10 Principales tareas y actividades de MSF-Agile

Fuente: Meier J y Colaboradores (2007)
31
Cuando se crea un nuevo proyecto de equipo utilizando la plantilla de MSFAgile proceso, una pgina de conceptos delineando la orientacin del proceso se
muestra en la ventana principal de Microsoft Visual Studio . Este es su punto de
vista inicial en el proceso de MSF-Agile. Tambin puede acceder a esta informacin
desde la pgina principal del portal del proyecto.
La configuracin de la herramienta va mucho ms all de la descripcin del
proceso e incluye los elementos de trabajo (tales como escenarios, calidad del
servicio, las tareas, los insectos, y los riesgos), los informes del proyecto, los roles
(grupos y permisos), y un portal del proyecto. Elementos clave proporcionados por la
plantilla de MSF-Agile incluyen:
Los elementos de trabajo
Grupos y permisos de cdigo fuente
Las reas y las iteraciones
Informes
Portal
2.3.3
Artefactos agile UP
El proceso unificado gil (AUP) es un desarrollo de programas basado en el
Proceso Unificado Racional (RUP) de IBM, es decir, el AUP es una versin

simplificada de RUP que incorpora tcnicas de desarrollo giles.
La figura 11
muestra el ciclo de vida del AUP.
Figura 11 Ciclo de vida Agile UP

Fuente: Scott W. (2005)
AUP mantiene las fases del RUP: Inicio, donde se identifica el alcance inicial
del proyecto, una potencial arquitectura para el sistema, se obtiene financiamiento
para el proyecto y aceptacin de los involucrados. Elaboracin, donde se prueba la
arquitectura del sistema, se hace un prototipo de arquitectura que elimine los riesgos
32
tcnicos para probar que el proyecto es factible. Construccin, donde se implementa

el software sobre una base incremental la que debe estar relacionada con los
objetivos de los involucrados. Y la transicin, donde se valida y se entrega el sistema
en un ambiente de produccin.
Sin embargo se han quitado varias disciplinas quedando las disciplinas de:
Modelo, donde se disean lo los procesos de negocios de la organizacin, el dominio
de problema que puede ser abordado por el software, y se identifica una solucin
viable. Implementacin, donde los diagramas del modelo se transforma en cdigo
ejecutable y se aplican pruebas bsicas en unidades particulares de prueba. Prueba,
donde se realiza una evaluacin objetiva para asegurar la calidad. Esto incluye
encontrar defectos, validar que el sistema funcione como fue diseado, y verificar
que los requerimientos estn abordados por las funcionalidades. Despliegue,
donde se planifica la entrega del sistema y se lleva a cabo el plan para que el sistema
est disponible para los usuarios. Administracin de la configuracin, donde
se
administra el acceso a los artefactos del proyecto. Esto no solo incluye el
seguimiento de las versiones de los artefactos, sino tambin controlar y administrar

los cambios sobre ellos. Administracin del proyecto, donde se dirige las actividades
que forman parte del proyecto. Esto incluye administracin de riesgos, dirigir
personas y coordinar personas con sistemas que estn fuera del alcance del
proyecto. Y la disciplina del ambiente, donde se facilita todo el entorno que permita
el normal desarrollo del proyecto (Scott W, 2005).
Los artefactos UP que necesita un mtodo gil son: El diagrama de procesos
del negocio, los diagramas de clases del sistema, el diseo de la base de datos y las
interfaces de usuario.
2.3.4
Prcticas XP y TDD
Palacio J (2005), afirma que el Extreme Programming (XP) surge sobre la
suposicin de que es posible desarrollar software de gran calidad a pesar, o incluso

como consecuencia del cambio continuo. Su principal asuncin es que con un poco
de planificacin, un poco de codificacin y unas pocas pruebas se puede decidir si
se est siguiendo un camino acertado o equivocado, evitando as tener que echar
marcha atrs demasiado tarde. Los valores que inspiran XP son:
Comunicacin, pone en comunicacin directa y continua a clientes y

desarrolladores. El cliente se integra en el equipo para establecer prioridades y
resolver dudas. De esta forma ve el avance da a da, y es posible ajustar la
agenda y las funcionalidades de forma consecuente
33
Feedback rpido y continuo, una metodologa basada en el desarrollo incremental

de pequeas partes, con entregas y pruebas frecuentes y continuas, proporciona
un flujo de retro-informacin valioso para detectar los problemas o desviaciones.
o
De esta forma fallos se localizan muy pronto.
La planificacin no puede evitar algunos errores, que slo se evidencian

al desarrollar el sistema.
La retro-informacin es la herramienta que permite reajustar la agenda y

los planes.
Simplicidad, consiste en desarrollar slo el sistema que realmente se necesita.

Implica resolver en cada momento slo las necesidades actuales. Los costes y la
complejidad de predecir el futuro son muy elevados, y la mejor forma de acertar
es esperar al futuro. Con este principio de simplicidad, junto con la comunicacin
y el feedback resulta ms fcil conocer las necesidades reales
Coraje, implica saber tomar decisiones difciles. Reparar un error cuando se

detecta. Mejorar el cdigo siempre que tras el feedback y las sucesivas
iteraciones se manifieste susceptible de mejora. Tratar rpidamente con el cliente
los desajustes de agendas para decidir qu partes y cundo se van a entregar.
XP no es un modelo de procesos ni un marco de trabajo, sino un conjunto de
12 prcticas que se complementan unas a otras y deben implementarse en un

entorno de desarrollo cuya cultura se base en los cuatro valores citados:
Prcticas de codificacin
o
Simplicidad de cdigo y de diseo para producir software fcil de

modificar.
Reingeniera contina para lograr que el cdigo tenga un diseo ptimo.
Desarrollar estndares de codificacin, para comunicar ideas con claridad

a travs del cdigo.
Desarrollar un vocabulario comn, para comunicar las ideas sobre el

cdigo con claridad.
Prcticas de desarrollo
o
Adoptar un mtodo de desarrollo basado en las pruebas para asegurar

que el cdigo se comporta segn lo esperado.
34
Programacin por parejas, para incrementar el conocimiento, la

experiencia y las ideas.
Asumir la propiedad colectiva del cdigo, para que todo el equipo sea
responsable de l.
Integracin continua, para reducir el impacto de la incorporacin de

nuevas funcionalidades.
Prcticas de negocio
o
Integracin de un representante del cliente en el equipo, para encauzar

las cuestiones de negocio del sistema de forma directa, sin retrasos o
prdidas por intermediacin.
Adoptar el juego de la planificacin para centrar en la agenda el trabajo

ms importante.
Entregas regulares y frecuentes para satisfacer la inversin del cliente.
Ritmo de trabajo sostenible, para terminar la jornada cansado pero no

agotado.
Yepes R y Chavarra R (2010), afirman que para un buen feedback, los equipos
XP requieren buenas prcticas de testing. Estos equipos practican test-driver
development (TDD) en pequeos ciclos en los que primero agregan un test y luego
escriben el cdigo fuente necesario para pasar dicho test. De esta manera los
equipos producen cdigo fuente con cerca del 100% de cobertura. La figura 12 ayuda
a entender estos conceptos.
Figura 12 Flujo para aplicar TDD

Fuente: Yepes R y Chavarra R (2010)
35
Los test son ejecutados en forma conjunta. Cuando los desarrolladores liberan
cdigo al repositorio, cada uno de los test deben pasar satisfactoriamente, lo que
significa que los desarrolladores tendrn un feedback inmediato a cerca de cmo
estn haciendo su trabajo. Esta comprobacin se puede realizarse de forma manual
o automatizada, interesando la segunda en lo que respecta a TDD.
Las pruebas unitarias, son realizadas a un componente individual de software.
Generalmente son dirigidas para probar los mtodo de una clase, buscando exactitud
a la hora de identificar rpidamente cuales instrucciones estn fallando en un
escenario determinado. Mientras que las pruebas de integracin, son realizadas a
dos o ms componentes o a todos los componentes de un software como un todo.
Aunque los test unitarios pueden dar la certeza que cada componente por separado
pueda estar funcionando correctamente, es muy probable que durante la interaccin
real con sus dependencias haya problemas que nicamente son detectados con los
test de integracin.
As el anlisis de cdigo y pruebas unitarias pueden validar que los cambios de
cdigo mitigan la vulnerabilidad expuesta por el defecto de cdigo identificado
previamente.
2.3.5
Prcticas Scrum
Schwaber K y Sutherland J (2010), autores de Scrum, definen que Scrum se
basa en la teora de control emprico del proceso, emplea un enfoque iterativo

incremental para optimizar la previsibilidad y controlar los riesgos. Existen tres pilares
que sostienen toda implementacin del control emprico de procesos.
El primer pilar es la transparencia, la transparencia garantiza que los aspectos
del proceso que afectan al resultado, son visibles para aquellos que administran dicho
resultado. Estos aspectos no slo deben ser transparentes, sino tambin conocidos.
Es decir, cuando alguien que inspecciona un proceso cree que algo est hecho, esto
debe ser equivalente a su definicin de "hecho".
El segundo pilar es la inspeccin, se deben inspeccionar con la frecuencia
suficiente los diversos aspectos del proceso para que puedan detectarse variaciones
inaceptables en el mismo. La frecuencia de inspeccin debe tener en cuenta que
todos los procesos se cambian por el propio acto de inspeccin. El dilema se presenta
cuando la frecuencia de inspeccin requerida excede la tolerancia del proceso a ser
inspeccionado. Afortunadamente, esto parece no aplicar al desarrollo de software. El
otro factor es la habilidad y la diligencia de la gente que inspecciona los resultados
del trabajo.
36
Y el tercer pilar es la adaptacin, si el inspector determina, a travs de la

inspeccin, que uno o ms aspectos del proceso estn fuera de los lmites
aceptables, y que el producto resultante ser inaceptable, debe ajustar el proceso o
el material procesado. El ajuste debe realizarse lo ms rpidamente posible para
minimizar una desviacin mayor.
Hay tres puntos para la inspeccin y la adaptacin en Scrum. La reunin diaria
de Scrum se utiliza para inspeccionar el avance hacia la meta de Sprint, y para hacer
las adaptaciones que optimicen el valor de la jornada de trabajo del da siguiente.
Adems, la revisin de sprint y las reuniones de planificacin se utilizan para
inspeccionar el progreso hacia el objetivo (la liberacin de una versin) y para hacer
las adaptaciones que optimicen el valor del siguiente Sprint. Por ltimo, la
retrospectiva de sprint se utiliza para revisar el sprint pasado y determinar qu
adaptaciones harn el siguiente sprint ms productivo, satisfactorio y agradable.
El marco de Scrum se compone de un conjunto de equipos Scrum y sus roles
asociados; as como de bloques de tiempo, artefactos, y reglas.
Los equipos Scrum estn diseados para optimizar la flexibilidad y la
productividad, para lo cual, son auto-gestionados, multifuncionales, y trabajan en
iteraciones. Cada equipo Scrum tiene tres roles: 1) el Scrum master,
que es
responsable de asegurar que el proceso es comprendido y seguido, 2) el Propietario

del producto, que es responsable de maximizar el valor del trabajo realizado por el
equipo Scrum, y 3) el equipo, que hace el trabajo. El equipo est formado por
desarrolladores con todos los conocimientos necesarios para convertir los
requerimientos del Propietario del producto en un incremento potencialmente
utilizable del producto al final del sprint.
Scrum emplea bloques de tiempo para crear regularidad. Los elementos de
Scrum basados en bloques de tiempo son: la reunin de planificacin de la entrega,
la reunin de planificacin del sprint, el sprint, el Scrum diario, la revisin del sprint,
y la retrospectiva del sprint. El corazn de Scrum es un sprint, que es una iteracin
de un mes de duracin o menos. La duracin de cada sprint se mantiene constante
a lo largo de todo el esfuerzo de desarrollo. Todos los sprints utilizan el mismo marco
de referencia de Scrum, y proporcionan un incremento de funcionalidad
potencialmente utilizable al producto final. Cada sprint se inicia inmediatamente
despus del anterior.
Scrum emplea cuatro Artefactos principales. El product backlog es una lista
priorizada de todo lo que podra ser necesario en el producto. El sprint backlog es
una lista de tareas para convertir el product backlog correspondiente a un sprint, en
37
un incremento del producto potencialmente entregable. Un burndown es una medida

del backlog restante a travs del tiempo. Un burndown de versin mide el product
backlog restante durante el tiempo correspondiente a una liberacin de una versin.
Un sprint burndown mide los elementos restantes del sprint backlog en el transcurso
de un sprint.
Las Reglas sirven de unin para los bloques de tiempo, los roles y los artefactos
de Scrum.
Palacio J (2011), define a Scrum como un mtodo de gestin y control para
complementar la aplicacin de otros mtodos giles como XP que, centrados en
prcticas de tipo tcnico, carecen de ellas.
Los principios de Scrum son:
Equipos autogestionados.
Una vez dimensionadas las tareas no es posible agregarles trabajo extra.
Reuniones diarias en las que los miembros del equipo se plantean 3 cuestiones:
Qu has hecho desde la ltima revisin?
Qu obstculos te impiden cumplir la meta?
Qu vas a hacer antes de la prxima reunin?
Iteraciones de desarrollo de frecuencia inferior a un mes, al final de las cuales se

presenta el resultado a los externos del equipo de desarrollo, y se realiza una
planificacin de la siguiente iteracin, guiada por cliente.
La figura 13 muestra el mtodo Scrum y el ciclo de vida de desarrollo gil de
software.
Figura 13 Proceso Scrum

Fuente: Palacio J (2011)
38
Scum denomina Sprint a cada iteracin de desarrollo y segn las

caractersticas del proyecto y las circunstancias del sprint puede determinarse una
duracin desde una hasta dos meses, aunque no suele ser recomendable hacerlos
de ms de un mes. El sprint es el ncleo central que proporciona la base de desarrollo
iterativo e incremental que recibe como entrada la pila de producto (product backlog).
39
CAPTULO 3
MATERIALES Y MTODOS
En este captulo se describe los materiales empleados y se explica el proceso

seguido para obtener un modelo de desarrollo web seguro.
3.1
Lugar de ejecucin
Esta investigacin se realiz en el campus de la Universidad Peruana Unin
Filial Juliaca, del departamento de Puno.

3.2
Equipos y materiales
Los equipos y materiales empleados para la realizacin de la presente
investigacin son:
3.2.1
Equipos
3.2.2
Laptop i5 (incluye windows 7)
Software
Microsoft Word 2010. Redaccin de la tesis.
Enterprise Architect 7.x. Diseo de sistemas mediante diagramas UML.
Balsamiq 2.x. Diseo de prototipos de pginas web
Python 2.7.x. Lenguaje de programacin gil
Django 1.5.x. Framework para el desarrollo de aplicaciones web.
SublimeText 2. Editor de cdigo fuente.
Git 2.x. Software para sincronizar repositorio locales.
Jenkins CI. Software de integracin contina.
Nginx 1.4.x. Servidor web para proyectos Django
Firefox 34.0.5 y firebug. Para la ejecucin de pginas web y, el anlisis

esttico del cdigo y depuracin de errores respectivamente.
40
3.2.3
SQLite 3 y MySQL 5. Gestores de base de datos
Bootstrap 2.x. Frontend responsivo para aplicaciones web.
Servicios
Acceso a internet. Para la bsqueda de informacin y el desarrollo

colaborativo.
Github. Servicio en la nube para la codificacin colaborativa
Assembla. Servicio en la nueve para el gerenciamiento del proyecto de

Qualpaca aplicando Scrum.
3.2.4
Impresiones y Fotocopias
Material bibliogrfico
Laudon K, Laudon J. 2012. Sistemas de informacin gerencial. 12 ed.

Mxico: Pearson educacin. 640 p. ISBN 978-607-32-0949-6
3.3
Tipo de investigacin
La presente investigacin es de tipo evaluativa aplicada. Ya que evala los
modelos SSE-CMM/ISO-21827 y OWASP. Estos modelos son combinados con

experiencias vividas para obtener un nuevo modelo para desarrollar aplicaciones web
seguras y luego fue aplicado en un proyecto real con la finalidad de refinar el modelo
propuesto y mejorar las buenas prcticas de desarrollo seguro de aplicaciones web.
El esquema de los procesos de la presente investigacin se muestra en la
figura 14.
METODOLOGAS BASE DE
SEGURIDAD DEL
SOFTWARE: SSECMM/ISO 21827, OWASP
METODOLOGAS DE
PROCESOS
DESARROLLO DE
SOFTWARE: SCRUM,
Agile UP
Propuesta: Un modelo para Desarrollar Aplicaciones

Web Seguras (WSM-DEV, por sus siglas en ingls)
Figura 14 Esquema de elaboracin de la propuesta
41
El agrupamiento de las prcticas de seguridad del modelo propuesto

denominado WSM-DEV, tienen su fundamento en las prcticas de seguridad
(dimensiones y capacidades) del modelo SSE-CMM. La gua OWASP, proporciona
las caractersticas bsicas de seguridad de una aplicacin web; las otras prcticas y
caractersticas de seguridad se basan en experiencias vividas en el desarrollo de
aplicaciones web.
Por su parte, la aplicacin del modelo WSM-DEV sobre los modelos de
software Scrum, permitieron la refinacin de las actividades y artefactos del modelo
propuesto.
3.4
Indicadores de evaluacin de la propuesta

Con la finalidad de conocer cualitativamente los resultados de la aplicacin del
modelo propuesto (producto), se definen los indicadores de evaluacin presentados

en la tabla 9.
Tabla 9. Indicadores de evaluacin para el modelo propuesto
#
Indicador
Porcentajes de
Numero de vulnerabilidades mitigadas
vulnerabilidades
por el nmero de vulnerabilidades
controladas.
identificadas
Velocidad del
Cantidad de trabajo realizado en 4
equipo gil de
semanas
Descripcin
90%
20 puntos historia
(en la primera
desarrollo.
3
Promedio ideal
iteracin)
Porcentaje de
Nmero de mtodos que siguen el estilo
mtodos que
de codificacin por el total de mtodos
cumplen el estilo
de la aplicacin
80%
de codificacin .
4
Porcentaje de
Nmero de lneas que siguen el estilo
lneas de cdigo el
de codificacin por el total de lneas de
que cumplen los
la toda la aplicacin
70%
estndares de
codificacin.
5
Porcentaje de
Numero de artefactos desarrollados de
artefactos
los nueve artefactos del modelo
80%
desarrollados.
El promedio ideal puede ser referencial, ya que el nivel de seguridad va

depender tambin del valor de los activos de informacin que el negocio requiere
42
proteger. Sin embargo, toda aplicacin debe mitigar las 13 vulnerabilidades de las
aplicaciones web del anexo B2.
El promedio de personas de un equipo gil son entre 3 y 7 personas promedio.
Los 20 puntos historia del promedio ideal est en funcin a 3 o 4 personas. Es decir
la velocidad promedio ideal de cada persona debe ser de 4 a 5 puntos al mes (Palacio
J, 2011).
Los indicadores 3 y 4 corresponden a las coberturas de cumplimiento del estilo
de codificacin a nivel de mtodos y de lneas de cdigo, que comnmente para la
cobertura aceptable de las pruebas suele ser del 80%. La cobertura de pruebas
puede ser incluida cuando se aplica con el modelo TDD.
43
3.5
Diagrama de flujo de las actividades de la Investigacin
El diagrama de flujo de las actividades de la presente investigacin se muestra

en la figura 15.
Organizacin y planificacin de la investigacin
Anlisis de las metodologas
Definicin de la propuesta
Validacin de la propuesta
Documentacin de la tesis
Propuesta invlida
Propuesta OK
Anlisis de resultados y
elaboracin de conclusiones
6. Revisin final de la tesis
Tesis con correcciones
Tesis OK
Figura 15 Diagrama de flujo de las actividades de la investigacin
44
Luego de la organizacin y planificacin de la investigacin, se analizaron las

metodologas resumidas en la figura 14 y se elabor el modelo de manera que se
integre la seguridad en el proceso de desarrollo de aplicaciones web, y a su vez se
fue documentando la tesis. Una vez definido el modelo, se realiz la validacin con
el desarrollo del proyecto Qualpaca como caso de estudio, esta aplicacin permiti
refinar los componentes del modelo permitiendo analizar los resultados finales y
formular las conclusiones de la investigacin. Una vez terminada la documentacin
tanto del modelo como de la tesis; la tesis fue enviada a revisin hasta corregir las
observaciones de los Jurados.
45
3.6
Cronograma de actividades
El desglose del trabajo realizado, luego de la organizacin y planificacin de la
investigacin, se muestra en la Tabla 10.

Tabla 10 - Cronograma de actividades
Tiempo (9 meses)
Actividades
2013-2014
Fase
A M J
ANLISIS DE METODOLOGAS
Organizacin de bibliografas
Anlisis de metodologas de DESARROLLO DE SOFTWARE
Anlisis de metodologas de SEGURIDAD DE INFORMACIN
Revisin de la seguridad de los frameworks emergentes para los
lenguajes de programacin giles y tradicionales.
DEFINICIN DE LA PROPUESTA
Elaboracin de un modelo inicial donde las actividades de
seguridad puedan concretarse juntamente con el modelo de
Documentar las actividades, los roles de cada componente del
modelo
Elaboracin de las plantillas de cada componente del modelo de
seguridad propuesta.
Refinar el modelo de seguridad propuesto.
Crear las plantillas de los artefactos de la propuesta.
Refinar las plantillas de los artefactos del modelo de seguridad
propuesto.
46
J A
O N D
VALIDACIN DE LA PROPUESTA Y DOCUMENTACIN

Elaborar un Backend de administracin para un determinado
framework emergente que contengan los componentes de
seguridad especificados en la OWASP siguiendo el modelo
propuesto.
Validacin de la propuesta aplicando a la construccin de una
Aplicacin Web
Documentacin del caso de estudio
Actualizacin del modelo propuesto
FASE FINAL
Anlisis de los resultados y elaboracin de conclusiones
Redaccin del Documento de la Tesis
Sustentacin
47
3.7
Presupuesto y financiamiento del proyecto de tesis

Tabla 11 - Presupuesto del proyecto
Descripcin
Unid.Med.
Cantidad
P.U.
SubTotal S/.
MATERIALES Y EQUIPOS
5,000.00
Laptop i5 (incluye Windows 7)
Unidad
4,500.00
4,500.00
Memoria USB
Unidad
50.00
50.00
Textos
Unidad
90.00
450.00
SOFTWARE
.00
Python
Lic. Libre
0.00
0.00
Sublime Text 2
Lic. Libre
0.00
0.00
Enterprise Architect 5
Lic. Trial
0.00
0.00
Balsamiq
Lic. Trial
0.00
0.00
Git
Lic. Libre
0.00
0.00
SERVICIOS DE TERCEROS
1,500.00
Modem + Internet
Ao
1,000.00
1,000.00
Hosting
GB
0.00
0.00
Impresiones
Unidad
500
0.20
100.00
Fotocopias
Unidad
2000
0.10
200.00
Empaste
Unidad
10
20.00
200.00
SERVICIOS DE CONSULTORA 1
15,000.00
Asesor de la tesis
RR.HH.
1,000.00
1,000.00
Tesista
RR.HH.
5,000.00
5,000.00
Analista-programador (backend)
RR.HH.
9,000.00
9,000.00
SERVICIOS DE CONSULTORA 2
12,000.00
Dueo del proyecto
RR.HH.
2,000.00
2,000.00
Jefe del proyecto
RR.HH.
2,000.00
2,000.00
Analista
RR.HH.
2,000.00
2,000.00
Programador
RR.HH.
2,000.00
6,000.00
PAGOS DEL PROCESO DE TESIS
2,380.00
OTROS GASTOS
1,500.00
PASAJES Y VITICOS
1,000.00
Imprevistos
1,000.00
500.00
Total S/.
37,380.00
48
Tabla 12 - Financiamiento del proyecto
Descripcin
Importe S/.
Financiamiento propio
19,380.00
Financiamiento UPeU
6,000.00
Financiamiento Grupo InnOp Per
12,000.00
Total S/.
37,380.00
El rubro de financiamiento propio de la tabla 12, corresponde a los gastos de

la compra de materiales y equipos, ms los gastos de servicios de terceros (excepto
el internet) y ms los otros gatos como son pasajes y viticos.
El rubro de financiamiento UPeU de la tabla 12, corresponde a los gastos de
internet ms el pago al tesista por ser empleado a tiempo completo de dicha
institucin.
El rubro de financiamiento Grupo InnOp Per de la tabla 12, corresponde a los
gastos de servicios de consultora que la empresa Grupo InnOp Per pag por el
desarrollo de Qualpaca.
49
CAPTULO 4
CONSTRUCCIN DEL MODELO PARA EL DESARROLLO
DE APLICACIONES WEB SEGURAS
4.1
Introduccin
En este captulo se describe el principal resultado del trabajo de tesis: el modelo
propuesto y sus elementos. Para una rpida identificacin del modelo propuesto, en
adelante se denominar por sus siglas en ingls WSM-DEV (Web-application
Security Model for Development).
4.2
Diseo grfico del modelo propuesto
El modelo para el desarrollo de aplicaciones web seguras (WSM-DEV, por sus

siglas en ingls), pretende ser un modelo de referencia para incorporar las mejores
prcticas de seguridad en el ciclo de vida de desarrollo, con la finalidad de construir
aplicaciones web robustas, confiables y en el menor tiempo. Para tal fin WSM-DEV
provee las plantillas y recursos para cada uno de sus procesos y artefactos.
Esta estrategia permite asignar directamente el trabajo que el negocio requiere
de modo que resulte simple, de menos a ms y natural para el desarrollador. La figura
16 muestra la representacin grfica de los grupos de actividades del modelo
propuesto.
Figura 16 Diseo del modelo WSM-DEV

50
El backend web seguro, es el primer mdulo que implementa una serie de

controles de seguridad en base a vulnerabilidades recurrentes en toda aplicacin web
especificados en estudios internacionales como la OWASP, entre otros estudios y
sobre todo en experiencias probadas. Este mdulo indica claramente el estilo de
codificacin (principios y prcticas) que el equipo debe seguir para construir el resto
del sistema. De este mdulo depender el nivel de seguridad de la aplicacin as
como el tiempo, los riesgos y el costo del proyecto. Este mdulo debe ser construido
siguiendo los pasos 2 al 4 del modelo propuesto WSM-DEV.
El anlisis de riesgo de seguridad, es el componente ms importante del
modelo WSM-DEV, donde se identifican y se priorizan las amenazas y
vulnerabilidades asociados al desarrollo de la aplicacin web para incorporarlos en
las tareas del desarrollo. Aqu se planifica el curso de accin requerido para llevar a
cabo los objetivos de seguridad de una iteracin.
El siguiente proceso de WSM-DEV es el proceso de implementacin de
controles de seguridad, donde se lleva a cabo las actividades planificadas
anteriormente con el fin de lograr los objetivos definidos. Al finalizar la iteracin, se
debe mostrar un producto completamente funcional de acuerdo a las actividades
definidas para la Iteracin con un nivel de seguridad de acuerdo a los objetivos de
seguridad de la Iteracin.
El ltimo proceso de WSM-DEV es el proceso de demostracin y validacin de
la seguridad donde se realizan procesos de revisin, validacin y medicin que
permitan certificar que el Incremento es confiable y las acciones correctivas
necesarias.
4.3
4.3.1
Principios de seguridad
Defensa en profundidad
Proveer a la aplicacin ms de un punto de defensa; la ltima lnea de defensa
debe darse en el backend de la aplicacin web.

4.3.2
Privilegios especficos
Definir perfiles de usuario especficos; los roles o funciones de los usuarios bien
definidas deben establecer claramente el manejo de la aplicacin.

4.3.3
Estilo de codificacin simple pero robusto

Escribir la cantidad mnima de lneas de cdigo que permita que el sistema
responda frente a fallas, y cumplir con los estndares y prcticas de codificacin.

51
Esto permitir identificar las vulnerabilidades, aumentar la productividad y la calidad

del cdigo.
4.3.4
Seguimiento
Guardar en bitcoras los sucesos del sistema ocasionados por las acciones de
usuarios e intrusos. Esto permitir conocer cmo la aplicacin est siendo atacada.
A continuacin se detallan las prcticas de seguridad de este modelo.
4.4
Backend web seguro

El objetivo del backend web seguro, es elaborar los componentes que toda
aplicacin web requiere antes de iniciar con su desarrollo, sobre todo los
componentes de seguridad, as como el estilo de codificacin. El objetivo es definir
una lnea base en seguridad web para las empresas y profesionales de software que
trabajan en el campo de la seguridad dentro del ciclo de desarrollo.
Proyectos sobre seguridad de software como la OWASP y WASC (Web
Application Security Consortium) definen un conjunto de vulnerabilidades que deben
ser consideradas en la construccin de una aplicacin web, algunos de los controles
de seguridad son implementados por los frameworks actuales, pero muchas veces
toma tiempo hacer que funcione y sobre todo deja de lado el estilo de codificacin de
la aplicacin. Va depender de la flexibilidad de los componentes de seguridad de los
frameworks para extender su funcionalidad a nuevos controles de seguridad que
requiera una aplicacin en particular.
Para iniciar el desarrollo de una aplicacin, lo mnimo que se necesita es que
estos componentes de seguridad deben estar debidamente implementados, as
como los otros componentes o libreras de utilidad de desarrollo de una aplicacin
web.
Las caractersticas del backend web seguro a usar o a desarrollar debe
satisfacer las caractersticas de la aplicacin web a desarrollarse, ms no al revs.
Si esto sucede, es necesario definir tareas de personalizacin al backend.
Por lo general, un Backend web seguro para aplicaciones web tipo SaaS, debe
tener las siguientes caractersticas: gestionar de manera rpida y segura a los
usuarios, perfiles, permisos, recursos del sistema, mdulos del sistema, mens
dinmicos, empresas, sucursales entre otros parmetros de configuracin del
sistema. De modo que los siguientes mdulos puedan reutilizar los mismos
componentes de seguridad, mensajera, auditora, plantillas web, sesiones y tokens
52
de usuarios, permitiendo incluso extender su funcionalidad para casos particulares.

De este Backend depender el nivel de seguridad, modernidad, riesgos, cantidad de
personal, costos y tiempos de un proyecto de software.
Estos requisitos y caractersticas del backend, debe definirse en la reunin
Project definition, ya que en esta reunin se valida los objetivos y el trabajo de todo
el proyecto. En esta reunin intervienen el Sponsor del proyecto, el Gerente del
proyecto, el Representante de los clientes, entre otros interesados del proyecto.
El backend web seguro, se puede evidenciar entonces en el Project definition
meeting obteniendo como resultado los requisitos y caractersticas del mdulo del
backend web seguro.
Entradas
Requisitos del sistema (visin del proyecto)
Herramientas
Project definition meeting
Salidas
Requisitos del sistema para el mdulo backend
Registro de riesgos de seguridad (amenazas y vulnerabilidades)
Registro de componentes de seguridad
Arquitectura de la aplicacin
Estndares de desarrollo
Mtodo de trabajo del equipo
Prototipos principales
Diseo de clases del sistema o ejemplos de aceptacin
Por lo tanto, a partir de los requisitos del sistema, se infieren los requisitos de
seguridad y las pruebas de vulnerabilidad que ayudan a definir el software y se
asignan a componentes de software. Este conjunto de requisitos de software y de
componente de software se convierten en: la arquitectura del software, los diseos
de los componentes de software y los componentes de software. En base a la
53
arquitectura y los estndares se elaboran los Prototipos principales y el Diseo de

clases de toda la aplicacin o al menos de la primera iteracin y son usados en la
validacin y priorizacin de los requisitos. En caso de estar usando TDD, basta con
agregar a los requisitos o historias de usuario los Ejemplos de aceptacin del usuario.
Para el desarrollo de este backend web seguro, debe seguir los pasos 2 al 4
del modelo WSM-DEV.
4.5
4.5.1
Artefactos del backend web seguro

Requisitos del sistema (o requisitos para el mdulo backend)
Los requisitos del sistema (mdulo backend), es el listado de requisitos
principales que define la visin de todo el proyecto (o de todo el mdulo). Vale sealar
que estn incluidos los requisitos de seguridad y expectativas del cliente
debidamente priorizados y estimados. Este listado contiene las siguientes partes:
Nombre del proyecto
Fecha de actualizacin
Listado de los requisitos con propiedades bsicas.
La plantilla para los requisitos del sistema puede verse en el anexo A1.
4.5.2
Registro de riesgos de seguridad (amenazas y vulnerabilidades).

El Registro de riesgos de seguridad (amenazas y vulnerabilidades), es el
listado de amenazas y vulnerabilidades comprometido con la aplicacin web. Esta

lista inicial para el backend, puede ser obtenido a partir de guas o normas como la
OWASP, recomendaciones de expertos y experiencias vividas que estn alineados
con el objetivo del proyecto. Este listado contiene las siguientes partes:
Nombre del proyecto
Listado de los riesgos de seguridad con propiedades bsicas.
La plantilla para el registro de riesgos de seguridad (amenazas y

vulnerabilidades) del proyecto puede verse en el anexo A2.
54
4.5.3
Registro de componentes de seguridad.

El registro de componentes de seguridad, es el listado de recursos de
seguridad para contrarrestar las amenazas y vulnerabilidades comprometidas con la

aplicacin web. Este listado contiene las siguientes partes:
Nombre del proyecto
Listado de los componentes (o una matriz de componentes con riesgos).
La plantilla para el registro de componentes de seguridad del proyecto puede

verse en el anexo A3.
4.5.4
Arquitectura de la aplicacin
La arquitectura de la aplicacin es un esquema que muestra las capas de la
aplicacin, las interacciones entre las capas basado en una arquitectura estndar y
las tecnologas que se usan para implementar cada capa. Este esquema muestra de
forma holstica el nivel de calidad y seguridad de la aplicacin. Este documento
consta de:
Informacin general
Historial de revisiones
Esquema de la arquitectura de la aplicacin (cuadro o grfico)
La plantilla de la Arquitectura de la aplicacin puede verse en el anexo A4.

4.5.5
Estndares de desarrollo
El estndar de desarrollo es un documento que indica cmo se debe de
nombrar los diferentes componentes de la aplicacin: nombre de las clases, atributos,

mtodos, archivos, carpetas, nombre de las tablas y campos, as como nombre de
los diagramas y elementos de diseo del sistema. Todo programador, adems del
estndar de desarrollo, debe seguir las tcnicas y estilos de desarrollo definidas para
el proyecto. Estas tcnicas y estilos se interiorizan a travs del backend o de un
ejemplo completo desde el diseo hasta la implementacin de un componente y
muestra el orden de las instrucciones o restricciones del programa, cdigo depurado
55
y las pruebas que todo componente debe cumplir.
Un estndar de desarrollo
contiene:
Informacin general
Trminos de definicin de identificadores
La plantilla del estndar de desarrollo puede verse en el anexo A5.

4.5.6
Mtodo de trabajo del equipo

El mtodo de trabajo del equipo es un documento que resume el plan del
proyecto con la informacin necesaria dirigida al equipo de desarrollo. Define las

herramientas y procedimientos para minimizar riesgo, sobre todo riesgos de
seguridad. Este documento contiene las siguientes partes:
Informacin general
Equipo de trabajo
Herramientas
Desafos o retos a superar
La plantilla del mtodo de trabajo del equipo puede verse en el anexo A6.
4.5.7
Prototipos principales
Los prototipos principales son las interfaces grficas del usuario diseado
mediante una herramienta para prototipos que validan las entradas de los datos, los
procesos de negocio y los reportes esperados por los usuarios y clientes. Los
prototipos principales y Los diagramas de clases de diseo del sistema son los nicos
artefactos que se necesitan para delegar tareas al equipo de desarrollo en un modelo
clsico, estos artefactos son reemplazados por los ejemplos de aceptacin para un
modelo gil. Un prototipo responde:
Proyecto
Mdulo
56
Fecha
Requisito
Imagen de la Interfaz grfica del usuario
Funcionalidad
Personal que aprueba la interface
La plantilla para un prototipo puede verse en el anexo A7.

4.5.8
Diseo del sistema (para la iteracin)

El diseo del sistema o de la iteracin es un reporte en HTML de la versin
actual del diseo del sistema y contiene los diagramas de clases de diseo. Un
diseo del sistema indica los componentes del sistema, sus relaciones de
dependencia, las restricciones y reglas de negocio que deben ser probadas y
validadas. El diseo debe relejar los estndares de desarrollo y la arquitectura del
sistema. En un documento formal o sistema de mensajes debe indicarse lo siguiente:
Nombre del proyecto
Actualizaciones importantes
Links de descarga o de consulta
Estructura base del modelo.
La plantilla del diseo del sistema puede verse en el anexo A8.
4.6
Anlisis de riegos de seguridad

El objetivo de este grupo de procesos es identificar y priorizar las amenazas y
vulnerabilidades de la aplicacin e incorporarlos a los requisitos del sistema o

historias de usuario que se van a implementar en la Iteracin. En Scrum, esta
integracin se realiza en la primera parte del Sprint planning meeting. Por lo que se
precisa de un experto en seguridad que ayude al Dueos del producto a identificar
los riesgos de seguridad.
57
Por lo tanto, a partir de los requisitos del sistema, incluyendo los requisitos del
backend, se infieren los nuevos requisitos de seguridad y las pruebas de
vulnerabilidad que ayudan a definir el software y se asignan a componentes de
software. En base a la arquitectura y los estndares se elaboran los prototipos
principales de toda la aplicacin o al menos de la primera iteracin y son usados en
la validacin y priorizacin de los requisitos.
Una vez identificado los riesgos de seguridad, se procede a definir los
componentes de seguridad para cada amenaza o vulnerabilidad. En Scrum, estas
actividades corresponde a la segunda parte del Sprint planning meeting, al definir las
tareas, relacionados a las historias del product backlog.
Para poder definir la lista de tareas de desarrollo, se debe tener listo el diseo
del sistema para todos los requisitos seleccionados de la Iteracin. Cada componente
del diseo del sistema debe estar debidamente documentado las reglas de negocio
y las restricciones de seguridad. El diseo debe reflejar el estndar de desarrollo, las
tcnicas o estilo de codificacin y la arquitectura de la aplicacin.
Las tareas para solucionar los errores y vulnerabilidades de la Iteracin anterior
e incluso las observaciones en el diseo de los requisitos seleccionados deben ser
rediseados y solucionados durante la Iteracin en curso.
El grupo de procesos de anlisis de riesgos de seguridad se puede evidenciar
entonces en la Iteration planning meeting obteniendo como resultado el registro de
componentes de seguridad.
Entradas
Requisitos del sistema
Registro de riesgos de seguridad (amenazas y vulnerabilidades)
Diseo del sistema (para la iteracin)
Herramientas
Iteration planning meeting
Salidas
Entradas actualizadas

58
A continuacin se describen cada uno de los nuevos artefactos, las plantillas

pueden revisarse en los anexos referidos.
4.7
Artefactos del anlisis de riesgos de seguridad

En el anlisis de riesgos de seguridad no cuenta con ningn nuevo artefacto.
Las plantillas de los artefactos pueden revisarse en los anexos referidos para los
artefactos del backend web seguro.
4.8
Implementacin de los componentes de seguridad

El objetivo de este grupo de procesos es llevar a cabo las tareas de
implementacin, por parte del equipo de desarrollo, mediante un seguimiento visible

con el fin de lograr los objetivos de seguridad definidos para dicha iteracin;
asimismo, implica tanto la coordinacin de personas y recursos, as como el
entrenamiento en seguridad al equipo de desarrollo.
Las tareas de la iteracin se enfocan en la codificacin y testing de los
componentes de seguridad juntamente con las tareas de dicha iteracin, por lo que
es importante contar con herramientas para la revisin y testing de la seguridad y
calidad del software sea manual como automatizado, estas tareas deben estar
soportadas por herramientas de desarrollo colaborativo y mtodos adecuados para
su integracin. A continuacin se presenta las buenas prcticas para un correcto
desempeo colaborativo.
1. Antes de realizar una tarea, obtener el ltimo commit del repositorio remoto,
es decir, actualizar el repositorio local.
2. Realizar la(s) tarea(s) segn los estndares y estilos de codificacin
establecidos para el proyecto.
3.
Antes de subir una tarea al repositorio remoto, volver a actualizar el

repositorio local, resolver los conflictos y errores si los hubiese y
seguidamente, subir las tareas al repositorio remoto. Si se est usando un
sistema de integracin continua, verificar que los reportes con la nueva
revisin o commit sigan sin errores y mantengan los indicadores de calidad
establecidos para el proyecto.
4. Comunicar el estado de la tarea segn el mtodo de trabajo establecido.

Dos prcticas bsicas para los testings son:
59
1. Filtrar entradas, con el fin de asegurar que los datos de entrada sean
vlidos.
2. Escapar salidas, para asegurar que los datos salientes no se
malinterpreten.
Las buenas prcticas para las pruebas de seguridad, dentro de este grupo de
procesos responden a las tareas de:
1. Filtrar entradas
Asegurar que los datos de entrada sean vlidos; verificar si los datos cumplen
con ciertas reglas, as como el origen de los datos.
2. Asegurar transacciones
Asegurar que los datos se guarden o no de forma adecuada. En ambos casos,
y en especial cuando falla, el sistema debe responder robustamente.
3. Escapar salidas
Asegurar que los datos de salida no se malinterpreten, es decir codificar o
decodificar caracteres especiales de tal forma que su significado original sea
preservado.
En muchas organizaciones dedicadas a la fabricacin de software, estos
componentes son desarrollados por un equipo central, dedicados a la investigacin
y mejora de los componentes claves de la aplicacin y, a dar soporte y capacitacin
al equipo de seguridad de un determinado proyecto sobre el uso adecuado de los
componentes de seguridad y otros utilitarios. El equipo de soporte central, son los
encargados de definir el estilo de codificacin para todo el proyecto, pues, frente a
un problema se tiene ms de una forma de solucionarlos; pero solo una forma es la
correcta para el proyecto en cuestin.
El grupo de procesos de implementacin de los componentes de seguridad se
puede evidenciar en el Security training meeting y por las herramientas de revisin y
validacin automatizadas y manuales obteniendo como resultado el Incremento o
producto funcional seguro.
Entradas

60
Herramientas
Herramientas de revisin y validacin automatizados y manuales
Security training meeting
Salidas
Producto funcional o incremento seguro

4.9
4.9.1
Artefactos de la implementacin de los componentes de seguridad

Producto funcional seguro
El producto funcional seguro, es la aplicacin funcionando de acuerdo a las
tareas definidas para la iteracin o la suma de ellos juntamente con los objetivos de
seguridad.
4.10 Demostracin y validacin de la seguridad
El objetivo de este grupo de procesos es revisar el cumplimiento de los
objetivos de seguridad del proyecto mediante la presentacin de resultados, se
realizan procesos de anlisis, revisin y medicin que permitan certificar que el
Incremento es confiable y las acciones correctivas necesarias.
Los procesos de anlisis, revisin y medicin se realizan de forma manual y
automtica. Las herramientas de Integracin Continua permiten automatizar estos
procesos. Por ejemplo, en un proceso TDD, la cobertura de la pruebas aceptable
promedio es del 80%. Estos parmetros de medicin deben ser definidos al inicio del
proceso de desarrollo. Los indicadores que miden la eficacia de este modelo se
muestra en la tabla 9.
Al finalizar una iteracin se debe presentar el resultado de la iteracin para su
aceptacin. Con respecto a la seguridad, se debe hacer pruebas de intrusin con el
fin de encontrar nuevas o recurrentes vulnerabilidades de tal manera que se lleven a
cabo acciones correctivas en la prxima iteracin.
El grupo de procesos de demostracin y validacin de la seguridad se puede
evidenciar mediante las reuniones de revisin de la iteracin y herramientas de
validacin automatizadas y manuales obteniendo como resultado el registro de
riesgos de seguridad actualizado y las lecciones aprendidas.
61
Entradas
Registro de riesgos de seguridad
Incremento seguro
Herramientas
Iteration review meeting
Herramientas de validacin automatizados y manuales
Salidas
Registro de riesgos de seguridad (vulnerabilidades)
Lecciones aprendidas

4.11 Artefactos de la demostracin y validacin de la seguridad
4.11.1 Formulario de lecciones aprendidas
El formulario de lecciones aprendidas, es un informe de lo que sali bien o no
durante el desarrollo de la iteracin y de las acciones de mejora para la siguiente
iteracin. Un formulario de lecciones aprendidas contiene las siguientes partes:
Proyecto:
N Iteracin:
Qu sali bien en la iteracin
Qu no sali bien en la iteracin
Qu mejoras vamos a implementar en la siguiente iteracin
La plantilla del formulario de lecciones aprendidas puede verse en el anexo A9.
4.12 Resumen
El modelo WSM-DEV, plantea claras actividades desde la concepcin del
proyecto hasta la entrega del producto funcional soportadas por plantillas
consistentes y simplificadas con el propsito de dar cumplimiento a los procesos de
62
ingeniera de software, acelerar el desarrollo y obtener una aplicacin web ms

segura.
63
CAPTULO 5
VALIDACIN DEL MODELO PROPUESTO
WSM-DEV PARTE 1
5.1
Introduccin
En este captulo se describe la aplicacin y validacin de la primera parte del
modelo propuesto WSM-DEV; sobre el backend web seguro. La segunda parte del
modelo se aplica y se valida en el siguiente captulo.
Para ambas partes se realizan mediante el desarrollo de una aplicacin web
para la cadena productiva de alpacas (patrocinado por CONCYTEC y la UPeU en el
ao 2013) denominada Qualpaca versin 1.0
Con la aplicacin y validacin de esta primera parte del modelo WSM-DEV se
obtuvo el segundo resultado o aporte del trabajo de tesis: El mdulo backend de
administracin y configuracin de aplicaciones web seguras en la nube escrita en
Django y Bootstrap. Y que tambin sirve como referencia para la construccin de del
mdulo backend con otros framewroks o lenguajes de programacin.
5.2
5.2.1
Acerca del proyecto

Grupo InnOp Per
Grupo InnOp Per EIRL, es una empresa dedicada a ofrecer consultora y
servicios a terceras empresas. La consultora y servicios en ingeniera se realizan

mediante el desarrollo de proyectos a plazo determinado e integrada por
profesionales. Grupo InnOp Per EIRL es parte ejecutante del proyecto UPeUCONCYTEC 2013 denominado Desarrollo de plataforma tecnolgica en la web para
la competitividad de la cadena productiva de alpacas en la regin Puno financiado
por el Consejo Nacional de Ciencia, Tecnologa e Innovacin del Per (CONCYTEC)
y por la Universidad Peruana Unin (UPeU)
5.2.2
Proyecto UPeU-CONCYTEC 2013

El proyecto UPeU-CONCYTEC 2013, es un proyecto de investigacin
presentado por la Dra. Nlida Gladys Maquera Sosa y la UPeU (Universidad Peruana
Unin) en el ao 2013 al CONCYTEC denominado Desarrollo de plataforma
64
tecnolgica en la web para la competitividad de la cadena productiva de alpacas en

la regin Puno, el cual consta de varios entregables entre ellos la aplicacin web
funcional denominada Qualpaca versin 1.0.
5.2.3
Qualpaca 1.0
Qualpca 1.0, es el nombre de la plataforma tecnolgica en la web para la
competitividad de la cadena productiva de alpaca en cumplimiento al proyecto UPeUCONCYTEC 2013.

Qualpaca 1.0, es una aplicacin web para la nube que da soporte a los registros
genealgicos y reproductores de alpacas de la regin Puno. La versin 1.0 consta de
los siguientes mdulos:
1. Seleccin e identificacin de alpaca
2. Empadre y gestacin
3. Paricin y destete
4. Sanidad
5. Esquila
6. Castracin
7. Retiro
Debido al tratado de confidencialidad y con la autorizacin de la Gerente
General de la empresa Grupo InnOp Per, parcialmente se pueden ver estos
documentos en los anexos referidos.
5.2.4
Materiales y mtodos
Qualpaca versin 1.0 fue desarrollado con tecnologas giles como el
framework Django 1.5.x de Python, el gestor de base de datos MySQL 5.x y sobre el
administrador de aplicaciones Backengo 0.1 (backenddj) que a su vez integra el
Bootstrap 2.x. El equipo de desarrollo multidisciplinario estuvo conformado por 5
personas contratadas por la consultora Grupo InnOp Per. Para el desarrollo del
proyecto se aplic el mtodo Scrum y para la seguridad el mtodo WSM-DEV.
Por acuerdo de confidencialidad, solo se describe y se muestra parte de los
procesos y resultados del proyecto Qualpaca que han sido autorizados por escrito
por la autora principal Dra. Nlida Gladys Maquera Sosa, Gerente General de la
empresa Grupo InnOp Per EIRL.
65
Seguidamente, se describe el proceso de desarrollo del backend web seguro

sobre la cual se desarroll Qualpaca.
5.3
Backend web seguro y la definicin del proyecto Qualpaca

El proyecto Qualpca 1.0, se inici formalmente el 01 de mayo del 2013, donde
solo se saba a grandes rasgos que se desarrollara una aplicacin web para mejorar
la cadena productiva de alpacas. El sistema tendra que registrar los datos
genealgicos y datos de produccin de las alpacas iniciando por todos los
productores de la regin Puno.
Despus de revisar los procesos de la cadena productiva de alpacas en
diferentes instituciones dedicados a la crianza de alpacas de la regin Puno y con la
asesora del Ing. Eliphas Coeli de la Universidad de Camerino de Italia, se defini la
visin del proyecto.
Seguidamente, se opt por aplicar los mtodos Scrum y WSM-DEV, el lenguaje
de programacin gil Python y el framework Django, que para ese entonces solo se
tena una versin en borrador del WSM-DEV y el principal riesgo era que no se
contaba con un backend web seguro desarrollado sobre Django, lo que hizo que el
inicio del desarrollo se postergara hasta el mes de noviembre del mismo ao (seis
meses despus). Sin embargo, mientras se esperaba la primera entrega del backend
para Django, se inici a disear el sistema.
Los prototipos del sistema se validaron el 14 de junio de 2013 en una reunin
con los representantes de las diferentes instituciones dedicados a la crianza de
alpacas de la regin Puno que se llev a cabo en el auditorio de la Direccin General
de Sistemas (DIGESI) de la UPeU Filial Juliaca. Para el 21 de junio ya se tena
actualizado el diseo en UML de todo el sistema y desplegado en un servidor privado.
En dicho reporte UML tambin se indic la Arquitectura de la aplicacin donde cada
componente segua los estndares de desarrollo previamente definidos. As mismo,
se llev a cabo la reunin de Project definition donde se aprob el acta de constitucin
del proyecto. Sin embargo, no poda iniciar el desarrollo mientras no se tena el
backend de administracin que el modelo WSM-DEV requiere.
Para fines de octubre del 2013 se public una versin beta del backend para
Django, que permiti iniciar el desarrollo el 04 de noviembre y terminar el 06 de
diciembre.
66
Para el 04 de noviembre se actualiz todo el diseo segn los componentes de

seguridad y utilitarios de backend para Django, y tambin se actualiz el mtodo de
trabajo del equipo entre otros documentos del proyecto.
5.4
Anlisis de riesgos de seguridad

Dado que la aplicacin web sera de tipo SaaS, se defini un backend para
administrar los permisos a los mdulos y a los datos de diferentes empresas

productoras de fibra de alpaca. La lista de requisitos para el mdulo backend web
seguro se muestra en el anexo B1.
La mayora de los riesgos de seguridad a tener en cuenta en el backend web
seguro fueron tomados de la OWASP Top 10 del ao 2013. La otra parte de la lista
de riesgos fue abstrada de experiencias personales vividas en diferentes proyectos
y diferentes frameworks como KumniaPHP, Hibernate, Spring Security, NHibernate,
Spring.Net, Flex, Silverlight, PrimeFace entre otros.
Estas caractersticas del backend y la lista base de riesgos, fue presentada,
discutida y validada en la reunin del Project definition. Con esta lista de riesgos de
seguridad se procedi a identificar los componentes de seguridad existentes para el
framework Django y evitar reinventar la rueda. El contenido de ambas listas se
muestra en los anexos B2 y B3.
Identificado los componentes se seguridad se procedi a disear estos
componentes y todo el mdulo del backend sobre el framework Django, respetando
la arquitectura, los estndares y el estilo de codificacin previamente definidos. El
anexo B10 muestra las tareas para el desarrollo del backend.
En la reunin de definicin del backend web seguro, asistieron: La Dra. Gladys
Maquera Sosa representando a los Patrocinadores CONCYTEC y UPeU y a las
principales instituciones productoras de fibra de alpaca de la Regin Puno. El Scrum
Master Ing. Abel Huanca Torres, y el Equipo Scrum conformado por Angel Sulln
Macalup, Oscar Mendoza Apaza y Elvis Al Vilca.
5.5

Gran parte de las tareas de implementacin fueron los estilos de cmo se usa
un componente de seguridad de Django y decidir por un estilo de programacin que

guiara el resto del proyecto.
La secuencia de comandos para proteger un activo fue asignada a
componentes con la finalidad de reutilizarlos y as minimizar las lneas de cdigo. La
67
flexibilidad de algunos componentes permite integrar la seguridad al final del proyecto

como es el caso del componente para proteger los recursos del sistema tomando al
usuario y el lugar donde se encuentra. El registro de componentes de seguridad para
el backend se muestra en el Anexo B3.
A continuacin se describen los riesgos y componentes de seguridad para el
backend. Los demos, la documentacin y todo el cdigo fuente puede ser revisada
en https://github.com/submitconsulting/backengo
5.5.1
SQL inyection
Los SELECT vulnerables toman los datos de entrada como vlidos si pasar por
ningn filtro. OWASP recomienda usar una API que permita parametrizar los datos
de entrada por separado.
Django framework, cuenta con los mtodos get, filter, exclude, etc. que
compara cada campo por separado. Por ejemplo:
User.objects.get(username=request.POST.get("username"),
password=request.POST.get("password"))
5.5.2
Prdida de autenticacin y gestin de sesiones

HTTP es un protocolo SIN ESTADO, esto significa que se tiene que usar una
SESSION para mantener el ESTADO para no estar autenticndose en cada pedido

HTTP. OWASP recomienda no exponer la SESSION ID en la red, en el navegador,
los logs, etc, as mismo, recomienda expirar y rotar la sesin y los tokens de
autenticacin.
Por su parte, Django cuenta con los mtodos login y logout para tales fines.
login(request,
authenticate(username=request.POST.get("username"),
password=request.POST.get("password"))
Luego, desde cualquier peticin HTTP, se puede acceder al token de

autenticacin con:
user = request.user
Y para destruir la sesin:

logout(request)
68
5.5.3
Secuencia de comandos en sitios cruzados (XSS)

El atacante inyecta en el ingreso de datos secuencia de comandos, por lo
general JavaScript, que explotan el intrprete del navegador web. XSS permite a los
atacantes obtener contraseas, llaves, token de sesin, redireccionar un usuario
hacia un sitio de malware o phishing. OWASP recomienda validar las entradas de
datos y seguir el estndar anatmico de un HTML (cuerpo, atributos, JavaScript,
CSS, o URL) para ubicar los datos no confiables.
Debido a que muchas aplicaciones requieren aceptar caracteres especiales
como parte de las entradas vlidas, una solucin ptima es escapar toda salida de
los datos a menos que se declare como dato confiable o sano o seguro (safe)
En Django, todas las salidas de datos son escapadas por defecto
{{ name }}
<input type="text" value="{{name}}">
Y para marcar como dato de salida seguro y quitar la proteccin XSS, Django
cuenta con el filtro safe:
{{ name|safe }}
5.5.4
Referencia directa insegura a objetos

Esto forma parte de realizar una AUTORIZACIN apropiada, junto con
Ausencia de Control de Acceso a las Funciones (5.5.7), los usuarios son capaces de
acceder a recursos y datos sin autorizacin. Un atacante modifica la URL o el valor
del parmetro que se refiere directamente a un objeto del sistema por otro objeto al
que no tiene acceso. OWASP recomienda comprobar el acceso con la lista de
accesos por cada usuario (identificadores de objeto, nombres de fichero o recursos).
Adems de las recomendaciones de la OWASP, para una rpida proteccin al
acceso a datos se debe generar y comprobar llaves de seguridad combinada con el
valor de parmetro.
El sistema de seguridad avanzado de Django, protege a nivel de permiso las
acciones del usuario. Por ejemplo:
from django.contrib.auth.decorators import permission_required
@permission_required('polls')
def my_view(request):
69
if request.user.has_perm('polls.can_vote):
...
...
Esto mismo se puede realizar de muchas formas, incluso en las plantillas html,
entre otras ventajas.
Se
dio
mayor
flexibilidad
construyendo
el
componente
decorador
@permission_resource_required, el cual identifica la URL actual y valida si el usuario
tiene o no permiso.
from apps.utils.decorators import permission_resource_required
@permission_resource_required
def my_view(request):
...
Con este componente se logra que la proteccin a los recursos se integre al

trmino de las tareas de desarrollo.
Para dar seguridad a datos, se dise un repositorio para el almacenamiento
temporal de identificadores claves a accesos a informacin clasificada denominada
UserToken. Por ejemplo, obtener el listado de las sedes de la empresa actual.
from apps.utils.security import UserToken
from apps.space.models import Headquar
headquar_list =
Headquar.objects.filter(enterprise_id=UserToken.get_enterprise_id(request.
session)).order_by("-id")
El otro componente de seguridad que da mayor seguridad es el componente

SecurityKey, que genera una llave de seguridad y la combina con el identificador de
los datos solicitados para luego validar la llave con la accin asociada.
Primero, en el tamplate se invoca al filtro key del templatetag app_security:
{% load app_security %}
<a href="{% url 'locality_delete' d.id|key:'locality_del' %}" ...
70
Y finalmente, al enviar la peticin de eliminar; descifra el id del objeto a partir

de la llave recibida:
from apps.utils.security import SecurityKey
from django.core.exceptions import PermissionDenied
from apps.params.models import Locality
from django.shortcuts import get_object_or_404
def locality_delete(request, key):

id = SecurityKey.is_valid_key(request, key, "locality_del")
if not id:
raise PermissionDenied
try:
d = get_object_or_404(Locality, id=id)
d.delete()
except:
...
5.5.5
Configuracin de seguridad incorrecta

Ocasionado por descuidos, desconocimientos y confianza ciega en el entorno
de produccin. Las claves de seguridad son los mismos del entorno de desarrollo,
los archivos de ejemplos y URL conocidos estn expuestos al pblico, la aplicacin
muestra el detalle completo de los errores. Por suerte, los nuevos frameworks
permiten configurar estos parmetros de forma simple. OWASP recomienda usar
diferentes contraseas para los entornos de Desarrollo, Aseguramiento de la calidad
(QA) y Produccin. Una fuerte arquitectura de la aplicacin que proporcione una
separacin segura y efectiva entre los componentes. Y realizar auditoras
peridicamente para ayudar a detectar fallos de configuracin.
Adems de las recomendaciones de la OWASP, la configuracin del entorno
de produccin se debe instalar las dependencias necesarias, dejando fuera
herramientas de integracin, depuracin, pruebas entre otros. Esta prctica,
incrementa el tiempo de respuesta de las peticiones HTTP.
Django provee un archivo de configuracin que maneja toda la aplicacin
comnmente denominado settings.py cuyas variables de configuracin ms
importantes son:
# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = '#zqk3o8k!^3j)5g5r=rlt#xz@km+a7f5og$9(&_$69v@4^%4uh'
71
# SECURITY WARNING: don't run with debug turned on in production!

DEBUG = True #False
TEMPLATE_DEBUG = DEBUG
ALLOWED_HOSTS = ['*',]
DEBUG = True, indica un entorno de desarrollo donde Django muestra los

errores al detalle, si es False y si no se ha personalizado los errores, enva la pgina
de error 404. Esta variable puede ser usada para que los archivos estticos de
terceros puedan ser llamados desde el servidor local o de un CNS. Por ejemplo, para
usar JQuery con un CDN sera:
<script src="//code.jquery.com/jquery-1.11.0.min.js"></script>
Esta prctica, incrementa la velocidad de carga.

5.5.6
Exposicin de datos sensibles

Ocurre cuando no se cifran adecuadamente los datos sensitivos o cuando no
se identifican todos los lugares donde estos datos son almacenados.

Tambin ocurre cuando una aplicacin almacena archivos cifrados pero la
clave de cifrado es accesible. Por ejemplo el valor de la variable SECRET_KEY de
item anterior. Esta vulnerabilidad queda fuera del alcance de la OWASP. Sin embargo
recomienda aplicar algoritmos de cifrado fuertes y estndar as como claves fuertes
y gestionarlas de forma segura. Y finalmente, deshabilitar el autocompletar en los
formularios de recolectan datos sensibles.
Por suerte, Django mapea las URLs de la aplicacin que son expuestos al
pblico, por lo tanto el archivo settings.py no se accede a travs de una URL.
Python usa la librera hashlib para encriptar y desencriptar cadenas. Por
ejemplo:
import uuid
import hashlib
def hash_password(password):
# uuid is used to generate a random number
salt = uuid.uuid4().hex
return hashlib.sha256(salt.encode() +
password.encode()).hexdigest() + ':' + salt
72
def check_password(hashed_password, user_password):

password, salt = hashed_password.split(':')
return password == hashlib.sha256(salt.encode() +
user_password.encode()).hexdigest()
new_pass = raw_input('Please enter a password: ')

hashed_password = hash_password(new_pass)
print('The string to store in the db is: ' + hashed_password)
old_pass = raw_input('Now please enter the password again to check:
')
if check_password(hashed_password, old_pass):
print('You entered the right password')
else:
print('I am sorry but the password does not match')
Para el backend, solo se necesit cifrar el password del usuario, y se aplic el

componente set_password de Django, por ejemplo:
request.user.set_password(request.POST.get("password"))
Y para validar la autenticacin, se us el componente authenticate de Django:

from django.contrib.auth import authenticate, login, logout
if authenticate(username=
request.POST.get("password")):
request.POST.get("username
"),
password=
...
5.5.7
Ausencia de control de acceso a las funciones

Esto forma parte de realizar una AUTORIZACIN apropiada, junto con
Referencia directa Insegura a objetos (5.5.4), los usuarios son capaces de acceder a
recursos y datos sin autorizacin. Un atacante modifica la URL o el valor del
parmetro de una funcin con privilegios. Las recomendaciones del OWASP y los
componentes de seguridad son los mismos de la seccin 5.5.4.
73
5.5.8
Falsificacin de peticiones en sitios cruzados (CSRF)

Al igual que XSS, el atacante no necesariamente inyecta cdigo en el envo de
datos, sino que manipulan el contenido de los datos de los parmetros de la URL
para realizar transacciones fraudulentas con o sin intencin del usuario. Ms an,
estos datos pueden provenir de URLs maliciosos. OWASP recomienda la inclusin
de un token no predecible (secreto) en cada solicitud HTTP. Estos tokens deben ser,
como mnimo, nicos para cada sesin del usuario.
Django genera automticamente un token secreto para cada sesin del usuario
y por defecto son validados en cada solicitud HTTP; es decir en cada accin o
mtodo:
Para peticiones con formularios:
<form action=" >
{% csrf_token %}
</form>
Para peticiones asncronas con Ajax:

$.ajaxSetup({
beforeSend: function(xhr, settings) {
if(settings.type == "POST"){
xhr.setRequestHeader("X-CSRFToken",
getCookie('csrftoken'));
}
}
});
Para peticiones asncronas con AngularJS:

angular.module('app',
['ngResource',
'ngCookies']).run(function ($http, $cookies) {
$http.defaults.headers.common['X-CSRFToken']=
$cookies['csrftoken'];
});
Para desproteger CSRF:

from django.views.decorators.csrf import csrf_exempt
@csrf_exempt
def func_index(request):
"""
"""
74
'ngRoute',
5.5.9
Uso de componentes con vulnerabilidades conocidas

Algunos componentes de software (o frameworks de programacin) son
vulnerables ante ataques conocidos, por ejemplo las vulnerabilidades Top 10 de

OWASP, entre otras vulnerabilidades. OWASP recomienda no usar componentes
que no ha codificado. Pero eso no es realista, por lo que todo proyecto de software
debera tener un proceso para identificar y revisar la seguridad de los componentes
que estn usando, todo ello bajo polticas de seguridad que regulen el uso de
componentes.
5.5.10 Redirecciones y reenvos no validados
Las redirecciones o reenvos con parmetros hacia otras pginas o sitios web
del tipo http://example.com/login/?next=/facturas/cobranza son frecuentes. Si no
son validados, el atacante puede enviar a la vctima a un sitio de su eleccin, pasando
por alto los controles de seguridad. OWASP recomienda evitar el uso de
redirecciones y reenvos, en caso de utilizar, no involucrar parmetros manipulables
por el usuario para definir el destino. Si los parmetros de destino no pueden ser
evitados, asegrese que el valor suministrado sea vlido y autorizado por el usuario.
Afortunadamente, los frameworks modernos como Django, mapean las URLs
autorizadas por la aplicacin. As, la URL http://example.com/facturas/cobranza
debe estar mapeado para ser reconocido como URL vlido.
Toda aplicacin Django mapea las URLs en el archivo urls.py. Por ejemplo:
from django.conf.urls import patterns, url
urlpatterns = patterns('apps.accounts.views',
url(r'^add_enterprise/$', 'add_enterprise', name='add_enterprise'),
url(r'^signup/$', 'signup_sys', name='signup_sys'),
url(r'^login/$', 'login_sys', name='login_sys'),
url(r'^load_access/(?P<headquar_id>.*)/(?P<module_id>.*)/$',
'load_access', name='load_access'),
url(r'^logout/$', 'logout_sys', name='logout_sys'),
url(r'^profile/edit/$', 'user_profile_edit',
name='user_profile_edit'),
url(r'^choice_headquar/(?P<field>[\w\d\-]+)/(?P<value>.*)/$',
'choice_headquar', name='choice_headquar'),
url(r'^choice_headquar/$', 'choice_headquar',
name='choice_headquar'),
)
75
5.5.11 Registro de sucesos incompletos

Los sucesos del sistema ocasionados por las acciones de los usuarios del
sistema deben ser guardados en bitcoras en un lugar seguro, que no est en
carpetas pblicas donde los atacantes puedan tener acceso. Estos registros pueden
ser automticos y manuales.
En Django, los registros de los sucesos automticos se configura en la variable
LOGGING del archivo de configuracin settings.py
LOGGING = {
...
'handlers': {
'file_django': {
'level': 'DEBUG',
'class': 'logging.FileHandler',
'filename': os.path.join(BASE_DIR, 'temp/logs',
'dj%s.txt'
(datetime.datetime.now().strftime("%Y-%m-%d"))),
'formatter': 'verbose_dj'
},
Y el registro de los sucesos manuales, mayormente son realizados cuando se

presenta alguna excepcin:
import logging
from apps.utils.security import log_params
log = logging.getLogger(__name__)
try:
self.get_object()
except Exception, e:
log.warning(e, extra=log_params(self.request))
76
5.5.12 Datos incompletos

La falta de integridad en las transacciones de datos es frecuente, se debe hacer
pruebas de estas transacciones y asegurar que los datos se estn guardando de
forma correcta en todas las tablas de base de datos afectados.
En Django, una forma de asegurar la transaccin de los datos es:
from django.db import transaction
@transaction.atomic
def user_add(request):
if request.method == "POST":
try:
sid = transaction.savepoint()
...
except Exception, e:
transaction.savepoint_rollback(sid)
message.error(request, e)
5.5.13 Permisos inconsistentes

Muchas veces se definen modelos de datos que no reflejan el control de
usuarios como el negocio requiere, siendo muy limitados y hasta fciles de descifrar
por un atacante. Un buen diseo debe dificultar el entendimiento de un intruso de
sobre cmo se distribuyen los accesos.
La figura 17 muestra el modelo de datos que Django usa para el control
adecuado de accesos a sus usuarios.
77
class sad/models.py cloud
dj ango.contrib.auth.models::
AbstractUser
User
-
last_headquar_id: CharField
last_module_id: CharField
__unicode__( ) : self.username
+user_set
date_joined: DateTimeField
email: EmailField
first_name: CharField
is_active: BooleanField
is_staff: BooleanField
last_name: CharField
username: CharField
0..*
Permission
+
__unicode__( ) : self.name
+permissions
0..*
+groups
+group_set 0..*
0..*
dj ango.contrib.auth.models::Group
+
Figura 17 Modelo de autorizacin de usuarios Django
Django guarda los accesos a los mtodos en la tabla de base de datos

Permission. Estos permisos estn agrupados en la tabla Group y Group agrupa a los
usuarios en User. As un usuario tiene accesos dependiendo de los Group asignados.
La figura 18 muestra el modelo de datos que el backend web seguro usa para
el control adecuado de accesos a sus usuarios en la nube.
78
class sad/models.py cloud
params/models.py::Person
-
birth_date: DateField
identity_num: CharField
photo: ImageField
__str__( ) : self.first_name, self.last_name, self.identity_num
+menu_set 0..*
+person
Menu
+
AbstractUser
+user 0..1
__unicode__( ) : self.title
+menu_set
0..1
+parent 0..1
User
0..*
last_headquar_id: CharField
last_module_id: CharField
1
+permission
+user_set
0..1
date_joined: DateTimeField
email: EmailField
is_staff: BooleanField
username: CharField
0..*
0..*
Permission
+
UserEnterprise
+permissions
0..*
+userenterprise_set
0..*
0..*
+userenterprise_set
+groups
+enterprise
+group_set 0..*
0..* +group
1
space/models.py::Enterprise
+
enumeration
MODULE_CHOICES
BACKEND = Backend Manager
WEB = Web informativa
VENTAS = Ventas
+groups
0..*
+initial_groups
0..*
is_actived: BooleanField
logo: ImageField
name: CharField
tax_id: CharField
0..*
+module_set
0..*
+initial_groups_module_set 0..*
+enterprise_set
Module
+
+module_set
0..*
+solutions
0..*
space/models.py::Solution
-
created_at: DateTimeField
description: CharField
is_actived: BooleanField
+solution
name: CharField
0..1
price: FloatField
test_date: DateTimeField
test_image: ImageField
updated_at: DateTimeField
Figura 18 Modelo de autorizacin de usuarios de aplicaciones SaaS

En sntesis, el backend extiende la seguridad de Django para aplicaciones
SaaS, personalizando los servicios y los mens dinmicos del sistema. Esto permite
reutilizar y extender la funcionalidad de los componentes de seguridad de Django.
79
Como Django, guarda los accesos a los mtodos en la tabla de base de datos
Permission. Estos permisos estn agrupados en la tabla Group y Group agrupa a los
usuarios. As un usuario tiene accesos dependiendo los Group asignados.
Los Group (perfil de usuario) son agrupados en Module, y los Module en
Solution. Cuando se asigna un Solution a una Enterprise, este conoce los Group y
Permission de sus Modules.
UserEnterprise, permite conocer los Group de un User para una Enterprise
actual. La Enterprise actual se almacena temporalmente en la clase UserToken
cuando el User la elija.
class UserToken:
"""
Clase que permite almacenar y recuperar los permisos a datos de
las empresas solicitados por los usuarios.
"""
@staticmethod
def set_enterprise_id(request, enterprise_id):
request.session['enterprise_id'] = enterprise_id
@staticmethod
def get_enterprise_id(session):
return session.get('enterprise_id', False)
El mtodo load_access permite cargar estos datos de forma segura:

from django.contrib.auth.decorators import login_required
from apps.sad.models import BACKEND
from apps.space.models import Headquar
@login_required(login_url="/accounts/login/")
def load_access(request, headquar_id, module_id):
...
# cargando permisos de datos para el usuario
headquar = Headquar.objects.get(id=headquar_id)
UserToken.set_enterprise_id(request,
headquar.enterprise.id)
...
80
module = Module.objects.get(id=module_id)
if BACKEND == module.module:
return
HttpResponseRedirect("/mod_backend/dashboard/")
...
Una vez que el usuario elija la Enterprise y el Module a la que est ingresando,
se carga el Menu para el User.
5.6
Demostracin y validacin de la seguridad

La Demostracin y validacin de la seguridad del backend, fueron realizados
en la reunin del Project definition para el proyecto Qualpaca.

En la pruebas de seguridad del mdulo backend, de los 13 riesgos de seguridad
o vulnerabilidades identificados, todos fueron controlaron por completo por los
componentes de seguridad implementados.
Los nuevos riesgos de seguridad encontrados fueron respecto a las
particularidades de proteccin para los mdulos del Qualpaca, lo cual se explica en
el siguiente captulo.
En las pruebas de intrusin de mdulo backend, de los 13 riesgos de seguridad
fueron mitigadas, logrando el 100% de vulnerabilidades mitigadas (respecto a las
trece vulnerabilidades).
Las lneas de cdigo el que cumplen los estndares de codificacin fueron
evaluados usando la herramienta PEP8 de Python. Logrando tener de 3 a 10 lneas
que no respetan los estndares de PEP8 de ms de 100 lneas de cdigo obteniendo
el 90% de cumplimiento.
En cuanto al cumplimiento del estilo de codificacin de los mtodos, no se
cuenta con herramientas para dicho cometido. Por lo que mediante una revisin
manual, se pueden observar el cumplimiento al 90%.
5.7
Resumen
El mdulo backend web seguro defini las caractersticas arquitectnicas de
seguridad de una aplicacin web, as como el estilo de codificacin para el resto del
proyecto.
81
CAPTULO 6
VALIDACIN DEL MODELO PROPUESTO
WSM-DEV PARTE 2
6.1
Introduccin
En este captulo se describe la aplicacin y validacin de la segunda parte del
modelo propuesto WSM-DEV; sobre los grupos de procesos 2, 3 y 4. La primera parte

del modelo se aplica y se valida en el anterior captulo. A partir de este backend se
inicia el ciclo iterativo de los tres grupos de procesos del modelo WSM-DEV.
Para ambas partes se realizan mediante el desarrollo de una aplicacin web
para la Cadena Productiva de Alpacas (patrocinado por CONCYTEC y la UPeU en
el ao 2013) denominada Qualpaca versin 1.0
Con la aplicacin y validacin de esta segunda parte del modelo WSM-DEV se
logr refinar las actividades y artefactos de dicho modelo.
6.2
Anlisis de riegos de seguridad

Luego de definir y validar los requisitos de Qualpaca, se analizaron los activos
de informacin que requieren de cierta proteccin, ya que el backend web seguro

contaba con componentes para dar seguridad a los recursos y datos que maneja
Qualpaca; es decir, el backend, permiti analizar directamente los riesgos de
seguridad para el negocio.
Estos entregables puede verse en los anexos C1 al C9. Adems, se adjunta
parte de los dems entregables del proyecto en los anexos C10 al C12.
Para el desarrollo de la aplicacin Qualpaca, por motivos de tiempo, no se
aplic el TDD, es por eso que para distribuir las tareas se realiz el diseo del sistema
a partir de los componentes del backend web seguro. Cada componente del diseo
del sistema qued debidamente documentado; las reglas de negocio y las
restricciones de seguridad, todo ello bajo el estilo de codificacin y la arquitectura de
la aplicacin.
82
Para una mejor distribucin del mantenimiento de los registros de alpacas en

el sistema, se decidi asignar uno o ms grupos de alpacas a un usuario tcnico del
sistema, y como consecuencia se present el siguiente riesgo de seguridad: que otro
usuario tcnico modifique los registros de alpacas de otro grupo de alpacas. Cuyo
impacto es alto, pues los datos de la alpaca son fundamentales para el mejoramiento
de la fibra.
6.3

Mantener el registro de riesgos de seguridad, ayud la implementacin de los
componentes de seguridad. El motivo por la cual se incorpora en los requisitos es

justamente para su testeo y validacin.
Para Qualpaca, solo se extendi la proteccin del componente UserToken con
la finalidad de validar la manipulacin de datos no solo nivel de sucursal o sede o
rebao, sino tambin a nivel de grupos o manadas de un rebao.
El resto de actividades de la fase de implementacin fueron las capacitaciones
para el uso adecuado de los componentes de seguridad del backend web seguro.
La revisin y validacin de los componentes de seguridad durante la
implementacin se realiz juntamente con las pruebas manuales por parte del equipo
de pruebas.
6.4
Demostracin y validacin de la seguridad

Los resultados de la fase de demostracin y validacin de la seguridad, fueron
realizados juntamente con la demostracin y retrospectiva del Sprint de Scrum.

Los registros de riesgos de seguridad, y componentes de seguridad de los
anexos B2, B2, C2 y C3 fueron los checklist para verificar y validar los objetivos de
seguridad para la iteracin. Como todo el desarrollo se hizo una iteracin de 4
semanas, durante la semana 5, se hicieron las correcciones encomendadas.
En la pruebas de intrusin, de los 13 riesgos de seguridad del Backend, 12 se
controlaron por completo para los procesos de negocio del Proyecto Qualpaca. Esto
equivale al 92.30% de vulnerabilidades controladas o mitigadas. El riesgo de
seguridad RS03 Referencia Directa Insegura a Objetos no fue controlado a cabalidad
por lo que se agreg nuevos mtodos al componente UserToken. Con este
componente se logr el 100% de vulnerabilidades mitigadas.
Se estimaron veinte (20) puntos historia para una Sprint de cuatro semanas,
logrando concretar todas las tareas en el plazo acordado, realizando as veinte
83
puntos-historia de un mes. Sin embargo, debido los cambios en los requerimientos

se tuvo que definir seis das ms para dar por finalizado el proyecto.
Las lneas de cdigo de Qualpaca que cumplen los estndares de codificacin
fueron evaluados usando la herramienta PEP8 de Python. Logrando tener de
cincuenta a cien lneas que no respetan los estndares de PEP8 de ms de 400
lneas de cdigo obteniendo apenas un 75% de cumplimiento. Esto se debe a que
no se us el PEP8 desde el inicio del proyecto.
manual, se pueden observar el cumplimiento al 80%.
Se logr desarrollar los nueve artefactos que solicita el modelo entre otros
entregable que el Scrum requiere. Para la definicin del proyecto Qualpaca se us el
formato para el acta de constitucin del proyecto del PMBoK (Project Management
Body of Knowledge).
6.5
Resumen
La aplicacin del modelo WSM-DEV, gracias a sus plantillas y a su backend
profesional aceler el desarrollo y se obtuvo una aplicacin web moderna y confiable.
84
CAPTULO 7
RESULTADOS Y DISCUSIN
En este captulo se presenta y se discute los resultados del presente trabajo de

tesis descritos en los captulos 5, 6 y 7. Entre los principales resultado son:
7.1
Nuevo modelo prctico para desarrollar aplicaciones web seguras en el

menor tiempo.
El modelo propuesto denominado WSM-DEV, resume en 4 prcticas generales
la integracin de la seguridad en el ciclo de vida de desarrollo de aplicaciones web,

mientras que la SSE-CMM contiene alrededor de 60 prcticas base de seguridad,
organizadas en 11 reas de proceso que cubren las reas principales de la ingeniera
de la seguridad. Lo que conlleva invertir mayores recursos de personal.
El modelo WSM-DEV provee de plantillas para cada uno de sus artefactos y,
de componentes de seguridad y utilitarios para la asignacin directa de las tareas de
desarrollo de los requerimientos del negocio, permitiendo conocer la parte prctica
de cmo se aplica cada prctica; mientras que la SSE-CMM solo define qu prcticas
se debe emplear. La estrategia clave del modelo WSM-DEV consisten en
implementar primeramente el mdulo backend mitigando trece vulnerabilidades de
toda aplicacin web que correr en la nube. Para el caso de implementacin del
backend en el lenguaje de programacin Python, estas vulnerabilidades se mitigaron
al 100% y para su aplicacin en el proyecto Qualpca, este porcentaje se redujo al
92.30% debido a las particularidades de la seguridad del negocio de Qualpaca.
As mismo, se intent iniciar el desarrollo de Qualpaca sin contar con un
backend preliminar conduciendo a un desorden en los estndares y estilos de
codificacin ya que cada programador hizo su mejor esfuerzo. Aunado al
desconocimiento de las principales vulnerabilidades y del lenguaje Python, se
comenz a notar el retraso. Se contabiliz 6 meses de retraso (mayo a
noviembre/2013). Mientras se esperaba la primera versin del backend se fue
diseando todo el sistema quedando cambios referentes al uso adecuado de los
componentes del backend. Terminado el backend para Django, se tuvo una semana
de capacitacin y seguidamente se comenz a desarrollar las tareas, cuya suma total
del trabajo de todas las tareas ascendi los 20 puntos historia, quedando terminado
en 5 semanas.
85
Las lneas de cdigo de Qualpaca que cumplen los estndares de codificacin

fueron evaluados usando la herramienta PEP8 de Python. Logrando tener de 50 a
100 lneas que no respetan los estndares de PEP8 de ms de 400 lneas de cdigo
obteniendo apenas un 75% de cumplimiento. Esto se debe a que no se us el PEP8
desde el inicio del proyecto. En la depuracin del backend se pudo usar la
herramienta PEP8 y se logr un 90% en el cumplimiento del uso adecuado del estilo
de codificacin
manual, se pueden observar el cumplimiento al 80% en el proyecto Qualpaca y a un
90% en el mdulo backend
7.2
Mdulo backend de administracin y configuracin de aplicaciones web

tipo SaaS con Django.
El mdulo backend web seguro para Python del modelo WSM-DEV, cubre trece
vulnerabilidades recurrentes en aplicaciones web y con la flexibilidad de extender a

casos especficos del negocio; mientras que las API de seguridad para Java de la
OWASP cubre solo diez vulnerabilidades y algunas vulnerabilidades para PHP. Para
Java o PHP solo se cuenta con componentes pero ningn backend.
Se extendieron las funcionalidades de los componentes nativos de seguridad
de Python como de Django en nuevos componentes de seguridad con la finalidad de
definir un estilo de codificacin simple pero robusta. Tambin se crearon nuevos
complementos de seguridad para mitigar las trece vulnerabilidades identificadas en
aplicaciones web tipo SaaS. Todos los componentes de seguridad implementados
en el Backend mitigaron las trece vulnerabilidades previamente identificadas (en el
anexo B2) mitigando el 100% de vulnerabilidades (respecto a las trece
vulnerabilidades).
86
CAPTULO 8
CONCLUSIONES Y RECOMENDACIONES
En este captulo se presenta las conclusiones principales de esta tesis, y

recomendaciones que orienten una mejor integracin de la seguridad dentro del
proceso WSM-DEV, as como para nuevas investigaciones sobre la construccin de
aplicaciones web seguras.
8.1
8.1.1
Conclusiones
Se elabor un modelo para el desarrollo de aplicaciones web seguras.
El modelo de Desarrollo de aplicaciones web seguras WSM-DEV, es el
principal aporte del trabajo de esta tesis. El modelo define cuatro principios y cuatro
prcticas de seguridad durante el ciclo de desarrollo para obtener una aplicacin web
confiable en el menor tiempo. Los procesos del SSE-CMM guiaron la definicin de
los componentes del WSM-DEV y las diez vulnerabilidades ms frecuentes de la
OWASP definieron las caractersticas de una aplicacin web confiable. Para una
aplicacin rpida, se incluyen plantillas de los artefactos del modelo y una serie de
componentes de seguridad web implementados en el lenguaje de programacin gil
Python. La aplicacin de este modelo en el proyecto Qualpaca, patrocinado por
CONCYTEC y la UPeU, se logr refinar sus actividades y artefactos y asignar un
peso adecuado a los indicadores de medicin.
De los 13 riesgos de seguridad del backend, 12 se controlaron por completo
para los procesos de negocio del proyecto Qualpaca lo que equivale al 92.30% de
vulnerabilidades mitigadas. El riesgo que no fue completamente mitigado fue el RS03
Referencia directa insegura a objetos por lo que se agreg nuevos mtodos al
componente de seguridad UserToken, logrando mitigar el 100% de vulnerabilidades
(respecto a las 13 vulnerabilidades previamente definidas).
8.1.2
La aplicacin del modelo WSM-DEV es mucho ms simple con modelos

giles de software.
El principal grupo de procesos del WSM-DEV es el anlisis de riesgos de
seguridad, donde se identifican las amenazas y vulnerabilidades de la aplicacin web

para la iteracin; estas actividades pueden integrarse a las reuniones de planificacin
de la iteracin y seguir los procesos del desarrollo bajo una modelo de software gil.
87
Sin embargo, tambin puede integrase a partir de la fase de requisitos en un modelo

de software formal de ingeniera.
8.1.3
Se desarroll un backend web seguro sobre Django para aplicaciones web

de tipo SaaS
El mdulo del backend para administrar aplicaciones web permite gestionar de
manera rpida y segura a los usuarios, perfiles, permisos, recursos del sistema,
mdulos del sistema, mens dinmicos, empresas, sucursales entre otros
parmetros de configuracin del sistema.
Este mdulo se desarroll en dos meses por una sola persona, y permiti la
implementacin directa de los requisitos del proyecto Qualpaca, terminando en cinco
semanas todo el desarrollo.
El estilo de codificacin del backend, permiti la concentracin del equipo y
realizar las tareas del mdulo de produccin del proyecto Qualpaca. Logrando
desarrollar 20 puntos historia en un mes.
El cumplimiento de los estndares de codificacin se verific mediante la
herramienta PEP8 de Python, alcanzado un 90% del cumplimiento.
Finalmente, gracias al backend que sigue un estilo de codificacin, pudo ser
interiorizado en todos los programadores alcanzando ms del 80% del cumplimiento.
8.1.4
Se cuenta con un catlogo de componentes de seguridad

El catlogo de componentes de seguridad, especificado en el anexo B3, queda
como libreras tiles para ser aplicado o gua para las nuevas aplicaciones web que
mitigan trece principales vulnerabilidades de las aplicaciones web.
8.2
8.2.1
Recomendaciones
Completar los test automatizados para el backend web seguro
Para aplicar poder desarrollar una aplicacin web completamente con TDD,
primero se debe terminar de implementar los test de unitarios del mdulo backend.
8.2.2
Backend web seguro para arquitecturas Single Page Application (SPA)

El futuro de la web es JavaScript, con AngularJS como el framework ms
popular; por lo que se necesita una backend con estas caractersticas.
88
8.2.3
Backend Web seguro con otros frameworks para Python u otros lenguajes
de programacin.
Dado que en el mercado de Per, los lenguajes de programacin ms
preferidos son .Net y Java, se requiere un backend sobre estas plataformas.

8.2.4
Antes de iniciar el desarrollo de un proyecto de software se necesita un

backend.
Para desarrollar un software, lo primero que el equipo de desarrollo debe contar
es con un backend con los componentes y libreras que una aplicacin web necesita,
sobre todo, debe reflejar el estilo de codificacin que facilitar la revisin de la calidad
del cdigo. Este backend permite, atender directamente los requisitos del negocio.
Se recomienda definir una persona o un equipo que construya los nuevos
componentes y utilitarios comunes de la nueva aplicacin e integrarlos en el backend
a modo de ejemplo, de modo que el equipo de desarrollo se concentre en atender
los requisitos del proyecto.
89
REFERENCIAS
Laudon K, Laudon J. 2012. Sistemas de Informacin Gerencial. 12 ed. Mxico:
Pearson Educacin. 640 p. ISBN 978-607-32-0949-6.
OWASP, 2013. Una Gua para Construir Aplicaciones y Servicios Web Seguros. The
Open Web Application Security Project [OWASP]. 4da ed. 311 p. Edicin en
espaol
OWASP, 2013. OWASP Top 10 2013 Los diez riesgos ms importantes en
Aplicaciones Web . 22 p. Edicin en espaol
OWASP, 2008. Gua de Pruebas OWASP. 3ra ed. 372 p. Edicin en espaol
OpenSAMM, 2010. Softwaer Assurance Maturity Model. OWASP. 1ra ed.
Ardi S, Shahmehri N, 2008. Integrating a Security Plug-in with the OpenUP/Basic
Development Process. Linkpings: Linkpings University. Department of
computer and information science. 8 p.
Ardi S, 2008. A Model and Implementation of a Security Plug-in for the Software Life
Cycle. Thesis No. 1353. Linkpings: Linkpings University. 124 p.
Gasca G. 2006. Anlisis de Riesgos para el Desarrollo de Software Seguro.
Tovar E y colaboradores, 2006. Desarrollo de Productos de Software Seguros en
Sintona con los Modelos SSE-CMM, COBIT E ITIL
ISO 27001, 2005. Tecnologa de la Informacin Tcnicas de seguridad Sistemas
de gestin de la informacin Requerimientos. 1ra ed. 41 p. Uso para fines
didcticos.
ISO 17799, 2005. Tecnologa de la Informacin Tcnicas de seguridad Cdigo
para la prctica de la gestin de la seguridad de la informacin. 2ra ed. 170
p.
Yepes R y Chavarra R, 2010. Un Enfoque para el Desarrollo gil de Aplicaciones
Web, Usando Scrum, Extreme Programing y Herramientas Open Source
sobre Plataforma Java: Caso de Estudio Mejoramiso Next. Facultad de
Ingeniera, Universidad de Antioqua
Schwaber K, Sutherland J. 2010. Scrum Guide: Scrum: Desarrollado y mantenido por
Ken Schwaber y Jeff Sutherland. 24 p.
Schwaber K, Sutherland J. 2011. Scrum Guide Update 2011. 1 p.
90
Schwaber K, Sutherland J. 2011. The Scrum Guide. The Definitive Guide to Scrum:
The Rules of the Game. 17 p.
Palacio J, Ruata C. 2011. Scrum Manager Gestin de Proyectos. Rev 1.4. 131 p.
Palacio J. 2007. Flexibilidad con Scrum. 229 p.
ISO 9000, 2005. Sistemas de gestin de la calidad Fundamentos y vocabulario.
Ginebra, Suiza. 42 p.
Caldern M, 2007. Una Taxonoma de Requerimientos de Seguridad de Software.
Escuela de Ciencias de la Computacin e Informtica, Universidad de Costa
Rica. Artculo de 9 pginas.
Schwaber K. Agile Project Management with Scrum
Schwaber K. Agile Software Development with Scrum
Schwaber K. The Enterprise and Scrum
White S y Miers D, 2007. BPMN Gua de Referencia y Modelado. OMG, Quality
Softcover Perfect Bound. 226 p.
INTECO, 2010. Implantacin de un SGSI en la empresa. Instituto Nacional de
Tecnologas de la Comunicacin. Espaa.
NEXUS, 2006. Parmetros fundamentales para la implantacin de un Sistema de
Gestin de Seguridad de la Informacin segn ISO 27001:2005
http://www.nexusasesores.com/docs/ISO27001-norma-e-implantacion-SGSI.pdf
visitado el 18 de abril de 2010.
NTP-ISO, 2006. Tecnologa de la informacin. Procesos del ciclo de vida. (NTPISO/IEC 12207:2006). 2da ed.
Barnum, S., McGraw, G., 2005, Knowledge for Software Security,IEEE Security &
Privacity, 74-78
McGraw, G., 2006, Software Security. Building Security In.
Viega J.; McGraw, G., 2001, Building Secure Software: How to avoid security
problems the right way,
Kan S. 1995. Metrics and Models in software Quality Engineering. Addison-Wesley
Kniberg H, Skarin M. 2010. Kanban y Scrum obteniendo lo mejor de ambos. C4Media
Inc. InfoQ. ISBN: 978-0-557-13832-6
Kniberg H. 2007. Scrum y XP desde las trincheras. C4Media Inc. InfoQ
91
Paulsson J, Westberg C. 2010. Secure Scrum During the Development of a

Configuration Tool for Generic Workflow.
Pressman R. 2002. INGENIERA DE SOFTWARE: UN ENFOQUE PRACTICO.
Shaw M., Garlan D. 1997. Software ArchitecturePerspective son an Emerging
Discipline. Prentice Hall.
Succi G, Marchesi M. 2000. Extreme Programming Examined. IBM, 2011. Security
Compliance.
http://www-01.ibm.com/software/tivoli/library/demos/
ibmscdemo/IBM_Security_Compliance.html Consultado el 04 de Octubre de

2011.
Llorente I, 2008. Seguridad en las Tecnologas de la Informacin. XX Seminario
Duque de Ahumada Seguridad y Nuevas tecnologas. http://dsaresearch.org/lib/exe/fetch.php?id=people%3Allorente%3Aresearch&cache=c
ache&media=people:llorente:seguridad_en_las_tecnologias_de_la_informaci
on.pdf, Consultado el 08 de Septiembre de 2011.
Cheng K. 2007. Baking in Security During the Systems Development Life Cycle. Booz
Allen
Hamilton.
[www.stsc.hill.af.mil/crosstalk/2007/03/index.html].
Consultado el 08 de Septiembre de 2011

Microsoft, 2011. Microsoft Security Development Lifecycle (SDL) Process
Guidance.
http://msdn.microsoft.com/en-
us/library/windows/desktop/84aed186-1d75-4366-8e61-8d258746bopq.aspx
Microsoft,
2011.
Security
Development
Lifecycle
for
Agile
Development
http://msdn.microsoft.com/en-us/library/windows/desktop/ee790621.aspx
Puyo R, 2009. Sistema de Gestin de la Seguridad de la Informacin SGSI ONP.
Oficina
de
Normalizacin
Previsional
ONP.
http://www.pecert.gob.pe/archi/talle012009/04-caso-onp.pdf Consultado el 08
de Septiembre de 2011
Piero B, 2009. La tecnologa como facilitador del cumplimiento de los controles de
un
SGSI.
crsi.ie.edu/files/documentacion/Catedra_de-riesgos_Oracle.ppt

Fernndez J, 2006. OWASP presentacin del proyecto. Conferencias FIST
https://www.owasp.org/images/b/b6/OWASP-Testing-Project_v1.pdf
92
Beck K y Colaboradores, 2001. Manifiesto por el Desarrollo gil de Software.

http://agilemanifesto.org/iso/es/. Consultado el 06 de Octubre de 2011.
Meier J y Colaboradores, 2007. MSF para desarrollo gil de software.
http://msdn.microsoft.com/en-us/library/bb668964.aspx Consultado el 06 de
Octubre de 2011.
Scott
W.
2005.
Scott
W.
Ambler's
Home
Page.
http://www.ambysoft.com/scottAmbler.html Consultado el 06 de Octubre de

2011
Palacio
J,
2005.
Procesos
tcnicas
para
desarrollo
de
software.
http://www.navegapolis.net. Consultado el 06 de Octubre de 2011.

Qualys
Guard.
2008.
Web
Application
Scanning.
http://www.qualys.com/docs/QG_WAS_DS_ES.pdf. Consultado el 11 de
Octubre de 2011.
BConsultores,
2011.
Arquitectura
de
Seguridad.
Balarezo
Consultores.
http://bconsultores.com/pages/arquitectura_de_seguridad.pdf Consultado el
11 de Octubre de 2011.
93
GLOSARIO
Riesgo: Es la estimacin del grado de exposicin de un activo o recurso, a que una

amenaza se materialice sobre l, causando daos a la organizacin. El riesgo indica
lo que le podra pasar a los activos si no se protegen adecuadamente.
Amenaza: Es la posibilidad de ocurrencia de cualquier tipo de evento o accin que
puede producir dao (material o inmaterial) sobre los elementos (activos, recursos)
de un sistema.
Vulnerabilidad: Son las debilidades, las condiciones y caractersticas del sistema
mismo (incluyendo la entidad que lo maneja), que lo hace susceptible a amenazas,
con el resultado de sufrir algn dao.
Impacto: Es la consecuencia de la materializacin de una amenaza sobre un activo.
Riesgo intrnseco: Es la posibilidad de que se produzca un impacto determinado en
un activo.
Salvaguarda: Son las prcticas, procedimientos o mecanismos que reducen el
riesgo y disminuyen el impacto y la probabilidad.
Riesgo residual: Es el riesgo que queda tras la aplicacin de salvaguardas.
Ataque: Es una amenaza que se convirti en realidad, es decir cuando un evento se
realiz. No dice nada si o no el evento fue exitoso.
Autenticidad: La legitimidad y credibilidad de una persona, servicio o elemento debe
ser comprobable.
Confidencialidad: Datos solo pueden ser legibles y modificados por personas
autorizados, tanto en el acceso a datos almacenados como tambin durante la
transferencia de ellos.
Integridad: Datos son completos, non-modificados y todos los cambios son
reproducibles (se conoce el autor y el momento del cambio).
Disponibilidad: Acceso a los datos debe ser garantizado en el momento necesario.
Hay que evitar fallas del sistema y proveer el acceso adecuado a los datos.
Elementos de informacin: Tambin Activos o Recursos de una institucin que
requieren proteccin, para evitar su prdida, modificacin o el uso inadecuado de su
94
contenido, para impedir daos para la institucin y las personas que salen en la
informacin. Se distingue y divide tres grupos, a) datos e informacin, b) sistemas e
infraestructura y c) personal.
Gestin de riesgo: Mtodo para determinar, analizar, valorar y clasificar el riesgo,
para posteriormente implementar mecanismos que permitan controlarlo. Est
compuesta por cuatro fases: 1) anlisis, 2) clasificacin, 3) reduccin y 4) control de
riesgo.
Seguridad informtica: Procesos, actividades, mecanismos que consideran las
caractersticas y condiciones de sistemas de procesamiento de datos y su
almacenamiento, para garantizar su confidencialidad, integridad y disponibilidad.
Auditora de seguridad: Permitir el registro de eventos (hay que identificar cules
pueden ser interesantes desde el punto de vista de la seguridad).
Gestin de seguridad: Definicin de perfiles de usuario y niveles de acceso
asociados.
Autodefensa: La aplicacin debe incluir sistemas de validacin de su funcionamiento
y fallar de manera segura si esa validacin no se cumple.
Control de acceso: Soporte de sistemas que limiten el nmero y tipo de sesiones,
el nivel de concurrencia y que proporcionen informacin sobre sesiones anteriores al
usuario para ayudar a la deteccin de intrusos.
Estndares de desarrollo: Define estratgicamente el nombre de los identificadores
del sistema, como son variables, clases, funciones, tablas, contantes, etc.
Estilo de codificacin: Provee un orden de las instrucciones del programa para una
clase o mtodo, en funcin de los estndares de desarrollo.
UML: Es el lenguaje de modelado de sistemas de software ms conocido y utilizado
en la actualidad; est respaldado por el OMG (Object Management Group).
95
ANEXOS
10 Anexo 1 Matriz de consistencia del proyecto
Ttulo de la investigacin: Un modelo para el desarrollo de aplicaciones web seguras

Problema
Objetivo
Marco terico
Indicadores
Metodologa
Cuales son las
O. General.
Antecedentes:
Porcentajes de
Tipo de
dificultades para
Elaborar un modelo de
SSE-CMM
vulnerabilidades
investigacin:
aplicar las guas
trabajo
OWASP
controladas
Aplicada
o modelos de
desarrollar aplicaciones
seguridad?
web seguras (menores
Velocidad del
Por qu las
vulnerabilidades) y en el
equipo gil de
Mtodo:
aplicaciones con
menor tiempo basadas
desarrollo
Investigacin
requisitos
en los procesos de la
complejos y con
metodologa SSE-CMM,
Porcentaje
lmites de tiempo
el Proyecto OWASP y
mtodos
han contribuido al
experiencias vividas.
cumplen el estilo
prctico
para
Evaluativa
incremento de
de
que
de codificacin
fallas o
Objetivos especficos:
Porcentaje
vulnerabilidades
Analizar las prcticas del
lneas de cdigo
de software?
SSE-CMM respecto al
el que cumplen
ciclo
los
de
vida
del
Cuales son las
Implementar los
causas
controles de seguridad
que
ocasionana
segn la OWASP top 10
grandes prdidas
para un
monetarias,
lenguaje/framework
hasta la prdida
especfico.
de confianza de
Establecer los principios
los
y prcticas del modelo a
clientes,
empleados
socios
negocio?
y
de
el
estndares
de codificacin
proponer.
Refinar
de
modelo
mediante su aplicacin
en un proyecto web tipo
SaaS.
96
Anexo A1 Requisitos del sistema

Proyecto: ______ --_______________________________________________________
Fecha de actualizacin: ____/_____/______
Cdigo
/Sprint
Requisito
RF01
/1
Requisito 1:
Descripcin:
RF02
/1
Pruebas de aceptacin y de seguridad:

1.
2.
Requisito 2:
Descripcin:
RF03
/1

1.
2.
Requisito 3: (reemplazo por RF04)
Descripcin:
RF04
/2

1.
2.
Requisito 4: (cambio en reemplazo de la RF03)
Descripcin:
1.
2.
97
Estado
Estimac.
Prioridad
Nuevo
8
puntos
historia
1000
En
Progreso
6
puntos
historia
900
Retirado
4
puntos
historia
800
Hecho
4
puntos
historia
700
Anexo A2 - Registro de riesgos de seguridad (amenazas y vulnerabilidades)

Proyecto: ______ --_______________________________________________________
COD
Riesgo de seguridad
A: Amenza V: Vulnerabilidad
Probabilidad: Alta, Media, Baja
Impacto: Alta, Media, Baja
98
Tipo
(A/V)
Probab
ilidad
Impac
to
Priori
dad
1000
Anexo A3 - Registro de componentes de seguridad

Proyecto: ______ --_______________________________________________________
COD
Componente de
seguridad
Riesgos de seguridad
99
Anexo A4 Arquitectura de la aplicacin

1. Informacin general
Cdigo y nombre del proyecto:
2. Historial de revisiones
Versin
- Fecha
- Elaborado por
3. Arquitectura de la aplicacin MTV (equivalente a MVC)

Capa
Modelo: M
Vista: V
Tecnologa
Django Model
Django Manager
Django Test/Unit Test
Django View
Django Form
SAD Backend
Django Test
Template: T
Django Template
Bootstrap
JQUERY
AJAX+ JSON
SAD Frontend
Selenium
100
Funcin
Entidades y mapeamientos
Extiende utilitarios del Model
Pruebas unitarias del modelo
Controlador de solicitudes y respuestas
Reglas de negocio y restricciones
Solicitudes y respuestas con AJAX
Restricciones de seguridad
Logs
Mensajera y Notificaciones
Pruebas de integracin de las vistas y de
los formularios
Interfaces grficas de usuario para las
entradas de datos y mostrar resultados
Diseo responsivo multidispositivo
Utilitarios diversos
Solicitudes y respuestas asncronas
Generacin de objetos HTML en tiempo
de ejecucin
Hojas de estilos personalizados
Pruebas funcionales en la Web
Anexo A5 Estndares de desarrollo

Versin
- Fecha
- Elaborado por
3. Trminos de definicin de identificadores

ID
Trmino
Ejemplo
Proyecto
Paquetes
Base de datos
Tablas
Atributo PK
Atributo
Atributo FK
Paquetes
Clases
Variables
Contantes
Mtodo
<nombre_proyecto>
<nombre_carpeta>
<nombre_db>
<prefix_nombre_tabla>
id
<nombre_atributo>
<tabla>_id
<nombre_carpeta>
<NombreClase><NombreCapa/vacio>
<nombre_variable>
<NOMBRE_CONSTANTE>
<nombre_metodo>(var_nombre)
Enumerators
<NOMBRE_ENUM>
Archivos
Interfaces
<nombre_pagina>.<py/html>
I<NombreClase><NombreCapa/vacio>
101
agil_cont
catalogo_productos
agil_cont_db
common_natural_person
id
functional_code
natural_person_id
catalogo_productos
class NaturalPerson
functional_code
DEFAULT="DNI"
def add();
def edit();
def delete();
def get_by_id(id);
def get_list_by_filter(filter);
DEFAULT="DNI"
CE="CE"
OTHERS="OTHERS"
IDENTITY_CHOICES = (
(DEFAULT, "D.N.I."),
(CE, "C.E."),
(OTHERS, "Otro.")
)
natural_person.html
INaturalPersonService
Anexo A6 Mtodo de trabajo del equipo

Versin
- Fecha
- Elaborado por
3. Equipo de trabajo
Rol
Product Owner
Scrum Master
Dupla 1-Doc.
Dupla 2-Dev.
Dupla 3-Dev.
Nombre
Nombre del cliente
Nombre del Jefe del proyecto
Nomb. Programador 1
Nomb. Programador 2
Nomb. Programador 3
Nomb. Programador 4
Nomb. Programador 5
Nomb. Programador 6
Ciudad
Correo/Celular
Tiempo
50%
50%
50%
50%
100%
100%
50%
50%
4. Herramientas
Elemento
Portal de
gerenciamiento
Portal de
integracin
Modelo y
Prototipado
Lenguaje de
programacin
Frameworks
Framework
responsivo
Base de datos
IDE
Comunicaciones
Herramienta
Assembla.com
Hosting
Github.com
https://github.com/submitconsulting/django_backend_project
Enterprise
Architect 7.5
Balsamiq
Python
http://djangobackend-model.appspot.com
https://www.assembla.com/spaces/djangobackend
Django 1.6.2
Bootstrap
MySQL 5.x
Sublime Text 2
Facebook
https://www.facebook.com/groups/262927820527361
102
5. Retos a superar
Desafo
Respecto a la metodologa scrum
Respecto al equipo distribuido

(parcial o totalmente, horarios,
idiomas diferentes)
Solucin
Definir la duracin del sprint a 4 semanas
Lea la wiki y utilice el foro de discusin del portal de
gerenciamiento (Mensajes)
Definir las tareas en base a una unidad de trabajo
diario o semanal (que incluya testes)
Informar el estado de las tareas en el portal de
gerenciamiento, incluye horas restantes.
Enviar el reporte de trabajo diario o semanal
(StandUp)
Documentacin en ingls
Respecto a las herramientas de

trabajo
Respecto a la experiencia de los
desarrolladores
Respecto a la documentacin
Falta de compromiso del cliente
Consigue una llamada con Hangout, Facebook o

Skype
Entrenamiento en las herramientas a usar
Cada cdigo, diagrama, prototipos debe seguir el
estndar de desarrollo elegido
Entrenamiento en las tecnologas a usar
El diseo/prototipo/restricciones deben estar listos
y validados a un Sprint de anticipacin
Involucrar al cliente en las reuniones y demos
103
Anexo A7 Prototipos principales

Proyecto:
Mdulo:
Fecha:
Requisito 1:
Imagen N
Funcionalidad:
Aprobado por:
104
Anexo A8 Diseo del sistema

1
INFORMACIN GENERAL
Cdigo y Nombre del proyecto:
HISTORIAL DE REVISIONES
Versin - Fecha
ACTUALIZACIONES IMPORTANTES
LINKS DE DESCARGA O DE CONSULTA

Modelo [http://djangobackend-model.appspot.com/DBackend-20131115/index.htm]
Scripts
ESTRUCTURA DEL MODELO

Mdulo
---Modelo del dominio
--- ---app
--- --- ---Diagrama de entidades
---Modelo de clases
--- ---Capa(si es Models o Views(Views en MVC es Controllers))
--- --- ---app
--- --- --- ---Diagrama de clases de diseo
--- --- --- --- ---Ejemplo completo del diagrama (explica las relaciones a detalle)
---Requisitos
--- ---Requisitos funcionales
--- ---Requisitos no funcionales
---Interfaz de usuario
--- ---Capa(template para django)
--- --- ---app
--- --- --- ---entity o rol
--- --- --- --- ---prototipo(.html)
Diagrama Vista general del proyecto
Diagrama de procesos de negocio
105
Anexo A9 Formulario de lecciones aprendidas

Proyecto:
N Iteracin:
Qu sali bien en la Iteracin
1.
2.
Qu no sali bien en la Iteracin

1.
2.
Qu mejoras vamos a implementar en la siguiente Iteracin

1.
2.
106
Anexo B1 Requisitos del Sistema (mdulo backend web seguro)

Proyecto: Backengo
Fecha de actualizacin: __04__/__09__/__2013__
Cdigo
/Sprint
RF01
/1
Requisito
Estado
Gestin de permisos de usuarios

Descripcin:
Permite distribuir determinados permisos a un Grupo de usuarios para
que puedan utilizar a ciertas funcionalidades especficas del sistema
segn los permisos asignados a dicho Grupo.
Hecho
Para ello:
Definir los recursos (permisos en django) del sistema a partir del
mdulo "auth" de django
Definir los Grupos de usuarios a partir del mdulo "auth" de django
Definir los permisos de los Grupos de usuarios.
RF02
/1
RF03
/1

1.
Gestin de los planes de servicios SaaS
Descripcin:
Permite distribuir accesos a los usuarios de una determinada empresa
y/o asociacin para que pueda utilizar ciertas funcionalidades del
sistema segn los permisos asignados a un determinado Plan de
servicio.
Para ello:
Definir los Mdulos de la aplicacin
Definir los Permisos de los Mdulos
Definir el grupo de mdulos denominado Plan de servicio (Solution)
Definir los Mdulos del plan (Solution)
1.
Gestin de mens dinmicos
Descripcin:
Permite definir el Men de los mdulos para facilitar al usuario el
acceso a las funcionalidades del sistema
Hecho
Hecho
Para ello:
Definir Men para los recursos del sistema y organizados por Mdulos
RF04
/1
RF05
/1

1. Cuando se elige el mdulo y la sede o empresa o asociacin se
debe visualizar el Men del usuario segn los Permisos asignados al
usuario para dicha Sede/empresa/asociacin y Mdulo.
Abir una cuenta en el sistema
Descripcin:
Permite abir una cuenta para un nuevo usuario, nueva asociacin y
nueva empresa para que pueda utilizar las funcionalidades del sistema
segn el plan de servicio escogido.
Inicio de sesin
Descripcin:
Permite iniciar sesin de la aplicacin web que sirva para utilizar
ciertas funcionalidades especficas del sistema para el usuario
registrado.
107
Hecho
Hecho
Estimac.
(horas)
Prioridad
RF06
/2
RF07
/2
1. Cuando se inicia sesin de la aplicacin web, Se debe cumplir que

si usuario ingresa nombre de usuario y contrasea correctas, se
presenta el mensaje "Bienvenido, "+nombre de usuario, mostrando la
lista de empresas junto con los mdulos a los cuales tiene permiso.
2. Cuando se inicia sesin de la aplicacin web, Se debe cumplir que
si usuario ingresa nombre de usuario incorrecto o contrasea
incorrecta, se presenta el mensaje "Usuario o contrasea incorrectos".
Gestin de la estructura organizacional para la nube
Descripcin:
Permite establecer la estructura de la organiacin en asociaciones,
empresas y sedes
Para ello:
Permite que la asociacin defina otras empresas
Permite que la empresa agregue otras sedes, y para diversas
asociaciaciones
Permite que la asociacin/empresa cambie de Plan de servicio
Permite que la asociacin/empresa/sede defina usuarios bajo ciertos
perfiles o permisos
Gestin de usuarios
Descripcin:
Permite establecer los usuarios del sistema segn los roles y las
sedes/empresas/asociaciones permitidas.
Hecho
Hecho
Para ello:
Registrar, bloquear, reactivar usuarios a partir del mdulo "auth" de
django y bajo los permisos preasignados a la
sede/empresa/asociacin que se est administrando.
Estas validaciones de los permisos se logra gracias a los:
Componentes para asegurar los recursos de la aplicacin
Componentes para asegurar los datos de las empresas
(Token de acceso a datos)
RF08
/2
RF09
/2
Permite visualizar el seguimiento de los motivos de bloqueos y

activaciones de los usuarios
Permite la actualizacin del perfil de usuario y contrasea
1.
Gestin de sucesos del sistema
Descripcin:
Permite tener el registro de sucesos del sistema que guarde
informacin de las acciones de los usuarios.
Para ello:
Permite el registro, en archivos logs y tablas de base de datos, de las
acciones de los usuarios y las respuestas del sistema durante el uso
de la aplicacin
Permite la visualizacin de los sucesos filtrados por da.
Recuperar contrasea
Descripcin:
Permite recuperar contrasea del usuario para que pueda iniciar
sesin en la aplicacin web.
108
Hecho
Hecho
Anexo B2 - Registro de riesgos de seguridad (amenazas y vulnerabilidades)

Proyecto: Backengo
COD
RS01
RS02
RS03
RS04
RS05
RS06
RS07
RS08
RS09
RS10
RS11
RS12
RS13
Riesgo de seguridad
Inyeccin
Prdida de Autenticacin y Gestin de Sesiones
Secuencia de Comandos en Sitios Cruzados(XSS)
Referencia Directa Insegura a Objetos
Configuracin de Seguridad Incorrecta
Exposicin de Datos Sensibles
Ausencia de Control de Acceso a las Funciones
Falsificacin de Peticiones en Sitios
Cruzados(CSRF)
Uso de Componentes con Vulnerabilidades
Conocidas
Redirecciones y reenvos no validados
Repudio
Datos incompletos
Permisos inconsistentes
109
Tipo
(A/V)
A
A
A
A
A
A
A
A
Probab
ilidad
Alta
Alta
Alta
Alta
Alta
Alta
Alta
Alta
Impac
to
Alta
Alta
Alta
Alta
Alta
Alta
Alta
Alta
Priori
dad
1000
1000
1000
1000
1000
1000
1000
1000
Alta
Alta
1000
A
A
A
A
Alta
Alta
Alta
Alta
Alta
Alta
Alta
Alta
1000
1000
1000
1000
Anexo B3 - Registro de componentes de seguridad

Proyecto: Backengo
URL de la documentacin de los componentes de seguridad:
http://educaci-dns.com:8001/admin/doc
COD
CS01
Componente de seguridad
Django model.objects.filter
Django request. session
Inyeccin
Prdida de Autenticacin y Gestin de Sesiones
django.contrib.auth.authenti
cate
django.contrib.auth.login
django.contrib.auth.logout.
apps.utils.security.UserToken
django form
django filter safe
apps.utils.decorators.permiss
ion_resource_required
apps.utils.security.
SecurityKey
Django request. POST
Django.forms. ModelForm
SecurityKey
Django settings.DEBUG
django.conf.urls.url
SecurityKey
Django csrf_token
crispy form
django.conf.urls.url
Secuencia de Comandos en Sitios Cruzados(XSS)
Referencia Directa Insegura a Objetos
Configuracin de Seguridad Incorrecta
Exposicin de Datos Sensibles

Ausencia de Control de Acceso a las Funciones
Falsificacin de Peticiones en Sitios Cruzados(CSRF)
Uso de Componentes con Vulnerabilidades Conocidas

Redirecciones y reenvos no validados
110
Anexo B4 Arquitectura de la aplicacin

Cdigo y Nombre del proyecto: Backengo
Desarrollo de un Backend web seguro para Django
Versin
1.0
- Fecha - Elaborado por

04/04/2013 Angel Sulln

Capa
Modelo: M
Vista: V
Tecnologa
Django Model
Django Manager
Django View
Django Form
SAD Backend
Django Test
Template: T
Django Template
Bootstrap
JQUERY
AJAX+ JSON
SAD Frontend
Selenium
111
Funcin
Extiende utilitarios del Model
Logs
los formularios
de ejecucin
Anexo B5 Estndares de desarrollo

Versin
1.0


ID
Trmino
Ejemplo
Proyecto
Paquetes
Base de datos
Tablas
Atributo PK
Atributo
Atributo FK
Paquetes
Clases
Variables
Contantes
Mtodo
<nombre_proyecto>
<nombre_carpeta>
<nombre_db>
id
<nombre_atributo>
<tabla>_id
<nombre_carpeta>
<nombre_variable>
<NOMBRE_CONSTANTE>
Enumerators
<NOMBRE_ENUM>
Archivos
Interfaces
112
agil_cont
catalogo_productos
agil_cont_db
id
functional_code
natural_person_id
catalogo_productos
class NaturalPerson
functional_code
DEFAULT="DNI"
def add();
def edit();
def delete();
def get_by_id(id);
DEFAULT="DNI"
CE="CE"
OTHERS="OTHERS"
IDENTITY_ CHOICES = (
(CE, "C.E."),
(OTHERS, "Otro.")
)
natural_person.html
Anexo B7 Prototipos principales

Proyecto: Backengo
Mdulo: Backend, app: accounts
Fecha:14/08/2013
Requisito 1: Mostar informacin resumida del proyecto
ui 1-index.html
Funcionalidad: Muestra la pgina de inicio del proyecto

Aprobado por:
Documentacin en http://backenddj-model.appspot.com/BackendDJ-20140514/index.htm
El cdigo fuente puede descargar gratuitamente de:
https://github.com/submitconsulting/backenddj y
https://github.com/submitconsulting/backengo (versin actual)
113
Proyecto: Backengo
Fecha:14/08/2013
Requisito 2: Ingreso al sistema
ui 2-login.html
Funcionalidad: Incia sesin de usuario

Aprobado por:
114
Proyecto: Backengo
Fecha:14/08/2013
Requisito 3: Apertura de Cuentas del sistema
ui 3-signup.html
Funcionalidad: Registra nuevo usuario

Aprobado por:
115
Proyecto: Backengo
Fecha:14/08/2013
Requisito 4: Restablecer contrasea
ui 4-passw ord_reset.html
ui 5-passw ord_reset-done.html
116
ui 6-reset
ui 7-reset-done
Funcionalidad: Reestablace contrasea del usuario

Aprobado por:
117
Proyecto: Backengo
Fecha:14/08/2013
Requisito 5: Elegir sede y mdulo
ui 8-choice_headquar.html
ui 11-dashboard.html
Funcionalidad: Permite elegir empresa y mdulo a administrar

Aprobado por:
118
Proyecto: Backengo
Fecha:14/08/2013
Requisito 6: Agregar nueva empresa y nueva asociacin al usuario actual
ui 9-add_enterprise.html
Funcionalidad:
Aprobado por:
119
Proyecto: Backengo
Fecha:14/08/2013
Requisito 7: Editar perfil del usuario
ui 10-profile_edit.html
Funcionalidad:
Aprobado por:
120
Proyecto: Backengo
Mdulo: Backend, app: space
Fecha:14/08/2013
Requisito 8: Editar datos de la asociacin
ui 12-edit_current.html
Funcionalidad:
Aprobado por:
121
Proyecto: Backengo
Fecha:14/08/2013
Requisito 9: Gestin de empresas
ui 13.1-index.html
ui 13.2-add.html
122
ui 14-edit_current.html
Funcionalidad:
Aprobado por:
123
Proyecto: Backengo
Fecha:14/08/2013
Requisito 10: Gestin de sedes
ui 15.1-index.html
ui 15.2-add.html
Funcionalidad:
Aprobado por:
124
Proyecto: Backengo
Mdulo: Backend, app: sad
Fecha:14/08/2013
Requisito 11: Gestin de usuarios
ui index.html
125
ui add.html
ui person_search.html
126
Proyecto: Backengo
Fecha:14/08/2013
Requisito 12: Gestin de recursos del sistema
ui index.html
ui add.html
Funcionalidad:
Aprobado por:
127
Proyecto: Backengo
Fecha:14/08/2013
Requisito 13: Gestin de perfiles de usuario
ui index.html
ui add.html
Funcionalidad:
Aprobado por:
128
Proyecto: Backengo
Fecha:14/08/2013
Requisito 14: Configuracin de privilegios de perfiles de usuario
ui permissions_edit.html
Funcionalidad:
Aprobado por:
129
Proyecto: Backengo
Fecha:14/08/2013
Requisito 15: Gestin de mdulos del sistema
ui index.html
ui add.html
Funcionalidad:
Aprobado por:
130
Proyecto: Backengo
Fecha:14/08/2013
Requisito 16: Gestin de soluciones o servicios SaaS
ui 21.1-index.html
ui 21.2-add.html
Funcionalidad:
Aprobado por:
131
Proyecto: Backengo
Fecha:14/08/2013
Requisito 17: Configuracin de planes del sistema
ui plans_edit
Funcionalidad:
Aprobado por:
132
Proyecto: Backengo
Fecha:14/08/2013
Requisito 18: Gestin de mens dinmicos del sistema
ui index.html
ui add.html
Funcionalidad:
Aprobado por:
133
Proyecto: Backengo
Fecha:14/08/2013
Requisito 19: Configuracin del sistema
ui basic.html
Funcionalidad:
Aprobado por:
134
Proyecto: Backengo
Fecha:14/08/2013
Requisito 20: Gestin de copias de seguridad de base de datos
ui index.html
Funcionalidad:
Aprobado por:
135
Proyecto: Backengo
Fecha:14/08/2013
Requisito 21: Seguimiento de accesos al sistema
ui index.html
Funcionalidad:
Aprobado por:
136
Proyecto: Backengo
Fecha:14/08/2013
Requisito 22: Seguimiento de auditoria
ui index.html
ui list.html
Funcionalidad:
Aprobado por:
137
Proyecto: Backengo
Fecha:14/08/2013
Requisito 23: Seguimiento de log del sistema
ui index.html
ui list.html
Funcionalidad:
Aprobado por:
138
Proyecto: Backengo
Mdulo: Backend, app: params
Fecha:14/08/2013
Requisito 24: Gestin de localidades
ui index.html (report_pre)
ui add.html
ui report.html
Funcionalidad:
Aprobado por:
139
Anexo B8 Diseo del sistema

1 INFORMACIN GENERAL
2 HISTORIAL DE REVISIONES
Versin - Fecha
1.0 12-12-13
3 ACTUALIZACIONES IMPORTANTES
4 LINKS DE DESCARGA O DE CONSULTA
Modelo: http://backenddj-model.appspot.com/BackendDJ-20140514/index.htm
Scripts
5 ESTRUCTURA DEL MODELO
Mdulo Backend: Este mdulo consta de las siguientes aplicaciones:
140
--- ---params
class params
Nombre:
Paquete:
Versin:
Autor:
params
params
1.0
Asullom
backenddj
enumeration
IDENTITY_TYPES
DEFAULT = DNI
CE = Carnet de extra...
PART_NAC = Partida de naci...
OTHERS = Otros
Locality
LocalityType
-
name: Char
+identity_type
+locality_type
0..1
0..* -
Person
-
birth_date: Date
first_name: Char
identity_num: Char
last_name: Char
modified_in: DateTime
photo: Image
registered_at: DateTime
Datos comunes de las personas naturales

(Clientes, Cta Ctes, Alumnos, Empleados,
etc.) y j urdicas (Clientes, Proveedores, etc )
--- ---sad
141
is_active: Boolean
location: Text
msnm: Float
name: Char
utm: Char

class sad
Nombre:
Paquete:
Versin:
Autor:
sad
sad
1.0
Asullom
django.contrib
dj ango::ContentType
Equivale a Perfil
Group-Permissions
los permisos (recursos+acciones)
definidos para el grupo=RecursoPerfil
+group_set
auth::Group
0..*
-
equivale a Categora del

Recurso
name=table name
app_label= app o module
model=model o controller
name: string
app_label: string
model: string
name: string
+content_type
+groups
0..*
+groups
0..*
+group 0..*
user-groups
los permisos del usuario
referente a los recursos(perm)
del sistema a travs de Group.
Filtar los permisos de los
UserProfile*.
+initial_groups
+permission_set
+permissions
0..*
0..*
auth::Permission
User-User_Permissions
nunca usar esta relacion, todo
se manejar a travs de grupos
+user_set
0..*
auth::User
-
date_joined: datetime
email: string
first_name: string
is_active: boolean
is_staff: boolean
is_superuser: boolean
last_login: datetime
last_name: string
password: string
username: string
+user
+user_permissions
0..* -
codename: string
name: string
+permission
+user_set
0..*
+user
Aqui van las acciones: add,

change, delete convertidos en
recursos de la forma
/<app>/<controller>/<action>/
1
+user
1
1
+user
extension security on cloud

backenddj
los permisos del usuario referente a la
manipulacin de informacin de la sede.
0..*
group: Group
+initial_groups_module_set
+module_set 0..*
0..*
Module
-
description: Text
icon: Char
is_active: Boolean
name: Char
address: Text
is_active: Boolean
is_main: Boolean
name: Char
phone: Char
+person
Anlogo a
UserProfileHeadquart
pero para Asociacin
0..1
1
+solutions
space::Solution
description: Text
is_active: Boolean
name: Char
0..* 0..1
0..1
space::Enterprise
space::Association
-
is_active: Boolean
logo: Image
name: Char
tax_id: Char
is_active: Boolean
logo: Image
name: Char
0..*
enumeration
MODULES
Menu
WEB = Web informativa

VENTAS = Ventas
BACKEND = Backend Manager
0..*
description: Text
icon: Char
+parent
is_active: Boolean
0..1
pos: Integer
title: Char
url: Char
0..*
--- ---space
142
params::Person
0..*
0..1
0..*
0..*
last_headquar_id: Char
last_module_id: Char
0..*
+module_set
0..*
group: Group
0..*
Anlogo a
UserProfileHeadqu
art pero para
Empresas
space::Headquar(sede)
-
0..*
1
Profile
UserProfileAssociation
UserProfileEnterprise
UserProfileHeadquar
Se le da al usuario acceso a una sede tantos
perfiles(group) sea necesario: el grupo que
es asignado, automticamente debe asignar
en user-groups
0..1
0..*
0..*
0..*
birth_date: Date
first_name: Char
identity_num: Char
last_name: Char
photo: Image
class space
Nombre:
Paquete:
Versin:
Autor:
space
space
1.0
Asullom
backenddj
Enterprise
enumeration
TYPES
+type_e
0..* -
GOVERMENT = Gobierno
PRIVATE = Privada
MIXED = Mixta
OTHERS = Otros
Solution
+type_a
1
-
description: Text
is_active: Boolean
name: Char
is_active: Boolean
logo: Image
name: Char
tax_id: Char
0..1
1
Example:
UPeU, UNI, UNMSM, etc.
0..1
params::Locality
0..*
0..*
0..*
Headquar(sede)
Association
-
is_active: Boolean
logo: Image
name: Char
0..1
0..* -
address: Text
is_active: Boolean
is_main: Boolean
name: Char
phone: Char
+locality 0..1 +headquar_set

0..*
-
is_active: Boolean
location: Text
msnm: Float
name: Char
utm: Char
Example:
UPeU Lima, UPeU Juliaca, UPeU Tarapoto, etc.
Permite que el empresario pueda manejar varias sedes y pertenecer a una o ms asociaciones
IMPORTANTE: Una empresa existe si tiene una o ms sedes, todo se trabaja en funcin a la sede (Headquart)
---Modelo de clases. Est dividido en dos capas
--- ---Models Layer
143
--- --- ---params

class params/models.py
Nombre:
Paquete:
Versin:
Autor:
params/models.py
params/models.py
1.0
Asullom
backenddj
Model
LocalityType
+
+locality_type
0..1
+locality_set 0..*
Model
models.py
Locality
+
__unicode__( ) : self.name,self.location
Person
+
__unicode__( ) : self.first_name
144
class params.models
params/models.py::LocalityType
+
__unicode__(self : ) : self.name
+locality_type
0..1
dj ango.db.models::Model
+
+
+
+
+
+locality_set 0..*
delete() : Entity
mucho_ms() : void
objects.filter(condition1 : , conditionN : ) : objects<Entity>
objects.get(id :int) : Entity
save() : Entity
models.py
params/models.py::Locality
+
__unicode__(self : ) : self.name,self.location
Seguir las tcnicas de codeo del ejemplo para Locality

en params.models.py y la gua pep8
--- --- ---sad

class sad/models.py
Nombre:
Paquete:
Versin:
Autor:
sad/models.py
sad/models.py
1.0
Asullom
backenddj
params/models.py::Person
space/models.py::Headquar(sede)
+
__unicode__( ) : self.first_name
+
+headquar_set
+person
1
+headquart
+headquar_set
1
0..*
0..*
+profile 0..1
+association
Profile
+profile +
+user
dj ango.contrib.auth.models::User
+
+user_set
__unicode__( ) : self.user.username
0..*
0..1
+user
1
+userprofileheadquart_set
0..1 space/models.py::Association
+enterprise
UserProfileHeadquar
space/models.py::Enterprise
0..*
+association_set
0..*
0..*
0..*
+enterprise_set
0..*
+userprofileenterprise_set
+groups
0..*
0..*
+group
1
+
__unicode__( ) : self.last_name
+group
+userprofileassociation_set
1
+groups
1
+solution
0..*
+group
+solution
0..1
+group_set
0..*
+initial_groups
0..*
+solutions
0..*
+permissions
+module_set
Permission
+
+module_set 0..*
+permission
+content_type
0..* +
0..*
+menu_set
Menu
0..*
ContentType
+
0..*
Module
+initial_groups_module_set
__unicode__( ) : self.last_name 0..1
+permission_set
0..1
space/models.py::Solution
0..*
__unicode__( ) : self.title
+parent 0..1
__unicode__( ) : self.last_name
+menu_set 0..*
--- --- ---space

145
0..*
class space/models.py
Nombre:
Paquete:
Versin:
Autor:
space/models.py
space/models.py
1.0
Asullom
backenddj
Solution
+
+solution
0..1
+solution
0..1
+association_set 0..*
Association
+
+enterprise_set 0..*
+association
Enterprise
+
0..1
+enterprise
+headquar_set 0..* +headquar_set 0..*

Headquar(sede)
+
+headquart_set
0..*
+locality
Model
0..1
models.py
+
__unicode__( ) : self.name,self.location
--- ---Views Layer

--- --- ---accounts
class accounts/v iew s.py
Nombre:
Paquete:
Versin:
Autor:
accounts/views.py
accounts/views.py
1.0
Asullom
#registro de las cuentas de usuario

+
+
add_enterprise(request) : Enterprise in render_to_response("accounts/add_enterprise.html", c), Redirect.to(request, "/accounts/choice_headquar/")

signup_sys(request) : Person in render_to_response("accounts/signup.html", c), redirect("/accounts/login/")
+
+
+
+
+
choice_headquar(request, field, value) : page< HeadquarLite> in render_to_response("accounts/choice_headquar.html", c)

load_access(request, headquar_id, module_id) : HttpResponseRedirect("/accounts/choice_headquar/") | Redirect.to("/mod_<name>/dashboard/")
login_sys(request) : render_to_response("accounts/login.html", c), HttpResponseRedirect("/accounts/choice_headquar/") | load_access
logout_sys(request) : HttpResponseRedirect("/")
user_profile_edit(request) : User in render_to_response("accounts/profile_edit.html", c), to("/accounts/choice_headquar/")
#login
Metodo
Notas
Parmetro
s
add_enterprise() Enterprise in
render_to_response("accounts/add_enterprise.ht
ml", c), Redirect.to(request,
"/accounts/choice_headquar/")
1 Inicializar Enterprise
2 Obtener el listado de Solution activos
ordenados por "id" y mostrarlos en el template
add_enterprise.html
3 Obtener Association.TYPES y mostrarlos en
el template add_enterprise.html
rq [in]
request
Public
-Si method="POST":
146
1 Obtener User actual con request.user

2 Si existe otro Association con el mismo
"name", retornar exception informando que el
"name" del Association ya existe
3 Salvar Association
4 Si existe otro Enterprise con el mismo
"name" del Enterprise ya existe
"tax_id", retornar exception informando que el
"tax_id" del Enterprise ya existe
6 Salvar Enterprise
7 Crear una Headquar con el name="Principal",
con la Association y Enterprise recien creadas
8 Salvar Headquar
9 Salvar los Group de la sede (de acuerdo a
la Solution elegida) en UserProfileHeadquar
10 Salvar los Group de la empresa (de acuerdo
a la Solution elegida) en
11 Salvar los Group de la asociacin (de
acuerdo a la Solution elegida) en
12 Salvar los Group de la sede, empresa y
asociacin, evitando Group repetidos, usando
User.groups.add(Group)
#Si hay algun exception mantener datos
enviados en el template add_enterprise.html
sin hacer cambios en la DB
signup_sys() Person in
render_to_response("accounts/signup.html", c),
redirect("/accounts/login/")
Public
1 Si el usuario ya est is_authenticated,

intentar cargar el ltimo acceso cargando
directamente la sede y el mdulo anterior,
sino cargar
HttpResponseRedirect("/accounts/choice_headqua
r/")
2 Inicializar Person
3 Obtener el listado de Solution activos
ordenados por "id" y mostrarlos en el template
signup.html
4 Obtener Association.TYPES y mostrarlos en
el template signup.html
5 Obtener el Person.DEFAULT de
Person.IDENTITY_TYPES y mostrarlos en el
template signup.html
-Si method="POST":
1 Si existe otro User con el mismo
"username", retornar exception informando que
el "username" del User ya existe
2 Si existe otro User con el mismo "email",
retornar exception informando que el "email"
del User ya existe
3 Salvar User
4 Si existe otro Person con el mismo
"identity_num" y "identity_type", retornar
exception informando que ya existe un Person
con "identity_num" y "identity_type"
"first_name", "last_name" , "identity_num" y
"identity_type", retornar exception informando
que el Person ya existe. Use normalize
6 Salvar Person
7. Salvar Profile con User del 3er paso y con
Person del 6to paso
"name" del Association ya existe
"tax_id", retornar exception informando que el
"tax_id" del Enterprise ya existe
12 Salvar Enterprise
13 Crear una Headquar con el
name="Principal", con la Association y
Enterprise recien creadas
14 Salvar Headquar
15 Salvar los Group de la sede (de acuerdo a
la Solution elegida) en UserProfileHeadquar
16 Salvar los Group de la empresa (de acuerdo
a la Solution elegida) en
147
rq [in]
request
17 Salvar los Group de la asociacin (de
acuerdo a la Solution elegida) en
18 Salvar los Group de la sede, empresa y
asociacin, evitando Group repetidos, usando
enviados en el template signup.html sin hacer
cambios en la DB
#login
Metodo
Notas
Parmetr
os
choice_headquar() page< HeadquarLite> in

render_to_response("accounts/choice_headquar
.html", c)
1 Obtener el listado paginado de HeadquarLite

filtrado segn los parmetros enviados,
ordenado por "-association__name","enterprise__name","-id" y mostrar en el
template choice_headquar.html
HeadquarLite={
"association": headquar.association,
#Asociaciones del user en la cuales colabora
"enterprise": headquar.enterprise, #Empresas
de del user en la cuales colabora
"headquar": headquar, #Sedes del user en la
cuales colabora
"modules": module_list, #mdulos a la cual el
user tiene acceso
"groups": group_list, #perfiles del usuario
}
rq [in]
request
1 Validar que la peticin no sea con ajax,

sino, informar que ESTA OPERACION NO DEBE SER
CARGADO CON AJAX, Presione F5
2 Validar si Headquar existe en la BD, sino,
retornar exception informando que Headquar no
fu encontrado
3 Validar si Module existe en la BD, sino,
retornar exception informando que Module no
fu encontrado
4 Si el user no es superuser: (si
is_superuser tiene acceso a todo)
4.1 Validar el usuario tiene acceso a la
Headquar, sino, retornar exception informando
que No tiene privilegio para ingresar a la
Headquar
4.2 Validar el usuario tiene acceso al
Module del Headquar del paso 4.1, sino,
retornar exception informando que No tiene
privilegio para ingresar al Module
5 Cargar permisos de datos para el usuario:
rq [in]
request
Public
load_access()
HttpResponseRedirect("/accounts/choice_headq
uar/") |
Redirect.to("/mod_<name>/dashboard/")
Public
str [in]
field
str [in]
value
str [in]
headquar_
id
str [in]
module_id
DataAccessToken.set_association_id(req
uest, headquar.association.id)
DataAccessToken.set_enterprise_id(requ
est, headquar.enterprise.id)
DataAccessToken.set_headquar_id(reques
t, headquar.id)
6 Intentar Obtener Profile del User para
Salvar Profile indicando la ultima sede y el
ultimo mdulo a la que ingres el User
(last_headquar_id = headquar_id,
last_module_id = module_id), si el User no
tiene Profile, crearle uno nuevo.
7 Cargar dashboard del mdulo seleccionado
login_sys()
render_to_response("accounts/login.html", c),
HttpResponseRedirect("/accounts/choice_headq
uar/") | load_access
Public
1 Inicializar User
2 Si el usuario ya est is_authenticated,
intentar cargar el ltimo acceso cargando
directamente la sede y el mdulo anterior (de
Profile), sino cargar
r/")
-Si method="POST":
1 Recuperar el d.username si el usuario est
logendose mediante email.
148
rq [in]
request
2 Autenticar al usuario usando

django.contrib.auth.authenticate(username=d.us
ername, password=password) y
django.contrib.auth.login, sino, retornar
exception informando que la Contasea no es
vlido, o el usuario no existe o no est
activo.
3 Salvar Access con los datos requeridos
4 Si la variable "next" no es nulo ni vaco
cargar al mtodo indicado en dicha variable.
5 Cargar en Message el saludo de bienvenida.
6 Intentar cargar el ltimo acceso cargando
directamente la sede y el mdulo anterior,
sino cargar
r/")
enviados en el template login.html
#El input para login y passwd solo debe
permitir valores alpanumricos ms la @,
evitando la posibilidad de codigo injection
SQL
#Validar {% csrf_token %}
logout_sys() HttpResponseRedirect("/")
1 Cerrar sesin con

django.contrib.auth.logout(request)
rq [in]
request
1 Obtener User actual con request.user

2 Intentar obtener Profile con User.id del
paso 1 si existe, sino dejar pasar sin
obtener datos del Profile del User
3 Obtener el listado de Group ya asignados de
User para las Headquar ( si tuviese) en
UserProfileHeadquar y mostrarlos en el
template profile_edit.html
User para las Enterprise ( si tuviese) en
UserProfileEnterprise y mostrarlos en el
User para las Association ( si tuviese) en
UserProfileAssociation y mostrarlos en el
6 Obtener Person.IDENTITY_TYPES y mostrarlos
en el template profile_edit.html
rq [in]
request
Public
user_profile_edit() User in
render_to_response("accounts/profile_edit.html
", c), to("/accounts/choice_headquar/")
Public
-Si method="POST":
del User ya existe
2 Salvar User
3 Obtener Person a travs de User.profile,
sino Salvar un Person nuevo
4. Obtener Profile a travs de User, sino
Salvar un Profile nuevo con el User del paso
2 y Person del paso 3
"identity_type", retornar exception informando
que el Person ya existe. Use normalize
7 Volver a Salvar Person con los datos
recibidos del formulario
enviados en el template profile_edit.html sin
hacer cambios en la DB
--- --- ---mod_backend

149
class mod_backend/v iew s.py

Nombre:
Paquete:
Versin:
Autor:
mod_backend/views.py
mod_backend/views.py
1.0
Asullom
#mod_backend_dashboard
+
mod_backend_dashboard(request) : render_to_response("mod_backend/dashboard.html", c)
Metodo
Notas
mod_backend_dashboard()
render_to_response("mod_backend/dashboard.html",
c)
Parmetros
rq [in]
request
Public
--- --- ---params

Metodo
Notas
Parmetros
locality_add() Locality in
render_to_response("params/locality/add.html",
c), to_action("index")
1 Inicializar Locality
2 Obtener el listado de todos los
LocalityType ordenado por name para
mostrar en el template add.html
rq [in] request
Public
-Si method="POST":
1 Si existe otro Locality con el mismo
150
name, retornar exception informando que el

name del Locality ya existe
enviados en el template add.html
2 Salvar Locality
Cdigo inicial:
d = Locality()
...
if normalize("NFKD", u"%s" %
d.name).encode("ascii", "ignore").lower()
in list(
normalize("NFKD", u"%s" %
col["name"]).encode("ascii",
"ignore").lower() for col in
Locality.objects.values("name").exclude(id
= d.id) #puede .filter()
):
raise
Exception(_("Locality <b>%(name)s</b>
name's already in use.") %
{"name":d.name})
d.save()
locality_type_list =
LocalityType.objects.all()
c = {
"page_module":_("Locality"),
"page_title":_("New locality."),
"d":d, #Si hay algun exception
mantener datos enviados en el template
"locality_type_list":locality_type_list,
}
locality_delete() to_action("index")
Public
rq [in] request
1 Si no es vlido la llave de seguridad,
retornar exception informando que se ha
denegado el acceso debido a que la llave
es incorrecta
2 Validar si Locality existe en la BD,
sino, retornar exception informando que
Locality no fu encontrado
3 Validar si Locality no tiene
dependencias con otras tablas, sino,
retornar exception informando que Locality
est asignado en la tabla donde fu
encontrada
4 Eliminar Locality
str [in] key
Cdigo inicial:
id = Security.is_valid_key(request, key,
"locality_del")
if d.headquart_set.count() > 0:
raise Exception( ("Localidad
<b>%(name)s</b> est asignado en
headquart.") % {"name":d.name} )
d.delete()
locality_edit() Locality in
render_to_response("params/locality/edit.html",
Public
rq [in] request
es incorrecta
3 Obtener el listado de todos los
LocalityType ordenado por name para
mostrar en el template edit.html
-Si method="POST":
1 Si existe otro Locality con el mismo
name del Locality ya existe
enviados en el template edit.html
2 Salvar Locality
Cdigo inicial:
"locality_upd")
...
if normalize("NFKD", u"%s" %
151
str [in] key
d.name).encode("ascii", "ignore").lower()
in list(
normalize("NFKD", u"%s" %
col["name"]).encode("ascii",
"ignore").lower() for col in
Locality.objects.values("name").exclude(id
= d.id) #puede .filter()
):
raise
Exception(_("Locality <b>%(name)s</b>
name's already in use.") %
{"name":d.name})
d.save()
locality_type_list =
LocalityType.objects.all()
c = {
"page_title":_("Update locality."),
"d":d,#Si hay algun exception mantener
datos enviados en el template
"locality_type_list":locality_type_list,
}
locality_index() page< Locality> in
render_to_response("params/locality/index.html",
c)
Public
rq [in] request
1 Obtener el listado paginado de Locality
filtrado y ordenado segn los parmetros
enviados y mostrar en el template
index.html
Cdigo inicial:
value_f = "" if value == "None" else value
column_contains = u"%s__%s" %
(field,"contains")#WHERE column LIKE %an%
locality_list =
Locality.objects.filter(**{
column_contains: value_f
}).order_by(order)
paginator = Paginator(locality_list, 25)
locality_page =
paginator.page(request.GET.get("page"))
c = {
"page_title":_("Localities list."),
str [in] field
str [in] value
str [in] order
"locality_page":locality_page,
"field":field,
"value":value.replace("/", "-"),
"order":order,
}
locality_report() objects< Locality> in
render_to_response("params/locality/report.html",
c)
1 Obtener el listado de Locality filtrado
y ordenado segn los parmetros enviados y
mostrar en el template report.html
Public
Cdigo inicial:
value = "" if value == "None" else value
column_contains = u"%s__%s" %
(field,"contains")
locality_list =
Locality.objects.filter(**{
column_contains: value }).order_by(order)
c = {
"page_title":_("Localities report."),
"locality_list":locality_list,
}
locality_state() to_action("index")
Public
rq [in] request
str [in] field
str [in] value
str [in] order

es incorrecta
3 Actualizar el campo Locality.is_active
para False/True
rq [in] request
Cdigo inicial:
"locality_%s" % state )
d.is_active = (True if state ==
"reactivar" else False)
d.save()
str [in] key
152
str [in] state
class params.v iew s
Nombre:
Paquete:
Versin:
Autor:
params.views
locality (ejemplo completo)
1.0
Asullom
python::Template
dj ango.http::
HttpResponseRedirect
+
-
python::Context
-
render(context) : String
python::RequestContext
data: Dictionary
request: HttpRequest
url: String
dj ango.http::
HttpResponse
-
Model
package
dj ango.shortcuts::Package
contents: String
status_code
template: List
+
+
models.py
redirect(forward) : void
render_to_response(template, data, context) : void
__unicode__(self) : self.name,self.location
+locality_set
0..*
+locality_type
0..1
apps.utils.security.py::Redirect
+
+
to(request, route, params) : return methodToCall(request) | return redirect(path)

to_action(request, action_name, params) : return methodToCall(request) | return redirect(path)
Model
dj ango.db::transaction.py
+
python::Exception
params/models.py::LocalityType
+
commit_on_success() : decorator(view_func)
__unicode__(self) : self.name
dj ango.core.paginator::Paginator
params/v iew s.py::#locality
+
+
+
+
+
+
Seguir las tcnicas de codeo

del ejemplo para Locality en
params.views.py y la gua
pep8
+
+
locality_add(request) : Locality in render_to_response("params/locality/add.html", c), to_action("index")

locality_delete(request, key) : to_action("index")
locality_edit(request, key) : Locality in render_to_response("params/locality/edit.html", c), to_action("index")
locality_index(request, field, value, order) : page< Locality> in render_to_response("params/locality/index.html", c)
locality_report(request, field, value, order) : objects< Locality> in render_to_response("params/locality/report.html", c)
locality_state(request, state, key) : to_action("index")
page(current_page) : page
Paginator(list, per_page) : Paginator
dj ango.contrib::
messages.py
apps.utils.messages.py::Message
apps.utils::decorators.py
+
+
-
apps.utils.security.py::Security
is_admin(view_func) : wrapped
permission_resource_required(function, template_denied_name) : decorator(view_func)
permission_resource_required_decorator(template_denied_name) : decorator(view_func)
+
+
get_key(id, action_name) : string

is_valid_key(request, key_value, action_name) : void
templatetags::app_security.py
+
templatetags::notify.py
key(id, action_name) : Security.get_key(id, action_name)
--- --- ---sad

153
get_notify(request) : message[]
+
+
+
+
+
critical(request, msg, audit) : void

debug(request, msg, audit) : void
error(request, msg, audit) : void
info(request, msg, audit) : void
set_msg(request, type, msg, audit) : void
warning(request, msg, audit) : void
python::logging
class sad/v iew s.py
#user
+
+
+
+
+
+
+
+
+
user_add(request) : User in render_to_response("sad/user/add.html", c), to_action("index")

user_add_from_person(request, key) : User in render_to_response("sad/user/add_from_person.html", c), to_action("index")
user_delete(request, key) : to_action("index")
user_edit(request, key) : User in render_to_response("sad/user/edit.html", c), to_action("index")
user_index(request, field, value, order) : page< User> in render_to_response("sad/user/index.html", c)
user_person_search(request, field, value) : objects<Person> in render_to_response("sad/user/person_search.html", c)
user_state(request, state, key) : to_action("index")
user_upload(request) : json < dict>
user_view(request, key) : User in render_to_response("sad/user/view.html", c), to_action("index")
#menu
+
+
+
+
+
menu_add(request) : Menu in render_to_response("sad/menu/add.html", c), to_action("index")

menu_delete(request, key) : to_action("index")
menu_edit(request, key) : Menu in render_to_response("sad/menu/edit.html", c), to_action("index")
menu_index(request, field, value, order) : page< Menu> in render_to_response("sad/menu/index.html", c)
menu_state(request, state, key) : to_action("index")
#module
+
+
+
+
+
+
module_add(request) : Module in render_to_response("sad/module/add.html", c), to_action("index")

module_delete(request, key) : to_action("index")
module_edit(request, key) : Module in render_to_response("sad/module/edit.html", c), to_action("index")
module_index(request) : objects< Module> in render_to_response("sad/module/index.html", c)
module_plans_edit(request) : objects< Module>, objects< Solution> in render_to_response("sad/module/plans_edit.html", c)
module_state(request, state, key) : to_action("index")
#group
+
+
+
+
+
group_add(request) : Group in render_to_response("sad/group/add.html", c), to_action("index")

group_delete(request, key) : to_action("index")
group_edit(request, key) : Group in render_to_response("sad/group/edit.html", c), to_action("index")
group_index(request) : objects< Group> in render_to_response("sad/group/index.html", c)
group_permissions_edit(request) : objects< Group>, objects< Permission> in render_to_response("sad/group/permissions_edit.html", c)
#resource (Permission)
+
+
+
+
resource_add(request) : Permission in render_to_response("sad/resource/add.html", c), to_action("index")

resource_delete(request, key) : to_action("index")
resource_edit(request, key) : Permission in render_to_response("sad/resource/edit.html", c), to_action("index")
resource_index(request) : objects< Permission> in render_to_response("sad/resource/index.html", c)
#group
Metodo
group_add() Group in
render_to_response("sad/group/add.html", c),
to_action("index")
Public
Notas
Parmetro
s
rq [in]
request
1 Inicializar Group
-Si method="POST":
1 Si existe otro Group con el mismo "name",
retornar exception informando que el "name"
del Group ya existe
2 Salvar Group
group_delete() to_action("index")
Public
rq [in]
request
denegado el acceso debido a que la llave es
incorrecta
2 Validar si Group existe en la BD, sino,
retornar exception informando que Group no
fu encontrado
3 Validar si Group no tiene dependencias
con otras tablas, sino, retornar exception
informando que Group est asignado en la
tabla donde fu encontrada
4 Eliminar Group
154
str [in] key
group_edit() Group in
render_to_response("sad/group/edit.html", c),
to_action("index")
rq [in]
request
incorrecta
2 Validar si Group existe en la BD, sino,
retornar exception informando que Group no
fu encontrado
Public
str [in] key
-Si method="POST":
1 Si existe otro Group con el mismo "name",
retornar exception informando que el "name"
del Group ya existe
2 Salvar Group
group_index() objects< Group> in
render_to_response("sad/group/index.html", c)
rq [in]
request
1 Obtener el listado de Group ordenado por
"-id" y mostrar en el template index.html
Public
group_permissions_edit() objects< Group>,

objects< Permission> in
render_to_response("sad/group/permissions_edit.ht 1 Obtener la lista de Permission ordenados
por
ml", c)
"content_type__app_label","content_type__mod
el"y mostrar en el template
Public
group_permissions_edit.html
2 Obtener la lista de Group ordenado por "id" y mostrar en el template
group_permissions_edit.html
3 En una list[] Obtener los privilegios
asignados en la forma "Permission.idGroup.id" y mostrar en el template
permissions_edit.html, donde los privilegios
asignados se marcan con check
-Si method="POST":
1 Eliminar los antiguos privilegios usando
Group.permissions.remove(Permission) para
cada par "Permission.id-Group.id" de todos
los request.POST.getlist("privilegios")
2 Salvar los nuevos privilegios marcados
con check en el template
permissions_edit.html. Usar
Group.permissions.add(Permission) para cada
par "Permission.id-Group.id" de todos los
request.POST.get("old_privilegios").split(",
")
#Si hay algun exception no hacer cambios en
la DB
#menu
Metodo
menu_add() Menu in
render_to_response("sad/menu/add.html",
Public
Notas
Parmetros
rq [in] request
1 Inicializar Menu
2 Obtener el listado de Menu
padres activos y mostrarlos en
el template add.html
3 Obtener el listado de
Permission y mostrarlos en el
template add.html
Menu.MODULES y mostrarlos en el
template add.html
-Si method="POST":
#Si hay algun exception mantener
add.html
1 Salvar Menu
155
rq [in]
request
menu_delete() to_action("index")
Public
menu_edit() Menu in
render_to_response("sad/menu/edit.html",
Public
rq [in] request
1 Si no es vlido la llave de
seguridad, retornar exception
informando que se ha denegado el
acceso debido a que la llave es
incorrecta
2 Validar si Menu existe en la
BD, sino, retornar exception
informando que Menu no fu
encontrado
3 Validar si Menu no es un men
inicial
4 Eliminar Menu
str [in] key
rq [in] request
incorrecta
encontrado
3 Validar si Menu no es un men
inicial
4 Obtener el listado de Menu
padres activos y mostrarlos en
el template edit.html
Permission y mostrarlos en el
template edit.html
Menu.MODULES y mostrarlos en el
template edit.html
str [in] key
-Si method="POST":
#Si hay algun exception mantener
edit.html
1 Salvar Menu
menu_index() page< Menu> in
render_to_response("sad/menu/index.html",
c)
1 Obtener el listado paginado
de Menu filtrado y ordenado
segn los parmetros enviados y
Public
mostrar en el template
index.html
rq [in] request
str [in] field
str [in] value
str [in] order
menu_state() to_action("index")
Public
rq [in] request
incorrecta
encontrado
3 Actualizar el campo
Menu.is_active para False/True
156
str [in] state
str [in] key
#module
Metodo
Notas
Parmetr
os
module_add() Module in
render_to_response("sad/module/add.html",
1 Inicializar Module
2 Obtener el listado de Group ordenado por
"name" y mostrarlos en el template add.html
Public
rq [in]
request
-Si method="POST":
1 Si existe otro Module con el mismo "name",
retornar exception informando que el "name" del
Module ya existe
#Si hay algun exception mantener datos enviados
en el template add.html
2 Salvar Module
3 Salvar los privilegios seleccionados en el
template add.html. Module.groups.add(Group) de
todos los request.POST.getlist("groups")
4 Salvar los privilegios iniciales seleccionados
en el template add.html.
Module.initial_groups.add(Group) de todos los
request.POST.getlist("initial_groups")
module_delete() to_action("index")
Public
module_edit() Module in
render_to_response("sad/module/edit.html"
, c), to_action("index")
Public
rq [in]
request
retornar exception informando que se ha denegado
el acceso debido a que la llave es incorrecta
retornar exception informando que Module no fu
encontrado
3 Validar si Module no tiene dependencias con
otras tablas, sino, retornar exception informando
que Module est asignado en la tabla donde fu
encontrada
4 Eliminar Module
str [in]
key
rq [in]
request
encontrado
4 Obtener el listado de Group y mostrarlos en el
template edit.html
5 Obtener el listado de ids de los Group
asginados al Module y mostrarlos en el template
edit.html
6Obtener el listado de ids de los Group
Iniciales asginados al Module y mostrarlos en el
template edit.html
7 Obtener el listado de Module.MODULES y
mostrarlos en el template edit.html
-Si method="POST":
1 Si existe otro Module con el mismo "name",
retornar exception informando que el "name" del
Module ya existe
#Si hay algun exception mantener datos enviados
en el template edit.html
2 Salvar Module
Module.groups.remove(Group) de todos los
request.POST.get("old_grupos_id_list").split(",")
4 Salvar los nuevos privilegios seleccionados en
el template edit.html. Module.groups.add(Group)
de todos los request.POST.getlist("groups")
5 Eliminar los antiguos privilegios iniciales
usando Module.initial_groups.remove(Group) de
todos los
request.POST.get("old_initial_groups_id_list").sp
lit(",")
6 Salvar los nuevos privilegios iniciales
seleccionados en el template edit.html.
Module.initial_groups.add(Group) de todos los
request.POST.getlist("initial_groups")
#Si hay algun exception no hacer cambios en la DB
157
str [in]
key
module_index() objects< Module> in

render_to_response("sad/module/index.htm
l", c)
Public
module_plans_edit() objects< Module>,

objects< Solution> in
render_to_response("sad/module/plans_edit
.html", c)
Public
rq [in]
request
1 Obtener el listado de Module ordenado por
"module", "-id" y mostrar en el template
index.html
rq [in]
request
1 Obtener la lista de Module activos ordenados
por "module" y mostrar en el template
plans_edit.html
2 Obtener la lista de Solution activos ordenado
por "-id" y mostrar en el template
plans_edit.html
3 En una list[] Obtener los privilegios
asignados en la forma "Solution.id-Module.id" y
mostrar en el template plans_edit.html donde los
privilegios asignados se marcan con check
-Si method="POST":
Module.solutions.remove(Solution) para cada par
"Solution.id-Module.id" de todos los
request.POST.getlist("privilegios")
2 Salvar los nuevos privilegios marcados con
check en el template plans_edit.html.
Module.solutions.add(Solution) para cada par
"Solution.id-Module.id" de todos los
request.POST.get("old_privilegios").split(",")
#Si hay algun exception no hacer cambios en la DB
module_state() to_action("index")
Public
rq [in]
request
encontrado
3 Actualizar el campo Module.is_active para
False/True
str [in]
state
str [in]
key
#resource (Permission)
Metodo
resource_add() Permission in
render_to_response("sad/resource/add.html",
Public
Notas
Parmetro
s
rq [in]
request
1 Inicializar Permission
-Si method="POST":
1 Resolver "name","model" y "app_label" a
partir de los objetos recibidos del template
add.html
2 Obtener o crear la ContentType con el
"name","model" y "app_label" recibidos del
template add.html
3 Resolver "codename" y "recurso"
4 Si existe otro Permission con el mismo
"codename" para la ContentType retornar
exception informando que el "recurso" ya
existe
5 Salvar Permission
enviados en el template add.html sin hacer
cambios en la DB
resource_delete() to_action("index")
Public
rq [in]
request
158
incorrecta
2 Validar si Permission existe en la BD,
Permission o Recurso no fu encontrado
3 No permitir eliminar recursos iniciales
4 Validar si Permission no tiene dependencias
con otras tablas, sino, retornar exception
informando que Permission (en forma de
recurso) est asignado en la tabla donde fu
encontrada
5 Eliminar Permission
resource_edit() Permission in
render_to_response("sad/resource/edit.html",
Public
str [in] key
rq [in]
request
incorrecta
2 Validar si Permission existe en la BD,
Permission o Recurso no fu encontrado
3 No permitir editar recursos iniciales
str [in] key
-Si method="POST":
1 Resolver "name","model" y "app_label" a
partir de los objetos recibidos del template
edit.html
2 Obtener o crear la ContentType con el
"name","model" y "app_label" recibidos del
template edit.html
3 Resolver "codename" y "recurso"
4 Si existe otro Permission con el mismo
"codename" para la ContentType retornar
exception informando que el "recurso" ya
existe
5 Salvar Permission
enviados en el template edit.html sin hacer
cambios en la DB
resource_index() objects< Permission> in

render_to_response("sad/resource/index.html"
, c)
Public
rq [in]
request
1 Obtener el listado de Permission ordenado
por
"content_type__app_label","content_type__model
" y mostrar en el template index.html.
#user
Metodo
user_add() User in
render_to_response("sad/user/add.html", c),
to_action("index")
Public
Notas
Parmetro
s
rq [in]
request
1 Inicializar User
2 Obtener el Headquar actual, id =
DataAccessToken.get_headquar_id(request.sess
ion)
3 Obtener el listado de Module activos
asignados a su Enterprise y Asociation del
Headquar actual
4 Obtener el listado de Group
pertenecientes al Module (del 3 paso) y
darle la forma indicada en la IGU y
mostrarlos en el template add.html (de la
forma Module>Group/perfil)
5 Obtener Person.IDENTITY_TYPES y
mostrarlos en el template add.html
-Si method="POST":
"username", retornar exception informando
que el "username" del User ya existe
del User ya existe
3 Salvar User
"identity_type", retornar exception
informando que el Person ya existe. Use
normalize
159

6 Salvar Person
7. Salvar Profile con User del 3er paso y
con Person del 6to paso
8 Salvar los Group de la sede
(request.POST.getlist("groups_sede")) en
UserProfileHeadquar
9 Salvar los Group de la empresa
(request.POST.getlist("groups_enterprise"))
en UserProfileEnterprise
10 Salvar los Group de la asociacin
(request.POST.getlist("groups_association"))
en UserProfileAssociation
11 Salvar los Group de la sede, empresa
yasociacin, evitando Group repetidos usando
cambios en la DB
user_add_from_person() User in
render_to_response("sad/user/add_from_person.ht
ml", c), to_action("index")
Public
rq [in]
request
incorrecta
2 Validar si Person existe en la BD, sino,
retornar exception informando que Person no
fu encontrado
ion)
Headquar actual
mostrarlos en el template
add_from_person.html (de la forma
Module>Group)
mostrarlos en el template
add_from_person.html
-Si method="POST":
del User ya existe
3 Salvar User
normalize
6 Actualizar Person, ahora con los datos
recibidos del formulario
7. Salvar Profile con User del 3er paso y
con Person del 6to paso
UserProfileHeadquar
enviados en el template add_from_person.html
sin hacer cambios en la DB
160
str [in] key
user_delete() to_action("index")
Public
user_edit() User in
render_to_response("sad/user/edit.html", c),
to_action("index")
Public
rq [in]
request
incorrecta
2 Validar si User existe en la BD, sino,
retornar exception informando que User no
fu encontrado
3 Validar si User no es admin, si lo es
enviar un mensaje "Lo sentimos, pero este
usuario no se puede eliminar."
4 Validar si User no tiene dependencias con
otras tablas, sino, retornar exception
informando que User est asignado en la
tabla donde fu encontrada
5 Eliminar User
str [in] key
rq [in]
request
incorrecta
fu encontrado
ion)
5 Obtener el listado de Group ya asignados
de User para la Headquar ( si tuviese) en
template edit.html
de User para la Headquar.enterprise ( si
tuviese) en UserProfileEnterprise y
de User para la Headquar.association ( si
tuviese) en UserProfileAssociation y
Headquar actual
mostrarlos en el template edit.html (de la
forma Module>Group)
-Si method="POST":
del User ya existe
3 Salvar User
4 Obtener Person a travs de User.profile,
sino Salvar un Person nuevo
5. Obtener Profile a travs de User, sino
Salvar un Profile nuevo con el User del paso
3 y Person del paso 4
normalize
8 Salvar nuevamente Person del paso 4
ahora con los datos recibidos del formulario
9 Eliminar los Group de la sede asignados
al User de UserProfileHeadquar
10 Eliminar los Group de la empresa
asignados al User de UserProfileEnterprise
11 Eliminar los Group de la asociacin
asignados al User de UserProfileAssociation
161
str [in] key
12 Eliminar los Group de la sede, empresa y

asociacin asignados al User usando
User.groups.remove(Group)
UserProfileHeadquar
enviados en el template edit.html sin hacer
cambios en la DB
user_index() page< User> in

render_to_response("sad/user/index.html", c)
Public
rq [in]
request
1 Obtener el listado paginado de User
filtrado y ordenado segn los parmetros
enviados y mostrar en el template index.html
str [in]
field
str [in]
value
str [in]
order
user_person_search() objects<Person> in
render_to_response("sad/user/person_search.html"
, c)
1 Obtener el listado de Person que no estn
en Profile, filtrar segn los parmetros
enviados de la bsqueda, ordenar por
Public
"last_name", "first_name" y mostrar en el
template person_search.html
rq [in]
request
str [in]
field
str [in]
value
user_state() to_action("index")
Public
rq [in]
request
incorrecta
fu encontrado
3 Validar si User no es admin, si lo es
enviar un mensaje "Lo sentimos, pero este
usuario no se puede inactivar."
4 Actualizar el campo User.is_active para
False/True
162
str [in]
state
str [in] key
user_upload() json < dict>

Public
user_view() User in
render_to_response("sad/user/view.html", c),
to_action("index")
Public
rq [in]
request
1 Ejecute este mtodo con ajax
2 Suba el archivo usando Upload.save_file(
, )
3 Devuelva informacin de la imagen subida
rq [in]
request
incorrecta
fu encontrado
de User para las Headquar ( si tuviese) en
template view.html
de User para las Enterprise ( si tuviese)
en UserProfileEnterprise y mostrarlos en el
template view.html
de User para las Association ( si tuviese)
en UserProfileAssociation y mostrarlos en el
template view.html
mostrarlos en el template view.html
--- --- ---space

163
str [in] key
class space/v iew s.py

Nombre:
Paquete:
Versin:
Autor:
space/views.py
space/views.py
1.0
Asullom
#headquar
+
+
+
+
+
+
headquar_add(request) : Headquar in render_to_response("space/headquar/add.html", c), to_action("index")

headquar_change_association(request, key) : Headquar in render_to_response("space/headquar/change_association.html", c), to_action("index")
headquar_delete(request, key) : to_action("index")
headquar_edit(request, key) : Headquar in render_to_response("space/headquar/edit.html", c), to_action("index")
headquar_index(request) : objects< Headquar> in render_to_response("space/headquar/index.html", c)
headquar_state(request, state, key) : to_action("index")
+
+
+
+
+
+
+
enterprise_add(request) : Enterprise in render_to_response("space/enterprise/add.html", c), to_action("index")

enterprise_delete(request, key) : to_action("index")
enterprise_edit(request, key) : Enterprise in render_to_response("space/enterprise/edit.html", c), to_action("index")
enterprise_edit_current(request) : Enterprise in render_to_response("space/enterprise/edit_current.html", c)
enterprise_index(request) : objects< Enterprise> in render_to_response("space/enterprise/index.html", c)
enterprise_state(request, state, key) : to_action("index")
enterprise_upload(request) : json < dict>
+
+
association_edit_current(request) : Association in render_to_response("space/association/edit_current.html", c)

association_upload(request) : json < dict>
+
+
+
+
+
solution_add(request) : Solution in render_to_response("space/solution/add.html", c), to_action("index")

solution_delete(request, key) : to_action("index")
solution_edit(request, key) : Solution in render_to_response("space/solution/edit.html", c), to_action("index")
solution_index(request) : objects< Solution> in render_to_response("space/solution/index.html", c)
solution_state(request, state, key) : to_action("index")
#enterprise
#association
#solution
#association
Metodo
association_edit_current() Association in
render_to_response("space/association/edit_curre
nt.html", c)
Public
Notas
Parmetr
os
rq [in]
request
1 Validar si Association actual existe en la

BD meidante
DataAccessToken.get_association_id(request.se
ssion), sino, retornar exception informando
que Association no fu encontrado
2 Obtener todos los Solution activos
ordenados por "id"
-Si method="POST":
name del Association ya existe
enviados en el template edit_current.html
association_upload() json < dict>

Public
rq [in]
request
2 Suba el archivo usando Upload.save_file( ,
)
#enterprise
164
Metodo
enterprise_add() Enterprise in
render_to_response("space/enterprise/add.html",
Public
Notas
Parmetr
os
rq [in]
request
1 Inicializar Enterprise
-Si method="POST":
"tax_id", retornar exception informando que
el "tax_id" del Enterprise ya existe
3 Salvar Enterprise
4 Crear una Headquar con el
name="Principal", con la Association actual y
con el Enterprise actual
5 Si existe otro Headquar con el mismo name
para la Enterprise, retornar exception
informando que el name del Headquart para la
Enterprise ya existe
6 Salvar Headquar
cambios en la DB
enterprise_delete() to_action("index")
Public
enterprise_edit() Enterprise in
render_to_response("space/enterprise/edit.html",
Public
rq [in]
request
incorrecta
2 Validar si Enterprise existe en la BD,
Enterprise no fu encontrado
3 Validar si Association actual, a la que
pertenece la Sede de la Enterprise a
eliminar, no se quede si ninguna sede
asociada, sino, retornar exception informando
que Association no puede quedar sin ninguna
sede asociada
4 Validar si Enterprise no tiene
dependencias con otras tablas, sino, retornar
exception informando que Enterprise est
asignado en la tabla donde fu encontrada
5 Eliminar Enterprise
str [in]
key
rq [in]
request
incorrecta
str [in]
key
-Si method="POST":
name del Enterprise ya existe
tax_id, retornar exception informando que el
tax_id del Enterprise ya existe
3 Salvar Enterprise
enterprise_edit_current() Enterprise in
render_to_response("space/enterprise/edit_curren
t.html", c)
Public
rq [in]
request
1 Validar si Enterprise actual existe en la
BD meidante DataAccessToken.get_enterprise
_id(request.session), sino, retornar
exception informando que Enterprise no fu
encontrado
2 Obtener todos los Solution activos
ordenados por "id"
-Si method="POST":
name del Enterprise ya existe
165

tax_id, retornar exception informando que el
tax_id del Enterprise ya existe
enviados en el template edit_current.html
3 Salvar Enterprise
enterprise_index() objects< Enterprise> in
render_to_response("space/enterprise/index.html"
, c)
1 Validar si Association actual existe en la
BD meidante
DataAccessToken.get_association_id(request.se
Public
ssion), sino, retornar exception informando
que Association no fu encontrado
2 Obtener el listado de Enterprise cuya Sede
est asociada con la Association actual,
ordenado por -id y mostrar en el template
index.html.
en dicho listado debe incluirse el nmero de
sedes asociadas a la Association actual
rq [in]
request
enterprise_state() to_action("index")
rq [in]
request
Public

incorrecta
3 Actualizar el campo Enterprise.is_active
para False/True
str [in]
state
str [in]
key
enterprise_upload() json < dict>

Public
rq [in]
request
2 Suba el archivo usando Upload.save_file( ,
)
#headquar
Metodo
headquar_add() Headquar in
render_to_response("space/headquar/add.html", c),
to_action("index")
Public
Notas
Parmetr
os
rq [in]
request
1 Inicializar Headquar
2 Obtener el listado en json de los
nombres de todos los Locality ordenado por
"name" y mostrar en el template add.html.
-Si method="POST":
1 Obtener o crear la Locality con el
nombre recibido del template add.html
2 Si existe otro Headquar con el mismo
"name" para la Enterprise, retornar
exception informando que el name del
Headquar ya existe para esa Enterprise
3 Salvar Headquar
cambios en la DB
headquar_change_association() Headquar in
render_to_response("space/headquar/change_associat
ion.html", c), to_action("index")
Public

incorrecta
2 Validar si Headquar existe en la BD,
Headquar no fu encontrado
nombres de todos los Association activos
ordenado por "name" y mostrar en el
template change_association.html
166
rq [in]
request
str [in]
key
-Si method="POST":
1 Obtener la Association con el nombre
recibido del template
change_association.html, sino se encuentra,
retornar exception informando que
Association no fu encontrado, vuelva a
intentar
2 Salvar Headquar
enviados en el template
change_association.html
headquar_delete() to_action("index")
Public
headquar_edit() Headquar in
render_to_response("space/headquar/edit.html", c),
to_action("index")
Public

incorrecta
3 Validar si Enterprise actual no se quede
si ninguna sede asociada, sino, retornar
exception informando que Enterprise no
puede quedar sin ninguna sede
4 Validar si Headquar no tiene
retornar exception informando que Headquar
est asignado en la tabla donde fu
encontrada
5 Eliminar Headquar
rq [in]
request

incorrecta
nombres de todos los Locality ordenado por
"name" y mostrar en el template edit.html
rq [in]
request
str [in]
key
str [in]
key
-Si method="POST":
1 Obtener o crear la Locality con el
nombre recibido del template edit.html
2 Si existe otro Headquar con el mismo
"name" para la Enterprise, retornar
exception informando que el name del
Headquar ya existe para esa Enterprise
3 Salvar Headquar
headquar_index() objects< Headquar> in
render_to_response("space/headquar/index.html", c)
Public
headquar_state() to_action("index")
Public
1 Validar si Enterprise actual existe en

la BD meidante
DataAccessToken.get_enterprise_id(request.s
ession), sino, retornar exception
informando que Enterprise no fu encontrado
2 Obtener el listado de Headquar de la
Enterprise actual, ordenado por -id y
mostrar en el template index.html.
rq [in]
request

incorrecta
3 Actualizar el campo Headquar.is_active
para False/True
rq [in]
request
str [in]
state
str [in]
key
#solution
Metodo
Notas
Parmetros
solution_add() Solution in
render_to_response("space/solution/add.html", c),
to_action("index")
1 Inicializar Solution
rq [in]
request
Public
-Si method="POST":
1 Si existe otro Solution con el mismo
name, retornar exception informando que
el name del Solution ya existe
2 Salvar Solution
167
solution_delete() to_action("index")
Public
solution_edit() Solution in
render_to_response("space/solution/edit.html", c),
to_action("index")
Public
seguridad, retornar exception informando
que se ha denegado el acceso debido a
que la llave es incorrecta
2 Validar si Solution existe en la BD,
Solution no fu encontrado
3 Validar si Solution no tiene
retornar exception informando que
Solution est asignado en la tabla donde
fu encontrada
4 Eliminar Solution
rq [in]
request
rq [in]
request
str [in] key
str [in] key
-Si method="POST":
1 Si existe otro Solution con el mismo
name, retornar exception informando que
el name del Solution ya existe
2 Salvar Solution
solution_index() objects< Solution> in
render_to_response("space/solution/index.html", c)
1 Obtener el listado de Solution

ordenado por "-id" y mostrar en el
template index.html
rq [in]
request
3 Actualizar el campo
Solution.is_active para False/True
rq [in]
request
Public
solution_state() to_action("index")
Public
str [in] state
str [in] key
168
Anexo B9 Formulario de lecciones aprendidas

Proyecto:
N Iteracin:
1.
2.

1.
2.

1. Investigar todas las formas o estilos de codificacin para definir el estilo de
codificacin de cada componentes y funciones de la aplicacin
2.
169
Anexo B10 Lista de tareas de desarrollo del backend

#
Ticket
Estado Estima
Entrega
(h*)
1
Inicio del proyecto Backend
01/08/2013
Refinacin del diseo del sistema para el mdulo
Hecho
48
06-ago
Hecho
48
11-ago
backend en Enterprise Architect

3
Refinacin del diseo del frontend basado HTML5,

Bootstrap, JQuery, AJAX, etc
Componente para la Gestin de mensajera y Logs
Hecho
24
14-ago
Componente para el Contexto de la Sesin del
Hecho
18
16-ago
Hecho
24
19-ago
Hecho
21-ago
Usuario en la nube
6
Componente para la seguridad de los recursos del

sistema
Componente para las llaves de seguridad de acceso

a datos
Otros componentes: Upload file, Redirect, etc.
Hecho
22-ago
Gestin personalizada de Recursos (django) del
Hecho
18
25-ago
Hecho
26-ago
Hecho
12
28-ago
sistema
10
Gestin personalizada de PERFILES (django) de

usuarios
11
Configuracin personalizada de PERMISOS (django)

o privilegios de usuarios
12
Gestin de MODULOS del sistema
Hecho
12
30-ago
13
Configuracin de PLANES del sistema
Hecho
02-sep
14
CREAR CUENTA para NUEVOS USUARIOS, Empresas
Hecho
18
08-sep
y asignacin de planes
15
Login y eleccin de la sede y mdulo a administrar
Hecho
12
12-sep
16
Perfil de usuario y Recuperacin de contrasea
Hecho
12
16-sep
17
Agregar nuevas EMPRESAS para usuarios existentes
Hecho
12
20-sep
y asignacin de planes
18
Actualizacin de datos de la asociacin
Hecho
12
24-sep
19
Gestin de empresas de la asociacin
Hecho
12
28-sep
20
Actualizacin de datos de la empresa
Hecho
12
02-oct
170
21
Gestin de sedes
Hecho
18
07-oct
22
Gestin de usuarios
Hecho
18
13-oct
23
Men dinmico
Hecho
12
17-oct
24
Depuracin
Hecho
18
23-oct
25
Publicacin y distribucin en Github
Hecho
26-oct
26
Entrenamiento de integracin
Hecho
12
30-oct
27
Actualizacin de la documentacin y prototipos
Hecho
48
15-nov
28
Entrega al 100% del Backend
15/11/2013
Sumas:
451
171
Anexo C1 Product backlog (requisitos del sistema)

Proyecto: QUALPACA -- Desarrollo de Plataforma Tecnolgica en la Web para la
Competitividad de la Cadena Productiva de Alpacas en la Regin Puno
Cdigo
/Sprint
RF01
/1
Requisito
Requisito 1: Identificacin y registro de alpacas
Descripcin:
Registro de alpacas segn su procedencia, cdigo de
identificacin, sexo, color, tipo o raza, datos de
nacimiento, padres, localidad donde vive, asociacin,
rebao y grupo a la que pertenece.
RF02
/1

1. Al aadir o seleccionar o buscar una alpaca el sistema
debe redirigir a la pgina que muestra el resumen de
la informacin de la alpaca para su posterior
actualizacin. El resumen depender de la
informacin suministrada; esta informacin son:
edad, datos reproductivos, produccin de fibra,
estado de salud y rbol genealgico.
2. La informacin de su grupo, padre y madre son
opcionales. Si son ingresados los datos de los padres,
el sistema debe generar su rbol genealgico hasta
sus bisabuelos.
3. Debe mostrar en HTML los registros de alpacas
reproductoras y no reproductoras dado un rango de
fecha y un grupo.
4. El usuario debe tener acceso de Administrador o
Tcnico de campo al rebao o al grupo para poder
actualizar el Registro de alpacas. El usuario no puede
visualizar ni actualizar registros del grupo o rebao
que no le est autorizado.
5. Poder rastrear al usuario que actualiz el Registro de
alpacas.
Requisito 2: Empadre y gestacin
Descripcin:
RF03
/1

1.
2.
Requisito 3: Paricin y destete
Descripcin:
RF04
/2

1.
2.
Requisito 4: Sanidad
Descripcin:
172
Estado
Estimac.
(horas)
Prioridad
Nuevo
40
10
Nuevo
40
Nuevo
20
Nuevo

1.
2.
Requisito 5: Esquila
Descripcin:
Nuevo
20
Nuevo
10
Nuevo
10

1.
2.
Requisito 6: Retiro
Descripcin:
1. Alpaca X ya no est en el registro de alpacas
reproductoras
2.
Requisito 7: Castracin
Descripcin:
1.
2.
173
Anexo C2 - Registro de riesgos de seguridad (amenazas y vulnerabilidades)

COD
RSQ01
Riesgo de seguridad
El sistema permite visualizar y actualizar informacin
de alpacas de otros rebaos. Un usuario debe tener
acceso nicamente a los registros de los Grupos
previamente asignados.
174
Tipo Probab
(A/V) ilidad
V
Alto
Impac
to
Alto
Priori
dad
1000
Anexo C3 - Registro de componentes de seguridad

COD
CSB01
Componente de seguridad
RS-Q01.
UserToken.
Contiene informacin de accesos a los Gupos de un determinado
rebao, bajo ciertos perfiles de usuario. Con lo cual permite el
control del acceso a datos de alpacas de cierto Grupo.
class UserToken:
@staticmethod
def set_grupo_id_list(request
, grupo_id_list):
request.session['grupo_id_list'] = grupo_id_list
@staticmethod
def get_grupo_id_list(session):
return session.get('grupo_id_list', False)
Ejemplo de uso:
Asignacin del privilegio::
grupo_id_list = list({d.id: d for d in Headquart.grupo_set.all()})
UserToken.set_grupo_id_list(request, grupo_id_list)
Validacin::
if camelido.id in UserToken.get_grupo_id_list(request.session):
#OK
else:
raise Exception( "Falta de privilegios ")
175
Anexo C4 Arquitectura de la aplicacin

Cdigo y Nombre del proyecto: QUALPACA
Versin
1.0


Capa
Modelo: M
Vista: V
Tecnologa
Django Model
Django View
Django Business
SAD Backend
Django Test
Template: T
Django Template
Bootstrap
JQUERY
AJAX+ JSON
SAD Frontend
Selenium
176
Funcin
Logs
los formularios
de ejecucin
Anexo C5 Estndares de desarrollo

Versin
1.0


ID
Trmino
Ejemplo
Proyecto
Paquetes
Base de datos
Tablas
Atributo PK
Atributo
Atributo FK
Paquetes
Clases
Variables
Contantes
Mtodo
<nombre_proyecto>
<nombre_carpeta>
<nombre_db>
id
<nombre_atributo>
<tabla>_id
<nombre_carpeta>
<nombre_variable>
<NOMBRE_CONSTANTE>
Enumerators
<NOMBRE_ENUM>
Archivos
Interfaces
177
agil_cont
catalogo_productos
agil_cont_db
id
functional_code
natural_person_id
catalogo_productos
class NaturalPerson
functional_code
DEFAULT="DNI"
def add();
def edit();
def delete();
def get_by_id(id);
DEFAULT="DNI"
CE="CE"
OTHERS="OTHERS"
IDENTITY_TYPES = (
(CE, "C.E."),
(OTHERS, "Otro.")
)
natural_person.html
Anexo C6 Mtodo de trabajo del equipo

Desarrollo de Plataforma Tecnolgica en la Web para la Competitividad de la Cadena
Productiva de Alpacas en la Regin Puno
Versin
1.0

3. Equipo de trabajo
Rol
Product
Owner
Scrum
Master
Dupla 1Doc./Dev.
Nombre
Dra. Nelida Gladys
Maquera Sosa
Ing. Fredy Abel
Huanca Torres
Ing. Fredy Abel
Huanca Torres
Ciudad
Juliaca
gladys.maqueragma@gmail.com
Correo/Celular
Tiempo
50%
Puno
abel.huanca@upeu.pe
30%
Puno
abel.huanca@upeu.pe
20%
Chullunquiani
asullom@gmail.com
50%
Dupla 2Dev.
Ing. ngel Sulln

Macalup
Est. Oscar David
Mendoza Apaza
Juliaca
oscdmdz@gmail.com
100%
Est. Elvis Al Vilca
Juliaca
fasco.elvis.45@gmail.com
50%
4. Herramientas
Elemento
Portal de
gerenciamiento
Portal de integracin
Modelo y Prototipado
Lenguaje de
programacin
Frameworks
Framework responsivo
Base de datos
IDE
Comunicaciones
Herramienta
Assembla.com
Hosting
Github.com
Enterprise
Architect 7.5
Balsamiq
Python
https://github.com/abelthf/qualpaca-project
Django 1.6.8
Bootstrap 2
MySQL 5.x
Sublime Text 2
Facebook
https://www.assembla.com/spaces/concytec-qualpaca
http://grupoinnop.pe/design
https://www.facebook.com/groups/513850221984640
178
5. Retos a superar
Desafo
Respecto a la metodologa scrum
Respecto al equipo distribuido

(parcial o totalmente, horarios,
idiomas diferentes)
Solucin
Definir la duracin del sprint a 4 semanas
Lea la wiki y utilice el foro de discusin del portal de
gerenciamiento (Mensajes)
Definir las tareas en base a una unidad de trabajo
diario o semanal (que incluya testes)
Informar el estado de las tareas en el portal de
gerenciamiento, incluye horas restantes.
Enviar el reporte de trabajo diario o semanal
(StandUp)
Documentacin en ingls
Respecto a las herramientas de

trabajo
Respecto a la experiencia de los
desarrolladores
Respecto a la documentacin
Falta de compromiso del cliente
Consigue una llamada con Hangout, Facebook o

Skype
Entrenamiento en las herramientas a usar
Cada cdigo, diagrama, prototipos debe seguir el
estndar de desarrollo elegido
Entrenamiento en las tecnologas a usar
El diseo/prototipo/restricciones deben estar listos
y validados a un Sprint de anticipacin
Involucrar al cliente en las reuniones y demos
179
Anexo C7 Prototipos principales

Proyecto: QUALPACA
Mdulo: Produccin
Fecha:
Requisito 1: Identificacin y registro de alpacas
ui index.html
180
ui add.html
Funcionalidad: Pgina que permite la administracin de registros de alpacas.

Aprobado por: Dra. Gladys Maquera Sosa
181
Anexo C8 Diseo del sistema

1
3
4
INFORMACIN GENERAL
Desarrollo de Plataforma Tecnolgica en la Web para la Competitividad de la Cadena
Productiva de Alpacas en la Regin Puno
Versin - Fecha
1.0 __04__/__11__/__2013__
ACTUALIZACIONES IMPORTANTES
Diseo integrado con los componentes de Backengo versin 1.0
LINKS DE DESCARGA O DE CONSULTA
Modelo [http://grupoinnop.pe/design] (Este hosting requiere contrasea)
Scripts:
No es necesario, Django genera automticamente las tablas.
ESTRUCTURA DEL MODELO
pkg Qualpaca Modules
El alcance de Qualpaca versin 1.0 consta de 3 mdulos:

backend: para configurar el sistema y administrar las cuentas de los usuarios (acceso restringido para
superusers).
production: crianza mejorada de alpacas. Registro, empadre, paricin, sanidad y esquila
w eb: la pgina web de Qualpaca (completamente independiente de los otros mdulos, se integra va json o
webservices)
Mdulo
--- ---app registro
182

class registro
space::Headquar(sede)
-
address: Text
is_active: Boolean
is_main: Boolean
name: Char
phone: Char
+sede
Camelido
+sede
1
1
0..*
space::Grupo
-
majada: Boolean
nombre: Char
+grupo
0..1
0..*
+camelido 0..* 0..1 0..*

GrupoCamelido
fecha_grupo: DateTime
-
codigo_arete: Char
consanguinidad_adn: Char
diametro_fibra: Char
fecha_destete: DateTime
fecha_nac: DateTime
imagen: Image
nombre: Char
observaciones: Text
parecido: Char
peso_bellon: Char
peso_nac: Char
procedencia_det: Text
---Modelo de clases
--- ---Capa(si es Models o Views(Views en MVC es Controllers))
--- --- ---registro app
--- --- --- ---Diagrama de clases de diseo Business Layer
class registro.business
business.py
CamelidoBusiness
+
+
+
+
+
+
+
+
+
+
+
get_arbol_gen_by_id(id :int) : json<Camelido>

get_by_id(id :int) : Camelido
get_list_by_headquart_and_fechas_and_grupo(rebanho_id :int, fecha_ini :DateTime, fecha_fin :DateTime, grupo_id :int?) : objects<Camelido>
get_list_by_headquart_and_filter(rebanho_id :int, filter :string?) : objects<Camelido>
get_list_by_headquart_and_sexo_and_filter(rebanho :Headquart, sexo :string, filter :string) : objects<Camelido>
get_list_by_sexo_and_filter(sexo :string, filter :string) : objects<Camelido>
get_page_by_headquart_and_grupo(rebanho_id :int, grupo_id :int?, order :string?, num_rows :int?, page_index :int?) : objects<Camelido>
get_retiro_list_by_headquart_and_fechas_and_grupo(rebanho_id :int, fecha_ini :DateTime, fecha_fin :DateTime, grupo_id :int?) : objects<Camelido>
initialize() : Camelido()
remove(id :int) : Camelido
save(camelido :Camelido) : Camelido
--- --- --- ---Diagrama de clases de diseo View Layer

class registro.v iew s
camelido
+
+
+
+
+
+
+
+
+
camelido_add(request :HttpRequest) : render_to_response,camelido_edit|HttpResponseRedirect

camelido_edit(request :HttpRequest, id :Integer) : render_to_response,camelido_edit|HttpResponseRedirect
camelido_ficha(request :HttpRequest, id :Integer) : render_to_response
camelido_json_by_filter(request :HttpRequest, filter :string) : render_to_response
camelido_report(request :HttpRequest, fecha_ini :DateTime, fecha_fin :DateTime, grupo_id :int?) : render_to_response
camelido_report_retiro(request :HttpRequest, fecha_ini :DateTime, fecha_fin :DateTime, grupo_id :int?) : render_to_response
camelido_retiro(request :HttpRequest, id :Integer) : camelido_remove|HttpResponseRedirect
hembra_json_by_filter(request :HttpRequest, filter :string) : render_to_response
macho_json_by_filter(request :HttpRequest, filter :string) : render_to_response
183
Diagrama de procesos de negocio para el mdulo de produccin

act Manej o Reproductiv o en Alpacas
Seleccin e Identificacin
(registro)
Inicio
Castracin (componente
opcional)
fin
Actividades simultneas
Faeneo,Venta, Descarte,...
(retiro)
[Ms de 4 servicios]
Sanidad
Esquila
Empadre y
Gestacin(empadre)
[Hasta 4 servicios]
fin
Qued
preada?
[si]
Paricin(paricion)
Manejo reproductivo en alpacas

Obs.
Calendario ganadero (genrico y personalizado
por zonas)
Calendairo sanitario
Destete
184
[no]
Operaciones de la clase business CamelidoBusiness

Metodo
get_arbol_gen_by_id()
json<Camelido>
Public
get_by_id() Camelido
Public
Notas
Parmetros
int [in] id
get_list_by_headquart_and_fec
has_and_grupo()
objects<Camelido>
Public
order by -id
Para el reporte de Registro de
alpacas(entradas).
if grupo_is is None: Traer todos los grupos
cuyo estado es seleccionado excepto Majada.
No traer alpacas con algn estado de retiro
(venta, muerte, etc.)
int [in] rebanho_id
get_list_by_headquart_and_filte order by codigo_arete

Este mtodo ser para buscar alpaca en el
r() objects<Camelido>
texbox principal, la view lo convertir en
Public
formato json
debe buscar segn el filter en todos los
Grupos, incluso en Majada. No traer los que
tienen algun estado de retiro
Debe mostrar el ltimo estado (paricin,
seleccionado. descartado si es majada)
int [in] rebanho_id
int [in] id
DateTime [in] fecha_ini

DateTime [in] fecha_fin
int? [in] grupo_id
string? [in] filter
La validacin de seguridad si el usuario

puede o no editar informacin de ese Grupo se
har cuando el usuario invoque la accin
get_list_by_headquart_and_sex
o_and_filter()
objects<Camelido>
Public
get_list_by_sexo_and_filter()
objects<Camelido>
Public
order by codigo_arete
Traer los que tienen como ltimo
estado=seleccionado
Headquart [in] rebanho
este mtodo se usar para buscar su madre o

padre
string [in] filter
order by codigo_arete
Traer los que tienen como ltimo
estado=seleccionado
string [in] sexo
string [in] sexo
string [in] filter
este mtodo se usar para buscar su madre o

padre
Debe buscar en todos los rebaos (heardquar)
get_page_by_headquart_and_gr order by -id

Si grupo_id es None, traer todos los grupos,
upo() objects<Camelido>
incluso Majada. No traer los que tienen algn
Public
estado de retiro (venta, muerte, etc.)
Debe mostrar el ltimo estado (paricin,
seleccionado. descartado si es majada)
La validacin de seguridad si el usuario
puede o no editar informacin de ese Grupo se
har cuando el usuario invoque la accin
get_retiro_list_by_headquart_a
nd_fechas_and_grupo()
objects<Camelido>
Public
initialize() Camelido()
Public
remove() Camelido
Public
int [in] rebanho_id

int? [in] grupo_id
string? [in] order
int? [in] num_rows
int? [in] page_index
order by -id
Para el reporte de Registro de
alpacas(entradas).
if grupo_is is None: Traer todos los grupos
cuyo estado es seleccionado excepto Majada.
No traer alpacas con algn estado de retiro
(venta, muerte, etc.)
int [in] rebanho_id
Retirar es cambiar su estado para algn

estado de retiro a una alpaca.
int [in] id
save() Camelido
Public

int? [in] grupo_id
Camelido [in] camelido
185
Operaciones de la clase view camelido

Metodo
Notas
camelido_add()
render_to_response,camelido_edit
|HttpResponseRedirect
Public
camelido_edit()
render_to_response,camelido_edit
|HttpResponseRedirect
Public
Parmetros
HttpRequest [in] request
camelido_ficha()
render_to_response
Public

Integer [in] id
Llamar los mtodos segn correspondan

Integer [in] id
camelido_json_by_filter()
render_to_response
Public
camelido_report()
render_to_response
Public
string [in] filter
llama a get_list_by_headquart_and_fechas_and_grupo

int? [in] grupo_id
camelido_report_retiro()
render_to_response
Public
llama a get_list_by_headquart_and_fechas_and_grupo

int? [in] grupo_id
llama a remove
camelido_retiro()
camelido_remove|HttpResponseR
edirect
Public
hembra_json_by_filter()
render_to_response
Public
macho_json_by_filter()
render_to_response
Public
Integer [in] id
string [in] filter
string [in] filter
186
Anexo C9 Formulario de lecciones aprendidas

Proyecto: QUALPACA
N Iteracin: 1
1. La distribucin de tareas fue acertada en tiempo, gracias al modelado de procesos de
negocio, al diseo detallado del sistema y al empeo del equipo de desarrollo.
2. El estilo de uso de los componentes de seguridad indicados en el backend permitieron
escribir cdigo limpio y en menos lneas de cdigo.

1. La resolucin de conflictos durante la sincronizacin del cdigo en el repositorio
remoto github.com
2.

1.
2.
187
Anexo C10 Acta de constitucin del proyecto

1
INFORMACIN GENERAL
Cdigo y Nombre del proyecto: QUALPACA - Desarrollo de Plataforma
Tecnolgica en la Web para la Competitividad de la Cadena Productiva de
Alpacas en la Regin Puno
Organizacin: CONCYTEC-UPeU/Grupo InnOp Per
Modalidad del servicio: Contrato
Fecha de inicio: 01-05-2013
Fecha de vencimiento: 30-09-2013 (Plazo de entrega: 4 meses)
Presupuesto estimado: S/. 12,000.00 NUEVOS SOLES
Presupuesto tope: S/. 12,000.00 NUEVOS SOLES
Dueo del producto: Gladys Maquera
Patrocinador del proyecto: CONCYTEC a travs de Gladys Maquera
Gerente del proyecto (Master): Abel Huanca
Versin - Fecha - Elaborado por
1.0 - 21/06/2013 - Abel Huanca
OBJETIVOS DEL PROYECTO

Desarrollar e implementar una plataforma tecnolgica basada en la Web
moderna para la Competitividad de la Cadena Productiva de Alpacas en la
Regin Puno
JUSTIFICACIN DEL PROYECTO

Proporcionar un sistema de informacin que colabore con el fortalecimiento de
las capacidades de mejoramiento gentico de la crianza de Alpacas que es la
base fundamental del Primer eslabn de la cadena productiva.
ALCANCE DEL PROYECTO

El proyecto consta de los siguientes actividades:
Evaluacin y pruebas de las diferentes mtodo y tecnologas para desarrollo
web moderna y segura
Creacin e implementacin de la plataforma tecnolgica basada en la Web
moderna para la Competitividad de la Cadena Productiva de Alpacas en la
Regin Puno
Creacin e implementacin de la pgina web donde se divulgar la informacin
referente a la mejora productiva de alpacas.
DESCRIPCIN GENERAL DEL SOFTWARE

El software es un aplicacin web como servicio (SaaS) totalmente responsivo
compatible con cualquier navegador web que registra y proporciona
informacin para el mejoramiento gentico de alpacas basado en el sistema de
empadre controlado, as como la produccin de fibra del rebao.
Mdulos:
1. Backend para la nube que gestione la informacin de muchas empresas y
asociaciones productoras de fibra de alpaca, donde los usuarios acceden a
la informacin segn sus funciones predefinidas.
2. Mdulo de produccin: Seleccin e identificacin, empadre y gestacin,
paricin y destete, sanidad, esquila, castracin y retiro de alpacas
188
3. Pgina Web donde se divulgar la informacin referente a la mejora

productiva de alpacas.
BENEFICIARIOS FINALES DEL SOFTWARE
Instituciones pblicas y privadas productoras de fibra de alpacas de la Regin
Puno
Productores independientes
REFERENCIAS
Product backlog o Requisitos del Sistema
FIRMA DE AUTORIZACIN DE LAS PARTES
Dra. Gladys Maquera Sosa

Por el CONCYTEC
Ing. Abel Huanca Torres

Gerente del Proyecto Qualpaca
189
Anexo C11 Sprint backlog

Nombre del Sprint: 1
Objetivos: [Funcionalidad del negocio que se va a generar]
1. Permitir el levantamiento de informacin de identificacin, clasificacin, empadre,
gestacin, paricin, destete, sanidad, esquila, castracin y retiro.
COD
T01
Sprint 1
Estado
Tarea:
Desarrollar el MODELO de datos para el mdulo de
PRODUCCIN y generar la administracin automtica
Django.
Descripcin:
Actualizar las apps:
apps/params
apps/rrhh
apps/sad
apps/space
Crear las apps:

apps/registro
apps/empadre
apps/paricion
apps/registro
apps/sanidad
apps/esquila
apps/castracin
apps/mod_produccion (sin tablas)
Crear las carpetas templates
templates/registro
templates/empadre
templates/paricion
templates/registro
templates/sanidad
templates/esquila
templates/castracin
templates/mod_produccion
templates/partials/produccin
1. Poder ingresar datos de prueba para todas las tablas
del mdulo de PRODUCCIN mediante el administrador
de Django.
2. Las tablas deben quedar integrados con las tablas de
seguridad del Backend en caso que as lo ameriten.
190
Hecho
Trabajo
restante
4 horas
Responsa
ble
ngel
Sullon
T02
Tarea:
Desarrollar la pgina index del mdulo de produccin
para listar y buscar alpacas.
Hecho
4horas
Oscar
Mendoza
Hecho
8horas
Elvis Ali
Hecho
16horas
Oscar
Mendoza
Descripcin:
Replicar template base para el mod_produccion con
men sidebar:
templates/base_mod_produccion.html
templates/base_mod_produccion_sidebar.html
templates/denied_mod_produccion.html
Listado de alpacas en :
templates/mod_produccion/camelido_list.html
apps/mod_produccion/views.camelido_list
Bsqueda asncrona (AJAX) de alpacas en:
templates/partials/produccion/header.html
apps/mod_produccion/views.camelido_json_by_filter
Redirigir a:
templates/registro/registro/index.html (dejar vaco)
apps/registro/views.registro_index
1. Visualizar o buscar alpacas del rebao y al encontrar
mostrar detalles del registro en otra ventana.
2. Al actualizar con mtodo GET en caso de errores,
debe mantenerse en el mdulo de PRODUCCION.
T03
Tarea:
Refinar el listado y bsqueda de alpacas
Descripcin:
Estos resultados deben mostrar alpacas con el ltimo
estado del camlido y segn privilegios del usuario.
Listado de alpacas en :
apps/mod_produccion/views.camelido_list
Bsqueda asncrona (AJAX) de alpacas en:
apps/mod_produccion/views.camelido_json_by_filter
T04

1. En el listado o bsqueda, mostrar alpacas con el
ltimo estado.
2. Permitir listar o buscar alpacas para los rebaos o
grupos asignados al usuario. Tambin usar llave de
seguridad.
Tarea:
Agregar y editar datos del camlido.
Descripcin:
Agregar alpaca en :
templates/registro/add.html
apps/registro/views.registro_add
Resultados en formato JSON:
apps/registro/views.macho_json_by_filter
apps/registro/views.hembra_json_by_filter
191
apps/registro/views.camelido_upload
Redirigir a:
templates/registro/registro/edit.html (cargar datos)
apps/registro/views.registro_edit
y desarrollar el mtodo editar.
T05

1. Registrar y actualizar datos de alpacas, verificar datos
obligatorios.
2. Registrar usuario que registra los datos de la alpaca.
3. No se debe permitir actualizar los datos de la alpaca si
el usuario no tiene permisos.
192
Anexo C12 Acta de conformidad del servicio o entrega

1
INFORMACIN GENERAL
Cdigo y Nombre del proyecto: QUALPACA - Desarrollo de Plataforma
Tecnolgica en la Web para la Competitividad de la Cadena Productiva de
Alpacas en la Regin Puno
Organizacin: CONCYTEC-UPeU/Grupo InnOp Per
Fecha de inicio: 01-05-2013
Fecha de vencimiento: (Plazo de entrega)
Presupuesto estimado: S/. 12,000.00 NUEVOS SOLES
Presupuesto tope: S/. 12,000.00 NUEVOS SOLES
Dueo del producto: Dra. Gladys Maquera
Patrocinador del proyecto: CONCYTEC a travs de Gladys Maquera
Gerente del proyecto (Master): Ing. Abel Huanca
FECHA DE ENTREGA: 04-12-2013
RESULTADO
Conforme: Si
Das atraso: 6 a partir del inicio del desarrollo
OBSERVACIONES
No hubo observaciones relevantes.
FIRMA DE CONFORMIDAD DEL CLIENTE O PATROCINADOR
Dra. Gladys Maquera Sosa
193
Anexo C13 Manual del usuario

Nombre de la
Aplicacin
BACKEND PARA APLICACIONES CON DJANGO
ltima
revisin
Elaborado
por
Caractersticas
Angel Sulln Macalup
Descarga,
Instalacin y
Ejecucin
Manual del Usuario

14-05-2014
Mdulo Backend para aplicaciones web SaaS seguras escritas en Django

y con la elegancia de Bootstrap. Permite gestionar diferentes partes del
sistema: usuarios, perfiles, recursos, permisos, mdulos, planes, mens,
asociaciones, empresas, sedes, logs, seguridad, internacionalizacin y
mucho ms.
Descarga gratis de GitHub

https://github.com/submitconsulting/backengo e instale las
dependecias:
$ pip install -r requirements.txt
Para ejecutar:
$python manage.py runserver
Pgina de
Inicio
194
Crear cuenta
de usuario
Formulario
de ingreso
195
Eleccin de la
empresa/sed
e y mdulo
Configuraci
n de los
planes SaaS
Creacin de
recursos
196
Creacin de
mens
Formulario
registro de
nuevas
empresas
Gestin de
empresas
197
Gestin de
sedes
Gestin de
usuarios
198
199

Tesis Upeu

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Tesis Upeu

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSIDAD PERUANA UNIN

UN MODELO PARA EL DESARROLLO DE

Tesis presentada para optar el grado de Magster en Ingeniera de

A mi amada esposa, Milva Gutierrez Quispe, por motivarme

A Dios, por haberme conducido en la elaboracin de este proyecto.

Marco conceptual .................................................................................................... 4

Modelo de procesos del software ................................................................... 4

Taxonoma de la seguridad .............................................................................. 4

Ingeniera del software .................................................................................... 7

Software como un servicio (SaaS) .................................................................... 7

Seguridad del software .................................................................................... 8

Desarrollo web ................................................................................................. 8

Revisin del estado del arte ..................................................................................... 9

Modelos de calidad del software en sintona con la Seguridad ...................... 9

Modelo de McGraw con la construccin de software seguro ....................... 12

SSE-CMM/ISO 21827, COBIT e ITIL en relacin a la seguridad del software . 13

Gua OWASP ................................................................................................... 19

Vulnerabilidades OWASP Top 10 ................................................................... 21

Microsoft SDL ................................................................................................. 23

Sustainable software security process (S3P) ................................................. 25

Controles de seguridad de ISO 27001 ............................................................ 26

Procesos giles de desarrollo de software ............................................................ 29

Marco general MSF-Agile ............................................................................... 30

Artefactos agile UP ......................................................................................... 32

Prcticas Scrum .............................................................................................. 36

Lugar de ejecucin ................................................................................................. 40

Equipos y materiales .............................................................................................. 40

Material bibliogrfico ..................................................................................... 41

Tipo de investigacin ............................................................................................. 41

Indicadores de evaluacin de la propuesta ........................................................... 42

Diagrama de flujo de las actividades de la Investigacin....................................... 44

Cronograma de actividades ................................................................................... 46

Presupuesto y financiamiento del proyecto de tesis ............................................. 48

Diseo grfico del modelo propuesto.................................................................... 50

Principios de seguridad .......................................................................................... 51

Defensa en profundidad ................................................................................ 51

Privilegios especficos .................................................................................... 51

Estilo de codificacin simple pero robusto .................................................... 51

Backend web seguro .............................................................................................. 52

Artefactos del backend web seguro ...................................................................... 54

Requisitos del sistema (o requisitos para el mdulo backend) ..................... 54

Registro de riesgos de seguridad (amenazas y vulnerabilidades). ................ 54

Registro de componentes de seguridad. ....................................................... 55

Arquitectura de la aplicacin ......................................................................... 55

Mtodo de trabajo del equipo ....................................................................... 56

Prototipos principales .................................................................................... 56

Diseo del sistema (para la iteracin)............................................................ 57

Anlisis de riegos de seguridad .............................................................................. 57

Artefactos del anlisis de riesgos de seguridad ..................................................... 59

Implementacin de los componentes de seguridad .............................................. 59

Artefactos de la implementacin de los componentes de seguridad ................... 61

Producto funcional seguro ............................................................................. 61

Demostracin y validacin de la seguridad ........................................................... 61

Artefactos de la demostracin y validacin de la seguridad ................................. 62

Formulario de lecciones aprendidas .............................................................. 62

Acerca del proyecto ............................................................................................... 64

Grupo InnOp Per .......................................................................................... 64

Proyecto UPeU-CONCYTEC 2013 ................................................................... 64

Qualpaca 1.0 .................................................................................................. 65

Materiales y mtodos .................................................................................... 65

Backend web seguro y la definicin del proyecto Qualpaca ................................. 66

Anlisis de riesgos de seguridad ............................................................................ 67

Implementacin de los componentes de seguridad .............................................. 67