Cespedes CP

UNIVERSIDAD RICARDO PALMA
FACULTAD DE INGENIERÍA
ESCUELA PROFESIONAL DE INGENIERÍA INFORMÁTICA
“DESARROLLO DE UNA APLICACIÓN WEB CRM

PARA OPTIMIZAR LA GESTIÓN DEL PROCESO DE
VENTA DE UNA EMPRESA INMOBILIARIA”
TESIS
PARA OPTAR EL TÍTULO PROFESIONAL DE INGENIERO INFORMÁTICO
PRESENTADO POR:
CÉSPEDES ROMERO, CARMEN DEL PILAR
LIMA – PERÚ
2013
CONTENIDO
INTRODUCCIÓN ...................................................................................................................... 6
CAPÍTULO I: VISIÓN DEL PROYECTO................................................................................ 8
1.1. El Problema. ............................................................................................................... 8
1.1.1. El Negocio. ......................................................................................................... 8
1.1.2. Procesos del Negocio. ........................................................................................ 8
1.1.3. Descripción del Problema. ................................................................................ 13
1.2. Fundamentación del Problema. ................................................................................ 13
1.2.1. Marco Teórico. ................................................................................................. 13
1.2.1.1. Marketing Relacional. ...................................................................................... 13
1.2.1.2. Sistemas y Tecnologías de Información. .......................................................... 15
1.2.1.3. Customer Relationship Management (CRM). .................................................. 18
1.2.1.4. Ingeniería de Software. ..................................................................................... 22
1.2.1.5. Lenguajes de programación. ............................................................................. 27
1.2.1.6. Bases de datos. .................................................................................................. 28
1.2.1.7. Web Server. ...................................................................................................... 30
1.2.1.8. Gestión de Proyectos. ....................................................................................... 30
1.2.2. Estado del arte. ................................................................................................. 46
1.2.2.1. Lenguajes de Programación.............................................................................. 46
1.2.2.2. Sistemas de Gestión de Base de Datos ............................................................. 51
1.2.2.3. Servidores Web ................................................................................................ 57
1.2.2.4. SOA .................................................................................................................. 60
1.2.2.5. Cloud Computing ............................................................................................. 67
1.2.2.6. WEB 2.0 Y CRM ............................................................................................. 73
1.2.2.7. API Google Maps ............................................................................................. 76
1.2.2.8. API Google Chart ............................................................................................. 77
3.1. Benchmarking. .......................................................................................................... 78
3.1.1. Microsoft Dynamics ......................................................................................... 78
3.1.2. SugarCRM ........................................................................................................ 81
3.1.3. SalesForce ......................................................................................................... 85
3.1.4. Benchmarking de los CRMs ............................................................................. 87
1.4 Objetivos del proyecto. ............................................................................................. 88
1.5 Beneficios del proyecto. ........................................................................................... 88
1.5.1 Beneficios tangibles .............................................................................................. 88
1.5.2 Beneficios intangibles: ......................................................................................... 88
1.5.3 Marco lógico. ........................................................................................................ 89
1.5.4 Objetivo General: ................................................................................................. 90
1.5.5 Objetivos Específicos: .......................................................................................... 90
1.6 Alcance del proyecto. ............................................................................................... 91
CAPÍTULO II: MODELADO DEL NEGOCIO ...................................................................... 93
2.1 Reglas del negocio .......................................................................................................... 93
2.1. Casos de uso del negocio .......................................................................................... 94
2.2. Especificaciones Casos de uso del negocio más significativos ................................ 95
2.2.1 Especificación del Caso de Uso del negocio “Cotizar Inmueble”........................... 95
2.2.2 Especificación del Caso de Uso del negocio “Separar Inmueble” .......................... 98
2.2.3 Especificaciones de los Casos de Uso del Negocio Restantes .............................. 101
CAPÍTULO III: REQUERIMIENTOS DEL SISTEMA ....................................................... 102
3.1. Requerimientos del software. ................................................................................. 102
3.1.1. Requerimientos No Funcionales ..................................................................... 102
3.1.2. Matriz de Requerimientos .............................................................................. 103
3.2. Casos de uso del sistema. ....................................................................................... 112
3.2.1. Diagrama de actores del sistema. ................................................................... 112
3.2.2. Diagrama de paquetes. .................................................................................... 113
3.2.3. Casos de uso del sistema. ............................................................................... 118
3.2.4. Matriz CUN vs CUS ....................................................................................... 119
3.2.5. Lista de CUS por procesos ............................................................................. 120
3.3. Especificaciones de los Casos de Uso del Sistema más significativos................... 121
3.3.1 Especificación del Caso de Uso del Sistema: “Cotizar Inmueble” ....................... 121
3.3.2 Especificación del Caso de Uso del Sistema: “Gestionar Cliente” ....................... 124
3.3.3 Especificación del Caso de Uso del Sistema: “Separar Inmueble” ....................... 127
3.3.4 Especificación del Caso de Uso del Sistema: “Gestionar Inmueble” .................... 129
3.4. Especificaciones de los Casos de Uso del Sistema Restantes ................................ 131
3.5. Modelo Conceptual del Sistema ............................................................................. 131
3.5.1. Diccionario de Clases: Ver Anexo 3 .............................................................. 131
3.5.2. Diagrama del Modelo Conceptual .................................................................. 131
CAPÍTULO IV: ARQUITECTURA ...................................................................................... 132
4.1. Descripción de la Arquitectura. .............................................................................. 132
4.2. Vista de Casos de Uso ............................................................................................ 134
4.3. Vista de Lógica ....................................................................................................... 135
4.3.1. Diagrama de Paquetes .................................................................................... 135
4.3.2. Realización de Caso de Uso Análisis – Gestionar Cliente ............................. 135
4.3.3. Realización de Caso de Uso Análisis – Cotizar Inmueble ............................. 142
4.4. Vista de Implementación o Componentes .............................................................. 144
4.4.1. Descripción General ....................................................................................... 144
4.4.2. Paquete “models” (casos de uso más significativos) ..................................... 145
4.4.3. Paquete “controllers” (casos de uso más significativos) ................................ 146
4.4.4. Paquete “views” (casos de uso más significativos) ........................................ 146
4.5. Vista de Concurrencia o procesos .......................................................................... 147
4.5.1. CU –Gestionar Cliente ................................................................................... 147
4.5.2. CU –Gestionar Inmueble ................................................................................ 152
4.5.3. CU – Cotizar Inmueble ................................................................................... 158
4.5.4. Modelo de Datos: Diagrama de modelo de datos: Ver Anexo 4 .................... 162
4.5.5. Modelo de Datos: Definición de las Tablas: Ver Anexo 5 ............................. 162
4.5.6. Modelo de despliegue ..................................................................................... 162
CAPÍTULO V: DESARROLLO Y PRUEBAS ..................................................................... 163
5.1. Desarrollo. .............................................................................................................. 163
5.1.1. Plataforma tecnológica. .................................................................................. 163
5.1.2 Descripción de los estándares de desarrollo. ...................................................... 164
5.2. Pruebas: Plan de Pruebas ........................................................................................ 165
5.2.1. Introducción .................................................................................................... 165
5.2.2. Alcance ........................................................................................................... 166
5.2.3. Referencias ..................................................................................................... 166
5.2.4. Requerimientos de Pruebas ............................................................................ 166
5.2.5. Tipos de Pruebas ............................................................................................. 167
5.2.6. Características a Probar .................................................................................. 167
5.2.7. Características que no se Prueban .................................................................. 168
5.2.8. Responsabilidades de Casos de Prueba .......................................................... 168
5.2.9. Secuencia de Pruebas...................................................................................... 168
5.2.10. Casos de Prueba .............................................................................................. 168
5.2.11. Pruebas de Integración.................................................................................... 175
5.2.12. Pruebas de Aceptación.................................................................................... 178
CAPÍTULO VI: GESTIÓN DEL PROYECTO ..................................................................... 180
6.1. Descripción de la Gestión del Proyecto. ................................................................. 180
6.2. Viabilidad del proyecto. ......................................................................................... 183
6.2.1. Viabilidad operacional. .................................................................................. 183
6.2.2. Viabilidad técnica. .......................................................................................... 185
6.2.3. Viabilidad económica. .................................................................................... 186
6.2.4. Viabilidad legal. ............................................................................................. 187
6.1. Organización del Proyecto...................................................................................... 187
6.1.1. Organigrama del proyecto. ............................................................................. 187
6.1.2. EDT del proyecto............................................................................................ 188
6.2. Estimación y ejecución del proyecto. ..................................................................... 189
6.2.1. Estimación del Proyecto por Casos de Uso .................................................... 189
6.2.2. Cronograma de ejecución del proyecto: Ver Anexo 8. .................................. 191
6.2.3. Estimación de presupuesto. ............................................................................ 191
6.2.4. Ejecución del presupuesto. ............................................................................. 192
6.3. Gestión de Comunicaciones del proyecto. ............................................................. 193
6.4. Gestión de Riesgos del proyecto. ........................................................................... 194
6.5. Plan de Gestión de Cambios ................................................................................... 199
6.8 Constancia de aceptación del cliente sobre el proyecto. .............................................. 199
CONCLUSIONES .................................................................................................................. 201
RECOMENDACIONES ........................................................................................................ 202
GLOSARIO DE TÉRMINOS ................................................................................................ 203
SIGLARIO ............................................................................................................................. 206
BIBLIOGRAFÍA .................................................................................................................... 208
ANEXOS ................................................................................................................................ 211
ANEXO 1 ............................................................................................................................... 211
ANEXO 2 ............................................................................................................................... 233
ANEXO 3 ............................................................................................................................... 272
ANEXO 4 ............................................................................................................................... 275
ANEXO 5 ............................................................................................................................... 276
ANEXO 6 ............................................................................................................................... 324
ANEXO 7 ............................................................................................................................... 331
ANEXO 8 ............................................................................................................................... 450
INTRODUCCIÓN
Teniendo en cuenta que el presente trabajo de tesis está relacionado a proponer un sistema que
ayude a la gestión comercial de las empresas que operan en el sector construcción, se dará una
perspectiva global del estado de la economía del país, focalizándonos principalmente en el
sector construcción y las variables que influyen en el crecimiento del mismo.
El INEI informa que en el tercer trimestre de 2012 la economía peruana medida a través del
producto bruto interno (PBI), a precios constantes de 1994, registró un incremento de 6,5%,
respecto al mismo período del año anterior, acumulando 12 trimestres consecutivos de
crecimiento económico1.
Gráfica N° 1: Producto Bruto Interno Trimestral 2004 – I – 2012 – III
(A precios constantes de 1994)
Fuente: Comportamiento de la Economía Peruana en el Tercer Trimestre de 2012. INEI (2012)
El producto bruto interno (PBI), principal componente de la oferta global de bienes y servicios,
a precios constantes de 1994, registró en el tercer trimestre de 2012 un incremento de 6,5% en
relación al mismo periodo del año anterior. Este resultado se explica por la participación
positiva de las actividades, en el crecimiento de esta variable, siendo la actividad construcción
la que tuvo el mayor incremento (19,3%)2.
1 INEI, 2012, Comportamiento de la Economía Peruana en el Tercer Trimestre de 2012. p.3

2
INEI, 2012, Comportamiento de la Economía Peruana en el Tercer Trimestre de 2012. p.13
Gráfica N° 2: Producto Bruto Interno por actividad económica, periodo 2012-III / 2011-III
(Variación porcentual del Índice de Volumen Físico)
Fuente: Comportamiento de la Economía Peruana en el Tercer Trimestre del 2012. INEI (2012)
Las condiciones favorables de acceso al financiamiento a través de los créditos hipotecarios

incentivan la inversión en construcción de viviendas. Así los créditos hipotecarios para
viviendas otorgados por las entidades del sistema bancario registraron un monto de 23 325
millones de nuevos soles, monto superior en 22,4% respecto a igual periodo del año anterior.
El número de deudores de créditos hipotecarios para vivienda mantuvo un comportamiento
creciente y ascendió a 182 016 al cierre del tercer trimestre, el cual representó un crecimiento
de 12,2% respecto a similar periodo del año anterior3.
Gráfica N° 3: Número Créditos Hipotecarios 2011 – 2012 (Miles de nuevos soles)
3
INEI, 2012, Comportamiento de la Economía Peruana en el Tercer Trimestre de 2012. p.26
Página | 5
Gráfica N° 4: Número de deudores de Crédito Hipotecario 2011 – 2012.
Según el Ministerio de Vivienda, Construcción y Saneamiento de Perú, el déficit habitacional

a nivel nacional alcanzó en el 2012 las 1’860,692 unidades (viviendas). De este total, el 79.1%
es déficit cualitativo (1’470,947 viviendas), correspondiente a familias que no están contentas
con su actual vivienda y quieren acceder a otro tipo de viviendas con mejores características.
Las 389.745 viviendas restantes corresponden al déficit cuantitativo, a la falta de viviendas

como tal, independientemente de sus propiedades o características4.
Gráfica N° 5: Déficit Habitacional Cuantitativo y Cualitativo 2012
Ámbito Total Cuantitativo Cualitativo
Nacional 1’860,692 (100.0%) 389,745 1’470,947

100.% 20.9% 79.1%
Fuente: Déficit Habitacional. Ministerio de Vivienda (2012)
Como resultado, las empresas inmobiliarias y constructoras han mostrado un

creciente interés por participar en el Programa MiVivienda y Techo Propio, dada la
alta rentabilidad del esquema actual y la baja morosidad en estos préstamos. En este sentido, si
bien inicialmente dichas empresas se enfocaron primero en el estrato AB, actualmente la
incursión en proyectos habitacionales destinados a hogares de menores ingresos que presenta
una oportunidad interesante. En estos casos, las preferencias de las empresas constructoras se
4
MI VIVIENDA, 2012, La Revista Inmobiliaria del Perú. p.10
Página | 6
orientan al desarrollo de grandes megaproyectos habitacionales, porque existe una gran
demanda aún insatisfecha5.
La estabilidad de la economía, la disponibilidad de crédito hipotecario a tasas de interés fijas y

de largo plazo, el apoyo de los institutos públicos de vivienda, la mejor situación financiera de
las empresas desarrolladoras y constructoras, y el impulso de la inversión pública y privada,
explican este comportamiento del boom inmobiliario, podemos llegar a la conclusión de que la
situación del mercado actual inmobiliario tiene una gran demanda insatisfecha, factor que
brinda una gigantesca oportunidad a las empresas del sector construcción, pero a la vez
significa para aquellas empresas que se lanzan a satisfacer la esta demanda, un gran reto para
administrar correctamente toda su información, que les permita aprovechar oportunamente la
demanda insatisfecha apoyados en soluciones tecnológicas.
Convención: La organización donde se realizó la investigación aplicada es una empresa

constructora e inmobiliaria privada a la cual denominaremos durante todo el informe de tesis
“Empresa Constructora Inmobiliaria”.
5 MI VIVIENDA, 2010, Desembolsos del nuevo crédito MIVIVIENDA crecieron 135% en el 2010. p. 1
Página | 7
CAPÍTULO I: VISIÓN DEL PROYECTO
1.1. El Problema.
1.1.1. El Negocio.
El resultado de esta investigación se aplicará a una empresa real, la Empresa Constructora
Inmobiliaria centrada en el desarrollo, construcción, gerencia y promoción de proyectos
inmobiliarios de viviendas sociales modernas en las provincias del Perú. Es una empresa 100%
peruana que nace en 1999 e incursiona durante sus primeros años en el desarrollo de proyectos
inmobiliarios en Lima. Desde 2008 se enfoca en el desarrollo de proyectos de vivienda social
en las provincias del Perú.
Uno de sus actuales mega-proyectos involucra una inversión de 34 millones de dólares para la
construcción de 720 departamentos en la ciudad de Arequipa, el proyecto contempla la
edificación de 13 bloques de edificios de entre ocho y quince pisos; orientados a satisfacer la
demanda inmobiliaria de los segmentos B y C de la población de Arequipa.
Visión:
Convertirnos en el líder especializado en construcción masiva de vivienda social de alta calidad

en el Perú.
Misión:
Cumplirle el sueño de la casa propia a miles de familias peruanas construyendo viviendas y

urbanizaciones de alta calidad a precios accesibles, con entrega rápida y con responsabilidad
medioambiental.
1.1.2. Procesos del Negocio.
Los procesos de la Empresa Constructora Inmobiliaria, se han estructurado en 3 tipos de

procesos:
Procesos Estratégicos: Son procesos destinados a definir y controlar las metas de la

organización, sus políticas y estrategias. Permiten llevar adelante la organización. Están en
Página | 8
relación muy directa con la misión/visión de la organización. Involucran personal de primer
nivel de la organización. Afectan a la organización en su totalidad.
Procesos Operativos: Son procesos que permiten generar el producto/servicio que se entrega
al cliente, por lo que inciden directamente en la satisfacción del cliente final. Generalmente
atraviesan muchas funciones. Son procesos que valoran los clientes y los accionistas.
Procesos de Apoyo: Apoyan los procesos operativos. Sus clientes son internos. Los procesos
de soporte también reciben el nombre de procesos de soporte.
Dentro de esta estructuración se han identificado los siguientes procesos:

Procesos Estratégicos:
1. Planificación Estratégica: Son los procesos relacionados con la planeación del negocio.
Aquellas que regulan y controlan las demás funciones básicas de la empresa.
2. Investigación y Desarrollo: Comprende los procesos de investigación y desarrollo de:
Tecnología, Procesos (operaciones), y Modelos de negocio.
3. Gestión de Control de Calidad: Este proceso comprende los procesos que garantizan la
satisfacción del cliente, como la entrega del Acta de Entrega y en caso se definan
observaciones registrarlas y atenderlas.
Procesos Operativos:
1. Estudio de Propuestas y Desarrollo de Proyectos: Son los procesos relacionados a la
concepción, estudio de factibilidad e inicio de los proyectos.
2. Gestión de Operaciones: Proceso de la administración y gestión de los proyectos y obras,
comprende los procesos que hacen posible la construcción de los proyectos.
3. Gestión de Marketing: Involucran los procesos que nos permiten satisfacer ls necesidades
de los clientes y obtener ganancias al mismo tiempo, involucra estrategias de mercado, de
ventas, estudio de mercado, posicionamiento de mercado, etc.
4. Gestión Comercial: Este proceso involucra desde la atención del cliente en una cotización,
la separación y seguimiento a la oportunidad; este proceso también involucra la atención
de los casos de desistimiento
5. Servicios Post – venta: Son los servicios de post-venta que agrupan las actividades
destinadas a mantener y / o realzar el valor del producto o servicio.
Procesos de Apoyo:
1. Gestión de Recursos Humanos: Involucra las tareas necesarias para conseguir y conservar
un grupo humano de trabajo, cuyas características vayan de acuerdo con los objetivos de
la empresa.
2. Gestión Tecnológica: Son los procesos relacionados con la gestión de la tecnología
utilizada por la empresa (Ejemplos. Tecnologías de la información y la
comunicación, Sistema informático).
3. Gestión de Compras: Este proceso involucra las actividades realizadas para adquirir
recursos para la realización correcta de cada una de las operaciones.
Página | 9
4. Infraestructura: Son los procesos relacionados con la gestión y desarrollo de la
infraestructura de la empresa: transportación, bienes raíces, plantas (cf. Fábrica), y equipos.
5. Gestión de Trámite Documentario: Son los procesos relacionados a la creación, registro
y seguimiento de las minutas, y las escrituras públicas.
6. Gestión Contable: Las funciones contables controlan la parte que tiene que ver con los
inventarios, costos, registros, balances, estados financieros y las estadísticas empresariales.
7. Gestión Legal: Este proceso tiene como propósito principal proveer
soporte legal (o jurídico) a la empresa como entidad y a sus operaciones.
8. Gestión Financiera: Este proceso comprende la obtención de fondos y del suministro del
capital necesario que se utiliza en el funcionamiento de la empresa (se incluye las Finanzas
corporativas).
A continuación mostramos el diagrama del proceso principal del negocio: “Proceso Comercial”,
es este proceso el más importante porque de la rentabilidad de los proyectos construidos
depende de cuántos inmuebles se vendan.
Gráfica N° 1.1.: Procesos de la Empresa Constructora Inmobiliaria
Fuente: Elaboración Propia (2011)
Este proceso está constituido por 7 sub – procesos, ellos son:
1. Generar Cotización
2. Gestionar Proyecto
Página | 10
3. Gestionar Cliente
4. Crear Expediente
5. Registrar Pago
6. Generar Contrato de Separación
7. Examinar Oportunidad
Página | 11
Gráfica N° 1.2.: Proceso de Venta
Fuente: Elaboración Propia (2011)
Página | 12
1.1.3. Descripción del Problema.
Como resultado del sostenido crecimiento del sector constructor y la necesidad insatisfecha de
vivienda en el país, la Empresa Constructora Inmobiliaria pretende desarrollar, construir y
vender la mayor cantidad de proyectos (de proyección social, apoyados por el estado en
programas de vivienda social que se desarrollan desde el Fondo MiVivienda y el Ministerio de
Vivienda, Construcción y Saneamiento y proyectos residenciales, proyectos propios de la
empresa), lo que conllevan a la necesidad de implementar una estrategia de negocios que
fortalezca el área comercial y que permita gestionar toda la información relevante a ésta, a fin
de llevar un control correcto y organizado para el cierre completo de cada venta, la promoción,
y los servicios post venta, y tener además una herramienta más adecuada para gestionar el
modelo de negocio donde intervienen programas de tipo “Techo Propio” o “Mi Vivienda”, que
matizan el negocio inmobiliario nacional.
1.2. Fundamentación del Problema.
1.2.1. Marco Teórico.

En el presente capítulo analizaremos las tecnologías actuales relacionadas con la mejora de la
gestión comercial y las relaciones de la empresa con sus clientes. En tal sentido, la concepción
actual de “CRM” (Customer Relationship Management) es una filosofía corporativa, en la que
se busca entender y anticipar las necesidades de los clientes existentes y también de los
potenciales; actualmente se integran las disciplinas de gestión empresarial (como marketing
relacional) y las soluciones tecnológicas que facilitan su aplicación, desarrollo y
aprovechamiento (Internet, intranet, extranet, comercio electrónico, ERP (Enterprise Resource
Planning), Data Warehouse, Data Mining, etc.). En pocas palabras se trata de una estrategia de
negocios, un modelo de gestión de toda la organización, basada en la orientación al cliente y
sus necesidades.
1.2.1.1. Marketing Relacional.

Desde finales de los años ochenta, se produjeron importantes cambios en el entorno competitivo
que evidenciaron la necesidad de un enfoque más profundo del marketing, que fuera desde el
mercado genérico hacia la relación con el cliente individual. En las distintas vertientes del
consumidor, la estrategia competitiva de la empresa, los medios de comunicación, los sistemas
de distribución, las tecnologías aplicables o las estructuras relativas de costos, ha habido una
Página | 13
evolución - o incluso revolución - que ha llevado a la necesidad de un nuevo paradigma de
marketing. Este nuevo paradigma de marketing se ha concretado principalmente en la atención
y cultivo de la relación entre el cliente y la empresa.
La creación de valor para el cliente parte necesariamente del reconocimiento de la importancia

de las relaciones, las cuales afectan tanto al contenido como al resultado de las transacciones.
Se desarrollará la estrategia de la empresa en torno al cliente tratando de hacer los procesos de
marketing más disciplinados, enfocados a objetivos comunes de toda la empresa, y donde el
marketing tiene un papel clave como motor de la orientación al cliente. La Asociación Española
de Marketing Relacional (AEMR, 2002) ha establecido una definición clara en este sentido:
"CRM es el conjunto de estrategias de negocio, marketing, comunicación e infraestructuras
tecnológicas, diseñadas con el objetivo de construir una relación duradera con los clientes,
identificando, comprendiendo y satisfaciendo sus necesidades. El CRM va más allá del
marketing de relación, es un concepto más amplio, es una actitud ante los clientes y ante la
propia organización, que se apoya en los procesos multicanales (teléfono, correo, internet,
fuerzas de ventas) para crear y añadir valor a la empresa y a sus clientes"6.
Según Diana Muñoz y Guillermo Gil, el Marketing Relacional, como su nombre lo indica,
busca crear, fortalecer y mantener las relaciones de las empresas comercializadoras de bienes y
servicios con sus clientes, buscando lograr el máximo número de negocios con cada uno de
ellos. Su objetivo es identificar a los clientes más rentables para establecer una estrecha relación
con ellos, que permita conocer sus necesidades y mantener una evolución del producto de
acuerdo con ellas a lo largo del tiempo.
El marketing relacional es la intersección entre el marketing y las relaciones públicas, la

característica principal es la individualización, cada cliente es único y se pretende que el cliente
así lo perciba: comunicación directa y personalizada, costos más bajos que el mercadeo y la
promoción tradicional.
Uno de los mayores componentes de mercadeo relacional es el llamado Marketing Directo, que
combina herramientas como publicidad, relaciones públicas, promoción, correo directo y tele
mercadeo7.
6 Alet, 2000, Como obtener clientes reales y rentables. p. 51

7 Muñoz & Gil, 2006, Solución CRM en la Empresa Pública y Privada. p.74
Página | 14
Kotler y Armstrong, definen que: “El marketing directo consiste en las conexiones directas con
consumidores individuales seleccionados cuidadosamente, a fin de obtener una respuesta
inmediata y de cultivar relaciones duraderas con los clientes. Quienes hacen marketing directo
se comunican directamente con los clientes, a menudo de forma individual (uno a uno) e
interactiva. Más allá de la construcción de marcas, imágenes, estos mercadólogos por lo regular
buscan una respuesta de los consumidores directa, inmediata y mensurable”8.
Toda relación está basada en el conocimiento mutuo, y por ello el marketing relacional intenta
conocer al máximo al consumidor, con el fin de poder “hablar” su mismo lenguaje,
personalizando al máximo la relación, de tal forma que el consumidor se sienta tratado de forma
exclusiva. El marketing relacional es reconocer que cada consumidor tiene “valor potencial”, y
diseñar una estrategia destinada a “realizar” dicho potencial. El objetivo del marketing
relacional es convertir el actual monólogo existente entre las marcas y los consumidores en un
diálogo, en el que ambas partes se beneficien del intercambio de información convirtiendo lo
que antes era una transacción en una relación. De esta manera, la empresa y sus consumidores
colaborarán en la búsqueda de un beneficio mutuo9.
1.2.1.2. Sistemas y Tecnologías de Información.

Cuando se habla de tecnología de información, estamos adentrándonos en un territorio de
fronteras cada vez más amplias y difusas, y de cambios cada vez más frecuentes. Hay que
entender que desde la invención del teléfono, hasta la era del fax, pasaron casi 80 años, mientras
que del fax a internet pasaron sólo 15 años y que desde entonces hasta ahora, las tecnologías
basadas en comunicaciones alámbricas, inalámbricas e internet, se desarrollaron a una
velocidad tal que se llegó a acuñar el concepto del año Web.
El ambiente tecnológico deberá considerar la adopción de modelos de negocios centrados en la

Web, que utilizan herramientas y estándares de Internet, y garantizan la omnipresencia de los
servicios y la información (cualquier momento – cualquier lugar), organizándose en forma
federalizada y con una arquitectura de tres niveles claramente separados: la interface, la lógica
de negocio y la gerencia transaccional de las bases de datos10.
8Kotler & Armstrong, 2003, Fundamentos de marketing.

9Reinares & Ponzoa, 2002, Marketing relacional: un nuevo enfoque para la seducción y fidelización del cliente.
10 Muñoz & Gil, 2006, Solución CRM en la Empresa Pública y Privada. p.40.
Página | 15
Gómez y Suarez en su libro “Sistemas de Información Herramientas prácticas para la gestión
empresarial”, indican que hoy en día, los sistemas de información juegan un papel cada vez
más importante en las modernas organizaciones empresariales, hasta el punto de condicionar
su éxito o fracaso en un entorno económico y social tan dinámico y turbulento como el que
caracteriza el mundo actual.
Los sistemas de información han adquirido una dimensión estratégica en las empresas de nuevo
milenio y han dejado de ser considerados una simple herramienta para automatizar procesos
operativos para convertirse en una pieza clave a tener en cuenta a la hora de formular la
estrategia empresarial, para llevar a cabo su implantación y para realizar el control de la gestión.
Los sistemas de información no sólo llegan a condicionar la estrategia de la moderna empresa,
sino que, además, constituyen el elemento fundamental para poder llevar a cabo una gestión
horizontal de la empresa, orientada a procesos y no a funciones, que permita poner énfasis en
la mejora continua de los resultados, con una clara orientación total hacia el cliente. Este es un
aspecto que hoy en día se considera clave, no ya para alcanzar el éxito, sino para garantizar la
supervivencia de la organización en un entorno tan competitivo y exigente como el actual.
La planificación y el diseño de los sistemas de información en las empresas y organizaciones

requieren una perspectivas multidisciplinar que tenga en cuenta los tres aspectos referidos, tal
y como se pone de manifiesto en la figura.
Gráfica N° 1.3.: Las 3 Dimensiones de un Sistema de Información
Fuente: Fundamentos de marketing. Kotler & Armstrong (2003)
A. Clasificación de los sistemas de información: por lo general, las clasificaciones más

extendidas de los sistemas de información suelen agrupar éstos en función de su
Página | 16
finalidad. De una forma muy global, puede considerarse que existen dos funciones
básicas para los sistemas11:
 Soporte a las actividades operativas, que da lugar a sistemas de información para
actividades más estructuradas (aplicaciones de contabilidad, planillas, pedidos y, en
general, lo que se denomina “gestión empresarial”) o también sistemas que permiten el
manejo de información menos estructurada: aplicaciones ofimáticas, programas técnicos
para funciones de ingeniería, etc.
 Soporte a las decisiones y el control de gestión, que puede proporcionarse desde las
propias aplicaciones de gestión empresarial (mediante salidas de información existentes) o
a través de aplicaciones específicas, como se presentará en este apartado.
Conviene indicar que en la actualidad resulta complejo establecer fronteras rígidas en

los sistemas que ofrece el mercado. Por ejemplo, un ERP (Sistema Integrado para la Gestión
Empresarial) soporta las actividades operativas en las distintas funciones o áreas y, al mismo
tiempo, es un sistema clave para la toma de decisiones, al menos en los puestos operativos y de
dirección media12.
Asimismo, también resulta habitual el clasificar los sistemas en función del tipo de función a la
que se dirige: financiera, recursos humanos, marketing, etc. La figura siguiente presenta las
ideas anteriores:
|
Gráfica N° 1.4.: Clasificación de los Sistemas de Información
Fuente: Sistemas de Información Herramientas prácticas para la gestión empresarial. Gómez &
Suarez (2007)
11
Gómez & Suárez, 2007, Sistemas de Información Herramientas prácticas para la gestión empresarial. p. 10
12 Gómez & Suárez, 2007, Sistemas de Información Herramientas prácticas para la gestión empresarial. p. 11
Página | 17
1.2.1.3. Customer Relationship Management (CRM).
El CRM se describe mejor como una colección de 3 capas: de filosofía operativa, de procesos
y de tecnología, las que ayudan a las organizaciones a mejorar sus ventas, servicio y operaciones
de marketing. Estas capas incluyen:
1. La filosofía de organizar la empresa centrada más en el cliente, para atraer a los clientes y
adaptar los servicios a los clientes de manera individual o a clientes segmentados.
2. Mejores prácticas para la gestión e integración de los procesos de venta, servicio y
marketing.
3. Tecnologías de información usadas para automatizar e integrar los diversos procesos y
actividades de ventas, servicios y marketing, para capturar y centralizar la información
relacionada con los clientes13.
A. Marketing en la nueva economía.
En la economía del nuevo milenio las empresas se enfrentan a un entorno mucho más
competitivo. Los clientes están mucho más informados y son considerablemente más exigentes.
Solicitan todo tipo de información sobre la empresa y sus productos y la quieren obtener
inmediatamente. Demandan soluciones personalizadas y desean participar en la concepción de
los productos que van a consumir. Los medios digitales interactivos permiten desarrollar una
comunicación directa entre las empresas y sus clientes, que pueden tener lugar desde cualquier
lugar del mundo y en cualquier momento (servicio permanente y global). Nos encontramos,
además, en una etapa económica en la que la oferta de productos y servicios supera claramente
a la demanda existente, provocando una tremenda lucha de las empresas por mantener sus
cuotas de mercado y fidelizar a sus clientes. Hoy, más que nunca, el cliente es lo más importante
y, por lo tanto, resulta imprescindible conocer qué es lo que espera de la empresa, qué productos
y servicios se requieren para satisfacer sus necesidades. La orientación total hacia el cliente y
hacia el mercado se convierten en la clave, no ya para garantizar el éxito, sino incluso la propia
supervivencia de muchas empresas. Por lo tanto, en estas condiciones, las empresas necesitan
conocer mucho mejor a sus clientes, para poder establecer una relación duradera y beneficiosa
para ambas partes.
Las últimas tendencias en marketing plantean una transición desde una situación dominada por
la adquisición de nuevos clientes (caracterizada por una inversión masiva en publicidad), hacia
otra etapa en la que los esfuerzos se centran en la retención y fidelización de los clientes
actuales. La calidad de los productos y la optimización de los procesos organizativos ya no
13 Bligh & Turk, 2004, CRM unplugged: releasing CRM's strategic value. p.6
Página | 18
representan una ventaja competitiva, simplemente son una condición necesaria para poder estar
en el mercado.
Las medidas encaminadas a facilitar la fidelización y retención de los clientes tienen un impacto
cada vez más importante en los resultados de una empresa14.
B. Aplicaciones de CRM.
Las aplicaciones CRM son herramientas que facilitan una gestión integral de las relaciones con
los clientes. Para ello, realizan un seguimiento personalizado de cada cliente, analizando su
comportamiento y rentabilidad para la empresa.
Estas aplicaciones permiten registran datos, recabados en todos los posibles contactos de cada
cliente con la organización:
 Contactos preventa.
 Gestiones asociadas a una venta.
 Servicios posventa.
De esta forma, se dispone de información unificada y completa de cada uno de los clientes: los
productos y servicios que ha contratado, las campañas y promociones a las que ha respondido,
las agendas del servicios postventa, etc., con un tratamiento homogéneo multicanal (contactos
en persona, por el teléfono, por fax, por correo a través de la Web, por e-mail.)
Las empresas son cada vez más conscientes de la necesidad de invertir en este tipo de
herramientas, una vez completados en desarrollo de sus sistemas de gestión empresarial (ERP).
Los últimos estudios publicados afirman que el mercado de las aplicaciones CRM va a ser uno
de los de mayor crecimiento dentro de la industria informática.
Así, por ejemplo, en un estudio de IDC presentado en Junio del 2000 realizado entre 1000
empresas Europeas de cinco países (España, Italia, Francia, Reino Unido y Alemania), se
afirmaba que las aplicaciones CRM eran percibidas como un arma estratégica para la
diferenciación en todos los sectores industriales. Más de un 19% de las compañías tenían en ese
14 Gómez & Suarez, 2007, Sistemas de Información Herramientas prácticas para la gestión empresarial. p. 75
Página | 19
momento programas en fase operativa o de producción, y un 32% de ellas se encontraban en
fase de planificación o implementación15.
C. Soluciones CRM.
Una visión distante supone reducir el CRM a un conjunto de herramientas orientadas a la mejora
tecnológica de la empresa y especialmente al control, seguimiento y análisis de los eventos que
tienen que ver con la relación con el cliente.
Desde un punto de vista práctico la mejor forma de diferenciar CRM estratégico y CRM
analítico, operacional y de colaboración (los dos últimos también conocidos como CRM activo)
es acudir a las empresas que ofrecen una u otra nomenclatura. Desde “trajes a medida” (o
soluciones diseñadas para las necesidades concretas de una empresa, de una unidad de negocio
de la misma o de un departamento) a soluciones estándares (basadas en la experiencia del propio
proveedor de soluciones tras su investigación e investigación en diferentes sectores), y
partiendo de la premisa de que las diferentes partes en que se acota un CRM han de formar un
sistema integrado, las llamadas soluciones CRM, pueden dividirse en tres partes.
4. CRM Analítico: hace referencia al almacenamiento (en el Data Warehouse) proceso,

modelización y explotación (o generación de informes) de la información disponible. Son
herramientas orientadas al conocimiento. En este sentido, ofrece información valiosa sobre
las relaciones que a nivel interno (entre los diferentes departamentos de la empresa,
unidades de negocio, áreas o personas) y externo (para los clientes, proveedores,
suministradores o cualquier otro público) han acontecido. Ofrece un apoyo importante en
la toma de decisiones, incorporan diferentes niveles de acceso en función de la jerarquía,
ocupación, responsabilidades u objetivos de cada uno de los usuarios.
5. CRM Operacional u Operativo: Hace referencia principalmente a los procesos de negocio
en la compañía. En este tipo de CRM se diferencian 2 partes:
 El back office: es decir, todos los procesos organizativos que configuran el entramado del
negocio y dan forma al mismo, pero con los que el cliente no entra de forma directa en
contacto. El cliente afecta a gran parte de dichos procesos, desde su toma de decisiones y
su interacción con la compañía, en la medida en que esta modifica sus procesos y
procedimientos para ofrecerle un servicio adecuado a sus expectativas y necesidades, pero
no define ni articula dichos procesos, que pertenecen al propio conocimiento del negocio
de la empresa.
 El front office: hace referencia a todas las áreas de la empresa que entran en relación directa
con el cliente. Desde el call center o centro de atención telefónica, hasta el establecimiento
15 Gómez & Suarez, 2007, Sistemas de Información Herramientas prácticas para la gestión empresarial. p. 85
Página | 20
en el que se venden los productos o servicios que la empresa ofrece, desde un vendedor a
comisión que gestiona una pequeña área del territorio hasta las campañas de marketing
directo llevadas a cabo por el departamento de marketing, todo aquello o todos aquellos que
están frente al cliente se incorporan dentro de este apartado.
6. EL CRM de colaboración, interacción directa (o “colaborativo”): es sin duda, una de

las más innovadoras herramientas informáticas desarrolladas al servicio de la empresa.
Cuando alguien asiste por primera vez a una demostración de un CRM analítico operativo,
puede quedarse fascinado, pero poco más tarde empieza a pensar que todo cuanto ha visto
le resulta familiar.
Algo muy diferente ocurre con el CRM de colaboración, probablemente porque aún no ha sido
incorporado en nuestra forma de vida con el rasgo más común y porque es capaz de sintetizar
o agrupar muchos de los últimos descubrimientos en el área de la tecnología informática y las
comunicaciones.
El CRM analítico y operativo desempeñará entonces un papel destacado. El CRM de

interacción directa o de colaboración se diferencia del CRM operativo en su división de front
office en que el primero se canaliza principalmente a través de medios electrónicos y da apoyo
a la preventa y a la venta, mientras que el segundo está principalmente orientado a la post venta.
Cuando se habla de e-CRM se suele hacer referencia, principalmente, a un CRM de
colaboración basada en soporte web en el que han sido incluidos módulos de análisis y
operacionales.
De acuerdo al proceso de apoyo son denominadas:
a. CRM Marketing: el CRM Marketing es una herramienta para el control y diseño de las
actividades del departamento de marketing que permite una mejora cualitativa y cuantitativa
de sus funciones, gracias a la mecanización de sus procesos y procedimientos. Basa su éxito
en la articulación de flujos de información en tiempo real, que, junto con el análisis de series
históricas y el seguimiento preciso de los objetivos fijados, permite a la empresa una mayor
y más adecuada intervención en el mercado en el que opera. El CRM marketing parte de
una estrategia de orientación de la empresa al largo plazo, basada en el conocimiento de la
clientela y en el incremento de su afinidad o fidelidad a la empresa. Gracias a la tecnología,
es capaz de convertir dicha estrategia en acciones tácticas plausibles.
b. CRM Ventas: supone un conjunto de aplicaciones orientadas a incrementar las ventas de
la empresa y mejorar la calidad de las mismas desde el punto de la proyección a futuro de
la empresa, que incluye factores tales como el beneficio, el control sobre la fuerza de ventas,
las ventas cruzadas a clientes (cross-sale), la recomendación de nuestros productos y
servicios por parte de nuestros propios clientes (member gets a member), o el aumento de
las compras, la frecuencia de las mismas o la mejora en el tipo de producto comprado (up-
sale)
Página | 21
c. CRM Servicios: formado por un conjunto de aplicaciones orientadas principalmente al
servicio post venta (antes identificado como CRM operacional y de colaboración), ya sea
mediante el aporte de identificación sobre el funcionamiento o características del producto
o servicio, seguimiento de la satisfacción y conocimiento del producto, reparación y
mantenimiento u otros.
d. CRM Business Intelligence o CRM Investigación de mercados: orientado
principalmente a la generación de informes para la toma de decisiones. El CRM para
investigación de mercados aporta información a las diferentes áreas de la empresa. Al hacer
referencia al CRM analítico se ha descrito con mayor detalle algunas de las respuestas que
aportan este tipo de aplicaciones o familias de ellas.
Cabe señalar que, si bien algunos fabricantes o empresas ofrecen soluciones únicas en esta área,
la verdadera eficacia de este tipo de aplicaciones reside en su integración con otras herramientas
de CRM, especialmente con las diseñadas específicamente para el área de ventas y marketing.
Al pensar en un CRM, tal y como promulga el llamado CRM estratégico, tenemos que intentar
contemplar un sistema integrado que contemple la mayoría de los procesos de organización.
Ahora bien, ante la disyuntiva de implementar un CRM corporativo (capaz de interconectar y
aportar soluciones en todas las áreas y direcciones), o hacerlo en algunas de las áreas,
especialmente en la de investigación de mercados o para los centros de interacción (donde están
demostrando una alta efectividad) será preciso valorar el nivel de preparación para el cambio
de la organización (ya comentado) y los recursos disponibles para el mismo. Siempre es mejor
acometer procesos parciales, valorar resultados y exportar experiencias a otras áreas que no
afronten el reto del cambio en su totalidad16.
1.2.1.4. Ingeniería de Software.

Definición: Según Pressman, para entender el software (y al ingeniería de software), es
importante examinar las características que lo hacen diferentes de otras cosas que construye el
ser humano. El software es un elemento lógico, en lugar de físico de un sistema. Por lo tanto,
el software tiene características muy diferentes a la de hardware:
El software se desarrolla o construye; no se manufactura en el sentido clásico: Ambas

actividades requieren la construcción de “un producto”, pero los enfoques son diferentes. Los
costos de software se concentran en la ingeniería. Esto significa que los proyectos de software
no se pueden manejar como si fueran proyectos de manufactura.
16 Reinares & Ponzoa, 2002, Marketing relacional: un nuevo enfoque para la seducción y fidelización del cliente. p. 259
Página | 22
El software “no se desgasta”; un aspecto que ilustra la diferencia entre el hardware y el
software es cuando un componente del hardware se desgasta se sustituye con un repuesto. Pero
en el software no existen repuestos. Cualquier falla del software implica un error en el diseño
o el proceso mediante el cual se pasó del diseño al código maquina ejecutable. Por lo tanto, el
mantenimiento del software implica de manera considerable una complejidad mayor que el de
hardware.
A pesar de que la industria tiene una tendencia hacia la construcción por componentes, la
mayoría del software aún se construyen a medida; los componentes reutilizables se han
creado para que el ingeniero se pueda concentrar en los elementos que en realidad son
innovadores en el diseño; es decir, en las partes que representan algo nuevo. En el mundo del
hardware, la reutilización de componentes es una parte natural del proceso de ingeniería. En el
ámbito del software, dicha actividad apenas se ha comenzado a extender.
Métodos de la ingeniería del software.
Un Método de ingeniería del software es un enfoque estructurado para el desarrollo de software

cuyo propósito es facilitar la producción de software de alta calidad de una forma costeable.
Métodos como Análisis Estructurado (De Marco, 1978) y JSD (Jackson, 1983) fueron los
primeros desarrollados en los años 70. Estos métodos intentaron identificar los componentes
funcionales básicos de un sistema, de tal forma que los métodos orientados a funciones fueron
complementados por métodos orientados a objetos, como los propuestos por Booch (1994) y
Rumbaugh (1991). Estos diferentes enfoques se han integrado en un solo enfoque unificado
basado en el Lenguaje de Modelado Unificado (UML)17.
No existe un método ideal, y métodos diferentes tienen distintas áreas donde son aplicables.
Por ejemplo, los métodos orientados a objetos a menudo son apropiados para sistemas
interactivos, pero no para sistemas con requerimientos rigurosos de tiempo real.
Todos los métodos se basan en la idea de modelos gráficos de desarrollo de un sistema y en el

uso de estos modelos como un sistema de especificación o diseño. Los métodos incluyen varios
componentes diferentes18.
Procesos del software.
17 Booch & Rumbaugh, 1999, The Unified Modeling Language User Guide
18 Sommerville, 2005, Ingeniería del software. p. 10
Página | 23
Según Sommerville los procesos del software son las actividades relacionadas con la
producción de un sistema software.
c.1. Modelos del proceso del software.
Los modelos del proceso de software son representaciones abstractas de estos procesos. Un
modelo de proceso del software es una descripción simplificada del proceso del software que
presenta una visión de este proceso. Estos modelos pueden incluir actividades que son parte de
los procesos y productos del software y el papel de las personas involucradas en la ingeniería
del software. Algunos ejemplos de estos tipos de modelos que se pueden producir son:
a) Un modelo de flujo de trabajo. Muestra la secuencia de actividades en el proceso junto

con sus entradas, salidas y dependencias. Las actividades en este modelo representan
acciones humanas.
b) Un modelo de flujo de datos o de actividad. Representa el proceso como un conjunto
de actividades, cada una de las cuales realiza alguna transformación en los datos.
Muestra cómo la entrada en el proceso, tal como una especificación, se transforma en
una salida, tal como un diseño. Pueden representar transformaciones llevadas a cabo por
las personas o por las computadoras.
c) Un modelo de rollación. Representa los roles de las personas involucradas en el proceso
del software y las actividades de las que son responsables. Todos los procesos de
software incluyen la especificación, el diseño, la implementación, la validación y la
evolución del software. Los modelos genéricos del proceso describen la organización
de los procesos del software. Ejemplo de estos modelos son: Modelo en cascada,
desarrollo evolutivo, ingeniería de software basada en componentes19.
c.2. Iteración de procesos.
Beck afirma que los cambios son inevitables en todos los procesos de software grandes. Los
requerimientos del sistema cambian cuando el negocio que procura el sistema responde a las
presiones externas. Las prioridades de gestión cambian. Cuando se dispone de nuevas
tecnologías cambian los diseños y la implementación. Esto significa que el proceso del software
no es un proceso único; más bien, las actividades del proceso se repiten regularmente conforme
el sistema se rehace conforme a peticiones de cambio. El desarrollo iterativo es tan fundamental
para el software, existen dos modelos de procesos que han sido diseñados explícitamente para
apoyar la iteración de procesos: entrega incremental, desarrollo en espiral20.
El Proceso Unificado de Rational - RUP.

20 Boehm, B. W. (1988). A spiral model of software development and enhancement. IEEE Computer (cap. 4 y 5)
Página | 24
Sommerville en su libro Ingeniería de Software menciona que el Proceso Unificado de Rational
(RUP: Rational Unified Process), es un modelo en fases que identifica cuatro fases diferentes
en el proceso del software. Sin embargo, a diferencia del modelo en cascada donde las fases se
equiparan con las actividades del proceso, las fases en el RUP están mucho más relacionadas
con asuntos de negocio más que técnicos. Las fases son:
a. Inicio. El objetivo de la fase de inicio es de establecer un caso de negocio para el

sistema. Se deben identificar todas las actividades externas (personas y sistemas) que
interactúan con el sistema y definir estas interacciones. Esta información se utiliza
entonces para evaluar la aportación que el sistema hace al negocio. Si esta aportación es
de poca importancia, se puede cancelar el proyecto después de esta fase.
b. Elaboración. Los objetivos de la fase de elaboración son desarrollar una comprensión
del dominio del problema, establecer un marco de trabajo arquitectónico para el sistema,
desarrollar el plan del proyecto e identificar los riesgos claves del proyecto. Al terminar
esta fase, se debe tener un modelo de los requerimientos del sistema (se especifican los
casos de uso UML), una descripción arquitectónica y un plan de desarrollo del software.
c. Construcción. La fase de construcción fundamentalmente comprende el diseño del
sistema, la programación y las pruebas. Durante esta fase se desarrolla e integran las
partes del sistema. Al terminar esta fase, debe tener un sistema software operativo y la
documentación correspondiente lista para entregarla a los usuarios.
d. Transición. La fase final de RUP se ocupa de mover al sistema desde la comunidad de
desarrollo a la comunidad de usuario y hacerlo trabajar en un entorno real. Esto se deja
de lado en la mayor parte de los modelos de procesos del software pero es, en realidad,
una actividad de alto costo y a veces problemática. Al terminar esta fase, se debe tener
un sistema software documentado que funciona correctamente en su entorno operativo.
Cada fase se puede representar de un modo iterativo con los resultados desarrollados
incrementalmente. Además el conjunto entero de fases puede también representarse de forma
incremental como se muestra en la citada figura por la flecha en forma de bucle desde la
transición hasta el inicio. La iteración dentro del RUP es apoyada de dos formas como se
muestra en la siguiente figura:
Gráfica 1.5: Iteración dentro del RUP
Página | 25
Fuente: Ingeniería del software .Sommerville (2005).
La vista estática de RUP se centra en las actividades que tienen lugar durante el proceso de
desarrollo. Esta se denomina flujo de trabajo en la descripción del RUP. Existen seis principales
flujos de trabajo del proceso identificados en el proceso y tres principales flujos de trabajo de
soporte. El RUP se ha diseñado conjuntamente con el UML – un lenguaje de modelado
orientado a objeto – por lo que la descripción del flujo de trabajo se orienta alrededor de los
modelos UML asociados21. A continuación se describen los principales flujos de trabajo de
ingeniería y de soporte:
Cuadro 1.1: Flujos de trabajo estáticos en el Proceso Unificado de Rational
Flujo de trabajo Descripción
Modelado del Los procesos del negocio se modelan utilizando casos de uso del
negocio negocio.
Se definen los actores que interactúan con el sistema y se

Requerimientos desarrollan casos de uso para modelar los requerimientos del
sistema.
Se crea y documenta un modelo del diseño utilizando modelos

Análisis y diseño arquitectónicos, modelos de componentes, modelos de objetos y
modelos de secuencias.
Se implementan y estructuran en subsistemas los componentes del

Implementación sistema, la generación automática de código de los modelos del
diseño ayuda a acelerar este proceso.
Las pruebas son un proceso iterativo que se llevan a cabo

Pruebas conjuntamente con la implementación. A la finalización de la
implementación tienen lugar las pruebas del sistema.
Se crea un release del producto, se distribuye a los usuarios y se

Despliegue
instala en su lugar de trabajo.
Configuración y
cambios de Este flujo de trabajo de soporte gestiona los cambios del sistema.
gestión
Página | 26
Gestión de
Este flujo de trabajo de soporte gestiona el desarrollo del sistema.
proyectos
Este flujo de trabajo se refiere a hacer herramientas software

Entorno
apropiadas disponibles para los equipos de desarrollo de software.
Fuente: Ingeniería del software .Sommerville (2005).
Ingeniería de Software Asistida por Computadora.
Sommerville comenta que la Ingeniería de Software Asistida por Computadora (Computer

Aided Software Engineering - CASE) es el nombre que se le da al software que se utiliza para
ayudar a las actividades del proceso de software como la ingeniería de requerimientos, el
diseño, el desarrollo de programas y las pruebas. Por lo tanto, las herramientas CASE incluyen
editores de diseño, diccionario de datos, compiladores, depuradores, herramientas de
construcción de sistemas, etc.
La tecnología CASE proporciona ayuda a procesos del software automatizando alguna de sus
actividades, así como proporcionando información acerca del software en desarrollo.
Aunque las predicciones que se hicieron cuando se introdujeron las herramientas CASE en los
años 80 y 90 fueron que el uso de la tecnología CASE generaría enormes ahorros en los costos
del proceso del software22.
1.2.1.5. Lenguajes de programación.

Un lenguaje de programación puede definirse como una notación para escribir instrucciones u
órdenes útiles para el ordenador y necesarias para la relación de un determinado proceso. Se
denomina "lenguaje fuente" a las órdenes que escribe el programador, las cuales son traducidas
al lenguaje máquina de la computadora. Cada lenguaje de programación tiene su propia
gramática o "lenguaje". Existen distintos niveles de programación, pudiendo englobarse en dos
grandes categorías:
i. Bajo nivel: es aquél por el que se accede al hardware directamente. Es el caso del
lenguaje máquina, el cual fue el primer lenguaje utilizado en la programación de
computadoras, si bien, ha sido sustituido por otros lenguajes más sencillos en su
utilización. Es el único que entiende directamente la computadora al usar el alfabeto
binario (0 y 1) por lo que, también son los menos "amigables" para el usuario ante el
cúmulo de errores que se pueden cometer.
22
Sommerville, 2005, Ingeniería del software. p. 79
Página | 27
ii. Los lenguajes ensambladores: de bajo nivel surgen como un intento de sustituir el
lenguaje máquina (son aquellos cuyas instrucciones son directamente entendibles por la
computadora sin la necesidad de traducción alguna, su instrucciones no son más que
bits (0 y 1), es fácil de comprender para la máquina y complicado para el hombre) por
otro más asequible en su aprendizaje y utilización. Cada instrucción equivale a una
instrucción en el lenguaje máquina: la única diferencia es que para su escritura utiliza
palabras mnemotécnicas y no cada de bits. Por lo demás, presenta casi todos los
inconvenientes del lenguaje máquina, entre ellos, el que cada modelo de ordenador tiene
un lenguaje ensamblador propio, por lo que un programa sólo puede utilizarse en la
máquina para la cual se programó, lo que obliga a conocer la intrincada arquitectura de
la máquina. Los lenguajes ensambladores son los que más se aproximan al lenguaje
máquina (0 y 1) y, en consecuencia, existen posibilidades de cometer errores, aunque
también son más rápidos porque la traducción al lenguaje máquina se efectúa en menos
pasos.
iii. Alto nivel: también denominados lenguajes evolucionados. Persiguen, en primer lugar,
lograr independencia de la máquina, de forma que un mismo programa se puede utilizar
en diferentes ordenadores, si bien, debe disponerse de un programa traductor (intérprete
o compilador) para obtener el programa ejecutable en el lenguaje binario de la máquina
de que se trate. De esta manera, no se requiere conocer el hardware específico del
equipo. En segundo lugar, que el programa se pueda escribir y leer de una forma más
sencilla, eliminando en gran medida las posibilidades de cometer errores, ya que se usan
palabras en inglés y no cadenas de bits o símbolos. Existen en la actualidad una gran
cantidad de lenguajes de programación de alto nivel. FORTRAN (lenguaje científico),
COBOL (COmmon Business Oriented Language o Lenguaje para programar
aplicaciones informáticas de negocio bajo cualquier plataforma), BASIC, Pascal, C y
Visual Basic. La nueva ola es la programación orientada a objetos, y, en este sentido, el
JAVA, Python y PHP están ganando popularidad.
7. Pero veamos en qué se diferencian los programas traductores arriba
mencionados:
iv. Los intérpretes: son traductores de lenguajes de programación de alto nivel que
traducen y se ejecuta el programa al mismo tiempo, es decir, traducen una sentencia de
programa a lenguaje máquina y el microprocesador, a continuación, la ejecuta; luego
pasas a la siguiente y así sucesivamente. Los programas como el BASIC deben ser
siempre ejecutados con su intérprete.
v. Los compiladores: traducen lenguajes de programación de alto nivel (COBOL y C) en
lenguaje máquina. Normalmente, un compilador genera, en primer lugar, lenguaje
ensamblador y, en acto seguido, traduce a lenguaje máquina. El programa se traduce
primero completamente, es decir, se "compila" y, tras comprobar que no existen errores,
se ejecuta.
El resultado es que los programas compilados se ejecutan más rápidamente que los
interpretados23.
1.2.1.6. Bases de datos.

A. Definición de un Sistema de Base de datos.
23 García, 2007, Conceptos básicos de hardware y software. p. 61
Página | 28
Un Sistema de Base de Datos es básicamente un sistema computarizado para llevar registros.
Es posible considerar a la propia base de datos como una especie de armario electrónico para
archivar, es decir, un depósito o un contenedor de una colección de archivos de datos
computarizados24.
B. Principales componentes de un Sistema de Bases de Datos.

A continuación se mencionarán los cuatro principales componentes en un sistema de base de
datos:
 La información: en general, la información en la base de datos estará integrada y además

será compartida.
 El equipo: se considera que son componentes del equipo del sistema: Medios de
almacenamiento secundario: dispositivos E/S asociados, Drives, Canales de E/S, etcétera,
Procesador o procesadores y memoria principal.
 Los usuarios: es todo el personal del departamento que requiera usar el sistema de base de
datos para implementar, consultar o realizar sus reportes. Se tienen diferentes tipos de
usuarios, entre los cuales tenemos a los programadores de aplicaciones; los cuales son los
responsables de escribir los programas de aplicación; los usuarios finales, quienes
interactúan con el sistema desde estaciones de trabajo o terminales; y finalmente el
Administrador de la Base de Datos (DBA), y es quien administra la base de datos Los
programas. Existe una capa de programas entre la base de datos física misma y los usuarios
del sistema: el Sistema de Administración de Base de Datos (DBMS, Data Base
Management System).
 El DBMS maneja todas las solicitudes de acceso a la base de datos formuladas por los
usuarios25.
C. El Sistema de Administración de Bases de Datos (DBMS).
El software que permite a una o más personas el usar y/o modificar los datos de una base de
datos se denomina Administrador de Base de Datos (DBMS). Maneja todas las solicitudes de
acceso a la base de datos formuladas por los usuarios.
24 Pérez L., 2004, Tesis de grado de licenciada en ciencias de la computación. p.14

25 Pérez L., 2004, Tesis de grado de licenciada en ciencias de la computación. p.14
Página | 29
 Seguridad: no todos los usuarios tienen acceso a todos los datos. Integridad: cierto tipo
de “consistencia” deberá realizarse sobre los atributos y los valores de los datos, para evitar
la inconsistencia en los datos.
 Sincronización: cuando varios usuarios corren programas que acceden a la base de datos
al mismo tiempo, el DBMS deberá dar protección de inconsistencias que puedan resultar de
dos operaciones simultáneas a un mismo grupo de datos.
 Protección de rupturas y recuperación: facilidades para realizar copias regulares de la

base de datos y reconstruirla después de un error de hardware o software.
 Uno de sus objetivos más importantes es proporcionar a los usuarios una visión abstracta
de los datos, es decir, el sistema esconde ciertos detalles de cómo se almacenan y mantienen
los datos, pero sin embargo se deben extraer eficientemente26.
1.2.1.7. Web Server.

La Web se ha convertido en parte de nuestra vida cotidiana. La gente usa la Internet para obtener
informes del tiempo, comprar libros, leer noticias, y mantenerse en contacto con amigos a través
de Web de e-mail. Navegadores Web proporcionan una interfaz amigable para acceder a la
información y para ocultar la complejidad de los protocolos subyacentes.
Los servidores Web o web servers son los programas que proporcionan la información a los
navegadores Web. Existen una serie de protocolos que utilizan los navegadores y servidores
para comunicarse, como TCP / IP (Transmission Control Protocol / Internet Protocol), DNS
(Domain Name System, Sistema de Nombres de Dominio) y HTTP (Hypertext Transfer
Protocol Secure, Protocolo de transferencia de hipertexto)27.
1.2.1.8. Gestión de Proyectos.

A. Definición de un proyecto.
Un proyecto es un esfuerzo temporal, que se lleva a cabo para crear un producto, servicio
o resultado único. La naturaleza de los proyectos indica un principio y un final definidos. El
final se alcanza cuando se logran los objetivos del proyecto o cuando se termina el proyecto
porque sus objetivos no se cumplirán o no pueden ser cumplidos, o cuando ya no existe la
necesidad que dio origen al proyecto. Todo proyecto crea un producto, servicio o resultado
26 Pérez L. Tesis de grado de licenciada en ciencias de la computación. p.14

27 López & Kallen, 2002, Apache 2 in 24 hours. p. 8
Página | 30
único. Aunque puede haber elementos repetitivos en algunos entregables del proyecto, esta
repetición no altera la unicidad fundamental del trabajo del proyecto.
Las tareas del proyecto pueden ser nuevas para el equipo del proyecto, lo que hace necesario
planificar con mayor dedicación que si se tratara de un trabajo de rutina. Además, los proyectos
se llevan a cabo en todos los niveles de una organización. Un proyecto puede involucrar a una
sola persona, una sola unidad o múltiples unidades dentro de la organización. Un proyecto
puede generar:
 Un producto que puede ser un componente de otro elemento o un elemento final en sí

mismo,
 La capacidad de realizar un servicio (por ejemplo una función comercial que brinda apoyo
a la producción o distribución).
 Un resultado tal como un producto o un documento (por ejemplo un proyecto de

investigación que desarrolla conocimientos que se pueden emplear para determinar si existe
una tendencia o si un nuevo proceso beneficiará a la sociedad)28.
B. Dirección de proyectos.
La dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas y
técnicas a las actividades del proyecto para cumplir con los requisitos del mismo. Se logra
mediante la aplicación e integración adecuadas de los 42 procesos de la dirección de proyectos,
agrupados lógicamente, que conforman los 5 grupos de procesos. Estos 5 grupos de procesos
son:
 Iniciación.
 Planificación.
 Ejecución.
 Seguimiento y control.
 Cierre.
Dirigir un proyecto por lo general implica:
 Identificar requisitos
28 PMI, 2008, Guía de los fundamentos para la dirección de Proyectos. p. 11
Página | 31
 Abordar las diversas necesidades, inquietudes y expectativas de los interesados según se
planifica y efectúa el proyecto.
 Equilibrar las restricciones contrapuestas del proyecto que se relacionan entre otros aspectos
con: el alcance, la calidad, el cronograma, el presupuesto, los recursos y el riesgo.
La relación entre estos factores es tal que si uno de ellos cambia, es probable que al menos otro
se vea afectado. Dada la posibilidad de sufrir cambios, el plan para la dirección del proyecto es
iterativo y su elaboración es gradual a lo largo del ciclo de vida del proyecto. La elaboración
gradual implica mejorar y detallar constantemente un plan, a medida que se cuenta con
información más detallada y específica, y con estimados más precisos. La elaboración gradual
permite a un equipo de dirección del proyecto, dirigir el proyecto con un mayor nivel de detalle
a medida que este avanza29.
C. Interesados.
Los interesados son personas u organizaciones (por ejemplo, clientes, patrocinadores, la
organización ejecutante o el público), que participan activamente en el proyecto, o cuyos
intereses pueden verse afectados positiva o negativamente por la ejecución o terminación del
proyecto. Los interesados también pueden ejercer influencia sobre el proyecto, los entregables
y los miembros del equipo. El equipo de dirección del proyecto debe identificar tanto a los
interesados internos como externos, con objeto de determinar los requisitos del proyecto y las
expectativas de todas las partes involucradas. Más aún el director del proyecto debe gestionar
la influencia de los diversos interesados con relación a los requisitos del proyecto, para asegurar
un resultado exitoso. El siguiente gráfico muestra la relación entre el proyecto, el equipo del
proyecto y otros interesados habituales30.
D. Procesos de la dirección de proyectos.

técnicas a las actividades del proyecto, para cumplir con los requisitos del mismo. La aplicación
de conocimientos requiere de la dirección eficaz de los procesos apropiados.

Página | 32
Un proceso es un conjunto de acciones y actividades interrelacionadas realizadas para obtener
un producto, resultado o servicio predefinido. Cada proceso se caracteriza por sus entradas, por
las herramientas y técnicas que puedan aplicarse y por las salidas que se obtienen.
Los directores del proyecto y sus equipos deben abordar cuidadosamente cada proceso, así
como las entradas y salidas que lo constituyen. A menudo, estas interacciones entre procesos
requieren efectuar concesiones entre requisitos y objetivos del proyecto, y las concesiones
específicas de desempeño variarán de un proyecto a otro y de una organización a otra. Una
dirección de proyectos exitosa incluye dirigir activamente estas interacciones a fin de cumplir
con los requisitos del patrocinador, el cliente y los demás interesados. En determinadas
circunstancias, será necesario repetir varias veces un proceso o conjunto de procesos para
alcanzar el resultado requerido. Los proyectos existen en el marco de referencia de una
organización y no pueden operar como un sistema cerrado. Requieren datos de entrada
procedentes de la organización y del exterior, y producen capacidades que vuelven a la
organización. Los procesos del proyecto pueden generar información para mejorar la dirección
de futuros proyectos31.
E. Origen de la gestión de proyectos.

Los proyectos han existido siempre. Cualquier trabajo para desarrollar algo único es un
proyecto, pero la gestión de proyectos es una disciplina relativamente reciente que comenzó a
forjarse en los años sesenta. La necesidad de su profesionalización surgió en el ámbito militar.
En los 50, el desarrollo de complejos sistemas militares, requería coordinar el trabajo conjunto
de equipos y disciplinas diferentes, en la construcción de sistemas únicos.
Bernard Schriever, arquitecto del desarrollo de misiles balísticos Polaris, es considerado el

padre de la gestión de proyectos, por la introducción del concepto de “concurrencia”, para
integrar todos los elementos del plan del proyecto en un solo programa y presupuesto.
El objetivo de la concurrencia era ejecutar las diferentes actividades de forma simultánea, y no

secuencialmente, y al aplicarla en los proyectos Thor, Atlas y Minuteman se redujeron
considerablemente los tiempos de ejecución. La industria del automóvil siguió los pasos de la
militar, aplicando técnicas de gestión de proyectos para la coordinación del trabajo entre áreas
y equipos diferentes. Comenzaron a surgir técnicas específicas, histogramas, cronogramas, los
Página | 33
conceptos de ciclo de vida del proyecto o descomposición en tareas (WBS Work Breakdown
Structure)32.
F. Organizaciones referentes en la gestión de proyectos.

La construcción de sistemas complejos que requerían el trabajo sincronizado de varias
disciplinas hizo evidente en los 60 la necesidad de nuevos métodos de organización para evitar
problemas recurrentes: Desbordamiento de agendas, desbordamiento de costes, calidad o
utilidad del resultado obtenido.
Para dar respuesta a esta necesidad, desde los años 60 han surgido organizaciones que
contribuyen al desarrollo del cuerpo de conocimiento de una gestión de proyectos, para ofrecer
garantías de previsibilidad y calidad de los resultados.
Este conocimiento se ha configurado como el currículo de una nueva profesión: La gestión de

proyectos predictiva. Las organizaciones más relevantes en esta línea son:
International Project Management Association (IPMA), fundada en 1965.
Project Management Institute (PMI) constituido en 1969.
Más tarde surgió PRINCE2, que comenzó a trabajar en 1989.
IPMA (International Project Management Association), centrada en el concepto de

“Competencias”, descritas a partir de la NCB (National Competence Baseline) desarrollada en
España por AEIPRO (Asociación Española de Ingeniería de Proyectos) y PMI surgieron como
organizaciones profesionales para desarrollar metodologías y procesos para la gestión de
proyectos.
OGC ha tenido la evolución inversa. Comenzó siendo un método (precursor de PRINCE),

alrededor del cual se ha terminado creando una organización. Se desarrolla en 1975, pero no es
hasta 1989 que pasa a llamarse PRINCE y es en 1996 cuando toma la denominación PRINCE2
y la orientación a todo tipo de proyectos33.
G. PMI - PMBOK.
a. Sobre el PMI.
32 Palacio J. & Rulata C., 2008, SCRUM Manager: Gestión de proyectos. p. 30

33 Palacio J. & Rulata C., 2008, SCRUM Manager: Gestión de proyectos. p. 30
Página | 34
Por casi 40 años, PMI ha defendido el profesionalismo de la gerencia de proyectos en todo el
mundo. Con más de medio millón de miembros y acreditados en más de 170 ciudades, PMI es
la asociación líder en la gestión de proyectos.
El Project Management Institute (PMI) es una asociación sin fines de lucro, líder en la Industria
de la Gerencia de Proyectos, dedicada al progreso y fomento de su aplicación efectiva a través
de la práctica. Fundada en 1969 en Pensilvania, Estados Unidos de Norteamérica. Actualmente
está presente en 172 países, con más de 420,000 miembros y profesionales certificados,
organizados en 250 Capítulos34.
b. Gerencia de proyectos.
En los términos simples, un proyecto es un emprendimiento único y temporal, con un
inicio y final. Usando esta amplia definición, existen proyectos en toda industria en el mundo,
desde la industria automotriz hasta la industria de la construcción, pasando por la industria
aeroespacial y de software. Es fácil ver como los gerentes de proyecto – aquellos profesionales
que dirigen los proyectos consistentemente con procedimientos probados – son parte vital de
una fuerza de trabajo global. Los gerentes de proyectos contribuyen a la calidad, eficiencia y
resultados de negocios a través de las diversas empresas.
Más formalmente, el PMI define a la gerencia de proyectos como “la aplicación de los
conocimientos, habilidades, herramientas y técnicas a un amplio rango de actividades en orden.
Los proyectos varían en tamaño y complejidad. Todos los proyectos, sin importar cuán
pequeños o grandes, o cuán sencillos o complejos sean, pueden configurarse dentro de la
siguiente estructura del ciclo de vida: Inicio, organización y preparación, ejecución del
proyecto, seguimiento y control del proyecto y cierre35.
c. La gerencia de proyectos en el Perú.

Actualmente la gerencia de proyectos en el Perú es ampliamente usada en proyectos de TI,
Minería y algunos proyectos del sector inmobiliario. Sin embargo su potencial puede aplicarse
a los sectores de gobierno, legislación, medicina, ingeniería y desarrollo científico.
Proyectos como la Central Hidroeléctrica El Platanal (de 200 MW y 220 millones de USD)
usan el estándar PMBOK (Project Management Body of Knowledge). Organizaciones como
34 PMI, 2007, Project Management Institute.
35 PMBOK, 2008, Guía de los fundamentos para la dirección de Proyectos (Guía del PMBOK), 4ª Ed. p. 23
Página | 35
Osinermin están implementando Oficinas de Proyectos (PMO por sus siglas en ingles) en
algunas divisiones de su organización como proyectos iniciales para su aplicación total. El BCP
trabaja con el estándar PMBOK aplicándolo es sus áreas de sistemas y marketing. Cambiando
de rubro Cosapi y GyM aplica el estándar PMBOK en diferentes proyectos inmobiliarios y de
construcción. Esto es reflejo de los más de 200 certificados PMP (Project Management
Profesional) que actualmente existen en el mercado peruano y que vienen aplicando el estándar
en las diferentes áreas y empresa donde trabajan, sin mencionar que esta cifra viene creciendo
rápidamente proyectándose para fin de año cerca de 300. Es por ello que en el Perú existen más
de 700 miembros del Capítulo PMI LIMA PERÚ, que participan activamente en la difusión del
estándar PMBOK y garantizan calidad en los proyectos de la región36.
d. Procesos de la dirección de proyectos.

técnicas a las actividades del proyecto para cumplir con los requisitos del mismo. La aplicación
de conocimientos requiere de la dirección eficaz de los procesos apropiados.
Un proceso es un conjunto de acciones y actividades interrelacionadas realizadas para obtener

un producto, resultado o servicio predefinido. Cada proceso se caracteriza por sus entradas, por
las herramientas y técnicas que puedan aplicarse y por las salidas que se obtienen. Los procesos
de dirección de proyectos se agrupan en cinco categorías conocidas como Grupos de Procesos
de la Dirección de Proyectos (o grupos de procesos):
 Grupo del Proceso de Iniciación. Aquellos procesos realizados para definir un nuevo
proyecto o una nueva fase de un proyecto ya existente, mediante la obtención de la
autorización para comenzar dicho proyecto o fase.
 Grupo del Proceso de Planificación. Aquellos procesos requeridos para establecer el

alcance del proyecto, refinar los objetivos y definir el curso de acción necesario para
alcanzar los objetivos para cuyo logro se emprendió el proyecto.
 Grupo del Proceso de Ejecución. Aquellos procesos realizados para completar el trabajo
definido en el plan para la dirección del proyecto a fin de cumplir con las especificaciones
del mismo.
36 PMI, 2007, Project Management Institute.
Página | 36
 Grupo del Proceso de Seguimiento y Control. Aquellos procesos requeridos para dar
seguimiento, analizar y regular el progreso y el desempeño del proyecto, para identificar
áreas en las que el plan requiera cambios y para iniciar los cambios correspondientes.
 Grupo del Proceso de Cierre. Aquellos procesos realizados para finalizar todas las
actividades a través de todos los grupos de procesos, a fin de cerrar formalmente el proyecto
o una fase del mismo.
La aplicación de los procesos de dirección de proyectos es iterativa y muchos procesos se

repiten durante el proyecto. Los Grupos de Procesos de la Dirección de Proyectos se vinculan
entre sí a través de los resultados que producen.
La naturaleza integradora de la dirección de proyectos requiere que el Grupo del Proceso de

Seguimiento y Control interactúe con los otros grupos de procesos, como se muestra en el
siguiente gráfico37.
Gráfica 1.6: Integración de grupos de procesos de la dirección de proyectos
Fuente: Guía del PMBOK (2008)
e. Áreas de conocimiento de la dirección de proyectos.

La Gestión de la Integración del Proyecto incluye los procesos y las actividades necesarias para
identificar, definir, combinar, unificar y coordinar los distintos procesos y actividades de la
dirección de proyectos dentro de los Grupos de Procesos de Dirección de Proyectos. En el
contexto de la dirección de proyectos, la integración incluye características de unificación,
consolidación, articulación, así como las acciones integradoras que son cruciales para la
37 PMBOK, Guía de los fundamentos para la dirección de Proyectos (Guía del PMBOK), 4ª Ed. p. 41 (B)
Página | 37
terminación del proyecto, la gestión exitosa de las expectativas de los interesados y el
cumplimiento de los requisitos. Los procesos de Gestión de la Integración del Proyecto
incluyen:
 Desarrollar el Acta de Constitución del Proyecto: Es el proceso que consiste en

desarrollar un documento que autoriza formalmente un proyecto o una fase y documentar
los requisitos iniciales que satisfacen las necesidades y expectativas de los interesados.
 Desarrollar el Plan para la Dirección del Proyecto: Es el proceso que consiste en

documentar las acciones necesarias para definir, preparar, integrar y coordinar todos los
planes subsidiarios.
 Dirigir y Gestionar la Ejecución del Proyecto: Es el proceso que consiste en ejecutar el

trabajo definido en el plan para la dirección del proyecto para cumplir con los objetivos del
mismo.
 Monitorear y Controlar el Trabajo del Proyecto: Es el proceso que consiste en

monitorear, revisar y regular el avance a fin de cumplir con los objetivos de desempeño
definidos en el plan para la dirección del proyecto.
 Realizar el Control Integrado de Cambios: Es el proceso que consiste en revisar todas

las solicitudes de cambios, aprobar los cambios y gestionar los cambios a los entregables, a
los activos de los procesos de la organización, a los documentos del proyecto y al plan para
la dirección del proyecto.
 Cerrar Proyecto o Fase: Es el proceso que consiste en finalizar todas las actividades a
través de todos los grupos de procesos de dirección de proyectos para completar
formalmente el proyecto o una fase del mismo.
La gestión de la integración del proyecto implica tomar decisiones en cuanto a la asignación de

recursos, balancear objetivos y alternativas contrapuestas, y manejar las interdependencias
entre las áreas de conocimiento de la dirección de proyectos.
Las áreas de conocimiento en la gestión de proyectos son:
 Gestión del alcance del proyecto.
 Gestión del Tiempo del Proyecto.
 Gestión de los Costos del Proyecto.
Página | 38
 Gestión de la Calidad del Proyecto.
 Gestión de los Recursos Humanos del Proyecto.
 Gestión de las Comunicaciones del Proyecto.
 Gestión de los Riesgos del Proyecto.
 Gestión de las Adquisiciones del Proyecto38.
H. PRINCE2.
PRINCE2 es el estándar por defecto para la Gestión de Proyectos en el Reino Unido y gran
parte de Europa y su uso también está creciendo con fuerza en el resto del mundo39.
a. Definición de PRINCE 2.
PRINCE 2 (Projects IN Controlled Environments) es un método estructurado para la gestión
efectiva de proyectos. Es de hecho un estándar utilizado por el gobierno del Reino Unido, y
ampliamente reconocido y utilizado por el sector privado. Este método es del dominio público,
ofreciendo una guía de buenas prácticas en la gestión de proyectos. PRINCE 2® es, sin
embargo, una marca registrada de la CCTA. Las características clave de PRINCE 2 son:
 Su enfoque en una justificación de negocio.
 Una estructura de organización definida para el equipo de gestión del proyecto.
 Una planificación basada en productos.
 Su énfasis en dividir el proyecto en fases manejables y controlables.
 Su flexibilidad para ser aplicado al nivel apropiado del proyecto40.
b. Metodología PRINCE 2.
PRojects IN Controlled Environments - Proyectos En Ambientes Controlados (PRINCE) es un
método de gestión de proyectos. Se aplicará a la gestión, control y organización de un proyecto.
"PRINCE2" se refiere a la segunda versión importante de este método puesto en marcha en

1996 y es una marca registrada de la Oficina de Comercio Gubernamental (OGC). PRINCE2
actualmente es la quinta edición, revisión y es ampliamente conocido como PRINCE 2009.
38 PMBOK. Guia de los fundamentos para la dirección de Proyectos (Guía del PMBOK), 4ª Ed. p. 70 (B)
39 PRINCE. Project in a box: Your own Project Support Office - PRINCE 2 (R.E.)
40 Prince Manual. PRINCE 2: Metodología de gestión de proyectos. p.9
Página | 39
PRINCE2 se ha convertido cada vez más popular y ahora es un estándar por defecto para la
gestión de proyectos en el Reino Unido41.
c. Lo positivo PRINCE 2.
PRINCE2 es un enfoque estructurado para la gestión de proyectos. Proporciona un método para
la gestión de proyectos dentro de un marco claramente definido. PRINCE2 describe los
procedimientos para coordinar a las personas y las actividades de un proyecto, cómo diseñar y
supervisar el proyecto, y qué hacer si el proyecto tiene que ser ajustado si no se desarrolla según
lo previsto.
En el método cada proceso es especificado con sus inputs y outputs claves y con objetivos
específicos y actividades que se llevarán a cabo, lo que da un control automático de cualquier
desviación del plan.
Dividido en etapas manejables, el método permite un control eficiente de los recursos. Sobre la
base de un estrecho seguimiento del proyecto se puede realizar de forma controlada y
organizada. Al ser un el método estructurado ampliamente reconocida y entendida PRINCE2
proporciona un lenguaje común para todos los participantes en el proyecto. Las funciones y
responsabilidades de gestión diferentes que participan en un proyecto se describen con detalle
y se pueden adaptar para adaptarse a la complejidad del proyecto y las habilidades de la
organización42.
d. Lo negativo de PRINCE 2.
PRINCE2 es a veces incorrectamente considera inadecuado para proyectos muy pequeños,
debido a los trabajos que requiere la creación y mantenimiento de los documentos. Sin embargo,
esto a menudo puede ser debido a una implementación pobre: PRINCE2 es totalmente
escalable43.
La figura siguiente presenta una visión general del modelo de procesos de PRINCE44.
41 PRINCE. Project in a box: Your own Project Support Office - PRINCE 2

42 PRINCE, 2011, Project in a box: Your own Project Support Office - PRINCE 2
43 PRINCE, 2011, Project in a box: Your own Project Support Office - PRINCE 2
44 PRINCE MANUAL, 2011, PRINCE 2: Metodología de gestión de proyectos, p.12
Página | 40
Gráfica 1.7: Visión general del modelo de procesos de PRINCE
Fuente:
PRINCE
2:
Metodología de gestión de proyectos (2011)
“PRINCE2 y PMBoK no compiten entre sí, son compatibles y complementarias y su

combinación puede mejorar la calidad de los productos y de los servicios prestados, a la vez
que mejora la satisfacción de las necesidad de negocio”45.
I. Metodologías ágiles.
Estos son los principales contrastes que diferencian el desarrollo tradicional del ágil: no lo
realizan equipos diferentes especializados. Es un equipo único, formado por personas muy
competentes, con perfiles y conocimientos que cubren las disciplinas necesarias para llevar a
cabo el trabajo. No hay fases. En realidad las fases pasan a ser tareas que se ejecutan cuando se
necesitan.
No se hace primero el diseño del concepto o los requisitos, más tarde el análisis, luego el
desarrollo, etc. Lo que aplicado al software serían las fases de: requisitos del sistema, requisitos
del software, análisis, diseño, construcción, pruebas e integración; y se ejecutarían de forma
secuencial, pasan a tareas que se llevan a cabo en el momento que hacen falta. Normalmente a
lo largo de pequeñas iteraciones durante todo el desarrollo.
45
Águeda A., 2010, PMBOK VS PRINCE 2
Página | 41
No se espera a disponer de requisitos detallados para comenzar el análisis, ni a tener éste para
pasar a la codificación. Muchas veces los requisitos no se pueden conocer si no avanza el
desarrollo y se va viendo y “tocando” el resultado. Otras veces el mercado es tan rápido que a
mitad de trabajo las tendencias o la competencia obligarán a modificar el producto. Además, la
participación de todo el equipo en el diseño aporta gran cantidad de talento innovador; un valor
clave en el mercado de productos y servicios TIC.
Los equipos ágiles empiezan a trabajar sin conocer con detalle cómo será el producto final.
Parten de la visión general, y sobre ella, producen regularmente incrementos de funcionalidad
que incrementan el valor al producto.
Principales modelos de gestión ágil.
Si hubiera que determinar cuál es el origen de la gestión ágil de proyectos, a falta de mejor
información, habría que situarlo en las prácticas adoptadas en los 80 por empresas como Honda,
3M, Canon, Fuji, Nec, Xerox, hp o Epson para el desarrollo de nuevos productos. La gestión
ágil de proyectos no es una gestión de anticipación (requisitos, diseño, planificación y
seguimiento) sino de adaptación (visión, exploración y adaptación). La gestión ágil tiene como
objetivos: valor, reducción del tiempo de desarrollo, agilidad, flexibilidad y fiabilidad. La
gestión ágil se basa en los principios del manifiesto ágil y centra el valor:
 Más en las personas y su interacción que en los procesos y las herramientas.
 Más en los resultados que funcionan que en la documentación exhaustiva.
 Más en la colaboración con el cliente que en la negociación contractual.
 Más en la capacidad de respuesta al cambio que en el seguimiento de un plan.
El desarrollo ágil comprende cinco fases: concepto, especulación, exploración, revisión y

cierre. El desarrollo ágil surgió en empresas de productos tecnológicos, fue identificado por
Nonaka y Takeuchi en los años 80 y a partir de los 90 diferentes profesionales del desarrollo
del software incorporaron sus principios en sus entornos de trabajo. De esas implementaciones
ágiles, las que abordan la gestión del proyecto son: ASD, AUP, Crystal, DSDM, Scrum. La
industria del software ha sido la primera en seguir su adopción, y muchos de sus profesionales
han documentado y propagado las formas particulares en las que han implementado los
principios de la agilidad en sus equipos de trabajo. De esta forma han aparecido en las últimas
décadas los nombres:
Página | 42
 AD - Agile Database Techniques.
 AM - Agile Modeling.
 ASD - Adaptive Software Development.
 AUP - Agile Unified Process.
 CRYSTAL.
 FDD - Feature Driven Development.
 DSDM - Dynamic Systems Development Method.
 Lean Software Development.
 SCRUM.
 TDD - Test-Driven Design.
 XBreed.
 XP - eXtreme Programming.
Éstos son los modelos que se encuentran inscritos en la organización Agile Alliance
(www.agilealliance.org) para promocionar y difundir su conocimiento. Cada una de ellos
expone formas concretas de aplicación de principios ágiles en el desarrollo de software.
Algunos determinan cómo realizar las pruebas, o la duración que emplean para desarrollar cada
iteración, o el protocolo para realizar las reuniones de trabajo. Unos métodos cubren áreas
concretas de la ingeniería del software (diseño, desarrollo pruebas), como es caso de AD, AM
o XP, y otros se centran en la gestión del proyecto. Estos últimos son:
 ASD - Adaptive Software Development.
 AUP - Agile Unified Process.
 CRYSTAL.
 DSDM - Dynamic Systems Development Method.
 SCRUM.
 XBreed.
Por ejemplo, el principio de desarrollo ágil iterativo e incremental, tiene reflejo en ciclos de 30
días empleados por Scrum, o de entre uno y cuatro meses empleado por los modelos Crystal.
Página | 43
CRYSTAL: Concebido por Alistair Cockburn (Cockburn, 2004), este modelo no describe una
metodología cerrada, sino un conjunto de ellas, junto con los criterios para seleccionar y adecuar
la más apropiada al proyecto. Los parámetros para determinarla son la criticidad y el tamaño
del sistema que se va a construir.
Gráfica 1.8: Modelo CRYSTAL
Fuente: SCRUM Manager: Gestión de proyectos. Palacio & Rulata (2008)
Los criterios empleados para la medición de estos parámetros son:
a. Criticidad (dimensión de las pérdidas que ocasionaría un malfuncionamiento del

sistema). Estos criterios definidos por el estándar IEEE 1012-1998.
1 (c): Pérdida de confort o usabilidad.
2 (d): Pérdidas económicas moderadas.
3 (e): Pérdidas económicas graves.
4 (l): Pérdida de vidas humanas.
b. Dimensión: Crystal determina el tamaño del sistema por el número de personas

empleadas en su desarrollo. (6 - 20 - 40 - 80). Fundamentos de Crystal:
Página | 44
 Desarrollo iterativo e incremental.
 Duración máxima de una iteración: 4 meses.
 Recomienda duraciones entre 1 y 3 meses.
 Especial énfasis en la importancia de las personas sobre los procesos.
 Especial énfasis en la comunicación directa.
 Modelo abierto a la adaptación e introducción de prácticas de otros modelos ágiles.
DSDM: DSDM es el acrónimo que da nombre a un modelo de procesos para desarrollo de

sistemas de software, concebido por el DSDM Consortium, que se fundó en Inglaterra en 1994,
y que actualmente tiene presencia en Inglaterra, EE.UU., Benelux, Dinamarca, Francia y Suiza;
y con interés y contactos para futuras representaciones en Australia, India y China.
Es un modelo que estuvo representado en la firma del Manifiesto Ágil: Arie van Bennekum,
firmante del manifiesto, era miembro del consorcio en Benelux, consultor y formador de
DSDM. En 2001, año del Manifiesto Ágil, DSDM publicó la versión 4.1 de su modelo, y se
consideró una metodología ágil; y aunque mantuvo las siglas, cambió la denominación original
(Dynamis Systems Development Method) por Framework for Business Centred Development.
Procesos del ciclo de desarrollo DSDM El ciclo de desarrollo de DSDM está compuesto de
cinco fases, precedidas de un pre-proyecto y un post-proyecto.
8. 1. Pre-proyecto.
9. 2. Estudio de viabilidad.
10. 3. Estudio de negocio.
11. 4. Iteración de modelado funcional.
12. 5. Iteración de diseño y desarrollo.
13. 6. Implementación.
14. 7. Post-desarrollo.
SCRUM: En 1995 Ken Schwaber presentó en OOPSLA 95 (Object-Oriented Programming
Systems & Applications conference) (Schwaber, 1995), la implementación de Scrum Para
software que él empleaba en el desarrollo de Delphi, y Jeff Sutherland en su empresa Easel
Corporation (compañía que en los macrojuegos de compras y fusiones se integraría en
VMARK, y luego en Informix y finalmente en Ascential Software Corporation).
Página | 45
Se basa en el principio ágil de desarrollo iterativo e incremental. Al período de trabajo para
desarrollar un incremento de producto se lo denomina “sprint”, y se recomiendan duraciones
entre una y cuatro semanas, si bien pueden contemplarse casos de hasta 60 días. Establece una
reunión al inicio de cada sprint para determinar el trabajo que se va a realizar, otra al final para
evaluar el resultado, y revisiones diarias que realiza el equipo en su auto-gestión”46.
Gráfica 1.9: Diagrama del modelo DSD
Fuente: SCRUM Manager: Gestión de proyectos. Palacio & Rulata (2008)
1.2.2. Estado del arte.

Actualmente existen técnicas y herramientas tecnologías que están revolucionando la manera
en cómo se implementan soluciones de tecnologías de información en las empresas, adoptando
conceptos de colaboración, herramientas analíticas e integración entre soluciones, a
continuación las revisaremos:
1.2.2.1. Lenguajes de Programación

A. ASP .NET
En primera instancia, .NET parece ser sólo un concepto de marketing, una forma de evitar otro
número final de Visual Basic, pero es mucho más que eso. .NET representa todo un rango de
tecnologías y conceptos que conforman una plataforma en la cual usted puede desarrollar
aplicaciones. Visual Basic .NET tiene un número de versión, el 7.0; pero no se usa. Así como
Windows XP, que en realidad es Windows NT 5.1, el nombre más sencillo o atractivo será el
que se use. Pero no espere escuchar Visual Basic 7.0 con frecuencia; de hecho, hay una multa
en Microsoft si se refiere a Windows XP como NT 5.1.
En el cambio a Visual Basic .NET, hay muchas cosas que se han modificado radicalmente; una
de ellas es el desarrollo de un nuevo fundamento de todas las herramientas de desarrollo .NET.
46 Palacio y Ruata, 2008, SCRUM Manager: Gestión de proyectos. p. 46
Página | 46
Este fundamento, conocido como .NET Framework, ofrece dos cosas primordiales: el entorno
de motor de ejecución básico y un conjunto de clases fundamentales. El entorno del motor de
ejecución es similar al sistema operativo en el sentido de que ofrece una capa entre su programa
y las complejidades del resto del sistema, con lo que provee de servicios a su aplicación y
simplifica el acceso a la funcionalidad de las capas inferiores. Las clases fundamentales ofrecen
una gran cantidad de funcionalidad, que envuelven y abstraen a tecnologías como los protocolos
de Internet, acceso al sistema de archivos, manejo de XML, etc.
Para que un lenguaje de programación aproveche el entorno del motor de ejecución y otra
funcionalidad del .NET Framework, el compilador debe producir código que se apegue a cierta
norma. Microsoft ofrece esta norma. la especificación de Lenguajes Comunes o Common
Languaje Specification (CLS), como una forma para crear cualquier compilador propio de .NET
Microsoft ha generado compiladores de Visual Basic, Visual C++ y C# que se apegan al .NET
Framework, pero ha puesto a disponibilidad del público la CLS para que otras empresas o
personas puedan generar compiladores para otros lenguajes. Como resultado, además de los
lenguajes provistos por Microsoft, hay otros como COBOL, APL, Smaltalk, etc., que están
generados con la misma base que Visual Basic .NET. En la ilustración siguiente se muestra la
relación de Common Language Runtime y la biblioteca de clases con las aplicaciones y el
sistema en su conjunto47.
A. JAVA.
Java es un lenguaje de programación orientado a objetos cuya sintaxis deriva de C y C++, pero
que provee un modelo de objetos más simple que C++. Java fue creado por James Gosling y
por la empresa SUN en el año 1995, como parte de una plataforma llamada Java Virtual
Machine o Máquina Virtual Java.
Aunque no se debe considerar a Java como una herramienta exclusiva y únicamente para la
programación en Internet, ya que su uso, lejos de restringirse a este campo, puede y debe
extenderse a problemas y situaciones de todo tipo, por lo tanto para evitar confusiones el
lenguaje Java se podría definir mejor de la siguiente forma: Java es un lenguaje de programación
orientado a objetos, de propósito general que presenta características especiales que lo hacen
idóneo para su uso en Internet48.
47 Mackenzie & Sharkey, 2011, Aprendiendo Visual Basic .NET en 21 lecciones avanzadas. p. 19
48 Esteban A., 2000, Programación en Java. p. 23
Página | 47
Desde entonces ha evolucionado hasta su versión 6. La máquina virtual permite que un
programa escrito y compilado en Java pueda ejecutarse en cualquier sistema operativo y
arquitectura sin ser modificado. El sistema operativo requiere tener una implementación de la
máquina virtual instalada. Java se compila en código de bytes o bytecode, y no en código
binario. El bytecode es la representación interna que entiende la máquina virtual, y es lo que
permite la independencia de arquitectura y sistema operativo.
Existen algunas otras diferencias importantes con C++. Java no permite herencia múltiple de
clases, aunque si permite herencia múltiple de interfaces. Las interfaces son definiciones de
comportamientos que pueden tener o implementar las clases, pero sin su implementación. Son
análogas a las clases abstractas con todos sus métodos abstractos de C++. En Java todos los
métodos son potencialmente polimórficos, mientras que en C++, un método debe ser declarado
virtual para que pueda comportarse en forma polimórfica. Java no posee destructores ni
operadores redefinibles por el programador. En Java las clases son definidas en paquetes y un
paquete puede contener múltiples clases y sub paquetes49.
B. PHP.
PHP es un lenguaje de programación usado frecuentemente para la creación de contenido para
sitios Web dinámicos con los cuales se puede programar las páginas HTML y los códigos
fuente. PHP es un acrónimo recursivo que significa "PHP - Hypertext Pre-processor"
(inicialmente PHP Tools, o, Personal Home Page Tools), y se trata de un lenguaje interpretado
usado para la creación de aplicaciones para servidores, o creación de contenido dinámico para
sitios Web.
El fácil uso y la similitud con los lenguajes más comunes de programación estructurada, como
C y Perl, permiten a la mayoría de los programadores experimentados crear aplicaciones
complejas con una curva de aprendizaje muy suave. También les permite involucrarse con
aplicaciones de contenido dinámico sin tener que aprender todo un nuevo grupo de funciones y
prácticas. Su interpretación y ejecución se da en el servidor Web, en el cual se encuentra
almacenado el script, y el cliente sólo recibe el resultado de la ejecución. Cuando el cliente
hace una petición al servidor para que le envíe una página Web, generada por un script PHP,
el servidor ejecuta el intérprete de PHP, el cual procesa el script solicitado que generará el
49 Maximiliano P., 2007, Tesis de grado de ingeniería en informática. p.18
Página | 48
contenido de manera dinámica, pudiendo modificar el contenido a enviar, y regresa el resultado
al servidor, el cual se encarga de regresárselo al cliente.
Además es posible utilizar PHP para generar archivos PDF, Flash, así como imágenes en
diferentes formatos, entre otras cosas. Permite la conexión a diferentes tipos de servidores de
bases de datos tales como MySQL, Postgres, Oracle, ODBC, DB2, Microsoft SQL Server,
Firebird y SQLite; lo cual permite la creación de Aplicaciones Web muy robustas.
PHP también tiene la capacidad de ser ejecutado en la mayoría de los sistemas operativos tales
como UNIX (y de ese tipo, como Linux o Mac OS X) y Windows, y puede interactuar con los
servidores Web más populares ya que existe en versión CGI, módulo para Apache, e ISAPI.
El modelo PHP puede ser visto como una alternativa al sistema de Microsoft que utiliza
ASP.NET/C#/VB.NET, a ColdFusion de la compañía Adobe (antes Macromedia), a JSP/Java
de Sun Microsystems, y al famoso CGI/Perl. Aunque su creación y desarrollo se da en el ámbito
de los sistemas libres, bajo la licencia GNU, existe además un IDE (entorno integrado de
desarrollo) comercial llamado Zend Optimizer. Recientemente, CodeGear (la división de
lenguajes de programación de Borland) ha sacado al mercado un entorno integrado de
programación para PHP, denominado Delphi for PHP 50.
C. PYTHON.
Python es un lenguaje de programación dinámico y orientado a objetos que puede ser usado
de muchas maneras en el desarrollo de software. Ofrece gran soporte e integración con otros
lenguajes y herramientas, viene con una extensiva cantidad de librerías y puede ser aprendido
en pocos días Muchos programadores informan un incremento sustancial en la productividad
y la sensación de que el lenguaje les motiva hacia un desarrollo de más alta calidad y código
más mantenible.
Python es distribuido bajo la licencia Open Source OSI que lo hace libre para ser usado
inclusive en el desarrollo de productos comerciales51.
50 López M. & Alonso J., 2008, Tesis de grado de ingeniero de las telecomunicaciones. p.28
51
Debuire B., 2010, EL Lenguaje de Programación Python.
Página | 49
D. Comparación de los lenguajes de programación
Cuadro 1.2: Comparación de los Lenguajes de Programación
LP Características Principales Desventajas
ASP .NET  Se encarga de detectar el tipo de navegador utilizado  Una de las limitaciones en el
por el cliente a la hora de realizar una petición al desarrollo con ASP es que con el
servidor y en consecuencia, determina la versión tradicional utilizamos lenguajes de
HTML que éste soporta. scripting no tipeados como VSBcrip o
 Se puede utilizar en cualquier computadora que esté JScrip. Podemos instalar otros
conectada a la red que tenga instalado un navegador. motores scripting que
 Es muy fácil de programar y tiene muchas utilidades impongan verificación de tipos; sin
que con una breve línea de aprendizaje pueden ser embargo, no son universalmente
modificadas a su gusto. conocidos o utilizamos como los
 Capacidad de conexión con la mayoría de los anteriores.
manejadores de base de datos.  Tiene que correr en PCs normales que
tengan Windows y un servidor Web.
JAVA  El JDK es una herramienta libre de licencias (sin  Hay diferentes tipos de soporte
costo), creada por Sun. Está respaldado por un gran técnico para la misma herramienta,
número de proveedores. Sun saca al mercado cada 6 por lo que el análisis de la mejor
meses una nueva versión del JDK. opción se dificulta.
 Existe soporte dado por Sun.  Para manejo a bajo nivel deben usarse
 Debido a que existen diferentes productos de Java, métodos nativos, lo que limita la
hay más de un proveedor de servicios. portabilidad.
 Existen dentro de su librería clases gráficas como  El diseño de interfaces gráficas con
awt y swing, las cuales permiten crear objetos awt y swing no es simple. o Existen
gráficos comunes altamente configurables y con una herramientas como el JBuilder que
arquitectura independiente de la plataforma. permiten generar interfaces gráficas
 Java permite a los desarrolladores aprovechar la de manera sencilla, pero tienen un
flexibilidad de la Programación Orientada a Objetos costo adicional.
en el diseño de sus aplicaciones.  Puede ser que no haya JDBC para
 Se puede acceder a bases de datos fácilmente con bases de datos poco comerciales.
JDBC, independientemente de la plataforma  Algunas herramientas tienen un costo
utilizada o El manejo de las bases de datos es adicional
uniforme, es decir transparente y simple.
PHP  Muy fácil de aprender.  Se necesita instalar un servidor web.
Se caracteriza por ser un lenguaje muy rápido.  Todo el trabajo lo realiza el servidor
 Soporta en cierta medida la orientación a objeto. y no delega al cliente. Por tanto
Clases y herencia. puede ser más ineficiente a medida
 Es un lenguaje multiplataforma: Linux, Windows, que las solicitudes aumenten de
entre otros. número.
 Capacidad de conexión con la mayoría de los  La legibilidad del código puede
manejadores de base de datos: MysSQL, verse afectada al mezclar sentencias
PostgreSQL, HTML y PHP.
Oracle, MS SQL Server, entre otras.  La programación orientada a
 Capacidad de expandir su potencial utilizando objetos es aún muy deficiente para
módulos. aplicaciones grandes.
 Posee documentación en su página oficial la cual  Dificulta la modularización.
incluye descripción y ejemplos de cada una de sus  Dificulta la organización por capas
funciones. de la aplicación.
 Es libre, por lo que se presenta como una alternativa Seguridad:
de fácil acceso para todos. PHP es un poderoso lenguaje e
 Incluye gran cantidad de funciones. intérprete, ya sea incluido como
 No requiere definición de tipos de variables ni parte de un servidor web en forma
manejo detallado del bajo nivel. de módulo o
ejecutado como un binario CGI
separado, es capaz de acceder a
archivos, ejecutar comandos y abrir
conexiones
de red en el servidor. Estas
propiedades hacen que cualquier
Página | 50
cosa que sea ejecutada en un
servidor web sea
insegura por naturaleza.
PYTHON  Simple: Python es en lenguaje simple y  Lentitud: Los programas

minimalístico. interpretados son más lentos que los
 Libre y Fuente Abierta: Python es un ejemplo de un compilados. Sin embargo los
FLOSS (Free/Libre and Open Source Software - programas interpretados suelen ser
Gratuito/Libre y Software de Fuente Abierta). cortos, en los que la diferencia es
FLOSS está basado en un concepto de una inapreciable.
comunidad que comparte conocimiento. Esta es una
de las razones por las cuales Python es tan bueno, ha
sido creado y mejorado por una comunidad que solo
quiere ver un mejor Python.
 Lenguaje de Alto Nivel: Cuando escribes programas
en Python nunca debes preocuparte por detalles de
bajo nivel, como manejar la memoria empleada por
tu programa.
 Interpretado: Es decir no existen compilaciones
separadas y pasos de ejecución. Solo ejecutas el
programa desde el código fuente. Internamente,
Python convierte el código fuente en una forma
intermedia llamada bytecodes, después los traduce
en el lenguaje nativo de tu computadora y ejecuta.
 Orientado a Objetos
 Librerías Extendidas: La librería estándar de Python
es de hecho muy amplia.
Fuente: Elaboración Propia
Por el tipo de compañía y necesidad de los clientes, se ha eligió PHP, debido a que al ser un CRM
que se utilizará en distintas partes de Perú, requiere ser una aplicación ligera pero estable; este
lenguaje de programación a través de los años y por su comunidad de programadores de
soportes se conoce como el lenguaje de programación que reúne 4 importantes características:
velocidad, estabilidad, seguridad y simplicidad.
1.2.2.2. Sistemas de Gestión de Base de Datos

A. Oracle
Oracle es un sistema de administración de base de datos, es uno de los motores de bases de
datos más potentes y utilizados en el mercado. Con su anuncio de 10g (o 10 - Grid), Oracle se
sumó a IBM, Sun Microsystems y Hewlett- Packard en la tendencia hacia la computación
distribuida, un concepto que involucra infraestructura de hardware y software, y que permite
reducir los costos de administración y uso de las tecnologías dentro de las empresas.
La computación distribuida o grid hace que los recursos de software y hardware que tiene una
empresa puedan "verse" y usarse como un sistema único. Así, por ejemplo, si el servidor de
Página | 51
correo de la compañía llega a su tope de uso, puede "inteligentemente" usar otros computadores
y redes en la empresa para evitar una caída en los sistemas52.
Oracle 11g es, el software de base de datos más robusta en el mercado hoy. También es el
software de base de datos líder utilizado y vendido en todo el mundo. Se ha convertido en un
estándar de arquitectura de la empresa para la gestión de datos, independientemente del tamaño
de los datos o la complejidad. Oracle es un software que organiza de manera eficiente los datos
de forma relacional. El modelo relacional es un concepto donde los datos son almacenados
lógicamente. El diseño de estos elementos es en forma de tablas. Las tablas tienen columnas, y
las columnas tienen atributos (carácter o un número, por ejemplo). Las tablas están organizadas
para almacenar datos específicos. Las tablas se relacionan entre sí a través de las claves
principales.
Oracle siempre ha tenido algunas técnicas de marketing creativas. A finales de 1990, Internet
estaba en auge, y todos deseaban la tecnología de Internet. Oracle lanzó una versión mejorada
de Oracle 8 y la calificó 8i (i representa el Internet). Esta adición fue un movimiento popular
porque en las empresas se dieron cuenta de las ventajas de facilitar el acceso a través de Internet.
El uso de Internet también reduce los requisitos de trabajo y el coste para aplicaciones cliente /
servidor en el que se ha instalado en la PC del usuario final. Tan popular como el boom de
Internet fue, grid computing es ahora la evolución de la gestión de arquitectura empresarial.
(De ahí la g, que significa la red.
El éxito de Oracle se debe en parte a la anticipación, la adaptación, y el establecimiento de las

tendencias de base de datos de tecnología. Usted puede elegir entre numerosas herramientas de
diseño y entorno de desarrollo integrado (IDE) de tecnologías, como la Arquitectura Orientada
a Servicios (SOA), Java y Extensible Markup Language (XML). Estas tecnologías son
portátiles, lo que reduce las dependencias de hardware o software y las suites estándar de
negocio a negocio (B2B), el procesamiento y la comunicación:
Orable es un DBMS (Database Management System, por sus siglas en inglés) poderoso y
robusto que funciona en muchos sistemas operativos, diferentes, incluyendo Windows 98,
Windows 2000, diversas variantes de UNIX, diferentes sistemas operativos de
macrocomputadoras y Linux. Éste es el DBMS más popular del mundo y tiene una larga historia
de desarrollo y uso. Oracle muestra al programador mucha de su tecnología y consecuentemente
52 Heredia. 2008, Gerencia de compras: La nueva estrategia competitiva. p. 156
Página | 52
puede afinarse y ajustarse de diversas maneras.Sin embargo, esto quiere decir que Oracle, puede
ser difícil de instalar, pues existen muchas configuraciones de la serie Oracle. Para empezar hay
dos versiones diferentes del motor DBMS de Oracle: Oracle personal y Oracle empresarial.
Además, existen formas y reportes y también el diseñador Oracle, así como un sistema central
de herramientas para la publicación de las bases de datos de Oracle en la web53.
B. SQL SERVER.
SQL Server es una de las mayores inversiones de Microsoft y ha sido una pieza estratégica
junto a los sistemas operativos Windows 200x Server, XP y Vista para incursionar en el
mercado de las aplicaciones corporativas. SQL Server es una plataforma para base de datos que
se utiliza en el procesamiento transaccional en línea (OLTP), a gran escala en las bodegas de
datos y las aplicaciones de comercio electrónico, así como también es una plataforma de
inteligencia de negocios para soluciones de integración, análisis y creación de informes de
datos.
La operación del producto es muy sencilla gracias a una interfaz amigable y al uso intensivo de
asistentes para la ejecución de un amplio número de tareas administrativas. La escalabilidad es
uno de los puntos fuertes de producto para competir con los principales productos similares
disponibles en el mercado corporativo.
Una base de datos SQL server, está dividida en varios componentes lógicos, como tablas, vistas
y otros elementos que son visibles al usuario. Estos elementos son dispuestos en dos o más
archivos en disco. EL formato y el lugar donde se graban los elementos lógicos son
transparentes para el usuario de sistema54.
SQL Server proporciona servicios de réplica entre varias copias de SQL Server así como con
otros sistemas de bases de datos. Sus Analysis Services (servicios de análisis), una parte integral
del sistema, incluye dispositivos de procesamiento en conexión analítico (OLAP, Online
Analytical Processing) y recopilación de datos. SQL Server proporciona una gran colección de
herramientas gráficas y «asistentes» que guían a los administradores de las bases de datos por
tareas tales como establecer copias de seguridad regulares, réplica de datos entre servidores y
ajuste del rendimiento de una base de datos. Muchos entornos de desarrollo soportan SQL
53 Kroenke, 2003, Procesamiento de base de datos. p.329

54 Osorio L., 2008, Base de datos relacionales teoría y práctica. p. 77
Página | 53
Server, incluyendo Visual Studio de Microsoft y productos relacionados, en particular los
productos y servicios .NET55.
C. MySQL.
MySQL es un sistema gestor de bases de datos (SGBD, DBMS por sus siglas en inglés) muy
conocido y ampliamente usado por su simplicidad y notable rendimiento. Aunque carece de
algunas características avanzadas disponibles en otros SGBD del mercado, es una opción
atractiva tanto para aplicaciones comerciales, como de entretenimiento precisamente por su
facilidad de uso y tiempo reducido de puesta en marcha. Esto y su libre distribución en Internet
bajo licencia GPL le otorgan como beneficios adicionales (no menos importantes) contar con
un alto grado de estabilidad y un rápido desarrollo.
Sin embargo, las diferencias con cualquier otra plataforma son prácticamente nulas, ya que la
herramienta utilizada en este caso es el cliente mysql - client, que permite interactuar con un
servidor MySQL (local o remoto) en modo texto. De este modo es posible trabajar con el sobre
un servidor instalado localmente o, a través de Internet, sobre un servidor remoto56.
MySQL es un gestor de base de datos sencillo de usar y rápido. También es uno de los motores
de base de datos más usados en Internet, la principal razón de esto es que es gratuito para
aplicaciones no comerciales. Las características principales de MySQL son:
 Es un gestor de base de datos. Una base de datos es un conjunto de datos y un gestor de

base de datos es una aplicación capaz de manejar este conjunto de datos de manera eficiente
y cómoda.
 Es una base de datos relacional. Una base de datos relacional es un conjunto de datos que
están almacenados en tablas entre las cuales se establecen unas relaciones para manejar los
datos de una forma eficiente y segura. Para usar y gestionar una base de datos relacional se
usa el lenguaje estándar de programación SQL.
 Es de código abierto. El código fuente de MySQL se puede descargar y está accesible a

cualquiera, por otra parte, usa la licencia GPL para aplicaciones no comerciales.
55 Silberschatz, Korth & Sudarshan, 2002, Fundamentos de bases de datos. p.646

56 Casillas L., Gibert M. & Pérez O., 2007, Bases de datos en MySQL. p. 235
Página | 54
 Es una base de datos muy rápida, segura y fácil de usar. Gracias a la colaboración de muchos
usuarios, la base de datos se ha ido mejorando, optimizándose en velocidad. Por eso es una
de las bases de datos más usadas en Internet.
 Existe una gran cantidad de software que la usa57.
D. POSTGRE SQL.
PostgreSQL es un gestor de bases de datos orientadas a objetos (SGBDOO o ORDBMS en sus
siglas en inglés) muy conocido y usado en entornos de software libre porque cumple los
estándares SQL92 y SQL99, y también por el conjunto de funcionalidades avanzadas que
soporta, lo que lo sitúa al mismo o a un mejor nivel que muchos SGBD comerciales.
PostgreSQL se distribuye bajo licencia BSD, lo que permite su uso, redistribución,

modificación con la única restricción de mantener el copyright del software a sus autores, en
concreto el PostgreSQL Global Development Group y la Universidad de California.
PostgreSQL puede funcionar en múltiples plataformas (en general, en todas las modernas
basadas en Unix), también en Windows de forma nativa. Para las versiones anteriores existen
versiones binarias para este sistema operativo, pero no tienen respaldo oficial.
En 1996 el nombre cambió a PostgreSQL retomando la secuencia original de versiones, por lo

que se liberó la versión 6.058.
PostgreSQL es un sistema de gestión de bases de datos objeto-relacional, distribuido bajo

licencia BSD y con su código fuente disponible libremente. Es el sistema de gestión de bases
de datos de código abierto más potente del mercado y en sus últimas versiones no tiene nada
que envidiarle a otras bases de datos comerciales.
PostgreSQL utiliza un modelo cliente/servidor y usa multiprocesos en vez de multihilos para

garantizar la estabilidad del sistema. Un fallo en uno de los procesos no afectará el resto y el
sistema continuará funcionando. Sus características técnicas la hacen una de las bases de datos
más potentes y robustos del mercado. Su desarrollo comenzó hace más de 15 años, y durante
este tiempo, estabilidad, potencia, robustez, facilidad de administración e implementación de
estándares han sido las características que más se han tenido en cuenta durante su desarrollo.
57 López M. & Alonso J., 2008, Tesis para optar el grado de ingeniero en telecomunicaciones. p. 34
58 Gibert M. & Pérez O. (2005). Bases de datos en PostgreSQL. p. 303
Página | 55
PostgreSQL funciona muy bien con grandes cantidades de datos y una alta concurrencia de
usuarios accediendo a la vez al sistema59.
E. Benchmarking
Con respecto a Oracle, no hacemos la comparación porque en su website, lo prohíbe, con estas
indicaciones: ‘You may not disclose results of any program benchmark tests without our prior
consent’60
Con respecto a los otros 3 Sistemas de Gestión de Bases de datos, mencionaremos sus
características principales y sus desventajas, para poder evaluarlas y así tomar la decisión más
asertiva.
Cuadro 1.3: Comparación de los SGBD

SGBD Características Principales Desventajas
SQL SERVER  Soporte de transacciones.  MSSQL usa Address Windowing
 Escalabilidad, estabilidad y seguridad. Extensión (AWE) para hacer el
 Soporta procedimientos almacenados. direccionamiento de 64-bit. Esto le
 Incluye también un potente entorno gráfico impide usar la administración dinámica
de administración, que permite el uso de de memoria, y sólo le permite alojar un
comandos DDL y DML gráficamente. máximo de 64 GB de memoria
 Permite trabajar en modo cliente-servidor, compartida.
donde la información y datos se alojan en el  MSSQL no maneja compresión de
servidor y los terminales o clientes de la red datos (excepto la versión 2008
sólo acceden a la información. Enterprise Edition, que sí lo hace), por
 Además permite administrar información de otros lo que las bases de datos pueden llegar
servidores de datos. a ocupar mucho espacio en disco.
 MSSQL requiere de un sistema
operativo Microsoft Windows, por lo
que no puede instalarse, por ejemplo, en
servidores Linux.
MySQL  Lo mejor de MySQL es su velocidad a la  Carece de soporte para transacciones,

hora de realizar las operaciones, lo que le rollback's y subconsultas.
hace uno de los gestores que ofrecen mayor  El hecho de que no maneje la integridad
rendimiento. referencial, hace de este gestor una
 Consume muy pocos recursos ya sea de CPU solución pobre para muchos campos de
como así también de memoria. aplicación, sobre todo para aquellos
 Licencia GPL y también posee una licencia programadores que proviene de otros
comercial para aquellas empresas que deseen gestores que sí que poseen esta
incluirlo en sus aplicaciones privativas. característica.
 Dispone de API's en gran cantidad de  NO es viable para su uso con grandes
lenguajes (C, C++, Java, PHP, etc.) bases de datos, a las que se acceda
 Mejor integración con PHP
59 Postgre Sql (2011) Sobre Postgre SQL. p. 1

60 Oracle(2011). License Rights
Página | 56
 Permite la gestión de diferentes usuarios, continuamente, ya que no implementa
como también de los permisos asignados a una buena escalabilidad.
cada uno de ellos.
 Tiene soporte para transacciones y además
posee una característica única de MySQL
que es poder agrupar transacciones.
PostgreSQL  Implementación del estándar SQL 92/SQL 99  Consume gran cantidad de recursos
 Licencia Berkeley Software Distribution-  Tiene un límite de 8K por fila, aunque
BSD se puede aumentar a 32K, con una
 Por su arquitectura de diseño, escala muy disminución considerable del
bien al aumentar el número de CPUs y la rendimiento.
cantidad de RAM.  Es de 2 a 3 veces más lento que
 Soporta transacciones y desde la versión 7.0 MySQL.
claves ajenas (con comprobaciones de
integridad referencial)
 Tiene mejor soporte para triggers y
procedimientos en el servidor.
 Incorpora una estructura de datos array.
 Incluye herencia entre tablas (aunque no entre
objetos, ya que no existen), por lo que a este
gestor de bases de datos se le incluye entre los
gestores objeto -relacionales.
 Implementa el uso de rollback's subconsultas
y transacciones, haciendo su funcionamiento
mucho más eficaz.
 Se puede realizar varias operaciones al
mismo tiempo sobre la misma tabla sin
necesidad de bloquearla.
Por el las mismas características importantes por las que escogió un lenguaje de programación:
velocidad, estabilidad, seguridad y simplicidad; se elige también el gestor de base de datos
MySQL, con el objetivo de que la solución tenga el comportamiento rápido, amigable y
navegable requerido por la Empresa Constructora Inmobiliaria.
1.2.2.3. Servidores Web

A. Apache.
El servidor HTTP Apache es un software libre que implementa un servidor HTTP de código
abierto para plataformas Unix (BSD, GNU/Linux, etc.), Windows, Macintosh, entre otras, que
implementa el protocolo HTTP/1.1 y la noción de sitio virtual.
El servidor Apache se desarrolla dentro del proyecto HTTP Server (httpd) de la Apache
Software Foundation. Apache tiene amplia aceptación en la red: desde 1996, Apache, es el
servidor HTTP más usado. Alcanzó su máxima cuota de mercado en 2005 siendo el servidor
empleado en el 70% de los sitios web en el mundo, sin embargo ha sufrido un descenso en su
Página | 57
cuota de mercado en los últimos años (frente a otras soluciones como el Microsoft Internet
Information Services o IIS)61.
B. IIS
Microsoft Internet Information Server (IIS) es el servidor Web dominante de la familia de
sistemas operativos Windows. Las razones para el éxito son múltiples, principalmente en torno
a la facilidad de uso e integración con otros productos de Microsoft. MS IIS viene preinstalado
con el sistema operativo o está disponible como una opción durante la instalación. Proporciona
un fácil de usar interfaz gráfica de usuario para la configuración del servidor y una interfaz
SNMP para el monitoreo.
IIS está estrechamente integrado con otras tecnologías de Microsoft, como Microsoft FrontPage
herramienta de publicación Web, Microsoft Active Server Pages (ASP) para el lado del servidor
desarrollo y, más recientemente, el. NET Framework. Además de ser un servidor HTTP
servidor, IIS también incluye un servidor FTP que se puede controlar desde la misma interfaz
gráfica de usuario como el servidor Web62.
C. Benchmarking
A continuación un Benchmark que nos permitirá evaluar ambos web servers:
Cuadro 1.4: Comparación de los Servidores Web
Apache IIS
Operating Systems supported: Cross-platform (Windows, Mac
OS X, Linux, BSD, Solaris, eCS, Windows
OpenVMS, AIX, z/OS)
License: Apache License 2.0 Proprietary
Website: http://httpd.apache.org/ http://www.microsoft.com/iis
Cost: Bundled with Windows NT family
Free
products
Basic access authentication: Yes Yes
Digest access authentication: Yes Yes
HTTPS support: Yes Yes
Virtual hosting: Yes Yes
CGI support: Yes Yes
FastCGI support: Yes Yes
Servlets: No No
SSI support: Yes Yes
61 López M. & Alonso J., 2008, Tesis para optar el grado de ingeniero en telecomunicaciones. p.35
62 López D. & Kallen I., 2002, Apache 2 in 24 hours. p. 417
Página | 58
Yes (via "mod_aspdotnet"
ASP.Net support: Yes
module)
Runs in user or kernel space: user space kernel or user space
Administration console: Yes Yes

IPv6: Yes Yes
Apache Software
Developed by: Microsoft Corp.
Foundation
Initial Release: 1995 With Windows NT 3.51
2.2.9 / June 13, 2008 (2008-
Latest Release: 7
06-13);
Portable configuration: Yes text/file Yes (Import & Export ) binary
Written in: C
Fuente: Apache vs IIS. Diffen.com (2011)
Este gráfico muestra el desempeño relativo de cada servidor web para ver cómo se comparan
cabeza a cabeza. El objetivo fue dar una comparación de rendimiento relativo en condiciones
comunes.
Gráfica 1.10: Diagrama del modelo DSD
Fuente: Apache vs IIS. Wiki.dreamhost.com (2011)
Por sus características de alta performance, utilizaremos el web server Apache, de esta manera
lograremos una combinación de muy alta performance en rendimiento y velocidad teniendo
como lenguaje de programación a PHP, como gestor de base de datos a MySQL y como servidor
web a Apache, buscando a través de esta elección, satisfacer los requerimientos no funcionales
de nuestro cliente.
Página | 59
1.2.2.4. SOA
La arquitectura de SOA es una respuesta directa a las necesidades de las áreas de negocios que
desean disponer de más flexibilidad en los sistemas de la empresa para poder adaptar más
rápidamente sus procesos para responder adecuadamente a las amenazas u oportunidades que
surgen en el entorno. SOA está basado en tecnologías desarrolladas inicialmente para realizar
operaciones B2B (Business to Business) pero que se han revelado muy útiles dentro de la
intranet63.
Fundamentalmente, la arquitectura orientada a servicios es una evolución en tecnología que se

convierte en un habilitador de negocios y eventualmente en un transformador de negocios.
Gráfica 1.11: La influencia de las nuevas tecnologías en el desarrollo de Internet
Fuente: Introducción a SOA (II). Aalbers (2011).
Una arquitectura orientada a servicios es una combinación de clientes y servicios que colaboran,
es soportada por un conjunto de capacidades de gestión, es guiada por principios, y es
gobernada por el soporte de estándares64.
i. La solución, Web Service

Tecnología propuesta como estándar conjuntamente entre IBM y Microsoft. Permite la
interacción entre sistema diversos, aunque estén programados en lenguajes de programación
distintos y corran en diferentes sistemas operativos
Propuesta de valor de los Web Services:
63 Aalbers H., 2011, Introducción a SOA (I). p. 3

64 Bean J., 2010, SOA and Web Services Interfaces Design. p. 4
Página | 60
 Reutilización de componentes.
 Permitir una mayor integración de sistemas y lograr tiempos de desarrollo más cortos
usando sistemas estándar no propietarios de comunicación.
 Tolerancia a cambios de diseño e infraestructura.
 Interacción dinámica entre socios de negocio.
 Soporte para sistemas heterogéneos.
 Mejorar la flexibilidad de los sistemas lento de lo esperado.
 Sin embargo, cada vez están apareciendo más servicios web públicos de calidad y la
situación está mejorando rápidamente.
 La implementación de web services dentro de la empresa es más fácil y aporta grandes

beneficios de manera inmediata.
 Simplificación de los sistemas.
 Reutilización de componentes.
 Posibilidad de crear nuevas aplicaciones conectando servicios existentes65.
Gráfica 1.12: Distribución Web Services
Fuente: SOA and Web Services Interfaces Design, Bean J. (2010).
65 Bean J., 2010, SOA and Web Services Interfaces Design. p. 9
Página | 61
En lugar de crear aplicaciones enormes y muy complejas se desarrollan componentes
reutilizables que son fáciles de mantener y probar. Las aplicaciones se crean diseñando un
proceso que interactúa con esos componentes. Para cada nueva aplicación se reutilizan los
componentes existentes y solo se desarrollan los que aún no existen. Los componentes se
conocen como servicios.
La implementación de SOA es una tarea compleja y que puede tardar bastante tiempo, es un
proceso de larga duración que no se logra de un día para otro. Por ello, lo mejor es dividirlo en
tres fases.
ii.Tres fases para lograr una implementación exitosa de SOA

Tanto para aquellos que parten desde cero, como para los que ya han tienen experiencia
trabajando con servicios, una implementación exitosa de SOA se logra dividiendo el proyecto
en tres fases que se ejecutan de manera consecutiva:
A. Planeación
B. Enterprise Application Integration
C. Business Process Management
Se describen a continuación:
A. Primera Fase – Planeación: Antes de poder empezar a crear

servicios y conectarlos es necesario definir los siguientes conceptos:
a. Definición de un servicio
Un servicio representa una función de negocios claramente definida que puede ser invocada
remotamente mediante protocolos de comunicación estándar.
Los servicios se definen mediante interfaces explícitos (WSDL) que son totalmente
independientes de la implementación del servicio. Los servicios deben poder ser invocados
utilizando protocolos de comunicación estándar que enfatizan la interoperabilidad e
independencia de ubicación.
b. Elección de los servicios requeridos

La mejor manera de detectar servicios es pidiendo a los usuarios de negocio que modelen sus
procesos.
c. Elección de los servicios a desarrollar
Página | 62
Para cada servicio detectado es necesario determinar si debe ser desarrollado desde cero o si es
posible exponer la funcionalidad que ya provee un sistema legado como un servicio. Para
sistemas legados hay distintas alternativas para exponer la funcionalidad que proveen como
servicio web:
 Colas de mensajes
 Adaptadores
 Acceso directo a la base de datos del sistema, etc.
a. Creación de nuevos servicios

Para servicios nuevos es posible utilizar virtualmente cualquier lenguaje de programación. Sin
embargo, muchos se pueden descartar por ser obsoletos, complejos, propietarios, etc. Los
servicios son programas, por lo tanto se deben desarrollar en base a metodologías aceptadas.
Una de las grandes ventajas de los servicios web es que permiten realizar fácilmente pruebas
unitarias, tanto funcionales como de volumen.
b. Elección de los protocolos de comunicación para servicios

Un sistema altamente distribuido, debe lograr funcionar a pesar de las fallas que pueden sufrir
algunos componentes. Esto se logra utilizando colas de mensajes para conectar de manera
asíncrona los distintos componentes. Sin embargo, en algunos casos, por ejemplo consultas,
puede no ser viable usar una comunicación asíncrona y HTTP puede ser entonces una
alternativa.
c. Administración de servicios
Si se dispone de pocos servicios, es posible que los desarrolladores sean quienes conserven los
archivos WSDL.
Si se cuenta con decenas de servicios, es necesario contar con un repositorio centralizado en el

que se publican todos los servicios existentes. Estandarización de los mensajes que van a
intercambiar los servicios
Normalización sintáctica: Cuando se trabaja con decenas de sistemas, es normal que no todos
manejen el mismo vocabulario. Para algunos, un mismo objeto, por ejemplo “Cliente” se puede
representar de manera distinta.
Página | 63
Es importante que durante el modelado de los procesos se intente normalizar la estructura de
los objetos de negocios, para simplificar la integración de sistemas y reducir la necesidad de
realizar transformaciones en las que se pueden perder datos, al interconectar diversos sistemas.
B. Segunda Fase - Enterprise Application Integration (EAI)

En esta fase se conectan los servicios a través de un Enterprise Service Bus (ESB) para lo que
es necesario considerar:
a. Ruteo y transformación de mensajes

Esta función es realizada por el Bus de Servicios Empresariales (ESB), él es en realidad una
infraestructura de comunicaciones seguras que permite conectar los servicios con los que cuenta
la organización. El ESB se crea utilizando colas de mensajes y brokers que transforman y rutean
mensajes en base a su contenido utilizando estándares como XSLT y XPath.
b. Seguridad
La seguridad es muy importante en el contexto de los web services. Es posible encriptar los
mensajes o el canal de comunicaciones. La seguridad debe estar centralizada. La seguridad
puede llegar a impactar seriamente al rendimiento de la aplicación.
c. Monitoreo
Una arquitectura SOA es tan sólida como su eslabón más débil, una de las principales misiones
del arquitecto es planear desde el diseño de la arquitectura cómo se van a monitorear todos los
aspectos de la misma para garantizar una operación tranquila y sin sobresaltos.
d. Calidad de servicio
Además de poder determinar posibles problemas es necesario hacer todo lo posible para evitar
que se produzcan.
La mejor estrategia es que cada componente esté en alta disponibilidad: Portal, orquestador de
procesos, servidores de aplicaciones (en los que corren los servicios), bases de datos, colas de
mensajes, brokers, etc.
La calidad de servicio también se refiere a tiempos de respuesta.
C. Tercera Fase - Business Process Management (BPM)

Tras la implementación del ESB, es importante definir:
Página | 64
a. La Separación de la capa de presentación de la lógica de negocios.
En un esquema de EAI, las aplicaciones comunican entre sí pero cada una mantiene su propio
interfaz de usuario.
Al pasar a la siguiente fase, se eliminan los clientes de cada aplicación y se consolidan en un

portal (De esta manera la capa de presentación se consolida en el portal, las funciones de
negocio en los servidores de aplicaciones y los procesos en el orquestador de procesos. Esto
simplifica el desarrollo y permite lograr mayores niveles de especialización).
b. Desarrollo de aplicaciones basadas en procesos

Tras una correcta planeación y una segunda fase en la que se desarrollan o exponen servicios,
se vuelve posible desarrollar nuevas aplicaciones conectando simplemente los distintos
servicios como parte de un proceso de negociosRealizar cambios a los procesos se vuelve
trivial, porque no hay que modificar código.
c. Monitoreo de procesos
Al ejecutar procesos, es posible monitorearlos para analizarlos y poder encontrar
posibilidades de mejora en los mismos. Con este modelo la dirección puede saber en tiempo
real la situación del negocio.
iii.Service Oriented Architecture

La adopción de una arquitectura basada en servicios requiere de una infraestructura de
comunicaciones escalable y segura entre los componentes. Esto es lo que se conoce como
Enterprise Service Bus:
A. El Bus de Servicios Empresariales (ESB)

 El Bus de Servicios Empresariales es el concepto que se refiere a la infraestructura de
transporte de mensajes entre el motor de procesos y los servicios de los que dispone la
empresa.
Gráfica 1.13: Distribución Web Services
Página | 65
Fuente: SOA and Web Services Interfaces Design. Bean J. (2010).
 El bus requiere una infraestructura sólida que ofrezca a los desarrolladores la seguridad de
que los mensajes sean entregados siempre, independientemente de los problemas que
puedan afectar a un servicio determinado en un momento dado.
 El bus debe ofrecer seguridad total y conectividad hacia todo el software de infraestructura
de la empresa
 El bus debe ser totalmente monitoreable porque se convierte en la columna vertebral de

todos los sistemas de la empresa66.
HTML fue diseñado para presentar información de manera sencilla y eficiente. HTML nunca
fue pensado para capturar información de formas complejas ni para manipular estos datos
localmente de manera flexible. HTML nos resuelve el problema de la oficina sin papel, que
tantas empresas quieren lograr. Muchas aplicaciones, en especial aquellas que requieren de
interfaces de usuario complejas, son muy difíciles de desarrollar en un ambiente web.
Todo el mundo reconoce que la capa de presentación debería ser creada por diseñadores
gráficos, sin embargo, la dificultad de crear interfaces complejas hace que muy a menudo esa
tarea quede a cargo de programadores.
B. El patrón Model-View-Controller (MVC)

 Para separar la capa de presentación de la de lógica de negocios, se creó el patrón Model-
View-Controller
 Se trata de un patrón de diseño en el que se manejan tres tipos de módulos.
- Vista - La capa de presentación, normalmente creada por los diseñadores gráficos, con
la que interactúan los usuarios
- Controlador - La capa de lógica de negocios que recibe datos de la Vista, los procesa
y le devuelve los resultados para que sean presentados de manera atractiva a los
usuarios
- Modelo - La representación de los datos que manipula la aplicación.
66 Aalbers H., 2010, Elección de tecnología para la capa de presentación de SOA. p.4
Página | 66
 El patrón MVC se desarrolló originalmente para aplicaciones cliente/servidor creadas en
Smalltalk y hoy en día sigue siendo muy popular en frameworks como Cocoa (MacOS X),
Swing o MFC67.
1.2.2.5. Cloud Computing

La nube es una metáfora de la Red, e. g. Internet. El National Institute of Standards and
Technology (NIST) define el cómputo en la nube como un modelo que proporciona, mediante
la red y según se requiera (en demanda), acceso a un conjunto compartido de recursos de
cómputo configurables, e. g. redes, servidores, almacenamiento, aplicaciones y servicios
ubicados en Data Centers.
Por tanto se trata de un modelo a la carta para la asignación y consumo de computación que
puede abastecerse rápidamente y ser puesto en marcha con un esfuerzo mínimo de gestión o
interacción por parte del proveedor del servicio. La Nube promueve la disponibilidad y está
compuesto de cinco características esenciales, ofrece tres modelos de servicio y puede
desplegarse en cuatro modelos68.
Este modelo se originó en los años 60, se refiere al hecho que la gente usaría el poder de
cómputo sólo cuando lo necesitara, y que sería cobrado en base al uso, como el agua o la
electricidad69.
Gráfica 1.14: Los Cuatro Modelos de Servicio
67 Aalbers H., 2010, Elección de tecnología para la capa de presentación de SOA. p.4
68 Juárez R., 2010, Cómputo en nube en el Distrito Federal – Anexo. p. 1
69 Aalbers H., 2010, Cloud computing. p. 1
Página | 67
Fuente: Definición de Cloud Computing, Juárez R. (2010)
A. Cloud Computing ¡Un futuro brillante!

 Economías de escala y foco en el negocio y no en la tecnología.
 Soluciones para PYMES - Se estima que para el 2015 el 50% de las empresas tendrán
alguno de su software como servicios SaaS.
 Calidad en niveles de servicio (SLAs)
 Facilita la innovación.
 Nuevo papel del CIO.
 Infraestructura competitiva - Cloud Computing y la globalización.
 Soluciones de ERP, CRM y Gestión de Contenidos.
B. Características del cloud computing

 Autoservicio en demanda: El cliente puede añadir o quitar recursos sin la interacción
humana del proveedor, tal como tiempo del servidor y almacenamiento en red.
 Extenso Acceso a la red: Los recursos están disponibles en la red y se acceden a través de
mecanismos estándar y heterogéneos (teléfonos móviles, computadores portátiles y PDAs).
 Puesta común de recursos: Los recursos informáticos del proveedor se comparten para
servir a múltiples clientes, usando un modelo multi – arrendatario, con diferentes recursos
físicos y virtuales asignados en forma dinámica y reasignando de acuerdo a la demanda de
los consumidores.
 Rápida Elasticidad: Las capacidades pueden proveerse de manera rápida y elástica, en

algunos casos, automáticamente para expandir las capacidades rápidamente, liberarlas y
reducirlas de nuevo e igual de rápido. A menudo, para el consumidor, las capacidades
disponibles para su aprovisionamiento parecen ser ilimitadas y pueden comprarse en
cualquier cantidad y en cualquier momento.
 Servicio Medido: Los sistemas en la nube controlan y optimizan automáticamente el uso

de recursos, aprovechando la capacidad de medición en algún nivel de abstracción
apropiado para el tipo de servicio que se trate (e. g. almacenamiento, procesamiento, ancho
de banda y cuentas de usuario activas). El uso de recursos puede ser monitoreado,
Página | 68
controlado y reportado proporcionando transparencia tanto para el proveedor como para el
consumidor del servicio utilizado70.
C. Modelos de servicio del cloud computing

Cloud Computing ofrece todo un sistema informático por medio de la red. Un sistema
informático se compone de los recursos computacionales físicos y lógicos, incluyendo los datos
e información del usuario residentes en la nube.
Cuando pensamos en recursos computacionales probablemente lo primero que viene a nuestra

mente son nuestros bienes tales como la PC, laptop, impresora, digitalizador (scanner), o todo
aquello que empleamos para procesar y organizar datos con el fin de tener información útil.
Todo aquello que viene a la mente al pensar en el término “cómputo” es factible conseguirlo,
bajo demanda y por medio de la red en mayor o menor nivel de abstracción con Cloud
Computing71.
1. SaaS: “Software como un servicio”

Las aplicaciones SaaS puede expresarse mediante un modelo que utiliza 4 niveles. Cada nivel
añade una característica respecto a la anterior: configurable, eficiencia, multi - usuario,
escalabilidad.Ofrece al consumidor el uso de las aplicaciones del proveedor ejecutadas en su
infraestructura de Nube. Se puede acceder a las aplicaciones desde varios dispositivos del
cliente a través de una interfaz ligera como un navegador Web. El consumidor no gestiona o
controla la infraestructura de Nube subyacente que consta de la red, los servidores, los sistemas
operativos, almacenamiento o siquiera las capacidades de la aplicación individual, con la
posible excepción de la configuración, limitada, específica que cada usuario puede establecer.
Características:
 Propiedad del software.
 No licencias - suscripción y pago por uso.
 Acceso a potentes aplicaciones a precios reducidos.
 Disponibilidad inmediata del servicio
 Aplicaciones multiusuario, personalizadas.
70 Cortés G., 2011, Cloud Computing - Tendencias - Modelos – Posibilidades. p. 1

71 Juárez R., 2010, Definición de Cloud Computing – Anexo. p. 3
Página | 69
 Control y gestión de la infraestructura.
Ejemplos:
2. PaaS: “Plataforma como un servicio”

Servicio de plataforma que permita desarrollar software a través de la red. Lo que ofrece al
cliente es implementar sobre la infraestructura de nube aplicaciones creadas o adquiridas por el
usuario, que empleen lenguajes de programación soportados por el proveedor. El consumidor
no gestiona o controla la infraestructura de nube subyacente, pero tiene el control sobre las
aplicaciones desplegadas y posiblemente sea capaz de configurar ciertas características, que el
proveedor permita, del entorno que aloja las aplicaciones.
Características:
 Un entorno de desarrollo basado en un navegador
 Despliegue transparente hacia el entorno de ejecución
 Herramientas de monitoreo y gestión
 Facturación basada en el uso
 Curva de aprendizaje
Ejemplos:
3. IaaS: “Infraestructura como servicio”

Externalización de servidores para espacio en disco, base de datos y/o tiempo de computación
Lo que se ofrece al usuario es la provisión de procesamiento, almacenamiento, redes y otros

recursos computacionales, sobre el cual se le permite al usuario desplegar y ejecutar cualquier
software, el cual puede incluir sistemas operativos y software de aplicación. El consumidor no
gestiona ni controla la infraestructura subyacente pero tiene el control de los sistemas
Página | 70
operativos, almacenamiento, aplicaciones implementadas y posiblemente control limitado de
determinados componentes de la red (e. g. servidores de seguridad)72.
Características:
 Soluciones basadas en virtualización
 Pago por consumo de recursos: espacio en disco utilizado, tiempo de CPU, espacio en base
de datos, transferencia de datos73:
Ejemplos:
Gráfica 1.15: Modelos de Servicio: SaaS – PaaS - IaaS
Fuente: Cloud Computing. Cortés G. (2011)

73 Cortés G., 2011, Cloud Computing - Tendencias - Modelos – Posibilidades. p. 1
Página | 71
Gráfica 1.16: Arquitecturas de las capas de servicio
Fuente: Cloud Computing. Cortés G. (2011)
D. Modelos de despliegue del cloud computing

a. Nube Privada: Servicios de propiedad o alquilada de la empresa. Las nubes privadas
permiten la protección de datos y la posibilidad de modificar el nivel de servicio, pues son
operadas por una única organización. Las nubes privadas están en una infraestructura “en
demanda” manejada por el mismo cliente o por un tercero, quien controla qué aplicaciones
correr y en dónde. La compañía es propietaria del servidor, red, y discos, por tanto, puede
decidir a qué usuarios les está permitido utilizar la infraestructura.
b. Nube Comunitaria: Servicios e Infraestructura compartida por una comunidad específica.
La infraestructura de la nube se comparte para apoyar a varias organizaciones que
conforman una comunidad que tiene preocupaciones compartidas (por ejemplo, la misión,
los requisitos de seguridad, la política y las consideraciones de cumplimiento). Puede ser
gestionada por las propias organizaciones o por un tercero.
c. Nube Pública: Servicios de venta al público en general con una infraestructura a gran escala
para su soporte. La infraestructura de nube pública se pone a disposición del público en
general o de un grupo industrial extenso, es manejada por un tercero en quien confiamos el
cómputo y la administración de nuestra información y es propiedad de un proveedor de
servicios de nube. Esto significa que muchos trabajos, de diferentes clientes, pueden
mezclarse en los servidores, sistemas de almacenamiento, y otra infraestructura dentro de
la nube pública.
d. Nube Híbrida: Las nubes híbridas combinan dos o más modelos de nubes (públicas,
comunitarias y privadas) que coexisten como entidades independientes, pero se mantienen
unidas mediante tecnología estandarizada o propietaria que permite la portabilidad de datos
y aplicaciones. El cliente es propietario de unas partes y comparte otras, aunque de forma
controlada. Estas nubes ofrecen escalabilidad en demanda, que puede o no ser
proporcionada externamente, a cambio añade la tarea de determinar cómo distribuir las
Página | 72
aplicaciones a través de estos diferentes ambientes, pues sólo funciona correctamente
aplicaciones que no dependan de sincronización compleja o bases de datos74.
1.2.2.6. WEB 2.0 Y CRM
La Web 2.0 y las redes sociales están cambiando el mundo y, también, el mundo de los
negocios. Ahora, el cliente es más importante que nunca y está estrechamente unido a la
estrategia, la gestión, los productos y los servicios de una empresa. En este contexto, es
fundamental que las soluciones de CRM aprovechen las oportunidades de la Web 2.0 para
cumplir el objetivo de estar más cerca del cliente75.
Hace una década, la mayoría de las empresas consideraba la gestión de relaciones con clientes
(CRM) como una función de operación detrás de la oficina para prestar un mejor soporte de
ventas y de operaciones del centro de llamadas. Con el tiempo, la tecnología ha cambiado la
forma de interactuar con los clientes de las empresas y dónde, cuándo y cómo realizan
transacciones. Los clientes se han vuelto más informados y sofisticados en sus comportamientos
de compra, y cómo interactúan a través de los medios de comunicación y canales. Atrás
quedaron los días de limitarse a supervisar la actividad de sitio web, tarjetas de respuesta, y el
tráfico en la tienda para recoger información procesable.
La reacción instintiva de muchas empresas de este cambio dinámico, que ha puesto a los
clientes en una posición más fuerte de control que nunca antes, es reunir simplemente más
datos, con la esperanza de alguna manera, aprendiendo a recuperar el control de una revolución
del marketing que ya salió de la estación.
Hoy en día, las empresas están aparentemente ahogadas en los datos, muchos de estos datos se
reúnen de manera incoherente y dispersa en toda la organización. Este y otros factores hacen
difícil, si no imposible, el aprovechar los datos. Sin duda, la forma en que las empresas recogen
y utilizar los datos debe ser integrada. Las organizaciones deben repensar cómo la información
se puede aprovechar para servir mejor a los objetivos de negocio, no sólo los objetivos de
marketing. Por otra parte, las empresas deben evolucionar rápidamente frente a los desafíos de
este nuevo entorno y no quedarse atrás. Los que han empezado esta transformación ya se dan
cuenta de las ventajas competitivas y financieras.

75 Cid R., 2005, Hacia el CRM 2.0: Retos y oportunidades. p. 42
Página | 73
La Ventaja competitiva del futuro dependerá de la capacidad de una
organización para entender, rastrear, realizar, medir, e influir en el comportamiento del
consumidor a nivel individual.
Para evolucionar del CRM 1.0 al CRM 2.0 hay que lograr verdadera centralidad en el cliente y
totalmente integrado el marketing del cliente.
Gráfica 1.17: Arquitecturas de las capas de servicio
CRM 1.0 CRM 2.0
• Tecnología • y Estrategia
• Experiencia • y Compromiso
• Back office • y Fron Office
• Ventas • y Marketing
• Operaciones • y beneficios
• Canales impulsadores • y los medios de
comunicación
impulsadores.
Fuente: CRM 2.0: Customer Strategy as a Business Strategy. Williams D. (2011)
El cambio fundamental requiere de todas las empresas es el compromiso con el cliente, pasando
de una orientación en la marca y en los productos a un modelo de negocio que este centrado
completamente en el cliente como un individuo único76.
Las empresas que son capaces de mantener el éxito son aquéllas que construyen sus negocios
en torno a sus clientes y, en este sentido, la tecnología naciente puede mejorar enormemente
esa capacidad.
76
Williams D., 2011, CRM 2.0: Customer Strategy as a Business Strategy. p.2
Página | 74
La última generación de clientes (los nacidos al final del milenio) ha crecido utilizando la
tecnología digital y sus miembros tienen nuevas expectativas sobre cómo aprender, trabajar e
interactuar. Además, cuentan con la firme convicción de que la colaboración es la clave del
éxito. Por ello, emplean las tecnologías de la Web 2.0 de forma natural y esperan que las
empresas con las que interactúan hagan lo mismo.
En su conjunto, se ha observado el incremento general de los clientes sociales. Ahora más que
nunca, los clientes hablan entre ellos, incluso cuando las organizaciones no ofrecen un lugar de
reunión para poder hacerlo, se ponen en contacto con comunidades independientes en las que
pueden colaborar, quizá incluso con la competencia. Las empresas deben estar atentas al
crecimiento del poder de los clientes sociales. En el pasado, las empresas podían crear su
imagen de marca a través de los medios tradicionales, como la televisión y los periódicos, pero
ahora no pueden controlar lo que se está diciendo de ellas en los blogs, los wikis y las redes
sociales.
Gráfica 1.18: Características de CRM y Social CRM
Fuente: Hacia el CRM 2.0: Retos y Oportunidades. Cid R. (2005)
Los consumidores están aprovechando herramientas como Twitter y Facebook para

intercambiar información sobre las empresas y sus productos e incluso están descubriendo y
resolviendo problemas sin involucrarlas. Por ello, es necesario cumplir las expectativas de esta
nueva base de clientes.
En definitiva, la Web 2.0 está transformando las soluciones de CRM y con ello está mejorando
el papel que desempeñan los clientes a la hora de influir en la estrategia, los productos y los
Página | 75
servicios de una empresa. Con la entrada de los clientes nacidos al final del milenio en la fuerza
de trabajo, el proceso de adopción de la Web 2.0 se está acelerando. Por ello, las empresas más
innovadoras están aprovechando las oportunidades que les ofrece la Web 2.0 para hacer que
sus organizaciones estén más centradas en el cliente77.
1.2.2.7. API Google Maps

Google Maps es una herramienta que permite desplegar un objeto geográfico a través de sus
coordenadas geográficas. El despliegue es vía la Web y es posible visualizar información
descriptiva y otros objetos geográficos (por ejemplo: calles) es una zona geográfica78.
Google Maps es un servicio de mapas al que se puede acceder desde un navegador web.
Dependiendo de la ubicación, se podrán ver los mapas básicos o personalizados e información
sobre negocios locales, como su ubicación, datos de contacto y cómo llegar hasta ellos. Sólo es
necesario hacer click y arrastrar los mapas para ver las secciones adyacentes en el momento. Al
contemplar las imágenes de satélite de la ubicación elegida se podrá ampliar y desplazar79.
Google Maps fue desarrollado originalmente por dos hermanos Daneses, Lars y Jens
Rasmussen, co-fundadores de “Where 2 Technologies” una empresa dedicada a la creación de
soluciones de mapeo. La empresa fue adquirida por Google en octubre de 2004, y los dos
hermanos luego crearon Google Maps (también son los que están detrás de Google Wave).
Antes de que hubiera una API pública, algunos desarrolladores descubrieron la manera de
hackear Google Maps para incorporar los mapas en sus propios sitios web. Esto llevó a Google
a la conclusión de que había una necesidad de una API pública, y en junio de 2005 fue lanzado
públicamente. El mashup por primera vez en Internet es a menudo considerado que lo ejerció
Housingmaps.com, una combinación de Google Maps con los listados de bienes raíces de
Craiglist.org. Fue creado de hecho antes de la API pública fuera puesto en libertad y fue
hackeado por el desarrollador Paul Rademacher. En mayo de 2010, se anunció la versión 3 del
API. Ahora es la opción recomendada para las nuevas aplicaciones de Google Maps y el
siguiente paso en la historia de Google Maps80.
77 Cid R., 2005, Hacia el CRM 2.0: Retos y oportunidades. p. 45

78 Mata M., 2009, Tesis que para obtener el grado de doctor en ciencias de la computación. p. 27
79 Google Maps, 2011, Guía del usuario de Google Maps
80 Maestros Del Web, 2011, Google Maps API V3 introducción y primeros pasos p. 1
Página | 76
Google Maps es un sitio que trabaja directamente para Google sin embargo su información de
negocios proviene de diversas fuentes como lo es la búsqueda web a través de Google Search,
datos proporcionados por los mismos dueños de los negocios que aparecen en el sitio, así como
los directorios de sección amarilla.
La información sobre mapas es proporcionada por la compañía Tele Atlas con quien Google
mantiene una asociación. Mientras que la información de vistas vía satélite proviene de Digital
Globe y MDA Federal.
Las imágenes mostradas en Google Maps son las mismas a las mostradas en Google Earth y la
antigüedad en sus imágenes varía entre uno y tres años dependiendo del área que se esté
observando81.
Es sólo HTML, CSS y Java Script trabajando junto. Los mapas son solo imágenes que se cargan
en el fondo a través de peticiones ejecutadas por la tecnología de AJAX, y se insertan en un
<div> en la página HTML. Mientras se navega en el mapa, el API envía información acerca de
las nuevas coordenadas y los niveles de “zoom” del mapa a través de AJAX y esto retorna las
imágenes.
El API consiste de archivos Java Script que contienen las clases, métodos y propiedades que se
usan para el comportamiento de los mapas. Las coordenadas están expresadas usando números
decimales separados por coma. La latitud siempre precede la longitud. La latitud es positiva
si va después del punto mostrado en el mapa y negativo si va antes. La longitud es positiva si
va arriba del punto y negativa si va debajo. En los mapas físicos, las coordenadas están
expresadas en grados.
Google está continuamente sorprendido por las nuevas formas que más de 150.000 sitios web
utilizan Google Maps. Existen varios casos de éxito, que podemos encontrar en la web oficial
de google. El caso de éxito más relacionado a esta investigación es Trulia82.
1.2.2.8. API Google Chart

Google Chart Tools proporcionan una manera perfecta para visualizar los datos en su sitio web.
Desde un simple gráfico de líneas hasta un complejo mapa de árbol jerárquico, la galería provee
81 Google Maps, 2013, Google Maps Fuera De Control. p. 1

82Trulia: Es un motor de búsqueda de bienes raíces que nos ayuda a encontrar inmuebles en venta y proporciona información
de bienes raíces para ayudarle a tomar mejores decisiones en el proceso.
Página | 77
una gran cantidad de tipos de gráficos muy bien diseñados. Un gráfico depende de los siguientes
componentes.
A. Librería
Los gráficos se exponen como clases de JavaScript.
Google Chart Tools ofrece muchos tipos de gráficos
para su uso. A pesar de la apariencia por defecto que es
la mejor para la mayoría de las situaciones, se puede
personalizar fácilmente para adaptarlo a la apariencia
de un sitio web. Los gráficos son muy interactivos y se
representan con tecnología HTML5/SVG (Scalable
Vector Graphics) para proporcionar compatibilidad entre navegadores (incluyendo VML para
versiones anteriores de IE) y la portabilidad entre plataformas para iPhones, iPads y Android.
No son necesarios los plugins.
B. Tablas de Datos
Todos los cuadros se rellenan con los datos usando la clase de Java Script DataTable. Tener
una estructura de datos común hace que sea fácil cambiar entre los tipos de gráficos. Esta clase
expone métodos para clasificar, modificar y filtrar datos. Se puede rellenar los datos mediante
programación a partir de los datos que se recuperan a partir de la base de datos83.
3.1. Benchmarking.
3.1.1. Microsoft Dynamics
Microsoft Dynamics ® CRM 2011 es un sistema de gestión de relaciones con el cliente que
está diseñado para el accesp a los usuarios del negocio de las áreas de Ventas, Servicio y
Marketing. Microsoft ® es líder en la nube y el CRM es una llave lista para la empresa como
estrategia Microsoft Cloud Services. Microsoft Dynamics CRM 2011 se construye sobre la base
de las versiones anteriores de Dynamics CRM para ofrecer a los fabricantes independientes de
software (ISVs) una plataforma potente para crear aplicaciones de línea de negocio. Estas
aplicaciones se refieren a menudo como las aplicaciones de CRM o aplicaciones ampliadas
XRM Framework, porque aprovechan las capacidades de seguimiento de relaciones más allá
de los típicos escenarios de relaciones con los clientes (CRM). Si su modelo de negocio es la
83
Google Chart, 2013, Introducción al uso de Herramientas de gráficos. p. 1
Página | 78
Gestión Inmobiliaria, Gestión de Flotas, Gestión de Pacientes o de vacaciones Planificación de
actividades para nombrar unos pocos, se puede implementar a través de una aplicación de CRM
extendido en Dynamics CRM 2011. En estos días, aplicaciones de línea de negocio (LOB)
Conexiones de modelo y de la pista entre los distintos tipos de datos empresariales. Dynamics
CRM 2011 brinda para el desarrollo de aplicaciones de negocio declarativo relacionales con
modelos de datos flexibles y servicios dinámicos. ISVs crear aplicaciones de CRM en
Ampliada Dynamics CRM 2011 utiliza el Framework. NET ™ y una variedad de otras
tecnologías comunes de la plataforma de Microsoft, como Windows Workflow Foundation
(WF), Windows Communication Foundation (WCF) y SQL Server ®. Estas tecnologías están
montadas como parte del marco de aplicaciones xRM.
Características Importantes:
 Roles Basados en la interfaz de usuario
Otra solicitud común para mejorar la experiencia global de la aplicación es permitir a los
usuarios con diferentes roles ver diferente contenidos en los formularios estándar. Por ejemplo,
un agente de arrendamiento y el administrador de la propiedad en un negocio de bienes raíces
necesitan información diferente acerca de una propiedad inmobiliaria.
Gráfica 1.19: Gestión de Roles
Fuente: Creación de aplicaciones de negocio con Microsoft Dynamics CRM 2011. Micrososft
Dynamics (2010)
Los usuarios que acceden a un registro de entidad que tiene múltiples formas puede elegir
cambiar entre los formularios disponibles que están disponibles para sus roles. Los
desarrolladores también pueden cambiar mediante programación el formulario que se muestra
el uso de secuencias de comandos del lado del cliente. En general, sin embargo, utilizando la
Página | 79
secuencia de comandos de cliente para ocultar y mostrar las pestañas o secciones de los
formularios existentes a menudo se obtienen mejores resultados que no causa una actualización
de página completa.
Gráfica 1.20: Gestión de Permisos
Dynamics (2010)
 Visualizaciones Gráficas, cuadros de mando e informes
El proceso de entrada de datos de una aplicación es importante, pero a menudo es la capacidad

de una empresa para analizar los datos y visualizarlos en formas significativas que marcan la
diferencia. Microsoft Dynamics CRM 2011 permite la construcción de esta data personalizada
con las entidades de la aplicación.
Gráfica 1.21: Gestión de Permisos
Página | 80
Dynamics (2010)
Mediante cuadros, cuadros de mando e informes, combinados o por separado, los usuarios y
los desarrolladores pueden crear visualizaciones para contar una historia de negocios más
completo. Los datos se pueden visualizar en forma resumida y luego permitir a los usuarios
acceder y tomar medidas en las filas de datos individuales. Los usuarios autorizados a utilizar
las herramientas integradas pueden crear las visualizaciones a partir de cero o yua partir de
plantillas proporcionadas por el ISV.
Utilidad del Proyecto de Tesis
La solución propuesta por Microsoft es un aporte muy importante para el presente proyecto de
investigación, debido que al un CRM líder en el mercado, nos da la visión de acuerdo a su vasta
experiencia que la gestión de roles y permisos y la visualización de gráficos, cuadros e informes
es de vital importancia en un CRM, de la misma manera el CRM SGI también pondrá real
énfasis en la correcta funcionalidad de estas trascendentales características.
3.1.2. SugarCRM
SugarCRM es uno de los principales proveedores mundiales de software CRM de código
abierto para las empresas pequeñas, medianas y grandes. SugarCRM ofrece una solución
flexible y rentable alternativa a las aplicaciones propietarias. SugarCRM es utilizado por más
de 3.500 organizaciones de todo el mundo comercial. SugarCRM está ayudando a la gente a
repensar cómo la tecnología puede ayudar a las empresas a gestionar las relaciones con clientes.
Es el líder en el mercado comercial de aplicaciones CRM de código abierto, ofrece un conjunto
rico en características de los procesos de negocio que mejoran la efectividad de marketing,
unidad de rendimiento de las ventas, mejora la satisfacción de los clientes y proporciona
información ejecutiva de desempeño del negocio. Apoyado por profundas capacidades de
colaboración y administración que se adapta a la forma en que operan la empresas. SugarCRM
está disponible en tres ediciones.
 Sugar Community Edition - versión de código abierto, libre de derechos de licencia.
 Sugar Professional - una versión comercial que ofrece funciones más avanzadas.
 Sugar Enterprise - Enterprise Edition con capacidades offline y soporte de Oracle.
Página | 81
En el siguiente diagrama se destaca la funcionalidad diferente que cada versión ofrece.
Gráfica 1.22: Características de SugarCRM
Fuente: SugarCRM para despachos de abogados un documento técnico. Gilroy (2010)
Sugar CRM permite a las compañías organizar y mantener la información de las relaciones con
sus clientes de manera eficiente en todos los aspectos. Ofrece la gestión integrada de la
información corporativa en las cuentas de clientes y contactos, clientes potenciales y
oportunidades de venta, además de actividades como llamadas, reuniones y tareas asignadas.
También ofrece un panel de control gráfico para realizar el seguimiento del proceso de ventas,
las fuentes de clientes de más éxito, y los resultados mes a mes para las oportunidades en el
pipeline.
Beneficios
 Toda la información de sus clientes en un solo lugar
 Fácil control de ventas y vendedores
 Personalizado a su negocio
Características
Sugar CRM está compuesto por módulos, cada uno de los cuales representa un aspecto
funcional específico de CRM, tales como cuentas, actividades, clientes potenciales y
oportunidades. Por ejemplo, el módulo de cuentas le permite crear y administrar cuentas de
Página | 82
clientes, y el módulo de Actividades le permite crear y administrar las actividades relacionadas
con las cuentas, oportunidades, etc.
Estos módulos están diseñados para ayudar a administrar las cuentas de clientes a través de cada
paso de su vida ciclo, comenzando con la generación y clasificación de leads, negociación,
cierre, incidentes a resolver, etc. Muchos de estos pasos están interrelacionados y, como
resultado, cada módulo incluye información relacionada. Por ejemplo, al ver los detalles de una
cuenta en particular, el sistema también muestra los contactos relacionados, actividades,
oportunidades, y los incidentes. Fácilmente se puede ver, editar y crear esta información.
 Sistema 100% en línea
 Gestión de cuentas, creación de clientes, empresas o personas
 Gestión de ventas, seguimiento a oportunidades y cumplimiento de metas de ventas por

vendedor
 Prospección, reportes de cumplimiento y ventas
 Gestión de contactos, creación de contactos por cuenta
 Gestión documental, publicación de documentos y ayudas comerciales
 Gestión de incidencias; administración de helpdesk para casos o reportes de error
 Niveles de acceso; configuración de usuarios por niveles de acceso y roles
 Fácil optimización a las características especiales de su negocio.
Funcionalidades:
 Automatización de la fuerza de ventas
Manejo de Leads, Contactos y oportunidades para perseguir hasta el final un nuevo negocio,
compartir información de ventas, seguimiento de la negociación y registro de las interacciones
con el cliente. El manejo de cuentas proporciona reportes por productos, zonas geográficas y
estado de la negociación.
 Automatización de marketing
Manejo de leads para el seguimiento y generación de nuevas oportunidades.
Gestión básica de campañas para mejor seguimiento de oportunidades.
Página | 83
 Atención al cliente
Gestión de eventos de atención al cliente centralizados que generan un histórico.
 Colaboración
Actividad de gestión de correos electrónicos, tareas, llamadas y reuniones.
Sindicación de contenidos para consolidar terceros fuentes de información.
 Administración
Editar la configuración del usuario, vistas, y los diseños de forma rápida en un solo lugar.
Gráfica 1.23: Prototipo SugarCRM
Fuente: www.sugarcrm.com
El aporte de la investigación realizada sobre SugarCRM es con respecto a la organización del

proceso de ventas relacionado a las actividades de seguimiento al cliente. Esta herramienta tiene
una gran facilidad de uso, las funcionalidades de los reportes y el enfoque especial en el proceso
de venta serán tomados en cuenta la hora de desarrollar el sistema. Una desventaja es que al
implementar el software de versión libre la reestructuración de las vistas de la base de datos
Página | 84
integra una interrelación entre muchas tablas lo que impide realizar la escalabilidad prometida
por la empresa en la entrega de la solución.
3.1.3. SalesForce
Salesforce.com ofrece un variado menú de aplicaciones de ventas y marketing, cada uno con
opciones de licencias múltiples, sin embargo, cada una de sus aplicaciones se basa en una
tecnología única, subyacente: la plataforma de desarrollo Force.com.
Gráfica 1.24: Vista del CRM SalesForce
Fuente: Obtenga más de Salesforce. Architect Solutions (2011)
Los desarrolladores de software usan Force.com para crear aplicaciones personalizadas con las
mismas herramientas que utilizan Salesforce.com para construir su Sales Cloud, Service Cloud,
Página | 85
Custom Cloud, and Collaboration Cloud. Así que cuando se dice que se está "desarrollando una
aplicación en la plataforma Force.com", significa que se está usando el lenguaje de Force.com
s rogramming (Apex) y herramientas de desarrollo estándar para crear nuevas funciones de
Salesforce que se conectan a los mismos datos que las características estándar.
Debido a Salesforce debe ser personalizable para satisfacer las demandas únicas de
organizaciones individuales de los clientes, Salesforce.com lanzó una serie de herramientas de
desarrollo basado en un lenguaje Java como codificación llamado Apex.
Limitaciones de Salesforce
A pesar de su desarrollo muy potente en herramientas la plataforma Force.com tiene algunas

limitaciones incorporadas. Los experimentados desarrolladores de Salesforce entienden estos
límites y saben cómo trabajar con ellos para construir aplicaciones robustas en la plataforma
Force.com. Desafortunadamente, hay una gran cantidad de desarrolladores inexpertos que no
son conscientes de que las restricciones siquiera existen.
Como la mayoría de las restricciones están relacionadas con el volumen de datos, los errores
por lo general pueden ser evitados. En realidad, hay tres restricciones que los desarrolladores
deben tener en cuenta al construir una aplicación personalizada de Salesforce:
 Límites de almacenamiento de datos
La data en Salesforce es cara, hay que tener cuidado, especialmente si se usan aplicaciones de
automatización de marketing. Son las que más utilizan datos.
Para mantener los costos bajos, siempre recomendamos limitar la creación de registros. La
mayoría de las cuentas de Salesforce comienzan con 1 GB de almacenamiento de datos o
registros de alrededor de 500.000. Cuando se supera este límite, usted tendrá que pagar por el
almacenamiento, ello puede variar entre $ 800 - $ 1.500 / GB (500.000 registros).
E-mail marketing es una actividad que rápidamente puede exceder los límites de
almacenamiento de datos.
Página | 86
Por ejemplo, una organización que envía correo electrónico a 70.000 contactos podrían generar
100.000 registros por correo. La organización excedería su capacidad de almacenamiento
después de sólo cinco correos.
 Límites de consulta
Estos son, con diferencia, los más duros límites a tratar. Tan pronto como su aplicación funciona
con unos pocos miles de registros, es probable que choquen los límites de la consulta.
Por ejemplo, hay límites en el número de registros que se pueden llamar, actualizarlos o
editarlos. También hay límites en el número de registros que se pueden guardar en la memoria.
La única manera de conseguir estos límites es procesar varios registros a la vez. Sin embargo,
esto no siempre es posible por lo que podría tener que manipular la aplicación para trabajar de
alguna manera dentro de los límites de la consulta.
 Límites de SQL
Salesforce utiliza un lenguaje de consulta denominado SOQL que imita llamadas SQL, pero no
admite todas las sentencias tipo llamadas de lectura/escritura SQL. Las limitaciones pueden ser
críticas y a menudo frustran a los nuevos desarrolladores.
En el lado positivo, Salesforce.com poco a poco va trayendo nuevas características para

soportar el estándar SQL lectura / escritura de las llamadas.
La investigación sobre SalesForce se basa en la administración de la data y la optimización de

las consultas de la BD (almacenamiento, consultas y sentencias). La investigación en mención
nos detalla las limitaciones que tiene la solución software, por ende este aporte es de vital
importancia para desde el inicio de la implementación de la BD optimizar las consultas y
guardar una bitácora de los store procedures y vistas gestionadas en la base de datos. Además
se ha elegido trabajar con mysql, por su conectividad, velocidad, y seguridad, características
que hacen de él altamente apropiado para acceder bases de datos en Internet.
3.1.4. Benchmarking de los CRMs

A continuación una comparación y evaluación de otros CRM conocidos a nivel mundial.
Página | 87
Cuadro 1.5: Benchmarking de CRM
Microsoft
BENCHMARKING SugarCRM Sales Force CRM SGI
Dynamics
Aspectos Funcionales
Ventas    
Post – Venta    
Marketing    
Seguimiento de Oportunidades    
Reportes Detallados    
Administración de Proyectos
   
Nacionales
Aspectos Funcionales
Interface de usuario Web Web Web Web
Costo por usuario Alto Bajo Bajo Bajo
Hay curva de
aprendizaje, la Hay una curva de Hay una curva de Es bastante
Fácil de usar
adaptación del aprendizaje aprendizaje intuitivo
usuario es larga
Personalización Alta Baja Baja Alta
Basado en la web    
Acceso a los esquemas de la base de Abierto y fácil
Prohibido Abierto Prohibido
datos de manejar
Lenguaje de programación .Net Framework PHP Apex PHP
SGBD SQL MySQL Oracle MySQL
Fuente: Elaboración Propia.
1.4 Objetivos del proyecto.

A continuación enunciamos el objetivo general y específicos del presente proyecto de
investigación:
1.5 Beneficios del proyecto.

Los beneficios del proyecto los clasificamos entre tangibles e intangibles:
1.5.1 Beneficios tangibles

Entre los beneficios tangibles podemos destacar:
 Incremento de las ventas (Ver detalle en el Anexo 4).
 Reducción de Personal de Trámite (Ver detalle en el Anexo 4).
1.5.2Beneficios intangibles:
Entre los beneficios intangibles podemos destacar:
Página | 88
 Clientes fidelizados.
 Toma de decisiones oportunas, inmediatas y pertinentes.
 Promover el desarrollo y competitividad organizacional.
 Mejor ambiente entre el personal del área comercial y las áreas involucradas a ella.
1.5.3Marco lógico.
A continuación detallamos el árbol de problemas y el árbol de objetivos:
Gráfica 1.25: Árbol de Problemas
Página | 89
Gráfica 1.26: Árbol de Objetivos
1.5.4Objetivo General:
Desarrollar un sistema informático que optimice la gestión del proceso de venta de una empresa
constructora inmobiliaria.
1.5.5Objetivos Específicos:
 Desarrollar un sistema que optimice los procesos de venta, de la Empresa Constructora
Inmobiliaria.
 Implementar la solución.
 Desplegar la solución.
 Contribuir a mejorar los resultados comerciales de la Empresa Constructora Inmobiliaria:

incrementando el número de ventas y reduciendo el personal del área de Trámite
Documentario.
Página | 90
1.6 Alcance del proyecto.
Para esta investigación primero se realizó un levantamiento de información para conocer y
entender los procesos de venta, marketing y servicios post ventas de la Empresa Constructora
Inmobiliaria para de esta manera definir un alcance basado en sus necesidades existentes.
El resultado de esta investigación se aplicó a una empresa real, la Empresa Constructora

Inmobiliaria. Actualmente la empresa administra la información propia de los proyectos y la
información de sus clientes de manera manual, factor que impide que la empresa aproveche las
diversas oportunidades que el mercado le ofrece en forma permanente.
Como solución a esta necesidad se plantó la utilización de un sistema informático de apoyo a

la gestión de ventas, marketing y servicios post ventas. Es decir se utilizó estrategias de
negocios centradas en los clientes conocida hoy en día como CRM mediante una completa
administración de proceso comercial, a través de un conjunto de estrategias y herramientas
enfocadas a la administración y creación de conocimiento mediante el análisis de datos
existentes de la organización.
Michael Porter propuso la cadena de valor como la principal herramienta para identificar
fuentes de generación de valor para el cliente: Cada empresa realiza una serie de actividades
para diseñar, producir, comercializar, entregar y apoyar a su producto o servicio; la cadena de
valor identifica nueve actividades estratégicas de la empresa, cada una con un costo, a través
de las que se puede crear valor para los clientes.
En este contexto, debido a que una solución CRM es básicamente una estrategia de negocios
centrada en el cliente, el objetivo mencionado de este proyecto se obtendrá con el desarrollo de
una aplicación Web CRM, que apoye los procesos de ventas (cotización, separación, venta,
cobranza), marketing (promociones) y servicios post ventas del sector inmobiliario (firma del
acta de conformidad), tomando como base los conocimientos de los procesos del negocio
inmobiliario y la investigación de herramientas tecnológicas y tendencias que existen en el
mercado.
Página | 91
Gráfica 1.27: Cadena de valor – Michael Porter
En estos
procesos se
centrará el CRM
Fuente: Michael Porter.
Página | 92
CAPÍTULO II: MODELADO DEL NEGOCIO
2.1 Reglas del negocio

Cuadro 2.1: Reglas del Negocio
Reglas del Negocio

1. Reglas de restricción
1.1. Reglas de operaciones
1.1.1. Reglas de flujo
RN01 La cotización tiene una duración de 3 días útiles.
RN02 Para hacer una separación debo hacer primero una cotización.
RN03 Cada forma de pago tiene un flujo de venta distinto.
1.1.2. Reglas de estímulo y respuesta
Si existe una promoción vigente, se le aplica a la venta de acuerdo a las
RN05
condiciones.
Si se presenta una incidencia en el proceso de post-venta es atendido
RN06
hasta su resolución.
1. 2. Reglas de estructura
1.2.1. Reglas de dominio o modelo de datos
RN07 Los precios de los inmuebles están en soles.
RN08 No hay precios de inmuebles negativos.
RN09 Una promoción puede ser un regalo o un descuento.
Existen 4 estados para los inmuebles: disponible, separado, vendido,
RN10
bloqueado.
RN11 Cada proyecto maneja independientemente sus cuentas bancarias.
1.2.2. Reglas de relación
Un mismo cliente puede hacer una o más cotizaciones, separaciones y
RN12
compras.
Un Jefe de ventas sólo les hace seguimiento a los asesores de venta
RN13
asignados.
2. Reglas de derivación
2.1. Reglas de inferencia
La definición y aprobación de la forma de pago del inmueble depende
RN15
de los ingresos del (de los) interesado(s).
Si un cliente no cumple con los pagos se elimina la separación y
RN16
Altozano retiene el 10% de la inicial.
2.2. Reglas de cálculo
La fórmula para el simulador de cuotas de pago es la que maneja la que
RN17
brinda cada Banco a la Empresa Constructora Inmobiliaria.
Página | 93
2.1. Casos de uso del negocio
De acuerdo a los procesos descritos en el Capítulo I, trabajaremos en base a los sub procesos
que trabajan directamente con el proceso de venta, debido a que las necesidades de la Empresa
Constructora Inmobiliaria se centran en este proceso.
Gráfica 2.1: Diagrama de Paquetes del Modelo del Negocio
Gestión Comercial Gestión deTrámite Documentario Gestión de Control de Calidad
Gestión de Marketing Gestión Legal Gestión Financiera
Gráfica 2.2: Casos de Uso del Negocio
Página | 94
<<extend>>
Gestionar Campaña
Gerente General
(from Gestión de Marketing)
(f rom Actores)
<<extend>>
Cotizar Inmueble
(from Gestión Comercial)
<<extend>>
Gestionar Promoción <<include>>

(from Gestión de Marketing)
Separar Inmueble Tramitar Minuta

(from Gestión Comercial) (from Gestión deTrámite Documentario)
<<extend>>
<<extend>> <<include>>
<<extend>>
<<include>>
Desistir Compra Enviar a Notaría Enviar a Banco

Cliente
(from Gestión Comercial) (from Gestión deTrámite Documentario) (from Gestión deTrámite Documentario)
(f rom Actores)
<<include>>
Tramitar Escritura Pública

(from Gestión deTrámite Documentario)
<<include>>
<<include>> <<include>> <<include>>
Tramitar Inscripción Liquidar Tributos y Servicios Entregar Acta de Entrega Registrar Desembolso
(from Gestión Legal) (from Gestión Financiera) (from Gestión de Control de Calidad) (from Gestión deTrámite Documentario)
2.2. Especificaciones Casos de uso del negocio más significativos
2.2.1 Especificación del Caso de Uso del negocio “Cotizar Inmueble”

Cuadro 2.2: Especificación Caso de Uso “Cotizar Inmueble”
Caso de Uso del

Cotizar Inmueble
Negocio
Actor Cliente.
Propósito Cotizar Inmueble.
Se explicará el proceso que involucra la cotización de un
Alcance
inmueble.
Definiciones,
Acrónimos y Ver Glosario.
Abreviaturas
Página | 95
• Diagrama de casos de uso del negocio.
Referencias • Diagrama de objetos del caso de uso Cotizar Inmueble.
• Diagrama de actividades del caso de uso Cotizar Inmueble.
Caso de Uso Gestionar Promoción
Casos de Uso Caso de Uso Gestionar Campaña
asociados Caso de Uso Separar Inmueble
Caso de Uso Desistir Compra
Resumen: El caso de uso Cotizar es de vital importancia para el negocio, se inicia
cuando el cliente llega al punto de venta y solicita información sobre el (los) inmueble(s)
de su interés, posteriormente el asesor comercial le asesora para seleccionar el (los)
inmueble (s), al conocer esta información se le muestra las promociones que están
asociados a la compra, las formas de pago y finalmente se le solicita sus datos
(asociándolo a una campaña de marketing) y le consulta si desea la impresión de la
cotización
Medidas de Al cotizar el asesor comercial debe acompañar al cliente, para que
Rendimiento elija el (los) inmueble(s) más idóneos a su necesidad y su realidad.
Se debe tener el Catálogo de Proyectos al alcance del asesor
comercial, para que pueda mostrarle toda esta información.
Pre-condiciones
Se debe contar con el simulador de pagos, para mostrarle al
cliente las distintas Formas de Pago.
FLUJO DE EVENTOS
Actor Proceso
1. El Cliente se acerca a un punto de venta y solicita una
cotización.
2. El Asesor Comercial consulta necesidad específica.
3. El Cliente le comenta sus necesidades detalladamente.
Cliente. 4. El Asesor Comercial le muestra toda la información
pertinente al inmueble sugerido. Y le consulta la forma de
pago de su elección.
5. El Cliente elige una forma de pago.
6. El Cliente solicita sus datos personales al cliente.
7. El Asesor Comercial Consulta si el cliente desea la impresión
de la cotización.
8. Si el cliente así lo desea se imprime la cotización.
9. El Asesor Comercial registra y realiza actividades de
seguimiento y control a la oportunidad.
Post-condiciones Se ha cotizado.
Categoría Caso de Uso Básico.
Dueño del Proceso Cliente.
Punto de Extensión No se han encontrado puntos de extensión.
Requisitos
No se han encontrado requisitos especiales.
Especiales
Gráfica 2.3: Diagrama de Actividades “Cotizar Inmueble”
Página | 96
: Cliente : Catálogo de Campaña
Solicitar Información de Consultar necesidad e interés

Inmueble
: Catálogo de Proyectos
Manifestar su necesidad e
interés
Entregar información del

Inmueble de su interés : Catálogo de Promociones
Definir Inmueble ¿Está No

de interés Interesado?
Si
Mostrar formas de
pago existentes
: Inmueble : Forma de Pago

[Definido] [Consultada]
Elegir forma de Solicitar datos
pago al cliente
: Catalogo de Campañas
[Consultada]
: Forma de Pago
: Cliente
[Definida]
Entregar Registrar datos [Cliente Contactado]

Información del cliente
Generar
Cotización
: Cotización
¿Imprimir Cotización?
[Creada]
Si No
Recibir Imprimir
Cotización Cotización
Registrar Actividades de
Seguimiento
Página | 97
Gráfica 2.4: Diagrama de Objetos “Cotizar Inmueble”
Catálogo de Promociones Catálogo de Campaña

(f rom Entidades) 1 Catálogo de Proyectos
1 (f rom Entidades) 1
1
(f rom Entidades)
0..*
1..*
1 1
1 Inmueble
1 (f rom Entidades)
1 1
1 1 1 1
1
Cliente
Cliente Asesor Comercial (f rom Entidades)
(f rom Actores)
(f rom Trabajadores)
1
1..* 0..*
0..* 0..*
1 1
Forma de Pago Cotización

(f rom Entidades) (f rom Entidades)
2.2.2 Especificación del Caso de Uso del negocio “Separar Inmueble”
Cuadro 2.3: Caso de Uso “Separar Inmueble”
Caso de Uso del

Separar Inmueble
Negocio
Actor Cliente
Propósito Separar Inmueble.
Se explicará el proceso que involucra la separación de un
Alcance
inmueble.
Definiciones,
Acrónimos y Ver Glosario
Abreviaturas
Referencias • Diagrama de objetos del caso de uso Separar Inmueble.
• Diagrama de actividades del caso de Separar Inmueble.
Página | 98
Caso de Uso Cotizar Inmueble.
Casos de Uso
Caso de Uso Tramitar Minuta.
asociados
Caso de Uso Desistir Compra.
Resumen:
El caso de uso Separar Inmueble es muy importante en el proceso de venta, crea una
oportunidad para la empresa, el cliente contactado se convierte en un cliente potencial,
el asesor comercial, verifica el pago hecho por concepto de la separación, gestiona las
firmas y finalmente genera y entrega el Contrato de Separación.
Medidas de Al tramitar el Contrato de Separación, el asesor comercial debe
Rendimiento verificar la los datos asociados al pago.
Pre-condiciones Se debe contar con una cotización.
FLUJO DE EVENTOS
Actor Proceso
1. El cliente entrega el (los) voucher(s) realizados por el
concepto de la separación.
2. El asesor verifica la cotización asociada a la separación y
el(los) pago(s) realizado(s). Si los datos están OK, el asesor
comercial procede a redactar el Contrato de Separación, de
lo contrario realiza nuevamente la verificación del pago.
Cliente 3. El Asesor Comercial gestiona las firmas requeridas para el
Contrato de Separación.
4. El Cliente firma el Contrato de Separación.
5. El Asesor Comercial firma y entrega el Contrato de
Separación al cliente.
6. El Asesor Comercial registra actividades de seguimiento
relacionadas al caso del cliente.
Post-condiciones Se genera un Contrato de Separación.
Categoría Caso de Uso Primario.
Propietario del
Asesor Comercial.
Proceso
Requisitos
El Cliente debe tener una cotización.
Especiales
Página | 99
Gráfica 2.5: Diagrama de Actividades “Separar Inmueble”
: Cliente : Asesor Comercial
Entregar Verificar Cotización y

Voucher Voucher de Pago : Cotización
[Consultado]
¿Datos OK?
No
Si
: Voucher de Pago
: Pago
[Consultado]
[Consultado]
Redactar Contrato
de Separación
: Contrato de Separación
[Creado]
Firmar Contrato Solicitar Firmas

de Separación : Expediente
No [Creado]
¿Firmas OK?
Si
Recibir Contrato de Entregar Contrato de

Separación Separación
Registrar Actividades de : Contrato de Separación

Seguimiento
[Entregado]
: Agenda
[Actualizado]
Página | 100
Gráfica 2.6: Diagrama de Objetos “Separar Inmueble”
1 1
0..*
Cotización Contrato de Separación

(f rom Entidades) 1 (f rom Entidades)
0..* 1
1
1 1
1 0..*
1
1
Expediente
Asesor Comercial 1 (f rom Entidades)
1
0..* 0..*
1 0..* 0..*
1 1
Agenda Voucher de Pago Pago

(f rom Entidades)
2.2.3 Especificaciones de los Casos de Uso del Negocio Restantes

Ver Anexo 1: Especificaciones de Casos de Uso del Negocio
Página | 101
CAPÍTULO III: REQUERIMIENTOS DEL SISTEMA
3.1. Requerimientos del software.
3.1.1. Requerimientos No Funcionales
N° Descripción Prioridad Exigencia

1 El sistema será desarrollado en lenguaje PHP. 3 E
2 El sistema usará una base de datos MySQL. 3 E
3 El sistema permitirá mantener la confidencialidad, es
decir, no permitirá accesos prohibidos en el sistema. 3 E
4 La disponibilidad del sistema será 24x7.

Garantizando un esquema adecuado que permita ante
3 E
una posible falla del mismo, un mecanismo de
contingencia.
5 El nivel de respuesta de la base de datos no excederá
de 45 segundos. 3 E
6 El sistema es multiusuario, es decir, permitirá el
acceso de más de 1 usuario a la vez. Máximo 3 E
soportado 15 usuarios a la vez.
7 El navegador soportado por el sistema será:
 Internet Explorer desde la versión 8.
 Mozilla Firefox desde la versión 3.6.
3 E
 Google Chrome desde la versión 5.
 Opera desde la versión 10
 Safari desde la versión 3.
Exigencia Descripción
E Exigible
D Deseable
Prioridad Nivel
Máxima 3
Prioridad
Mínima Prioridad 1
Página | 102
3.1.2. Matriz de Requerimientos
Cuadro 3.1: Matriz de Requerimientos
REQUERIMIENTOS FUNCIONALES
CLASIFICACION ATRIBUTOS
Nª PROCESO ACTIVIDAD REQUERIMIENTO CASO DE USO
Beneficio Complejidad Riesgo
F U R P S + Actores
(A, M, B) (A, M, B) (A, M, B)
R001 VENTAS Definir Inmueble Definir Inmueble x x x x x x A M B Asesor Comercial Cotizar Inmueble
R002 VENTAS Definir Cliente Definir Cliente x x x x x x A M B Asesor Comercial Cotizar Inmueble
R003 VENTAS Registrar Forma de Pago Registrar Forma de Pago x x x x x x A M B Asesor Comercial Cotizar Inmueble
R004 VENTAS Definir Cuenta Bancaria Definir Cuenta Bancaria x x x x x A B B Asesor Comercial Cotizar Inmueble
R005 VENTAS Definir Promoción Definir Promoción x x x x x x A M B Asesor Comercial Cotizar Inmueble
R006 VENTAS Imprimir Cotización Ver Cotización en HTML x x x x x A A B Asesor Comercial Cotizar Inmueble
R007 VENTAS Imprimir Cotización Ver Cotización en PDF x x x x x x A A B Asesor Comercial Cotizar Inmueble
R008 VENTAS Adjuntar documentos al expediente Adjuntar DNI x x x x x A B B Asesor Comercial Separar Inmueble
R009 VENTAS Registrar información del pago Registrar Información del Pago x x x x x A B B Asesor Comercial Separar Inmueble
R010 VENTAS Adjuntar Voucher Adjuntar Voucher x x x x x A B B Asesor Comercial Separar Inmueble
R011 VENTAS Generar Contrato de Separación Generar Contrato de Separación x x x x x A B B Asesor Comercial Separar Inmueble
R012 VENTAS Adjuntar Contrato de Separación Adjuntar Contrato de Separación x x x x x A B B Asesor Comercial Separar Inmueble
R013 VENTAS Crear Expediente Registrar Expediente x x x x x A B B Asesor Comercial Separar Inmueble
TRÁMITE Asesor de Trámite

R014 Registrar Información de la Minuta Registrar Información de la Minuta x x x x x A B B Tramitar Minuta
DOCUMENTARIO Documentario
Página | 103
F U R P S + Actores
(A, M, B) (A, M, B) (A, M, B)
R015 Generar Minuta Generar Minuta x x x x x A B B Tramitar Minuta
R016 Generar Anexo A Generar Anexo A x x x x x A B B Tramitar Minuta
R017 Generar Anexo B Generar Anexo B x x x x x x A A A Tramitar Minuta
TRÁMITE Adjuntar Minuta Escaneada y Asesor de Trámite
R018 Adjuntar Minuta Firmada x x x x x A B M Tramitar Minuta
DOCUMENTARIO Firmada Documentario
TRÁMITE Registrar Información de Envío a Asesor de Trámite
R019 Enviar a Notaría x x x x x A B B Enviar a Notaría
DOCUMENTARIO Notaría Documentario
TRÁMITE Asesor de Trámite Tramitar Escritura
R020 Registrar Escritura Pública Registrar Firmas x x x x x A B B
DOCUMENTARIO Documentario Pública
Registrar Información del Asesor de Trámite Registrar
R021 FINANZAS Registrar Desembolso x x x x x A B B
Desembolso Documentario Desembolso
CONTROL DE Asesor de Control Entregar Acta de
R022 Entregar Acta de Entrega Entregar Acta de Entrega x x x x x A B B
CALIDAD de Calidad Entrega
Liquidar Tributos y
R023 FINANZAS Liquidar Tributos y Servicios Liquidar Tributos y Servicios x x x x x A B B Asesor Financiero
Servicios
Liquidar Tributos y
R024 FINANZAS Liquidar Tributos y Servicios Adjuntar Voucher x x x x x x A B B Asesor Financiero
Servicios
TODOS LOS
R025 Ver Detalle del Expediente Ver Detalle del Expediente x x x x x A M B Asesor Comercial Separar Inmueble
PROCESOS
TODOS LOS
R026 Buscar Expediente Buscar Expediente x x x x x x A M M Usuario Buscar Expediente
PROCESOS
Registrar Información del Contrato Registrar Información del Registrar Contrato
R027 LEGAL x x x x x A B B Asesor Legal
de Separación Contrato de Separación de Separación
Registrar Contrato
R028 LEGAL Adjuntar Archivo Adjuntar Archivo x x x x x A B M Asesor Legal
de Separación
Registrar Información de la
R029 LEGAL Registrar Información de la Minuta x x x x x A B M Asesor Legal Registrar Minuta
Minuta
Página | 104
F U R P S + Actores
(A, M, B) (A, M, B) (A, M, B)
R030 LEGAL Adjuntar Archivo Adjuntar Archivo x x x x x A B B Asesor Legal Registrar Minuta
Registrar Información del Acta de Registrar Información del Acta de Registrar Acta de
R031 LEGAL x x x x x A B B Asesor Legal
Entrega Entrega Entrega
Registrar Acta de
R032 LEGAL Adjuntar Archivo Adjuntar Archivo x x x x x A B B Asesor Legal
Entrega
GESTIÓN DE Asesor de
R033 Registrar Proyecto Registrar Información del Proyecto x x x x x A B B Gestionar Proyecto
OPERACIONES Operaciones
R034 Registrar Proyecto Registrar Geoposición x x x x x A A B Gestionar Proyecto
R035 Registrar Proyecto Registrar Foto x x x x x A A B Gestionar Proyecto
R036 Registrar Proyecto Registrar Cuenta x x x x x A B B Gestionar Proyecto
GESTIÓN DE Actualizar Información del Asesor de
R037 Actualizar Proyecto x x x x x A B B Gestionar Proyecto
OPERACIONES Proyecto Operaciones
R038 Actualizar Proyecto Actualizar Geoposición x x x x x A M M Gestionar Proyecto
R039 Actualizar Proyecto Actualizar Cuenta x x x x x A B B Gestionar Proyecto
R040 Eliminar Proyecto Eliminar Proyecto x x x x x A B B Gestionar Proyecto
R041 Eliminar Proyecto Eliminar Foto x x x x x A M B Gestionar Proyecto
R042 Eliminar Proyecto Eliminar Cuenta x x x x x A B B Gestionar Proyecto
R043 Ver Detalle del Proyecto Ver Información del Proyecto x x x x x A B M Gestionar Proyecto
R044 Ver Detalle del Proyecto Ver geoposición x x x x x x A B M Gestionar Proyecto
R045 Ver Detalle del Proyecto Ver Foto x x x x x x A B M Gestionar Proyecto
R046 Ver Detalle del Proyecto Ver Cuenta x x x x x A B B Gestionar Proyecto
Página | 105
F U R P S + Actores
(A, M, B) (A, M, B) (A, M, B)
GESTIÓN DE Registrar Información del Tipo de Asesor de Gestionar Tipo de
R047 Gestionar Tipo de Inmueble x x x x x A B B
OPERACIONES Inmueble Operaciones Inmueble
GESTIÓN DE Actualizar Información del Tipo de Asesor de Gestionar Tipo de
R048 Gestionar Tipo de Inmueble x x x x x A B B
OPERACIONES Inmueble Operaciones Inmueble
GESTIÓN DE Asesor de Gestionar Tipo de
R049 Gestionar Tipo de Inmueble Eliminar del Tipo de Inmueble x x x x x A B B
OPERACIONES Operaciones Inmueble
GESTIÓN DE Asesor de Gestionar Tipo de
R050 Gestionar Tipo de Inmueble Ver Detalle del Tipo de Inmueble x x x x x A B B
OPERACIONES Operaciones Inmueble
GESTIÓN DE Registrar Información del Asesor de
R051 Registrar Tipología x x x x x A B B Gestionar Tipología
OPERACIONES Tipología Operaciones
R052 Registrar Tipología Registrar Foto x x x x x x A M B Gestionar Tipología
R053 Registrar Tipología Registrar Cuadro de Acabados x x x x x A M B Gestionar Tipología
R054 Actualizar Tipología x x x x x A B B Gestionar Tipología
OPERACIONES Tipología Operaciones
R055 Actualizar Tipología Actualizar Cuadro de Acabados x x x x x A B B Gestionar Tipología
R056 Eliminar Tipología Eliminar Tipología x x x x A B B Gestionar Tipología
R057 Eliminar Tipología Eliminar Foto x x x A B B Gestionar Tipología
R058 Ver Tipología Ver Información del Tipología x x x x A B B Gestionar Tipología
R059 Ver Tipología Ver Foto x x x x A B B Gestionar Tipología
R060 Ver Tipología Ver Cuadro de Acabados x x x x A B B Gestionar Tipología
R061 Gestionar Etapa Registrar Información de la Etapa x x x x A B B Gestionar Etapa
Página | 106
F U R P S + Actores
(A, M, B) (A, M, B) (A, M, B)
R062 Gestionar Etapa Actualizar Información de la Etapa x x x x A B B Gestionar Etapa
R063 Gestionar Etapa Eliminar Etapa x x x x A B B Gestionar Etapa
R064 Gestionar Etapa Ver Detalle de la Etapa x x x x A B B Gestionar Etapa
GESTIÓN DE Registrar Información del Asesor de
R065 Gestionar Inmueble x x x x x A B A Gestionar Inmueble
OPERACIONES Inmueble Operaciones
R066 Gestionar Inmueble x x x x x A B B Gestionar Inmueble
OPERACIONES Inmueble Operaciones
R067 Gestionar Inmueble Eliminar Inmueble x x x x x A B B Gestionar Inmueble
R068 Gestionar Inmueble Ver Detalle de Inmueble x x x x x A B B Gestionar Inmueble
GESTIÓN
R069 Registrar Cliente Registrar Información del Cliente x x x x x A B B Asesor Comercial Gestionar Cliente
COMERCIAL
GESTIÓN
R070 Actualizar Cliente Actualizar Información de Cliente x x x x x A B M Asesor Comercial Gestionar Cliente
COMERCIAL
GESTIÓN
R071 Eliminar Cliente Eliminar Cliente x x x x x A B M Asesor Comercial Gestionar Cliente
COMERCIAL
GESTIÓN
R072 Ver Cliente Ver detalle del Cliente x x x x x A B B Asesor Comercial Gestionar Cliente
COMERCIAL
GESTIÓN DE Registrar Información de la Forma Asesor de Gestionar Forma de
R073 Gestionar Forma de Pago x x x x A B B
OPERACIONES de Pago Operaciones Pago
GESTIÓN DE Actualizar Información de la Forma Asesor de Gestionar Forma de
R074 Gestionar Forma de Pago x x x x A B B
OPERACIONES de Pago Operaciones Pago
GESTIÓN DE Asesor de Gestionar Forma de
R075 Gestionar Forma de Pago Eliminar Forma de Pago x x x x A B B
OPERACIONES Operaciones Pago
GESTIÓN DE Asesor de Gestionar Forma de

R076 Gestionar Forma de Pago Ver Detalle de la Forma de Pago x x x x A B B
OPERACIONES Operaciones Pago
Página | 107
F U R P S + Actores
(A, M, B) (A, M, B) (A, M, B)
Registrar Información de la Gestionar
R077 MARKETING Registrar Promoción x A M B Gerente Comercial
Promoción Promoción
Gestionar
R078 MARKETING Actualizar Promoción Actualizar Promoción x A M B Gerente Comercial
Promoción
Gestionar
R079 MARKETING Eliminar Promoción Eliminar Promoción x A M B Gerente Comercial
Promoción
Gestionar
R080 MARKETING Ver Promoción Ver detalle de la Promoción x A M B Gerente Comercial
Promoción
GESTIÓN DE Registrar Información de la Asesor de Gestionar
R081 Gestionar Observaciones x M B B
OPERACIONES Observación Operaciones Observación
GESTIÓN DE Actualizar Información de la Asesor de Gestionar
R082 Gestionar Observaciones x M B B
OPERACIONES Observación Operaciones Observación
GESTIÓN DE Asesor de Gestionar
R083 Gestionar Observaciones Eliminar Observación x M B B
OPERACIONES Operaciones Observación
GESTIÓN DE Asesor de Gestionar
R084 Gestionar Observaciones Ver Detalle de la Observación x M B B
OPERACIONES Operaciones Observación
R085 MARKETING Registrar Campaña x A B B Gerente Comercial Gestionar Campaña
Campaña
R086 MARKETING Actualizar Campaña Actualizar Campaña x A B B Gerente Comercial Gestionar Campaña
R087 MARKETING Eliminar Campaña Eliminar Campaña x A B B Gerente Comercial Gestionar Campaña
R088 MARKETING Ver Campaña Ver detalle del Campaña x A B B Gerente Comercial Gestionar Campaña
Gestionar
R089 LEGAL Registrar Apoderado Registrar Apoderado x x A B B Asesor Legal
Apoderado
Gestionar
R090 LEGAL Actualizar Apoderado Actualizar Apoderado x x A B B Asesor Legal
Apoderado
Gestionar
R091 LEGAL Eliminar Apoderado Eliminar Apoderado x x A B B Asesor Legal
Apoderado
Gestionar
R092 LEGAL Ver Información del Apoderado Ver detalle del Apoderado x x A B B Asesor Legal
Apoderado
R093 FINANZAS Registrar Empresa x x M B B Asesor Financiero Gestionar Empresa
Empresa
Página | 108
F U R P S + Actores
(A, M, B) (A, M, B) (A, M, B)
R094 FINANZAS Actualizar Empresa Actualizar Empresa x x M B B Asesor Financiero Gestionar Empresa
R095 FINANZAS Eliminar Empresa Eliminar Empresa x x M B M Asesor Financiero Gestionar Empresa
R096 FINANZAS Ver Empresa Ver detalle de la Empresa x M B B Asesor Financiero Gestionar Empresa
R097 FINANZAS Registrar banco Registrar Información de la banco x x M B B Asesor Financiero Gestionar Banco
R098 FINANZAS Actualizar banco Actualizar Información de la banco x x M B B Asesor Financiero Gestionar Banco
R099 FINANZAS Eliminar banco Eliminar banco x x M B B Asesor Financiero Gestionar Banco
R100 FINANZAS Ver banco Ver detalle de la banco x M B B Asesor Financiero Gestionar Banco
R101 FINANZAS Registrar Notaría x x M B B Asesor Financiero Gestionar Notaría
Notaría
R102 FINANZAS Actualizar Notaría Actualizar Notaría x x M B B Asesor Financiero Gestionar Notaría
R103 FINANZAS Eliminar Notaría Eliminar Notaría x x M B M Asesor Financiero Gestionar Notaría
R104 FINANZAS Ver Notaría Ver detalle de la Notaría x M B B Asesor Financiero Gestionar Notaría
Registrar Información del Punto Gestionar Punto de

R105 FINANZAS Registrar Punto de Venta x M B B Asesor Financiero
de Venta Venta
Gestionar Punto de
R106 FINANZAS Actualizar Punto de Venta Actualizar Punto de Venta x M B B Asesor Financiero
Venta
Gestionar Punto de
R107 FINANZAS Eliminar Punto de Venta Eliminar Punto de Venta x M B B Asesor Financiero
Venta
Gestionar Punto de
R108 FINANZAS Ver Punto de Venta Ver detalle de la Punto de Venta x M B B Asesor Financiero
Venta
Página | 109
F U R P S + Actores
(A, M, B) (A, M, B) (A, M, B)
GESTIÓN Registrar Información del Agente Gestionar Equipo
R109 Registrar Agente de Venta x x M M M Gerente Comercial
COMERCIAL de Venta de Ventas
GESTIÓN Actualizar Información del Agente Gestionar Equipo
R110 Actualizar Agente de Venta x x M M B Gerente Comercial
COMERCIAL de Venta de Ventas
GESTIÓN Gestionar Equipo
R111 Eliminar Agente de Venta Eliminar Agente de Venta x x M B B Gerente Comercial
COMERCIAL de Ventas
GESTIÓN Gestionar Equipo
R112 Ver Equipo de Venta Ver detalle del Equipo de Venta x M B B Gerente Comercial
COMERCIAL de Ventas
TODOS LOS Registrar Información de la Gestionar
R113 Registrar Actividad x x M M B Usuario
PROCESOS Actividad Actividad
TODOS LOS Actualizar Información de la Gestionar
R114 Actualizar Actividad x x M M B Usuario
PROCESOS Actividad Actividad
TODOS LOS Gestionar
R115 Eliminar Actividad Eliminar Actividad x x M B B Usuario
PROCESOS Actividad
TODOS LOS Ver detalle en la Vista Lista de las Gestionar
R116 Ver Actividad x M M B Usuario
PROCESOS Actividades Actividad
TODOS LOS Ver detalle en la Vista Díaria de las Gestionar
PROCESOS Actividades Actividad
TODOS LOS Ver detalle en la Vista Semanal de Gestionar
PROCESOS las Actividades Actividad
TODOS LOS Ver detalle en la Vista Mensual de Gestionar
PROCESOS las Actividades Actividad
R120 SEGURIDAD Registrar Información del Usuario Registrar Información del Usuario x B B B Usuario Gestionar Usuario
R121 SEGURIDAD Actualizar Información del Usuario Actualizar Información del Usuario x B B B Usuario Gestionar Usuario
R122 SEGURIDAD Eliminar Usuario Eliminar Usuario x B B B Usuario Gestionar Usuario
R123 SEGURIDAD Registrar Información del Rol Registrar Información del Rol x x B B B Usuario Gestionar Rol
Página | 110
F U R P S + Actores
(A, M, B) (A, M, B) (A, M, B)
R124 SEGURIDAD Actualizar Información del Rol Actualizar Información del Rol x B B B Usuario Gestionar Rol
R125 SEGURIDAD Eliminar Rol Eliminar Rol x B B B Usuario Gestionar Rol
R126 SEGURIDAD Actualizar Permiso Actualizar Permiso x x x B B B Usuario Gestionar Rol
R127 SEGURIDAD Completar Formulario Iniciar Sesión x x x x x x B B B Usuario Iniciar Sesión
R128 SEGURIDAD Iniciar Sesión Iniciar Sesión x x x x x B B B Usuario Iniciar Sesión
R129 SEGURIDAD Cerrar Sesión Cerrar Sesión x x x x x B B B Usuario Cerrar Sesión
Actualizar
R130 SEGURIDAD Actualizar Contraseña Actualizar Contraseña x x x x x x B B B Usuario
Contraseña
Recordar
R131 SEGURIDAD Completar Formulario Completar Formulario x x x x x x B B B Usuario
Contraseña
Recordar
R132 SEGURIDAD Enviar Correo de Confirmación Enviar Correo de Confirmación x x x x x B M M Usuario
Contraseña
Página | 111
3.2. Casos de uso del sistema.
3.2.1. Diagrama de actores del sistema.
Gráfica 3.1: Diagrama de Actores del Sistema
Usuario
Asesor Comercial
Asesor Financiero
Gerente
Comercial
Asesor de Control
Asesor de Trámite Documentario de Calidad
Administrador de
Asesor Legal la Seguridad
Gerente de
Operaciones
Página | 112
3.2.2. Diagrama de paquetes.
Gráfica 3.2: Diagrama de Paquetes del Sistema
Gestión Gestión de
Comercial Marketing
Gestión de
Operaciones
Gestión de Control
de Calidad
Gestión Legal
Gestión
Financiera
Gestión de Trámite Seguridad

Documentario
Página | 113
Gráfica 3.3: Casos de Uso del paquete Gestión Comercial
Usuario
(f rom Actors)
Gerente
Comercial
(f rom Actors)
<<include>> Cotizar Inmueble
Asesor Comercial
(f rom Actors)
Gestionar Equipo de Ventas Gestionar Cliente
<<extend>>
Buscar Expediente
<<extend>>
Separar Inmueble
Gestionar Actividad
Ver Detalle del Expediente
Gráfica 3.4: Casos de Uso del paquete Gestión de Trámite Documentario
Tramitar Minuta
Enviar a Notaría
Asesor de Trámite
Documentario
(f rom Actors)
Tramitar Escritura Pública
Registrar Desembolso
Página | 114
Gráfica 3.5: Casos de Uso del paquete Gestión de Control de Calidad
Entregar Acta de Entrega

Asesor de Control de Calidad
(f rom Actors)
Gráfica 3.6: Casos de Uso del paquete Gestión Financiera
Liquidar Tributos y Servicios
Gestionar Empresa
Gestionar Banco
Asesor Financiero
(f rom Actors)
Gestionar Notaría
Gestionar Forma de Pago
Gestionar Punto de Venta
Página | 115
Gráfica 3.7: Casos de Uso del paquete Gestión Legal
Tramitar Inscripción
Gestionar Apoderado
Asesor Legal
(f rom Actors)
Registrar Contrato de Separación
Registrar Acta de Entrega

Registrar Minuta
Gráfica 3.8: Casos de Uso del paquete Gestión de Operaciones
Gestionar Proyecto
Gestionar Tipo de Inmueble
Gestionar Etapa
Gerente de
Operaciones
(f rom Actors)
Gestionar Tipología
Gestionar Inmueble
Gestionar Obser vaciones
Página | 116
Gráfica 3.9: Casos de Uso del Paquete Gestión de Marketing
Gestionar Campaña
Gerente
Comercial
(f rom Actors) Gestionar Promoción
Gráfica 3.10: Casos de Uso del paquete Seguridad
<<include>>
Iniciar Sesión Cerrar Sesión
Cambiar Contraseña
Usuario
(f rom Actors)
<<extend>>
Recordar Contraseña
Gestionar Usuario
<<extend>>
Administrador de
la Seguridad Gestionar Rol Gestionar Permiso
(f rom Actors)
Página | 117
3.2.3. Casos de uso del sistema.
Gráfica 3.11: Casos de Uso del Sistema
Cerrar Sesión Cambiar Contraseña Gestionar Cliente

Gestionar Proyecto Ver Detalle del Expediente (from Seguri... (from Seguri...
Gestionar Equipo de Ventas Cotizar Inmueble
(from Ges tión Comerc ...
(from Ges tión Comerc ... (from Ges tión Comerc ... (from Ges tión Comerc ...
(from Ges tión de Operac io...
Gestionar Tipo de Inmueble Recordar Contraseña

<<include>> Gestionar Campaña
<<extend>> (from Seguri...
(from Ges tión de Mark et...
Gestionar Tipología
Iniciar Sesión
(from Seguri... Gestionar Promoción
Gerente
Comercial (from Ges tión de Mark et...
Buscar Expediente
(from Ac t...
Gestionar Etapa
Separar Inmueble
Asesor Comercial
(from Ac t...
Gerente de Usuario
Operaciones (from Ac t...
Gestionar Inmueble (from Ac t...
Gestionar Actividad Tramitar Minuta
(from Ges tión Comerc ... Asesor de Trámite
Documentario (from Ges tión de Trámite Doc umenta...
(from Ac t...
Enviar a Notaría
Registrar Contrato de Separación Gestionar Obser vaciones
(from Ges tión de Trámite Doc umenta...
(from Ges tión Le... Administrador de la Asesor de Control de Tramitar Escritura Pública Gestionar Empresa
Seguridad Calidad (from Ges tión de Trámite Doc umenta... (from Ges tión Financ i...
(from Ac t... (from Ac t...
Registrar Minuta Gestionar Usuario

(from Ges tión Le... Registrar Desembolso
Asesor Legal (from Seguri...
Entregar Acta de Entrega (from Ges tión de Trámite Doc umenta...
(from Ac t...
(from Ges tión de Control de Cali...
Gestionar Rol
(from Seguri...
Asesor Financiero
Registrar Acta de Entrega
(from Ac t...
(from Ges tión Le... Liquidar Tributos y Servicios
(from Ges tión Financ i...
Gestionar Apoderado Gestionar Banco
Tramitar Inscripción (from Ges tión Le... <<include>> (from Ges tión Financ i...
(from Ges tión Le...
Gestionar Forma de Pago Gestionar Punto de Venta Gestionar Notaría

(from Ges tión Financ i... (from Ges tión Financ i...
Gestionar Permiso (from Ges tión Financ i...
(from Seguri...
Página | 118
3.2.4. Matriz CUN vs CUS
Cuadro 3.2: Matriz Casos de Uso del Negocio vs Casos de Uso del Sistema
CUN CUS Nº
Cotizar Inmueble 1
Gestionar Proyecto 2
Gestionar Tipo de Inmueble 3
Gestionar Tipología 4
Gestionar Etapa 5
Gestionar Inmueble 6
Cotizar Inmueble Gestionar Forma de Pago 7
Gestionar Observación 8
Gestionar Empresa 9
Gestionar Banco 10
Gestionar Punto de Venta 11
Ver detalle del Expediente 12
Gestionar Actividad 13
Separar Inmueble 14
Separar Inmueble
Gestionar Apoderado 15
Gestionar Cliente Gestionar Cliente 16
Gestionar Equipo de Ventas Gestionar Equipo de Ventas 17
Gestionar Promoción Gestionar Promoción 18
Gestionar Campaña Gestionar Campaña 19
Tramitar Minuta Tramitar Minuta 20
Gestionar Notaría 21
Enviar a Notaría
Enviar a Notaría 22
Tramitar Escritura Pública Tramitar Escritura Pública 23
Registrar Desembolso Registrar Desembolso 24
Liquidar Tributos y Servicios Liquidar Tributos y Servicios 25
Registrar Contrato de Separación Registrar Contrato de Separación 26
Registrar Minuta Registrar Minuta 27
Registrar Acta de Entrega 28
Entregar Acta de Entrega Entregar Acta de Entrega 29
Tramitar Inscripción Tramitar Inscripción 30
Iniciar Sesión 31
Cerrar Sesión 32
Modificar Contraseña 33
Seguridad Recordar Contraseña 34
Gestionar Rol 35
Gestionar Permiso 36
Gestionar Usuario 37
Página | 119
3.2.5. Lista de CUS por procesos
Cuadro 3.3: Lista de los CUS por procesos
PROCESO CUS Nº
Cotizar Inmueble CUS 01
Gestionar Cliente CUS 02
Gestión Comercial Separar Inmueble CUS 03
Ver detalle del Expediente CUS 04
Gestionar Equipo de Ventas CUS 05
Gestionar Promoción CUS 06
Gestión de Marketing
Gestionar Campaña CUS 07
Tramitar Minuta CUS 08
Gestión de Trámite
Enviar a Notaría CUS 09
Inmobiliario
Tramitar Escritura Pública CUS 10
Registrar Contrato de Separación CUS 11
Registrar Minuta CUS 12
Gestión Legal Registrar Acta de Entrega CUS 13
Tramitar Inscripción CUS 14
Gestionar Apoderado CUS 15
Gestionar Empresa CUS 16
Gestionar Banco CUS 17
Gestionar Punto de Venta CUS 18
Gestión Financiera Gestionar Notaría CUS 19
Gestionar Forma de Pago CUS 20
Registrar Desembolso CUS 21
Liquidar Tributos y Servicios CUS 22
Gestión de Control de Calidad Entregar Acta de Entrega CUS 23
Gestionar Proyecto CUS 24
Gestionar Tipo de Inmueble CUS 25
Gestionar Tipología CUS 26
Gestión de Operaciones
Gestionar Etapa CUS 27
Gestionar Inmueble CUS 28
Gestionar Observación CUS 29
Gestionar Actividad CUS 30
Iniciar Sesión CUS 31
Cerrar Sesión CUS 32
Todos los Procesos Modificar Contraseña CUS 33
Involucrados Recordar Contraseña CUS 34
Gestionar Rol CUS 35
Gestionar Permiso CUS 36
Gestionar Usuario CUS 37
Página | 120
3.3. Especificaciones de los Casos de Uso del Sistema más
significativos
3.3.1 Especificación del Caso de Uso del Sistema: “Cotizar Inmueble”
Cuadro 3.4: ECUS “Cotizar Inmueble”
Nombre de Caso de
Cotizar Inmueble
Uso
Tipo Primario.
Actores Asesor Comercial.
Breve Descripción En este caso de uso se realiza la cotización de un inmueble.
Flujo Básico:
1. El caso de uso inicia cuando una persona se acerca a un
Punto de Venta para solicitar información sobre uno o
más inmuebles de su interés.
2. El Asesor Comercial verifica en el sistema si ya ha
visitado la Empresa Inmobiliaria anteriormente. Si tiene
un historial de visitas, se le hace un seguimiento de
visitas (Ejecuta CUS Gestionar Actividad), de lo
contrario el asesor comercial le mostrará la información
requerida en el sistema, asociado a cada inmueble, le
mostrará las promociones existentes y las formas de
pago posibles para cada caso; además de una galería de
fotos, el mapa (con la posición exacta del inmueble), un
video (visita guiada), un plano y la información general
del proyecto. (Ejecuta CUS “Ver Inmueble”)
3. El asesor comercial define el(los) inmueble(s) del
Flujo de Eventos
cliente, el número de cuenta asociado al proyecto, la
forma de pago, la promoción y le solicita sus datos
personales. (Ejecuta CUS “Gestionar Cliente”) y
registra la cotización
4. El sistema guarda la información ingresada por el asesor
comercial y muestra el detalle de la cotización en
HTML, con la opción de ser generado en PDF. Si el
cliente así lo prefiere se imprime la cotización de lo
contrario finaliza el caso de uso
Flujo Alternativo:
1. En el paso 2 si tiene un historial de visitas, se revisa la
agenda y las actividades relacionadas al cliente, además
se verifica su inmueble de interés, y se le consulta si
continúa interesado en ese (esos) inmueble(s) o si desea
que le mostremos información sobre otro(s)
inmueble(s).
Requerimientos El tiempo de respuesta del sistema no debe exceder de 6
Especiales segundos.
Página | 121
- El usuario debe iniciar sesión para utilizar el sistema
Pre – Condiciones - El usuario debe contar con los permisos respectivos
para acceder a estas funcionalidades.
Post - Condiciones El sistema registra una nueva cotización.
Gráfica 3.12: Prototipo CUS “Cotizar Inmueble” – Ver Inmueble – Inmuebles disponibles
Gráfica 3.13: Prototipo CUS “Cotizar Inmueble”
Página | 122
Gráfica 3.14: Prototipo CUS “Imprimir Cotización en PDF”
Página | 123
3.3.2 Especificación del Caso de Uso del Sistema: “Gestionar Cliente”
Cuadro 3.5: ECUS “Gestionar Cliente”
Nombre de Caso de
Analizar Cliente
Uso
Tipo Primario.
Este caso de uso realiza el análisis de la oportunidad con cada
Breve Descripción
cliente.
Flujo Básico:
1. El caso de uso inicia cuando el asesor comercial decide

gestionar un cliente, el asesor comercial seleccionar la
opción “Gestionar Clientes”.
2. El sistema lista los clientes registrados en el sistema, con las
opciones para registrar un nuevo cliente, actualizar/
eliminar los datos de un cliente ya registrado.
3. El asesor comercial registra los datos de un nuevo cliente y
elige la opción guardar.
4. El sistema guarda la información ingresada.
Flujo Alternativo:
Flujo de Eventos
1. En el paso 2 si el asesor comercial decide actualizar los
datos del cliente, el sistema le muestra el formulario con los
datos del cliente para que él los pueda modificar. El asesor
comercial modifica la información y elige la opción
guardar. Finalmente el sistema guarda los cambios
realizados.
2. En el paso 2 si el asesor comercial decide eliminar el

registro de un cliente, el sistema le muestra el formulario
con los datos del cliente y la opción eliminar. El asesor
comercial modifica la información y elige la opción
guardar. Finalmente el sistema guarda los cambios
realizados.

Pre – Condiciones - El usuario debe contar con los permisos respectivos para
acceder a esta funcionalidad.
Post - Condiciones El sistema registra/actualizar o elimina los datos del cliente.
Página | 124
Gráfica 3.15 Prototipo CUS “Gestionar Cliente” – Lista
Página | 125
Gráfica 3.16 Prototipo CUS “Gestionar Cliente” – Registrar/Actualizar Cliente
Página | 126
3.3.3 Especificación del Caso de Uso del Sistema: “Separar Inmueble”
Cuadro 3.6: ECUS “Separar Inmueble”
Nombre de Caso de Uso Separar Inmueble

Tipo Primario.
Breve Descripción Este caso de uso realiza la separación de un inmueble.
Flujo Básico:
1. Este caso de uso inicia cuando el asesor comercial,
decide registrar un pago por el concepto de separación.
2. El sistema le muestra el formulario para registrar la
separación.
3. El asesor comercial completa el formulario con los datos
del pago realizado por el cliente por concepto de una
separación y elige la opción guardar.
4. El sistema verifica si el pago igual al monto mínimo de
separación y guarda la información registrada.
5. Si el pago de la separación ha sido completado, el sistema
muestra la opción para generar, el modelo de contrato de
separación único, el anexo A (Cuadro de Acabados) el
Anexo B.
Flujo de Eventos 6. El asesor comercial genera en formato .doc el contrato de
separación, realiza el seguimiento correspondiente para
la firma del contrato de separación.
7. El sistema muestra el formulario para Adjuntar el
Contrato de Separación.
8. El asesor comercial escanea el contrato correctamente
firmado y elige la opción “Adjuntar Contrato de
Separación”.
9. El sistema guarda la información registrada en el
expediente.
Flujo Alternativo:
1. En el punto 4 en el caso de que no haya completado con
los pagos realizados del monto mínimo de separación, el
asesor comercial puede registrar otros pagos en la opción
“Registrar Pago”
Pre – Condiciones - El usuario debe contar con los permisos respectivos para
acceder a esta funcionalidad.
- El sistema registra uno o más pagos
- El sistema genera el contrato de separación.
Post - Condiciones
- El sistema anexa al expediente el escáner del contrato de
separación con las firmas completas.
Página | 127
Gráfica 3.17: Prototipo CUS “Separar Inmueble” – Registrar Pago
Gráfica 3.18: Prototipo CUS “Separar Inmueble” – Generar Contrato de Separación
Página | 128
Gráfica 3.19: Prototipo CUS “Separar Inmueble” – Adjuntar Contrato de Separación
3.3.4 Especificación del Caso de Uso del Sistema: “Gestionar Inmueble”

Cuadro 3.7: ECUS “Gestionar Inmueble”
Nombre de Caso de Uso Gestionar Inmueble

Tipo Primario.
Actores Gerente de Operaciones
Breve Descripción Este caso de uso brinda la funcionalidad de registrar,
actualizar, eliminar y ver un inmueble.
Flujo de Eventos Flujo Básico:
1. Este caso de uso inicia cuando el Gerente de
Operaciones selecciona la opción “Gestionar
Inmueble”.
2. El sistema muestra la pantalla correspondiente a la
gestión de inmuebles.
3. El gerente de operaciones escoge la opción
“Registrar”.
4. El sistema le muestra la pantalla correspondiente al
registro de un nuevo inmueble.
5. El gerente de operaciones registra los datos generales
como: estado, etapa, modelo, tipo, bloque, número,
precio, CUH, monto mínimo de separación, piso,
descripción, área de terreno, área construida y luego
elige la opción “Guardar”.
Página | 129
6. El sistema guarda la información registrada.
Flujo Alternativo:
1. En el punto 3 el gerente de operaciones tiene otras
opciones como “Actualizar”, “Eliminar” y “Ver
detalle”.
2. En la opción “Actualizar”, sigue los mismos pasos del
flujo básico, con la única diferencia de que el sistema
le carga los datos pertenecientes al registro del
inmueble.
3. En la opción “Eliminar”, el sistema le muestra el
detalle del inmueble, con la opción “Eliminar”, si el
gerente de operaciones elige esta opción, el registro
del inmueble se elimina.
4. En la opción “Ver detalle” el gerente de operaciones
puede ver el detalle del inmueble seleccionado.
Requerimientos El tiempo de respuesta del sistema no debe exceder de
Especiales 6 segundos.
Pre – Condiciones - El usuario debe iniciar sesión para utilizar el sistema
- El usuario debe contar con los permisos respectivos
para acceder a esta funcionalidad.
Post - Condiciones - El sistema registra, actualiza, elimina o muestra el
detalle de un inmueble.
Gráfica 3.20: Prototipo CUS “Gestionar Inmueble”
Página | 130
3.4. Especificaciones de los Casos de Uso del Sistema Restantes
Ver Anexo 2: Especificaciones de Casos de Uso del Negocio
3.5. Modelo Conceptual del Sistema

3.5.1. Diccionario de Clases: Ver Anexo 3
3.5.2. Diagrama del Modelo Conceptual
Gráfica 3.21: Diagrama del Modelo Conceptual
observacion galeria_foto 1 0..* foto

campaña 0..* 1 empresa etapa
1
0..* 0..*
1 0..* 1
proyecto_cuenta 0..* 1 ifi 1 0..* ifi_tasa
situacion_campaña
geoposicion
1 0..* 1 1
1 0..*
1
inm ueble_modelo proyecto
1..*
0..* 1
1..* proyecto_forma_pago 1 1..* forma_pago
1 1
1
0..*
0..*
pais 1 0..* region 1 0..* ciudad 1 0..* distrito inm ueble 0..* 1 inm ueble_tipo pventa cotizacion_detalle
prom ocion
1 1..*
1..* 1 0..*
1
1 0..*
0..* 0..*
comision 1
actividad_tipo 0..* 0..* actividad 0..* 1 cliente 1
cotizacion
1..* creacion_expediente
0..* 1 1
grupo_de_agentes 1
recordar
0..*
1 1 1 proyecto_contrato
separacion 0..*
1 1
1 1..* 1 1 1 1
1 1 1
grupo_de_venta 1 0..* agente 1 1 usuario 1 1..*
expediente 0..* pago
1 pagos_x_separacion
1 1
0..* 1 1 1 1
1..* 0..* 1
0..* 1 1
minuta 0..* 1 proyecto_minuta
metas_m odelo 1 1
faq 1
1 1
rol 1
0..*
1..* persona desembolso
0..*
1 0..* 1
1
meta 1 1
area envio_a_notaria 0..* 1 notaria
0..*
1 1
0..* recurso
agente_cargo tramite_inscripcion escritura_publica
1 1 1
persona_natural liquidacion_tys
Fuente: Elaboración Propia. entrega_acta_entrega 0..* 1 proyecto_acta
Página | 131
CAPÍTULO IV: ARQUITECTURA
4.1. Descripción de la Arquitectura.

En este capítulo se detallará los aspectos relacionados a la estructura general del sistema, la
organización de componentes y relaciones entre ellos, los requerimientos que debe satisfacer el
sistema y las restricciones a las que está sujeto, así como las propiedades no funcionales del
sistema y su impacto sobre la calidad del mismo, las reglas y decisiones del diseño que
gobiernan esta estructura y los argumentos que justifican las decisiones tomadas.
Es muy complejo capturar la arquitectura software en un sólo modelo (o diagrama). Para manejar esta
complejidad se representan diferentes aspectos y características de la arquitectura en múltiples vistas.
Una vista es “una presentación de un modelo, la cual es una descripción completa de un sistema desde
una particular perspectiva”. El modelo más aceptado a la hora de establecer las vistas necesarias para
describir una arquitectura software es el modelo 4+1 conocida como 4+1 View.84.
Gráfica 4.1: Modelo de vista de la arquitectura “4+1”
Fuente:
Krutchen,
1995, p 42-50
Este modelo define 5 vistas:
1. Vista de Casos de Uso: Es la vista que muestra la funcionalidad del sistema percibida por
actores externos
84
KRUTCHEN, 1995
Página | 132
2. Vista Lógica: Una vista que muestra cómo la funcionalidad es diseñada dentro del sistema
en términos de la estructura estática del sistema y comportamiento dinámico
3. Vista de Componentes o Implementación: Una vista que muestra la organización de los
componentes de código
4. Vista de Concurrencia o Procesos: Una vista que muestra las concurrencias en el sistema
y encamina los problemas de comunicación y sincronización que están presentes en un
sistema de concurrencias.
5. Vista de Despliegue o Implantación: Una vista que muestra la implementación del sistema
como una estructura física con computadoras y dispositivos llamados nodos.
El capítulo de arquitectura de Software tiene como principal finalidad proveer una vista de la
arquitectura del sistema CRM SGI, proponiendo la estructura de alto nivel del sistema y sus
propiedades globales. Para ello emplea una serie de vistas arquitectónicas, la cual servirá para
representar los diferentes aspectos del sistema.
El patrón del estilo arquitectónico del Sistema CRM SIG es el MVC (Modelo Vista
Controlador), se llegó a él debido a que hemos desarrollado un sistema web y el patrón MVC
es a menudo un patrón utilizado en aplicaciones web; es decir es un patrón o modelo de
abstracción de desarrollo de software que separa los datos de una aplicación, la interfaz de
usuario, y la lógica de negocio en tres componentes distintos. El patrón de llamada y retorno
MVC, se ve frecuentemente en aplicaciones web, donde la vista es la página HTML y el código
que provee de datos dinámicos a la página, el modelo es el Sistema de Gestión de Base de Datos
y la Lógica de negocio, y el controlador es el responsable de recibir los eventos de entrada desde
la vista. Este patrón se aplicó utilizando un framework MVC del lenguaje PHP llamado Zend
Framework, con la versión 1.10.
Entre los mecanismos arquitectónicos usados podemos mencionar 3:
1. Mecanismo de Persistencia: Mecanismo que permite manejar la persistencia de la data, para

ello se utiliza las consultas de las clases modelo para asegurar el ingreso consistente de la
data.
2. Mecanismo de Seguridad: Mecanismo que permite manejar la seguridad de la data, para
ello se validarán los permisos existentes por cada rol del sistema, los usuarios tendrán
acceso sólo a los recursos asociados a su rol.
3. Mecanismo de Gráficos: Mecanismo que soporta las interfaces gráficas, para ello se ha
implementado el API de Google Charts, validado para cada uno de los gráficos con los que
cuenta el sistema CRM SGI.
La meta principal de la arquitectura del sistema es mostrar los aspectos principales que influirán
en la etapa de desarrollo, para esto se tomarán en cuenta las siguientes metas para el diseño de
la arquitectura del sistema:
Página | 133
1. Proporcionar un entendimiento más claro del sistema. Mediante diversas vistas se
explicarán las relaciones y las funcionalidades entre los componentes que lo conforman.
2. Brindar una comunicación efectiva entre las personas involucradas.
3. Proporcionar un estándar de calidad e integridad de la información mantenida. Esto,
restringiendo el acceso a la base de datos sólo a las clases que les sea delegada esa función
mediante perfiles.
4. Proporcionar una estructura flexible y tolerante al cambio.
Las restricciones que presenta el Sistema y tienen un valor significado en el proyecto son:
5. 1. El sistema CRM SGI estará basado en un sistema web.
6. 2. Todas las funcionalidades de la aplicación web, para los diferentes perfiles de usuario,
deben estar disponibles desde cualquier PC que tenga acceso a internet.
7. 3. Se utilizará la herramienta de desarrollo PHP 5 para la construcción del software.
8. 5. Se empleará el servidor de Base de Datos MySQL 5.5
9. 5. Se empleará el servidor Web Apache 2.2
10. 6. El entorno de desarrollo será sobre el sistema operativo Linux, bajo un servicio
hosteado.
Mencionadas las pautas generales de la arquitectura de software pasaremos a mostrar cada una
de las vistas del modelo 4+1.
4.2. Vista de Casos de Uso

La vista de casos de uso se ha subdividido en 8 subsistemas: Base, Ventas, Trámite
Documentario, Legal, Finanzas, Post –Venta, BI, Desistimiento.
Los casos de uso arquitectónicos seleccionados fueron:
 Gestionar Cliente
 Gestionar Inmueble
 Cotizar Inmueble
Gráfica 4.2: Diagrama de los Casos de Uso más significativos para la arquitectura
Gestionar Inmueble
Gerente de Operaciones
(from Base)
Gestionar Cliente
(from Base)
<<include>>
<<include>>
Cotizar Inmueble
Asesor Comercial
(from Ventas)
(f rom Actors)
Página | 134
4.3. Vista de Lógica
4.3.1. Diagrama de Paquetes
Gráfica 4.3: Diagrama de Paquetes
Vistas Controladores Modelos
4.3.2. Realización de Caso de Uso Análisis – Gestionar Cliente
Gráfica 4.4: Diagrama de Clases- CUA Gestionar Cliente
E_Cliente
1
0..*
: Asesor Comercial IU_Cliente C_Cliente
E_Cotización
Gráfica 4.5: Diagrama de Colaboración - CUA Gestionar Cliente - Listar
1: Ver Clientes 2: Solicitar Lista de Clientes 3: Solicitar Lista de Clientes
5: Presentar Lista Paginada 4: Devolver Registros

: : Asesor : IU_Cliente : C_Cliente : E_Cliente
Comercial
Página | 135
Descripción del diagrama de colaboración – Listar: El Asesor Comercial a través de la

interfaz de usuario IU_Cliente solicita ver la lista de clientes, la interfaz de usuario IU_Cliente
solicita a la clase controladora C_Cliente la lista de clientes del sistema, la clase controladora
se comunica con la clase entidad E_Cliente quien devuelve los registros a la clase controladora,
la clase controladora devuelve la lista de clientes a la clase IU_Cliente de forma paginada.
Gráfica 4.6: Diagrama de Colaboración - CUA Gestionar Cliente – Registrar
2: Validar Datos 3: Registrar Cliente

1: Registrar Cliente
5: Presentar Mensaje de Éxito 4: Confirmar Registro

: : Asesor Comercial : IU_Cliente : C_Cliente : E_Cliente
Descripción del diagrama de colaboración – Registrar: El Asesor Comercial a través de la

interfaz de usuario IU_Cliente ingresa los datos del cliente, la lista de argumento y selecciona
la opción “Guardar”, el sistema a través de la interfaz de usuario, invoca a la clase controladora
C_Cliente que valida los datos ingresados verificando que el DNI del cliente no se repita y que
los parámetros sean correctos, una vez que los datos hayan sido validados, invoca a la clase
entidad E_Cliente y registra el cliente, la clase entidad E_Cliente confirma el registro y la clase
controladora solicita confirmar la operación a la interfaz IU_Cliente.
Gráfica 4.7: Diagrama de Colaboración - CUA Gestionar Cliente – Actualizar

1: Actualizar Cliente 2: Validar Datos 3: Actualizar Cliente
5: Presentar Connfirmación de la Oparación 4: Confirmar Actualización

: : Asesor Comercial : IU_Cliente : C_Cliente : E_Cliente
Descripción del diagrama de colaboración – Actualizar: El Asesor Comercial a través de la

interfaz de usuario IU_Cliente actualiza los datos del cliente, la lista de argumento y selecciona
la opción “Guardar”, el sistema a través de la interfaz de usuario, invoca a la clase controladora
C_Cliente que valida los datos ingresados y que los parámetros sean correctos, una vez que los
datos hayan sido validados, invoca a la clase entidad E_Cliente y actualiza los datos del registro
del cliente, la clase entidad E_Cliente confirma la actualización y la clase controladora solicita
confirmar la operación a la interfaz IU_Cliente.
Página | 136
Gráfica 4.8: Diagrama de Colaboración - CUA Gestionar Cliente – Eliminar
3: Obtener cotizaciones asociadas

1: Eliminar Cliente 2: Eliminar Cliente
4: Devolver Cotizaciones : E_Cotización

7: Presentar mensaje de éxito
: : Asesor Comercial : IU_Cliente : C_Cliente 5: Eliminar Cliente
6: Confirmar Eliminación
: E_Cliente
Descripción del diagrama de colaboración – Eliminar: El Asesor Comercial a través de la

interfaz de usuario IU_Cliente selecciona la opción “Eliminar”, el sistema a través de la interfaz
de usuario, invoca a la clase controladora C_Cliente que verifica que el cliente no tenga
cotizaciones asociadas consultándole a la clase entidad E_Cotización, la clase E_Cotización
devuelve las cotizaciones asociadas al cliente, en caso de que no hayan registros asociados
solicita a la clase entidad E_Cliente elimina el cliente, la clase E_Cliente confirma la
eliminación a la clase controladora, quien solicita presentar la confirmación al usuario a través
de un mensaje a la clase IU_Cliente.
Gráfica 4.9: Diagrama de Colaboración - CUA Gestionar Cliente – Ver Detalle
: E_Cliente
3: Solicitar información del cliente
4: Devolver información
1: Ver Detalle del Cliente 2: Obtener información del cliente
5: Solicitar expedientes
7: Mostrar Detalle del Cliente

: : Asesor Comercial : IU_Cliente : C_Cliente
6: Devolver Información
: E_Cotización
Descripción del diagrama de colaboración – Ver Detalle: El Asesor Comercial a través de

la interfaz de usuario IU_Cliente solicita ver el detalle del cliente, el sistema a través de la
interfaz de usuario, invoca a la clase controladora C_Cliente invoca a la entidad E_Cliente
Página | 137
solicitándole la información del cliente, la entidad E_Cliente devuelve dicha información, luego
la controladora C_Cliente solicita a la entidad E_Cotización las cotizaciones relacionadas con
el cliente, la entidad E_ Cotización devuelve la información de las cotizaciones relacionadas al
cliente a la clase controladora C_Cliente, quien muestra el detalle del Cliente a través de un
mensaje a la clase IU_Cliente.
Realización de Caso de Uso Análisis – Gestionar Inmueble
Gráfica 4.10: Diagrama de Clases- CUA Gestionar Inmueble
1 E_Proyecto
1
0..*
0..*
0..* 1
0..*
E_Inmueble E_Etapa 1
0..*
0..* 0..*
0..*
1 0..*
:Gerente de Operaciones IU_Inmueble C_Inmueble
0..*
1 E_Bloque
1
E_Cotización
E_Tipologia E_TipoInmueble
Gráfica 4.11: Diagrama de Colaboración - CUA Gestionar Inmueble – Listar

1: Ver Inmuebles 2: Solicitar Lista de Inmuebles 3: Solicitar Lista de Inmuebles

: :Gerente de Operaciones : IU_Inmueble : C_Inmueble : E_Inmueble
Descripción del diagrama de colaboración – Listar: El Gerente de Operaciones a través de

la interfaz de usuario IU_Inmueble solicita ver la lista de inmuebles, la interfaz de usuario
IU_Inmueble solicita a la clase controladora C_Inmueble la lista de inmuebles del sistema, la
clase controladora se comunica con la clase entidad E_Inmueble quien devuelve los registros a
Página | 138
la clase controladora, la clase controladora devuelve la lista de inmuebles a la clase
IU_Inmueble de forma paginada.
Gráfica 4.12: Diagrama de Colaboración - CUA Gestionar Inmueble – Registrar
: E_Proyecto : E_Etapa
3: Solicitar Proyectos 4: Devolver Proyectos

6: Devolver Etapas
5: Solicitar Etapas
7: Solicitar Bloques : E_Bloque

2: Solicitar Información 8: Devolver Bloques
1: Registrar Inmueble 13: Registrar Inmueble 9: Solicitar Tipos de Inmuebles
16: Presentar mensaje de éxito 10: Devolver Tipos de Inmuebles

: :Gerente de Operaciones : IU_Inmueble : C_Inmueble : E_TipoInmueble
14: Registrar Inmueble 11: Solicitar Tipologias
15: Confirmar Registro

12: Devolver Tipologías
: E_Tipologia
: E_Inmueble
Descripción del diagrama de colaboración – Registrar: El Gerente de Operaciones a través

de la interfaz de usuario IU_Inmueble ingresa los datos del inmueble y solicita la información
necesaria para registrar un inmueble, solicita los proyectos a la entidad E_Proyecto que
devuelve la lista de proyectos, solicita las Etapas a la entidad E_Etapa que devuelve la lista de
etapas, solicita la lista de bloques a la entidad E_Bloque que devuelve la lista de bloques,
solicita la lista de tipos de inmuebles a la entidad E_TipoInmueble que devuelve la lista de tipos
de inmuebles, solicita la lista de tipologías a la entidad E_Tipología que devuelve la lista de
tipologías, luego selecciona la opción “Guardar”, el sistema a través de la interfaz de usuario,
invoca a la clase controladora C_Inmueble que valida los datos ingresados verificando que el
que los parámetros sean correctos, una vez que los datos hayan sido validados, invoca a la clase
entidad E_Inmueble y registra el inmueble, la clase entidad E_Inmueble confirma el registro y
la clase controladora solicita confirmar la operación a la interfaz IU_Inmueble.
Página | 139
Gráfica 4.13: Diagrama de Colaboración - CUA Gestionar Inmueble – Actualizar
: E_Proyecto
: E_Etapa
4: Confirmar Proyecto
3: Validar Proyecto 6: Confirmar Etapa
: :Gerente de Operaciones : E_Bloque

5: Validar Etapa
7: Validar Bloque 8: Confirmar Bloque
1: Actualizar Inmueble
2: Validar Datos 9: Validar Tipo de Inmueble
15: Presentar confirmación de la actualización del inmueble 10: Confirmar Tipo de Inmueble
: IU_Inmueble : C_Inmueble : E_TipoInmueble
13: Actualizar Inmueble 11: Validar Tipología

14: Confirmar Actualización
12: Confirmar Tipología
: E_Inmueble
: E_Tipologia
Descripción del diagrama de colaboración – Actualizar: El Gerente de Operaciones a través

de la interfaz de usuario IU_Inmueble actualiza los datos del inmueble, y selecciona la opción
“Guardar”, el sistema a través de la interfaz de usuario, invoca a la clase controladora
C_Inmueble que valida los datos ingresados y que los parámetros sean correctos, valida el
proyecto con la entidad E_Proyecto quien confirma los datos del proyecto, valida la etapa con
la entidad E_Etapa quien confirma los datos de la etapa, valida los datos del bloque con la
entidad E_Bloque quien confirma los datos del bloque, valida los datos del tipo de inmueble
con la entidad E_TipoInmueble quien confirma los datos del tipo de inmueble, valida los datos
de la tipología con la entidad E_Tipología quien conforma los datos de la tipología; una vez
que los datos hayan sido validados, invoca a la clase entidad E_Inmueble y actualiza los datos
del registro del inmueble, la clase entidad E_Inmueble quien confirma la actualización y la clase
controladora solicita confirmar la operación a la interfaz IU_Inmueble.
Página | 140
Gráfica 4.14: Diagrama de Colaboración - CUA Gestionar Inmueble – Eliminar
3: Obtener cotizaciones asociadas

: E_Cotización
4: Devolver Cotizaciones
1: Eliminar Inmueble 2: Eliminar Inmueble
7: Presentar mensaje de éxito

: :Gerente de Operaciones : IU_Inmueble : C_Inmueble 5: Eliminar Inmueble
6: Confirmar Eliminación
: E_Inmueble
Descripción del diagrama de colaboración – Eliminar: El Gerente de Operaciones a través

de la interfaz de usuario IU_Inmueble selecciona la opción “Eliminar”, el sistema a través de
la interfaz de usuario, invoca a la clase controladora C_Inmueble que verifica que el inmueble
no tenga cotizaciones asociadas consultándole a la clase entidad E_Cotización, la clase
E_Cotización devuelve las cotizaciones asociadas al inmueble, en caso de que no hayan
registros asociados solicita a la clase entidad E_Inmueble elimina el cliente, la clase
E_Inmueble confirma la eliminación a la clase controladora, quien solicita presentar la
confirmación al usuario a través de un mensaje a la clase IU_Inmueble.
Gráfica 4.15: Diagrama de Colaboración - CUA Gestionar Inmueble – Ver Detalle
3: Solicitar información del proyecto

: E_Proyecto
1: Ver Detalle del Inmueble 2: Obtener información del inmueble
5: Solicitar información del inmueble

7: mostrar detalle del inmueble
: :Gerente de Operaciones : IU_Inmueble : C_Inmueble
: E_Inmueble
Descripción del diagrama de colaboración – Ver Detalle: El Gerente de Operaciones a través

de la interfaz de usuario IU_Inmueble solicita ver el detalle del inmueble, el sistema a través de
la interfaz de usuario, invoca a la clase controladora C_Inmueble invoca a la entidad
E_Proyecto solicitándole la información del proyecto asociado al inmueble, la entidad
Página | 141
E_proyecto devuelve dicha información, luego la controladora C_Inmueble solicita a la entidad
E_Inmueble la información del inmueble, la entidad E_ Inmueble devuelve la información
solicitada a la clase controladora C_Inmueble, quien muestra el detalle del Inmueble a través
de un mensaje a la clase IU_Inmueble.
4.3.3. Realización de Caso de Uso Análisis – Cotizar Inmueble
Gráfica 4.16: Diagrama de Clases- CUA Cotizar Inmueble
E_Cliente 1
1..*
E_Inmueble
0..*
0..*
:Asesor Comercial IU_Cotización C_Cotización
0..*
1
0..* E_Cotización
E_FormaPago
E_CuentaBancaria
Gráfica 4.17: Diagrama de Colaboración - CUA Cotizar Inmueble – Listar
1: Ver Cotizaciones 2: Solicitar Lista de Cotizaciones 3: Solicitar Lista de Cotizaciones

: : Asesor Comercial : IU_Cotización : C_Cotización : E_Cotización
Descripción del diagrama de colaboración – Listar: El Asesor Comercial a través de la

interfaz de usuario IU_Cotización solicita ver la lista de cotizaciones, la interfaz de usuario
IU_Cotización solicita a la clase controladora C_Cotización la lista de cotizaciones del sistema,
la clase controladora se comunica con la clase entidad E_Cotización quien devuelve los
registros a la clase controladora, la clase controladora devuelve la lista de cotizaciones a la clase
IU_Cotización de forma paginada.
Página | 142
Gráfica 4.18: Diagrama de Colaboración - CUA Cotizar Inmueble – Registrar
: E_Inmueble
: :Asesor Comercial
3: Seleccionar Inmueble 4: Confirmar Registro
1: Cotizar Inmueble
5: Seleccionar Cliente
: E_Cliente
6: Confirmar Cliente
2: Validar Datos 7: Seleccionar Cuenta Bancaria
13: Presentar Mensaje de Éxito 8: Confirmar Cuenta Bancaria

: IU_Cotización : C_Cotización : E_CuentaBancaria
11: Registrar Cotización

9: Seleccionar Forma de Pago
12: Confirmar Registro
10: Confirmar Forma de Pago
: E_Cotización : E_FormaPago
Descripción del diagrama de colaboración – Registrar: El Asesor Comercial a través de la

interfaz de usuario IU_Cotización ingresa los datos del inmueble, cliente, cuenta bancaria,
forma de pago; posteriormente solicita confirmar el inmueble a la entidad E_Inmueble que
devuelve la confirmación del registro, solicita confirmar el cliente a la entidad E_Cliente que
devuelve la confirmación del cliente, solicita confirmar la cuenta bancaria a la entidad
E_CuentaBancaria que devuelve la confirmación de la Cuenta Bancaria, solicita confirmar la
forma de pago a la entidad E_FormaPago que devuelve la confirmación del registro, solicita
confirmar el registro de la cotización a la entidad E_Cotización que devuelve la confirmación
del registro luego selecciona la opción “Guardar”, el sistema a través de la interfaz de usuario,
invoca a la clase controladora C_Cotización que confirma el registro y la clase controladora
solicita confirmar la operación a la interfaz IU_Cotización.
Gráfica 4.19: Diagrama de Colaboración - CUA Gestionar Inmueble – Ver Detalle
1: Ver detalle de la Cotización 2: Obtener información de la Cotización 3: Solicitar información de la Cotización
5: Mostrar detalle de la Cotización 4: Devolver Información

: :Asesor Comercial : IU_Cotización : C_Cotización : E_Cotización
Descripción del diagrama de colaboración – Ver Detalle: El Asesor Comercial a través de

la interfaz de usuario IU_Cotización solicita ver el detalle de la cotización, el sistema a través
de la interfaz de usuario, invoca a la clase controladora C_Cotización invoca a la entidad
Página | 143
E_Cotización solicitándole la información de la cotización, la entidad E_ Cotización devuelve
la información solicitada a la clase controladora C_Cotización, quien muestra el detalle de la
Cotización a través de un mensaje a la clase IU_Cotización.
4.4. Vista de Implementación o Componentes
4.4.1. Descripción General

El modelo de componentes es la distribución física de los componentes del sistema, en este caso
el sistema se encuentra instalado en un servidor web hosteado en la nube (altozanoventas.pe):
El código de la aplicación web se encuentra en la siguiente ruta:
 /home3/altozano /public_html/beta
La ruta del archivo público de inicio de la aplicación es:
 /public_html/beta/gestion/index.php
La carpeta /public_html/beta/application se encuentra fuera del alcance del directorio raíz de la

aplicación a fin de proteger el código fuente de cualquier tipo de intromisión o ejecución de
manera irregular. Así los permisos de las carpetas de este nivel son de nivel 755 y los archivos
de nivel superior son 775.
El archivo de configuración de la aplicación será el archivo config.ini que estará ubicado en la

ruta /beta/application/configs/config.ini y contendrá los accesos a la base de datos y otros
parámetros de configuración, como parámetros de conexión a otros servicios.
Gráfica 4.20: Diagrama de Paquetes – Dependencia de Paquetes
application zend_library
Los siguientes paquetes se encontrarán en la ruta /var/application, y como podemos apreciar el

paquete de “application” depende enteramente del paquete “zend_library”, el paquete
“application” contenderá enteramente las fuentes de la aplicación web y el paquete
“zend_library” contenderá la plataforma en las cuales nuestras clases y funciones tendrán
soporte.
Página | 144
Gráfica 4.21: Paquete “application”
views controllers models
El paquete “application” contiene las carpetas views, controller y models respectivamente, estas
carpetas ilustran que la aplicación se basa en el patrón modelo-vista-controlador, y dentro de
cada carpeta se ubicarán las clases respectivas.
4.4.2. Paquete “models” (casos de uso más significativos)

La carpeta models contiene los archivos de las clases de acceso a datos, en la clase
BaseModel.php se encuentran las funciones de conexión con la base de datos y todas las demás
clases de esta carpeta dependen de esta clase.
Gráfica 4.22: Paquete “models”
Proyecto.php Etapa.php Bloque.php Tipo.php
Inmueble.php
ClientePotencial.php
BaseModel.php
Campania.php Fpago.php
NroCuenta.php Pventa.php
Promocion.php
Cotizacion.php
Página | 145
4.4.3. Paquete “controllers” (casos de uso más significativos)
La carpeta controllers contiene archivos de las clases de control. El archivo BaseController.php

contiene todas las funciones que se reutilizan entre todas las clases de control y todas los demás
archivos de esta carpeta dependen de aquel archivo.
Gráfica 4.23: Paquete “controllers”
ProyectoController.php EtapaController.php BloqueController.php
TipoController.php
ClientepController.php
InmuebleController.php
BaseController.php
CampaniaController.php
FpagoController.php
NrocuentaController.php
PventaController.php
PromocionController.php CotizacionController.php
4.4.4. Paquete “views” (casos de uso más significativos)
La carpeta views está dividida en dos carpetas, la carpeta “helpers” y la carpeta “scripts”, en la
carpeta “helpers” se almacenan los archivos de extensión javascript, los cuales en el diseño
hacen llamadas tipo ajax.
Gráfica 4.24: Paquete “views”
helpers scripts
Página | 146
Gráfica 4.25: Paquete “views”
proyecto etapa bloque tipo
inmuebleope fpago pventa campania
clientep nrocuenta promocion cotizacion
Fuente:
Elaboración Propia
4.5. Vista de Concurrencia o procesos
4.5.1. CU –Gestionar Cliente
Gráfica 4.26: Diagrama de Clases “Gestionar Cliente”
Página | 147
Gráfica 4.27: Diagrama de Secuencia “Gestionar Cliente” - Listar
: index_view_clientep : clientepController : BD_Model_ClientePotencial

: :Asesor
Comercial
index( )
indexAction( )
getClientePLista( )
El usuario al seleccionar la opción “Clientes” del menú de Base, invoca a la clase

index_view_clientep ejecutando la función index, la función index hace una llamada a la
función indexAction de la clase ClientepController que se encarga de obtener la lista de clientes
registrados en el sistema a través de la función getClientePLista de la clase
BD_Model_ClientePotencial, una vez que la función indexAction posee los registros, los
entrega a la función indexAction de forma paginada.
Página | 148
: : : : BD_Model_Proyecto : : :
: : Asesor registrar_view_clientep ver_view_clientep clientepController BD_Model_Campania BD_Model_Pventa BD_Model_ClientePotencial
Comercial
registrar( )
registrarAction( )
getProyectoBasico( )
getAllActivas( )
getDetalle( )
guardar( )
registrarAction( )
presentarMensaje( ) registrar( )
Gráfica 4.28:Diagrama de Secuencia “Gestionar Cliente” – Registrar/ Actualizar
Página | 149
El usuario en la lista de clientes, hace clic en la opción “Registrar”, este evento ejecuta la opción
registrar de la clase registrar_view_clientep, la función hace una llamada a la función
registrarAction de la clase ClientepController el cual invoca a la clase BD_Model_Proyecto a
fin de tener la lista de los proyectos a través de la función getProyectoBasico, posteriormente
ejecuta la función getAllActivas de la clase BD_Model_Campania a fin de tener la lista de
campañas activas, luego ejecuta la función getDetalle de la clase BD_Model_Pventa a fin de
tener la lista de puntos de venta. Una vez que el formulario tiene todos los datos cargados el
usuario registra la información del cliente y elige la opción “Guardar”, este evento hace una
llamada a la función registrarAction de la clase clientepController el cual verifica los datos, si
toda la información ingresada es correcta ejecuta la función registrar de la misma clase, y
finalmente la clase ver_view_clientep presenta un mensaje de información indicando que la
operación tuvo éxito.
Gráfica 4.29: Diagrama de Secuencia “Gestionar Cliente” – Ver
: : :
ver_view_clientep clientepController BD_Model_ClientePotencial
: :Asesor
Comercial
ver( )
verAction( )
getClientePotencialDetalleById( )
Cuando el usuario elige la opción ver en la lista de clientes, ejecuta la función ver de la clase
ver_view_clientep, el cual hace una llamada a la función verAction de la clase
ClientepController, esta función realiza una llamada a la función
getClientePotencialDetalleById de la clase BD_Model_ClientePotencial que devuelve el
detalle del cliente por el id del mismo, una vez que la función posee el detalle del cliente, la
información es presentada a través de la clase ver_view_clientep.
Página | 150
Gráfica 4.30: Diagrama de Secuencia “Gestionar Cliente” – Eliminar
: : : : BD_Model_Cotizacion
ver_view_clientep clientepController BD_Model_ClientePotencial
: :Asesor
Comercial
ver( )
verAction( )
getClientePotencialDetalleById( )
getDetalleTotal( )
eliminar( )
El usuario cuando hace clic en la opción eliminar de un registro presentado en la lista de

clientes, ejecuta la función ver de la clase ver_view_clientep, el cual hace una llamada a la
función verAction de la clase ClientepController, esta función realiza una llamada a la función
getClientePotencialDetalleById de la clase BD_Model_ClientePotencial que devuelve el
detalle del cliente por el id del mismo(con un mensaje de alerta si el cliente no se puede
eliminar), por la elección de la opción eliminar la clase clientepController envía una variable
eliminar con el valor 1, con esta confirmación una vez que la función posee el detalle del cliente,
la clase clientepController verifica si el cliente posee cotización a través de la función
getDetalleTotal de la clase BD_Model_Cotización, si no posee cotizaciones la clase
clientepController ejecuta la función eliminar y el registro del cliente queda eliminado.
Página | 151
4.5.2. CU –Gestionar Inmueble
Gráfica 4.31: Diagrama de Clases “Gestionar Inmueble”
Página | 152
Gráfica 4.32: Diagrama de Secuencia “Gestionar Inmueble” - Listar
: : : BD_Model_Proyecto :
: :Gerente de
index_view_inmuebleope InmuebleopeController BD_Model_Inmueble
Operaciones
index( )
indexAction( )
itemsXPagina( )
getIndexTotal( )
El usuario al seleccionar la opción “Inmuebles” del menú de Base, invoca a la clase

index_view_inmuebleope, esta función hace una llamada a la función indexAction
de la clase clientepController que se encarga de obtener la lista de proyectos en el
sistema a través de la función getProyectoBasico de la clase BD_Model_Proyecto,
luego la clase de control InmuebleopeController ejecuta la función itemsXPagina
y la función getIndexTotal , una vez que la función indexAction posee los registros,
los entrega a la función index de forma paginada.
Página | 153
: : : : BD_Model_Proyecto : : : : BD_Model_Modelo :
: :Gerente de
registrar_view_inmuebleope ver_view_inmuebleope InmuebleopeController BD_Model_Etapa BD_Model_Bloque BD_Model_Tipo BD_Model_Inmueble
Operaciones
registrar( )
registrarAction( )
getAll( )
getAll( )
getDetalle( )
getDetalle( )
guardar( )
registrarAction( )
registrar( )
presentarMensaje( )
Gráfica 4.33: Diagrama de Secuencia “Gestionar Inmueble” – Registrar/ Actualizar
Página | 154
El usuario en la lista de inmuebles, hace clic en la opción “Registrar”, este evento ejecuta la
opción registrar de la clase registrar_view_inmuebleope, la función hace una llamada a la
función registrarAction de la clase InmuebleopeController el cual invoca a la clase
BD_Model_Proyecto a fin de tener la lista de los proyectos a través de la función
getProyectoBasico, posteriormente ejecuta la función getAll de la clase BD_Model_Etapa a fin
de tener la lista de etapas, luego ejecuta la función getAll de la clase BD_Model_Bloque a fin
de tener la lista de bloques, posteriormente ejecuta la función getDetalle de la clase
BD_Model_Tipo a fin de tener la lista de tipos de inmuebles, luego ejecuta la función getDetalle
de la clase BD_Model_Modelo a fin de tener la lista de modelos o tipologías. El usuario ingresa
los datos correspondientes al inmueble y hace clic en el botón “Guardar”, si toda la información
ingresada es correcta se ejecuta la función registrarAction de la clase inmuebleopeController y
finalmente la clase controladora presenta un mensaje de información a la clase
ver_view_clientep indicando que la operación tuvo éxito.
Gráfica 4.34: Diagrama de Secuencia “Gestionar Inmueble” – Ver
: : :
: :Gerente de
ver_view_inmuebleope InmuebleopeController BD_Model_Inmueble
Operaciones
ver( )
verAction( )
getDetalleById( )
El usuario cuando hace clic en la opción ver de un registro presentado en la lista de inmuebles,
ejecuta el evento ver de la clase ver_view_inmuebleope, el cual hace una llamada a la función
verAction de la clase InmuebleopeController, esta función realiza una llamada a la función
getDetalleById de la clase BD_Model_Inmueble que devuelve el detalle del inmueble por el id
Página | 155
del mismo, una vez que la función posee el detalle del inmueble, la información es presentada
a través de la clase ver_view_inmuebleope.
Página | 156
Gráfica 4.35: Diagrama de Secuencia “Gestionar Inmueble” – Eliminar
: : :
: :Gerente de ver_view_inmuebleope InmuebleopeController BD_Model_Inmueble
Operaciones
ver( )
verAction( )
getDetalleById( )
eliminar( )
presentarMensaje( )
El usuario cuando hace click en la opción eliminar de un registro presentado en la lista de

inmuebles, ejecuta la función ver de la clase ver_view_clientep, el cual hace una llamada a la
función verAction de la clase InmuebleopeController, esta función realiza una llamada a la
función getDetalleById de la clase BD_Model_Inmueble que devuelve el detalle del Inmueble
por el id del mismo, por la elección de la opción eliminar la clase InmuebleopeController envío
una variable eliminar con el valor 1, con esta confirmación una vez que la función posee el
detalle del cliente, la clase InmuebleopeController verifica si el estado del inmueble es
“SEPARADO” o “VENDIDO”, en estos casos el muestra un mensaje de alerta indicando que
no se puede eliminar el inmueble, en caso contrario si procede a la eliminación del inmueble,
de esta manera la clase InmuebleopeController ejecuta la función eliminar y el registro del
cliente queda eliminado, finalmente la clase InmuebleopeController muestra el mensaje de
confirmación de la eliminación en la clase ver_view_inmuebleope.
Página | 157
4.5.3. CU – Cotizar Inmueble
Gráfica 4.36: Diagrama de Clases “Cotizar Inmueble”
Página | 158
Gráfica 4.37: Diagrama de Secuencia “Cotizar Inmueble” - Listar
: : : BD_Model_Cotizacion
: :Asesor
index_view_cotizacion CotizacionController
Comercial
index( )
indexAction( )
getDetalleCoti( )
getDetalleCotiTotal( )
El usuario al seleccionar la opción “Ver Cotizaciones” del menú de Ventas, invoca a la clase
index_view_cotizacion, esta función hace una llamada a la función indexAction de la clase
CotizacionController que se encarga de obtener la lista de cotizaciones en el sistema a través
de la función getDetalleCoti de la clase BD_Model_Cotizacion, luego misma clase ejecuta la
función getDetalleCotiTotal que obtiene el total de cotizaciones, una vez que la función
indexAction posee los registros, los entrega a la función index de forma paginada.
Página | 159
: : ver_view_cotizacion : : : : : : BD_Model_Promocion : BD_Model_Fpago : BD_Model_Cotizacion
: :Asesor registrar_view_cotizacion CotizacionController BD_Model_Inmueble BD_Model_ClientePotencial BD_Model_NroCuenta BD_Model_Observacion
Comercial
registrar( )
registrarAction( )
getDetalleById( )
getClientePotencial( )
getCuenta( )
getObservacionxProyecto( )
getPromocionxProyecto( )
getAll( )
guardar( )
registrarAction( )
presentarMensaje( ) registrar( )
Gráfica 4.38: Diagrama de Secuencia “Cotizar Inmueble” – Registrar
Página | 160
El usuario selecciona la opción “Cotizar” de la lista de los inmuebles (caso de uso “Gestionar
Inmueble”), la función registrar de la clase registrar_view_cotizacion invoca a la función
registrarAction de la clase CotizaciónController, esta clase hace una llamada a la función
getDetalleById de la clase BD_Model_Inmueble (con el objetivo de asociar a la cotización el
(los) inmueble(s) de interés), la misma clase controladora invoca a la función
getClientePotencial de la clase BD_Model_ClientePotencial que se encarga de obtener la lista
de clientes de manera que el asesor comercial pueda asociar la cotización a un determinado
cliente, también la clase controladora invoca a la función getCuenta de la clase
BD_Model_NroCuenta para asociar la cotización a un determinado número de cuenta, también
la clase controladora invoca a la función getObservacionxProyecto de la clase
BD_Model_Observacion, para asociar las observaciones a la cotización; luego la clase
controladora invoca a la función getAll de la clase BD_Model_Promocion para obtener las
promociones y poder asociarlas a la cotización en caso de que el asesor comercial lo vea por
conveniente. Al obtener el formulario completo el usuario registra todos los datos
correspondientes a la cotización, el usuario elige la opción “Guardar”, el sistema a través de la
función registrarAction de la clase CotizacionController, finalmente la clase controladora
ejecuta la función registrar de la clase BD_Model_Cotizacion, luego la clase de control
CotizacionController presenta el mensaje de la confirmación del registro a la clase
ver_view_cotizacion.
Gráfica 4.39: Diagrama de Secuencia “Cotizar Inmueble” - Ver
: ver_view_cotizacion : : BD_Model_Cotizacion
: :Asesor
CotizacionController
Comercial
ver( )
verAction( )
getDetalleById( )
Página | 161
El usuario al seleccionar la opción “Ver Detalle” del la lista de Cotizaciones, invoca a la función
ver de la clase ver_view_cotizacion, esta función hace una llamada a la función verAction de
la clase CotizacionController que se encarga de obtener el detalle de la cotización de interés a
través de la función getDetalleById de la clase BD_Model_Cotizacion, finalmente la clase de
control CotizacionController presenta el detalle de la Cotización.
4.5.4. Modelo de Datos: Diagrama de modelo de datos: Ver Anexo 4
4.5.5. Modelo de Datos: Definición de las Tablas: Ver Anexo 5
4.5.6. Modelo de despliegue
Gráfica 4.40: Modelo de Despliegue
SERVIDOR DE BD
Lima Usuario SERVIDOR WEB
INTERNET
Arequipa Usuario
FIREWALL
Puerto Maldonado Usuario
Tacna Usuario
Página | 162
CAPÍTULO V: DESARROLLO Y PRUEBAS
5.1. Desarrollo.
5.1.1. Plataforma tecnológica.

Software de Desarrollo
Para el desarrollo de la solución software se utilizó la siguiente plataforma tecnológica:
Aptana Studio 3: Aptana es un sencillo pero completo entorno de desarrollo especializado en

programación de aplicaciones dinámicas para web. Aptana Studio 3 aprovecha la flexibilidad
de Eclipse y se centra en un motor de desarrollo web de gran alcance. Aptana Studio 3 amplía
las capacidades para crear, editar y previsualizar y depurar sitos web HTML, CSS y JavaScript
con PHP y Ruby.
Entre otras características de la herramienta, destacan:
- Ayuda en código HTML, CSS y JavaScript.
- Depurador integrado que permite establecer puntos de ruptura, inspeccionar variables,

ejecución y control.
- Un terminal integrado permite acceder rápidamente a un terminal de línea de comandos para

ejecutar instrucciones del sistema operativo y utilidades de idioma.
- Entorno de desarrollo configurable como se desee con posibilidad de ampliación de las

capacidades básicas.
Framework
La aplicación web se basó en el Framework de ZEND 1.10 que posee las librerías necesarias
donde la aplicación web estará soportada en PHP 5.
Así mismo se utilizó el framework en javascript de Google Maps versión 2 que poseen las
funciones necesarias para presentar información geográfica en el mapa de Google y Google
Página | 163
Chart versión 1 que posee las funciones necesarias para presentar los reportes de Business
Intelligence.
Patrones
Zend Framework promueve el uso del patrón Modelo Vista Controlador, por lo tanto para la
programación utilizaremos el patrón MVC.
5.1.2 Descripción de los estándares de desarrollo.

A. Lenguaje de Programación
Se utilizó PHP 5.2.17
Definición de Proyectos y clases
Se estandarizaron los nombres de las clases para así sea más fácil el acceso a ellos:
 Formulario de lista:
</carpeta de la entidad>index.phtml
 Formulario de registro, o actualización de la entidad:
</carpeta de la entidad>registrar.phtml
 Formulario de la vista del detalle o la eliminación de la entidad:
</carpeta de la entidad>ver.phtml
La aplicación se estructuró bajo el patrón MVC, Modelo Vista Controlador:
1. Clases de modelo de BD
2. Clases de control
Página | 164
3. Clases de vistas
Cada subsistema tiene su subcarpeta propia dentro conservando el patrón MVC:
4. Las clases de modelo dentro de la carpeta “models”

5. Las clases de control dentro de la carpeta “controllers”
6. Clases de vistas están dentro de la carpeta “views”
B. Base De Datos
Se utilizara la versión MySQL 5.5.29
La Base de Datos se nombrará “altozano_ventas”
Tablas:
Los nombres de las tablas estarán en minúsculas y en caso de ser compuesto por dos palabras
se utilizarán el guión bajo “_”.
StoredProcedures:
2 dígitos indicando “sp”, separado del carácter “_”, luego vendrá el nombre (todo en
minúsculas), en caso de ser un nombre compuesto, serán separados igualmente del carácter “_”.
Ejemplo: sp_<nombre_del_storedprocedure>
Vistas:
2 dígitos indicando “v”, separado del carácter “_”, luego vendrá el nombre (todo en minúscula),
en caso de ser un nombre compuesto, serán separados igualmente del carácter “_”. Ejemplo:
vw_<Nombre_de_Vista>
5.2. Pruebas: Plan de Pruebas
5.2.1. Introducción
El propósito del presente plan fue establecer y documentar la planificación de las pruebas a
realizar para comprobar el buen funcionamiento del sistema y de la estrategia a utilizar para su
ejecución, definiendo los casos de prueba correspondientes.
Este documento fue dirigido a todo el equipo de desarrollo y al Gerente del proyecto.
Página | 165
5.2.2. Alcance
El presente documento se aplicó al momento de realizar las pruebas en el proceso de
construcción de software.
5.2.3. Referencias
El presente documento tomó como referencia y base la arquitectura del software.
5.2.4. Requerimientos de Pruebas

En las siguientes secciones se identifican los requerimientos que fueron probados.
A. Pruebas Funcionales
La siguiente lista de requerimientos fueron probados:
 Registrar Cliente
 Editar Cliente
 Eliminar Cliente
 Registrar Inmueble
 Editar Inmueble
 Eliminar Inmueble
 Cotizar Inmueble
B. Pruebas de Seguridad
Para las pruebas de seguridad se tuvo que verificar el control de la identificación exclusiva para los
usuarios registrados en el sistema de acuerdo a los permisos del rol que se le asignaron.
C. Pruebas de Requisitos Tecnológicos

Para las pruebas de requisitos tecnológicos se verificó el correcto funcionamiento del sistema
utilizando los navegadores:
 Internet Explorer desde la versión 8.
 Mozilla Firefox desde la versión 3.6.
 Google Chrome desde la versión 5.
 Opera desde la versión 10
 Safari desde la versión 3.
Página | 166
5.2.5. Tipos de Pruebas
A continuación se presentan los tipos de pruebas utilizados para la validación de la solución.
A. Pruebas de Casos de Uso

Una vez realizadas las pruebas unitarias y de integración, se efectuaron las pruebas de casos de
uso, las cuales permitieron verificar la correcta implementación de los flujos básico y
alternativos de todos los casos de uso presentes en la solución. Después de realizar estas pruebas
se pasó a las pruebas de aceptación.
B. Pruebas de Integración
Permiten probar la combinación de diferentes partes del sistema con el objetivo de determinar
si funcionan correctamente integradas. Luego de realizar las pruebas unitarias sobre los
componentes individuales, las pruebas de integración permiten probar el buen funcionamiento
del sistema cuando existe una transferencia de datos entre los componentes. A pesar de probar
la correcta interacción entre los componentes, para brindar un diagnóstico general del sistema
se necesitan las pruebas de casos de uso.
C. Pruebas de Aceptación
Pruebas realizadas por el usuario final con el objetivo de validar que el sistema cumpla con el
funcionamiento esperado. Estas pruebas son las últimas en realizarse y marcan el fin de la fase
de pruebas de sistema.
5.2.6. Características a Probar

A continuación se presentan las características generales que se buscaron probar:
 El sistema debe ser confiable, es decir no debe permitir el ingreso o registro de datos
inconsistentes con la lógica de negocio.
 El sistema debe presentar claridad al usuario, es decir debe mostrar mensajes de

confirmación, error y éxito cuando sea necesario.
 El sistema debe restringir el uso de funcionalidades de acuerdo a los permisos y roles de los
usuarios.
 El sistema debe cumplir correctamente con las funcionalidades descritas en los casos de
uso.
Página | 167
 El sistema debe utilizar las bondades del Ajax y el Javascript para que las operaciones sean
sencillas e intuitivas, evitando al usuario el problema de la recarga de página tras cada
operación.
5.2.7. Características que no se Prueban

A continuación se presentan las características que no se pretendieron probar:
 Tiempos de respuesta mínimo y máximo para la aplicación, se asume que las condiciones
de red son las adecuadas para que los tiempos de respuesta sean los adecuados.
 Performance del sistema durante periodos de sobrecarga de la red, ya sea por una gran
cantidad de visitantes o por problemas en la red.
5.2.8. Responsabilidades de Casos de Prueba

El sistema fue probado por los usuarios de las siguientes áreas: Ventas, Trámite Documentario,
Legal, Sistemas y la Gerencia General de la Empresa Constructora Inmobiliaria. Las pruebas
fueron realizadas independientemente por cada área.
5.2.9. Secuencia de Pruebas

Se aprovechó el esquema elaborado tanto para la fase de pruebas como para el ciclo de
desarrollo del producto, siguiendo un esquema evolutivo.
5.2.10. Casos de Prueba
5.2.10.1. Registrar Cliente

IDENTIFICADOR PCU POSITIVA REGISTRAR CLIENTE
Nombre de la Prueba Escenario Positivo para el Registro del Cliente
Objetivo Probar que se creará con éxito el cliente si es que se ingresa: DNI (con
caracteres numéricos de longitud de 8 dígitos), nombres, apellido
paterno, apellido materno, sexo, estado civil (soltero), ingreso familiar
(con caracteres numéricos y sin coma), celular, correo (si tiene y una
dirección electrónica correcta), país: selección de la lista de los países,
región: selección de la lista de las regiones de acuerdo al país
seleccionado, provincia de la lista de las provincias de acuerdo a la
región seleccionada, distrito de la lista de distritos de acuerdo a la
provincia seleccionada, se entero por de acuerdo a la lista de las
campañas de la empresa y los proyectos de interés de acuerdo a la lista
de proyectos, el punto de venta de afiliación de acuerdo a la lista de
puntos de venta; para todos los campos en los que se debe ingresar
mediante teclado los campos deben de tener longitud y formato correcto.
Inicialización Que el usuario registrado tenga los permisos para registrar un cliente.
Se podrá cotizar un inmueble asociado al cliente registrado en la base

Finalización
de datos.
Acciones Se debe ingresar los campos:
Página | 168
- DNI: 43997867
- Nombres: Maria Isabel
- Apellido Paterno: Caldas
- Apellido Materno: Egoávil
- Sexo: Femenino
- Estado Civil: Soltera
- Ingreso Familiar: 3000
- Celular: 978675645
- Correo: mcaldas@gmail.com
- País: Perú
- Región: Arequipa
- Provincia: Arequipa
- Distrito: Arequipa
- Dirección: Av. Del ejercito 1565
- Se entero por: América Televisión
- Proyecto de Interés: EL MIRADOR DE LA ALAMEDA
- Punto de Venta de Afiliación: CASETA DE VENTAS -
ALAMEDA SALAVERRY
Resultados Esperados Mensaje de confirmación del registro del cliente.
Resultados Reales Ventana con los datos ingresados para el registro del cliente.
IDENTIFICADOR PCU NEGATIVA REGISTRAR CLIENTE

Nombre de la Prueba Escenario Negativo para el Registro del Cliente
Probar que no se creará con éxito el cliente si es que se ingresa: DNI
(con caracteres numéricos de longitud de 8 dígitos), nombres: vacío,
apellido paterno, apellido materno, sexo: vacío, estado civil (soltero),
ingreso familiar (con caracteres numéricos y sin coma), celular, correo
(si tiene y una dirección electrónica correcta):vacío, país: selección de
la lista de los países, región: selección de la lista de las regiones de
Objetivo acuerdo al país seleccionado, provincia de la lista de las provincias de
acuerdo a la región seleccionada, distrito de la lista de distritos de
acuerdo a la provincia seleccionada, se entero por de acuerdo a la lista
de las campañas de la empresa y los proyectos de interés de acuerdo a
la lista de proyectos, el punto de venta de afiliación de acuerdo a la lista
de puntos de venta; para todos los campos en los que se debe ingresar
Finalización No se registrará el cliente ni se almacenará en la base de datos.
Se debe ingresar los campos:
- DNI: 43997867
- Nombres: vacío
- Apellido Paterno: Caldas
- Apellido Materno: Egoávil
- Sexo: vacío
- Estado Civil: Soltera
Acciones
- Celular: 978675645
- Correo: vacío
- País: Perú
- Región: Arequipa
- Dirección: Av. Del ejercito 1565
- Se entero por: América Televisión
Página | 169
ALAMEDA SALAVERRY
Mensaje de error que indica que no se han ingresado todos los campos
Resultados Esperados
obligatorios.
Ventana con los datos del cliente y el mensaje de error que indica que
Resultados Reales
no se han ingresado todos los campos obligatorios.
5.2.10.2. Actualizar Cliente

IDENTIFICADOR PCU POSITIVA ACTUALIZAR CLIENTE
Nombre de la Prueba Escenario Positivo para la Actualización del Cliente
Objetivo Probar que se actualizará con éxito los datos del cliente si es que se
ingresa: DNI (con caracteres numéricos de longitud de 8 dígitos),
nombres, apellido paterno, apellido materno, sexo, estado civil (soltero),
ingreso familiar (con caracteres numéricos y sin coma), celular, correo
(si tiene y una dirección electrónica correcta), país: selección de la lista
de los países, región: selección de la lista de las regiones de acuerdo al
país seleccionado, provincia de la lista de las provincias de acuerdo a la
región seleccionada, distrito de la lista de distritos de acuerdo a la
provincia seleccionada, se entero por de acuerdo a la lista de las
campañas de la empresa y los proyectos de interés de acuerdo a la lista
de proyectos, el punto de venta de afiliación de acuerdo a la lista de
puntos de venta; para todos los campos en los que se debe ingresar
Inicialización Que el usuario registrado tenga los permisos para actualizar un cliente.
Finalización Se podrá cotizar un inmueble asociado al cliente cuyos datos han sido
actualizados en la base de datos.
- DNI: 43878899
- Nombres: Luis Alberto
- Apellido Paterno: Luján
- Apellido Materno: Arellano
- Sexo: Masculino
- Estado Civil: Soltero
- Celular: 978675633
- Correo: lujanarellano@gmail.com
- País: Perú
- Región: Arequipa
- Dirección: Av. La Merced 156
- Se entero por: Banco Interbank
ALAMEDA SALAVERRY
Resultados Esperados Mensaje de confirmación de la actualización de los datos del cliente.
Resultados Reales Ventana con los datos del cliente.
IDENTIFICADOR PCU NEGATIVA ACTUALIZAR CLIENTE

Nombre de la Prueba Escenario Negativo para la Actualización del Cliente
Objetivo Probar que se actualizará con éxito los datos del cliente si es que se
ingresa: DNI (con caracteres numéricos de longitud de 8 dígitos),
nombres: vacío, apellido paterno, apellido materno, sexo, estado civil
(soltero):vacío, ingreso familiar (con caracteres numéricos y sin coma),
Página | 170
celular: vacío, correo (si tiene y una dirección electrónica correcta),
país: selección de la lista de los países, región: selección de la lista de
las regiones de acuerdo al país seleccionado, provincia de la lista de las
provincias de acuerdo a la región seleccionada, distrito de la lista de
distritos de acuerdo a la provincia seleccionada, se entero por de acuerdo
a la lista de las campañas de la empresa y los proyectos de interés de
acuerdo a la lista de proyectos, el punto de venta de afiliación de acuerdo
a la lista de puntos de venta; para todos los campos en los que se debe
ingresar mediante teclado los campos deben de tener longitud y formato
correcto.
Inicialización Que el usuario registrado tenga los permisos para actualizar un cliente.
Finalización Los datos del cliente no han sido actualizados en la base de datos.
- DNI: 43878899
- Nombres: vacío
- Apellido Paterno: Luján
- Apellido Materno: Arellano
- Sexo: Masculino
- Estado Civil: vacío
- Celular: vacío
- Correo: lujanarellano@gmail.com
- País: Perú
- Región: Arequipa
- Dirección: Av. La Merced 156
- Se entero por: Banco Interbank
- Punto de Venta de Afiliación: CASETA DE VENTAS - ALAMEDA
SALAVERRY
Resultados Esperados Mensaje de error que indica que no se han actualizado todos los campos
obligatorios.
Resultados Reales Ventana con los datos del cliente y el mensaje de error que indica que
no se han actualizado todos los campos obligatorios.
5.2.10.3. Eliminar Cliente

IDENTIFICADOR PCU POSITIVA ELIMINAR CLIENTE
Nombre de la Prueba Escenario Positivo para la Eliminación del Cliente
Probar que se eliminará con éxito el cliente si luego de elegir la opción
Objetivo eliminar debido a que el cliente en mención no se encuentra asociado a
una cotización o a algún expediente, el sistema nos permite eliminarlo.
Inicialización Que el usuario registrado tenga los permisos para eliminar un cliente.
Finalización El cliente quedará eliminado del sistema.
Se debe seleccionar un cliente que no este asociado a una cotización a
Acciones
algún expediente.
Resultados Esperados Mensaje de confirmación de eliminación.
Resultados Reales Ventana con los datos del cliente.
IDENTIFICADOR PCU NEGATIVA ELIMINAR CLIENTE

Nombre de la Prueba Escenario Negativo para la Eliminación del Cliente
Página | 171
Probar que no se eliminará con éxito el cliente si luego de elegir la
opción eliminar debido a que el cliente en mención se encuentra
Objetivo
asociado a una cotización o a algún expediente, el sistema no nos
permite eliminarlo.
Inicialización Que el usuario registrado tenga los permisos para eliminar un cliente.
Finalización El cliente no quedará eliminado del sistema.
Se debe seleccionar un cliente que este asociado a una cotización a
Acciones
algún expediente.
Mensaje de error que indica que no puede eliminar el cliente debido a
que está asociado a una cotización a un expediente.
Ventana con los datos del cliente y el mensaje de error que indica que
Resultados Reales no se ha eliminado al cliente debido a que está asociado a una cotización
a un expediente.
5.2.10.4. Registrar Inmueble
IDENTIFICADOR PCU POSITIVA REGISTRAR INMUEBLE

Nombre de la Prueba Escenario Positivo para el Registro de un Inmueble
Probar que se registrará con éxito el inmueble si es que luego de
seleccionar el proyecto al que pertenece el inmueble a registrar se ingresa:
estado: de la lista de estados, la etapa: de la lista de etapas del proyecto,
bloque de la lista de bloques del proyecto, tipo de inmueble: de la lista de
Objetivo
tipos de inmuebles, tipología de la lista de tipologías del proyecto, piso,
número, precio, monto mínimo de separación.; para todos los campos en
los que se debe ingresar mediante teclado los campos deben de tener
longitud y formato correcto.
Inicialización Que el usuario registrado tenga los permisos para registrar un inmueble.
Se podrá cotizar un inmueble asociado al inmueble registrado en la base
Finalización
de datos.
- Proyecto: EL MIRADOR DE LA ALAMEDA
- Estado: DISPONIBLE
- Etapa: 1
- Bloque/Manzana: 2
Acciones
- Tipo de Inmueble: DEPARTAMENTO FLAT
- Tipología: 7
- Piso: 2
- Número/Lote: 203
- Precio: 197300
- Monto de Separación: 2500
Resultados Esperados Mensaje de confirmación del registro del inmueble.
Resultados Reales Ventana con los datos ingresados para el registro del inmueble.
IDENTIFICADOR PCU NEGATIVA REGISTRAR INMUEBLE

Nombre de la Prueba Escenario Negativo para el Registro del Inmueble
Probar que no se registrará con éxito el inmueble si es que se ingresa:
estado (vacío): de la lista de estados, la etapa: de la lista de etapas del
proyecto, bloque de la lista de bloques del proyecto, tipo de inmueble: de
Objetivo la lista de tipos de inmuebles, tipología de la lista de tipologías del
proyecto, piso, número (vacío), precio, monto mínimo de separación
(vacío); para todos los campos en los que se debe ingresar mediante
teclado los campos deben de tener longitud y formato correcto.; para todos
Página | 172
los campos en los que se debe ingresar mediante teclado los campos deben
de tener longitud y formato correcto.
Finalización No se registrará el inmueble ni se almacenará en la base de datos.
- Estado: vacío
- Etapa: 1
- Bloque/Manzana: 2
Acciones - Tipo de Inmueble: DEPARTAMENTO FLAT
- Tipología: 7
- Piso: 2
- Número/Lote: vacío
- Precio: 197300
- Monto de Separación: vacío
Mensaje de error que indica que no se han ingresado todos los campos
obligatorios.
Ventana con los datos del inmueble y el mensaje de error que indica que
Resultados Reales
no se han ingresado todos los campos obligatorios.
5.2.10.5. Actualizar Inmueble

IDENTIFICADOR PCU POSITIVA ACTUALIZAR INMUEBLE
Nombre de la Prueba Escenario Positivo para la Actualización del Inmueble
Probar que se actualizará con éxito los datos del inmueble si es que se
ingresa: estado: de la lista de estados, la etapa: de la lista de etapas del
proyecto, bloque de la lista de bloques del proyecto, tipo de inmueble: de
Objetivo la lista de tipos de inmuebles, tipología de la lista de tipologías del
proyecto, piso, número, precio, monto mínimo de separación; para todos
los campos en los que se debe ingresar mediante teclado los campos deben
Inicialización Que el usuario registrado tenga los permisos para actualizar un inmueble.
Finalización Los datos del inmueble serán actualizados en la base de datos.
- Estado: DISPONIBLE
- Etapa: 1
- Bloque/Manzana: 5
- Tipología: 7
- Piso: 4
- Número/Lote: 404
- Precio: 197300
- Monto de Separación: 2500
Resultados Esperados Mensaje de confirmación de la actualización de los datos del inmueble.
Resultados Reales Ventana con los datos del inmueble.
IDENTIFICADOR PCU NEGATIVA ACTUALIZAR INMUEBLE

Nombre de la Prueba Escenario Negativo para la Actualización del Inmueble
Probar que no se actualizará con éxito los datos del inmueble si es que se
ingresa: estado: de la lista de estados, la etapa (vacío): de la lista de etapas
Objetivo del proyecto, bloque de la lista de bloques del proyecto, tipo de inmueble:
de la lista de tipos de inmuebles, tipología de la lista de tipologías del
proyecto, piso, número, precio (vacío), monto mínimo de separación
Página | 173
(vacío); para todos los campos en los que se debe ingresar mediante
teclado los campos deben de tener longitud y formato correcto.
Inicialización Que el usuario registrado tenga los permisos para actualizar un inmueble.
Finalización Los datos del inmueble no serán actualizados en la base de datos
- Estado: vacío
- Etapa: 1
- Bloque/Manzana: 5
- Tipología: 5
- Piso: 4
- Número/Lote: vacío
- Precio: vacío
- Monto de Separación: vacío
Mensaje de error que indica que no se ha podido registrar la actualización
Resultados Esperados de los datos del inmueble debido a que no se han registrado todos los
campos obligatorios.
Resultados Reales no se ha podido registrar la actualización de los datos del inmueble,
debido a que no se han registrado todos los campos obligatorios.
5.2.10.6. Eliminar Inmuebles
IDENTIFICADOR PCU POSITIVA ELIMINAR INMUEBLE

Nombre de la Prueba Escenario Positivo para la Eliminación del Inmueble
Objetivo Probar que se eliminará con éxito el inmueble si luego de elegir la opción
eliminar debido a que el inmueble en mención no se encuentra asociado a
una cotización o a algún expediente, el sistema nos permite eliminarlo.
Inicialización Que el usuario registrado tenga los permisos para eliminar un inmueble.
Finalización El inmueble quedará eliminado del sistema.
Acciones Se debe seleccionar un inmueble que no esté asociado a una cotización a
algún expediente.
Resultados Esperados Mensaje de confirmación de eliminación.
Resultados Reales Ventana con los datos del inmueble.
IDENTIFICADOR PCU NEGATIVA ELIMINAR INMUEBLE

Nombre de la Prueba Escenario Negativo para la Eliminación del Inmueble
Probar que no se eliminará con éxito el inmueble si luego de elegir la
opción eliminar debido a que el inmueble en mención se encuentra
Objetivo
asociado a una cotización o a algún expediente, el sistema no nos permite
eliminarlo.
Inicialización Que el usuario registrado tenga los permisos para eliminar un inmueble.
Finalización El inmueble no quedará eliminado del sistema.
Se debe seleccionar un inmueble que este asociado a una cotización a
Acciones
algún expediente.
Mensaje de error que indica que no puede eliminar el inmueble debido a
que está asociado a una cotización a un expediente.
Resultados Reales no puede eliminar el inmueble debido a que está asociado a una cotización
a un expediente.
5.2.10.7. Cotizar Inmueble

IDENTIFICADOR PCU POSITIVA COTIZAR INMUEBLE
Página | 174
Nombre de la Prueba Escenario Positivo para la Cotización de un Inmueble
Probar que se registrará con éxito la cotización si es que luego de
seleccionar el proyecto al que pertenece el inmueble que se desea cotizar
se ingresa: cliente: por una búsqueda en la lista de clientes de la base de
datos, interés del cliente: de la lista de interés del cliente, número de
Objetivo
servicio de pago activo: de la lista de números de servicio de pago activo
y forma de pago: de la lista de formas de pago; para todos los campos en
los que se debe ingresar mediante teclado los campos deben de tener
longitud y formato correcto.
Inicialización Que el usuario registrado tenga los permisos para registrar una cotización.
Finalización Se podrá registrar una cotización y su detalle en la base de datos.
- Cuenta Cliente: MARIA ISABEL CALDAS EGOÁVIL
Acciones
- Interés del Cliente: Muy Interesado
- Nro. de Servicio de Pago Activo: INTERBANK NRO. 10-052-01
SOLES
- Forma de pago: Calificación Directa INTERBANK
Resultados Esperados Mensaje de confirmación del registro de la cotización.
Resultados Reales Ventana con los datos ingresados de la cotización.
IDENTIFICADOR PCU NEGATIVA COTIZAR INMUEBLE

Nombre de la Prueba Escenario Negativo para la Cotización de un Inmueble
Probar que no se registrará con éxito la cotización si es que luego de
seleccionar el proyecto al que pertenece el inmueble que se desea cotizar
se ingresa: cliente (vacío): por una búsqueda en la lista de clientes de la
base de datos, interés del cliente: de la lista de interés del cliente, número
Objetivo
de servicio de pago activo (vacío): de la lista de números de servicio de
pago activo y forma de pago: de la lista de formas de pago; para todos los
campos en los que se debe ingresar mediante teclado los campos deben
Inicialización Que el usuario registrado tenga los permisos para registrar una cotización.
Finalización No se podrá registrar una cotización y su detalle en la base de datos.
- Cuenta Cliente: vacío
Acciones
- Interés del Cliente: Muy Interesado
- Nro. de Servicio de Pago Activo: vacío
- Forma de pago: Calificación Directa INTERBANK
Mensaje de error que indica que no se puede registrar la cotización porque
no se han indicado los campos obligatorios.
Ventana con los datos de la cotización con el mensaje de error que indica
Resultados Reales
que no se puede registrar la cotización.
5.2.11. Pruebas de Integración
5.2.11.1. Primera Integración
Página | 175
La primera integración tuvo como objetivo el desarrollar los mantenimientos de las clases
fundamentales del sistema. En esta integración se implementaron los siguientes casos de uso.
Nombre del Caso de Uso Módulo

Gestionar Proyecto Base
Gestionar Etapa Base
Gestionar Bloque Base
Gestionar Tipología Base
Gestionar Tipo de Inmueble Base
Gestionar Inmuebles Base
Gestionar Clientes Base
Gestionar Equipo de Ventas Base
Gestionar Promociones Base
Gestionar Tipo de Campañas Base
Gestionar Situación de Campañas Base
Gestionar Campañas Base
Gestionar Faqs Base
Gestionar Metas Base
Gestionar Razones Sociales Base
Gestionar Bancos Base
Gestionar Notarias Base
Gestionar Puntos de Venta Base
Gestionar Cuentas Bancarias Base
Gestionar Formas de Pago Base
Gestionar Agencias Bancarias Base
Gestionar Rango de Fechas Base
Gestionar Apoderados Base
Gestionar Observaciones Base
5.2.11.2. Segunda Integración

La segunda integración tuvo como objetivo el desarrollar el registro de una de las transacciones
más importantes del sistema. En esta integración se implementarán el caso de uso Cotizar
Inmueble, además de los casos de uso implementados en la integración previa:

Cotizar Inmueble Ventas
5.2.11.3. Tercera Integración

La tercera integración tuvo como objetivo el desarrollar el registro de la separación. En esta
integración se implementó el caso de uso Separar Inmueble, además de los casos de uso
implementados en integraciones previas:
Página | 176
Separar Inmueble Ventas
5.2.11.4. Cuarta Integración

La cuarta integración tuvo como objetivo el desarrollar el registro del proceso completo de
venta. En esta integración se implementaron los siguientes casos de uso, además de los casos
de uso implementados en integraciones previas:

Registrar Cuota Inicial Trámite Documentario
Registrar Pagos de la Cuota Inicial Trámite Documentario
Generar Minuta Trámite Documentario
Registrar Firmas de Minuta Trámite Documentario
Escanear Minuta Trámite Documentario
Registrar Envío a Banco Trámite Documentario
Registrar Envío a Notaría Trámite Documentario
Registrar Firmas de Escritura Pública Trámite Documentario
Registrar Desembolso Trámite Documentario
Registrar Liquidación de Tributos y Finanzas
Servicios
Generar Acta de Entrega Post – Venta
Escanear Acta de Entrega Post – Venta
Registrar Trámite de Inscripción Legal
Registrar Desistimiento Desistimiento
Liberar Inmueble Desistimiento
Registrar Devolución Legal
5.2.11.5. Quinta Integración

La quinta integración tuvo como objetivo el desarrollar los reportes, además de los casos de uso
implementados en integraciones previas:
Nombre del Reporte Reportes

Reporte de Cotizaciones Reportes
Reporte de Expedientes Reportes
Reporte de Fecha de Fases Reportes
Reporte de Rango de Fechas Reportes
Pipeline de Ventas Reportes
Cotizaciones por asesor Reportes
Performance de Ventas Reportes
Ventas por asesor Reportes
Benchmarking de Cotizaciones Reportes
Benchmarking de Ventas Reportes
Efectividad de Ventas Reportes
Producción de los Expedientes Reportes
Ingresos por mes Reportes
Página | 177
Número de Inmuebles Entregados Reportes
5.2.11.6. Sexta Integración

La sexta integración tuvo como objetivo el probar las funcionalidades más básicas del sistema,
En esta integración se implementaron los siguientes casos de uso:

Iniciar Sesión Seguridad
Cerrar Sesión Seguridad
Modificar Contraseña Seguridad
Recordar Contraseña Seguridad
Gestionar Rol Seguridad
Gestionar Permiso Seguridad
Gestionar Usuario Seguridad
5.2.12. Pruebas de Aceptación

5.2.12.1. Pruebas de la Interfaz Gráfica
Se muestra una pantalla de ejemplo en la figura 5.1. Se realizaron las siguientes tareas para
todas las pantallas del sistema (Para un mejor detalle revisar Anexo 7: Manual de Usuario):
a. Verificar que todas las pantallas del sistema tengan el mismo diseño (look and feel)
b. Verificar que la parte superior derecha (1) indique el usuario que ha iniciado sesión y su rol
en el sistema, además de la opción Salir (Salir del Sistema).
c. Verificar que la parte superior izquierda (3) contenga el logo de la Empresa Constructora
Inmobiliaria.
d. Verificar que el Menú tenga las opciones, de acuerdo a los permisos del rol.
e. Verificar que la parte inferior esté dividida verticalmente en dos secciones, con la sección
izquierda (4) conteniendo el menú de opciones y la sección derecha (2) tenga los detalles
de la operación elegida en la sección izquierda. Si hubiera demasiada información que
mostrar en una sola pantalla se utilizarán pestañas, las cuales categorizarán los datos a
mostrar.
Gráfica 5.1.: Presentación del Sistema
1
3 3
Página | 178
4 2
Página | 179
CAPÍTULO VI: GESTIÓN DEL PROYECTO
6.1. Descripción de la Gestión del Proyecto.

En el presente capítulo detallaremos el detalle del marco metodológico usado para la gestión de
proyectos, en este caso hemos aplicado los conceptos de ingeniería de software bajo el marco
del proceso del RUP, y las prácticas de gestión de proyectos estándar PMBOK.
Este marco está organizado en 4 fases, apoyados por procesos transversales de apoyo a estas
etapas y las áreas de conocimiento del marco de gestión de proyectos que propone el PMBOK,
según se muestra en el siguiente grafico:
Concepción Elaboración Construcción Transición
Gráfica 6.1: Fases del Proyecto
Gestión de Gestión de Gestión de

Gestión del Gestión de Gestión de Gestión de Gestión de
Comunicacion Recursos Tiempo y
Alcance Riesgo Calidad Incidentes Adquisiciones
es Humanos Costo
Gráfica 6.2: Gestión de Proyecto
Gráfica 6.3: Roles de la Empresa que desarrolla el software
Gerente del Proyecto Arquitecto Programador 1

Analista Administrador de la BD Programador 2
Página | 180
Gráfica 6.4: Roles de la Empresa Constructora Inmobiliaria
Gerente del Proyecto Gerente TI Usuario Final Usuario Clave
I. CONCEPCIÓN
En esta fase se realizó las definiciones iniciales del proyecto y que dieron el marco general de
todo el proyecto, la definición de las características del proyecto en términos del alcance, de los
objetivos, riesgos potenciales, asimismo se desarrolló el plan de trabajo acordado por ambas
partes, la organización del proyecto, los recursos humanos asignados y los roles de cada uno,
se acordó el marco metodológico de gestión de proyecto y los procedimientos administrativos
del mismo. Se elaboró el acta de constitución del proyecto (Project Charter) que fue la
referencia principal para ambas partes durante todo el proyecto.
Asimismo, en esta etapa se realizó la evaluación de los recursos que requiere el proyecto y
como resultado se elaboró el plan de adquisición de los recursos requeridos por el proyecto y
el sistema.
Se analizó también la Empresa Constructora Inmobiliaria, para identificar los procesos del
negocio involucrados en la solución de software, obteniendo como resultado final el modelado
del negocio y del sistema. En esta fase también se identificaron los requerimientos funcionales
y no funcionales del sistema.
II. ELABORACIÓN
El objetivo principal de esta etapa fue transformar los requerimientos a una especificación que
describa cómo implementar el sistema, para ello se elaboraron los prototipos del sistema que
dieron soporte a los procesos analizados con el fin de construir una herramienta de
comunicación importante entre los técnicos y los usuarios finales involucrados en el proyecto.
Al final de la elaboración de los prototipos se realizó un control de calidad del modelo validado
por los usuarios clave asignados al proyecto
Página | 181
El análisis fundamentalmente consistió en construir una arquitectura base que denote
integralmente las características del software, actividades propias del análisis/diseño del
sistema de la metodología RUP adaptadas al caso particular, que generaron los artefactos
correspondientes.
III. CONSTRUCCION / DESARROLLO

El objetivo principal de esta etapa fue convertir los elementos de la arquitectura de software en
elementos de implementación, dichos elementos son códigos fuentes, ejecutables, binarios,
entre otros. Otra parte de esta disciplina son las pruebas unitarias, las cuales se limitan a los
componentes de software implementados. De esta disciplina se obtuvo un sistema ejecutable
estable, constituido de los resultados producidos por los programadores.
El principal objetivo de esta fase una vez desarrollado cada módulo, fue evaluar la calidad del
producto que se está desarrollando a través de las diferentes etapas por las cuales este pasa,
mediante la aplicación de pruebas concretas para validar que las suposiciones hechas en el
diseño y los requerimientos se estén cumpliendo satisfactoriamente, esto quiere decir que se
verificó que el producto funcione como se diseñó y que los requerimientos son satisfechos
cabalmente. Esta etapa brinda soporte para encontrar y documentar (y solucionar) defectos en
la calidad del sistema a las otras etapas.
Esta disciplina de control de calidad estuvo presente en todo el ciclo de vida del desarrollo del
sistema para ir refinándolo y no solo al final del mismo.
El desarrollo de esta disciplina consistió en planificar que es lo que hay que probar, diseñar
cómo se va a llevar a cabo la prueba, implementar lo necesario para llevarlas a cabo, ejecutarlas
en los niveles necesarios y obtener los resultados, de esta manera la información obtenida sirvió
para ir refinando la solución informática.
El papel de las pruebas fue evaluar la calidad, y proporcionar una realimentación a tiempo, de
forma que los aspectos de calidad se pudieron resolver de manera efectiva en tiempo y costo.
Los principales aspectos que fueron evaluados en el producto software fueron la funcionalidad
(hace lo que debe), la fiabilidad (resistente a fallos), y el rendimiento (lleva a cabo su trabajo
de manera efectiva).
Página | 182
Las pruebas requirieron de la integración de todas las piezas del sistema a efectos de realzar las
pruebas integrales sobre el sistema funcionando de manera integral y estas fueron realizadas
por el equipo de desarrollo para hacer una primera validación y luego se realizó las pruebas de
aceptación (realizado sobre el sistema global por los usuarios clave de la Empresa Constructora
Inmobiliaria).
VI. TRANSICIÓN
Esta etapa tuvo como objetivo instalar con éxito el sistema elaborado por el equipo de desarrollo
y asegurar la disponibilidad del producto para los usuarios finales.
Se produjo una mayor intensidad de trabajo en la etapa de transición de la implementación,

debido a que su propósito era asegurar una aprobación y adaptación sin que existan dificultades
del software por parte del usuario. Esta etapa se complementó en el trabajo realizado al preparar
el camino, sobre todo con actividades relacionadas a la planificación, pero también con la
elaboración del manual de usuario.
Aunque el sistema esté bien diseñado y desarrollado correctamente su éxito dependió de su

implantación y ejecución por lo que fue importante capacitar a los usuarios finales con respecto
a su uso y mantenimiento del mismo.
6.2. Viabilidad del proyecto.

6.2.1. Viabilidad operacional.
 ¿Existe apoyo suficiente para el proyecto por parte de la administración?, ¿Y por parte de
los usuarios?
Si existe la colaboración de los interesados, tanto del área gerencial como del área operativa.
Existen personas claves en cada proceso, personas que además de brindar información de sus
actividades, muestran el interés para automatizar actividades manuales y así ahorrar tiempo,
para presentar los reportes en el momento indicado a sus superiores y en el caso de los gerentes
para tenerlos disponibles.
 Los métodos que actualmente se usan en la empresa, ¿son aceptados por los usuarios?
De alguna manera estos métodos han sido aplicados desde un inicio y fueron renovándose con
el constante crecimiento de la empresa, los requerimientos aumentaron y estos métodos de
trabajo han tenido que ser actualizados acorde al aumento de requerimientos. Actualmente se
Página | 183
utilizan herramientas y métodos manuales para realizar el proceso comercial, de allí la
necesidad de una solución.
 ¿Los usuarios han participado en la planeación y desarrollo del proyecto?, ¿Cómo lo han
hecho?
Los usuarios han participado con la iniciativa del Gerente Comercial, quien decidió hacerse
cargo del proyecto en la empresa, el convocó al personal de cada área y continuamente se
trabajo con ellos en el proceso de levantamiento de requerimientos.
 ¿El sistema propuesto causará perjuicios?
No se espera causar ningún perjuicio sino más bien beneficiar a la Empresa Constructora
Inmobiliaria y por los resultados también a sus clientes.
 ¿Producirá resultados pobres en alguna área?
No, debido a qué el área comercial, junto con el área de operaciones llevan el trabajo más arduo
en la Empresa Constructora Inmobiliaria, otras áreas se beneficiaran ya que se incrementaran
las ventas.
 ¿Se perderá control en alguna área específica?
No se perderá el control en ninguna área.
 ¿Será contraproducente la operatividad de las facilidades de captura de datos?
Al contrario, se espera obtener los resultados deseados con la colaboración del área operativa
para brindarnos la información necesaria.
 ¿La productividad de los empleados será menor después de instalado el sistema?
No, la productividad de los empleados se optimizará debido a que ahorrarán tiempo en la

elaboración de los reportes solicitados por la gerencia y al automatizarse las actividades
manuales que ellos realizan, tendrán más tiempo para dedicar a las actividades estratégicas de
la empresa.
 ¿Los clientes se verán afectados por la implantación?
Afectados de manera positiva, pues su inversión de tiempo en todo el proceso de compra del
inmueble será menor.
Página | 184
6.2.2. Viabilidad técnica.
Un Computador Pentium IV, 1Gb de RAM, Disco de 80 Gb de disco duro.
 ¿Existe o se puede adquirir la tecnología necesaria para realizar lo que se pide?
Si Existe la tecnología necesaria, programas necesarios como navegadores web, entre

otros.
 ¿Los técnicos están suficientemente entrenados o con la experiencia necesaria para adoptar
la nueva tecnología (HW, SW, Comunicaciones)?
Si, los técnicos están altamente entrenados para adaptarse al aprendizaje de la nueva
aplicación.
 ¿El equipo (HW) propuesto tiene la capacidad técnica para soportar todos los datos
requeridos para usar el nuevo sistema?
Si, en el equipo detallado se podrá acceder al sistema.
 ¿El sistema propuesto ofrecerá respuestas adecuadas a las peticiones sin importar el número
y ubicación de los usuarios?
Si ofrecerá una veloz respuesta a las peticiones del cliente.
 Si se desarrolla el sistema, ¿se puede crecer con facilidad?
Si, el sistema podrá crecer debido a la gran escalabilidad definida en la arquitectura y

los diversos patrones y buenas prácticas usadas en el desarrollo del proyecto.
 ¿Existen garantías técnicas de exactitud, confiabilidad, facilidad de acceso y seguridad de

los datos?
Si las hay, se cuenta con las características del hosting que soporta la solución
informática para brindar la seguridad esperada.
Página | 185
6.2.3. Viabilidad económica.
La duración de desarrollo del proyecto es de 25 semanas, estas se reparten en 4 etapas o fases
FASE SEMANA FECHA INICIO FECHA FIN

CONCEPCION 1 02/05/2012 15/06/2012
ELABORACIÓN 2 18/06/2012 03/08/2012
CONSTRUCCIÓN 3 06/08/2012 19/09/2012
TRANSICIÓN 4 06/09/2012 08/10/2012
Inversiones Tecnológicas
ESTACIÓN COSTO
ALQUILER DE SERVIDOR WEB S/ 230.00
Material de Oficina por mes
Descripción Costo S/.

4 Folder con palanca S/. 20.00
4 Paquetes de Hoja Bond S/.80.00
1 Memoria USB S/120.00
2 Cartuchos de Tinta Negra S/. 240.00
2 Cartuc S/. 240.00
hos de Tinta Color
Sub Total S/. 700.00
a. Beneficios tangibles
Entre los beneficios tangibles podemos destacar:
 Aumento de las ventas en un 20%
 Aumento de las utilidades en un 10% (reduciendo los gastos en tiempo, recursos humanos
y recursos).
b. Beneficios intangibles:
Entre los beneficios intangibles podemos destacar:
 Clientes fidelizados.
 Toma de decisiones oportunas, inmediatas y pertinentes.
 Promover el desarrollo y competitividad organizacional.
 Mejor ambiente entre el personal del área comercial y las áreas involucradas a ella.
Página | 186
El Análisis del VAN y del TIR se encuentran en el Anexo 6.
6.2.4. Viabilidad legal.

El sistema contémplate el cumplimiento del marco regulatorio vigente que se aplican a esta
industria.
Para ello en el sistema se ha definido los siguientes procesos debidamente validados por los
abogados de la Empresa Constructora Inmobiliaria:
1. Un proceso para la firma del contrato de separación

2. Un proceso para la firma de minutas
3. Un proceso para la firma de Escritura Pública
4. Un proceso para el registro de los pagos.
5. Un proceso de control de envío del expediente a la notaría.
6. Un proceso de verificación del trámite en registros públicos.
6.1. Organización del Proyecto.
6.1.1. Organigrama del proyecto.
Gráfica 6.1: Organigrama del Proyecto
Empresa Empresa
Constructora Desarrollador
Inmobiliaria del Software
Gerente del
Sponsor
Proyecto
Área de Área de Gestión del

Desarrollo Infraestructura Hosting
Administrador
Analista Arquitecto Desarrollador de Base de
Datos
Página | 187
6.1.2. EDT del proyecto.
CRM SGI
Sistema de Gestión
Inmobiliaria
1. Gestión del
2. Concepción 3. Elaboración 4. Consctrucción 5. Transición
Proyecto
5.1 Instalación y
1.1 Project 2.1 Mapa de 3.1 Realización de
4.1 Módulo Base configuración del
Charter Procesos los CUS
sistema
1.2 Declaración 3.2 Diseño de

2.2 Reglas de 4.2 Módulo 5.2 Manual de
del Alcance del Prototipos del
Negocio Ventas usuario
Proyecto sistema
1.3 Plan de 4.3 Módulo

2.3 Glosario de 3.3 Modelo 5.3 Manual de
Gestión del Trámite
Términos Conceptual Configuración
Alcance Documentario
2.4 Vista interna 3.4 Diseño del

4.4 Módulo 5.4 Capacitación
1.4 WBS y externa del modelo lógico y
Finanzas de personal
Negocio físico de la BD
1.5 Plan de 5.5 CD con

2.5 Realización de 3.5 Realización de
Gestión del 4.5 Módulo Legal instalador del
los CUN la BD.
Cronograma sistema
2.6 Matriz de 5.6 Acta de

1.6 Solicitud de 4.6 Módulo Post -
Actividades y aceptación de
Cambio Venta
Requerimientos instalación
2.7 Documento de
1.7 Acta de
requerimientos 4.7 Plan de
Cierre de
funcionales y no Pruebas
Poryecto
funcionales.
4.8 Resultado de
2. 8 Diagrama
pruebas de
CUS
sistema
4.9 Correcciones
y modificaciones
del sistema
Página | 188
6.2. Estimación y ejecución del proyecto.
A. Estimación de costos para los principales recursos del proyecto
Estimación del Costo de Hora Hombre
DÓLARES
SUELDO PROMEDIO $ 3000
DÍAS LABORALES 22 días
HORAS DIARIAS 8 horas
Costo Hora 17.04
Obtenemos que el costo por hora es $17 dólares americanos, considerando

que se trabaja 8 horas diarias, 22 días al mes.
A continuación detallamos los recursos del proyecto:
Nombre del Recurso Tipo Capacidad Tasa
Máxima Estándar
Gerente del Proyecto Trabajo 100% S/ 70.00
Analista / Arquitecto Trabajo 100% S/ 46.00
Administrador de BD Trabajo 100% S/ 23.00
Programador 1 Trabajo 100% S/ 23.00
Programador 2 Trabajo 100% S/ 23.00
Impresora Material S/ 350.00
Servidor Web de Material S/ 230.00
Prueba
Útiles de Oficina Material S/ 700.00
6.2.1. Estimación del Proyecto por Casos de Uso
Como parte de la metodología, el tiempo destinado a la implementación del sistema

debe estar estimado para que se puedan asignar los recursos correctamente. El
equipo de desarrollo ha hecho uso de la técnica de estimación por casos de uso, lo
cual dio un resultado de de 1562 horas-hombre de esfuerzo, asumiendo que los
integrantes del equipo son capaces de culminar con un punto de función (UCP) en
7 horas. Esta información complementa a la estimación ya que con esto se puede
determinar el tiempo de duración del proyecto, el cual es 6 meses,
aproximadamente. Para más detalle se muestra la siguiente tabla.
Página | 189
Cuadro 6.1 – Estimación del esfuerzo por caso de uso
N° Caso de Uso UAW UUCW UUCP AUCP
1 Cotizar Inmueble 5 7 12 10.8
2 Gestionar Cliente 3 3 6 4.2
3 Separar Inmueble 4 4 8 7.2
4 Ver detalle del Expediente 3 4 7 6.3
5 Gestionar Equipo de Ventas 2 2 4 0.8
6 Gestionar Promoción 2 2 4 1.2
7 Gestionar Campaña 2 2 4 1.6
8 Tramitar Minuta 3 4 7 4.2
9 Enviar a Notaría 3 2 5 2.5
10 Tramitar Escritura Pública 3 2 5 4.5
11 Registrar Contrato de 2 2 4 0.8
Separación
12 Registrar Minuta 2 2 4 0.8
13 Registrar Acta de Entrega 3 2 5 2
14 Tramitar Inscripción 3 2 5 3.5
15 Gestionar Apoderado 2 2 4 1.2
16 Gestionar Empresa 2 2 4 1.2
17 Gestionar Banco 2 2 4 1.2
18 Gestionar Punto de Venta 2 2 4 1.2
19 Gestionar Notaría 2 2 4 1.2
20 Gestionar Forma de Pago 2 2 4 1.2
21 Registrar Desembolso 3 2 5 4.5
22 Liquidar Tributos y Servicios 3 2 5 4.5
23 Entregar Acta de Entrega 3 2 5 4.5
24 Gestionar Proyecto 1 2 3 2.7
25 Gestionar Tipo de Inmueble 2 2 4 2.8
26 Gestionar Tipología 2 2 4 2.8
27 Gestionar Etapa 2 2 4 2.8
28 Gestionar Inmueble 2 2 4 2.8
29 Gestionar Observación 2 2 4 2.8
30 Gestionar Actividad 2 2 4 2.8
31 Iniciar Sesión 1 1 2 1.2
32 Cerrar Sesión 1 1 2 1.2
33 Modificar Contraseña 1 1 2 1.2
34 Recordar Contraseña 1 1 2 1.2
35 Gestionar Rol 1 2 3 2.1
36 Gestionar Permiso 1 2 3 2.1
37 Gestionar Usuario 1 2 3 2.1
TOTAL 101.7
Fuente: Elaboración propia
Página | 190
Cuadro 6.2 – Estimación del esfuerzo del proyecto
Horas x UCP 7
Esfuerzo total (horas-hombre) 711.9
Hombres-Mes 120
Número de integrantes del proyecto 3
Meses 5.9325
La metodología RUP da una visión, de acuerdo a la experiencia de diversos proyectos, de

cuánto tiempo y esfuerzo se debe destinar a cada una de las fases del RUP. Los tiempos se
muestran en la siguiente tabla, donde también se puede encontrar el tiempo estimado del
proyecto para cada una de estas fases.
Cuadro 6.3 – Distribución del esfuerzo y el tiempo según RUP
ESFUERZO 5,00 % 20,00 % 65,00 % 10,00 %
TIEMPO 12,00 % 21,00 % 50,00 % 17,00 %
Cuadro 6.4 – Distribución del esfuerzo y el tiempo del proyecto

ESFUERZO 5.085 20.34 66.105 10.17
TIEMPO 0.72 1.26 3 1.02
6.2.2. Cronograma de ejecución del proyecto: Ver Anexo 8.
6.2.3. Estimación de presupuesto.

A continuación presentamos el gráfico de la curva “S” o línea de costos
presupuestados:
CRM SGI - Sistema de Gestión Inmobiliaria Detalle Costo
Gestión del Proyecto S/ 9,274
Fase de Concepción S/9,560
CRM SGI Fase de Elaboración S/ 9,116
Fase de Construcción S/ 11,300
Fase de Transición S/ 5,149
Total CRM SGI S/ 44,399
A continuación presentamos el gráfico de la curva “S” o línea de costos estimados:
Página | 191
12000.00 S/. 11,300.00
S/. 9,274.00 S/. 9,560.00

10000.00
8000.00 S/. 9,116.00
6000.00
4000.00 S/. 5,149.00
2000.00
0.00
Gestión del Fase de Fase de Fase de Fase de
Proyecto Concepción Elaboración Construcción Transición
6.2.4. Ejecución del presupuesto.

Según lo proyectado en la gestión de presupuesto, el resumen es:
Siendo el resultado del costo propuesto del proyecto:

COSTO SOLES DÓLARES
Costo Presupuestado 44,399 17,2750
El resultado de la ejecución del proyecto es el siguiente:

CRM SGI Detalle Costo previsto
Gestión del Proyecto S/. 10,201.4
Fase de Concepción S/. 10,516
CRM SGI Fase de Elaboración S/. 10,027.6
Fase de Construcción S/. 12,430
Fase de Transición S/. 5,663.9
Total CRM SGI S/. 48,838.9
A continuación presentamos el gráfico de la curva “S” o línea de costos

ejecutados:
Página | 192
14000
12430
12000
10201.4 10516
10000
10027.6
8000
6000 5663.9
4000
2000
0
Gestión del Fase de Fase de Fase de Fase de
Proyecto Concepción Elaboración Construcción Transición
6.3. Gestión de Comunicaciones del proyecto.

La planificación de las comunicaciones (que tendrán lugar dentro del desarrollo del
proyecto) permitió asegurar la oportuna y apropiada generación, recopilación,
diseminación, almacenamiento y disposición de la información del proyecto. Proveyó
relaciones entre las personas, ideas e información necesarias para alcanzar el éxito.
Todos los involucrados en el proyecto intercambiaron comunicaciones en el “lenguaje”
del proyecto y entendiendo que las comunicaciones afectan positiva o negativamente al
proyecto.
Acta de Reunión
De acuerdo al siguiente formato:

Acta de Reunión Periódica o Mensual
Descripción Este documento fue elaborado por el Gerente del Proyecto
después de cada reunión y fue entregado por correo
electrónico a las personas que participaron en ella para sus
comentarios y observaciones.
En el que se registraban los siguientes ítems:
 Objetivo
 Agenda
 Asistencia
 Temas Tratados
 Temas Pendientes
 Acuerdos Tomados
 Firma de los Participantes
Día El día de la reunión
Periodicidad Según corresponda a la reunión
Página | 193
Para toda documentación escrita, el procedimiento a seguir para su aceptación formal es
el siguiente:
1. Enviar por correo electrónico los acuerdos (Acta de reunión)
2. Archivar el cargo generado, después de haber aceptado este cargo a Empresa
Constructora Inmobiliaria, tiene 4 días para emitir sus observaciones.
3. Formalizar la aceptación (firmas) de los documentos entregados.
4. Comunicar por correo electrónico la aceptación total de los documentos, de lo
contrario se considera aprobado, en caso posteriormente se requiera implementar
observaciones no entregadas en el plazo acordado se contemplaran dentro de la
Gestión de Cambios.
Correo Electrónico
El uso del correo electrónico se dió en todas las fases del proyecto y servió sólo como
medio facilitador de la comunicación generada por el proyecto.
Documentación del Proyecto
Toda información generada durante el desarrollo del proyecto fue comunicada por el
Gerente del Proyecto de la empresa que implementa el software y enviada al Gerente de
Proyecto de la Empresa Constructora Inmobiliaria.
Ambos interesados tendrán la responsabilidad de generar, en sus organizaciones, los
repositorios de los documentos del proyecto.
6.4. Gestión de Riesgos del proyecto.

Identificación de los riesgos
1. Debido que el gerente del proyecto tenga pendientes otras tareas fuera de este proyecto
podría ocurrir que haya demora en la definición del Project Charter lo que llevaría a
no entregar el documento que abriría inicio al proyecto.
2. Debido a que el usuario no tenga bien en claro sus necesidades para el sistema o la
solución que necesita, podría ocurrir una definición del alcance del proyecto ambiguo,
lo que podría provocar falta de detalle en el alcance del proyecto.
3. Debido a que se tiene plazos cortos para la ejecución del proyecto y al dejar de lado la
los riesgos, podría ocurrir que no se identifiquen los riesgos, lo que llevaría a una mala
definición del alcance y además nos llevaría a no poder controlar los eventos
inesperados que ocurrirían durante el proyecto.
Página | 194
4. Al aplicar una incorrecta metodología de análisis podría ocurrir que los requerimientos
funcionales no sean entregados a tiempo, y se tenga una mala definición del alcance
del proyecto o se tenga una idea incorrecta de lo que se necesita para el sistema
5. Al aplicar una incorrecta metodología de análisis podría ocurrir que los requerimientos
no funcionales no sean entregados a tiempo, y que los requerimientos no funcionales
no sean correctamente definidos y haciéndolos no comprensibles para la
implementación.
6. Al aplicar una incorrecta metodología de diseño, podría provocar una incorrecta
especificación de los documentos y entregables, lo que llevaría a provocar confusión
a la siguiente fase en la implementación
7. La falta de una buena metodología de desarrollo por el lado de los programadores,
podría provocar errores en los programas desarrollados, lo que llevaría a rehacer el
código de los CUS definidos.
Análisis Cualitativo
Para el mejor entendimiento de la lista de riesgos, a continuación se explicarán los
criterios utilizados para establecer los valores en el nivel de probabilidad y el nivel de
impacto.
Escala De Probabilidad
Consiste en la probabilidad de que ocurra el riesgo. Los valores son baja, media y alta.
En la siguiente tabla se muestra la correspondencia entre el nivel de probabilidad y el
rango de probabilidad.
Nivel de Probabilidad Valor
Baja 0.25
Media 0.50
Alta 0.75
Escala de Impacto
La siguiente tabla muestra el peso por cada nivel de impacto.

Nivel de Peso del
Alcance Tiempo Costo
Impacto Impacto
Incremento del
Atrasos de 8
Baja 10 Apenas perceptible 5% del costo
horas
inicial
Atrasos mayores Incremento
Plazos y Costos
Media 40 a 8 horas y mayor al 5% y
afectados
menor a 24 horas menor al 10%
Impacto relevante para Atrasos de más Incrementos
Alta 80
el éxito del proyecto de 24 horas mayores al 10%
Matriz de Probabilidad e Impacto
Página | 195
En el siguiente cuadro se puede apreciar las diferentes zonas de control, que han sido
clasificadas en conformidad con los umbrales de riesgo de los interesados.
Probabilidad Amenazas
0.25 2.5 10 20
0.50 5 20 40
0.75 7.5 30 60
10 40 80
Impacto
Aquellos riesgos cuya combinación de probabilidad e impacto se encuentre en la zona

roja o amarilla, deberán ser controlados durante el desarrollo del proyecto hasta
eliminarlos. Aquellos riesgos cuya combinación de probabilidad e impacto se encuentre
en la zona verde, deberán ser controlados de manera global mediante un Plan de
Respuesta conjunto para todos.
Representado en la matriz de probabilidad:
ALTA R2
MEDIA R1, R3, R7
PROBABILIDAD R4
BAJA R5
R6
BAJA MEDIA ALTA
IMPACTO
Aplicación de estrategias de mitigación

1. Gerente de proyecto debe desarrollar el Proyect Charter dejándose apoyar por el
Analista logrando así 2 objetivos, que definir con el analista las características
del proyecto y disminuir el trabajo del Gerente del Proyecto, haciendo viable la
iniciación del proyecto en la fecha programada.
2. Se debe de comprometer al usuario en las definiciones de los requerimientos del
proyecto, un usuario por cada proceso, debido a que la definición de los
requerimientos con los interesados es el primer paso que permitirá llevar a éxito
el proyecto.
3. El Gerente del Proyecto y el Analista deben trabajar una metodología de
seguimiento de actividades dinámica que se adapte a las personalidades de cada
programador, para que la implementación se haga más llevadera.
Identificación de Riesgos:
Fuente de la Declaración del Entregable (s)

NR Categoría Frecuencia Trigger
identificación riesgo Involucrado (s)
Página | 196
El Jefe de Proyecto Demora en la Retraso en la entrega del
1 tenga pendientes otras definición del Project Project Charter Inicio Poca documento inicial del
tareas Charter proyecto
El usuario no tenga bien Definición del alcance Documentos de Falta de detalle en el alcance
2 Planeación Alta
en claro las necesidades del proyecto ambiguo alcance del proyecto del proyecto
Tener plazos cortos Mala definición del alcance

para la ejecución del No identificación de Plan de gestión de del proyecto y eventos que no
3 Planeación Medio
proyecto y dejar de lado riesgos del proyecto riesgos se podrían controlar debido a
los riesgos los inconvenientes
Requerimientos Creación de la matriz Definición incorrecta de lo

Incorrecta metodología
4 funcionales no de requerimientos Ejecución Medio que se necesita para el
de análisis
entregados a tiempo funcionales sistema.
Requerimientos no Creación de la matriz

Incorrecta metodología Confusión en la fase de
5 funcionales no de requerimientos no Ejecución Medio
de análisis Construcción
entregados a tiempo funcionales
análisis no detallado Elaboración del

Incorrecta metodología Mala definición del alcance
6 correctamente y mala documento de Planeación Alta
de diseño del proyecto
especificación análisis
Identificación de
Falta de una buena Rehacer segmentos de código
errores en los Desarrollo del plan Construcció
7 metodología de los Baja de los CUS y se perdería
programas de pruebas n
programadores tiempo nuevamente.
desarrollados
Página | 197
Identificación de Riesgos:
¿Requiere
¿Requiere análisis
NR Impacto Probabilidad Score Ranking Fundamentos de la evaluación de P e I respuesta de Corto
Cuantitativo? (S / N)
Plazo? (S / N)
1 Media Media 2 Moderado Se finaliza proyecto S N
2 Alto Alta 3 Alto Ampliación de proyecto y alto costo S S
3 Media Media 2 Moderado Modificación de análisis que perjudique el avance del proyecto y las funcionalidades del sistema N N
4 Bajo Media 2 Moderado Ampliación de proyecto y aumento costo N N
7 Media Media 2 Moderado Ampliación de proyecto y aumento costo N N
Plan de Respuesta:
Presupuesto y
Estrategia de ¿Requiere un plan Score
Duración para
NR Respuesta Acciones especificas Risk Owner de contingencia? S / Imp Prob (Riesgo Riesgos Secundarios
implementar la
acordada N Residual)
respuesta
Gerente de proyecto desarrollara el Project Gerente de

1 Evitar n días N 0.4 0.7 Medio Ninguno, se finaliza proyecto
Charter y se lo entregara al cliente para la firma Proyecto
Comprometer al usuario en las definiciones del Gerente de
Ampliación de proyecto y alto
2 Mitigación proyecto. Que más de una persona esta en las $700.00 Proyecto, Líder S 0.7 1 Alto
costo
reuniones de requisitos del usuario. Usuario
Indicar lo importante que es la identificación de
Gerente de Modificación de análisis que
riesgos para el éxito de todo el proyecto, y tomar
3 Mitigación $200.00 Proyecto, Líder S 0.4 0.6 Medio perjudique el avance del proyecto y
en consideración un proyecto que planifique y
Usuario las funcionalidades del sistema
controle los riesgos
Tener que considerar analistas con un nivel Gerente de
Ampliación de proyecto y aumento
4 Mitigación adecuado para fases importantes de los pre- $400.00 Proyecto, Líder N 0.2 0.8 Medio
costo
requisitos Usuario
Gerente de
Comprometer al usuario en las definiciones del Ampliación de proyecto y aumento
5 Mitigación $700.00 Proyecto, Líder N 0.2 0.7 Bajo
proyecto. costo
Usuario
Incrementar recursos para no incrementar el Gerente de Ampliación de proyecto y aumento
6 Mitigación $200.00 N 0.3 0.8 Medio
tiempo del proyecto Proyecto costo
Realizar plan de pruebas unitarias durante la etapa Gerente del Ampliación de proyecto y aumento
7 Mitigación $500.00 S 0.4 0.8 Medio
de construcción proyecto costo
2700
Página | 198
6.5. Plan de Gestión de Cambios
Nombre del Proyecto Siglas del Proyecto

CRM Sistema de Gestión Inmobiliaria CRM SGI
Nombre del Rol Persona Responsabilidad Nivel de Autoridad

Asignada
Dirimir en decisiones empatadas
Sponsor AV en el Comité de Control de Total sobre el proyecto.
Cambios.
Comité de
Decidir qué cambios se aprueban, Autorizar, rechazar, o diferir
Control de AV/LM/CC
rechazan, o difieren. solicitudes de cambio.
Cambios
Evaluar impactos de las
Gerente del Solicitudes de Cambio y hacer Hacer recomendaciones sobre
LM
Proyecto recomendaciones. los cambios.
Aprobar Solicitudes de Cambio.
Asistente de Captar las iniciativas de cambio de
Gestión de CC los stakeholders y formalizarlas en Emitir solicitudes de cambio.
Proyectos Solicitudes de Cambio.
Solicitar cambios cuando lo crea
Stakeholder Cualquiera Solicitar cambios.
conveniente y oportuno.
Tipos de Cambios
1. Acción Correctiva: Este tipo de cambio no pasa por el Proceso General de Gestión de Cambios, en
su lugar el Project Manager tiene la autoridad para aprobarlo y coordinar su ejecución.
2. Acción Preventiva: Este tipo de cambio no pasa por el Proceso General de Gestión de Cambios, en
su lugar el Project Manager tiene la autoridad para aprobarlo y coordinar su ejecución.
3. Reparación de Defecto: Este tipo de cambio no pasa por el Proceso General de Gestión de Cambios,
en su lugar el Project Manager tiene la autoridad para aprobarlo y coordinar su ejecución.
4. Cambio Al Plan De Proyecto: Este tipo de cambio pasa obligatoriamente por el Proceso General
de Gestión de Cambios, el cual se describe en la sección siguiente.
Proceso General de Gestión del Cambio

Formalizar Iniciativa entregando solicitud de cambio vía
Solicitud de Cambios mail o en las reuniones detallando el motivo a todos los
involucrados.
6.8 Constancia de aceptación del cliente sobre el proyecto.

Nombre del Proyecto: Sistema de Gestión Inmobiliaria (CRM SGI)
Elaborado por: LM - Gerente del proyecto
Fecha: Lunes 23 de Abril del 2012
Iniciación:
Gerente de proyecto : Poder de administrar todos los recursos asignados por el sponsor.
199/
44
El propósito de este proyecto es el desarrollar una solución que resuelva la problemática del
área comercial de la Empresa Constructora Inmobiliaria.
El alcance del proyecto es la gestión de las actividades de los procesos que interactúan en la
Sinopsis:
venta de un inmueble.
El proyecto tomará 142 días útiles, a partir del 23 de Abril del 2012.
El proyecto necesitará una inversión de 20 000 dólares americanos.
El proyecto urge por la necesidad de llevar un control de las ventas a nivel nacional
(actualmente en 4 puntos: Arequipa, Puerto Maldonado, Tacna y Lima).
Propósito /
Esta estrategia de negocios busca optimizar el proceso comercial y los procesos vinculados
Necesidad del
a él (debido a que para el negocio en mención las ganancias están muy relacionadas con las
Negocio:
ventas).
El sistema brindará información oportuna para una correcta y acertada toma de decisiones.
El producto integrará los módulos de ventas, marketing, trámite documentario, finanzas,
legal, post - venta, operaciones, base seguridad y reportes.
Siendo desarrollado en una plataforma web, con el objetivo de facilitarles el acceso desde
cualquier punto de venta a nivel nacional
Principales Entregables del Proyecto
Project Charter (Acta de constitución del proyecto)
Módulo Base
Módulo de Ventas
Descripción
Módulo de Marketing
del producto y
Módulo de Trámite Documentario
entregables:
Módulo de Finanzas
Módulo Legal
Módulo de Post - Venta
Reportes
CD con el instalador del Sistema
Manual de Instalación y Configuración
Manual de Usuario
Acta de cierre del proyecto.
Captura total de requerimientos (Informes de Entrevistas terminados).
Resumen del Informe de Entregables Terminados.
cronograma de Informe de Pruebas del Sistema Aprobado.
Hitos: Informe de Capacitación Terminada.
Acta de Cierre del Proyecto.
Supuestos, El presupuesto tiene una holgura de 10%.
Restricciones, El proyecto no puede excederse del tiempo pre-establecido.
Riesgos: Los recursos humanos están establecidos de acuerdo a su rol.
Recursos Financieros: 20000 dólares americanos
Recursos Personales:
Un Gerente de Proyectos
Un Analista
Un Arquitecto
Un DBA
Recursos:
2 Programadores
Materiales:
3 Laptops
3 RPM’s telefónicos.
1 Impresora Canon MP 150
Útiles de Oficina.
El proyecto será desarrollado bajo la metodología RUP para lograr el cumplimiento eficiente
Propuesta:
del producto (A tiempo, bajo el presupuesto señalado).
El proyecto es confiable ya que está siendo desarrollado bajo la metodología confiable del
Aceptación: Proceso Unificado de Rational, además generará un elevado retorno de inversión para la
empresa patrocinadora.
Los interesados en este proyecto son:
Gerente General de la Empresa Constructora Inmobiliaria
Influencias de
Los Gerentes y trabajadores de las siguientes áreas de la Empresa Constructora Inmobiliaria:
los
Ventas, Marketing, Trámite Inmobiliario, Finanzas, Legal, Post - Venta.
interesados:
Gerente de Proyectos
Equipo del Proyecto
Patrocinador:
Aprobación: Gerente del Proyecto: LM Gerente General de la Empresa
Constructora Inmobiliaria.
200/
44
CONCLUSIONES
Al recapitular todo lo tratado en el presente proyecto de tesis, y de acuerdo a los objetivos planteados al inicio del
presente proyecto de investigación llegamos a las siguientes conclusiones:
1. El sistema web desarrollado fundamentado en los procesos estandarizados y definidos al inicio del proyecto ayuda
a optimizar el proceso de venta de la Empresa Constructora Inmobiliaria.
2. Gracias al trabajo en equipo de la empresa cliente y la empresa desarrolladora de software, se logró implementar
la solución.
3. Gracias al seguimiento y capacitaciones brindadas por el lado de la empresa desarrolladora de software, se
cumplió con la implantación exitosa de la solución. Actualmente la solución se encuentra instalada en el hosting
de la Empresa Constructora Inmobiliaria y la están utilizando en proyectos distribuidos en varias ciudades del
Perú.
4. El producto final es una aplicación web CRM que optimiza el proceso de venta de la Empresa Constructora
Inmobiliaria, consiguiendo así ventajas notables como: proveer a la gerencia la información oportuna para tomar
decisiones asertivas a tiempo, permitir al área de ventas conseguir más ventas por el tiempo invertido en el
seguimiento y atención a los clientes (tiempo que antes se invertía en la elaboración de reportes manuales y
diarios) y facilitar al área de trámite documentario la información necesaria automatizada, para brindar mayor
confiabilidad de sus expedientes a los clientes.
201/
44
RECOMENDACIONES
Una vez establecidas las conclusiones a las que se arribó mediante el análisis de los resultado, s se proponen las
siguientes recomendaciones:
1. La implementación de un CRM tiene que ver con la utilización de un software, pero el software como una
herramienta tecnológica es sólo uno de los medios que conduce a administrar la relación con los clientes. Esta
estrategia implica sobre todo conocer las necesidades de los clientes y personalizar la oferta para aumentar la
satisfacción y sobre todo la lealtad de los clientes. Por ende es recomendable continuar optimizando la solución
web a medida para la Empresa Constructora Inmobiliaria.
2. Para implementar la estrategia CRM, es importante una cultura organizacional apropiada, ese es el elemento más
importante, por ello es recomendable no sólo informar al personal que se va a pasar a una etapa siguiente en la
estrategia CRM, sino invitarlo a que forme parte del desarrollo esta estrategia de negocios.
3. Para ofrecer una oferta adaptada a las necesidades de los clientes se sugiere que para una futura versión se
considere la identificación de los mismos en el sistema, de manera que tengan un acceso completo a la
visualización del estado de sus expedientes y la edición completa de los expedientes dentro del sistema para todas
las áreas involucradas.
4. Para consolidar la estrategia CRM se recomienda la continuidad del compromiso de la dirección y del personal
en el desarrollo y evolución de la estrategia CRM.
202/
44
GLOSARIO DE TÉRMINOS
(Actor del negocio) Representa un rol jugado por alguien o algo

BUSINESS ACTOR
externo al negocio y que interactúa o se relaciona con el negocio.
(Proceso del negocio) Conjunto o grupo de tareas o actividades
que tienen una secuencia u orden lógico, además emplean
BUSINESS PROCESS
recursos de la organización, ofrece resultados de interés a alguien
y apoya algún objetivo de la organización.
(Caso de uso del negocio) Identifica un proceso específico del
negocio que produce un resultado de valor medible y esperado
BUSINESS USE CASE
por un actor (o actores) en particular. Representa la secuencia de
actividades desarrolladas para lograr ese valor.
(Modelo de casos de uso del negocio) Muestran la agrupación de
procesos en paquetes (grandes procesos) y la descomposición de
BUSINESS USE CASE
los mismos en casos de uso de negocio, muestran la interacción
MODEL
de actores y casos de uso de negocio, en resumen muestran el
contexto del negocio.
Conjunto de actividades o de esfuerzos que se realizan durante
cierto tiempo y están encaminados a conseguir un fin, en este
caso es un fin de comunicar las actividades de promoción. Los
CAMPAÑA temas de campaña suelen ser desarrollados con la intención de
ser utilizado durante un cierto periodo de tiempo, pero muchos
de ellos son de corta duración debido a factores como la alta
competencia del mercado.
CH El Crédito Hipotecario es aquel que una IFI da.
Aquel documento o información que el departamento de compras
usa en una negociación. Es un documento informativo que no
genera registro contable. Cotización son la acción y efecto de
COTIZACIÓN cotizar (poner precio a algo, estimar a alguien o algo en relación
con un fin, pagar una cuota). El término suele utilizarse para
nombrar al documento que informa y establece el valor de
productos o servicios.
CUN Casos de Uso del Negocio
CUS Casos de Uso del Sistema
(Cliente) Es la "razón de ser" del negocio, no forma parte de la
CUSTOMER
organización.
IFI Institución Financiera Interbancaria.
Ingeniería de software es la disciplina o área de la informática
INGENIERIA DE
que ofrece métodos y técnicas para desarrollar y mantener
SOFTWARE
software de calidad.
Se consideran inmuebles todos aquellos bienes considerados
bienes raíces, por tener de común la circunstancia de estar
íntimamente ligados al suelo, unidos de modo inseparable, física
o jurídicamente, al terreno, tales como las parcelas, urbanizadas
INMUEBLE o no, casas, naves industriales, o sea, las llamadas fincas, en
definitiva, que son bienes imposibles de trasladar o separar del
suelo sin ocasionar daños a los mismos, porque forman parte del
terreno o están anclados a él. Etimológicamente su denominación
proviene de la palabra inmóvil.
203/
44
La latitud es la distancia angular entre el ecuador y un punto
LATITUD determinado del planeta medida a lo largo del meridiano que pasa
por ese punto.
Distancia expresada en grados, entre el meridiano de un punto y
LONGITUD
otro tomado como referencia en el Ecuador.
Es el proceso social y administrativo por el que los grupos e
MARKETING individuos satisfacen sus necesidades al crear e intercambiar
bienes y servicios.
Borrador que se hace de un escrito, especialmente de un contrato,
MINUTA
antes de redactarlo definitivamente.
Un conjunto finito de actividades interdependientes que recibe
PROCESO
una aportación que se transforma, de forma lógica, en un
EMPRESARIAL
resultado.
La promoción de ventas es una herramienta o variable de la
mezcla de promoción (comunicación comercial), consiste en
PROMOCIÓN incentivos de corto plazo, a los consumidores, a los miembros del
canal de distribución o a los equipos de ventas, que buscan
incrementar la compra o la venta de un producto o servicio.
Las pruebas de software (en inglés software testing) son las
investigaciones empíricas y técnicas cuyo objetivo es
PRUEBA proporcionar información objetiva e independiente sobre la
calidad del producto a la parte interesada o stakeholder. Son una
actividad más en el proceso de control de calidad.
Expresión matemática o algoritmo que permite calcular el valor
REGLA DE CÁLCULO
de un término.
Es un tipo especial de reglas de operación, estas reglas
REGLA DE FLUJO determinan y limitan cómo fluye la información a través del
proceso.
REGLA DE ESTÍMULO Condición que debe ser cierta para ejecutar una operación de
Y RESPUESTA respuesta inmediata.
REGLA DE Son asociadas a la clases, objetos y sus relaciones, se sub-
ESTRUCTURA clasifican como reglas de relaciones y de dominio de datos.
REGLA DE Condición que debe ser cierta para inferir un hecho o un estado.
INFERENCIA
Condición que debe ser cierta para asegurar que una operación se
REGLA DE
ejecute correctamente, puede darse antes y después de la
OPERACIÓN
operación y puede asociarse a precondiciones y post condiciones.
Es una declaración que rige el funcionamiento de algún aspecto
REGLA DEL
del negocio, indica el tipo de requerimiento sobre cómo opera el
NEGOCIO
negocio.
En la ingeniería de sistemas, un requisito o requerimiento (del
inglés requirement: ‘requisito’) es una necesidad documentada
REQUERIMIENTO sobre el contenido, forma o funcionalidad de un producto o
servicio. Se usa en un sentido formal en la ingeniería de sistemas
o la ingeniería de software.
(Socio o decisor) Se le considera el propietario del proceso, los
STAKEHOLDER resultados del proceso le sirven para tomar decisiones, no
participa de la parte operativa.
En la ingeniería de software se denomina aplicación web a
aquellas aplicaciones que los usuarios pueden utilizar accediendo
SOLUCIÓN WEB
a un servidor web a través de Internet o de una intranet mediante
un navegador. En otras palabras, es una aplicación software que
204/
44
se codifica en un lenguaje soportado por los navegadores web en
la que se confía la ejecución al navegador.
Equipamiento lógico o soporte lógico de un sistema informático,
SOFTWARE el que comprende el conjunto de los componentes lógicos
necesarios que hacen posible la realización de tareas específicas
La venta es una de las actividades más pretendidas por empresas,
organizaciones o personas que ofrecen algo (productos, servicios
VENTA u otros) en su mercado meta, debido a que su éxito depende
directamente de la cantidad de veces que realicen ésta actividad,
de lo bien que lo hagan y de cuán rentable les resulte hacerlo.
205/
44
SIGLARIO
AD Agile Database Techniques.

AEIPRO Asociación Española de Ingeniería de Proyectos
AM Agile Modeling
API Application Programming Interface
ASD Adaptive Software Development
AUP Agile Unified Process
BCL Base Class Library
BFH Familiar Habitacional
BI Business Intelligence
BPM Business Process Management
B2B Business to Business
CASE Computer Aided Software Engineering
CBSE Component-Based Software Engineering
CIO Chief Information Officer
CRM Customer Relationship Management
CLR Common Language Runtime
CLS Common Languaje Specification
CSS Cascading Style Sheets
DBMS Database Management System
DSDM Dynamic Systems Development Method
ERP Enterprise Resource Planning
EAI Enterprise Application Integration
ESB Enterprise Service Bus
FDD Feature Driven Development
FTP File Transfer Protocol
GLP General Public License
HOLAP Hybrid On-Line Analytical Processing
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol
IaaS Infrastructure as a Service
IDC International Data Corporation
IIS Microsoft Internet Information Server
IPMA International Project Management Association
JDK Java Development Kit
MOLAP Multidimensional On-Line Analytical Processing
MVC Model-View-Controller
NIST National Institute of Standards and Technology
OLAP On-Line Analytical Processing
PaaS Platform as a Service
PBI Producto Interno Bruto
PHP Hypertext Pre-processor
PMBOK Project Management Body of Knowledge
PMI Project Management Institute
POO Programación orientada a objetos
PRINCE Projects IN Controlled Environments
206/
44
QoS Quality of service
ROLAP Relacional On-Line Analytical Processing
RUP Rational Unified Process
SaaS Software as a Service
SCM Supply Chain Management
SGBDOO Sistema de Gestión de Base de Datos Orientado a Objetos.
SLA Service Level Agreement.
SOA Service Oriented Architecture.
TIC Tecnologías de la Información y la Comunicación.
UAW Total de valores de los actores sin ajustar.
UUCW Total de valores de los casos de uso sin ajustar.
UUCP Puntos de casos de uso sin ajustar.
AUCP Puntos de casos de uso ajustados.
UML Unified Modeling Language, es el lenguaje de modelado de sistemas de
WSDL Web Services Description Language.
software más conocido y utilizado en la actualidad; está respaldado por el
XP eXtreme Programming.
OMG (Object Management Group). Es un lenguaje gráfico para visualizar,
especificar, construir y documentar un sistema.
207/
44
BIBLIOGRAFÍA
Aalbers H. (2013). Introdución a SOA (I). Consultado el 23 de Enero de 2013 en http://www.huibert-

aalbers.com/IT_Insight/Spanish/PDF/ITI003Sp-SOA(I).pdf
Aalbers H. (2013). Introdución a SOA (II). Consultado el 23 de Enero de 2013 en http://www.huibert-

aalbers.com/IT_Insight/Spanish/PDF/ITI005Sp-SOA(II).pdf
Aalbers H. (2013). Elección de tecnología para la capa de presentación de SOA. Consultado el 23 de Enero de 2013 en
http://www.huibert-aalbers.com/IT_Insight/Spanish/PDF/ITI008Sp-SOAPresentationLayer.pdf
Aalbers H. (2013). Cloud computing. Consultado el 23 de Enero de 2013 en http://www.huibert-

aalbers.com/IT_Insight/Spanish/PDF/ITI012Sp-CloudComputing.pdf
Águeda A., (2013). PMBOK vs PRINCE2 el 23 de Enero de 2013 en http://www.pmi-

bcn.org/es/Noticias/22/Primer_webinar_del_Capitulo_de_Barcelona:_PMBoK_vs_PRINCE2/
Alet J. (2000). Como obtener clientes reales y rentables – Marketing Relacional. Ed. Gestión 2000. Barcelona 1994.
ARQUITECT SOLUTIONS (2011). Obtenga más de Salesforce. Consultado el 19 de Febrero del 2013 en
http://salesforce.architech.ca/wp-content/uploads/2012/11/Get-More-Out-of-Salesforce.pdf
Bean J.(2010). SOA and Web Services Interfaces Design, Elsevier (cap. 1)
Beck K. (2000). Extreme Programming Explained, Boston Addison-Wesley (cap. 4, 17, 25 y 26)
Bligh P. & Turk D. (2004). CRM unplugged: releasing CRM's strategic value.
Boehm, B. W. (1988). A spiral model of software development and enhancement. IEEE Computer (cap. 4 y 5).
Booch G. & Rumbaugh J. (1999). The Unified Modeling Language User Guide Reading, MA; Addison-Wesley (cap. 1, 4, 8)
Casillas L., Gibert M. y Pérez O. (2007) Bases de datos en MySQL. Ed. Fundació per a la Universitat Oberta de Catalunya.
Cid R. (2005). Hacia el CRM 2.0: Retos y oportunidades. Ed. Ediciones Deusto. Consultado el 23 de Enero del 2013 en http://www.e-
deusto.com/revistas/
Cortés G. Cloud Computing - Tendencias - Modelos – Posibilidades. ACIS 2011. Consultado el 23 de Enero de 2013 en
http://www.acis.org.co/fileadmin/Conferencias/CloudComputing.pdf
Debuiré B. (2012) El Lenguaje de Programación Python. Consultado el 23 de Enero de 2013 en

http://www.coplec.org/files/Flisol%20-%20Python.pdf
Esteban A. (2000). Programación en java. Ed. Grupo Eidos.
García E. (2007). Conceptos básicos de hardware y software. Ed. Dykinson, Madrid.
Gibert M. y Pérez O. (2005). Bases de datos en PostgreSQL. Ed. Fundació per a la Universitat Oberta de Catalunya.
Gilroy D. (2010) SugarCRM for Law Firms A Whitepaper. Consultado el 19 de Debrero del 2013 en:
http://www.conscious.co.uk/cms/document/sugarcrm_for_law_firms.pdf
Gómez A & Suárez C. (2007). Sistemas de Información Herramientas prácticas para la gestión empresarial.
Google Chart (2013). Introducción al uso de Herramientas de gráficos. Consultado el 23 de Enero de 2013
https://developers.google.com/chart/interactive/docs/index
208/
44
Google Maps (2013). Guía del usuario de Google Maps. Consultado el 23 de Enero de 2013 en
http://maps.google.com/support/bin/static.py?hl=es&page=guide.cs&guide=21670&from=21670&rd=1
Heredia N. (2008) Gerencia de compras: la nueva estrategia competitiva. 1ª Ed.
INEI (2012) - Comportamiento de la Economía Peruana en el Tercer Trimestre de 2012. Consultado el 23 de Enero de 2013 en:
http://www.inei.gob.pe/web/BoletinFlotante.asp?file=15565.pdf
Juarez R. (2010) Definición de Cloud Computing. Consultado el 23 de Enero del 2013 en

http://www.economia.unam.mx/cechimex/BECAS%20CH-MX/RicardoJuarezAnexos.pdf
Kotler P. & Armstrong G. (2003). Fundamentos de marketing, México. Pearson Educación de México, S.A. de C.V.
Kroenke D. (2003). Procesamiento de base de datos. Pearson Educacion; 8ª Ed.
Osorio L. (2008). Base de datos relacionales teoría y práctica. Instituto Tecnológico Metropolitano, Medellín Colombia.
López M. & Alonso J. (2008). Tesis para optar el grado de ingeniero de las telecomunicaciones. Diseño e implementación de un
sistema de gestión de acceso a una red wi-fi utilizando software libre. Consultado el 23 de Enero del 2011 en
http://tesis.pucp.edu.pe/files/PUCP000000001078/Dise%F1o%20e%20implementaci%F3n%20de%20un%20sistema%20de%20gest
i%F3n%20de%20accesos%20a%20una%20red%20wi-fi%20utilizando%20software%20libre.pdf
López D. & Kallen I. (2002). Apache 2 in 24 hourse. Ed. Sams Publishing
Mackenzie D. – Sharkey K. (2011) Aprendiendo Visual Basic .NET en 21 lecciones avanzadas. Pearson Educación de México S.A.
Consultado el 23 de Enero de 2013 en
http://books.google.com.pe/books?id=Rfm9jecXbDoC&printsec=frontcover&hl=es#v=onepage&q&f=false
Maestros Del Web (2011) Google Maps API V3 introducción y primeros pasos. Consultado el 26 de Setiembre de 2011 en
http://www.maestrosdelweb.com/editorial/google-maps-api-v3-introduccion-y-primeros-pasos/
Mata M. (Abril 2009). Tesis que para obtener el grado de doctor en ciencias de la computación. Recuperación y ponderación de
información geográfica desde repositorios no estructurados conducidos por ontologías. Instituto Politécnico Nacional - Centro de
Investigación en Cómputo. Laboratorio de procesamiento inteligente de información geo – espacial, México. Consultado el 23 de
Enero de 2013 en http://www.cic.ipn.mx/posgrados/images/sources/cic/tesis/B050941.pdf
Maximiliano P. (2007). Tesis de grado de ingeniería en informática. Extensión del estándar PSS de CORBA para proveer servicios de
estado persistente con acceso remoto: Análisis, diseño e implementación, Universidad de Buenos Aires, Argentina. el 23 de Enero de
2013 en http://materias.fi.uba.ar/7500/pilardi-tesisingenieriainformatica.pdf
Microsoft Dynamics (Noviembre 2010). Creación de aplicaciones de negocio con Microsoft Dynamics CRM 2011. Consultado el 19
de Febrero del 2013 en http://www.microsoft.com/en-us/download/confirmation.aspx?id=14364
MI VIVIENDA (2012). “Desembolsos del nuevo crédito MIVIVIENDA crecieron 135% en el 2010”. Consultado el 23 de Enero de
2013 en http://www.mivivienda.com.pe/NR/rdonlyres/59EC7B22-C2FD-49A0-B1E8-
F3ED8A621D0F/9483/RevistaFondoMIVIVIENDAN50.pdf
Muñoz D. & Gil G. (Setiembre 2006). Solución CRM en la Empresa Pública y Privada. Grupo Editorial Megabyte. 1ª Ed.
Oracle (2011), License Rights, Consultado el 23 de Enero de 2013 en http://www.oracle.com/technetwork/testcontent/standard-

license-088383.html
Osorio F. (2008) Bases de datos relacionales: teoría y práctica. Instituto Tecnológico Metropolitano. 1ra Edición.
Palacio J. & Ruata C. SCRUM Manager: Gestión De Proyectos. Ed. Rev. 1.4 - Enero 2011. Consultado el 23 de Enero de 2013 en
Http://Www.Scrummanager.Net/Files/Sm_Proyecto.Pdf
Pérez L. (2004) Tesis de grado de licenciada en ciencias de la computación. Sistema de base de datos para una ferretería. Consultado
el 23 de Enero de 2013 en http://perseo.cs.buap.mx/bellatrix/tesis/TES728.pdf
209/
44
PMI (2007). Project Management Institute. Consultado el 23 de Enero de 2013 en
http://www.pmi.org.pe/sitio/modules/smartsection/item.php?itemid=6
PMBOK, Guia de los fundamentos para la dirección de Proyectos (Guía del PMBOK) (2008). Project Management Institute. 4ª Ed.
Postgre Sql (2011). Sobre Postgre SQL. Consultado el 23 de Enero de 2013 en http://www.postgresql.org.es/sobre_postgresql
Pressman R. (2005). Ingeniería Del Software, un enfoque práctico. 6ª Ed.
PRINCE (2011). Project in a box: Your own Project Support Office - PRINCE 2. Consultado 23 de Enero de 2011 en
http://www.projectinabox.org.uk/prince2.asp
Prince Manual (2011). PRINCE 2: Metodología de gestión de proyectos. Consultado el 23 de Enero de 2013 en
http://es.scribd.com/doc/24166418/MANUAL-PRINCE-2-Metodologia-Gestion-de-Proyectos
Reinares P. & Ponzoa J. (2002). Marketing relacional: un nuevo enfoque para la seducción y fidelización del cliente. Ed. Prentice Hall
Sommerville I. (2005). Ingeniería del software. Ed. Pearson Education S.A; Addison-Wesley (cap. 1, 4 y 17)
Silberschatz A., Korth H. & Sudarshan S. (2002). Fundamentos de bases de datos. Ed. McGRAW-HILL/INTERAMERICANA DE
ESPAÑA, S. A. U.
Visual Basic .Net (2011). “Información general y conceptual sobre .NET Framework”
Consultado el 23 de Enero de 2013 en http://msdn.microsoft.com/es-pe/library/zw4w595w.aspx
Wiki.dreamhost.com (2011). Apache vs. IIS. Consultado el 23 de Enero de 2013 en

http://wiki.dreamhost.com/Web_Server_Performance_Comparison
Williams D. (2011). CRM 2.0: Customer Strategy as a Business Strategy. Creating Sustainable Competitive Advantage in a New
Digital World. Merkle a Customer Relationship Marketing Agency. Consultado el 23 de Enero de 2013 en
http://www.merkleinc.com/thought-leadership/white-papers/crm-20-customer-strategy-business-strategy
Zeis C., Ruel C. y Wessler M. (2009).Oracle 11g for dummies. Ed. Wiley Publishing Inc. Consultado el 23 de Enero de 2013 en
http://www.canadawise.ca/eBooks/oracle11g%20for%20Dummies.pdf
210/
44
ANEXOS
ANEXO 1
ESPECIFICACIONES DE LOS CASOS DE USO DEL NEGOCIO

Especificación del Caso de Uso del negocio “Desistir Compra”
Cuadro 1: Caso de Uso “Desistir Compra”
Caso de Uso del Negocio Desistir Compra

Actor Cliente
Propósito Gestionar el desistimiento de una compra.
Alcance Se explicará el proceso de un desistimiento de compra.
Definiciones, Acrónimos Ver Glosario
y Abreviaturas
Referencias • Diagrama de objetos del caso de uso Desistir Compra.
• Diagrama de actividades del caso de Desistir Compra.
Caso de Uso Separar Inmueble.
Casos de Uso asociados
Resumen:
El caso de uso Desistir Compra es el caso en el que un cliente abandona la compra
de un inmueble.
La compra de un inmueble abandonada.
Medidas de Rendimiento
La continuación de una compra
Un desistimiento sólo puede darse luego del Contrato
Pre-condiciones de Separación o luego de la Firma de la Minuta, no
después.
FLUJO DE EVENTOS
Actor Proceso
1. El Cliente expone ante el asesor el motivo por el
que abandona la compra del inmueble.
2. El asesor comercial evalúa el caso del cliente. Si su
caso tiene solución persuade al cliente de no
abandonar la compra, de lo contrario solicita Firma
de Carta de Desistimiento y Mutuo Disenso.
3. El Cliente Entrega decide no abandonar la compra
Cliente o de lo contrario entrega Carta de Desistimiento y
Mutuo Disenso
4. El Asesor Comercial adjunta al Expediente los
documentos entregados por el cliente.
5. El asesor comercial comunica disponibilidad del
inmueble.
6. El asesor de finanzas gestiona el pago del cheque al
cliente con la devolución.
Post-condiciones Desistimiento Registrado
Dueño del Proceso Cliente
211/
44
Un desistimiento sólo puede darse luego del Contrato
Requisitos Especiales de Separación o luego de la Firma de la Minuta, no
después.
Gráfica 1: Diagrama de Actividades “Desistir Compra”

: cliente : Asesor Comercial : Asesor Financiero
Exponer motivo de Evaluar caso

desistimiento
: Expediente
Decide no abandonar Si ¿Tiene Solución?
la compra [Consultado]
No
Solicitar Firma de Carta de

Desistimiento y Mutuo Disenso
: Expediente
Entregar Carta de Desistimiento Adjuntar Documentos al [Modificado] : Cheque de Devolución

y Mutuo Disenso Firmados Expediente.
[Creado]
Comunicar disponibilidad de Gestionar pago del cheque al

inmueble cliente con la devolución.
: Carta de Desistimiento
[Creada]
: Mutuo Disenso
[Creada]
: Inmueble
[Modificado]
Gráfica 2: Diagrama de Objetos “Separar Inmueble”
0..1
1 Mutuo Disenso
(f rom Entidades)
1
Asesor Comercial
1
1 0..*
1 0..1
1 1 1
0..*
0..*Expediente Carta de Desistimiento
Cliente
(f rom Actores)
1 0..1
Cheque de Devolución
(f rom Entidades)
Asesor Financiero

Especificación del Caso de Uso del negocio “Tramitar Minuta”
212/
44
Cuadro 2: Caso de Uso “Tramitar Minuta”
Caso de Uso del
Tramitar Minuta
Negocio
Actor Asesor de Trámite Documentario
Propósito Tramitar Minuta
Alcance Se explicará el proceso que involucra tramitar la minuta.
Definiciones, Ver Glosario
Acrónimos y
Abreviaturas
Referencias • Diagrama de objetos del caso de uso Tramitar Minuta.
• Diagrama de actividades del caso de uso Tramitar Minuta.
Caso de Uso Enviar a Banco
Casos de Uso
Caso de Uso Enviar a Notaría
asociados
Caso de Uso Desistir Compra
Resumen:
El caso de uso Tramitar Minuta describe el proceso que se realiza para lograr una
minuta correctamente firmada.
Medidas de
Una minuta firmada y archivada.
Rendimiento
Para firmar una minuta el cliente antes debe tener un contrato
Pre-condiciones
de separación
FLUJO DE EVENTOS
Actor Proceso
Asesor de Trámite 1. El Asesor de Trámite Documentario consulta el expediente.
Documentario 2. El Asesor de Trámite Documentario verifica si falta
registrar algunos pagos.
3. Si faltan registrar pagos, el cliente entrega el(los)
voucher(s) y el Asesor de Trámite Documentario los
registra en el expediente, de lo contrario el Asesor de
Trámite Documentario imprime la minuta y sus anexos.
4. El Asesor de Trámite Documentario solicita firmas.
5. El Cliente firma la minuta.
6. El Asesor de Trámite Documentario archiva la minuta al
expediente.
Post-condiciones Se ha tramitado la minuta.
Dueño del Proceso El Asesor de Trámite Documentario
Requisitos
Debe existir el expediente asociado
Especiales
213/
44
Gráfica 3: Diagrama de Actividades “Tramitar Minuta”
: Cliente : Asesor de Trámite Documentario
Consultar
Expediente
: Voucher de Pago
: Minuta
: Expediente
[Consultado]
[Generada]
[Consultado]
¿Faltan pagos para completar la inicial?
Entregar voucher de Solicitar voucher de

pago Pago
Si
: Anexo 1
Registrar
No [Generado]
Imprimir Minuta
y Anexos
: Anexo 2
: Pago : Voucher de Pago [Generado]
Firmar Minuta [Registrado] [Registrado] Solicitar Firmas
Archivar Minuta
al Expediente
: Expediente
[Actualizado]
Gráfica 4: Diagrama de Objetos “Tramitar Minuta”
0..*
Voucher de Pago Cotización
(f rom Entidades)
(f rom Entidades)
1
1
1
1 1
1 0..* 0..* 1
1
0..*
Pago Contrato de Separación
Asesor de Trámite Documentario (f rom Entidades) (f rom Entidades)
1 1 1
1
0..*
1
0..*
0..* 1 1
Anexo 2 0..*
(f rom Entidades)
1
1 1 1 1
Anexo 1 Minuta Expediente

(f rom Entidades) (f rom Entidades) (f rom Entidades)

Especificación del Caso de Uso del negocio “Enviar a Banco”
214/
44
Cuadro 3: Caso de Uso “Enviar a Banco”
Caso de Uso del
Enviar a Banco
Negocio
Actor El Asesor de Trámite Documentario
Propósito Enviar el expediente al banco.
Alcance Se explicará el proceso de envío del expediente al banco.
Definiciones, Ver Glosario
Acrónimos y
Abreviaturas
Referencias • Diagrama de objetos del caso de uso Enviar a Banco.
• Diagrama de actividades del caso de uso Enviar a Banco.
Casos de Uso Caso de Uso Tramitar Minuta.
asociados Caso de Uso Enviar a Banco.
Resumen:
El caso de uso Enviar a Banco, describe el proceso mediante el cual se envía el
expediente al Banco.
Medidas de
El expediente es enviado al banco.
Rendimiento
Pre-condiciones El expediente debe contar con la Minuta de Compra Venta.
FLUJO DE EVENTOS
Actor Proceso
El Asesor de 1. El Asesor de Trámite Documentario consulta el
Trámite Expediente para ver su estado.
Documentario 2. El Asesor de Trámite Documentario envía el Expediente
al banco.
3. El banco recibe el expediente.
4. El Asesor de Trámite Documentario registra fecha de
envío del expediente al banco.
Post-condiciones Se envía el expediente al banco.
Dueño del Proceso Asesor de Trámite Documentario.
Punto de Extensión No hay puntos de extensión.
Requisitos
Debe existir el expediente asociado.
Especiales
215/
44
Gráfica 5: Diagrama de Actividades “Enviar a Banco”
: Banco : Asesor de Trámite Documentario
Consultar
Expediente
: Expediente
Recibir [Consultado] Enviar Expediente

Expediente a Banco
Registrar fecha de envío del

expediente al banco
: Expediente
[Actualizado]
Gráfica 6: Diagrama de Objetos “Enviar a Banco”
1 0..*
0..* Expediente
Asesor de Trámite Documentario (f rom Entidades)
1..*
1..*
Banco
(f rom Actores)
216/
44
Especificación del Caso de Uso del negocio “Enviar a Notaría”
Cuadro 4: Caso de Uso “Enviar a Notaría”
Caso de Uso del Negocio Enviar a Notaría

Propósito Enviar expediente a la notaría.
Se explicará el proceso de envío del expediente a la
Alcance
notaría.
y Abreviaturas
• Diagrama de objetos del caso de uso Enviar a Notaría.
Referencias
• Diagrama de actividades del caso de uso Enviar a
Notaría.
Casos de Uso asociados Caso de Uso Enviar a Banco.
Caso de Uso Tramitar Escritura Pública.
Resumen:
El caso de uso Enviar a Notaría, describe el proceso mediante el cual se envía el
expediente a la notaría y luego del trámite, el expediente está listo para la Escritura
Pública.
Medidas de Rendimiento El número de Kardex registrado en el Expediente.
Pre-condiciones El expediente debe contar con la Minuta de Compra Venta.
FLUJO DE EVENTOS
Actor Proceso
El Asesor de Trámite 1. El Asesor de Trámite Documentario consulta el
Documentario Expediente para ver su estado.
2. El Asesor de Trámite Documentario envía el Expediente
a la Notaría.
3. El Asesor de Trámite Documentario registra número de
Kardex en el expediente.
Post-condiciones Se registra el número de Kardex, definido en la notaría.
Dueño del Proceso El Asesor de Trámite Documentario.
Requisitos Especiales Debe existir el expediente asociado.
217/
44
Gráfica 7: Diagrama de Actividades “Enviar a Notaría”
: Notaría : Asesor de Trámite Documentario
Consultar
Expediente
: Expediente
[Consultado]
Recibir Enviar Expediente
Expediente a Notaría
Asignar Kardex Registrar Número de

Kardex en el Expediente
: Expediente
[Actualizado]
Gráfica 8: Diagrama de Objetos “Enviar a Notaría”
Asesor de Trámite Documentario

1..* 0..*
0..*
Expediente
1..* (f rom Entidades)
Notaría
(f rom Actores)

Especificación del Caso de Uso del negocio “Tramitar Escritura Pública”
Cuadro 5: Caso de Uso “Tramitar Escritura Pública”
Caso de Uso del Negocio Tramitar Escritura Pública

218/
44
Propósito Tramitar Escritura Pública.
Se explicará el proceso que involucra el trámite de
Alcance
completar las firmas de la Escritura Pública.
Definiciones, Acrónimos
Ver Glosario
y Abreviaturas
Referencias • Diagrama de objetos del caso de uso Separar Inmueble.
• Diagrama de actividades del caso de Separar Inmueble.
Caso de Uso Enviar a Notaría.
Caso de Uso Registrar Desembolso.
Resumen:
El caso de uso Tramitar Escritura Pública describe el proceso que se realiza para lograr
una escritura pública correctamente firmada.
Medidas de
Una Escritura Pública firmada y archivada.
Rendimiento
Para tramitar una escritura pública se debe haber enviado a
Pre-condiciones
la notaría.
FLUJO DE EVENTOS
Actor Proceso
Asesor de Trámite 5. El Asesor de Trámite Documentario consulta el
Documentario expediente para ver su estado.
6. El Asesor de Trámite Documentario solicita las firmas.
7. El Banco firma la escritura pública.
8. El Cliente firma la escritura pública
9. El Asesor de Trámite Documentario verifica las firmas.
10. Si las firmas están OK se archiva la escritura pública
en el expediente, de lo contrario se solicitan nuevamente
las firmas.
Una escritura pública correctamente firmada y archivada en
Post-condiciones
el expediente.
Dueño del Proceso Asesor de Trámite Documentario.
Punto de Extensión No hay puntos de extensión
219/
44
Gráfica 9.: Diagrama de Actividades “Tramitar Escritura Pública”
: Cliente : Banco : Asesor de Trámite Documentario
Consultar
Expediente
: Expediente
[Consultado]
Firmar Escritura Solicitar Firmas

Pública
Firmar Escritura
Pública
Verificar Firmas
No
¿Firmas OK?
: Escritura Pública Si
[Firmada] Archivar Escritura Pública

en el Expediente
: Expediente
[Actualizado]
Gráfica 10: Diagrama de Objetos “Tramitar Escritura Pública”
1 0..*
Expediente
Asesor de Trámite Documentario 1 (f rom Entidades)
1..*
1 1
1..*
0..* Banco 0..* 0..* 1

(f rom Actores)
1 1
Escritura Pública
Cliente
(f rom Entidades)
(f rom Actores)
220/
44
Especificación del Caso de Uso del negocio “Registrar Desembolso”
Cuadro 6: Caso de Uso “Registrar Desembolso”
Caso de Uso del Negocio Registrar Desembolso

Actor Asesor Financiero
Propósito Registrar el desembolso del Banco.
Se explicará el proceso de la que involucra la
Alcance
verificación y el registro del desembolso.
Definiciones, Acrónimos y Ver Glosario
Abreviaturas
• Diagrama de objetos del caso de uso Registrar
Referencias Desembolso.
• Diagrama de actividades del caso de Registrar
Desembolso.
Caso de Uso Tramitar Escritura Pública
Caso de Uso Registrar Entregar Acta de Entrega
Resumen:
El caso de uso Registrar Desembolso, define el proceso para verificar que el
desembolso se haya concedido satisfactoriamente.
Medidas de Rendimiento Verificar con el banco el desembolso.
Se debe haber archivado la escritura pública al
Pre-condiciones
expediente.
FLUJO DE EVENTOS
Actor Proceso
Asesor Financiero 1. El asesor financiero verifica y consulta el expediente.
2. El asesor financiero realiza el seguimiento al
desembolso.
3. El Banco confirma el estado del desembolso.
4. Si el desembolso ha sido concedido el asesor
financiero registra la información referente al
desembolso en el expediente. De lo contrario el
asesor financiero volverá a hacer la verificación del
desembolso.
Se registra la información del desembolso en el
Post-condiciones
expediente.
Dueño del Proceso Asesor Financiero.
221/
44
Gráfica 11: Diagrama de Actividades “Registrar Desembolso”
: Banco : Asesor Financiero
Consutlar
Expediente
: Expediente
[Consultado] Realizar el seguimiento al

desembolso
Confirmar estado Verificar Desembolso

del desembolso con el Banco No
¿Desembolso
OK?
Si
Registrar Desembolso
en el Expediente
: Expediente
[Actualizado]
Gráfica 12: Diagrama de Objetos “Registrar Desembolso”
1 0..*
Expediente
Asesor Financiero (f rom Entidades)
1..*
0..*
Banco
(f rom Actores)
Especificación del Caso de Uso del negocio “Entregar Acta de Entrega”
Cuadro 7: Caso de Uso “Entregar Acta de Entrega”
Caso de Uso del Negocio Entregar Acta de Entrega

Actor Asesor de Control de Calidad.
Propósito Entregar el Acta de Entrega.
Alcance Se explicará el proceso de la Entrega del Acta de Entrega.
222/
44
y Abreviaturas
• Diagrama de objetos del caso de uso Entregar Acta de
Referencias Entrega.
• Diagrama de actividades del caso de uso Entregar Acta
de Entrega.
Caso de Uso Tramitar Registrar Desembolso.
Caso de Uso Tramitar Liquidar Tributos y Servicios.
Resumen:
El caso de uso Entregar Acta de Entrega detalla el proceso mediante el cual el asesor
de control de calidad entrega el acta de entrega y solicita la firma del cliente,
manifestando que el inmueble ha satisfecho las expectativas del cliente.
Medidas de Rendimiento Acta de Entrega firmado.
Para entregar la carta de entrega es necesario contar con la
Pre-condiciones
información del desembolso.
FLUJO DE EVENTOS
Actor Proceso
Asesor de Control de 1. El asesor de control de calidad consulta el expediente.
Calidad 2. El asesor de control de calidad imprime el acta de
entrega.
3. El asesor de control de calidad solicita la firma del
cliente.
4. Si no existen observaciones el cliente firma el acta de
entrega y el proceso termina, en caso de haber alguna
observación se deriva el caso al área legal.
Firma del acta de entrega en el caso de que el cliente no
tenga ninguna observación.
Post-condiciones
En caso exista alguna observación el caso es derivado al
área legal.
Dueño del Proceso El Asesor Legal.
223/
44
Gráfica 13: Diagrama de Actividades “Entregar Acta de Entrega”
: Cliente : Asesor de Control de Calidad

Fuente: Elaboración
Propia
Gráfica 14: Diagrama de

Consultar Objetos “Entregar Acta
Expediente
de Entrega”
: Expediente
[Consultado] Imprimir Acta

de Entrega
: Acta de Entrega
Solicitar Firma
del Cliente [Generada]
Firmar Acta de No ¿Existen

Entrega Ob servaciones?
Si
Derivar Caso al
Área Legal
Adjuntar Acta de Entrega

al Expediente
: Expediente
[Actualizado]
1 0..*
1 1
Expediente
0..* 1 1
Asesor de Control de Calidad (f rom Entidades)
(f rom Trabajadores) 1
Acta de Entrega
(f rom Entidades)
1
1
1
0..*
Cliente
(f rom Actores)
224/
44
Especificación del Caso de Uso del negocio “Liquidar Tributos y Servicios”
Cuadro 8: Caso de Uso “Liquidar Tributos y Servicios”
Caso de Uso del Negocio Liquidar Tributos y Servicios

Actor Asesor Financiero.
Propósito Liquidar los tributos y servicios.
Se explicará el proceso que involucra la liquidación de los
Alcance
tributos y servicios.
y Abreviaturas
• Diagrama de objetos del caso de uso Liquidación de
Referencias Tributos y Servicios.
•Diagrama de actividades del caso de uso Liquidación de
Tributos y Servicios
Caso de Uso Tramitar Entregar Acta de Entrega.
Caso de Uso Registrar Tramitar Inscripción.
Resumen:
El caso de uso Liquidar Tributos y Servicios define el proceso del registro de los pagos
por estos conceptos.
Monto total del monto de pago para la liquidación de
Medidas de Rendimiento
tributos y servicios cancelado.
Pre-condiciones Se debe haber firmado el acta de entrega.
FLUJO DE EVENTOS
Actor Proceso
Asesor Financiero 1. El asesor financiero verifica y consulta el expediente.
2. El asesor financiero verifica el pago de la liquidación
de tributos y servicios.
3. El cliente entrega el voucher de pago por el concepto
de liquidación de tributos y servicios.
4. El asesor financiero registra el pago en el expediente.
5. Si el pago se ha completado se archiva el expediente,
de lo contrario se continúa verificando el pago de la
liquidación de los tributos y servicios.
Se registra el pago de la liquidación de los tributos y
Post-condiciones
servicios.
Dueño del Proceso Asesor Financiero.
225/
44
Gráfica 15: Diagrama de Actividades “Liquidar Tributos y Servicios”
: Cliente : Asesor Financiero
: Voucher de Pago : Expediente
[Consultado] [Consultado]
Entregar Consultar
Voucher Expediente
Verificar Pago de Liquidación

de Tributos y Servicios
¿Pagos OK?
No
Si
Solicitar Pago Registra Pago en el

correcto al cliente Expediente
: Expediente
Archivar Expediente
[Actualizado]
Gráfica 16: Diagrama de Objetos “Liquidar Tributos y Servicios”
1 0..*
1
1 Expediente
Asesor Financiero (f rom Entidades)
(f rom Trabajadores) 1
1
0..*
1 0..*
0..*
1 0..*
Voucher de Pago
Cliente
(f rom Entidades)
(f rom Actores)
226/
44
Especificación del Caso de Uso del negocio “Tramitar Inscripción”
Cuadro 9: Caso de Uso “Tramitar Inscripción”
Caso de Uso del Negocio Tramitar Inscripción

Actor Asesor Legal
Propósito Tramitar Inscripción
Se explicará el proceso que involucra el Tramitar la
Alcance
Inscripción del inmueble.
y Abreviaturas
• Diagrama de objetos del caso de uso Tramitar
Referencias Inscripción.
• Diagrama de actividades del caso de Tramitar
Inscripción.
Casos de Uso asociados Caso de Uso Tramitar Liquidar Tributos y Servicios.
Resumen:
El caso de uso Tramitar Inscripción detalla el proceso de inscripción en registros
públicos y registros finales del inmueble adquirido.
Medidas de Rendimiento El detalle del Trámite de Inscripción del inmueble.
Para registrar el Trámite de Inscripción es necesario haber
Pre-condiciones
hecho la liquidación de tributos y servicios
FLUJO DE EVENTOS
Actor Proceso
Cliente 1. El asesor legal consulta el expediente.
2. El asesor legal tramita la inscripción en registros
públicos y registros finales.
3. El asesor legal registra la información de registros
públicos y finales en el expediente.
Se ha tramitado la inscripción en registros públicos y
registros finales (ficha de independización del inmueble,
Post-condiciones exoneración de la alcabala, envío de escritura a registros
públicos, cambio de propietario en la municipalidad,
levantamiento de hipoteca matrimonial).
Dueño del Proceso El Asesor Legal.
227/
44
Gráfica 17: Diagrama de Actividades “Tramitar Inscripción”
: Asesor Legal
Consultar
Expediente
: Expediente
[Consultado] Tramitar Inscripción en

Registros Públicos
Registrar la Inscripción en Registros

Públicos en el Expediente
Registrar la Inscripción de Registros : Expediente

Finales en el Expediente
[Actualizado]
: Expediente
[Actualizado]
Gráfica 18: Diagrama de Objetos “Tramitar Inscripción”
1 0..*
Expediente
Asesor Legal (f rom Entidades)
228/
44
Especificación del Caso de Uso del negocio “Gestionar Promoción”
Cuadro 10: Caso de Uso “Gestionar Promoción”
Caso de Uso del Negocio Gestionar Promoción

Actor Gerente Comercial.
Propósito Gestionar una promoción.
Se explicará el proceso que involucra la gestión de una
Alcance
promoción.
y Abreviaturas
• Diagrama de objetos del caso de uso Gestionar
Referencias Promoción.
• Diagrama de actividades del caso de uso Gestionar
Promoción.
Casos de Uso asociados No existen casos de uso asociados
Resumen:
El caso de uso Gestionar Promoción define el proceso mediante el cual se
administran las promociones de la empresa.
Medidas de Rendimiento Una promoción creada, actualizada o eliminada.
Para definir una promoción es necesaria contar con la
Pre-condiciones información del catálogo de proyectos, porque las
promociones trabajan en base a los proyectos.
FLUJO DE EVENTOS
Actor Proceso
Gerente Comercial 1. El gerente comercial consulta el Catálogo de
Promociones.
2. El gerente comercial define lo que desea hacer.
3. Si desea eliminar, se elimina la promoción y acaba
el proceso.
4. En caso contrario, define el proyecto, modelo,
etapa, tipo de inmueble, inmueble y forma de pago.
5. El gerente comercial define la promoción.
Post-condiciones Una promoción creada, actualizada o eliminada.
Dueño del Proceso El Gerente Comercial.
Requisitos Especiales No se han encontrado requisitos especiales
229/
44
Gráfica 19: Diagrama de Actividades “Gestionar Promoción”
: Gerente General
Consultar Catálogo de
Promociones
: Catálogo de Promociones ¿Fecha Si Eliminar

Expirada? Promoción
[Consultado]
No
Definir Proyecto
Definir Modelo
: Promoción : Catálogo de Promociones
Definir Etapa [Eliminada] [Actualizado]
: Catálogo de Proyectos
Definir Tipo de
[Consultado] Inmueble
Definir
Inmueble
Definir Forma
de Pago : Promoción
[Actualizada]
Definir
Promoción
: Catálogo de Promociones
[Actualizado]
Gráfica 20: Diagrama de Objetos “Gestionar Promoción”
1
1
Catálogo de Promociones
(f rom Entidades) 0..*
1
1 0..*
1
Promoción
Gerente Comercial 1 (f rom Entidades)
(f rom Actores)
Catálogo de Proyectos
(f rom Entidades)
230/
44
Especificación del Caso de Uso del negocio “Gestionar Campaña”
Cuadro 11: Caso de Uso “Gestionar Campaña”
Caso de Uso del Negocio Gestionar Campaña

Actor Gerente Comercial.
Propósito Gestionar una campaña.
Se explicará el proceso que involucra la gestión de una
Alcance
campaña.
y Abreviaturas
• Diagrama de objetos del caso de uso Gestionar
Referencias Campaña.
• Diagrama de actividades del caso de uso Gestionar
Campaña.
Casos de Uso asociados No existen casos de uso asociados
Resumen:
El caso de uso Gestionar Campaña, define el proceso mediante el cual se administran
las campañas de la empresa.
Medidas de Rendimiento Una campaña creada, actualizada o eliminada.
Pre-condiciones No existen pre - condiciones
FLUJO DE EVENTOS
Actor Proceso
Gerente Comercial 1. El gerente comercial consulta el Catálogo de
Campañas.
2. El gerente comercial define lo que desea hacer.
3. Si desea eliminar, elimina la campaña y acaba el
proceso.
4. En caso contrario el gerente comercial define la
campaña.
Post-condiciones Una campaña creada, actualizada o eliminada.
Dueño del Proceso El Gerente Comercial.
Requisitos Especiales No se han encontrado requisitos especiales
231/
44
Gráfica 21: Diagrama de Actividades “Gestionar Campaña”
: Gerente Comercial
Consultar Catálogo de
Campañas
: Catálogo de Campañas ¿Desea Eliminar

Eliminar? Campaña
[Consultado]
Definir Campaña
: Campaña : Catálogo de Campañas
[Eliminada] [Actualizado]
: Campaña : Catálogo de Campañas
[Actualizada] [Actualizado]
Gráfica 22: Diagrama de Objetos “Gestionar Campaña”
1
Catálogo de Campañas
1 (f rom Entidades)
1
1
Gerente Comercial
(f rom Actores)
0..*
0..*
Campaña
(f rom Entidades)
232/
44
ANEXO 2
ESPECIFICACIONES DE LOS CASOS DE USO DEL SISTEMA
Especificación del Caso de Uso del Sistema: “Tramitar Minuta”
Cuadro 1: ECUS “Tramitar Minuta”

Nombre de Caso de Uso Tramitar Minuta
Tipo Primario
Actores Asesor de Trámite Documentario
Breve Descripción Este caso de uso brinda la funcionalidad de tramitar una minuta.
1. Este caso de uso inicia cuando el Asesor de Trámite Documentario elige la
opción “Tramitar Minuta”.
2. El sistema muestra la pantalla con las opciones para generar la Minuta y los
anexos.
3. El Asesor de Trámite Documentario genera la minuta y los dos anexos de la
minuta.
4. El sistema muestra el formulario para registrar la fecha de las firmas de la
minuta.
5. El Asesor de Trámite Documentario registra las fechas de las firmas de la
minuta.
6. Si todas las firmas están completas el Sistema muestra un formulario con la
opción para Escanear la Minuta.
7. El Asesor de Trámite Documentario escanea la minuta en la opción
“Seleccionar archivo”.
8. El sistema guarda la información registrada en el expediente.
Flujo Alternativo:
1. En el paso 2 si el cliente no ha cancelado lo correspondiente a la inicial, el
sistema no le permitirá generar la minuta ni los anexos.
Requerimientos Especiales El tiempo de respuesta del sistema no debe exceder de 6 segundos.
Pre – Condiciones El usuario debe iniciar sesión para utilizar el sistema
El usuario debe contar con los permisos respectivos para acceder a esta
funcionalidad.
Post - Condiciones El sistema registra el trámite de la minuta.
El sistema registra el número de veces que es generada la Minuta.
233/
44
Gráfica 1: Prototipo CUS “Tramitar Minuta”
Especificación del Caso de Uso del Sistema: “Enviar a Notaría”
Cuadro 2: ECUS “Enviar a Notaría”

Nombre de Caso de Uso Enviar a Notaría
Tipo Primario
Breve Descripción Este caso de uso registra el envío del expediente a la notaría.
opción “Enviar a Notaría”.
2. El sistema muestra la pantalla con las opciones para definir la notaría a la
cual se enviará el expediente, el mail de contacto y el número de Kardex.
3. El Asesor de Trámite Documentario elige la opción “Guardar”.
Flujo Alternativo:
1. En el punto 3 si el número de Kardex no se registra en este paso, puede ser
registrado posteriormente.
funcionalidad.
Post - Condiciones El sistema registra el envío a la notaría en el expediente.
234/
44
Gráfica 2: Prototipo CUS “Enviar a Notaría”
Especificación del Caso de Uso del Sistema: “Tramitar Escritura Pública”
Cuadro 3: ECUS “Tramitar Escritura Pública”

Nombre de Caso de Uso Tramitar Escritura Pública
Tipo Primario
Breve Descripción Este caso de uso registra el envío del expediente a la notaría.
opción “Tramitar Escritura Pública”.
2. El sistema muestra la pantalla con las opciones para registrar las fechas en
las que se ha firmado la escritura pública.
3. El Asesor de Trámite Documentario registra las fechas en las que se firmó
la Escritura Pública y elige la opción “Registrar”.
funcionalidad.
Post - Condiciones El sistema registra las fechas de la firma de la Escritura Pública.
235/
44
Gráfica 3: Prototipo CUS “Tramitar Escritura Pública”
Especificación del Caso de Uso del Sistema: “Registrar Desembolso”
Cuadro 4: ECUS “Registrar Desembolso”

Nombre de Caso de Uso Registrar Desembolso
Tipo Primario
Actores Asesor Financiero
Breve Descripción Este caso de uso registra el desembolso.
1. Este caso de uso inicia cuando el asesor financiero elige la opción “Registrar
Desembolso”.
2. El sistema muestra la pantalla con las opciones para registrar los datos del
desembolso.
3. El asesor financiero define los datos del desembolso: número de desembolso,
monto, número de cuenta, fecha y luego elige la opción “Guardar”.
4. El sistema guarda los datos del registro del desembolso.
funcionalidad.
Post - Condiciones El sistema registra la información del desembolso.
236/
44
Gráfica 4: Prototipo CUS “Registrar Desembolso”
Especificación del Caso de Uso del Sistema: “Entregar Acta de Entrega”
Cuadro 5: ECUS “Entregar Acta de Entrega”

Nombre de Caso de Uso Entregar Acta de Entrega
Tipo Primario.
Actores Asesor de Control de Calidad
Breve Descripción Este caso de uso registra la entrega del acta de entrega.
1. Este caso de uso inicia cuando el asesor de control de calidad selecciona la
opción “Entregar Acta de Entrega”.
2. El sistema muestra la pantalla para registrar la información referente a la
entrega del acta de entrega.
3. El asesor legal registra la información indicando la fecha de generación del
acta de entrega, la fecha de la firma del acta de entrega, y el escaneado del
acta de entrega firmada, luego elige la opción “Guardar”.
4. El sistema guarda los datos registrados
funcionalidad.
Post - Condiciones El sistema registra la información referente al acta de entrega.
237/
44
Gráfica 5: Prototipo CUS “Entregar Acta de Entrega”
Especificación del Caso de Uso del Sistema: “Liquidar Tributos y Servicios”
Cuadro 6: ECUS “Liquidar Tributos y Servicios”

Nombre de Caso de Uso Liquidar Tributos y Servicios
Tipo Primario
Breve Descripción Este caso de uso registra el pago de los tributos y servicios por parte del cliente.
1. Este caso de uso inicia cuando el asesor financiero elige la opción “Liquidar
Tributos y Servicios”.
2. El sistema muestra la pantalla con las opciones para registrar los pagos de la
liquidación de tributos y servicios.
3. El asesor financiero define los datos de la liquidación de los tributos y
servicios: tanto para la liquidación de los tributos y servicios el monto,
número de voucher y la opción para adjuntar este voucher, además la fecha
de depósito; luego el asesor financiero elige la opción “Registrar”.
Flujo Alternativo:
1. En el punto 3, en el caso de que ambos pagos los haya hecho en un solo
tiempo y cuente con un solo voucher, sólo adjunta un documento.
Los datos deben viajar encriptados.
funcionalidad.
Post - Condiciones El sistema registra la liquidación de tributos y servicios.
238/
44
Gráfica 6: Prototipo CUS “Liquidar Tributos y Servicios”
Especificación del Caso de Uso del Sistema: “Tramitar Inscripción”
Cuadro 7: ECUS “Tramitar Inscripción”

Nombre de Caso de Uso Tramitar Inscripción
Tipo Primario.
Actores Asesor Legal
Breve Descripción Este caso de uso registra el trámite de inscripción.
1. Este caso de uso inicia cuando el asesor legal selecciona la opción “Tramitar
Inscripción”.
2. El sistema muestra el formulario para registrar el trámite de inscripción.
3. El asesor legal registra los trámites de registros públicos y registros generales,
luego elige la opción “Guardar”.
funcionalidad.
Post - Condiciones El sistema registra el trámite de inscripción.
239/
44
Gráfica 7: Prototipo CUS “Tramitar Inscripción”
Especificación del Caso de Uso del Sistema: “Registrar Contrato de Separación”
Cuadro 8: ECUS “Registrar Contrato de Separación”

Nombre de Caso de Uso Registrar Contrato de Separación
Tipo Primario.
Breve Descripción Este caso de uso registra el contrato de separación.
1. Este caso de uso inicia cuando el asesor legal selecciona la opción “Registrar
Contrato de Separación”.
2. El sistema muestra la pantalla para registrar el contrato de separación.
3. El asesor legal registra el nombre, una descripción, el archivo adjunto del
contrato y luego elige la opción “Guardar”.
4. El sistema registra el modelo único de Contrato de Separación
Flujo Alternativo:
1. En el punto 3 si el modelo del contrato de separación ya ha sido adjuntado
el asesor legal tiene la opción de cambiar de archivo.
funcionalidad.
Post - Condiciones El sistema registra el modelo único del contrato de separación.
240/
44
Gráfica 8: Prototipo CUS “Registrar Contrato de Separación”
Especificación del Caso de Uso del Sistema: “Registrar Minuta”
Cuadro 9: ECUS “Registrar Minuta”

Nombre de Caso de Uso Registrar Contrato Minuta
Tipo Primario.
Breve Descripción Este caso de uso registra la minuta.
Minuta”.
2. El sistema muestra la pantalla para registrar la minuta.
4. El sistema registra el modelo único de Minuta.
Flujo Alternativo:
1. En el punto 3 si el modelo de la minuta ya ha sido adjuntado el asesor legal
tiene la opción de cambiar de archivo.
funcionalidad.
Post - Condiciones El sistema registra el modelo único de la minuta.
241/
44
Gráfica 9: Prototipo CUS “Registrar Minuta”
Especificación del Caso de Uso del Sistema: “Registrar Acta de Entrega”
Cuadro 10: ECUS “Registrar Acta de Entrega”

Nombre de Caso de Uso Registrar Acta de Entrega
Tipo Primario.
Breve Descripción Este caso de uso registra el contrato de separación.
Acta de Entrega”.
2. El sistema muestra la pantalla para registrar el acta de entrega.
4. El sistema registra el modelo único de Acta de Entrega.
Flujo Alternativo:
1. En el punto 3 si el modelo del acta de entrega ya ha sido adjuntado el asesor
legal tiene la opción de cambiar de archivo.
funcionalidad.
Post - Condiciones El sistema registra el modelo único de acta de entrega.
242/
44
Gráfica 10: Prototipo CUS “Registrar Acta de Entrega”
Especificación del Caso de Uso del Sistema: “Ver detalle del Expediente”
Cuadro 11: ECUS “Ver detalle del Expediente”

Nombre de Caso de Uso Ver detalle del Expediente
Tipo Primario.
Actores Usuario.
Breve Descripción En este caso de uso se muestra el detalle completo de un expediente.
1. El caso de uso se inicia cuando el usuario decide ver el detalle del expediente
y elige la opción “Listar Expedientes” realiza una búsqueda. y tiene un
resultado exitoso.
2. EL sistema le muestra los expedientes que son el resultado de su búsqueda.
3. El usuario elige la opción “Ver detalle”.
4. El sistema le muestra el amplio detalle del expediente.
funcionalidad.
Post - Condiciones El sistema muestra el detalle de un determinado expediente.
243/
44
Gráfica 11: Prototipo CUS “Buscar Expediente”

Gráfica 12: Prototipo CUS “Buscar Expediente – Resultado por fechas”
244/
44
Gráfica 13: Prototipo CUS “Buscar Expediente – Resultado por días”
245/
44
Gráfica 14: Prototipo CUS “Ver detalle del expediente” – Vista detalle del expediente
246/
44
Especificación del Caso de Uso del Sistema: “Gestionar Proyecto”
Cuadro 12: ECUS “Gestionar Proyecto”

Nombre de Caso de Uso Gestionar Proyecto
Tipo Primario.
Breve Descripción Este caso de uso brinda la funcionalidad de registrar, actualizar, eliminar y ver
un proyecto.
1. Este caso de uso inicia cuando el Gerente de Operaciones selecciona la
opción “Gestionar Proyecto”.
2. El sistema muestra la pantalla correspondiente a la gestión de proyectos.
3. El gerente de operaciones escoge la opción “Registrar”.
4. El sistema le muestra la pantalla correspondiente al registro de un nuevo
proyecto.
5. El gerente de operaciones registra los datos generales como: nombre,
empresa, banco estructurador, estado, rango de precios, código Techo
Propio, número de pisos, video en Youtube, ubicación en google Maps, fotos
(para la galería de fotos), y luego el gerente de operaciones elige la opción
“Guardar”.
Flujo Alternativo:
1. En el punto 3 el gerente de operaciones tiene otras opciones como
“Actualizar”, “Eliminar” y “Ver detalle”.
2. En la opción “Actualizar”, sigue los mismos pasos del flujo básico, con la
única diferencia de que el sistema le carga los datos pertenecientes al registro
del proyecto y el gerente de operaciones actualiza los datos.
3. En la opción “Eliminar”, el sistema le muestra el detalle del proyecto, con la
opción “Eliminar”, si el gerente de operaciones elige esta opción, el registro
del proyecto se elimina.
4. En la opción “Ver detalle” el gerente de operaciones puede ver el detalle del
proyecto seleccionado.
funcionalidad.
Post - Condiciones El sistema registra, actualiza, elimina o muestra el detalle de un proyecto.
247/
44
Gráfica 15: Prototipo CUS “Gestionar Proyecto”
Especificación del Caso de Uso del Sistema: “Gestionar Tipo de Inmueble”
Cuadro 13: ECUS “Gestionar Tipo de Inmueble”

Nombre de Caso de Uso Gestionar Tipo de Inmueble
Tipo Primario.
un tipo de inmueble.
opción “Gestionar Tipo de Inmueble”.
2. El sistema muestra la pantalla correspondiente a la gestión de tipos de
inmuebles.
4. El sistema le muestra la pantalla correspondiente al registro de un nuevo tipo
de inmueble.
5. El gerente de operaciones registra los datos generales como: código y
nombre, luego el gerente de operaciones elige la opción “Guardar”.
Flujo Alternativo:
del tipo de inmueble.
248/
44
3. En la opción “Eliminar”, el sistema le muestra el detalle del tipo de inmueble,
con la opción “Eliminar”, si el gerente de operaciones elige esta opción, el
registro del tipo de inmueble se elimina.
4. En la opción “Ver detalle” el gerente de operaciones puede ver el detalle del
tipo de inmueble seleccionado.
funcionalidad.
Post - Condiciones El sistema registra, actualiza, elimina o muestra el detalle de un tipo de inmueble.
Gráfica 16: Prototipo CUS “Gestionar Tipo de Inmueble”
uente: Elaboración Propia.
Especificación del Caso de Uso del Sistema: “Gestionar Tipología”
Cuadro 14: ECUS “Gestionar Tipología”

Nombre de Caso de Uso Gestionar Tipología
Tipo Primario.
una tipología (o modelo).
opción “Gestionar Modelo”.
2. El sistema muestra la pantalla correspondiente a la gestión de tipologías.
3. El gerente de operaciones selecciona el proyecto en el cuál desea gestionar
las tipologías.
4. El sistema le muestra la lista de las tipologías que pertenecen al proyecto
seleccionado.
6. El sistema le muestra la pantalla correspondiente al registro de una nueva
tipología.
7. El gerente de operaciones registra los datos generales como: nombre,
programa, número de cuartos, número de baños, video en Youtube, número
de cocheras, número de jardines, número de lavanderías, número de áreas de
servicio y la descripción corta y detallada, luego el gerente de operaciones
elige la opción “Guardar”.
Flujo Alternativo:
249/
44
de la tipología.
3. En la opción “Eliminar”, el sistema le muestra el detalle del modelo, con la
de la tipología se elimina.
4. En la opción “Ver detalle” el gerente de operaciones puede ver el detalle de
la tipología seleccionada.
funcionalidad.
Post - Condiciones El sistema registra, actualiza, elimina o muestra el detalle de una tipología.
Gráfica 17: Prototipo CUS “Gestionar Tipología”
Especificación del Caso de Uso del Sistema: “Gestionar Etapa”
Cuadro 15: ECUS “Gestionar Etapa”

Nombre de Caso de Uso Gestionar Etapa
Tipo Primario.
una etapa.
opción “Gestionar Etapa”.
2. El sistema muestra la pantalla correspondiente a la gestión de etapas.
las etapas.
250/
44
4. El sistema le muestra la lista de las etapas que pertenecen al proyecto
seleccionado.
etapa.
7. El gerente de operaciones registra los datos generales como: número, fecha
de registro, fecha de entrega, fecha máxima de pago sin interés y descripción,
luego el gerente de operaciones elige la opción “Guardar”.
Flujo Alternativo:
de la etapa.
3. En la opción “Eliminar”, el sistema le muestra el detalle de la etapa, con la
de la etapa se elimina.
la etapa seleccionada.
funcionalidad.
Post - Condiciones El sistema registra, actualiza, elimina o muestra el detalle de una etapa.
Gráfica 18: Prototipo CUS “Gestionar Etapa”
251/
44
Especificación del Caso de Uso del Sistema: “Gestionar Observación”
Cuadro 16: ECUS “Gestionar Observación”

Nombre de Caso de Uso Gestionar Observación
Tipo Secundario
una observación.
opción “Gestionar Observación”.
2. El sistema muestra la pantalla correspondiente a la gestión de observaciones.
las observaciones.
4. El sistema le muestra la lista de las observaciones que pertenecen al proyecto
seleccionado.
observación.
7. El gerente de operaciones registra los datos generales como: descripción,
modelo y etapa, luego el gerente de operaciones elige la opción “Guardar”.
Flujo Alternativo:
de la observación.
3. En la opción “Eliminar”, el sistema le muestra el detalle de la observación,
con la opción “Eliminar”, si el gerente de operaciones elige esta opción, el
registro de la observación se elimina.
la observación.
funcionalidad.
Post - Condiciones El sistema registra, actualiza, elimina o muestra el detalle de una observación.
252/
44
Gráfica 19: Prototipo CUS “Gestionar Observaciones”
Especificación del Caso de Uso del Sistema: “Gestionar Empresa”
Cuadro 17: ECUS “Gestionar Empresa”

Nombre de Caso de Uso Gestionar Empresa
Tipo Secundario.
una empresa.
1. Este caso de uso inicia cuando el asesor financiero selecciona la opción
“Gestionar Empresa”.
2. El sistema muestra la pantalla correspondiente a la gestión de empresas.
3. El asesor financiero elige la opción “Registrar”
empresa.
5. El asesor financiero define el ruc, razón social, dirección, estado y datos de
los representantes legales (DNI, nombres y apellidos, título y cargo que
desempeña) y luego escoge la opción “Guardar”.
Flujo Alternativo:
1. En el punto 3 el asesor financiero tiene otras opciones como “Actualizar”,
“Eliminar” y “Ver detalle”.
de la empresa.
253/
44
3. En la opción “Eliminar”, el sistema le muestra el detalle de la empresa, si el
asesor financiero elige la opción “Eliminar” el sistema elimina el registro de
la empresa.
4. En la opción “Ver detalle” el asesor financiero puede ver el detalle de la
empresa.
funcionalidad.
Post - Condiciones El sistema registra, actualiza, elimina o muestra el detalle de una empresa.
Gráfica 20: Prototipo CUS “Gestionar Empresa”
Especificación del Caso de Uso del Sistema: “Gestionar Apoderado”
Cuadro 18: ECUS “Gestionar Actividad”

Nombre de Caso de Uso Gestionar Apoderado
Tipo Primario.
Actores Usuario
un apoderado.
1. Este caso de uso inicia cuando el usuario selecciona la opción “Gestionar
Apoderado”.
2. El sistema muestra la pantalla correspondiente a la gestión de los
apoderados.
3. El usuario escoge la opción “Registrar”.
4. El sistema le muestra la pantalla correspondiente al registro del apoderado.
5. El usuario registra los datos generales como: Empresa, nombre, correo,
teléfono y luego elige la opción “Guardar”
Flujo Alternativo:
1. En el punto 3 el usuario tiene otras opciones como “Actualizar”, “Eliminar”
y “Ver detalle”.
del apoderado.
254/
44
3. En la opción “Eliminar”, el sistema le muestra el detalle de la actividad, con
la opción “Eliminar”, si el usuario elige esta opción, el registro del apoderado
se elimina.
4. En la opción “Ver detalle” el usuario puede ver el detalle del apoderado
seleccionado.
funcionalidad.
Post - Condiciones El sistema registra, actualiza, elimina o muestra el detalle de un apoderado.
Gráfica 21: Prototipo CUS “Gestionar Apoderado”
Especificación del Caso de Uso del Sistema: “Gestionar Banco”
Cuadro 19: ECUS “Gestionar Banco”

Nombre de Caso de Uso Gestionar Banco
Tipo Secundario.
un Banco.
“Gestionar Banco”.
2. El sistema muestra la pantalla correspondiente a la gestión de Bancos o IFIs
(Instituciones Financieras Interbancarias).
3. El asesor financiero escoge la opción “Registrar”.
banco.
5. El asesor financiero registra los datos generales como: código y nombre, y
Flujo Alternativo:
única diferencia de que el sistema le carga los datos pertenecientes al banco.
3. En la opción “Eliminar”, el sistema le muestra el detalle de la IFI, al elegir
la opción “Eliminar”, el registro del banco se elimina.
255/
44
4. En la opción “Ver detalle” el asesor financiero puede ver el detalle del grupo
de ventas seleccionado.
funcionalidad.
Post - Condiciones El sistema registra, actualiza, elimina o muestra el detalle de un banco.
Gráfica 22: Prototipo CUS “Gestionar Banco”
Especificación del Caso de Uso del Sistema: “Gestionar Notaría”
Cuadro 20: ECUS “Gestionar Notaría”
Nombre de Caso de Uso Gestionar Notaría

Tipo Secundario.
una notaría.
“Gestionar Notaría”.
2. El sistema muestra la pantalla correspondiente a la gestión de notarías.
notaría.
5. El asesor financiero registra los datos generales como: nombre, correo
principal, correo auxiliar 1 y correo auxiliar 2 y luego elige la opción
“Guardar”.
Flujo Alternativo:
única diferencia de que el sistema le carga los datos pertenecientes a la
notaría.
3. En la opción “Eliminar”, el sistema le muestra el detalle de la notaría, al
elegir la opción “Eliminar”, el registro de la notaría se elimina.
notaría seleccionada.
256/
44
funcionalidad.
Post - Condiciones El sistema registra, actualiza, elimina o muestra el detalle de una notaría.
Gráfica 23: Prototipo CUS “Gestionar Notaría”
Especificación del Caso de Uso del Sistema: “Gestionar Punto de Venta”
Cuadro 21: ECUS “Gestionar Punto de Venta”

Nombre de Caso de Uso Gestionar Punto de Venta
Tipo Secundario.
un punto de venta.
“Gestionar Punto de Venta”.
2. El sistema muestra la pantalla correspondiente a la gestión de puntos de
venta.
punto de venta.
5. El asesor financiero registra los datos generales como: nombre y dirección,
y luego elige la opción “Guardar”.
Flujo Alternativo:
única diferencia de que el sistema le carga los datos pertenecientes al punto
de venta.
3. En la opción “Eliminar”, el sistema le muestra el detalle del punto de venta,
al elegir la opción “Eliminar”, el registro del punto de venta se elimina.
4. En la opción “Ver detalle” el asesor financiero puede ver el detalle del punto
de venta seleccionado.
funcionalidad.
Post - Condiciones El sistema registra, actualiza, elimina o muestra el detalle de un Punto de Venta
257/
44
Gráfica 24: Prototipo CUS “Gestionar Punto de Venta”
Especificación del Caso de Uso del Sistema: “Gestionar Forma de Pago”
Cuadro 22: ECUS “Gestionar Forma de Pago”

Nombre de Caso de Uso Gestionar Forma de Pago
Tipo Secundario.
una forma de pago.
“Gestionar Forma de Pago”.
2. El sistema muestra la pantalla correspondiente a la gestión de formas de
pago.
forma de pago.
5. El asesor financiero registra los datos generales como: código, descripción y
Flujo Alternativo:
única diferencia de que el sistema le carga los datos pertenecientes a la forma
de pago.
3. En la opción “Eliminar”, el sistema le muestra el detalle de la forma de pago,
al elegir la opción “Eliminar”, el registro de la forma de pago se elimina.
forma de pago seleccionada.
funcionalidad.
Post - Condiciones El sistema registra, actualiza, elimina o muestra el detalle de una forma de pago.
258/
44
Gráfica 25: Prototipo CUS “Gestionar Forma de Pago”
Especificación del Caso de Uso del Sistema: “Gestionar Equipo de Ventas”
Cuadro 23: ECUS “Gestionar Equipo de Ventas”

Nombre de Caso de Uso Gestionar Equipo de Ventas
Tipo Secundario.
Actores Gerente Comercial
un equipo de ventas.
1. Este caso de uso inicia cuando el Gerente Comercial selecciona la opción
“Gestionar Equipo de Ventas”.
2. El sistema muestra la pantalla correspondiente a la gestión del equipo de
ventas.
3. El gerente comercial escoge la opción “Registrar”.
agente de ventas.
5. El gerente comercial registra los datos generales como: usuario, rol y fecha
y luego selecciona la opción “Guardar”.
Flujo Alternativo:
1. En el punto 3 el gerente comercial tiene otras opciones como “Actualizar”,
del agente de ventas.
3. En la opción “Eliminar”, el sistema le muestra el detalle del agente de ventas,
con la opción “Eliminar”, si el gerente elige esta opción, el registro del
agente se elimina.
4. En la opción “Ver detalle” el gerente de ventas puede ver el detalle del agente
de ventas seleccionado.
259/
44
funcionalidad.
Post - Condiciones El sistema registra, actualiza, elimina o muestra el detalle de un agente de ventas.
Gráfica 26: Prototipo CUS “Gestionar Equipo de Ventas”
Especificación del Caso de Uso del Sistema: “Gestionar Promoción”
Cuadro 24: ECUS “Gestionar Promoción”

Nombre de Caso de Uso Gestionar Promoción
Tipo Secundario.
una promoción.
“Gestionar Promoción”.
2. El sistema muestra la pantalla correspondiente a la gestión de promociones.
3. El gerente comercial define el proyecto en el cual se desea registrar una
nueva promoción.
promoción.
6. El gerente comercial registra los datos generales como: nombre, tipo,
descripción, fecha de inicio y fin, modelo, etapa, tipo de inmueble, forma de
pago y adjuntar brochure, y luego elige la opción “Guardar”.
Flujo Alternativo:
de la promoción.
3. En la opción “Eliminar”, el sistema le muestra el detalle de la promoción,
con la opción “Eliminar”, si el gerente elige esta opción, el registro de la
promoción se elimina.
4. En la opción “Ver detalle” el gerente comercial puede ver el detalle de la
promoción seleccionada.
260/
44
funcionalidad.
Post - Condiciones El sistema registra, actualiza, elimina o muestra el detalle de una promoción.
Gráfica 27: Prototipo CUS “Gestionar Promoción”
Especificación del Caso de Uso del Sistema: “Gestionar Campaña”
Cuadro 25: ECUS “Gestionar Campaña”

Nombre de Caso de Uso Gestionar Campaña
Tipo Secundario.
una campaña.
“Gestionar Campaña”.
2. El sistema muestra la pantalla correspondiente a la gestión de campañas.
campaña.
5. El gerente comercial registra los datos generales como: nombre,
observación, estado, tipo, respuesta prevista, rango de fechas, planificación
de ingresos, gasto real, gasto previsto, y luego elige la opción “Guardar”.
Flujo Alternativo:
de la campaña.
3. En la opción “Eliminar”, el sistema le muestra el detalle de la campaña, con
la opción “Eliminar”, si el gerente elige esta opción, el registro de la campaña
se elimina.
4. En la opción “Ver detalle” el gerente comercial puede ver el detalle de la
campaña seleccionada.
funcionalidad.
Post - Condiciones El sistema registra, actualiza, elimina o muestra el detalle de una campaña.
261/
44
Gráfica 28: Prototipo CUS “Gestionar Campaña”
Especificación del Caso de Uso del Sistema: “Gestionar Actividad”
Cuadro 26: ECUS “Gestionar Actividad”

Nombre de Caso de Uso Gestionar Actividad
Tipo Primario.
Actores Usuario
una actividad.
1. Este caso de uso inicia cuando el usuario selecciona la opción “Gestionar
Actividad”.
2. El sistema muestra la pantalla correspondiente a la gestión de la agenda (en
la que se encuentran las actividades desplegadas en 3 vistas: por día, por mes
y por año).
3. El usuario escoge la opción “Registrar”.
4. El sistema le muestra la pantalla correspondiente al registro de la actividad.
5. El usuario registra los datos generales como: tipo de actividad, prioridad,
rango de tiempos, cliente, etc. Y elige la opción “Guardar”
Flujo Alternativo:
a. En el punto 3 el usuario tiene otras opciones como “Actualizar”, “Eliminar”
y “Ver detalle”.
b. En la opción “Actualizar”, sigue los mismos pasos del flujo básico, con la
de la actividad.
c. En la opción “Eliminar”, el sistema le muestra el detalle de la actividad, con
la opción “Eliminar”, si el usuario elige esta opción, el registro de la
actividad se elimina.
d. En la opción “Ver detalle” el usuario puede ver el detalle de la actividad
seleccionada.
funcionalidad.
Post - Condiciones El sistema registra, actualiza, elimina o muestra el detalle de una actividad.
262/
44
Gráfica 29: Prototipo CUS “Gestionar Actividad” – Vista Agenda
263/
44
Gráfica 30: Prototipo CUS “Gestionar Actividad” – Registrar Actividad
Especificación del Caso de Uso del Sistema: “Gestionar Usuario”
Cuadro 27: ECUS “Gestionar Usuario”

Nombre de Caso de Uso Gestionar Usuario
Tipo Primario.
Actores Administrador de la Seguridad
Breve Descripción Este caso de uso brinda la funcionalidad de registrar, actualizar, eliminar un
usuario.
1. Este caso de uso inicia cuando el Administrador de la Seguridad selecciona
la opción “Gestionar Usuario”.
2. El sistema muestra la pantalla correspondiente a la gestión de usuarios.
3. El Administrador de la Seguridad elige la opción “Registrar”.
4. El sistema le muestra la el formulario para registrar un usuario.
5. El Administrador de la Seguridad registra los siguientes campos: correo
electrónico, contraseña, la verificación de la contraseña, rol, estado,
nombres, apellidos, teléfono, celular, fax, web site, país, ciudad, distrito,
dirección y elige la opción “Guardar”.
Flujo Alternativo:
1. En el punto 3 el Administrador de la Seguridad tiene otras opciones como
del usuario.
264/
44
3. En la opción “Eliminar”, el sistema le muestra el detalle del usuario, con la
opción “Eliminar”, si el Administrador de la Seguridad elige esta opción, el
registro del usuario se elimina. En el caso de que existan entidades
relacionadas a este usuario, el sistema mostrará un mensaje comunicando
que el usuario no se puede eliminar.
4. En la opción “Ver detalle” el Administrador de la Seguridad puede ver el
detalle del usuario seleccionado.
funcionalidad.
Post - Condiciones El sistema registra, actualiza, elimina o muestra el detalle de un usuario.
Gráfica 31: Prototipo CUS “Gestionar Usuario”
Especificación del Caso de Uso del Sistema: “Gestionar Rol”
Cuadro 28: ECUS “Gestionar Rol”

Nombre de Caso de Uso Gestionar Rol
Tipo Primario.
un rol.
la opción “Gestionar Rol”.
265/
44
2. El sistema muestra la pantalla correspondiente a la gestión de roles.
3. El Administrador de la Seguridad escoge la opción “Registrar”.
4. El sistema le muestra la pantalla correspondiente al registro de un nuevo rol.
5. El Administrador de la Seguridad registra el nombre y elige la opción
“Guardar”.
Flujo Alternativo:
1. En el punto 3 el Administrador de la Seguridad tiene otras opciones como
del rol.En el caso de que existan usuarios registrados con ese rol, el sistema
mostrará un mensaje comunicando que el rol no se puede modificar.
3. En la opción “Eliminar”, el sistema le muestra el detalle del rol, con la opción
“Eliminar”, si el Administrador de la Seguridad elige esta opción, el registro
del rol se elimina. En el caso de que existan usuarios registrados con ese rol,
el sistema mostrará un mensaje comunicando que el rol no se puede
eliminar.
4. En la opción “Ver detalle” el Administrador de la Seguridad puede ver el
detalle del rol seleccionado.
funcionalidad.
Post - Condiciones El sistema registra, actualiza, elimina o muestra el detalle de un rol.
266/
44
Gráfica 32: Prototipo CUS “Gestionar Rol”
Especificación del Caso de Uso del Sistema: “Gestionar Permisos”
Cuadro 29: ECUS “Gestionar Permisos”

Nombre de Caso de Uso Gestionar Permisos
Tipo Primario.
Breve Descripción Este caso de uso brinda la funcionalidad de actualizar y ver los permisos de un
rol.
la opción “Gestionar Permisos”.
2. El sistema muestra la pantalla correspondiente a la gestión de permisos.
3. El Administrador de la Seguridad elige la opción “Actualizar Permisos” del
rol para del cual desea gestionar los permisos.
4. El sistema le muestra la pantalla correspondiente a la gestión de los permisos.
5. El Administrador de la Seguridad actualiza los permisos y elige la opción
“Guardar”.
Flujo Alternativo:
1. En el punto 3 el Administrador de la Seguridad tiene la opción de “Ver
detalle”. En la opción “Ver detalle” el Administrador de la Seguridad puede
ver el detalle de los permisos del rol.
funcionalidad.
Post - Condiciones El sistema actualiza o muestra el detalle de los permisos de un rol.
267/
44
Gráfica 33: Prototipo CUS “Gestionar Permisos”
Especificación del Caso de Uso del Sistema: “Iniciar Sesión”
Cuadro 30: ECUS “Iniciar Sesión”

Nombre de Caso de Uso Iniciar Sesión
Tipo Primario
Actores Usuario
Breve Descripción Este caso de uso se hará el inicio de sesión de un usuario registrado en el sistema.
1. Este caso de uso inicia cuando el usuario ingresa sus datos: usuario y
contraseña y selecciona la opción “Acceder”.
2. El sistema verifica los datos de la identificación del usuario, si es usuario
registrado le muestra una pantalla de bienvenida, con todas las opciones de
navegación y gestión en el sistema.
Flujo Alternativo:
1. En el punto 2 si los datos de identificación son erróneos, el sistema le
mostrará un mensaje indicando “El correo y/o contraseña son incorrectos”.
Pre – Condiciones El usuario debe estar registrado en el sistema para poder ingresar.
Post - Condiciones Un usuario accede al sistema.
Gráfica 34: Prototipo CUS “Iniciar Sesión”
268/
44
Especificación del Caso de Uso del Sistema: “Cerrar Sesión”
Cuadro 31: ECUS “Cerrar Sesión”

Nombre de Caso de Uso Cerrar Sesión
Tipo Primario
Actores Usuario
Breve Descripción Este caso de uso se hará el cierre de sesión de un usuario registrado en el sistema.
1. Este caso de uso inicia cuando el usuario selecciona la opción “Salir”.
2. El sistema cierra todas las pantallas del sistema y elimina de memoria toda
la información de usuario en ese instante. Y muestra la pantalla de Iniciar
Sesión.
Pre – Condiciones EL usuario debe haber iniciado sesión.
El usuario debe estar registrado en el sistema para poder ingresar.
Post - Condiciones Un usuario cierra sesión en el sistema.
Gráfica 35: Prototipo CUS “Cerrar Sesión”
269/
44
Especificación del Caso de Uso del Sistema: “Modificar Contraseña”
Cuadro 32: ECUS “Modificar Contraseña”

Nombre de Caso de Uso Modificar Contraseña
Tipo Primario
Actores Usuario
Breve Descripción Este caso de uso se hará la modificación y actualización de la contraseña.
1. Este caso de uso inicia cuando el usuario selecciona su nombre.
2. El sistema muestra el detalle de la información de la cuenta del usuario.
3. El usuario elige la opción “Actualizar datos de Ingreso”.
4. El sistema muestra la pantalla con las opciones para actualizar su contraseña.
5. El usuario registra la contraseña y vuelve a escribir la contraseña, luego elige
la opción “Actualizar”.
6. El sistema valida los campos ingresados y muestra un mensaje de “Sus datos
se han actualizado satisfactoriamente”.
Flujo Alternativo:
1. En el paso 5, si las contraseñas no coinciden, el sistema mostrará un mensaje
indicando que “Las contraseñas no coinciden”.
Post - Condiciones Un usuario cierra sesión en el sistema.
Gráfica 36: Prototipo CUS “Modificar Contraseña”
270/
44
Especificación del Caso de Uso del Sistema: “Recordar Contraseña”
Cuadro 33: ECUS “Recordar Contraseña”

Nombre de Caso de Uso Recordar Contraseña
Tipo Primario
Actores Usuario
Breve Descripción Este caso de uso se hará el recordatorio de la contraseña al usuario.
1. Este caso de uso inicia cuando el usuario selecciona la opción “Olvidaste tu
contraseña ¡Haz click aquí!”.
2. El sistema muestra la pantalla para que el usuario ingrese su correo
electrónico y de esta manera el usuario pueda recuperar su contraseña.
3. El usuario digita su correo electrónico y elige la opción “Recordar”.
4. El sistema procesa la información ingresada y envía la información
correspondiente al correo del usuario.
Flujo Alternativo:
1. En el paso 4 el usuario sigue los pasos detallados en el mail.
Post - Condiciones El sistema recuerda la contraseña al usuario.
Gráfica 37: Prototipo CUS “Recordar Contraseña”
271/
44
ANEXO 3
Diccionario de Clases
N° Clase Descripción
1 Actividad Una actividad de seguimiento, realizada para conseguir una venta

2 Agente Representa a una persona que pertenece al área de ventas.
3 Cargo de Agente Responsabilidad que se atribuye a alguien del área de ventas
4 Área Es la información que representa a las áreas o procesos de la empresa.
Contiene la información relacionada a las Instituciones Financieras Interbancarias
5 Banco
con las que trabaja la Empresa Constructora Inmobiliaria en el proceso de venta.
6 Banco Tasa Contiene la información actualizada de la tasa del banco
Contiene la información de las campañas de marketing que realiza la empresa (En
7 Campaña este caso representan al conjunto de actos que se dirigen a conseguir un fin
determinado en este caso publicitario)
Contiene la información de las ciudades a la que puede pertenecer un cliente o un
8 Ciudad
usuario del sistema
Representa a la persona que está interesada en comprar algún (o algunos)
9 Cliente
inmueble(s) de la Empresa Constructora Inmobiliaria.
Representa al documento que contiene la información del cliente interesado en una
10 Cotización
compra y del (de los) inmueble(s) de interés.
11 Cotización Detalle Contiene el detalle de la cotización.
Contiene la información de los documentos necesarios para la creación de un
12 Creación Expediente
expediente.
13 Desembolso Contiene la información del pago del desembolso de dinero por el lado del cliente.
Contiene la información de los distritos a la que puede pertenecer un cliente o un

14 Distrito
usuario del sistema
Contiene la información de las razones sociales que administra la Empresa
15 Empresa
Constructora Inmobiliaria
Contiene la información del registro de las actas de entrega que han sido entregadas
16 Acta de Entrega
a los clientes.
17 Envío a Notaría Contiene la información del registro del envío a la notaría de todos los expedientes.
Contiene la información del registro de aquellos expedientes que ya tienen las

18 Escritura Pública
firmas de la escritura pública.
Contiene la información de las etapas (entidad que agrupa un número determinado
19 Etapa
de bloques) de un proyecto.
272/
44
Contiene el resumen de venta de cada venta (desde la cotización hasta el Registro
20 Expediente
de Trámite de Inscripción)
21 Faq Contiene la información de las preguntas frecuentes.
Contiene la información de las formas de pago que administra la Empresa
22 Forma de Pago
23 Galería de Foto Contiene la información de las galerías de fotos de los proyectos y modelos.
24 Geoposición Contiene la información de la ubicación de los proyectos.
25 Grupo de Agentes Contiene la información de los grupos de agentes organizados con algún objetivo.
Contiene la información de los grupos de venta organizados por ciudades en las
26 Grupo de Venta
que se encuentra la Empresa Constructora Inmobiliaria.
Contiene la información de los inmuebles (bienes raíces) de la Empresa
27 Inmueble
Contiene la información de las tipologías (cada uno de los modelos) de los
28 Inmueble Modelo
proyectos.
Contiene la información de los tipos de inmueble de los proyectos, por ejemplo:
29 Inmueble Tipo
departamento flat, estacionamiento, depósito.
Liquidación de Tributos Contiene la información del registro de aquellos expedientes que ya tienen el pago
30
y Servicios de la liquidación de los tributos y servicios
Contiene la información de las metas de venta que establece la gerencia para el área
31 Meta
de ventas.
Contiene la información de aquellos expedientes que ya tienen registrada la firma
32 Minuta
de la minuta
Contiene la información de las notarias con las que trabaja la Empresa Constructora
33 Notaría
Inmobiliaria.
Contiene la información de aquellas observaciones que aparecen al final de la
34 Observación
cotización.
Contiene la información de todos los pagos que los clientes han realizado por el
35 Pago por Separación
concepto de separación.
Contiene la información de los países a los que puede pertenecer un cliente o un
36 País
usuario del sistema.
37 Persona Contiene los datos de la persona que está registrada como usuario del sistema.
Contiene la información de las promociones que realiza la empresa para impulsar
38 Promoción
sus ventas.
Contiene toda información importante de los proyectos que administra la Empresa
39 Proyecto
40 Proyecto Acta Contiene el registro de las actas de entrega asociadas a cada proyecto.
Contiene el registro de los modelos de los contrato de separación que administra la
41 Proyecto Contrato
Empresa Constructora Inmobiliaria
Contiene la información de las cuentas asociadas a cada uno de los proyectos que
42 Proyecto Cuenta
administra la Empresa Constructora Inmobiliaria.
273/
44
Contiene el registro de los modelos de minuta que administra la Empresa
43 Proyecto Minuta
Contiene la información de los puntos de venta de la Empresa Constructora
44 Punto de Venta
Inmobiliaria.
Contiene la información de los usuarios que han utilizado la opción recordar o
45 Recordar
cambiar contraseña.
Contiene la información de los recursos que administra el sistema, con ellos se
46 Recurso
asignan los permisos a los roles.
Contiene la información de las regiones a las que puede pertenecer un cliente o un
47 Región
usuario de sistema.
Contiene la información de los roles que pueden ser asociados a los usuarios del
48 Rol
sistema.
49 Separación Contiene la información de los expedientes que tienen una separación asociada.
Contiene la información de los expedientes que cuentan con el registro del trámite
50 Trámite de Inscripción
de inscripción-
51 Usuario Contiene la información de todos los usuarios que están registrados en el sistema.
274/
44
ANEXO 4
275/
44
ANEXO 5
Acceso
Comentarios de la tabla: acceso
Colum Tipo Nulo Predeterm Com entarios

na inado
id int(11) No
usuario_i int(11) No
d
fecha_hor datetime No
a
ip char(30) No
control char(50) No
accion char(50) No
url char(200) No
actividad
Comentarios de la tabla: actividad
Colum na Tipo Nulo Predeterm inado Com entarios

id char(20) No
proyecto_id int(3) Sí NULL
actividad_tipo_id tinyint(4) No 1
asunto varchar(120) Sí NULL
fecha_inicio datetime Sí NULL
fecha_vencimiento datetime Sí NULL
prioridad tinyint(4) Sí NULL
asignado_a int(11) Sí NULL
estado tinyint(4) Sí NULL
cliente_id int(11) Sí NULL
duracion_horas char(2) Sí NULL
duracion_minutos char(2) Sí NULL
aviso tinyint(4) Sí 0
descripcion text Sí NULL
autor_id_registro int(11) Sí NULL
autor_id_modificacion int(11) Sí NULL
fecha_registro datetime Sí NULL
276/
44
fecha_modificacion datetime Sí NULL
actividad_tipo
Comentarios de la tabla: Tipos de actividades
Colum Tipo Nulo Predeterm inado Com entarios

na
id tinyint(10) No
nombre char(20) Sí NULL
agencia
Comentarios de la tabla: agencia
Colum na Tipo Nulo Predeterm Com entarios

inado
id int(11) No
ciudad varchar(70) No
banco_nombr varchar(70) No
e
identificador varchar(100) No
agente
Comentarios de la tabla: agente

inado
id int(11) No
usuario_id int(11) No
padre_id int(11) No
proyecto_id int(3) No
cargo_id int(11) No
fecha date No
ultimo_grupo_i int(11) No
d
277/
44
agente_cargo
Comentarios de la tabla: agente_cargo

na
id int(11) No
nombre varchar(200) No
apoderado
Comentarios de la tabla: apoderado

id int(11) No
empresa_ruc varchar(13) No
nro_asiento varchar(100) No
dni int(8) No
nombre varchar(80) Sí NULL
correo varchar(70) Sí NULL
telefono varchar(20) Sí NULL
autor_id_registro int(11) No
fecha_registro datetime No
area
Comentarios de la tabla: area

na
id int(11) No
banco
Comentarios de la tabla: banco

id varchar(10) No
278/
44
tasa_anual double Sí NULL
banco_tasa
Comentarios de la tabla: banco_tasa

id int(11) No
banco_id varchar(10) No
tasa_anual double No
autor_id_registr int(11) No
o
bloque
Comentarios de la tabla: bloque

id int(20) No
etapa_numero int(11) No
numero varchar(50) No
descripcion varchar(200) No
279/
44
campania
Comentarios de la tabla: campania

inado
id int(11) No
empresa_ruc varchar(13) No
campania_situacion_id int(11) No
campania_tipo_id int(11) No
fecha_fin datetime Sí NULL
ingresos_planificados double Sí NULL
gasto_real double Sí NULL
gasto_previsto double Sí NULL
moneda varchar(20) Sí NULL
campania_situacion
Comentarios de la tabla: campania_situacion

id int(11) No

autor_id_modificacion int(11) No
fecha_modificacion datetime No
campania_tipo
Comentarios de la tabla: campania_tipo

id int(11) No
280/
44
ciudad
Comentarios de la tabla: ciudad

na
pais_id char(3) No
region_i int(10) No
d
ciudad_i int(11) No
d
nombre char(100) No
cliente
Comentarios de la tabla: cliente

inado
id int(11) No
estado varchar(20) Sí NULL
tipo_documento_id char(3) No
nro_documento char(12) No
nombres varchar(250) No
apellido_paterno varchar(250) Sí NULL
apellido_materno varchar(250) Sí NULL
conyuge_dni char(12) No
conyuge_nombres varchar(60) No
conyuge_apellido_paterno varchar(60) No
conyuge_apellido_materno varchar(60) No
fecha_nacimiento varchar(10) No
edad int(11) Sí NULL
celular varchar(20) Sí NULL
pais_id char(3) Sí NULL
region_id int(10) Sí NULL
ciudad_id int(11) Sí NULL
distrito_id int(10) Sí NULL
281/
44
direccion varchar(250) Sí NULL
sexo char(10) Sí NULL
estado_civil_id varchar(30) Sí NULL
nro_ficha_sep_bienes char(30) Sí NULL
archivo_ficha_sep_bienes varchar(50) Sí NULL
numero_hijos int(11) Sí NULL
ingresos int(11) Sí NULL
ingresos_conyugales int(11) Sí NULL
campania_id int(11) Sí NULL
fuente_descripcion varchar(250) Sí NULL
es_cliente tinyint(4) Sí NULL
tiene_inmuebles int(11) Sí NULL
certicom_ok int(11) Sí NULL
contacto varchar(250) Sí NULL
proyecto_id2 int(11) Sí NULL
pventa_id int(11) No
observaciones text No
cliente_potencial
Comentarios de la tabla: cliente_potencial

inado
id int(11) No
estado varchar(20) Sí NULL
nombres varchar(250) No
apellido_paterno varchar(250) Sí NULL
apellido_materno varchar(250) Sí NULL
conyuge_dni char(12) No
conyuge_nombres varchar(60) No
conyuge_apellido_paterno varchar(60) No
conyuge_apellido_materno varchar(60) No
tipo_documento_id char(3) No
nro_documento char(12) No
fecha_nacimiento varchar(10) No
282/
44
edad int(11) Sí NULL
celular varchar(20) Sí NULL
fax varchar(20) Sí NULL
pais_id char(3) Sí NULL
region_id int(10) Sí NULL
ciudad_id int(11) Sí NULL
distrito_id int(10) Sí NULL
sexo char(10) Sí NULL
estado_civil_id varchar(30) Sí NULL
numero_hijos int(11) Sí NULL
ingresos int(11) Sí NULL
ingresos_conyugales int(11) Sí NULL
fuente_id varchar(20) Sí NULL
campania_id int(11) No
fuente_descripcion varchar(250) Sí NULL
es_cliente tinyint(4) Sí NULL
tiene_inmuebles int(11) Sí NULL
certicom_ok int(11) Sí NULL
contacto varchar(250) Sí NULL
proyecto_id2 int(11) Sí NULL
pventa_id int(11) No
observaciones text No
fecha2_registro datetime Sí NULL
observacion2 text Sí NULL
283/
44
cobranza
Comentarios de la tabla: cobranza

inado
id int(11) No
separacion_id int(11) Sí NULL
envio_documentos int(11) Sí NULL
observaciones_1 text Sí NULL
fecha_envio varchar(10) Sí NULL
digitacion int(11) Sí NULL
fecha_digitacion varchar(10) Sí NULL
aprob_riesgos int(11) Sí NULL
observaciones_2 text Sí NULL
firmas_ok int(11) Sí NULL
fecha_firmas varchar(10) Sí NULL
dps_ok int(11) Sí NULL
observaciones_dps text Sí NULL
fecha_dps varchar(10) Sí NULL
tasacion_ok int(11) Sí NULL
observaciones_tasacion text Sí NULL
fecha_tasacion varchar(10) Sí NULL
estudio_titulos int(11) Sí NULL
observaciones_estudio text Sí NULL
fecha_estudio varchar(10) Sí NULL
hr_ok int(11) Sí NULL
observaciones_hr text Sí NULL
fecha_hr varchar(10) Sí NULL
f4_ok int(11) Sí NULL
observaciones_f4 text Sí NULL
fecha_f4 varchar(10) Sí NULL
envio_contrato int(11) Sí NULL
observaciones_contrato text Sí NULL
fecha_envio_contrato varchar(10) Sí NULL
desembolso_monto double Sí NULL
desembolso_cuenta varchar(25) Sí NULL
desembolso_fecha varchar(10) Sí NULL
dni_ok int(11) Sí NULL
minuta_ok int(11) Sí NULL
formulario_tp_ok int(11) Sí NULL
284/
44
carta_aprob_ok int(11) Sí NULL
envio_cofide int(11) Sí NULL
observaciones_cofide text Sí NULL
fecha_cofide varchar(10) Sí NULL
envio_fovime int(11) Sí NULL
observaciones_fovime text Sí NULL
fecha_fovime varchar(10) Sí NULL
comision
Comentarios de la tabla: comision

id int(11) No
inmueble_tipo_i char(4) Sí NULL
d
fecha_activida varchar(10) Sí NULL
d
monto double Sí NULL
comision_generada
Comentarios de la tabla: comision_generada
Colum Tipo Nulo Predeterm Com entarios

na inado
id int(11) No
rol_id int(11) No
rol_hijo_i int(11) Sí 0
d
inmueble_i int(11) No
d
monto double No
moneda varchar(20) No
mes datetime No
285/4
4
cotizacion
Comentarios de la tabla: cotizacion

inado
id int(11) No
fase int(2) No
codigo int(6) No
proyecto_estado_id smallint(6) No
proyecto_tipo_id char(30) No
bloque_numero varchar(20) Sí NULL
bloque_fecha_entrega date Sí NULL
bloque_fecha_entrega_sin_interes date Sí NULL
cliente_id int(11) No
cliente_estado varchar(20) No
cliente_dni char(12) Sí NULL
id_gradointeres int(11) Sí NULL
financiamiento_id varchar(30) Sí NULL
inicial double Sí NULL
cada_cuantos int(11) Sí NULL
letras int(11) Sí NULL
letras_detalle text Sí NULL
tiempo_deposito int(11) Sí NULL
bono double Sí NULL
prestamo_fovime decimal(10,0) Sí NULL
pago_saldo float No 0
importe_por_tramite double Sí NULL
precio_total double No
promocion_id int(11) Sí NULL
descuento_promocion text Sí NULL
precio_total_final double No
observaciones text Sí NULL
nrocuenta_id int(11) No
validez_dias int(11) Sí NULL
sys_uit double No
estado int(11) Sí NULL
asesor_id int(11) No
bd_rand varchar(200) Sí NULL
286/4
4
cotizacion_detalle
Comentarios de la tabla: cotizacion_detalle

inado
id bigint(20) No
cotizacion_id int(11) No
inmueble_id int(11) No
inmueble_tipo varchar(100) No
inmueble_codigo varchar(8) Sí NULL
inmueble_modelo varchar(20) Sí NULL
inmueble_numero varchar(20) Sí NULL
inmueble_bloque varchar(20) Sí NULL
inmueble_etapa varchar(100) No
inmueble_lote varchar(10) Sí NULL
precio_venta int(11) No
inmueble_minseparacion double No
descripcion varchar(250) Sí NULL
creacion_expediente
Comentarios de la tabla: creacion_expediente

id int(11) No
expediente_id int(11) No
tipo_de_ingresos int(11) Sí NULL
dni_titular int(11) Sí NULL
dni_conyuge int(11) Sí NULL
copia_luz_fono int(11) Sí NULL
inscripcion_bfh varchar(30) Sí NULL
dps_completo int(11) Sí NULL
ahorro_casa int(11) Sí NULL
cuenta_ahorrocasa varchar(50) Sí NULL
ahorro_techo int(11) Sí NULL
cuenta_ahorrotecho varchar(50) Sí NULL
ultimo_estado_cuenta int(11) Sí NULL
cronograma_pagos int(11) Sí NULL
certicom int(11) Sí NULL
287/4
4
tarjeta_propiedad int(11) Sí NULL
pu_y_hr int(11) Sí NULL
boleta_pago int(11) Sí NULL
estado_cuenta_AFP int(11) Sí NULL
boletas_pago_variable int(11) Sí NULL
certificado_retenciones int(11) Sí NULL
estado_cuenta_AFP_op int(11) Sí NULL
ddjj_1ra int(11) Sí NULL
recibos_pago_arriendos int(11) Sí NULL
contratos_alquiler int(11) Sí NULL

autovaluo_inmueble int(11) Sí NULL
ddjj_4ta int(11) Sí NULL
pagos_mensuales_4ta int(11) Sí NULL
contrato_locacion_servicios int(11) Sí NULL
relacion_princ_clientes int(11) Sí NULL
ddjj_3ra int(11) Sí NULL
declaraciones_pago_IGV int(11) Sí NULL
ficha_registral_constitucion int(11) Sí NULL
estados_cuenta_bancarios int(11) Sí NULL
relacion_clientes_proveedores int(11) Sí NULL
archivo_dni varchar(20) Sí NULL
archivo_dniconyuge varchar(20) Sí NULL
archivo_recibo varchar(20) Sí NULL
archivo_declaracion_jurada varchar(200) Sí NULL
banco_id varchar(10) Sí NULL
nombre_ejecutivo varchar(250) Sí NULL
correo_ejecutivo varchar(100) Sí NULL
telefono_ejecutivo varchar(20) Sí NULL
cuenta_bancaria
Comentarios de la tabla: cuenta_bancaria

id int(11) No
nro_cuenta varchar(100) Sí NULL
288/4
4
nro_spa varchar(100) Sí NULL
nro_cci varchar(100) Sí NULL
autor_id_registr int(11) Sí NULL
o
desembolso
Comentarios de la tabla: desembolso

id int(11) No
nro_cuenta_id varchar(20) Sí NULL
nro_operacion varchar(20) Sí NULL
fecha datetime Sí NULL
monto_bfh double Sí NULL
nro_cuenta_bfh varchar(50) Sí NULL
nro_operacion_bfh varchar(50) Sí NULL
fecha_bfh datetime Sí NULL
desistimiento
Comentarios de la tabla: desistimiento

id int(11) No
fecha_desistimiento datetime Sí NULL
archivo_cartadestistimiento varchar(250) Sí NULL
razon_desistimiento varchar(200) Sí NULL
289/4
4
devolucion
Comentarios de la tabla: devolucion

inado
id int(11) No
archivo_mutuodisenso varchar(250) Sí NULL
numero_cheque varchar(250) Sí NULL
archivo_cheque varchar(250) Sí NULL
distrito
Comentarios de la tabla: distrito

na
pais_id char(3) No
region_i int(10) No
d
ciudad_i int(11) No
d
distrito_i int(10) No
d
empresa
Comentarios de la tabla: empresa

ruc varchar(13) No
razon_social varchar(250) Sí NULL
nro_partidae varchar(100) Sí NULL
r01_dni varchar(20) Sí NULL
r01_nombres varchar(250) Sí NULL
r01_cargo varchar(60) Sí NULL
r01_titulo varchar(60) Sí NULL
r02_dni varchar(20) Sí NULL
290/4
4
r02_nombres varchar(250) Sí NULL
r02_cargo varchar(60) Sí NULL
r02_titulo varchar(60) Sí NULL
estado tinyint(4) Sí 1
encuesta
Comentarios de la tabla: encuesta

id int(11) No
rpta_01 varchar(100) Sí NULL

rpta_07_1 varchar(100) Sí NULL
rpta_09_otro varchar(100) Sí NULL
o
291/4
4
entrega_inmueble
Comentarios de la tabla: entrega_inmueble

inado
id int(11) No
proyecto_acta_id int(11) No
apoderado_id int(11) No
fecha_generacion_acta datetime Sí NULL
fecha_firma datetime Sí NULL
acta_entrega_escaneada varchar(70) Sí NULL
observaciones varchar(255) Sí NULL
fecha_registro varchar(10) Sí NULL
envio_a_banco
Comentarios de la tabla: envio_a_banco

id int(11) No
fecha_enviobanco datetime Sí NULL
nombre_contacto varchar(170) Sí NULL
envio_a_notaria
Comentarios de la tabla: envio_a_notaria

id int(11) No
notaria_id int(11) Sí NULL
correo_enviado varchar(255) Sí NULL
nro_kardex varchar(50) Sí NULL
292/4
4
escritura_publica
Comentarios de la tabla: escritura_publica

id int(11) No
firma_banco int(11) Sí NULL
fecha_banco varchar(10) Sí NULL
firma_cliente int(11) Sí NULL
fecha_cliente varchar(10) Sí NULL
firma_conyuge int(11) Sí NULL
fecha_conyuge varchar(10) Sí NULL
firma_altozano int(11) Sí NULL
fecha_altozano varchar(10) Sí NULL
fecha_registro_ep datetime Sí NULL
etapa
Comentarios de la tabla: etapa

inado
id int(11) No
fecha_entrega date No
fecha_entrega_interes date No
293/4
4
expediente
Comentarios de la tabla: expediente

id int(11) No
fase int(2) No
nro_documento varchar(30) No
nombres varchar(70) Sí NULL
ap_paterno varchar(25) Sí NULL
ap_materno varchar(25) Sí NULL
mail varchar(70) Sí NULL
proyecto_nombre varchar(100) Sí NULL
financiamiento_id varchar(70) No
tiempo_deposito int(11) No
inmueble1_etapa varchar(20) Sí NULL
inmueble1_modelo varchar(35) Sí NULL
inmueble1_bloque varchar(30) Sí NULL
inmueble1_tipo varchar(100) Sí NULL
inmueble1_numero int(4) Sí NULL
inmueble1_precio_venta double No
inmueble1_min_separacion double No
inmueble1_id int(11) No

inmueble2_precio_venta double Sí NULL
inmueble2_id int(11) Sí NULL
294/4
4
responsablec_id int(11) No
fecha_cotizacion datetime No
nro_dias_separacion int(4) Sí NULL
responsables_id int(11) Sí NULL
fecha_separacion datetime Sí NULL
nro_dias_ce int(4) Sí NULL
creacion_expediente_id int(11) Sí NULL
responsablece_id int(11) Sí NULL
fecha_creacion_expediente datetime Sí NULL
nro_dias_minuta int(4) Sí NULL
minuta_id int(11) Sí NULL
responsablm_id int(11) Sí NULL
fecha_minuta datetime Sí NULL
envio_banco_id int(11) Sí NULL
responsableeb_id int(11) Sí NULL
fecha_envio_banco datetime Sí NULL
nro_dias_en int(4) Sí NULL
envio_notaria_id int(11) Sí NULL
responsableen_id int(11) Sí NULL
fecha_envio_notaria datetime Sí NULL
nro_dias_ep int(4) Sí NULL
escritura_publica_id int(11) Sí NULL
responsableep_id int(11) Sí NULL
fecha_escritura_publica datetime Sí NULL
nro_dias_desembolso int(4) Sí NULL
desembolso_id int(11) Sí NULL
responsabled_id int(11) Sí NULL
fecha_desembolso datetime Sí NULL
nro_dias_ltys int(4) Sí NULL

liquidacion_tys_id int(11) Sí NULL
responsableltys_id int(20) Sí NULL

fecha_liquidaciontys datetime Sí NULL
nro_dias_ti int(4) Sí NULL
tramite_inscripcion_id int(11) Sí NULL
responsableti_id int(20) Sí NULL
fecha_tramite_inscripcion datetime Sí NULL
nro_dias_ei int(4) Sí NULL
entrega_inmueble_id int(11) Sí NULL
responsableei_id int(20) Sí NULL
fecha_entrega_inmueble datetime Sí NULL
295/4
4
desistimiento_id int(11) Sí NULL
responsabledesistimiento_id int(11) Sí NULL
fecha_desistimiento datetime Sí NULL
devolucion_id int(11) Sí NULL
responsabledevolucion_id int(11) Sí NULL
fecha_devolucion datetime Sí NULL
estado varchar(25) No ABIERTO
faq
Comentarios de la tabla: faq

id int(11) No
area_id int(11) No
pregunta text No
respuesta text No
forma_pago
Comentarios de la tabla: forma_pago

id varchar(30) No
galeria_fotos
Comentarios de la tabla: galeria_fotos

na
id int(11) No
entidad varchar(100) Sí NULL
entidad_ int(11) Sí NULL
id
296/4
4
geoposicion
Comentarios de la tabla: geoposicion

na
id int(11) No
pais_id char(3) No
region_i int(10) No
d
ciudad_i int(11) No
d
distrito_i int(10) No
d
latitud double No
longitud double No
esdistrit tinyint(4) No
o
grado_interes
Comentarios de la tabla: grado_interes

id_gradointere int(11) No
s
valor_porcentaj double Sí NULL
e
estado char(1) Sí 0
orden char(1) No
grupo_de_agentes
Comentarios de la tabla: grupo_de_agentes

inado
id int(11) No
grupov_id int(11) No
supervisor_i int(11) Sí NULL
d
jefev_id int(11) Sí NULL
asesor_id int(11) Sí NULL
297/4
4
grupo_de_venta
Comentarios de la tabla: grupo_de_venta

id int(11) No
observacion text Sí NULL
inmueble
Comentarios de la tabla: inmueble

id int(11) No
etapa_numero varchar(20) No
bloque char(20) No
codigo int(4) Sí NULL
cuh int(6) Sí NULL
numero_tasacion int(20) Sí NULL
valor_tasacion double Sí NULL
modelo_nombre varchar(40) No
programa_nombre varchar(100) No
inmueble_tipo_nombre char(40) No
iarea_terreno double Sí NULL
iarea_construida double Sí NULL
iarea_libre double No
iarea_ocupada double Sí NULL
numero int(8) Sí NULL
moneda varchar(20) Sí SOL
298/4
4
minimo_separacion double Sí NULL
estado varchar(15) No DISPONIBLE
piso int(11) Sí NULL
autor_id_modificacio int(11) Sí NULL
n
inmueble_modelo
Comentarios de la tabla: inmueble_modelo

id int(11) No
programa varchar(40) No
numero_cuartos int(11) Sí 0
numero_banos int(11) Sí 0
numero_medio_banos int(11) No 0
numero_terrazas int(11) Sí 0
youtube varchar(30) Sí NULL
numero_cocheras int(11) Sí 0
numero_jardines int(11) Sí 0
numero_lavanderias int(11) Sí 0
numero_aservicio int(11) Sí 0
descripcion_corta text Sí NULL
descripcion_detallada text Sí NULL
cuadro_acabados varchar(40) Sí NULL
foto varchar(250) Sí NULL
299/4
4
inmueble_tipo
Comentarios de la tabla: inmueble_tipo

id char(4) No
intervalos_fechas
Comentarios de la tabla: intervalos_fechas

id int(11) No
cotizacion_separacion int(2) No
separacion_minuta int(2) No
minuta_envionotaria int(2) No
envionotaria_escriturapublica int(2) No
escriturapublica_desembolso int(2) No
desembolso_entregainmueble int(4) No
entregainmueble_liquidaciontys int(2) No
liquidaciontys_inscripcion int(2) No
liquidacion_tys
Comentarios de la tabla: liquidacion_tys

id int(11) No
monto_tributos double Sí NULL
cuentaid_tributos int(11) No
nro_transaccion_tributos varchar(50) Sí NULL
fecha_liquidacion_tributos datetime Sí NULL
archivo_liquidacion_tributos varchar(70) Sí NULL
monto_servicios double Sí NULL
cuentaid_servicios int(11) No
nro_transaccion_servicios varchar(50) Sí NULL
fecha_liquidacion_servicios datetime No
300/4
4
archivo_liquidacion_servicios varchar(70) Sí NULL
meta
Comentarios de la tabla: meta

id int(11) No
asesor int(11) No
mes varchar(15) No
anio int(11) Sí NULL
unidad int(3) Sí NULL
soles double Sí NULL
minuta
Comentarios de la tabla: minuta

id int(11) No
cuota_inicial double Sí NULL
saldo_inicial double No
nro_operacion_inicial varchar(50) No
fecha_inicial datetime No
nro_cuenta_inicial int(11) No
archivo_inicial varchar(100) Sí NULL
monto_aprobado double No
total_pagos_realizados double Sí NULL
nro_carta_fianza varchar(70) Sí NULL
nro_operacion varchar(50) Sí NULL
fecha_pago_fianza datetime No
archivo_carta_fianza varchar(45) Sí NULL
firma_cliente int(1) Sí NULL
fecha_cliente datetime Sí NULL
301/4
4
firma_apoderado int(1) Sí NULL
archivo_poder varchar(160) Sí NULL
firma_conyuge int(1) Sí NULL
fecha_conyuge datetime Sí NULL
apoderado_id int(11) Sí NULL
fecha_legal datetime Sí NULL
firma_altozano int(1) Sí NULL
fecha_altozano datetime Sí NULL
letra_gastos_municipales int(1) Sí NULL
archivo_letragastosmunicipales varchar(160) Sí NULL
generar_poder int(1) Sí NULL
dni_poder varchar(12) Sí NULL
nombre_poder varchar(50) Sí NULL
letras_garantia int(1) Sí NULL
lgarantia_gpsp int(1) Sí NULL
veces_minuta_generada int(11) No 0
archivo_minuta_escaneada varchar(200) No
modelo_acabado
Comentarios de la tabla: modelo_acabado

id int(11) No
modelo_id int(11) Sí NULL
archivo varchar(250) Sí NULL
autor_id_registr int(11) Sí NULL
o
notaria
Comentarios de la tabla: notaria

id int(11) No
w ebsite varchar(100) Sí NULL
302/4
4
nombre_contacto1 varchar(100) Sí NULL
correo1 varchar(70) Sí NULL
telefono1 varchar(10) Sí NULL
observacion
Comentarios de la tabla: observacion

id int(11) No
descripcion text No
pagos_x_cuotainicial
Comentarios de la tabla: pagos_x_cuotainicial

id int(11) No
minuta_id int(11) No
monto double No
nro_cuenta varchar(50) No
nro_operacion varchar(50) No
fecha_deposito datetime Sí NULL
archivo_vouche varchar(50) Sí NULL
r
o
303/4
4
pagos_x_separacion
Comentarios de la tabla: pagos_x_separacion

id int(11) No
separacion_id int(11) No
monto double No
nro_cuenta varchar(50) No
otra_cuenta varchar(50) Sí NULL
nro_operacion varchar(50) No
fecha_deposito datetime Sí NULL
archivo_vouche varchar(50) Sí NULL
r
o
pais
Comentarios de la tabla: pais

na
pais_id char(3) No
nombre char(30) No
persona
Comentarios de la tabla: persona

id int(10) No
pais_id char(3) Sí PER
region_id int(10) Sí 0
ciudad_id int(11) Sí 0
distrito_id int(10) Sí 0
telefono char(30) Sí NULL
celular char(30) Sí NULL
304/4
4
correo char(200) Sí NULL
w eb_site char(200) Sí NULL
direccion char(250) Sí NULL
autor_id_registro int(11) Sí 0
autor_id_modificacion int(11) Sí 0
estado char(1) Sí A
bd_fregistro datetime Sí NULL
persona_natural
Comentarios de la tabla: persona_natural

id int(10) No
apellidos char(70) No
nombres char(70) No
fecha_nacimient date Sí NULL
o
promocion
Comentarios de la tabla: promocion

id int(11) No
tipo varchar(1) No
descripcion text No
aplica_dsct varchar(1) No
descuento float No
fecha_inicio varchar(10) Sí NULL
fecha_fin varchar(10) Sí NULL
forma_pago varchar(20) Sí NULL
archivo_adjunto varchar(20) Sí NULL
305/4
4
proyecto
Comentarios de la tabla: proyecto

id int(3) No
codigo_techopropio varchar(20) No
ruc varchar(13) No
proyecto_estado char(20) No
area double No 0
latitud double Sí NULL
longitud double Sí NULL
pais_id char(3) No
region_id int(10) No
ciudad_id int(11) No
distrito_id int(10) No
direccion varchar(200) No
direccion_referencia char(250) No
intro text Sí NULL
detalle text Sí NULL
precio_desde int(11) Sí NULL
precio_hasta int(11) Sí NULL
numero_pisos int(11) Sí 0
proyecto_acta
Comentarios de la tabla: proyecto_acta

id int(11) No
descripcion tinytext No
archivo_acta varchar(60) No
306/4
4
o
proyecto_contrato
Comentarios de la tabla: proyecto_contrato

id int(11) No
descripcion text No
contrato_separacion varchar(20) No
proyecto_cuenta
Comentarios de la tabla: proyecto_cuenta

inado
id int(11) No
cuenta_id int(11) No
proyecto_i int(11) No
d
etapa_id int(11) No
proyecto_estado
Comentarios de la tabla: proyecto_estado

na
id smallint(6) No
proyecto_forma_pago
Comentarios de la tabla: proyecto_forma_pago
307/4
4
id int(11) No
forma_pago_id varchar(30) No
inicial int(11) No
proyecto_metas
Comentarios de la tabla: proyecto_metas

na
id int(11) No
meta_id int(11) No
modelo_i int(11) No
d
proyecto_minuta
Comentarios de la tabla: proyecto_minuta

id int(11) No
descripcion text No
archivo_minuta varchar(20) No
o
proyecto_observacion
Comentarios de la tabla: proyecto_observacion

inado
id int(11) No
observacion_i int(11) No
d
308/4
4
etapa_id int(11) No
modelo_id int(11) No
proyecto_promocion
Comentarios de la tabla: proyecto_promocion

id int(11) No
promocion_id int(11) No
etapa_id int(11) No
modelo_id int(11) No
inmueble_tipo_i char(4) Sí NULL
d
inmueble_id int(11) Sí NULL
fpago_id varchar(30) Sí
proyecto_tipo
Comentarios de la tabla: proyecto_tipo

na
id varchar(2) No
pventa
Comentarios de la tabla: pventa

na
id int(11) No
direccio varchar(100) No
n
recordar
Comentarios de la tabla: recordar

na
id int(11) No
correo varchar(60) No
309/4
4
estado int(11) No
encripta varchar(100) No
do
recurso
Comentarios de la tabla: recurso

na
id int(11) No
codigo char(4) No
url varchar(40) No
habilita int(11) No
do
orden int(11) No
padre varchar(50) No
region
Comentarios de la tabla: region

na
pais_id char(3) No
region_i int(10) No
d
nombre char(100) No
rol
Comentarios de la tabla: rol

na
id int(11) No
rol_x_recurso
Comentarios de la tabla: rol_x_recurso
310/4
4
na
rol_id int(11) No
recurso_i int(11) No
d
ver char(1) Sí NULL
registrar char(1) Sí NULL
actualiza char(1) Sí NULL
r
eliminar char(1) Sí NULL
activar char(1) Sí NULL
publicar char(1) Sí NULL
separacion
Comentarios de la tabla: separacion

id int(11) No
apoderado_id int(11) No
programa varchar(40) Sí NULL
total double Sí NULL
monto_aprobado double No
contrato_escaneado varchar(400) Sí NULL
nro_carta_aprob varchar(20) Sí NULL
fecha_emision datetime Sí NULL
archivo_carta_aprob varchar(50) Sí NULL
nro_carta_aprob_act varchar(20) Sí NULL
fecha_emision_actualizada datetime Sí NULL
fecha_vencimiento_actualizada datetime Sí NULL
archivo_carta_aprob_act varchar(50) Sí NULL
numero_operacion varchar(20) Sí NULL
agencia_banco varchar(120) Sí NULL
nombre_ejecutivo varchar(120) Sí NULL
correo_ejecutivo varchar(100) Sí NULL
telefono_ejecutivo varchar(20) Sí NULL
fecha_maxima_contrato datetime Sí NULL
forma_pago varchar(20) Sí NULL
nro_meses int(2) Sí NULL
311/4
4
cuenta_01 varchar(60) Sí NULL
monto_01 double Sí NULL
numero_transaccion_01 varchar(100) No
fecha_deposito_01 datetime No
archivo_voucher_01 varchar(100) No
archivo_voucher_03 varchar(100) No
veces_contrato_generado int(11) No
tipo_de_cambio
Comentarios de la tabla: tipo_de_cambio

id int(11) No
moneda_origen varchar(20) No
moneda_destino varchar(20) No
valor decimal(10,0) No
tramite_inscripcion
Comentarios de la tabla: tramite_inscripcion

id int(11) No
fecha_habilitacionurbana datetime Sí NULL
fecha_recepcionobrasmuni datetime Sí NULL
fecha_recepcionobrassunarp datetime Sí NULL
fecha_conformidadobrasmuni datetime Sí NULL
fecha_conformidadobrassunarp datetime Sí NULL
fecha_transferenciadominio datetime Sí NULL

fecha_cambiopropietario datetime Sí NULL
312/4
4
usuario
Comentarios de la tabla: usuario

id int(11) No
rol_id int(11) No
persona_id int(10) No
nombre_usuari varchar(100) No
o
contrasena varchar(60) No
estado char(1) No A
v_actividad_detalle
Comentarios de la tabla: v_actividad_detalle

inado
id char(20) No
actividad_tipo_id tinyint(4) No 1
asunto varchar(120) Sí NULL
prioridad tinyint(4) Sí NULL
asignado_a int(11) Sí NULL
estado tinyint(4) Sí NULL
cliente_id int(11) Sí NULL
duracion_horas char(2) Sí NULL
duracion_minutos char(2) Sí NULL
aviso tinyint(4) Sí 0
asignado_nombres char(70) Sí NULL
asignado_apellidos char(70) Sí NULL
313/4
4
actividad_tipo_nombre char(20) Sí NULL
cliente_nombres varchar(250) Sí NULL
cliente_apellido_paterno varchar(250) Sí NULL
cliente_apellido_materno varchar(250) Sí NULL
v_agente_detalle
Comentarios de la tabla: v_agente_detalle

cargo_id int(11) No
cargo_nombre varchar(200) Sí NULL
id int(11) No 0
fechaagente_registro date No
usuario_id int(11) Sí 0
persona_id int(10) Sí NULL
nombre_agente varchar(200) Sí NULL
rol_id int(11) Sí NULL
rol_nombre varchar(100) Sí NULL
nombre_usuario varchar(100) Sí NULL
estado char(1) Sí A
nombres char(70) Sí NULL
apellidos char(70) Sí NULL
fecha_nacimiento date Sí NULL
region_nombre char(100) Sí NULL
ciudad_nombre char(100) Sí NULL
distrito_nombre varchar(45) Sí NULL
v_bloque_detalle
Comentarios de la tabla: v_bloque_detalle

id int(20) No 0
etapa_numero int(11) No
total_inmuebles bigint(21) Sí NULL
total_inmuebles_disponibles bigint(21) Sí NULL
total_inmuebles_separados bigint(21) Sí NULL
total_inmuebles_vendidos bigint(21) Sí NULL
v_cotizacion_cabecera_detalle
Comentarios de la tabla: v_cotizacion_cabecera_detalle

inado
id int(11) No 0
fase int(2) No
codigo int(6) No
pago_saldo float No 0
proyecto_tipo_id char(30) No
proyecto_estado_id smallint(6) No
bloque_numero varchar(20) Sí NULL
bloque_fecha_entrega date Sí NULL
bloque_fecha_entrega_sin_interes date Sí NULL
cliente_dni char(12) Sí NULL
financiamiento_id varchar(30) Sí NULL
cada_cuantos int(11) Sí NULL
tiempo_deposito int(11) Sí NULL
promocion_id int(11) Sí NULL
descuento_promocion text Sí NULL
prestamo_fovime decimal(10,0) Sí NULL
letras int(11) Sí NULL
letras_detalle text Sí NULL
importe_por_tramite double Sí NULL
nrocuenta_id int(11) No
validez_dias int(11) Sí NULL
estado int(11) Sí NULL
asesor_id int(11) No
emp_razon_social varchar(250) Sí NULL
id_gradointeres int(11) Sí 0
nombre_gradointeres varchar(250) Sí NULL
cliente_nombres varchar(250) Sí NULL
cliente_apellido_paterno varchar(250) Sí NULL
cliente_apellido_materno varchar(250) Sí NULL
tipo_documento_id char(3) Sí NULL
nro_documento char(12) Sí NULL
cliente_telefono varchar(20) Sí NULL
cliente_celular varchar(20) Sí NULL
cliente_correo varchar(250) Sí NULL
proyecto_foto varchar(250) Sí NULL
proyecto_estado_nombre char(20) Sí NULL
promocion_nombre varchar(255) Sí NULL
promocion_fecha_inicio varchar(10) Sí NULL
promocion_fecha_fin varchar(10) Sí NULL
promocion_tipo varchar(1) Sí NULL
promocion_descripcion text Sí NULL
aplica_dsct varchar(1) Sí NULL
promocion_descuento float Sí NULL
asesor_nombres char(70) Sí NULL
asesor_apellidos char(70) Sí NULL
correo_asesor varchar(100) Sí NULL
telefono_asesor char(30) Sí NULL
celular_asesor char(30) Sí NULL


proyecto_direccion varchar(200) Sí NULL
proyecto_direccion_referencia char(250) Sí NULL
banco_nombre varchar(250) Sí NULL
nro_cuenta_id int(11) Sí 0
nro_spa varchar(100) Sí NULL
nro_cci varchar(100) Sí NULL
cuenta_banco_id varchar(10) Sí NULL
v_cotizacion_detalle_detalle
Comentarios de la tabla: v_cotizacion_detalle_detalle

inado
id bigint(20) No 0
inmueble_id int(11) No
inmueble_tipo varchar(100) No
inmueble_codigo varchar(8) Sí NULL
inmueble_modelo varchar(20) Sí NULL
inmueble_numero varchar(20) Sí NULL
inmueble_bloque varchar(20) Sí NULL
inmueble_etapa varchar(100) No
inmueble_lote varchar(10) Sí NULL
inmueble_minseparacion double No
numero_cuartos int(11) Sí 0
numero_banos int(11) Sí 0
numero_medio_banos int(11) Sí 0
numero_terrazas int(11) Sí 0
numero_lavanderias int(11) Sí 0
modelo_foto varchar(250) Sí NULL
area_terreno double Sí NULL
area_construida double Sí NULL
area_ocupada double Sí NULL
area_libre double Sí NULL
etapa_id int(11) Sí 0
v_etapa_detalle
Comentarios de la tabla: v_etapa_detalle

id int(11) No 0
fecha_entrega date No
fecha_entrega_interes date No
total_inmuebles bigint(21) Sí NULL
total_inmuebles_disponibles bigint(21) Sí NULL
total_inmuebles_separados bigint(21) Sí NULL
total_inmuebles_vendidos bigint(21) Sí NULL
v_expediente_detalle
Comentarios de la tabla: v_expediente_detalle

id int(11) No 0
fase int(2) No
nro_documento varchar(30) No
nombres varchar(70) Sí NULL
ap_paterno varchar(25) Sí NULL
ap_materno varchar(25) Sí NULL
mail varchar(70) Sí NULL
inmueble1_precio_venta double No
inmueble1_id int(11) No
responsablec_id int(11) No
fecha_cotizacion datetime No
nro_dias_separacion int(4) Sí NULL
responsables_id int(11) Sí NULL
fecha_separacion datetime Sí NULL
nro_dias_ce int(4) Sí NULL
creacion_expediente_id int(11) Sí NULL
responsablece_id int(11) Sí NULL
fecha_creacion_expediente datetime Sí NULL
nro_dias_minuta int(4) Sí NULL
minuta_id int(11) Sí NULL
responsablm_id int(11) Sí NULL
fecha_minuta datetime Sí NULL
nro_dias_en int(4) Sí NULL
envio_notaria_id int(11) Sí NULL
responsableen_id int(11) Sí NULL
fecha_envio_notaria datetime Sí NULL
nro_dias_ep int(4) Sí NULL
escritura_publica_id int(11) Sí NULL
responsableep_id int(11) Sí NULL
fecha_escritura_publica datetime Sí NULL
nro_dias_desembolso int(4) Sí NULL
desembolso_id int(11) Sí NULL
responsabled_id int(11) Sí NULL
fecha_desembolso datetime Sí NULL
nro_dias_ltys int(4) Sí NULL
liquidacion_tys_id int(11) Sí NULL
responsableltys_id int(20) Sí NULL
fecha_liquidaciontys datetime Sí NULL
nro_dias_ti int(4) Sí NULL
tramite_inscripcion_id int(11) Sí NULL
responsableti_id int(20) Sí NULL
fecha_tramite_inscripcion datetime Sí NULL

nro_dias_ei int(4) Sí NULL
entrega_inmueble_id int(11) Sí NULL
responsableei_id int(20) Sí NULL
fecha_entrega_inmueble datetime Sí NULL
estado varchar(25) No ABIERTO
monto_total double Sí NULL
minimo_separacion_i1 double Sí NULL
minimo_separacion_i2 double Sí NULL
v_geoposicion_detalle
Comentarios de la tabla: v_geoposicion_detalle

inado
id int(11) No
pais_id char(3) No
latitud double No
longitud double No
esdistrito tinyint(4) No
region_nombr char(100) Sí NULL
e
ciudad_nombr char(100) Sí NULL
e
distrito_nombr varchar(45) Sí NULL
e
v_inmueble_detalle
Comentarios de la tabla: v_inmueble_detalle

id int(11) No 0
etapa_numero varchar(20) No
bloque char(20) No
codigo int(4) Sí NULL
modelo_nombre varchar(40) No
inmueble_tipo_nombre char(40) No
iarea_terreno double Sí NULL
iarea_construida double Sí NULL
numero int(8) Sí NULL
estado varchar(15) No DISPONIBLE
autor_id_modificacio int(11) Sí NULL
n
v_proyecto_detalle
Comentarios de la tabla: v_proyecto_detalle

id int(3) No 000
codigo_techopropio varchar(20) No
ruc varchar(13) No
proyecto_estado char(20) No
area double No 0
latitud double Sí NULL
longitud double Sí NULL
pais_id char(3) No
direccion varchar(200) No
direccion_referencia char(250) No
intro text Sí NULL
detalle text Sí NULL
precio_desde int(11) Sí NULL
precio_hasta int(11) Sí NULL
numero_pisos int(11) Sí 0
v_usuario_detalle
Comentarios de la tabla: v_usuario_detalle

id int(11) No 0
persona_id int(10) No
rol_id int(11) No
rol_nombre varchar(100) Sí NULL
nombre_usuario varchar(100) No
estado char(1) No A
nombres char(70) Sí NULL
apellidos char(70) Sí NULL
fecha_nacimiento date Sí NULL
ANEXO 6
Proyección de Recuperación de la Inversión
Nombre de la Opción
CRM SGI 5937 VP: Valor Presente Neto
PP: Payback Period
6.5 (meses) 1587% TIR: Tasa Interna de Retorno
Año Año Fuentes Clave,

Factor ($000) 0 1 Año 2 Año 3 Año 4 Año 5 Total Explicaciones
INVERSION INICIAL
0.0 0.0
Servicios de Ingeniería de Software 42.0 42.0
Costos de Personal 18.0 18.0 Datos estimados por el cliente.
0.0
Total Inversión Inicial 60.0 0.0 0.0 0.0 0.0 0.0 60.0
GASTOS CONCURRENTES
Costo del administrador del sistema con un reajuste anual del 2%
Costos de Administración 24.0 24.5 25.0 25.5 26.0 124.9 (Inflación)
Cinco sedes, S/ 300 nuevos soles, costo de banda ancha mensual por
Costos de Comunicaciones 18.0 18.0 18.0 18.0 18.0 90.0 sede
Presupuesto de S/ 3,000 nuevos soles por año para las mejoras de
Costos de Evolución del Sistema 3.0 3.0 3.0 3.0 3.0 15.0 sistema.
Capacitación a Usuarios 3.0 3.0 3.0 3.0 3.0 15.0 Costo de capacitación a nuevos usuarios del sistema.
Total Inversión Concurrente 0.0 48.0 48.5 49.0 49.5 50.0 244.9
Total TODOS los Gastos Por Año 60.0 48.0 48.5 49.0 49.5 50.0 304.9
Total TODOS los Gastos Acumulados 60.0 108.0 156.5 205.4 254.9 304.9
BENEFICIOS
Área Comercial
Reducción del Personal de Trámite Documentario 44.4 88.8 88.8 88.8 88.8 399.6 Reducción del personal por automatización de los trámites
Incremento de Ventas 900.0 1800.0 1800.0 1800.0 1800.0 8100.0 Incremento de ventas por incremento de productividad de los vendedores
Total Bruto de Beneficios Por Año 0.0 944.4 1888.8 1888.8 1888.8 1888.8 8499.6
Total Bruto de Beneficios Acumulado 0.0 944.4 2833.2 4722.0 6610.8 8499.6
Total NETO de Beneficios Por Año 0.0 896.4 1840.3 1839.8 1839.3 1838.8 8254.7
Total NETO de Beneficios Acumulado 0.0 896.4 2736.7 4576.6 6415.9 8254.7
FLUJO DE CAJA NETO

Flujo de Caja Neto Anual -60.0 896.4 1840.3 1839.8 1839.3 1838.8 8194.7
Flujo de Caja Neto Acumulado -60.0 836.4 2676.7 4516.6 6355.9 8194.7
Tasa de Descuento para Valor Presente = 8%

FIN Reducción de Personal de Trámite Documentario NOTAS
Definición Incrementar la productividad (costo-efectividad) del personal

de Trámite Documentario
Información de Ref. Análisis de procesos, análisis de data historica
Origen de los ahorros Reducción de trabajo debido a:

- eliminación de trabajo manual
- automatización de los controles y seguimiento de los expedientes con el sistema
- generación de alertas de identificación de situaciones de execpción
- integración de datos para reducir errores y conciliaciones
- facilidad en el ingreso de información
Cálculos para: CRM SGI Importe ($000) Total ($000)
Variables de entrada: Número de personas reducidas 2

Salario promedio/persona (con beneficios) S/. 44
Total $89
Factores Específicos para
Impacto en el Tiempo % de Ahorros ganados en Año 1 (asumiendo que la implementación 50%

empieza a mediados de año)
% de Ahorros ganados en el Año 2 100%
% de Ahorros ganados despues del Año 2 100%
Impacto Neto por Periodo Ahorros Anuales $89

Ahorros Año 1 S/. 44.4 50%
Total Ahorros en Cinco Años $400
Intangibles Relacionados
Mejora en la imagen del servicio a clientes
Mayor seguridad y control
sobretiempos
Comentarios:
FIN Incremento de Ventas NOTAS
Definición Incrementar el porcentaje de ventas

Información de Ref. Análisis de los procesos de ventas
Origen del incremento Incrementos debidos a:

- Mayor velocidad de atención a los clientes en las
casetas de ventas
- Mayor cantidad de clientes potenciales por vendedor
- Mayor tiempo de seguimiento de ventas para los vendedores
- Alertas del sistema para oportuno seguimiento del ciclo de ventas
Cálculos para: CRM - SGI Importe ($000) Total ($000)
Análisis mensual:
Número de clientes potenciales manejados actualmente por
Variables de entrada: 15
vendedor
Número de clientes manejados con el sistema 20
Incremento de clientes potenciales 5
Porcentaje promedio de cierre de ventas por vendedor 20.00%
Incremento de ventas cerradas por vendedor 1
Número de vendedores 5
Incremento total de ventas cerradas 5
Precio promedio por inmueble 30
Incremento de ingresos por ventas adicionales 150
Ingresos Adicionales Totales $1,800
Impacto en el Tiempo % de Ingresos adicionales en Año 1 (asumiendo que la 50%

implementación empieza a mediados de año)
% de ingresos adicionales en el Año 2 100%
% de ingresos adicionales despues del Año 2 100%
Impacto Neto por Periodo Ingresos Adicionales Anuales $1,800

Ahorros Año 1 $900 25%
Ahorros Año 2 $1,800 75%
Total Ahorros en Cinco Años $8,100
Intangibles Relacionados
Mejora de la imagen del dpto. de compras internamente
Comentarios:
ANEXO 7
ANEXO 8
Trabajo
EDT EDT Costo Trabajo Variación Trabajo real Comienzo Fin
previsto
1 CRM SGI S. 44,399.00 1,048 horas 1,020 horas 28 horas 76 horas vie 20/04/12 lun 22/10/12
1.1 Gestión del Proyecto S. 9,274.00 124 horas 108 horas 16 horas 40 horas vie 20/04/12 lun 22/10/12
1.1.1 Project Charter S. 2,100.00 30 horas 17 horas 13 horas 30 horas vie 20/04/12 mar 24/04/12
1.1.1.1 Elaborar el Project Charter S. 1,400.00 20 horas 10 horas 10 horas 20 horas vie 20/04/12 mar 24/04/12
1.1.1.2 Aceptar Project Charter S. 700.00 10 horas 7 horas 3 horas 10 horas lun 23/04/12 mar 24/04/12
1.1.1.3 Hito S. 0.00 0 horas 0 horas 0 horas 0 horas mar 24/04/12 mar 24/04/12
1.1.2 Declaración del Alcance del Proyecto S. 1,540.00 22 horas 19 horas 3 horas 10 horas mar 24/04/12 vie 27/04/12
1.1.2.1 Elaborar Declaración del Alcance del Proyecto S. 840.00 12 horas 12 horas 0 horas 0 horas mar 24/04/12 mié 25/04/12
1.1.2.2 Aceptar Declaración del Alcance del Proyecto S. 700.00 10 horas 7 horas 3 horas 10 horas jue 26/04/12 vie 27/04/12
1.1.2.3 Hito S. 0.00 0 horas 0 horas 0 horas 0 horas vie 27/04/12 vie 27/04/12
1.1.3 Plan de Gestión del Alcance S. 1,190.00 17 horas 17 horas 0 horas 0 horas vie 27/04/12 mié 02/05/12
1.1.3.1 Elaborar Plan de Gestión del Alcance S. 700.00 10 horas 10 horas 0 horas 0 horas vie 27/04/12 lun 30/04/12
1.1.3.2 Aceptar Plan de Gestión del Alcance S. 490.00 7 horas 7 horas 0 horas 0 horas lun 30/04/12 mar 01/05/12
1.1.3.3 Hito S. 0.00 0 horas 0 horas 0 horas 0 horas lun 30/04/12 mié 02/05/12
1.1.4 WBS S. 162.00 3 horas 3 horas 0 horas 0 horas mié 02/05/12 mié 02/05/12
1.1.4.1 Elaborar WBS S. 92.00 2 horas 2 horas 0 horas 0 horas mié 02/05/12 mié 02/05/12
1.1.4.2 Aceptar WBS S. 70.00 1 hora 1 hora 0 horas 0 horas mié 02/05/12 mié 02/05/12
1.1.4.3 Hito S. 0.00 0 horas 0 horas 0 horas 0 horas mié 02/05/12 mié 02/05/12
1.1.5 Plan de Gestión del Cronograma S. 1,162.00 19 horas 19 horas 0 horas 0 horas mié 02/05/12 vie 04/05/12
1.1.5.1 Elaborar Plan de Gestión del Cronograma S. 812.00 14 horas 14 horas 0 horas 0 horas mié 02/05/12 jue 03/05/12
1.1.5.2 Aceptar Plan de Gestión del Cronograma S. 350.00 5 horas 5 horas 0 horas 0 horas jue 03/05/12 vie 04/05/12
1.1.6 Plan de Gestión de Riesgo y Contingencias S. 162.00 3 horas 3 horas 0 horas 0 horas vie 04/05/12 vie 04/05/12
Elaborar Plan de Gestión de Riesgo y
1.1.6.1 S. 92.00 2 horas 2 horas 0 horas 0 horas vie 04/05/12 vie 04/05/12
Contingencias
Aceptar Plan de Gestión de Riesgo y
1.1.6.2 S. 70.00 1 hora 1 hora 0 horas 0 horas vie 04/05/12 vie 04/05/12
Contingencias
1.1.7 Acta de Cierre del proyecto S. 1,260.00 18 horas 18 horas 0 horas 0 horas lun 15/10/12 lun 22/10/12
1.1.7.1 Elaborar Acta de Cierre del proyecto S. 980.00 14 horas 14 horas 0 horas 0 horas lun 15/10/12 mar 16/10/12
1.1.7.2 Aceptar Acta de Cierre del proyecto S. 280.00 4 horas 4 horas 0 horas 0 horas vie 19/10/12 vie 19/10/12
1.1.7.3 Seguimiento y Control S. 0.00 0 horas 0 horas 0 horas 0 horas lun 22/10/12 lun 22/10/12
1.1.8 Solicitud de Cambio S. 648.00 12 horas 12 horas 0 horas 0 horas lun 16/07/12 vie 17/08/12
1.1.8.1 Elaborar Solicitud de Cambio 1 S. 138.00 3 horas 3 horas 0 horas 0 horas lun 16/07/12 lun 16/07/12
1.1.8.2 Aceptar Solicitud de Cambio 1 S. 70.00 1 hora 1 hora 0 horas 0 horas lun 16/07/12 lun 16/07/12
1.1.8.3 Elaborar Solicitud de Cambio 2 S. 138.00 3 horas 3 horas 0 horas 0 horas lun 30/07/12 lun 30/07/12
1.1.8.5 Elaborar Solicitud de Cambio 3 S. 46.00 1 hora 1 hora 0 horas 0 horas lun 06/08/12 lun 06/08/12
1.1.8.7 Elaborar Solicitud de Cambio 4 S. 46.00 1 hora 1 hora 0 horas 0 horas vie 17/08/12 vie 17/08/12
1.1.8.8 Aceptar Solicitud de Cambio 4 S. 70.00 1 hora 1 hora 0 horas 0 horas vie 17/08/12 vie 17/08/12
1.1.8.9 Hito 1 S. 0.00 0 horas 0 horas 0 horas 0 horas vie 17/08/12 vie 17/08/12
1.2 Fase de Concepción S. 9,560.00 165 horas 157 horas 8 horas 16 horas mié 02/05/12 vie 15/06/12
1.2.1 Reglas del Negocio S. 184.00 4 horas 4 horas 0 horas 0 horas mié 02/05/12 mié 02/05/12
1.2.2 Glosario de Terminos S. 184.00 4 horas 4 horas 0 horas 0 horas jue 03/05/12 jue 03/05/12
1.2.2.1 Identificar Palabras Claves del Negocio S. 184.00 4 horas 4 horas 0 horas 0 horas jue 03/05/12 jue 03/05/12
1.2.2.2 Hito S. 0.00 0 horas 0 horas 0 horas 0 horas jue 03/05/12 jue 03/05/12
1.2.3 Vista Externa del Negocio S. 1,132.00 22 horas 22 horas 0 horas 0 horas jue 03/05/12 lun 07/05/12
1.2.3.1 Identificar Actores del Negocio S. 232.00 4 horas 4 horas 0 horas 0 horas jue 03/05/12 jue 03/05/12
1.2.3.2 Identificar Casos de Uso del Negocio S. 348.00 6 horas 6 horas 0 horas 0 horas jue 03/05/12 jue 03/05/12
1.2.3.3 Modelar Casos de Uso del Negocio S. 552.00 12 horas 12 horas 0 horas 0 horas jue 03/05/12 lun 07/05/12
1.2.3.4 Hito S. 0.00 0 horas 0 horas 0 horas 0 horas lun 07/05/12 lun 07/05/12
1.2.4 Vista Interna del Negocio S. 920.00 20 horas 20 horas 0 horas 0 horas lun 07/05/12 mié 09/05/12
1.2.4.1 Identificar Trabajadores del Negocio S. 230.00 5 horas 5 horas 0 horas 0 horas lun 07/05/12 lun 07/05/12
1.2.4.2 Identificar Entidades del Negocio S. 230.00 5 horas 5 horas 0 horas 0 horas lun 07/05/12 lun 07/05/12
1.2.4.3 Elaborar Modelo de Objetos del Negocio S. 460.00 10 horas 10 horas 0 horas 0 horas lun 07/05/12 mié 09/05/12
1.2.4.4 Hito S. 0.00 0 horas 0 horas 0 horas 0 horas mié 09/05/12 mié 09/05/12
1.2.5 Realización de los CUN S. 1,104.00 24 horas 24 horas 0 horas 0 horas mié 09/05/12 lun 14/05/12
1.2.5.1 Especificar los Casos de Uso del Negocio S. 1,104.00 24 horas 24 horas 0 horas 0 horas mié 09/05/12 lun 14/05/12
1.2.6 Matriz de Actividades y Requerimientos S. 1,564.00 34 horas 26 horas 8 horas 16 horas lun 14/05/12 vie 18/05/12
1.2.6.1 Identificar Requisitos Comunes S. 368.00 8 horas 8 horas 0 horas 0 horas lun 14/05/12 mar 15/05/12
1.2.6.2 Priorizar Requisitos S. 460.00 10 horas 10 horas 0 horas 0 horas mar 15/05/12 mié 16/05/12
1.2.6.3 Elaborar Matriz de Requerimientos S. 736.00 16 horas 8 horas 8 horas 16 horas jue 17/05/12 vie 18/05/12
1.2.7 Documento de Requerimientos Funcionales S. 598.00 13 horas 13 horas 0 horas 0 horas lun 21/05/12 mar 22/05/12
1.2.7.1 Priorizar Requerimientos Funcionales S. 230.00 5 horas 5 horas 0 horas 0 horas lun 21/05/12 lun 21/05/12
1.2.7.2 Elaborar Matriz de Requerimientos Funcionales S. 368.00 8 horas 8 horas 0 horas 0 horas lun 21/05/12 mar 22/05/12
1.2.8 Documento de Requerimientos No Funcionales S. 552.00 12 horas 12 horas 0 horas 0 horas mar 22/05/12 jue 24/05/12
1.2.8.1 Priorizacion de Requerimientos No Funcionales S. 230.00 5 horas 5 horas 0 horas 0 horas mar 22/05/12 mié 23/05/12
Elaborar Matriz de Requerimientos No
1.2.8.2 S. 322.00 7 horas 7 horas 0 horas 0 horas mié 23/05/12 jue 24/05/12
Funcionales
1.2.8.3 Hito S. 0.00 0 horas 0 horas 0 horas 0 horas jue 24/05/12 jue 24/05/12
1.2.9 Diagrama de CUS S. 736.00 16 horas 16 horas 0 horas 0 horas jue 24/05/12 lun 28/05/12
1.2.9.1 Elaborar Modelo de CUS S. 736.00 16 horas 16 horas 0 horas 0 horas jue 24/05/12 lun 28/05/12
1.2.10 Documento de Lista de CU Priorizados S. 744.00 12 horas 12 horas 0 horas 0 horas lun 28/05/12 mar 29/05/12
1.2.10.1 Priorizar CUS S. 560.00 8 horas 8 horas 0 horas 0 horas lun 28/05/12 mar 29/05/12
1.2.10.2 Elaborar Analisis FURPS+ S. 184.00 4 horas 4 horas 0 horas 0 horas lun 28/05/12 lun 28/05/12
1.2.11 Documento de Estándares S. 792.00 4 horas 4 horas 0 horas 0 horas vie 15/06/12 vie 15/06/12
1.2.11.1 Definir Estandares de Documentacion S. 140.00 2 horas 2 horas 0 horas 0 horas vie 15/06/12 vie 15/06/12
1.2.11.2 Definir Estandares de Programacion S. 92.00 2 horas 2 horas 0 horas 0 horas vie 15/06/12 vie 15/06/12
1.2.11.3 Seguimiento y Control S. 560.00 0 horas 0 horas 0 horas 0 horas vie 15/06/12 vie 15/06/12
1.3 Fase de Elaboración S. 9,116.00 267 horas 263 horas 4 horas 20 horas lun 18/06/12 vie 03/08/12
1.4 Fase de Construcción S. 11,300.00 375 horas 375 horas 0 horas 0 horas lun 06/08/12 mié 19/09/12
1.5 Fase de Transición S. 5,149.00 117 horas 117 horas 0 horas 0 horas jue 06/09/12 lun 08/10/12

Cespedes CP

Cargado por

Información del documentohacer clic para expandir la información del documentoCespsedes

Información del documentohacer clic para expandir la información del documento

Copyright:

Formatos disponibles

Cespedes CP

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Cespedes CP

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD RICARDO PALMA

ESCUELA PROFESIONAL DE INGENIERÍA INFORMÁTICA

“DESARROLLO DE UNA APLICACIÓN WEB CRM

PARA OPTAR EL TÍTULO PROFESIONAL DE INGENIERO INFORMÁTICO

Gráfica N° 1: Producto Bruto Interno Trimestral 2004 – I – 2012 – III

(A precios constantes de 1994)

Fuente: Comportamiento de la Economía Peruana en el Tercer Trimestre de 2012. INEI (2012)

1 INEI, 2012, Comportamiento de la Economía Peruana en el Tercer Trimestre de 2012. p.3

Las condiciones favorables de acceso al financiamiento a través de los créditos hipotecarios

Gráfica N° 3: Número Créditos Hipotecarios 2011 – 2012 (Miles de nuevos soles)

Fuente: Comportamiento de la Economía Peruana en el Tercer Trimestre de 2012. INEI (2012)

Fuente: Comportamiento de la Economía Peruana en el Tercer Trimestre de 2012. INEI (2012)

Según el Ministerio de Vivienda, Construcción y Saneamiento de Perú, el déficit habitacional

Las 389.745 viviendas restantes corresponden al déficit cuantitativo, a la falta de viviendas

Gráfica N° 5: Déficit Habitacional Cuantitativo y Cualitativo 2012

Ámbito Total Cuantitativo Cualitativo

Nacional 1’860,692 (100.0%) 389,745 1’470,947

Fuente: Déficit Habitacional. Ministerio de Vivienda (2012)

Como resultado, las empresas inmobiliarias y constructoras han mostrado un

La estabilidad de la economía, la disponibilidad de crédito hipotecario a tasas de interés fijas y

Convención: La organización donde se realizó la investigación aplicada es una empresa

Convertirnos en el líder especializado en construcción masiva de vivienda social de alta calidad

Cumplirle el sueño de la casa propia a miles de familias peruanas construyendo viviendas y

1.1.2. Procesos del Negocio.

Los procesos de la Empresa Constructora Inmobiliaria, se han estructurado en 3 tipos de

Procesos Estratégicos: Son procesos destinados a definir y controlar las metas de la

Dentro de esta estructuración se han identificado los siguientes procesos:

Gráfica N° 1.1.: Procesos de la Empresa Constructora Inmobiliaria

Fuente: Elaboración Propia (2011)

Este proceso está constituido por 7 sub – procesos, ellos son:

Fuente: Elaboración Propia (2011)

1.2. Fundamentación del Problema.

1.2.1. Marco Teórico.

1.2.1.1. Marketing Relacional.

La creación de valor para el cliente parte necesariamente del reconocimiento de la importancia

El marketing relacional es la intersección entre el marketing y las relaciones públicas, la

6 Alet, 2000, Como obtener clientes reales y rentables. p. 51

1.2.1.2. Sistemas y Tecnologías de Información.

El ambiente tecnológico deberá considerar la adopción de modelos de negocios centrados en la

8Kotler & Armstrong, 2003, Fundamentos de marketing.

La planificación y el diseño de los sistemas de información en las empresas y organizaciones

Gráfica N° 1.3.: Las 3 Dimensiones de un Sistema de Información

Fuente: Fundamentos de marketing. Kotler & Armstrong (2003)

A. Clasificación de los sistemas de información: por lo general, las clasificaciones más

Conviene indicar que en la actualidad resulta complejo establecer fronteras rígidas en

 Gestiones asociadas a una venta.

4. CRM Analítico: hace referencia al almacenamiento (en el Data Warehouse) proceso,

6. EL CRM de colaboración, interacción directa (o “colaborativo”): es sin duda, una de

El CRM analítico y operativo desempeñará entonces un papel destacado. El CRM de

De acuerdo al proceso de apoyo son denominadas:

1.2.1.4. Ingeniería de Software.

El software se desarrolla o construye; no se manufactura en el sentido clásico: Ambas

Métodos de la ingeniería del software.

Un Método de ingeniería del software es un enfoque estructurado para el desarrollo de software

Todos los métodos se basan en la idea de modelos gráficos de desarrollo de un sistema y en el

Procesos del software.

c.1. Modelos del proceso del software.