Propuesta Desarrollo

Propuesta Técnica
Sistema de Perfilamiento de Usuario

ConsultasWeb S.A.
Propuesta Desarrollo Sistema Perfilamiento
Contenidos
1. INTRODUCCIÓN .................................................................................................................................... 2
1.1 MOTIVACIÓN PARA ESTE REQUERIMIENTO .......................................................................................... 2
1.2 PRESENTACIÓN DE PERFILAMIENTO .................................................................................................... 2
1.3 TERMINOLOGÍA ACORDADA ................................................................................................................ 3
1.4 CRITERIOS DE ÉXITO ........................................................................................................................... 3
1.4.1 Para el Cliente ............................................................................................................................ 3
1.4.2 Visión Comercial de CONSULTASWEB S.A. ............................................................................. 3
1.4.3 Para el Producción Informática ................................................................................................. 3
1.5 RESTRICCIONES Y ALCANCES .............................................................................................................. 4
2. SOLUCIÓN PROPUESTA ...................................................................................................................... 5
2.1 PÁGINA DE PERFIL............................................................................................................................... 5
2.1.1 Caso de Uso 1: Ingreso a la Plataforma .................................................................................... 5
2.1.2 Visión General de la Interfaz de Usuario Propuesta .................................................................. 6
2.1.3 Funcionalidades Especiales y Consideraciones ......................................................................... 6
2.2 ADMINISTRACIÓN DE PARÁMETROS .................................................................................................... 7
2.2.1 Caso de Uso 2: Mantención de Tablas ....................................................................................... 7
2.2.2 Validaciones ............................................................................................................................... 7
3. METODOLOGÍA DE DESARROLLO ................................................................................................. 8
3.1 PROCESOS DE DESARROLLO ................................................................................................................ 8
3.1.1 Fase Concepción (Modelamiento y Diseño) ............................................................................... 8
3.1.2 Fase de Desarrollo (Elaboración y Construcción de RUP) ....................................................... 9
3.1.3 Fase de Desarrollo Transición (estabilización e instalación) .................................................... 9
3.2 ESTRATEGIAS DE DESARROLLO ........................................................................................................... 9
3.2.1 Etapa de Modelamiento y Diseño ............................................................................................... 9
3.2.2 Etapa de Desarrollo ..................................................................................................................10
3.2.3 Etapa de Transición y Entrega ..................................................................................................10
3.3 ROLES DEL EQUIPO ............................................................................................................................11
4. CALENDARIO E HITOS DE ENTREGA ...........................................................................................14
4.1 ACTIVIDADES DE PREPARACIÓN PARA EL DESARROLLO ....................................................................14
4.2 CALENDARIO DE HITOS RELEVANTES ................................................................................................14
4.3 PARTICIPACIÓN DE CONSULTASWEB S.A. EN EL PROYECTO ..............................................................15
5. ANÁLISIS DE RIESGOS Y TEMAS POR RESOLVER ....................................................................16
5.1 RIESGOS .............................................................................................................................................16
5.2 TEMAS POR RESOLVER .......................................................................................................................16
© RodrigoSandoval.net, Lo Barnechea, Santiago Pág. 1

1. Introducción
Tomando en consideración la plataforma de servicios de consulta Web de CONSULTASWEB S.A.,
también conocida como SCW (Sistema Consultas Web), actualmente se está implantando un
cambio a nivel de la estructura transversal de administración de cuentas de usuario, autentificación
y autorización de acceso a las aplicaciones.
Junto con estos cambios, se levanta la necesidad de contar con la funcionalidad que permite, al
identificar un usuario en forma única, mostrarle sólo las aplicaciones que tenga disponible según su
perfil, junto con una gráfica adecuada al cliente (empresa) al que pertenece.
En suma, la plataforma de autentificación y autorización se esquematiza de la siguiente manera,
donde una secuencia de pasos lógicas llevan al usuario a (A) entrar al formulario de autenticación,
ingresar su user+password, luego pasar por el (B) módulo de perfilamiento, el cual reconocerá
su perfil, mostrándole una página adecuada a la gráfica del cliente y las aplicaciones
disponibles. Finalmente, al seleccionar una de estas aplicaciones, (C) un módulo de autorización
valida la credencial del usuario contra la lista de usuarios registrados para el servicio.
1.1 Motivación para este Requerimiento

Primero que nada, la plataforma SCW actual ofrece un esquema que cumple funcionalmente con la
idea de perfilamiento, pero carece de la estética adecuada y de la flexibilidad a nivel de usuario
(sólo maneja detalle por cliente).
Por otro lado, el módulo actual de autorización y perfilamiento está directamente asociado a una
estructura de autenticación insuficiente para los requerimientos de seguridad actuales.
Finalmente, esta idea forma parte de la actualización tecnológica de la plataforma de consulta
Web.
1.2 Presentación de Perfilamiento

