Você está na página 1de 213

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

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

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

Demostracin y validacin de la seguridad ........................................................... 81

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

Implementacin de los componentes de seguridad .............................................. 83

6.4

Demostracin y validacin de la seguridad ........................................................... 83

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

Aporte a la seguridad del software

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.
Fuente: Tovar E y colaboradores (2006)

15

Tabla 5 Seguridad y COBIT, dominio adquirir e implementar


rea de proceso

Aporte a la seguridad del software

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.
Fuente: Tovar E y colaboradores (2006)
Tabla 6 Seguridad y COBIT, dominio entrega y soporte
rea de proceso

Aporte a la seguridad del software

DS2.Administracin Este punto puede ser complementado con normas y


de servicios

controles explcitos para el momento exteriorizar el

prestados por

desarrollo de software.

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

Fuente: Tovar E y colaboradores (2006)


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

Aporte a la seguridad del software

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.
Fuente: Tovar E y colaboradores (2006)

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.
Fuente: Tovar E y colaboradores (2006)

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
desarrollo de software.
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
Fecha de actualizacin
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
Fecha de actualizacin
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
Historial de revisiones
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
Historial de revisiones
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
Historial de revisiones
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

Registro de componentes de seguridad


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

Registro de componentes de seguridad


60

Herramientas

Herramientas de revisin y validacin automatizados y manuales

Security training meeting

Salidas

Producto funcional o incremento seguro

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


pueden revisarse en los anexos referidos.
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

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


pueden revisarse en los anexos referidos.
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

Implementacin de los componentes de seguridad


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

dj ango.contrib.auth.models::
Permission
+

__unicode__( ) : self.name
+permissions

0..*

+groups
+group_set 0..*

0..*

dj ango.contrib.auth.models::Group
+

__unicode__( ) : self.name

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
first_name: CharField
identity_num: CharField
last_name: CharField
photo: ImageField

__str__( ) : self.first_name, self.last_name, self.identity_num

+menu_set 0..*

+person

Menu
+

dj ango.contrib.auth.models::
AbstractUser

+user 0..1

__unicode__( ) : self.title

+menu_set

0..1

+parent 0..1
User

0..*

last_headquar_id: CharField
last_module_id: CharField

__unicode__( ) : self.username

1
+permission

+user_set

0..1

date_joined: DateTimeField
email: EmailField
first_name: CharField
is_active: BooleanField
is_staff: BooleanField
last_name: CharField
username: CharField

0..*
0..*

dj ango.contrib.auth.models::
Permission
+

UserEnterprise

__unicode__( ) : self.name
+permissions

0..*

+userenterprise_set

0..*

0..*
+userenterprise_set

+groups
+enterprise
+group_set 0..*

0..* +group

1
space/models.py::Enterprise

dj ango.contrib.auth.models::Group
+

enumeration
MODULE_CHOICES
BACKEND = Backend Manager
WEB = Web informativa
VENTAS = Ventas

__unicode__( ) : self.name

+groups

0..*

+initial_groups

0..*

is_active: BooleanField
is_actived: BooleanField
logo: ImageField
name: CharField
tax_id: CharField

__unicode__( ) : self.name
0..*

+module_set

0..*

+initial_groups_module_set 0..*

+enterprise_set

Module
+

__unicode__( ) : self.name

+module_set

0..*

+solutions

0..*

space/models.py::Solution
-

created_at: DateTimeField
description: CharField
is_active: BooleanField
is_actived: BooleanField
+solution
name: CharField
0..1
price: FloatField
test_date: DateTimeField
test_image: ImageField
updated_at: DateTimeField

__unicode__( ) : self.name

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

Implementacin de los componentes de seguridad


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.
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 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
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 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
Consultado el 08 de Septiembre de 2011
Microsoft,

2011.

Security

Development

Lifecycle

for

Agile

Development

http://msdn.microsoft.com/en-us/library/windows/desktop/ee790621.aspx
Consultado el 08 de Septiembre de 2011
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

