ESQUEMA DE UNA PROPUESTA TECNICA PARA LA ELABORACION DE SISTEMA

Propuesta Técnica
Sistema de Perfilamiento de Usuario
ConsultasWeb S.A.

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 servicio1.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.”
Propuesta Desarrollo Sistema Perfilamiento

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

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.

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:

• Cliente al que pertenece. En consecuencia, se recupera la gráfica asociada al cliente.
• 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:

• Noticias y Avisos.

2.1.2 Visión General de la Interfaz de Usuario Propuesta

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.
  
  
  • Las aplicaciones disponibles se forman de una lista, en la cual cada ítem de ésta es un par Nombre+URL de aplicación.
  • 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:
  
  • Cambio de password de usuario
  • Administración delegada de usuarios  sólo acceso el administrador del cliente.

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. 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. Si el usuario está autentificado, pero no se cuenta con un registro de su perfil, sedeberá tomar un perfil por defecto definido a nivel de cliente, el cual es común paratodos 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

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”. Cadaadministrador 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.

Validaciones

Dentro de lo que corresponde al ingreso de datos de las diferentes tablas, se define la necesidad de validar el Que

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.
  

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

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

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.