Propuesta Técnica

Propuesta Técnica

Sistema de Perfilamiento de Usuario

ConsultasWeb S.A.

 

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:

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

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

 

 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.

 

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.

 

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.

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:

 

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.

Link de mas ejemplos de Propuesta Tecnica

http://www.scribd.com/doc/30882337/Propuesta-tecnica

http://www.medellin.gov.co/alcaldia/jsp/modulos/N_admon/obj/img/vinculoscbg/FORTALEC%20DE%20ORGAN%20REDES%20Y%20ALIANZAS%20_19-10-05_.pdf

Ejemplos de cuadros de Propuestas Técnicas – Universidad de Guanajuato

PROPUESTA TECNICA

ANEXO T-2

ANEXO T-2A

LISTADO DE MATERIALES MAS SIGNIFICATIVOS

ANEXO T-2A

  LICITACION NO.:

 OBRA:

DOCUMENTO

 T-2 A

 

RAZON SOCIAL DEL LICITANTE

 

 FIRMA DEL LICITANTE

HOJA :

DE :

LISTADO DE MATERIALES MAS SIGNIFICATIVOS:

CLAVE DESCRPCION UNIDAD CANTIDADES

A UTILIZAR

ESPECIFICACIONES

TECNICAS

 
1 2 3 4 5  
           
        1.- CLAVE

2.- DESCRIPCION DE LOS MATERIALES.

3.- UNIDAD DE MEDICION

4.- CANTIDADES A UTILIZAR

5.- ESPECIFICACIONES TECNICAS CONTEMPLADAS EN BASES

 

       
       
       

SE DEBERAN ENLISTAR LOS MATERIALES MAS REPRESENTATIVOS PUESTOS EN EL SITIO DE LOS TRABAJOS, INDICANDO LAS CANTIDADES A UTILIZAR Y SUS RESPECTIVAS UNIDADES DE MEDICION SIN COSTOS.

 INCLUIR DIRECTORIO DE PROVEEDORES:

 CLAVE       RAZON SOCIAL Y DIRECCION                                                               TELEFONO:

 

  

PROPUESTA TECNICA

ANEXO T-3

ANEXO T-3 A 

RELACION DE MAQUINARIA Y EQUIPO DE CONSTRUCCION

ANEXO T-3 A

LICITACION NO.:

 OBRA:

DOCUMENTO

 T-3 A

 

RAZON SOCIAL DEL LICITANTE

 

 FIRMA DEL LICITANTE

HOJA :

DE :

RELACION DE MAQUINARIA Y EQUIPO DE CONSTRUCCION:

No. ECO. NOMBRE DE LA MAQUINA O EQUIPO MOD. FACTURA VIDA UTIL ARRENDADO DISPONIBILIDAD
          SIN OPCION COMPRA CON OPCION COMPRA UBICACIÓN FISICA FECHA DE DISPONIBILIDAD EN EL SITIO  
1 2 3 4 5 6 7 8 9  
                   
                   
                   
                   
                   
    1.- NUMERO ECONOMICO DE LA MAQUINA

2.- EL NOMBRE DE LA MAQUINA O EQUIPO.

3.- EL MODELO CORRESPONDIENTE YA SEA COMPLETO O CON LAS ABREVIATURAS CONOCIDAS EN EL RAMO DE LA CONSTRUCCION.

4.- NUMERO DE FACTURA, SI EL EQUIPO ES DEL LICITANTE

5.- VIDA UTIL EN PORCENTAJE

6.- SI SE ARRENDARA SIN OPCION A COMPRA

7.- SI SE ARRENDARA CON OPCION A COMPRA

8.- EN LO QUE ESTA SIENDO USADA ACTUALMENTE.

9.- FECHA EN QUE SE DISPONDRA DEL EQUIPO EN EL SITIO.

   
       
       
       
       
       
       
       
       
       
                   
                           

 LA MAQUINARIA RELACIONADA SERA LA ADECUADA Y SUFICIENTE PARA LLEVAR A CABO LOS TRABAJOS, EN CONGRUENCIA CON EL PROGRAMA DE UTILIZACION DE MAQUINARIA Y EQUIPO DE CONSTRUCCION.

1 comentario

  1. Temas « César Augusto Luna Victoria Bazán said,

    […] Propuesta Técnica […]

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: