martes, 23 de febrero de 2010
lunes, 22 de febrero de 2010
lunes, 15 de febrero de 2010
Ejemplo de ERS
EJEMPLO ESPECIFICACION DE REQUISITOS
DESCRIPCIÓN GLOBAL
2.1 Perspectiva del producto
El sistema de administración de un punto de venta de KIOSKO
interactuará con al menos dos equipos de cómputo, mediante una base de datos.
La interacción con los usuarios será a través de menús.
2.2 Funciones del producto
El sistema tendrá funciones tales como altas-bajas, compras, ventas e
inventarios.
Altas-bajas: estará relacionado con los registros de productos
existentes, así como con los datos individuales de cada producto
(nombre, precio, etc.).
Compras: tendrá relación con la cantidad de productos en
existencias, es decir solo se encargará de interactuar con el aumento en la
cantidad de productos.
Ventas: es la contraparte de compras, es decir ésta función solo
reducirá las existencias de productos.
Inventarios: se relacionará con todos los datos, para hacer
informes acerca del control de productos en el KIOSKO (existencias,
faltantes, pérdidas).
2.3 Características del usuario
Es deseable que los usuarios del sistema tengan conocimientos básicos en
computación, que esté familiarizado con los procesos que se llevan a cabo en
una tienda.
2.4 Restricciones
Las características del hardware en los equipos donde se instalará el
sistema, serán siempre las mismas.
El sistema deberá de ser capaz de funcionar paralelamente con otras
aplicaciones, siempre y cuando el hardware lo permita.
Los distintos módulos deberán tener un diseño e implementación
sencillos, independientes de la plataforma o el lenguaje de programación.
2.5 Atención y dependencias
Se asume que los requisitos descritos en este documento son estables una
vez que sea aprobado
Se asume que el sistema operativo Microsoft Windows XP estará
disponible en los equipos donde se instalará el sistema.
REQUISITOS ESPECÍFICOS
3.1 Requisitos funcionales
3.1.1 REQ01 Registro de descripción:
El usuario podrá registrar productos y guardarlos mediante el sistema
en cuestión, los campos de estos registros deberán ser, como mínimo, la clave
del producto, su descripción, precio, cantidad en existencia, etc.
3.1.2 REQ02 Visibilidad de las descripciones:
El usuario podrá ver las descripciones con las que dispone
determinado producto para poder realizar la operación correspondiente de
acuerdo a ello.
3.1.3 REQ03 Selección de descripciones:
Se podrá especificar la descripción de los productos almacenados en la
base de datos mediante consultas.
3.1.4 REQ04 Independencia entre servidores:
El servidor será totalmente independiente, para que el usuario pueda
dar un buen servicio.
3.1.5 REQ05 Unidad de las descripciones:
En cada servidor, las descripciones serán únicas.
3.2 Requisitos de interfaces externas
3.2.1 REQ06 Interfaces del usuario:
Se podrá comunicar con el usuario para aprovechar los requisitos del
sistema, el usuario indicará al sistema las operaciones que debe realizar e
introducirá los datos que el sistema le pida.
3.2.2 REQ07 Interfaces del software:
La comunicación entre los módulos del sistema se realizará mediante
bases de datos relacionadas.
3.3 Requisitos de rendimiento
3.3.1 REQ08 Tiempo de repuesta:
La respuesta que dará el sistema con respecto a la petición del usuario
deberá ser en tiempo real.
3.4 Requisitos de desarrollo
3.4.1 REQ09 Ciclo de vida:
El ciclo de vida elegido para desarrollar el sistema será el de cascada
(waterfall) que consiste en cuatro etapas que son: análisis, diseño, codificación y
prueba, mismas que nos ayudarán a simplificar la planeación de actividades.
3.5 Atributos
3.5.1 REQ10 Portabilidad:
El sistema debe ser portable, para que se pueda instalar en diferentes equipos
de la misma empresa con facilidad.
3.5.2 REQ11 Mantenibilidad:
El sistema deberá ser diseñado para que su mantenimiento sea fácil, y de esta
manera pueda ser ampliado y corregido en caso de ser necesario.
APÉNDICE
Entrevista
Esta entrevista la realizamos en uno de los establecimientos de Kiosko ubicado
sobre la avenida Insurgentes alrededor de las 12 del mediodía del 29 de Octubre. El
entrevistador fue nuestro compañero Eric Fernando Mesina Covarrubias.
Mesina: ah, Buenas Tardes, ehhh, vengo de la Facultad de Telemática a aplicar
una encuesta para ver si...pa...eh para hacer una preguntas.
Kiosko: Ah si, está bien.
Mesina: Ehh, la primera pregunta sería, ¿En la actualidad cómo se lleva a cabo
el control de los productos?
Kiosko: Ah mira pues con un programa que se llama microchip.
Mesina: ah, ¿qué actividades operacionales se realizan con los productos?
Kiosko: pues mira, las compras, las ventas y también los inventarios.
Mesina: ¿los productos están clasificados de alguna manera para facilitar su
identificación?
Kiosko: ah mira pues en la tienda si están separados, con el sistema pues no sé,
andamos pasando el código (de barras) para encontrarlos.
Mesina: ¿Cuáles son los datos que podemos obtener de un producto?
Kiosko: mmmmmmm, ¿cómo?
Mesina: no sé, como claves, nombres, así.
Kiosko: ah si mira pues con código de barras, nombres, precios y cuánto estoy
vendiendo.
Mesina: ¿cómo se realizan la adquisición/ compra de productos?
Kiosko: ¿como adquisiciones?
Mesina: si como.... por ejemplo, que le compran a algún proveedor o...
Kiosko: ah mira pues casi todo es directamente con los proveedores pero todo
de lo de abarrotes lo trae el supervisor.
Mesina: si la compra se realizó sólo a proveedores previamente autorizados, ¿es
necesario guardar sus datos?
Kiosko: si, sería el numero de la nota del proveedor para que pase a cobrar a la
coca.
Mesina: ¿Expiden facturas?
Kiosko: mmmm, si
Mesina: Eeen qué casos?
Kiosko: pues cuando el cliente quiere y pues nada mas se les pide el RFC.
Mesina: ¿cómo se realiza la expedición de ticket?
Kiosko: Pues como todos los productos, se pasan por la computadora al final
nomas se imprime mm..
Mesina: ¿qué datos se necesitan para ello?
Kiosko: pueees cuanto vale el producto, la dirección del establecimiento, el
importe, la fecha, el cambio y el efectivo con el que se quiere pagar.
Mesina: Ta bien, ¿para alguna de las operaciones es necesario conocer los datos
del cliente?
Kiosko: eeehm no, pues nada mas, esteee, con las facturas.
Mesina: ah ok, ¿cuántas personas acceden al sistema?
Kiosko: mira pues yo, y los encargados y también los supervisores, los
supervisores perdón.
Mesina: ¿estas personas tienen los mismos privilegios para ver la información
del sistema?
Kiosko: no, nosotros como encargados no podemos registrar, este, los nuevos
productos ni borrarlos, y los supervisores si.
Mesina: ¿de qué manera se restringe la información a personas ajenas o no
autorizadas.?
Kiosko: mira pues si entras como encargado, no mas este, puedes ver lo de
ventas, compras e inventarios, y me imagino que los supervisores tienen laaaa opción
para registrar productos.
Mesina: ¿requieren de contraseña para dar inicio al sistema?
Kiosko: si, y también, este, usuario.
Mesina: ok, es necesario conocer los datos de las personas que usan el sistema
dentro de el?
Kiosko: ay no!, porque todos, este, entramos cooon el mismo usuario y
contraseña.
Mesina: ehhh, ¿requiere que el sistema pueda ser implementado en equipos con
características diferentes?
Kiosko: mmm, pues si, todos son iguales.
Mesina: yyy laaa, a ver, requiere que además del funcionamiento normal el
sistema tenga algún apartado para pruebas o para dar capacitación a... a nuevos
usuarios?
Kiosko: pues no lo tiene pero estaría bien que lo tuviera pues para...
capacitación sobre todo
Mesina: ah ok, bueno pues muchas gracias
Kiosko: ah gracias a ustedes, que les vaya bien
Mesina: gracias.
Especificacion de Requisitos de Software
La ERS es un contrato entre la empresa desarrolladora y la empresa cliente. Ambas partes deben comunicarse muy estrechamente para establecer los requisitos de la aplicación. Una buena ERS ayudará a la empresa cliente a describir qué es lo que quiere, y también servirá a los desarrolladores para comprender qué es, exactamente, lo que le están pidiendo. De la ERS depende el resultado final del producto software. Por tanto, es muy importante que en ella se describa lo más detalladamente posible "todo" lo que se espera que haga dicho software. Hay que saberlo todo, incluso se tiene que saber por qué no se sabe lo que no se sabe. Para ello, el desarrollador debe preguntarle al cliente preguntas tales como:
- ¿Qué debe hacer el programa? Esta es la pregunta más importante, de ella surgirán todas las demás. El cliente debe explicar al desarrollador para qué necesita un software, qué tareas quiere que desempeñe, en qué ámbito, etc.
- ¿Qué datos de entrada y de salida intervienen en el proceso? Todos los programas manipulan datos. Por tanto, esta es la segunda pregunta más importante, de la cual también se derivan otras como: ¿hay que validar o filtrar los datos de entrada?, ¿de cuánta información se trata?, ¿siempre es la misma?, ¿se deben almacenar los datos de salida en algún soporte informático?, etc.
- ¿En qué máquina y sistema operativo se va a ejecutar? Cuando se desarrolla una aplicación de gran tamaño, hay que prestar especial atención a los recursos necesarios para su buen funcionamiento. En relación a este aspecto, algunas otras preguntas son: ¿se va a ejecutar en una red?, ¿la velocidad del proceso es un aspecto crítico?, etc.
- ¿Quién será el usuario de la aplicación? No es lo mismo desarrollar una aplicación para ser usada por personas que poseen conocimientos avanzados de informática (por ejemplo, un administrador de red) que por otras que sólo tienen conocimientos a nivel usuario (por ejemplo, un administrativo). Este aspecto influirá, especialmente, en cómo debe ser la interfaz de la aplicación, y cuáles son los términos en que se elaborará el manual de usuario. El manual de usuario de cualquier programa suele ser un libro que acompaña al software. Dicho manual se puede ir confeccionando a lo largo de todo el ciclo de vida y en él se explica al usuario los pasos que debe seguir para instalar la aplicación, configurarla, utilizarla, etc. A veces, las aplicaciones informáticas también ofrecen una ayuda en línea, que, igualmente, forma parte de dicha documentación.
- Además, hay que saber otras cosas, tales como: ¿cuál va a ser el tratamiento de posibles errores en la ejecución del programa?, ¿cómo se va a garantizar la seguridad de los datos?, ¿cuál será la vida útil de la aplicación?, ¿podrá sufrir modificaciones en el futuro?, etc.
martes, 9 de febrero de 2010
lunes, 8 de febrero de 2010
sábado, 6 de febrero de 2010
martes, 2 de febrero de 2010
Fundamentos de Sistemas
DIFERENCIA
ENTRE DATO, INFORMACIÓN Y CONOCIMIENTO
Antes
de nada, debemos comprender en qué se diferencia el conocimiento de
los datos y de la información. En una conversación informal, los
tres términos suelen utilizarse indistintamente y esto puede llevar
a una interpretación libre del concepto de conocimiento. Quizás la
forma más sencilla de diferenciar los términos sea pensar que los
datos están localizados en el mundo y el conocimiento está
localizado en agentes de cualquier tipo, mientras que la información
adopta un papel mediador entre ambos.
Un
agente no equivale a un ser humano. Podría tratarse de un animal,
una máquina o una organización constituida por otros agentes a su
vez.
DATO,
INFORMACIÓN Y CONOCIMIENTO SEGÚN DAVENPORT Y PRUSAK (1999)
Dato:
Un
dato es un conjunto discreto, de factores objetivos sobre un hecho
real. Dentro de un contexto empresarial, el concepto de dato es
definido como un registro de transacciones. Un dato no dice nada
sobre el porqué de las cosas, y por sí mismo tiene poca o ninguna
relevancia o propósito.
Las
organizaciones actuales normalmente almacenan datos mediante el uso
de tecnologías. Desde un punto de vista cuantitativo, las empresas
evalúan la gestión de los datos en términos de coste, velocidad y
capacidad.
Todas
las organizaciones necesitan datos y algunos sectores son totalmente
dependientes de ellos. Bancos, compañías de seguros, agencias
gubernamentales y la Seguridad Social son ejemplos obvios. En este
tipo de organizaciones la buena gestión de los datos es esencial
para su funcionamiento, ya que operan con millones de transacciones
diarias. Pero en general, para la mayoría de las empresas tener
muchos datos no siempre es bueno. Las organizaciones almacenan datos
sin sentido. Realmente esta actitud no tiene sentido por dos
razones. La primera es que demasiados datos hacen más complicado
identificar aquellos que son relevantes. Segundo, y todavía más
importante, es que los datos no tienen significado en sí mismos.
Los
datos describen únicamente una parte de lo que pasa en la realidad
y no proporcionan juicios de valor o interpretaciones, y por lo
tanto no son orientativos para la acción. La toma de decisiones se
basará en datos, pero estos nunca dirán lo que hacer. Los datos no
dicen nada acerca de lo que es importante o no.
A pesar de todo, los datos son importantes para las
organizaciones, ya que son la base para la creación de información.
Información:
Como
han hecho muchos investigadores que han estudiado el concepto de
información, lo describiremos como un mensaje, normalmente bajo la
forma de un documento o algún tipo de comunicación audible o
visible. Como cualquier mensaje, tiene un emisor y un receptor. La
información es capaz de cambiar la forma en que el receptor percibe
algo, es capaz de impactar sobre sus juicios de valor y
comportamientos. Tiene que informar; son datos que marcan la
diferencia. La palabra “informar” significa originalmente “dar
forma a “ y la información es capaz de formar a la persona que la
consigue, proporcionando ciertas diferencias en su interior o
exterior. Por lo tanto, estrictamente hablando, es el receptor, y no
el emisor, el que decide si el mensaje que ha recibido es realmente
información, es decir, si realmente le informa. Un informe lleno de
tablas inconexas, puede ser considerado información por el que lo
escribe, pero a su vez puede ser juzgado como “ruido” por el que
lo recibe.
La
información se mueve entorno a las organizaciones a través de
redes formales e informales. Las redes formales tienen una
infraestructura visible y definida: cables, buzones de correo electrónico,
direcciones,... Los mensajes que estas redes proporcionan incluyen
e-mail, servicio de entrega de paquetes, y transmisiones a través
de Internet. Las redes informales son invisibles. Se hacen a medida.
Un ejemplo de este tipo de red es cuando alguien te manda una nota o
una copia de un artículo con las siglas “FYI” (For Your
Information).
A
diferencia de los datos, la información tiene significado
(relevancia y propósito). No sólo puede formar potencialmente al
que la recibe, sino que esta organizada para algún propósito. Los
datos se convierten en información cuando su creador les añade
significado. Transformamos datos en información añadiéndoles
valor en varios sentidos. Hay varios métodos:
Contextualizando:
sabemos para qué propósito se generaron los datos.
Categorizando:
conocemos las unidades de análisis de los componentes
principales de los datos.
Calculando:
los datos pueden haber sido analizados matemática o estadísticamente.
Corrigiendo:
los errores se han eliminado de los datos.
Condensando:
los datos se han podido resumir de forma más concisa.
Los
ordenadores nos pueden ayudar a añadir valor y transformar datos en
información, pero es muy difícil que nos puedan ayudar a analizar
el contexto de dicha información. Un problema muy común es
confundir la información (o el conocimiento) con la tecnología que
la soporta. Desde la televisión a Internet, es importante tener en
cuenta que el medio no es el mensaje. Lo que se intercambia es más
importante que el medio que se usa para hacerlo. Muchas veces se
comenta que tener un teléfono no garantiza mantener conversaciones
brillantes. En definitiva, que actualmente tengamos acceso a más
tecnologías de la información no implica que hayamos mejorado
nuestro nivel de información.
Conocimiento:
La
mayoría de la gente tiene la sensación intuitiva de que el
conocimiento es algo más amplio, más profundo y más rico que los
datos y la información.
Vamos
a intentar realizar una primera definición de conocimiento que nos
permita comunicar que queremos decir cuando hablamos de conocimiento
dentro de las organizaciones.
Para
Davenport y Prusak (1999) el conocimiento es una mezcla de
experiencia, valores, información y “saber hacer” que sirve
como marco para la incorporación de nuevas experiencias e información,
y es útil para la acción. Se origina y aplica en la mente de los
conocedores. En las organizaciones con frecuencia no sólo se
encuentra dentro de documentos o almacenes de datos, sino que también
esta en rutinas organizativas, procesos, prácticas, y normas.
Lo
que inmediatamente deja claro la definición es que ese conocimiento
no es simple. Es una mezcla de varios elementos; es un flujo al
mismo tiempo que tiene una estructura formalizada; es intuitivo y
difícil de captar en palabras o de entender plenamente de forma lógica.
El conocimiento existe dentro de las personas, como parte de la
complejidad humana y de nuestra impredecibilidad. Aunque solemos
pensar en activos definibles y concretos, los activos de
conocimiento son mucho más difíciles de manejar. El conocimiento
puede ser visto como un proceso (flujo) o como un stock.
El
conocimiento se deriva de la información, así como la información
se deriva de los datos. Para que la información se convierte en
conocimiento, las personas debe hacer prácticamente todo el
trabajo. Esta transformación se produce gracias a:
Comparación.
Consecuencias.
Conexiones.
Conversación.
Estas
actividades de creación de conocimiento tienen lugar dentro y entre
personas. Al igual que encontramos datos en registros, e información
en mensajes, podemos obtenemos conocimiento de individuos, grupos de
conocimiento, o incluso en rutinas organizativas.
FUNDAMENTOS DEL ANALISIS DE SISTEMAS
Ver presentacion
Un sistema es un conjunto de componentes que se unen e interactuan entre si para formar un todo en base a un mismo objetivo.
Ejemplos de Sistemas pueden ser uno de drenaje, uno de agua, etc.
Es importante que todos los componentes esten interrelacionados entre si para que todo el sistema pueda funcionar.
Un
sistema de información está relacionado con la computación y se refiere
a programas que hacemos para que las computadoras trabajen en base a un
problema en particular.
Podemos tener sistemas manuales y automatizados.
Los
manuales por supuesto, son los que las personas elaboran y los
automatizados son los que dependen de un computador para funcionar, si
son combinados entonces dependen tambien de las personas que son las
que desarrollan dicho software para que resuelva un problema.
Sistema de Información (SI):
Definición 1:
Es un grupo de gente, una serie de procedimientos o equipo de procesamiento
de datos que escoge, almacenan, procesan y recuperan datos para disminuir
la incertidumbre en la toma de decisiones mediante el suministro de información
a los niveles gerenciales para que sea utilizada eficientemente.
Definición 2:
Es el medio por el cual los datos fluyen de una persona o departamento
hacia otros y puede ser cualquier cosa, desde la comunicación
interna entre los diferentes componentes de la organización y líneas
telefónicas hasta sistemas de cómputo que generan reportes
periódicos para varios usuarios.
Definición 3:
Los sistemas de información es el medio por el cual se enlazan
todos los componentes de un sistema para alcanzar el objetivo.
Características de los sistemas de información modernos:
Sistemas sencillos sirviendo a funciones y niveles múltiples dentro
de la empresa.
Acceso inmediato en línea a grandes cantidades de información.
Fuerte confiabilidad en la tecnología de telecomunicaciones.
Mayor cantidad de inteligencia y conocimientos implícita en los
sistemas.
La capacidad para combinar datos y gráficas.
ELEMENTOS DE UN SI
OBJETIVO PRINCIPAL DEL LOS SI
El Análisis de Sistemas
Es la etapa en la cual una persona experta evalua la situacion de un
negocio o empresa y elabora una propuesta para resolver el problema en
un cierto tiempo y de una manera en particular.
El análisis tiene
más que ver con la parte de inspeccionar, conocer los detalles, las
personas involucradas y la idea general del problema.
El Diseño de Sistemas
Es
el proceso de planificar, reemplazar o complementar un sistema
organizacional existente. Pero antes de hacer esta tarea es necesario
comprender en su totalidad el viejo sistema. En esta etapa se obtiene
el diseño del nuevo sistema a través de interfases, programas y bases
de datos utilizando distintas herramientas para su representacion.
Es aqui donde utilizamos diferentes técnicas para representar un problema como DFDs, flujogramas, Pseudocódigo y otros.
En
resumen podemos decir que el Análisis de Sistemas nos dice qué es lo
que el sistema debe hacer y el Diseño de Sistemas establece cómo
alcanzar ese objetivo.
lunes, 1 de febrero de 2010
Papel Analista Sistemas
PAPELES DEL ANALISTA DE SISTEMAS
El analista de sistemas audita, de forma sistemática, el funcionamiento de la empresa al examinar las funciones de captura y procesamiento de datos, así como la emisión de resultados, lo cual le permitirá mejorar los procesos a la organización. Al mejorar el soporte que proporcionan los sistemas de información computarizados, se obtienen importantes a veces en las funciones empresariales. Estas definiciones recalcan el uso de enfoques sistemáticos y metódicos para analizar y lograr mejorar las operaciones que ocurren en el contexto particular de la empresa.
Nuestra definición del analista de sistemas, tiene que ser necesariamente muy amplia. El analista requiere tener la habilidad de trata para cualquier tipo de persona, así como también, tener la debida experiencia en el manejo de computadoras. El analista protagoniza numerosos papeles, y en ocasiones, se ve obligado a mantener un equilibrio, al asumir simultáneamente mas de uno. Los tres papeles principales de un analista de sistemas debe cubrir son: el de consultor, el de especialista de apoyo o soporte y el de agente de cambio, tal como se describe en la figura 1.1.
FIGURA 1.1
EL ANALISTA DE SISTEMAS COMO CONSULTOR
Por lo regular, el analista de sistemas participa como consultor para la empresa. Esto implica que un analista pueda contratarse para canalizar a la empresa ciertos tópicos de la informática. Esto ofrece una ventaja, en el sentido de que el consultor externo trae consigo perspectivas frescas, que no poseen otros miembros de la organización. Por otra parte, para el analista externo implica una desventaja, pues apenas tiene pleno acceso a la cultura organizacional autentica, que no se ofrece de forma abierta a un externo.
Como consultor externo, deberá conocer e implantar las metodologías que se discuten a lo largo de este libro, que le serán útiles para analizar y diseñar sistemas de información adecuados para cualquier empresa en particular. Mas aun, contará con la ayuda de los usuarios de los sistemas de información, para entender la cultura de la organización desde sus propios puntos de vista
EL ANALISTA DE SISTEMAS COMO PERSONAL DE APOYO
El otro papel que puede protagonizar es el de especialista de apoyo o staff dentro de una empresa, donde de manera regular, trabaje dentro del departamento de sistemas. En esta posición, el analista dispone de una experiencia profesional respecto al hardware y al software y a sus aplicaciones en la empresa. Con frecuencia estas tareas no se asocian a un proyecto ambicioso de sistemas, sino más bien implican decisiones o modificaciones menores que se dan en un departamento individual.
Como especialista de apoyo, no dirigirá un proyecto, solo será un recurso humano de apoyo para quienes lo dirigen. Si es un analista de sistemas contratado por una organización de servicios o de manufactura, muchas de sus actividades diarias se ajustarán a este papel.
EL ANALISTA DE SISTEMAS COMO AGENTE DE CAMBIO
El papel que mejor se entiende y que le confiere una alta responsabilidad al analista de sistemas, es el de agente de cambio; sin importar si es o no externo a la organización. Como analista, será un agente de cambio cada vez que realice alguna de las actividades del ciclo de desarrollo del sistema del sistema (que se discute en la sección siguiente), las cuales se mantienen presentes en la empresa por un largo periodo (desde dos semanas hasta quizá mas de un año). Un agente de cambio puede definirse como aquella persona que sirve como catalizador para el cambio, que desarrolla un plan para el mismo y que colabora con otros para agilizarlo.
Su presencia dentro de la empresa la modifica. Como analista de sistema debe aceptar lo anterior y utilizarlo como el punto de inicio de su análisis. Esto es por lo que tendrá que relacionarse con los usuarios y con la dirección (si ellos no fueran la única y misma persona), desde el principio del proyecto. Sin su colaboración, será incapaz de entender lo que pasa en la organización, y el cambio real no se llevará a cabo.
Si el cambio (esto es, los beneficios que la empresa obtiene mediante los sistemas de información)parece quedar garantizado después del análisis, el siguiente paso será desarrollar un plan para tal cambio, en colaboración con las personas que se involucrarán en tales cambios. Una vez que se alcance un consenso para el cambio a realizar, se encontrará en constante relación con aquellos que estén participando del cambio. Facilita el cambio al usar su experiencia en el trato humano y en la computación, para llegar a una integración hombre-maquina en el sistema de información.
Como analista de sistemas, al actuar como agente de cambio, apoya una corriente particular de cambio, que involucra el uso de los sistemas de información. Además, transmite a los usuarios el proceso de cambio ya que esta convencido de que tales cambios no ocurren de manera independiente en los sistemas de información, sino mas bien, estos ocasionan cambios a lo largo de las organizaciones.
CUALIDADES DEL ANALISTA DE SISTEMAS
De las descripciones precedentes sobre los diferentes papeles que el analista de sistemas tiene que protagonizar, es fácil ver, que el analista de sistemas, con éxito, debe contar con una amplia gama de cualidades. Los analistas de sistemas, son gente de naturaleza muy diversa y seguramente esto, restringe cualquier intento de caracterización; sin embargo hay ciertas características que parecen presentar la mayoría de los analistas de sistemas.
Ante todo, el analista es un solucionador de problemas. El o ella es una persona que ve el análisis de los problemas como un reto y que disfruta encontrando soluciones factibles. Cuando es necesario, el analista tiene que ser capaz de abordar de manera sistemática la situación, mediante la aplicación hábil de herramientas, técnicas y experiencia. El analista también debe ser un buen interlocutor, manteniendo una relación cordial con otra gente, durante largos periodos. El analista de sistemas necesita contar con suficiente experiencia en computación para programar, entender las capacidades de las computadoras, recoger las necesidades de información de los usuarios y llegar a transmitir a los programadores lo necesario.
El analista de sistemas debe ser autodiciplinado y automotivado como individuo. También el analista debe ser capaz de administrar y coordinar innumerables recursos del proyecto, incluyendo a otras personas. El análisis de sistemas exige demasiado, pero se compensa con la naturaleza cambiante de los problemas, así como por el continuo enfrentamiento al reto.
Suscribirse a:
Entradas (Atom)