Este documento se focaliza en describir los requerimientos funcionales del módulo encargado de
una “Presentación de Perfilamiento”, consistente en desplegar información gráfica asociada al perfil
del usuario. Este módulo no incluye aspectos de autenticación ni de autorización a las aplicaciones
de los servicios de consulta en CONSULTASWEB S.A.
La definición acordada de la Presentación de Perfilamiento es la siguiente:
“Esquema por el cual, un usuario previamente autenticado, entra a una página cuya
gráfica y mensajes son del cliente al que pertenece, y según su perfil, verá aquellas
aplicaciones activas e inactivas que tiene asignadas.”

1.3 Terminología acordada

 “Cliente”, corresponde a la empresa cliente del servicio de consulta contratado. Cada
cliente a su vez cuenta con varios usuarios. La gráfica estética se asocia a los clientes.
 “Usuario”, son los usuarios de consulta identificados individualmente, los cuales
pertenecen a uno y sólo un cliente. A este nivel se manejan las opciones entre las que se
distinguen las opciones que el usuario tiene habilitadas, las que se le muestran, pero no
tiene habilitadas y las que no se le muestran.
1.4 Criterios de Éxito

1.4.1 Para el Cliente
- Que la plataforma – luego de autentificar a cada usuario – reconozca su perfil y
pertenencia al cliente, mostrando las opciones (aplicaciones) disponibles para él, en un
contexto visual asociado a su empresa.
- Existen clientes (ejemplo Banco BCI) que tienen varias aplicaciones (servicios de consulta)
disponibles. Estas aplicaciones no están disponibles para otros clientes, por lo que el
módulo debe poder manejar correctamente estos accesos.
- Que el usuario identifique visualmente los elementos de seguridad activos para la
plataforma.
- Tener la posibilidad de administrar los perfiles de cada usuario en forma autónoma.
1.4.2 Visión Comercial de CONSULTASWEB S.A.

- Que la plataforma – luego de autentificar a cada usuario – reconozca su perfil y
pertenencia al cliente, mostrando las opciones (aplicaciones) disponibles para él, en un
contexto visual asociado a su empresa.
- Que el usuario identifique visualmente los elementos de seguridad activos para la
plataforma.
- Tener la posibilidad de administrar los perfiles de cada usuario en forma autónoma.
- Presencia gráfica de cada cliente a los usuarios respectivos, y la posibilidad de entregar
gráfica e información de CONSULTASWEB S.A. a la vez.
- Posibilidad de mostrarle a cada usuario las aplicaciones que tiene activas y aquellas que
no tiene activas, pero que podría tenerlas (si las contrata).
- Mostrar a cada usuario sólo las opciones asociadas a la empresa-cliente a la que
pertenece.
1.4.3 Para el Producción Informática

- Que el esquema de perfilamiento se suscriba a la información que se le muestra el usuario
autentificado.
- Que la administración de este perfilamiento sea expedita al realizarse en
CONSULTASWEB S.A. y por parte del cliente en forma delegada.

1.5 Restricciones y Alcances

- Esto se restringe a la presentación de información y opciones de acuerdo a un perfil
especial y único por usuario.
- No incluye autorización a acceder a aplicaciones específicas. No incluye autentificación.
- Se debe basar el perfilamiento en el username.
- Puede derivarse de la plataforma Active Directory o ser una aplicación separada.
- Privilegiar un desarrollo de solución en fases, para adelantar la activación del esquema en
algún cliente (BCI).

2. Solución Propuesta
Dentro del módulo general de perfilamiento se reconocen dos grandes submódulos, cada uno
enfocado en un propósito diferente. Estos son:
- Página de perfil, generada estéticamente por cada cliente y con las opciones habilitadas
según el perfil de cada usuario.
- Administración de parámetros, consistente en una aplicación de mantención de los
datos de los clientes, sus aplicaciones, y los perfiles de cada usuario.
2.1 Página de Perfil

2.1.1 Caso de Uso 1: Ingreso a la Plataforma
(Despliegue Página de Perfil por Usuario)
Diagrama 2.1 – Ingreso a la Plataforma