Consultado el 08 de Septiembre de 2011


Fernndez J, 2006. OWASP presentacin del proyecto. Conferencias FIST
https://www.owasp.org/images/b/b6/OWASP-Testing-Project_v1.pdf
Consultado el 08 de Septiembre de 2011
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

desarrollo de software.
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

Pruebas de aceptacin y de seguridad:


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

RF04
/2

Pruebas de aceptacin y de seguridad:


1.
2.
Requisito 4: (cambio en reemplazo de la RF03)
Descripcin:
Pruebas de aceptacin y de seguridad:
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: ______ --_______________________________________________________
Fecha de actualizacin: ____/_____/______
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: ______ --_______________________________________________________
Fecha de actualizacin: ____/_____/______
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
Solicitudes y respuestas con AJAX
Generacin de objetos HTML en tiempo
de ejecucin
Hojas de estilos personalizados
Pruebas funcionales en la Web

Anexo A5 Estndares de desarrollo


1. Informacin general
Cdigo y nombre del proyecto:

2. Historial de revisiones
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


1. Informacin general
Cdigo y nombre del proyecto:

2. Historial de revisiones
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

Pruebas de aceptacin y de seguridad:


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)
Pruebas de aceptacin y de seguridad:
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

Pruebas de aceptacin y de seguridad:


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.
Pruebas de aceptacin y de seguridad:
Inicio de sesin
Descripcin:
Permite iniciar sesin de la aplicacin web que sirva para utilizar
ciertas funcionalidades especficas del sistema para el usuario
registrado.
Pruebas de aceptacin y de seguridad:

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
Pruebas de aceptacin y de seguridad:
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
Pruebas de aceptacin y de seguridad:
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
Fecha de actualizacin: __04__/__09__/__2013__
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

A: Amenza V: Vulnerabilidad
Probabilidad: Alta, Media, Baja
Impacto: Alta, Media, Baja

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
Fecha de actualizacin: __04__/__09__/__2013__
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

Riesgos de seguridad
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
apps.utils.decorators.permiss
ion_resource_required
apps.utils.security.
SecurityKey
Django settings.DEBUG
django.conf.urls.url
apps.utils.decorators.permiss
ion_resource_required
apps.utils.security.
SecurityKey
Django csrf_token
crispy form

django.conf.urls.url
apps.utils.decorators.permiss
ion_resource_required

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


1. Informacin general
Cdigo y Nombre del proyecto: Backengo
Desarrollo de un Backend web seguro para Django

2. Historial de revisiones
Versin
1.0

- Fecha - Elaborado por


04/04/2013 Angel Sulln

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

111

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
Solicitudes y respuestas con AJAX
Generacin de objetos HTML en tiempo
de ejecucin
Hojas de estilos personalizados
Pruebas funcionales en la Web

Anexo B5 Estndares de desarrollo


1. Informacin general
Cdigo y Nombre del proyecto: Backengo

2. Historial de revisiones
Versin
1.0

- Fecha - Elaborado por


04/04/2013 Angel Sulln

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>

112

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 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
Mdulo: Backend, app: accounts
Fecha:14/08/2013
Requisito 2: Ingreso al sistema
ui 2-login.html

Funcionalidad: Incia sesin de usuario


Aprobado por:

114

Proyecto: Backengo
Mdulo: Backend, app: accounts
Fecha:14/08/2013
Requisito 3: Apertura de Cuentas del sistema
ui 3-signup.html

Funcionalidad: Registra nuevo usuario


Aprobado por:

115

Proyecto: Backengo
Mdulo: Backend, app: accounts
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
Mdulo: Backend, app: accounts
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
Mdulo: Backend, app: accounts
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
Mdulo: Backend, app: accounts
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
Mdulo: Backend, app: space
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
Mdulo: Backend, app: space
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
Mdulo: Backend, app: sad
Fecha:14/08/2013
Requisito 12: Gestin de recursos del sistema
ui index.html

ui add.html

