1. REPUBLICA BOLIVARIANA DE VENEZUELA
INSTITUTO UNIVERSITARIO POLITÉCNICO
“SANTIAGO MARIÑO”
EXTENSIÓN PORLAMAR
ESCUELA DE INGENIERÍA DE SISTEMAS
CATEDRA: SISTEMAS II
PROPUESTA DE UN SISTEMA DE AUTENTIFICACIÓN Y AUTORIZACIÓN DE
USUARIO ELECTRONI,C.A
Ronald Bello C.I: 19.682.121
Porlamar, abril de 2017

2. INTRODUCCIÓN
Tomando en consideración la plataforma de servicios de consulta Web de
ELECTRONI,C.A., también conocida como SCW (Sistema Consultas Web), actual-
mente se está implantando un cambio a nivel de la estructura transversal de admi-
nistración de cuentas de usuario, autentificación y autorización de acceso a las apli-
caciones.
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 (em-
presa) al que pertenece.
En suma, la plataforma de autentificación y autorización se esquematiza de la si-
guiente manera, donde unas secuencias de pasos lógicas llevan al usuario a (A)
entrar al formulario de autenticación, ingresar su usuario y contraseña, 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.

3. ANÁLISIS DE LOS REQUERIMIENTOS Y ALCANCE
-Que la plataforma reconozca su perfil y pertenencia al cliente, mostrando las op-
ciones (aplicaciones) disponibles para él, en un contexto visual asociado a su em-
presa.
-Existen clientes que tienen varias aplicaciones disponibles. Estas aplicaciones no
están disponibles para otros clientes, por lo que el módulo debe poder manejar co-
rrectamente 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.
-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
integrar gráfica e información de ELECTRONI,C.A a la vez.
-Posibilidad de mostrarle a cada usuario las aplicaciones que tiene activas y aque-
llas 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.
-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 ELEC-
TRONI,C.A y por parte del cliente en forma delegada.

4. RESTRICCIONES
-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 autentifi-
cación.
-Se debe basar el perfilamiento en el nombre de usuario.
-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 es-
quema en algún cliente.

5. SOLUCION PROPUESTA
El usuario hace ingreso a la plataforma, lo cual sólo requiere identificar el
usuario por medio de su nombre de usuario, el cual se captura en la aplicación di-
rectamente desde su credencial activa. Este ingreso recupera los parámetros aso-
ciados 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 identifi-
cació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 aso-
ciada al cliente.
o La lista de aplicaciones a las que el usuario tiene visibilidad, distin-
guiendo 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.

6. FASES DE DESARROLLO
Para entrar en la etapa de desarrollo se toma a consideración el siguiente modelo:
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 desa-
rrollo de alta calidad y productividad.
1.-Fase de concepción (Modelamiento y Diseño)
En esta etapa se completan los objetivos de la etapa de “Incepción” del RUP, defi-
niendo en concreto la solución a llevar a cabo (sea desarrollo interno, externaliza-
ción o compra de paquete), Propuesta Desarrollo Sistema Perfilamiento identifi-
cando los principales riesgos y definiendo el plan global del proyecto. Si ha transcu-
rrido mucho tiempo desde la Evaluación Preliminar, se parte revisando la validez de
sus conclusiones.
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 de-
tallan 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 (Proceso Unificado de Rational).
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 pro-
ducció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.

7. CALENDARIO DE ENTREGA
Las actividades se han ordenado de la siguiente manera, de modo de maxi-
mizar la visibilidad que el cliente tendrá del avance y evolución del sistema en su
desarrollo.
Semana 1: Levantamiento de Requerimientos Detallado.
Documento de levantamiento de requerimientos estructurado y ordenado, que de-
berá ser validado por la contraparte del cliente. Parcialmente se irán generando mi-
nutas y borradores del documento para poder ir validando los detalles. Adicional-
mente, 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.
Como resultado de esta etapa de desarrollo y al concluir las dos semanas, se en-
tregará 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.
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.
Al concluir esta semana de revisión y estabilización se entregará una versión ope-
rativa y probada del sistema, junto con test de aceptación formalizados.
Semana 6: Capacitación y Cierre
Capacitación y el material utilizado en este proceso. Adicionalmente, se hará en-
trega de la documentación de sistema, incluyendo manuales de usuario, de admi-
nistrador e instalación, diseño, y elementos de instalación y código fuente.

8. ANÁLISIS DE 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 in-
tegración, se reconoce como un riesgo.
o Calificación Gravedad: Media-Alta
o Tipo: Interno
o 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 rele-
vantes.