Descripción
El usuario hace ingreso a la plataforma, lo cual sólo requiere identificar el usuario por medio de su
username, el cual se captura en la aplicación directamente desde su credencial activa. Este
ingreso recupera los parámetros asociados a la estética del cliente y de los datos de aplicaciones
visibles y activas para el usuario. Adicionalmente, cada vez que un usuario ingresa a la plataforma
debe quedar el registro de este ingreso en una bitácora, para lo cual se podrá aprovechar el
repositorio de transacciones disponible en la plataforma de consulta.
Conceptualizando el Perfilamiento como un módulo que recibe datos de entrada y luego despliega
información, se debe considerar lo siguiente:
- El único parámetro de entrada es la identificación del usuario. Esta identificación servirá
para recuperar los elementos de su perfil desde un repositorio de datos.
- Los elementos del perfil incluyen:
o Cliente al que pertenece. En consecuencia, se recupera la gráfica asociada al
cliente.
o La lista de aplicaciones a las que el usuario tiene visibilidad, distinguiendo aquellas
a las que tiene acceso activo, aquellas a las que sólo tiene derecho a ver el título
pero no tiene el vínculo activo.
- Otros aspectos asociados al cliente son:
o Noticias y Avisos.

2.1.2 Visión General de la Interfaz de Usuario Propuesta
Esta zona se reserva para el logotipo de la

empresa, cargado como fondo de la tabla,
cuyo color podría controlase mediante un css.
Logotipo e información
de la plataforma
Menú dinamico
configurable
La diagramación propuesta debería permitir:

- Cambio fácil del logo del cliente, manteniendo la gráfica de COMICROM visible.
- La posibilidad de poner avisos/novedades comunes para todos los usuarios de cualquier
cliente, o bien sólo los usuarios de un cliente.
- Que todos los usuarios de un mismo cliente vean la misma página de entrada, variando
sólo la lista de aplicaciones disponibles.
o Las aplicaciones disponibles se forman de una lista, en la cual cada ítem de ésta
es un par Nombre+URL de aplicación.
o Cada aplicación asociada al cliente, al ingresar un usuario específico, puede ser:
visible y activa (nombre+link), visible e inactiva (sólo nombre, sin link), o bien
invisible (no se muestra al usuario).
- Acceso a aplicaciones genéricas como:
o Cambio de password de usuario
o Administración delegada de usuarios  sólo acceso el administrador del cliente.
2.1.3 Funcionalidades Especiales y Consideraciones

- Registro Log de Consulta. Cada vez que un usuario ingresa a la plataforma, se debe
dejar registro de su identificación de usuario, la fecha, hora y dirección IP del computador
desde el cual se conectó.
- Usuarios inválidos.
o Si el usuario que ingresa no está autentificado, no debería ingresar a la aplicación
de perfil. Esta página sólo está disponible para usuarios autentificados.

o Si el usuario está autentificado, pero no se cuenta con un registro de su perfil, se

deberá tomar un perfil por defecto definido a nivel de cliente, el cual es común para
todos los usuarios de dicho cliente a los que no se les haya aplicado perfil.
2.2 Administración de Parámetros

2.2.1 Caso de Uso 2: Mantención de Tablas
Mantención de
Tablas
Registro Log
del Ingreso
Administrador RepTransacciones
Diagrama 2.2 – Mantención de Tablas de Parámetros
Descripción
Estas funcionalidades están habilitadas sólo para usuarios especialmente designados con el
privilegio de mantención sobre las tablas de este módulo, denominados “administradores”. Cada
administrador tendrá acceso a las tablas de datos que componen el módulo de Perfilamiento y en
particular, las que estén asociadas con el registro de la siguiente información:
- Clientes registrados. A cada cliente se le asocia un nombre, un prefijo que lo relaciona
con las cuentas de usuario del dominio (en Dominio ECM, cada cuenta tiene asociado el
prefijo del cliente al que pertenece), y adicionalmente datos que determinan la estética a
presentar: logos y hojas de estilo, además de algunos mensajes ad-hoc a los usuarios del
cliente.
- Aplicaciones. Las aplicaciones, asociadas por cliente, identificando su nombre y URL.
- Perfil de Usuario. Reconociendo una relación entre las aplicaciones y cada usuario. Se
especifica una aplicación al usuario, indicando si es visible y activa, visible e inactiva o
directamente invisible e inactiva (caso default: si no está registrada también es invisible).
- Otros datos para el cliente. Tal es el caso de noticias especiales.
2.2.2 Validaciones
Dentro de lo que corresponde al ingreso de datos de las diferentes tablas, se define la necesidad
de validar que