Funcionalidad:
Aprobado por:

127

Proyecto: Backengo
Mdulo: Backend, app: sad
Fecha:14/08/2013
Requisito 13: Gestin de perfiles de usuario
ui index.html

ui add.html

Funcionalidad:
Aprobado por:

128

Proyecto: Backengo
Mdulo: Backend, app: sad
Fecha:14/08/2013
Requisito 14: Configuracin de privilegios de perfiles de usuario

ui permissions_edit.html

Funcionalidad:
Aprobado por:

129

Proyecto: Backengo
Mdulo: Backend, app: sad
Fecha:14/08/2013
Requisito 15: Gestin de mdulos del sistema
ui index.html

ui add.html

Funcionalidad:
Aprobado por:

130

Proyecto: Backengo
Mdulo: Backend, app: space
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
Mdulo: Backend, app: sad
Fecha:14/08/2013
Requisito 17: Configuracin de planes del sistema
ui plans_edit

Funcionalidad:
Aprobado por:

132

Proyecto: Backengo
Mdulo: Backend, app: sad
Fecha:14/08/2013
Requisito 18: Gestin de mens dinmicos del sistema
ui index.html

ui add.html

Funcionalidad:
Aprobado por:

133

Proyecto: Backengo
Mdulo: Backend, app: sad
Fecha:14/08/2013
Requisito 19: Configuracin del sistema
ui basic.html

Funcionalidad:
Aprobado por:

134

Proyecto: Backengo
Mdulo: Backend, app: sad
Fecha:14/08/2013
Requisito 20: Gestin de copias de seguridad de base de datos
ui index.html

Funcionalidad:
Aprobado por:

135

Proyecto: Backengo
Mdulo: Backend, app: sad
Fecha:14/08/2013
Requisito 21: Seguimiento de accesos al sistema
ui index.html

Funcionalidad:
Aprobado por:

136

Proyecto: Backengo
Mdulo: Backend, app: sad
Fecha:14/08/2013
Requisito 22: Seguimiento de auditoria
ui index.html

ui list.html

Funcionalidad:
Aprobado por:

137

Proyecto: Backengo
Mdulo: Backend, app: sad
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
Cdigo y Nombre del proyecto: Backengo
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:

---Modelo del dominio

140

--- ---params
--- --- ---Diagrama de entidades
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
modified_in: DateTime
msnm: Float
name: Char
registered_at: DateTime
utm: Char

--- --- ---Diagrama de entidades


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

registered_at: DateTime

group: Group
registered_at: DateTime

+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
modified_in: DateTime
name: Char
phone: Char
registered_at: DateTime

+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
modified_in: DateTime
name: Char
registered_at: DateTime
tax_id: Char

is_active: Boolean
logo: Image
modified_in: DateTime
name: Char
registered_at: DateTime

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
--- --- ---Diagrama de entidades

142

params::Person

0..*

0..1

0..*

0..*

last_headquar_id: Char
last_module_id: Char

0..*

+module_set

0..*

group: Group
registered_at: DateTime

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
modified_in: DateTime
photo: Image
registered_at: DateTime

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
modified_in: DateTime
name: Char
registered_at: DateTime
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
modified_in: DateTime
name: Char
registered_at: DateTime

0..1

0..* -

address: Text
is_active: Boolean
is_main: Boolean
modified_in: DateTime
name: Char
phone: Char
registered_at: DateTime

+locality 0..1 +headquar_set


0..*
-

is_active: Boolean
location: Text
modified_in: DateTime
msnm: Float
name: Char
registered_at: DateTime
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


--- --- --- ---Diagrama de clases de diseo
class params/models.py
Nombre:
Paquete:
Versin:
Autor:

params/models.py
params/models.py
1.0
Asullom

backenddj
Model
LocalityType
+

__unicode__( ) : self.name

+locality_type

0..1

+locality_set 0..*
Model
models.py
Locality
+

__unicode__( ) : self.name,self.location

Person
+

