Mi artículo...La infoxicación, ¿existe o no en las grandes multinacionales?

Resumen

El mundo actual posee una gran cantidad de información al alcance de cualquiera con una conexión a internet. Para muchas personas esta cantidad de información es casi una plaga y hasta un vicio, pero para otros tantos, esa cantidad es solo una gran ayuda para su diario vivir.

He decidido realizar una investigación de este fenómeno dentro de una compañía multinacional para validar
si sufren de infoxicación, o por el contrario es una bendición tener toda la información al alcance de la mano, para este tipo de empresas.

Como comentaba en la primera entrega de este blog, la infoxicación es la sobrecarga de información, es decir, tener más información de la que humanamente es posible.

Realicé un estudio en la empresa donde laboro pero si quieren ver los resultados, saldrán pronto en la revista TIA de la Universidad Distrital Francisco José de Caldas.

Un abrazo a todos :)

PD: dejo el link a la revista
Revista TIA - Tecnología, Investigación y Academia

Profesionalmente

Para esta entrada voy a hablar sobre la Empresa en la que actualmente trabajo..

Es una empresa multinacional que brinda servicios tecnológicos usando switches transaccionales.

Esto indica que nuestros principales clientes son los Bancos y Redes.

Los productos que más se trabajan y sobre los cuales se venden más servicios son los switches transaccionales. Un Switch transaccional es una plataforma que gestiona, precisamente, transacciones financieras de diferentes Adquirientes en busca de autorización.

Un Adquiriente puede ser un Banco, un Datafono o Red. La búsqueda de autorización se basa en diferentes esquemas que prácticamente buscan resolver la transacción en el Switch o en un Autorizador Externo.

 Algo como el siguiente ejemplo:

1.       Una compra en una tienda con Datáfono, un retiro de dinero en un Cajero Automático o una consignación en un Banco, es realizada por un cliente.

2.       La información de la transacción es enviada al Switch transaccional el cual valida la transacción para evitar fraudes de ser posible. Si no tiene las configuraciones requeridas para aprobar la transacción, el switch envía la transacción a la entidad correspondiente o a otro servidor que actúa como Autorizador ya que posee la información para aprobar la transacción.

3.       El sistema autorizador aprueba o declina la transacción (ej: si no tiene fondos suficientes) y resuelve la transacción.

El nivel de exigencia es alto, pero así mismo la experiencia que se adquiere al realizar este tipo de trabajos.

Por esta entrada no es más : )

Chaus!  <3

Mi hobbie...el canto

Hello!!!

Hoy quiero hablarles sobre mi pasión, la música. Desde los 8 años canto, amo la música y para mi no hay nada mejor que estar en un escenario.

Creo firmemente que la música es el idioma universal. Lo que una pieza te hace sentir aquí, también lo hace a alguien en París o en Japón, sin importar el lenguaje.

Yo comencé a vivir esto desde muy chica. Aprendí a leer partituras tan fácilmente como si se tratara de otro idioma para mi.

La música es mi escape del estrés y la rutina, aunque no es para nada parecido a lo que todos piensan, que es  sencillo. Hay que ensayar, de forme unnitaria y con tu grupo, en mi caso el coro donde canto, y hacer que todo esté perfecto. Pero lo más hermoso de la música es que es un arte, y como arte podemos transmitir sentimientos y emociones.

Técnicas de recolección de requerimientos

Hola a todos...

Las técnicas de requerimientos son utilizadas por todos para obtener las necesidades de sus clientes, pero, ¿cuáles son esas técnicas? ¿cuál es la mejor a utilizar?

Como el tiempo es tan corto, presentaré sólo unas pocas técnicas, pero vale aclarar que cada técnica depende de quién la utilice y lo mejor no es sólo casarse con una técnica sino hacer un mix de varias, hacia sus necesidades.

Entrevistas

Las entrevistas con los skateholders del sistema son parte de la mayoría de procesos en ingeniería. En estas entrevistas, el equipo de ingeniería de requerimientos hace preguntas sobre el sistema que utilizan y el sistema a desarrollas. Los requerimientos provienen de las respuestas a dichas preguntas.

Ing. Software, Sommerville

Escenario

Un escenario es una descripción parcial y concreta del comportamiento de un sistema en una determinada situación. Es una descripción parcial, porque no necesita describir todas las características de las entidades involucradas, sólo se describe aquello que está relacionado con un comportamiento particular del sistema analizado.

A pesar de estar acotados a un determinado comportamiento, describen todo el contexto que involucra a esa actividad: recursos del sistema, objetivos de los usuarios, contexto social en que se desarrolla, entidades involucradas. Proveen un “retrato” de como esa actividad se lleva a cabo.

Prototipos

Es una pequeña muestra de funcionalidad limitada, de como seria el producto final, una vez terminada.

Lluvia de ideas

Lluvia de ideas o tormenta de ideas (Brainstorming) es una técnica de grupo para generar ideas originales en un ambiente relajado. Esta herramienta creada en el año 1941 por Alex Osborne cuando su búsqueda de ideas creativas resulto en un proceso interactivo de grupo no estructurado de “Lluvia de ideas” que generaba más y mejores ideas que las que los individuos podían producir trabajando de forma independiente.

Los Requerimientos!

Hello  to all my followers!!

Today, I'm going to be writing in English..... lol

Bueno ya... Era broma.....

Hoy hablaremos sobre los "Requerimientos".