3. Metodología de Desarrollo
RodrigoSandoval.net en sus proyectos ha adoptado una metodología que recoge elementos de
distintas tendencias metodológicas y tecnológicas actualmente en uso en la industria de los
proyectos de software. Principalmente se toman en consideración cuatro modelos:
- CMMI (Modelo de Capacidad de Madurez del SEI de la Carnegie Mellon University), en
cuanto al QUE se quiere alcanzar.
- RUP (Proceso Unificado de Rational) como base de conocimientos para definir el proceso,
estos es QUE se debe hacer y CUANDO para tener un proceso de desarrollo de alta
calidad y productividad.
- MSF (Microsoft Solution Framework), el cual maneja un aspecto muy maduro de los roles,
determinando QUIEN participa en el proyecto.
- Extreme Programming, que es una tendencia reciente de las denominadas metodologías
ágiles, en las cuales se determina COMO se lleva adelante el desarrollo, privilegiando la
comunicación entre los roles del proyecto y la visibilidad de funcionalidad hacia el cliente.
En la configuración actual se ha puesto énfasis en las áreas de proceso clave (KPA) de:
- Administración de Requerimientos.
- Planificación de Proyectos.
- Control y seguimiento de proyectos.
- Aseguramiento de Calidad.
Estas KPA se complementan con el modelo iterativo e incremental propuesto por RUP, orientado a
enfrentar oportunamente los riesgos del proyecto.
Se han definido inicialmente las siguientes etapas del ciclo de desarrollo, para cada una de las
cuales se ha definido un Flujo de Procesos, que establece actividades, responsables y productos
de trabajo.
Cada Flujo se representa en un “Diagrama de Actividad” de UML, en que la “pista” identifica el Rol
responsable, y se detallan las actividades a realizar.
Estos flujos son de conocimiento de toda la empresa y se encuentran publicados en la Intranet de
ConsultasWeb S.A.. Al seleccionar cada actividad en los diagramas se despliega una descripción
que precisa:
- Propósito de la actividad,
- Pasos a seguir,
- Artefactos de Entrada,
- Artefactos de Salida,
- Rol Responsable.
3.1 Procesos de Desarrollo

Etapas relevantes dentro del proceso de desarrollo son las siguientes:
3.1.1 Fase Concepción (Modelamiento y Diseño)

En esta etapa se completan los objetivos de la etapa de “Inception” del RUP, definiendo en
concreto la solución a llevar a cabo (sea desarrollo interno, externalización o compra de paquete),

identificando los principales riesgos y definiendo el plan global del proyecto. Si ha transcurrido
mucho tiempo desde la Evaluación Preliminar, se parte revisando la validez de sus conclusiones.
3.1.2 Fase de Desarrollo (Elaboración y Construcción de RUP)

En esta fase se llevan a cabo las iteraciones necesarias para construir el producto de software.
Cada iteración abarca un subconjunto del sistema, para el cual se detallan los Requerimientos, se
hace análisis, diseño, construcción y test. La iteración termina con un producto de software
probado y en condiciones de ser puesto en Producción. En las primeras iteraciones se desarrolla el
subconjunto del sistema que permite enfrentar los principales riesgos y definir la arquitectura del
sistema. Además, el modelo iterativo permite una evaluación objetiva del estado de avance del
proyecto y una adecuada administración de cambios. Esta fase agrupa las Fases de Elaboración y
Construcción del RUP.
3.1.3 Fase de Desarrollo Transición (estabilización e instalación)

En esta fase se traspasa la aplicación aprobada por el área de QA al área de producción. Una vez
que la aplicación ha sido instalada, se procede a efectuar el Test de Aceptación Usuario. En caso
de ser aprobado se pone término formal al proceso de desarrollo, de lo contrario, se deben
documentar las observaciones y proceder a efectuar las correcciones que se acuerden necesarias.
3.2 Estrategias de Desarrollo

A través del tiempo, el esquema de desarrollo de proyectos de software adoptado por el equipo
que RodrigoSandoval.net pondrá a cargo de este proyecto ha incluido ciertas estrategias que han
demostrado, principalmente en la industria del software, buenos y consistentes resultados.
3.2.1 Etapa de Modelamiento y Diseño

a. Utilización de especificaciones y modelamiento con lenguaje UML, incluyendo
diagramas de Casos de Uso, de Actividades, de Secuencia, de Clases, entre otros.
b. Afinamiento de requerimientos, por medio de reuniones frecuentes con los clientes e
interesados en el sistema. En esta primera etapa – siguiendo parte de la filosofía de la
programación extrema (Extreme Programming – estrategia de desarrollo orientada a
disminuir los costos y maximizar el valor entregado en un proyecto) se valora la
interacción frecuente y directa con el cliente y/o usuarios finales, como forma de
aclarar los detalles de los requerimientos antes de comenzar el desarrollo formal y de
esa forma identificar los cambios necesarios cuando aún es más simple re-diseñar.
c. Enfoque de Diseño Orientado a Aspectos. Tomando en consideración que hay
necesidades transversales dentro de todos los sistemas, se toma una perspectiva en la
cual se reconocen cuáles son aquellas necesidades y se modelan en función de ser
adoptadas por los módulos que correspondan. Tal es el caso de los elementos
asociados a la seguridad de las aplicaciones, la trazabilidad, y la configuración
centralizada.
En esta etapa, para facilitar el entendimiento entre analistas y clientes/usuarios, se trabaja con
diversas alternativas gráficas, que incluyen:
- Uso de prototipos visuales, que permiten darle al usuario una aproximación real a la
interfaz de usuario que finalmente resolverá las funcionalidades.
- Adicionalmente se trabajará con diagramas simples y claros de entender, sin recurrir a
nomenclaturas excesivamente técnicas. Entre los diagramas a utilizar está el de secuencia,
que permite seguir visualmente el ciclo de eventos relevantes para el usuario utilizando el
programa.