__unicode__( ) : self.first_name

--- --- --- --- ---Ejemplo completo del diagrama (explica las relaciones a detalle)

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


--- --- --- ---Diagrama de clases de diseo
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
+

__unicode__( ) : self.name
+headquar_set

+person

1
+headquart
+headquar_set
1

0..*

0..*

+profile 0..1
+association

Profile
+profile +
+user
dj ango.contrib.auth.models::User
+

__unicode__( ) : self.username

+user_set

__unicode__( ) : self.user.username

0..*

0..1

+user
1

+userprofileheadquart_set

0..1 space/models.py::Association

+userprofileheadquart_set
+enterprise

UserProfileHeadquar

space/models.py::Enterprise

0..*

__unicode__( ) : self.name

+association_set

0..*

__unicode__( ) : self.name

0..*
+userprofileheadquart_set

0..*

+enterprise_set

0..*

UserProfileEnterprise
+userprofileenterprise_set
+groups

0..*

0..*
+group

dj ango.contrib.auth.models::Group
1
+

__unicode__( ) : self.last_name

UserProfileAssociation

+group

+userprofileassociation_set

1
+groups
1

+solution

0..*

+group

+solution

0..1

+group_set

0..*
+initial_groups

0..*

__unicode__( ) : self.name

+solutions

0..*
+permissions

+module_set

dj ango.contrib.auth.models::
Permission
+

+module_set 0..*
+permission

+content_type

0..* +

__unicode__( ) : self.name

0..*

+menu_set
Menu

0..*

dj ango.contrib.auth.models::
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


--- --- --- ---Diagrama de clases de diseo

145

0..*

class space/models.py
Nombre:
Paquete:
Versin:
Autor:

space/models.py
space/models.py
1.0
Asullom

backenddj

Solution
+

+solution

__unicode__( ) : self.name

0..1

+solution

0..1

+association_set 0..*
Association
+

+enterprise_set 0..*

__unicode__( ) : self.name

+association

Enterprise
+

0..1
+enterprise

__unicode__( ) : self.name

+headquar_set 0..* +headquar_set 0..*


Headquar(sede)
+

__unicode__( ) : self.name

+headquart_set
0..*

+locality
Model

0..1
models.py
params/models.py::Locality
+

__unicode__( ) : self.name,self.location

--- ---Views Layer


--- --- ---accounts
--- --- --- ---Diagrama de clases de diseo
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", retornar exception informando que el
"name" del Enterprise ya existe
5 Si existe otro Enterprise con el mismo
"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
UserProfileEnterprise
11 Salvar los Group de la asociacin (de
acuerdo a la Solution elegida) en
UserProfileAssociation
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"
5 Si existe otro Person con el mismo
"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
8 Si existe otro Association con el mismo
"name", retornar exception informando que el
"name" del Association ya existe
9 Salvar Association
10 Si existe otro Enterprise con el mismo
"name", retornar exception informando que el
"name" del Enterprise ya existe
11 Si existe otro Enterprise con el mismo
"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

