PRIORIDADES
Categorización de incidentes
La categorización del incidente a resolver es fundamental para su adecuado
tratamiento y pronta resolución (o sea, eficiencia y eficacia).
La categoría define el recorrido del incidente en la organizacion . Una categoría equivocada puede hacer que un incidente “navegue sin rumbo” dentro del área TI.

Prioridad: secuencia en que se tratarán los incidentes.
 Se determina por el impacto, la urgencia y el esfuerzo.
 Impacto: desde el punto de vista del negocio.
 Urgencia: es la velocidad con la que debe resolverse el incidente.
 La prioridad y la urgencia no se definen en base a la presión del usuario
sino según los procedimientos y los acuerdos de servicio. Deben usarse
criterios uniformes y preestablecidos

IMPACTO

El criterio típico debería incluir:
Coste potencial de la no-resolución  (para el cliente)  ej: (2/4) grande,0 pequeño(1/4) desconocido
Amenaza de lesión a clientes o empleados              ej: (2/4) grande,0 pequeño,(1/4) desconocido
Implicaciones legales                                                   ej:(2/4)  grande,0 pequeño(1/4) desconocido
Trastorno a clientes y empleados                               ej:(2/4)  grande,0 pequeño,(1/4) desconocido
El impacto no trata de la complejidad de la solución

ESFUERZO

0 pequeño 1/2 dia
1 intermedios o desconocidos 1-2 dias
2 grande   minimo3 dias

URGENCIA (fecha compromiso-hoy)

 entre 0 y 3 dias                         -> 2
 entre 3 y 5 dias o desconocido -> 1
 mayor de  5                    ->  0

Un esquema de PRIORIDAD

1->normal esfuerzo (0)    ,pequeña urgencia (0) ,impacto (0)
2->importante esfuerzo (1),normal urgencia  (1) , impacto (1) ,
3->alta  : esfuerzo es (2),alta urgencia    (2) , impacto (2)

ORDENES DE PAGO

Este tema es una de las encrucijadas de empresas productivas / servicio/comerciales
Es un "nudo" , una intersección de transacciones
El proveedor nos emite facturas por sus servicios /productos
Esos y otros comprobantes constituyen la "deuda" con el proveedor
Al momento de disminuir el nivel de lo adeudado , surgen una serie de preguntas
Que esta pendiente de pagar a xxxx?
Cuando fue el ultimo pago hecho?
Que cheque recibimos de clientes como pago y están a tiempo para utilizarlos?
Cuanto se pago de la factura xxxxx?
Que saldo hay en el banco yyyy?
Como quedara la deuda después del pago?
Sera conveniente pagar el 100% de lo adeudado ?
Que pasa si se paga una parte?
Los procesos informatizados generan registracion de la deuda?
etc
etc
etc
Por ejemplo una empresa de transporte contrata camiones para sus servicios
El sistema de transporte genera la registracion de la deuda de cada viaje
Cuando se paga , además de actualizar las cuentas de los proveedores y bancos , se actualizan la caja y el iva compras

Esta es una versión refinada y extendida de lo citado en post anterior
Se ha dado mucha importancia a la necesidad de manejo sencillo para que no sea imprescindible la existencia de una función de tesorería o administración de pagos
Cualquier persona responsable y cuidadosa puede obtener resultados importantes

Cilcos de desarrollo:
ciclo de desarrollo evolutivo o iterativo o que?
El concepto de un desarrollo evolutivo implica cambio y eso esta muy bien . Pero quien asegura que el cambio es una evolucion ?
La teoria hace muy apetitosa la idea de un proceso de desarrollo guiado por el concepto de evolucion.
Un proceso de desarrollo iterativo hace pensar en la famosa espiral
Entonces nos auxilia el concepto del prototipo
Pero en el mundo de todos los dias me parece mas correcto el proceso de : versiones sucesivas
porque aparte de los errores y defectos que seran mejorados en las proxmas versiones , es fundamental el siguiente tema: requerimientos cambiantes o nuevos que implican una nueva version del soft

Factura  electronica

Se desarrollo una etension de las app existentes

El usuario genera una factura ; el app lo manda al web service del afip y devuelve su aprobacion

O sea que sobre un tradicional sistema de stocks nuestro ; corriendo una conversion de tablas y agregado datos de configuracion , se puede agregar la componente de FACTURACION ELECTRONICA .

Y extiende un sistema con:

-Multiples depositos

-Multiples puestos de trabajo

-Multiples operadores del sistema

-Multiples vendedores

-Multiples precios

-Recargos / Limite de venta y deuda a Clientes 

-Circuito de reposicion de mercaderia

-Remitos y posterior facturacios de remitos

-Presupuestos y posterior facturacion