- Las minutas de reuniones formales tendrán el detalle suficiente para validar que lo
discutido está claro y entendido por todos.
Se adjuntan ejemplos de este tipo de elementos como anexo a este documento.
3.2.2 Etapa de Desarrollo

a. Uso de la plataforma .NET, utilizando C# como lenguaje de desarrollo.
b. Uso de patrones y estándares, así como buenas prácticas y bloques de aplicación
probados y validados.
Como parte de su estrategia, el equipo de desarrollo es fuerte seguidor de las
tendencias de uso de patrones de diseño, buscando aprovechar las soluciones ya
conocidas y probadas que se han vuelto un estándar en la industria.
Simultáneamente, por medio del movimiento de Patterns & Practices que Microsoft
lleva algunos años impulsando, se han aprovechado soluciones y buenas prácticas
que resuelven problemáticas específicas de una manera controlada. En esta misma
línea, se aprovechan ciertos módulos ya construidos y probados, conocidos como
Application Blocks. Entre ellos, por mencionar algunos, se utiliza el Data Access App.
Block y el Exception App. Block, los cuales simplifican problemáticas estándar como es
el acceso a la base de datos y el manejo de excepciones en el flujo del sistema.
c. Desarrollo Controlado por Testing (Test-Driven-Development). Esta estrategia de
desarrollo es implementada por los desarrolladores, quienes aparte de codificar las
funcionalidades del sistema que tienen asignadas, se aseguran de la calidad de sus
entregas por medio de los tests unitarios. Al adoptar un esquema de desarrollo
asociado directamente a tests pre-programados e involucrados en el código, pueden
asegurar con absoluta seguridad – al correr y aprobar esos tests – que cualquier
modificación que se realiza sobre los módulos que tienen a su cargo durante el
proceso de desarrollo y estabilización, no afecta las funcionalidades ya operativas.
Para ello, se adoptó una herramienta que trabaja junto a Visual Studio descrita en la
sig. sección.
d. Frecuente Compilación e Integración de Módulos. De modo de lograr visibilidad e
integridad del desarrollo del proyecto, así como tener un control de corto plazo en la
integridad de los módulos. Esta práctica es apoyada por herramientas que incluyen
repositorio centralizado de código y el concepto conocido en la industria como el “Daily
Build”. Esta práctica, cuando corresponde, se traduce en entregas parciales con mayor
frecuencia, que permiten darle visibilidad al avance del proyecto.
3.2.3 Etapa de Transición y Entrega

El objetivo de la Metodología de Testing es definir el Criterio de Aceptación y especificar la forma
como se probará la aplicación a ser testada con la finalidad que todos los componentes de
software concuerden con el criterio definido.
La aplicación rigurosa de la metodología permite descubrir en forma temprana defectos que
pueden impactar en el desarrollo, poniendo en riesgo el cumplimiento de las metas fijadas, como
también asegurar una alta calidad del producto final y que el proceso de construcción del software
esté bajo control y sea repetible. Como metodología se ha adoptado un proceso de certificación
iterativo incremental permitiendo mitigar tempranamente los principales riegos propios del proceso
de desarrollo de software.
3.2.3.1 Focalización de las Pruebas

Los esfuerzos de Testing se focalizarán fundamentalmente a:

a) Testing Funcional y de Cobertura. El objetivo de estas pruebas es validar si todas las

funcionalidades especificadas en el documento de Diseño están construidas y
funcionan como es debido.
b) Testing de Performance. Su objetivo consiste en generar una carga sobre el sistema
mientras se mide su respuesta y se monitorea el comportamiento de los servicios, con
el fin de asegurar que la aplicación será capaz de responder en forma ágil bajo cargas
severas, que no se presenten errores y que los servicios no colapsen. Para ello se
utilizan herramientas para generar la carga y utilitarios para monitorear los servicios y
analizar los logs resultantes del proceso de pruebas.
c) Testing de Compatibilidad. La finalidad de este testing es verificar la correcta
operación de los diferentes navegadores Web y sistemas operativos de los usuarios
finales.
3.3 Roles del Equipo