Los requerimientos son las cosas que los clientes necesitan, pero (frecuentemente) confunden con las que quieren.... Voy a detallar un poco más esta frase...

"Un requerimiento es una condición o capacidad NECESARIA por un usuario para solucionar un problema o lograr un objetivo".

- EEE Standard Glossary of Swoftware Engeneering Terminology (1990)

Bueno, como les decía, los requerimientos no deben ser confundidos con lo que el cliente QUIERE, por esto se han desarrollado planes para obtenerlos y uno de los básicos es el típico ... "Divide y Conquer"... No, no es un juego... o bueno, si lo es, pero ... Ahhh... Ustedes me entienden.. Es una estrategia...

La idea es dividir los requerimientos en Niveles, los cuales son:
- Negocio: Estos son los requerimientos de alto nivel, es algo así como los requerimientos que se deben cumplir en el proyecto general (Ej: Misión, visión).

- Usuario: Estos definen los requerimientos que los usuarios deben poder realizar dentro de la solución, Generalmente los definen los Casos de uso.

- Funcionales: Estos son un poco más complicados o muy técnicos por decirlo así, estos definen el como se debe realizar la solución para poder cumplir los requerimientos de usuario. generalmente es como se debe hacer lo que se tiene que permitir hacer.

- No Funcionales: Estos aun que hacen parte de los funcionales, es mejor dividirlos una vez más.. esto, ya que son requerimientos asociados a la eficiencia de la solución, Unos ejemplos de estos son; Portabilidad, Usabilidad, Seguridad y Rendimiento.



Ahora para finalizar la entrada (Que está un poco larga)......
Hablaré de la Egislación o Levantamiento de requerimientos para los demás mortales...

Este es un proceso por el cual se obtienen los requerimientos de un proyecto, los pasos son:
Iniciación -> Obtención -> Elaboración -> Negociación -> Especificación -> Validación -> Administración

Espero hayan aprendido un poco,

Hasta la próxima entrada!
Chaus!! <3

Las 4 P's

Hola a Todos los Seguidores <3

Esta semana hablaremos de las cuatro P's -----

No, no son Pizza, Pollo Pavo y Puerco......lo que se imaginan, recuerden que esto es un Blogg de informática ;)

Las "4P" es una Metodología que se utiliza en la Gestión de Proyectos para reducir el análisis a cuatro puntos clave----

Los puntos a revisar en esta Metodología son:

1. Personal: Este punto radica en la Fuerza Humana del Proyecto, busca definir Aspectos del proyecto relacionados con los involucrados... Define Entrenamiento, Retribución, Metodología de Reclutamiento, Niveles Organizacionales y Tipos de Gestión-

2. Proceso: Este punto tiene como objetivo generar el mejor flujo de procesamiento para el proyecto, busca que el proceso a utilizar sea Claro, Medible y Visible, define Entradas, Salidas y controles dentro del proceso a utilizar.

3. Producto: Este punto tiene como objetivo buscar o definir los entregables y la mejor presentación de los mismos dentro del proyecto, los productos pueden ser Diagramas de Flujo, de Procesos, Organigramas y demás, dejando de lado Los Productos Finales----

4. Proyecto:  Este punto busca definir las fases o el conjunto de actividades que se desarrollaran en el Proyecto y su Gestión (Personal, Tiempo y Dinero), haciendo así una Amalgama de las anteriores P-

Corto pero conciso me despido!!!

Chaus hasta la proxima!!

Gestión de Proyectos

Hola a mis seguidores!! <3

Esta semana vamos a hablar sobre "Estándares de Gestión de Proyectos"---
Entre los mas conocidos tenemos: PMI, Prince, RUP, XP, CMMI, P2M, pero por el tiempo que tengo voy a describir dos de los anteriores y elegir un favorito.

El primero será PMI PMBOK y el segundo PRINCE-

* PMI no es un estándar (como algunos pueden pensar....), PMI es solo la organización internacional fundada en 1969, que posee como objetivo Generar los estándares de gestión de proyectos y uno de ellos es el PMBOK que fue creado por los rededores de 1990-





* PRINCE, es el acronimo que acorta el nombre en inglés "PRojects IN Controlled Environments", PRINCE otorga a quienes lo usan una metodología de gestión organización completa y no solo de gestión de proyectos y podemos decir que sus inicios datan cerca de 1989-




La diferencia radica en que PMBOK se enfoca (o profesa) sus Áreas del conocimiento y comparte las mejores prácticas para obtener los mejores resultados en cada una de ellas (las áreas son: Integración, Alcance, Tiempo, Costo, Calidad, Recurso Humano, Comunicaciones, Riesgos, Adquisiciones e Interesados)-

Y por el otro lado PRINCE se enfoca en presentar recomendaciones sobre los procesos que crean un proyecto satisfactorio: Quien debe hacerlo?, Cuando debe hacerse?-

Muy similar??? puede que si porque finalmente ambos esperan presentar las "mejores practicas" para obtener un buen desenvolvimiento del proyecto.... PERO no es del todo igual.... PRINCE busca ver el proyecto de manera más General o Globalizada, buscando lo mejor para el proyecto en su totalidad, mientras que PMBOK busca realizar lo mejor del proyecto FASE por FASE-

En mi opinión PRINCE dedica más sus esfuerzos en generar un mejor proceso del proyecto, por lo que es mi favorito-- Por algo lo usan en Europa <3
Chaus y hasta la próxima entrada!!