UserProfileEnterprise
17 Salvar los Group de la asociacin (de
acuerdo a la Solution elegida) en
UserProfileAssociation
18 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 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
HttpResponseRedirect("/accounts/choice_headqua
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
HttpResponseRedirect("/accounts/choice_headqua
r/")
#Si hay algun exception mantener datos
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
4 Obtener el listado de Group ya asignados de
User para las Enterprise ( si tuviese) en
UserProfileEnterprise y mostrarlos en el
template profile_edit.html
5 Obtener el listado de Group ya asignados de
User para las Association ( si tuviese) en
UserProfileAssociation y mostrarlos en el
template profile_edit.html
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":
1 Si existe otro User con el mismo "email",
retornar exception informando que el "email"
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
5 Si existe otro Person con el mismo
"first_name", "last_name" , "identity_num" y
"identity_type", retornar exception informando
que el Person ya existe. Use normalize
6 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"
7 Volver a Salvar Person con los datos
recibidos del formulario
#Si hay algun exception mantener datos
enviados en el template profile_edit.html sin
hacer cambios en la DB

--- --- ---mod_backend


--- --- --- ---Diagrama de clases de diseo

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


--- --- --- ---Diagrama de clases de diseo

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
#Si hay algun exception mantener datos
enviados en el template add.html
2 Salvar Locality
Cdigo inicial:
d = Locality()
if request.method == "POST":
...
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")
d = get_object_or_404(Locality, id=id)
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",
c), 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 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, retornar exception informando que el
name del Locality ya existe
#Si hay algun exception mantener datos
enviados en el template edit.html
2 Salvar Locality
Cdigo inicial:
id = Security.is_valid_key(request, key,
"locality_upd")
d = get_object_or_404(Locality, id=id)
if request.method == "POST":
...
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_module":_("Locality"),
"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_module":_("Locality"),
"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_module":_("Locality"),
"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

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 Actualizar el campo Locality.is_active
para False/True

rq [in] request

Cdigo inicial:
id = Security.is_valid_key(request, key,
"locality_%s" % state )
d = get_object_or_404(Locality, id=id)
d.is_active = (True if state ==
"reactivar" else False)
d.save()

str [in] key

152

str [in] state

--- --- --- --- ---Ejemplo completo del diagrama (explica las relaciones a detalle)
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
params/models.py::Locality

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


--- --- --- ---Diagrama de clases de diseo

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
#Si hay algun exception mantener datos
enviados en el template add.html
2 Salvar Group

group_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 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
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 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
#Si hay algun exception mantener datos
enviados en el template edit.html
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",
c), to_action("index")
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
4 Obtener el listado de
Menu.MODULES y mostrarlos en el
template add.html
-Si method="POST":
#Si hay algun exception mantener
datos enviados en el template
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",
c), 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 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
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 Obtener el listado de Menu
padres activos y mostrarlos en
el template edit.html
5 Obtener el listado de
Permission y mostrarlos en el
template edit.html
6 Obtener el listado de
Menu.MODULES y mostrarlos en el
template edit.html

str [in] key

-Si method="POST":
#Si hay algun exception mantener
datos enviados en el template
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
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 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",
c), to_action("index")
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
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 Module existe en la BD, sino,
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
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 Module existe en la BD, sino,
retornar exception informando que Module no fu
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
3 Eliminar los antiguos privilegios usando
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":
1 Eliminar los antiguos privilegios usando
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
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 Module existe en la BD, sino,
retornar exception informando que Module no fu
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",
c), to_action("index")
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
#Si hay algun exception mantener datos
enviados en el template add.html sin hacer
cambios en la DB

resource_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

158

incorrecta
2 Validar si Permission existe en la BD,
sino, retornar exception informando que
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",
c), to_action("index")
Public

str [in] key

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 Permission existe en la BD,
sino, retornar exception informando que
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
#Si hay algun exception mantener datos
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":
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
"first_name", "last_name" , "identity_num" y
"identity_type", retornar exception
informando que el Person ya existe. Use
normalize
5 Si existe otro Person con el mismo

159

"identity_num" y "identity_type", retornar