Para enfrentar éste y otros proyectos de similar magnitud, se recomienda adoptar un esquema de
roles que permitan delinear claramente las distintas funciones de las personas involucradas, y
llevar adelante un proceso metodológico controlado.
Esta idea está soportada por un concepto de base que rescata definiciones de diversas otras
metodologías actualmente aplicadas en el mercado.
Como base para la constitución del equipo de personas que participan en el proyecto, se toma
como base la definición propuesta por MSF (Microsoft Solutions Framework), la cual se basa en los
siguientes principios fundamentales:
 Fomentar la comunicación abierta
 Trabajar hacia una visión compartida
 Facultar a los miembros del equipo
 Establecer competencias clara y responsabilidad compartida
 Enfocarse en entregar valor al negocio
 Mantenerse ágil, esperar el cambio
 Invertir en calidad
 Aprender de todas las experiencias
En esa línea, MSF fomenta la combinación de distintas ideas, a través de equipos de pares y
define roles y responsabilidades para los equipos de pares.
Los roles principales de este modelo son seis, que se describen en el siguiente diagrama.
Administración de
Programa
Administración de Desarrollo
Producto
Experiencia de Pruebas
Usuario
Administración de
Implantación
Roles en el esquema MSF de gestión de proyectos.

Para llevar adelante este esquema, cada rol tiene su respectiva meta, como se describe a
continuación.
Rol Meta Clave de Calidad

Administración del Producto Clientes Satisfechos
Administración del Programa Entrega de la solución dentro de las restricciones del proyecto
Desarrollo Construcción de acuerdo a la especificación
Pruebas Aprobación para liberación sólo después de identificar y atender los asuntos
relacionados con la calidad del producto
Experiencia del Usuario Desempeño mejorado del usuario
Administración de Implantación Gestión de puesta en marcha y operación contínua
Este equipo sigue una secuencia de hitos que se transforman en un proceso iterativo de desarrollo,
donde cada iteración reconoce las etapas fundamentales que también se respaldan en
metodologías como RUP.
Liberación
Completada
Aprobación de Liberar Visualizar Visión/Alcance

Liberación Aprobado
MSF
Estabilizar Planificar
Desarrollar
Alcance Planos del Proyecto

Completado Aprobados
Cabe hacer notar en forma importante, que la labor de Product Manager, representante del cliente
y defensor de las funcionalidades requeridas será un rol que deberá cumplir la contraparte de
negocio de ConsultasWeb S.A., por tanto, deberá contar con la disponibilidad de tiempo para
interactuar en todas las instancias de validación de requerimientos y posteriormente revisión de
funcionalidades.
Para este proyecto, se contempla el siguiente equipo:
Rol Persona Empresa Dedicación
Program Manager José Tapia RodrigoSandoval.net 50%
Developer Ariel Muñoz, Ricardo RodrigoSandoval.net 100%

Vicencio.
Testing Cristina Figueroa RodrigoSandoval.net 100% a partir de

semana 2
Deployment - ConsultasWeb S.A. 30% estimado, a

partir de semana 5
User Experience - (comercial) ConsultasWeb S.A. 30% semana 1 a 3

- (operaciones)
Product Manager Juan Torres ConsultasWeb S.A. 50%

4. Calendario e Hitos de Entrega

4.1 Actividades de Preparación para el Desarrollo
Estas actividades no serán visibles para el usuario final, pero son necesarias en una etapa de
setup para el desarrollo, permitiendo al equipo contar con los ambientes de desarrollo y de testing
adecuados para conducir los hitos de entrega adecuadamente en servidores de ConsultasWeb
S.A. en forma posterior. Estas actividades incluyen:
- Instalación de Software inicial: Windows 2003 Server + SQL Server 2000 con las mismas
versiones que se cuenta en los servidores de ConsultasWeb S.A. y configuraciones
equivalentes (en particular a nivel de cuentas de dominio para los usuarios del sistema).
- Instalación de Hummingbird DM: con la misma versión y configuración equivalente para
ConsultasWeb S.A..
- Instalación de software adicional. Tal es el caso de los componentes del Visor (el
propuesto es Spicer Imagenation), así como los componentes de herramientas para
Reportes, y Workflow necesarios.
4.2 Calendario de Hitos Relevantes

