CONSULTORIA

Consultoria es el proceso por el cual ayudamos a nuestros clientes a resolver problemas o alcanzar objetivos

Nuestras metas durante el proceso son:

Establecer un vinculo de colaboracion Solucionar los problemas de forma permanente Brindar atencion a los aspectos tecnicos y a las personas

Nuestra experiencia se ha desarrollado en empresas comerciales , industriales y de servicios donde nuestros consultores hicieron su aporte en el area de direccion , administracion, operaciones administrativas , produccion ,infromación para desiciones e información para operación , tecnologia informática , análisis de sistemas , diseño de sistemas , reingenieria

Las componentes basicas de un trabajo de consultoria en su empresa seran:

Exploracion Fijacion de objetivos Programa de trabajo Controles Planificar transferencia , instalacion,institucion,puesta en marcha

Para trabajar como consultor o independiente, uno necesita ser un 

verdadero experto en el campo en el que se ha especializado.

Trabajamos sobre datos y reglas para modelar sistemas informaticos útiles, estables , robustos , capaces de interactuar eficazmente con las computadoras y comodamente con los seres humanos que los manejan

En nuestra tarea de consultoria siempre tenemos presente que :un sistema informático instituido debe ser revisado periódicamente para cersiorarse de que se estén empleando los procedimientos y datos apropiados. Este seguimiento es esencial para obtener los beneficios esperados y recuperar los gastos causados por los cambios. Un grupo de trabajo debe ver en el seguimiento una oportunidad para introducir cambios de mejoramiento . ....Deberá cerciorarse que el trabajador individual por lo menos no tendrá que enfrentar mas contingencias que las que son normales en la organización (G. Nadler: Diseño de sistemas de producción)

1- Lo escucharemos

2- Reuniremos informacion y evaluaremos

3- Propondremos una solucion factible (Aseguramiento de datos y estructuras , reingenieria de procesos de informacion y  de sistemas esenciales)

4- Si es necesario iniciaremos un proceso de consultoria

➤Cualquier oferta de soft hace exhibicion de sus CARACTERISTICAS

que esta escrito en n+/- ,
 que los datos se guardan en la base de datos estacional orateplus ,
 que es bajo en contenido de sodio ,
 que es cero azucar ,
 que es un diseño transaction holatv! ,
 que es multiusuario
que cuenta y acumula los flujos
que controla los saldos
que el diseño de informacion y procesos esta basado en componentes zzz
 que esta integrado a la red regional y se hace delivery de cafe incluido
que la empresa esta aprobada por la jtp 666
 que se cumple con la normativa gral y especial del area
 etc
 etc
 etc
Debemos considerar que para una aplicacion que resuelve problemas integrados , muchas de esas caracteristicas no tienen ningun significado especial , quizas si no  las tuviera simplemente no estaria en concurso.
➤ Las caracteristicas sumamnete apropiadas o diferenciadas en alguna aplicacion las llamamos VENTAJAS
➤Cuando la disposicion de un soft permite que la empresa haga algo que antes no podia , o que lo hace a menos cosoto , o mejor ... eso implica un BENEFICIO

✱✱✱ Lo IMPORTANTE es que algunas de esas caracteristicas signifiquen una VENTAJA para la empresa
✱✱✱ El trabajo del consultor es la intervencion para localizar caracteristias ventajosas que  se conviertan en un BENEFICIO

Donde invertir en test y correccion antes de liberar un programa?

La severidad de los defectos tienden a seguir la regla 80/20. Con el %80 de los defectos no criticos  y un %20  criticos.
Adicionalmente , generalmente solo el %20 de las caracteristica de un programa , son  criticas  en el sentido que:un error en esas  caracteristicas haga inservible al programa.
La probabilidad de que un bug critico ocurra en un area funcional critica  es apenas del %4 (%20 de %20). O sea , las chances de que un bug sea de menor importancia es del %96
Podemos interpretar que para que esos % sean factibles se debe incurrir en una desproporcionada cantidad de testeo y correcccion a las areas funcionales criticas
James Walsh . "detrmining software quality" .Computer languaje , abril 1993