exception informando que ya existe un Person
con "identity_num" y "identity_type"
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
User.groups.add(Group)
#Si hay algun exception mantener datos
enviados en el template add.html sin hacer
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
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 Person existe en la BD, sino,
retornar exception informando que Person no
fu encontrado
3 Obtener el Headquar actual, id =
DataAccessToken.get_headquar_id(request.sess
ion)
4 Obtener el listado de Module activos
asignados a su Enterprise y Asociation del
Headquar actual
5 Obtener el listado de Group
pertenecientes al Module (del 4 paso) y
darle la forma indicada en la IGU y
mostrarlos en el template
add_from_person.html (de la forma
Module>Group)
6 Obtener Person.IDENTITY_TYPES y
mostrarlos en el template
add_from_person.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
"first_name", "last_name" , "identity_num" y
"identity_type", retornar exception
informando que el Person ya existe. Use
normalize
5 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"
6 Actualizar Person, ahora con los datos
recibidos del formulario
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
User.groups.add(Group)
#Si hay algun exception mantener datos
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
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 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
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 User existe en la BD, sino,
retornar exception informando que User no
fu encontrado
3 Intentar obtener Profile con User.id del
paso 2 si existe, sino dejar pasar sin
obtener datos del Profile del User
4 Obtener el Headquar actual, id =
DataAccessToken.get_headquar_id(request.sess
ion)
5 Obtener el listado de Group ya asignados
de User para la Headquar ( si tuviese) en
UserProfileHeadquar y mostrarlos en el
template edit.html
6 Obtener el listado de Group ya asignados
de User para la Headquar.enterprise ( si
tuviese) en UserProfileEnterprise y
mostrarlos en el template edit.html
7 Obtener el listado de Group ya asignados
de User para la Headquar.association ( si
tuviese) en UserProfileAssociation y
mostrarlos en el template edit.html
8 Obtener el listado de Module activos
asignados a su Enterprise y Asociation del
Headquar actual
9 Obtener el listado de Group
pertenecientes al Module (del 8 paso) y
darle la forma indicada en la IGU y
mostrarlos en el template edit.html (de la
forma Module>Group)
10 Obtener Person.IDENTITY_TYPES y
mostrarlos en el template edit.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 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
6 Si existe otro Person con el mismo
"first_name", "last_name" , "identity_num" y
"identity_type", retornar exception
informando que el Person ya existe. Use
normalize
7 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"
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)
13 Salvar los Group de la sede
(request.POST.getlist("groups_sede")) en
UserProfileHeadquar
14 Salvar los Group de la empresa
(request.POST.getlist("groups_enterprise"))
en UserProfileEnterprise
15 Salvar los Group de la asociacin
(request.POST.getlist("groups_association"))
en UserProfileAssociation
16 Salvar los Group de la sede, empresa
yasociacin, evitando Group repetidos usando
User.groups.add(Group)
#Si hay algun exception mantener datos
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
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 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 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
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 User existe en la BD, sino,
retornar exception informando que User no
fu encontrado
3 Intentar obtener Profile con User.id del
paso 2 si existe, sino dejar pasar sin
obtener datos del Profile del User
4 Obtener el listado de Group ya asignados
de User para las Headquar ( si tuviese) en
UserProfileHeadquar y mostrarlos en el
template view.html
5 Obtener el listado de Group ya asignados
de User para las Enterprise ( si tuviese)
en UserProfileEnterprise y mostrarlos en el
template view.html
6 Obtener el listado de Group ya asignados
de User para las Association ( si tuviese)
en UserProfileAssociation y mostrarlos en el
template view.html
7 Obtener Person.IDENTITY_TYPES y
mostrarlos en el template view.html

--- --- ---space


--- --- --- ---Diagrama de clases de diseo

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":
1 Si existe otro Association con el mismo
name, retornar exception informando que el
name del Association ya existe
#Si hay algun exception mantener datos
enviados en el template edit_current.html
2 Salvar Association

association_upload() json < dict>


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

#enterprise

164

Metodo

enterprise_add() Enterprise in
render_to_response("space/enterprise/add.html",
c), to_action("index")
Public

Notas

Parmetr
os
rq [in]
request

1 Inicializar Enterprise
-Si method="POST":
1 Si existe otro Enterprise con el mismo
"name", retornar exception informando que el
"name" del Enterprise ya existe
2 Si existe otro Enterprise con el mismo
"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
#Si hay algun exception mantener datos
enviados en el template add.html sin hacer
cambios en la DB

enterprise_delete() to_action("index")
Public

enterprise_edit() Enterprise in
render_to_response("space/enterprise/edit.html",
c), 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 Enterprise existe en la BD,
sino, retornar exception informando que
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
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 Enterprise existe en la BD,
sino, retornar exception informando que
Enterprise no fu encontrado