Las actividades se han ordenado de la siguiente manera, de modo de maximizar la visibilidad que
el cliente tendrá del avance y evolución del sistema en su desarrollo.
Semana 1 – Levantamiento de Requerimientos Detallado.
Esta actividad requerirá de la participación activa por parte de ConsultasWeb S.A., de modo de
determinar con detalle las funcionalidades requeridas por el sistema.
Entregables: Esta semana de trabajo concluirá con la entrega de un documento de
levantamiento de requerimientos estructurado y ordenado, que deberá ser validado por la
contraparte del cliente (ConsultasWeb S.A.). Parcialmente se irán generando minutas y borradores
del documento para poder ir validando los detalles. Adicionalmente, se entregará un prototipo
visual que tiene por objetivo mostrar la forma en que se entregarán las funcionalidades, así como
validar en el momento la forma en que se resolverían los requerimientos.
Semana 2 y 3 – Preparación Sistemas y Desarrollo Inicial
Durante estas dos semanas se comenzará el desarrollo tomando como base la definición de
requerimientos detallados de la semana anterior. En esta semana de trabajo es muy posible que se
requiera de la validación de detalles puntuales por parte de la contraparte de negocio del cliente, lo
cual se haría en sesiones personales breves y previamente coordinadas, así como por e-mail y/o
teléfono.
Entregables: Como resultado de esta etapa de desarrollo y al concluir las dos semanas, se
entregará una versión funcional parcial que contará con las siguientes funcionalidades: desplegar
página de perfilamiento, con gráfica asociada al cliente y las opciones habilitadas al usuario.
Semana 3 y 4 – Desarrollo Módulo Administración de Perfiles.
En estas dos semanas se trabajará en completar la funcionalidad del Administración.
Entregables: Al concluir las semanas de desarrollo se podrá instalar una versión funcional para
revisión por parte de los usuarios relevantes o contraparte del cliente.
Semana 5 – Validación y Estabilización.
Se espera un proceso de revisión exhaustivo por parte del cliente, de modo de validar la correcta
operación ante escenarios “realistas”: Cualquier observación relevante deberá ser corregida o

atendida durante estos días de revisión, según se determine de común acuerdo su relevancia y
necesidad, tomando como referencia el documento de requerimientos.
Entregables: al concluir esta semana de revisión y estabilización se entregará una versión
operativa y probada del sistema, junto con tests de aceptación formalizados.
Semana 6 – Capacitación y Cierre
Durante esta semana se realizará la capacitación de uso del sistema a administradores.
Adicionalmente, se formalizará la entrega del sistema con acta de validación y entrega.
Entregables: Capacitación y el material utilizado en este proceso. Adicionalmente, se hará entrega
de la documentación de sistema, incluyendo manuales de usuario, de administrador e instalación,
diseño, y elementos de instalación y código fuente.
4.3 Participación de ConsultasWeb S.A. en el Proyecto

Dentro de las diferentes actividades consideradas en este proyecto, se requiere la participación
activa de personal específico de ConsultasWeb S.A. para las siguientes actividades:
- Levantamiento de Requerimientos Detallado. Tomando en cuenta la definición por
parte de la contraparte de ConsultasWeb S.A. quien se focalizaría en las necesidades de
negocio del sistema. Qué se necesita resolver, cuál de las alternativas propuestas podría
ser suficiente/necesario, etc. Esta participación requiere dedicación durante los días
iniciales del proceso de levantamiento, en la forma de reuniones de entre 1 y 3 horas de
duración, así como la disponibilidad para resolver dudas más detalladas y específicas una
vez iniciado el desarrollo, en la forma de reuniones cortas y precisas (de media a una
hora), por correo electrónico y/o por teléfono.
- Implantación de versiones intermedias y definitiva. Para poder instalar el software en
las instalaciones (servidores) de ConsultasWeb S.A., se requiere contar con personal
específico que tenga los accesos correspondientes y que adicionalmente tenga la
disponibilidad de tiempo – en sesiones programadas con anticipación – para participar del
proceso de instalación y configuración, como parte del traspaso de conocimiento de la
operación técnica del sistema. Esto implica sesiones cada dos semanas aprox. de entre 2
y 4 horas consecutivas.
- Validación de Entrega Funcional. Si bien el proceso de desarrollo contempla actividades
de testing y certificación de la correctitud de la funcionalidad, se solicita que personal de
ConsultasWeb S.A., específicamente quienes conocen las necesidades de los usuarios de
Document Control y/o que serán los usuarios finales del sistema, que dispongan de
tiempo para decepcionar las versiones intermedias y particularmente la definitiva. Estas
sesiones de revisión serán formalizadas con una lista (tipo checklist) de funcionalidades
entregadas en la versión intermedia y final, que los usuarios podrán revisar con diferentes
niveles de profundidad en cuanto a la operación del, sistema, y complementando los tests
funcionales entregados y realizados por parte del equipo de desarrollo, confirmarán la
correcta operación y funcionamiento del sistema de acuerdo a los requerimientos
levantados en la etapa inicial.

5. Análisis de Riesgos y Temas por Resolver

5.1 Riesgos
Integración con Active Directory
Los perfiles de usuarios deben asociarse a las cuentas registradas en el Domain Controller, de
modo que se administran los datos de estas cuentas desde Active Directory. Dado el poco
conocimiento que existe en el mercado de este tipo de integración, se reconoce como un riesgo.
 Calificación Gravedad: Media-Alta
 Tipo: Interno
 Estrategia de resolución: se propone hacer una prueba de concepto durante la fase de