-Control de Formas de Pago

-Cuentas corrientes
-Tarjetas de credito
-Analisis de Venta
-Analisis de Margenes
-Analisis Anual
-Valorizacion de stoks
-etc
-etc
-etc

Autenticación y cifrado

Notas de "Security complete" SYBEX
ciphertext=TEXTO CIFRADO =información transformada en un formato que puede ser luego revertido
Habitualmente es creada usando un crypto algorithm(ALGORITMO DE ENCRIPTADO) and a crypto key (llave de encriptado)
Crypto algorithm =(ALGORITMO DE ENCRIPTADO)= es implemente una formula matematica que se aplica a la informacion que se desea encriptar
Crypto key =(LLAVE DE ENCRIPTADO)= es una variable adicional injectada en el algoritmo para asegurarse que el texto cifrado no se deriva usando la misma operación
computacional todas las veces que el algoritmo procesa información
En 1976 Diffie y Hell introducen el concepto de  public cipher keys (clave publica de cifrado)
Una LLAVE PUBLICA es una llave de cifrado que ha sido matematicamente derivada de una LLAVE PRIVADA O LLAVE SECRETA DE CIFRADO
La información encriptada con la llave publica , puede ser desencriptada únicamente con la llave privada.
Las llaves no son simétricas.
La llave publica es especialmente diseñada para usarse en el encriptado datos, mientras que la llave privada es usada para desencriptar texto cifrado
Diffie-Hellman puede usarse para PROVEER AUTENTICACIÓN
Esto se hace firmando un mensaje con tu llave privada antes de encriptarla con la llave publica.
FIRMAR=es un algoritmo que procesa tu llave privada y el contenido del mensaje. esto crea una firma digital única, que se agrega al final del mensaje.
Dado que el contenido del mensaje es usada para crear la firma , tu firma digital sera diferente con cada mensaje que mandes.
Supongamos que queremos mandar a Fred un mensaje privado

1- ud crea una firma digital , utilizando tu llave privada
2- encriptar el mensaje usando  la llave publica de Fred
3- Cuando Fred recibe el mensaje ,desencripta el texto ciifrado  usando su llave privada
4-verifica la firma digital usando tu llave publica
5- si la firma coincide , Fred sabe que el mensaje es autentico y no ha sido alterado

El portal de Sistemas
Los urgentes requerimientos , habitualmente apuntan a la creación de aplicaciones que sirven de soporte a actividades esenciales de la empresa.
Generalmente entre la aplicaciones existentes , existe un grado de integracion a través de datos compartidos
Pero en el mundo real tenemos varios factores que atentan en contra de la fácil integracion de sistemas. Entre ellos: procesos de negocio , division del trabajo, datos especializados , aplicaciones especializadas , semántica difusa , etc que tienden a lo que se conoce como "disparate systems"
Entre las diversas soluciones propuestas y compiladas en patrones , hemos optado por el "portal de integracion"

En nuestra solución tenemos una aplicación  para el armado del portal , que permite la selección de aplicaciones y su agrupacion en una estructura jerárquica de árbol con asociacion de imagenes para facilitar su identificacion ; además como cada aplicacion puede tener control de acceso (en nuestros sistemas se utiliza una política de niveles de autorización  apuntando al patrón ACL) se simplifica la operativa de acceso permitiendo la identifiacion única al ingresar al portal

Para el usuario la apariencia del portal es esta:

LOS ACTORES EN LA CONSULTORÍA

EL CONSULTOR
EL CLIENTE:  es el que "representa la empresa y non hacen los encargos ,el que paga y volverá a contratar
EL USUARIO: el "sufriente" o "sufridor", el personaje imprescindible en esta trama , el que carga datos en la computadora , el que los busca , el que utiliza los programas como si fueran una "maquina", el que junta los datos y arma lo que los jefes le piden
EL BENEFICIARIO: los que se afectan directa o indirectamente de las consecuencias derivadas de nuestro trabajo , no son los que toman desiciones respecto de nuestro trabajo .
EL PRODUCTO

Trabajamos para  clientes ; los usuarios  nos mostraran sus necesidades ,y pueden ser hasta opuestas a los objetivos del cliente. . Pero lucharan para conseguir que nuestro producto o solución atienda sus necesidades. Hay que atender esto porque se busca integrar al usuario como un actor importante y no como un "sufriente" . Pero se debe manejar el riesgo de qu7er  empecemos a ver al cliente con los ojos del sufriente usuario. No se debe asumir los objetivos del usuario como propios
Los beneficiarios  generalmente no son personajes cercanos a la acción , pero se venderán ante nosotros como asesores del cliente . Es interesante tenerlos en cuenta porque así podemos valorar la extensión y sinergia de nuestro trabajo