str [in]
key

-Si method="POST":
1 Si existe otro Enterprise con el mismo
name, retornar exception informando que el
name del Enterprise ya existe
2 Si existe otro Enterprise con el mismo
tax_id, retornar exception informando que el
tax_id del Enterprise ya existe
3 Salvar Enterprise
#Si hay algun exception mantener datos
enviados en el template edit.html

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":
1 Si existe otro Enterprise con el mismo
name, retornar exception informando que el
name del Enterprise ya existe

165

2 Si existe otro Enterprise con el mismo


tax_id, retornar exception informando que el
tax_id del Enterprise ya existe
#Si hay algun exception mantener datos
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

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 Enterprise existe en la BD,
sino, retornar exception informando que
Enterprise no fu encontrado
3 Actualizar el campo Enterprise.is_active
para False/True

str [in]
state

str [in]
key

enterprise_upload() json < dict>


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

#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
#Si hay algun exception mantener datos
enviados en el template add.html sin hacer
cambios en la DB

headquar_change_association() Headquar in
render_to_response("space/headquar/change_associat
ion.html", c), to_action("index")
Public

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 Headquar existe en la BD,
sino, retornar exception informando que
Headquar no fu encontrado
3 Obtener el listado en json de los
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
#Si hay algun exception mantener datos
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

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 Headquar existe en la BD,
sino, retornar exception informando que
Headquar no fu encontrado
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
dependencias con otras tablas, sino,
retornar exception informando que Headquar
est asignado en la tabla donde fu
encontrada
5 Eliminar Headquar

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 Headquar existe en la BD,
sino, retornar exception informando que
Headquar no fu encontrado
3 Obtener el listado en json de los
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
#Si hay algun exception mantener datos
enviados en el template edit.html
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

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 Headquar existe en la BD,
sino, retornar exception informando que
Headquar no fu encontrado
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
#Si hay algun exception mantener datos
enviados en el template add.html
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

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 Solution existe en la BD,
sino, retornar exception informando que
Solution no fu encontrado
3 Validar si Solution no tiene
dependencias con otras tablas, sino,
retornar exception informando que
Solution est asignado en la tabla donde
fu encontrada
4 Eliminar Solution

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 Solution existe en la BD,
sino, retornar exception informando que
Solution no fu encontrado

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
#Si hay algun exception mantener datos
enviados en el template edit.html
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

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 Solution existe en la BD,
sino, retornar exception informando que
Solution no fu encontrado
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:
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. 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
Fecha de actualizacin: __04__/__11__/__2013__
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

Pruebas de aceptacin y de seguridad:


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

Pruebas de aceptacin y de seguridad:


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

RF04
/2

Pruebas de aceptacin y de seguridad:


1.
2.
Requisito 4: Sanidad
Descripcin:
172

Estado

Estimac.
(horas)

Prioridad

Nuevo

40

10

Nuevo

40

Nuevo

20

Nuevo

Pruebas de aceptacin y de seguridad:


1.
2.
Requisito 5: Esquila
Descripcin:

Nuevo

20

Nuevo

10

Nuevo

10

Pruebas de aceptacin y de seguridad:


1.
2.
Requisito 6: Retiro
Descripcin:
Pruebas de aceptacin y de seguridad:
1. Alpaca X ya no est en el registro de alpacas
reproductoras
2.
Requisito 7: Castracin
Descripcin:
Pruebas de aceptacin y de seguridad:
1.
2.

173

Anexo C2 - Registro de riesgos de seguridad (amenazas y vulnerabilidades)


Proyecto: QUALPACA -- Desarrollo de Plataforma Tecnolgica en la Web para la
Competitividad de la Cadena Productiva de Alpacas en la Regin Puno
Fecha de actualizacin: __04__/__11__/__2013__
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.

A: Amenza V: Vulnerabilidad
Probabilidad: Alta, Media, Baja
Impacto: Alta, Media, Baja

174

Tipo Probab
(A/V) ilidad
V
Alto

Impac
to
Alto

Priori
dad
1000

Anexo C3 - Registro de componentes de seguridad


Proyecto: QUALPACA -- Desarrollo de Plataforma Tecnolgica en la Web para la
Competitividad de la Cadena Productiva de Alpacas en la Regin Puno
Fecha de actualizacin: __04__/__11__/__2013__
COD
CSB01

Componente de seguridad

Riesgos 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


1. Informacin general
Cdigo y Nombre del proyecto: QUALPACA

2. Historial de revisiones
Versin
1.0

- Fecha - Elaborado por


04/04/2013 Angel Sulln

3. Arquitectura de la aplicacin MTV (equivalente a MVC)


Capa
Modelo: M
Vista: V

Tecnologa
Django Model
Django Test/Unit Test
Django View
Django Business
SAD Backend

Django Test
Template: T

Django Template
Bootstrap
JQUERY
AJAX+ JSON
SAD Frontend

Selenium

176

Funcin
Entidades y mapeamientos
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
Solicitudes y respuestas con AJAX
Generacin de objetos HTML en tiempo
de ejecucin
Hojas de estilos personalizados
Pruebas funcionales en la Web

Anexo C5 Estndares de desarrollo


1. Informacin general
Cdigo y Nombre del proyecto: QUALPACA

2. Historial de revisiones
Versin
1.0

- Fecha - Elaborado por


04/04/2013 Angel Sulln

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>

177

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_TYPES = (
(DEFAULT, "D.N.I."),
(CE, "C.E."),
(OTHERS, "Otro.")
)
natural_person.html
INaturalPersonService

Anexo C6 Mtodo de trabajo del equipo


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

2. Historial de revisiones
Versin
1.0

- Fecha - Elaborado por


04/04/2013 Angel Sulln

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
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
HISTORIAL DE REVISIONES
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
---Modelo del dominio
--- ---app registro
182

--- --- ---Diagrama de entidades


class registro

space::Headquar(sede)
-

address: Text
is_active: Boolean
is_main: Boolean
modified_in: DateTime
name: Char
phone: Char
registered_at: DateTime
+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
registered_at: 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
registered_at: DateTime

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

DateTime [in] fecha_ini


DateTime [in] fecha_fin
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

HttpRequest [in] request

HttpRequest [in] request


Integer [in] id

Llamar los mtodos segn correspondan


Integer [in] id

HttpRequest [in] request

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

HttpRequest [in] request


DateTime [in] fecha_ini
DateTime [in] fecha_fin
int? [in] grupo_id

camelido_report_retiro()
render_to_response
Public

llama a get_list_by_headquart_and_fechas_and_grupo

HttpRequest [in] request


DateTime [in] fecha_ini
DateTime [in] fecha_fin
int? [in] grupo_id

llama a remove
camelido_retiro()
camelido_remove|HttpResponseR
edirect
Public

HttpRequest [in] request

hembra_json_by_filter()
render_to_response
Public

HttpRequest [in] request

macho_json_by_filter()
render_to_response
Public

HttpRequest [in] request

Integer [in] id

string [in] filter

string [in] filter

186

Anexo C9 Formulario de lecciones aprendidas


Proyecto: QUALPACA
N Iteracin: 1
Qu sali bien en la Iteracin
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.

Qu no sali bien en la Iteracin


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

Qu mejoras vamos a implementar en la siguiente Iteracin


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
HISTORIAL DE REVISIONES
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


Proyecto: QUALPACA -- Desarrollo de Plataforma Tecnolgica en la Web para la
Competitividad de la Cadena Productiva de Alpacas en la Regin Puno
Nombre del Sprint: 1
Fecha de actualizacin: __05__/__11__/__2013__
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
Pruebas de aceptacin y de seguridad:
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
Pruebas de aceptacin y de seguridad:
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

Pruebas de aceptacin y de seguridad:


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

Pruebas de aceptacin y de seguridad:


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