concepción del proyecto para resolver los aspectos técnicos relevantes.
5.2 Temas por Resolver

 Se requiere de parte de ConsultasWeb S.A. datos de prueba para cargar en los ambientes de
desarrollo y de prueba del grupo de desarrollo. Estos datos deberán estar durante la etapa de
elaboración en la forma de DTS para carga en SQL-Server.
 Se requiere definir por parte de ConsultasWeb S.A. quién será contraparte comercial para
validar los aspectos de presentación y funcionalidad de la página de perfilamiento.
 Se requiere definir por parte de ConsultasWeb S.A. quién será contraparte operativa, en otras
palabras, quiénes operarán el sistema una vez implantado, así como quién operará como
administrador de los perfiles.

Propuesta Desarrollo

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Propuesta Desarrollo

Загружено:

Авторское право:

Доступные форматы

Propuesta Técnica

Sistema de Perfilamiento de Usuario

© RodrigoSandoval.net, Lo Barnechea, Santiago Pág. 1

1.1 Motivación para este Requerimiento

1.2 Presentación de Perfilamiento

© RodrigoSandoval.net, Lo Barnechea, Santiago Pág. 2

1.3 Terminología acordada

1.4 Criterios de Éxito

1.4.2 Visión Comercial de CONSULTASWEB S.A.

1.4.3 Para el Producción Informática

© RodrigoSandoval.net, Lo Barnechea, Santiago Pág. 3

1.5 Restricciones y Alcances

© RodrigoSandoval.net, Lo Barnechea, Santiago Pág. 4

2.1 Página de Perfil

Diagrama 2.1 – Ingreso a la Plataforma

© RodrigoSandoval.net, Lo Barnechea, Santiago Pág. 5

2.1.2 Visión General de la Interfaz de Usuario Propuesta

Esta zona se reserva para el logotipo de la

La diagramación propuesta debería permitir:

2.1.3 Funcionalidades Especiales y Consideraciones

© RodrigoSandoval.net, Lo Barnechea, Santiago Pág. 6

o Si el usuario está autentificado, pero no se cuenta con un registro de su perfil, se

2.2 Administración de Parámetros

Diagrama 2.2 – Mantención de Tablas de Parámetros

© RodrigoSandoval.net, Lo Barnechea, Santiago Pág. 7

3.1 Procesos de Desarrollo

3.1.1 Fase Concepción (Modelamiento y Diseño)

© RodrigoSandoval.net, Lo Barnechea, Santiago Pág. 8

3.1.2 Fase de Desarrollo (Elaboración y Construcción de RUP)

3.1.3 Fase de Desarrollo Transición (estabilización e instalación)

3.2 Estrategias de Desarrollo

3.2.1 Etapa de Modelamiento y Diseño

© RodrigoSandoval.net, Lo Barnechea, Santiago Pág. 9

3.2.2 Etapa de Desarrollo

3.2.3 Etapa de Transición y Entrega

3.2.3.1 Focalización de las Pruebas

© RodrigoSandoval.net, Lo Barnechea, Santiago Pág. 10

a) Testing Funcional y de Cobertura. El objetivo de estas pruebas es validar si todas las

3.3 Roles del Equipo

© RodrigoSandoval.net, Lo Barnechea, Santiago Pág. 11

Rol Meta Clave de Calidad

Aprobación de Liberar Visualizar Visión/Alcance

Alcance Planos del Proyecto

Rol Persona Empresa Dedicación

Program Manager José Tapia RodrigoSandoval.net 50%

Developer Ariel Muñoz, Ricardo RodrigoSandoval.net 100%

Testing Cristina Figueroa RodrigoSandoval.net 100% a partir de

Deployment - ConsultasWeb S.A. 30% estimado, a

© RodrigoSandoval.net, Lo Barnechea, Santiago Pág. 12

User Experience - (comercial) ConsultasWeb S.A. 30% semana 1 a 3

Product Manager Juan Torres ConsultasWeb S.A. 50%

© RodrigoSandoval.net, Lo Barnechea, Santiago Pág. 13

4. Calendario e Hitos de Entrega

4.2 Calendario de Hitos Relevantes

© RodrigoSandoval.net, Lo Barnechea, Santiago Pág. 14

4.3 Participación de ConsultasWeb S.A. en el Proyecto

© RodrigoSandoval.net, Lo Barnechea, Santiago Pág. 15

5. Análisis de Riesgos y Temas por Resolver

5.2 Temas por Resolver

© RodrigoSandoval.net, Lo Barnechea, Santiago Pág. 16

Вам также может понравиться