-Un programa terminado contiene todos los defectos posiblesY los que no sean los que pusimos nosotros , es probable que se generen por el ambiente pero ...Que se manifiesten como fallas ...mmmm. sigue siendo una cuestión de probabilidades.-

Hace mas de 20 años cuando llego la ola de los formalismos , se hizo notable un tema: la fiabilidad del software . con mucho fundamento estadístico se proclamaba aspectos ingenierles en esta profesión. Me pareció fantástico que al fin los términos modelo , distribución , esperanza , muestra ... etc etc etc iban a ser parte del normal arsenal de conceptos del programador
Tema no apto para los programadores iluminados , menos para los que provenian de áreas no formales o sin nivel matemático.
Fue una oprotuna inspiracion , hoy en los centros de desarrollo de la ingenieria continua el debate

"El tamaño, la complejidad y la dependencia humana de los productos basados en software han crecido dramáticamente durante las últimas décadas. Los desarrolladores de software están luchando para entregar software confiable con un nivel aceptable de calidad, dentro del presupuesto y el cronograma dados.
Una medida de la calidad y confiabilidad del software es la cantidad de fallas residuales . Por lo tanto, los investigadores se están centrando en la identificación del número de
fallas presentes en el software o la identificación de los módulos del programa que son más
 probable que contenga fallas.
 Se han desarrollado muchos modelos usando varias técnicas. Se sigue un enfoque común para la predicción de fiabilidad del software utilizando datos de falla.
 La confiabilidad del software y la predicción de la calidad es altamente deseada por los promotores , desarrolladores, gerentes y usuarios finales. Detectando software las fallas al principio del desarrollo definitivamente mejorarán la confiabilidad y calidad de manera rentable."  A. K. Pandey and N. K. Goyal, Early Software Reliability Prediction, Studies in Fuzziness and Soft Computing" ...
...
"Los modelos de confiabilidad del software generalmente se refieren a estimar el número de
errores en un software parcialmente depurado. Las pruebas realizadas en el software resultan
 como : aceptado, condicionalmente aceptado o rechazado. La aceptación puede ser
basado en la cantidad de errores encontrados durante un período de tiempo seleccionado, en el número de caminos ejecutados del número total de caminos disponibles para ser ejecutados, o algun  otro criterio preestablecido. Una variedad de modelos de confiabilidad ahora compiten por
la atención del analista
Los modelos de confiabilidad de software se pueden categorizar ampliamente
como lo sugirió Pham (2006):
• Determinístico: utilizado para estudiar la cantidad de operadores y operandos distintos
así como las instrucciones de la máquina en el programa. Los dos  más comunes  son:
- La métrica de software de Halstead, basada en el no exclusivo. de operadores y operandos.
- Métrica de complejidad ciclomática de McCabe, basada en el número ciclomático V (G).
• Probabilistico: describe la ocurrencia de falla y / o el fenómeno de eliminación de fallas
del proceso de prueba como eventos probabilísticos con respecto al tiempo y / o prueba
esfuerzo. Algunos modelos probabilísticos comunes incluyen los siguientes (Pham 2006):
- Modelo de tasa de fallas (tiempos entre modelos de falla).
- Modelo de falla o conteo de fallas (modelos NHPP).
- Error o modelo de siembra de fallas.
- Modelo de crecimiento de confiabilidad, etc."
 Ajeet Kumar Pandey 2013
Aunque ninguna técnica puede determinar el número de errores restantes con precisión absoluta, la medición sistemática de la tasa a la que se están descubriendo nuevos errores proporciona una pista valiosa sobre la calidad del software. El principio básico de esta técnica es intuitivamente atractivo:
Cuanto mas defefctos hay en un programa , mas fácil es descubrirlos.

el numero de nuevos bugs por unida de tiempo de testeo , tiende a disminuir con el tiempo en la medida que los defectos de un programa son descubertos y solucionados.
Midiendo la tasa de decaimiento en el descubrimiento de defectos a travez del tiempo en un proyecto,el numero de bugs no detectados que quedan en un programa, puede ser inferidos con un alto grado de confianza
James Walsh Determining software quality .Computer languaje abril 1993