Analista de sistemas

Un analista de sistemas o a veces simplemente analista, en la disciplina de la ingeniera del software, es aquel individuo responsable de investigar, planear, coordinar y recomendar opciones de software y sistemas para cumplir los requerimientos de una empresa de negocios. El analista de sistemas juega un rol vital en el proceso de desarrollo de los sistemas. Un analista de sistemas exitoso debe adquirir cuatro habilidades: analtica, tcnica, gerencial, e interpersonal. Las habilidades analticas permiten al analista de sistemas entender a la organizacin y sus funciones, las cuales le ayudan a identificar oportunidades, analizar y resolver problemas. Las habilidades tcnicas ayudan al analista de sistemas a entender el potencial y las limitaciones de las tecnologas de la informacin. El analista de sistemas debe ser capaz de trabajar con varios lenguajes de programacin, sistemas operativos, y plataformas hardware de computadoras. Las habilidades gerenciales ayudan al analista de sistemas a administrar proyectos, recursos, riesgos, y cambio. Las habilidades interpersonales ayudan al analista de sistemas a trabajar con los usuarios finales as como con analistas, programadores, y otros profesionales de los sistemas. Tambin es una categora profesional de rango superior a la de programador y a la de diseador, generalmente ejercida por titulados superiores en Ingeniera Informtica.

Orgenes
En sus inicios, la industria del software adopt un enfoque organizativo tayloriano, al igual que la mayora de las industrias del momento. Este enfoque propugna la especializacin de funciones como mtodo organizativo. Bajo tal enfoque, el proceso de construccin de software se concibe como un conjunto de tareas altamente especializadas donde est claramente definido el papel de cada categora profesional:

El analista tiene como cometido analizar un problema y describirlo con el propsito de ser solucionado

mediante un sistema informtico.

El diseador realiza, en base al anlisis, el diseo de la solucin El programador cuya funcin consiste en trasladar las especificaciones del diseador en cdigo ejecutable por

la computadora.

El analista tiene que delimitar el anlisis para ver lo que se quiere hacer inicialmente y despus darle al

usuario nuevas opciones de uso.

Evolucin de la profesin
Hoy da, estas funciones han quedado claramente obsoletas a pesar de que la categora profesional sigue existiendo como tal. Los avances de la ingeniera del software en su corta vida han puesto de manifiesto que estas funciones no son suficientes para lograr un mnimo xito en el desarrollo de software. Las funciones ms relevantes que faltan son:

Direccin (de proyectos), para dirigir los recursos hacia el resultado deseado. Educcin de requisitos, para determinar el comportamiento que se espera del software. Garanta de calidad, para garantizar las expectativas del cliente. Diseo, para que exista una mnima certeza de que el software es viable y eficaz con la tecnologa existente.

Gestin de configuracin, para controlar el caos a medida que el software crece.

Estas funciones han sido adoptadas en muchos casos por analistas, pero no son materia especfica de esta profesin. En algunas organizaciones (y en algunos pases) la profesin ya no existe, siendo sustituida por otras figuras tales como el ingeniero de software, el jefe de proyecto, el modelador de software, o el analista-programador. Esta ltima figura es muy popular ya que resuelve los tpicos problemas de comunicacin que existan entre analistas y programadores. Estos problemas se deben a la extrema idealizacin de la especializacin de funciones. Es deseable tambin que el analista de sistemas tenga conocimientos -al menos bsicos- de usabilidad. Ya que cualquier sistema que no est al servicio de los usuarios o diseado pensado en el usuario, no tiene mucho sentido.

Perfil tradicional del analista

El perfil tradicional del analista es analizar. Las cualidades que se esperan de un analista son esencialmente la capacidad de abstraccin y de anlisis. Los conocimientos que requiere son aquellos relacionados con las tcnicas de anlisis de sistemas de informacin:

Conocimiento del paradigma tradicional de la ingeniera del software y del tradicional ciclo de vida del

software en cascada.

Modelado funcional: Diagrama de flujo de datos, diagrama de estado, etc. Modelado de datos y sus tcnicas: Diagrama entidad-relacin, modelo relacional, etc. Conocimiento de la tecnologa: arquitectura de software, bases de datos, etc.

Todas estas son materias propias de la titulacin denominada Ingeniera Informtica.

FUENTE: http://es.wikipedia.org/wiki/Analista_de_sistemas

Ingeniera informtica
La ingeniera informtica es la profesin que consiste en la aplicacin de los fundamentos de la ciencia de la computacin, la electrnica y la ingeniera de software, para el desarrollo de soluciones integrales de cmputo y comunicaciones, capaces de procesar informacin de manera automtica. Por lo que se refiere al soporte fsico, la ingeniera informtica se fundamenta en la tecnologa electrnica, lo que le permite a los ordenadores interactuar con sistemas fsicos, as como desarrollar interfaces de comunicacin y control entre el ordenador y diversos dispositivos mecnicos y elctricos, tales como sistemas de adquisicin de datos, instrumentacin virtual, control de robots, sistemas de iluminacin, etc En el aspecto lgico y formal, la ingeniera informtica se fundamenta en la teora de autmatas, los lenguajes formales, la teora de la informacin, el diseo de algoritmos, el reconocimiento de patrones, la inteligencia artificial y la ingeniera del conocimiento. En el aspecto de integracin, la ingeniera informtica comprende multitud de tcnicas y conocimientos especficos para el diseo, construccin y mantenimiento de software, sujetos a restricciones de calidad, tiempo y coste. El conjunto de estas tcnicas se conoce como ingeniera del software.

Adems de los aspectos puramente tcnicos de los sistemas informticos, la ingeniera informtica se ocupa los aspectos de tipo organizativo, social y legal. Por ejemplo, los relacionados con la planificacin, direccin y control de proyectos informticos; la auditora y control; la realizacin de peritajes informticos, etc. En la actualidad se imparten en Espaa las siguientes titulaciones:

Ingeniera Informtica (5 aos) Ingeniera Tcnica en Informtica de Gestin - I.T.I.G. (3 aos) Ingeniera Tcnica en Informtica de Sistemas - I.T.I.S. (3 aos)

Para considerar cualquiera de estas carreras como terminadas, al igual que en otras ingenieras se exige la entrega de un trabajo final: Proyecto de Fin de Carrera (PFC) en el que el alumno demuestre las capacidades aprendidas durante los aos de enseanza recibidos. Anteriormente la ingeniera informtica era una licenciatura (licenciatura en informtica) que tena una duracin de 6 aos. Hasta el momento de la creacin de dichos estudios no exista el ttulo como tal, siendo una rama de la fsica o las matemticas. Sin embargo, algunas universidades siguen adoptando este concepto de licenciatura.

Ingeniera de software
Ingeniera de software es la disciplina o rea de la informtica que ofrece mtodos y tcnicas para desarrollar y mantener software de calidad. Esta ingeniera trata con reas muy diversas de la informtica y de las ciencias de la computacin, tales como construccin de compiladores, sistemas operativos, o desarrollos Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de sistemas de informacin y aplicables a infinidad de reas (negocios, investigacin cientfica, medicina, produccin, logstica, banca, control de trfico, meteorologa, derecho, Internet, Intranet, etc. Una definicin precisa an no ha sido contemplada en los diccionarios, sin embargo se pueden citar las enunciadas por algunos de los ms prestigiosos autores:

Ingeniera de Software es el estudio de los principios y metodologas para el desarrollo y mantenimiento de

sistemas software (Zelkovitz, 1978)

Ingeniera de software es la aplicacin prctica del conocimiento cientfico al diseo y construccin de

programas de computadora y a la documentacin asociada requerida para desarrollar, operar y mantenerlos. Se conoce tambin como Desarrollo de Software o Produccin de Software ( Bohem, 1976).

Ingeniera de Software trata del establecimiento de los principios y mtodos de la ingeniera a fin de obtener

software de modo rentable, que sea fiable y trabaje en mquinas reales (Bauer, 1972).

Es la aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin y

mantenimiento del software; es decir, la aplicacin de la ingeniera al software (IEEE, 1993).

En el 2004, en los Estados Unidos, la Oficina de Estadsticas del Trabajo (U. S. Bureau of Labor Statistics) cont 760.840 ingenieros de software de computadora.1 El trmino "ingeniero de software", sin embargo, se utiliza en forma

genrica en el ambiente empresarial, y no todos los ingenieros de software poseen realmente ttulos de Ingeniera de universidades reconocidas. Algunos autores consideran que Desarrollo de Software es un trmino ms apropiado que Ingeniera de Software (IS) para el proceso de crear software. Personas como Pete McBreen(autor de "Software Craftmanship") cree que el trmino IS implica niveles de rigor y prueba de procesos que no son apropiados para todo tipo de desarrollo de software. Indistintamente se utilizan los trminos Ingeniera de Software o Ingeniera del Software. En hispanoamrica el trmino usado normalmente es el primero de ellos.

Metodologa
Un objetivo de dcadas ha sido el encontrar procesos y metodologas, que sean sistemticas, predecibles y repetibles, a fin de mejorar la productividad en el desarrollo y la calidad del producto software.

Etapas del proceso

La ingeniera de software requiere llevar a cabo numerosas tareas, dentro de etapas como las siguientes:

Anlisis de requisitos
Extraer los requisitos de un producto de software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y experiencia en la ingeniera de software para reconocer requisitos incompletos, ambiguos o contradictorios. El resultado del anlisis de requisitos con el cliente se plasma en el documento ERS, Especificacin de Requerimientos del Sistema, cuya estructura puede venir definida por varios estndares, tales como CMM-I. Asimismo, se define un diagrama de Entidad/Relacin, en el que se plasman las principales entidades que participarn en el desarrollo del software. La captura, anlisis y especificacin de requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de trabajo para estos fines. Aunque an no est formalizada, ya se habla de la Ingeniera de Requisitos.

Especificacin
La Especificacin de Requerimientos describe el comportamiento esperado en el software una vez desarrollado. Gran parte del xito de un proyecto de software radicar en la identificacin de las necesidades del negocio (definidas por la alta direccin), as como la interaccin con los usuarios funcionales para la recoleccin, clasificacin, identificacin, priorizacin y especificacin de los requerimientos del software. Entre las tcnicas utilizadas para la especificacin de requerimientos se encuentran:

Casos de Uso Historias de usuario

Siendo los primeros ms rigurosas y formales, los segundas ms giles e informales.

Arquitectura

La integracin de infraestructura, desarrollo de aplicaciones, bases de datos y herramientas gerenciales, requieren de capacidad y liderazgo para poder ser conceptualizados y proyectados a futuro, solucionando los problemas de hoy. El rol en el cual se delegan todas estas actividades es el del Arquitecto. El Arquitecto de Software es la persona que aade valor a los procesos de negocios gracias a su valioso aporte de soluciones tecnolgicas. La Arquitectura de Sistemas en general, es una actividad de planeacin, ya sea a nivel de infraestructura de red y hardware, o de Software. La Arquitectura de Software consiste en el diseo de componentes de una aplicacin (entidades del negocio), generalmente utilizando patrones de arquitectura. El diseo arquitectnico debe permitir visualizar la interaccin entre las entidades del negocio y adems poder ser validado, por ejemplo por medio de diagramas de secuencia.

Un diseo arquitectnico describe en generar el cmo se construir una aplicacin de software. Para ello se documenta utilizando diagramas, por ejemplo:

Diagramas de clases Diagramas de base de datos Diagramas de despliegue Diagramas de secuencia Diagramas de infraestructura fsica

Siendo los dos primeros los mnimos necesarios para describir la arquitectura de un proyecto que iniciar a ser codificado. Depende del alcance del proyecto, complejidad y necesidades, el arquitecto elige qu diagramas elaborar.

Entre las herramientas para disear arquitecturas de software se encuentran:

Enterprise Archit Microsoft Visio for Enterprise Architects

Programacin
Reducir un diseo a cdigo puede ser la parte ms obvia del trabajo de ingeniera de software, pero no necesariamente es la que demanda mayor trabajo y ni la ms complicada. La complejidad y la duracin de esta etapa est ntimamente relacionada al o a los lenguajes de programacin utilizados, as como al diseo previamente realizado.

Prueba
Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificacin del problema. Una tcnica de prueba es probar por separado cada mdulo del software, y luego probarlo de forma integral, para as llegar al objetivo. Se considera una buena prctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la program, idealmente un rea de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un rea de pruebas, la primera es que est compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evala que la

documentacin entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el software hace las cosas tal y como estn descritas. El segundo enfoque es tener un rea de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en qu condiciones puede fallar una aplicacin y que pueden poner atencin en detalles que personal inexperto no considerara.

Documentacin

[editar]

Todo lo concerniente a la documentacin del propio desarrollo del software y de la gestin del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de usuario, manuales tcnicos, etc; todo con el propsito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al sistema.

Mantenimiento

[editar]

Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto puede llevar ms tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda la ingeniera de software tiene que ver con dar mantenimiento. Una pequea parte de este trabajo consiste en arreglar errores, o bugs. La mayor parte consiste en extender el sistema para hacer nuevas cosas. De manera similar, alrededor de 2/3 de toda la ingeniera civil, arquitectura y trabajo de construccin es dar mantenimiento.

Modelos de desarrollo de software

La ingeniera de software tiene varios modelos o paradigmas de desarrollo en los cuales se puede apoyar para la realizacin de software, de los cuales podemos destacar a stos por ser los ms utilizados y los ms completos:

Modelo en cascada o Clsico (modelo tradicional) Modelo en espiral (modelo evolutivo) Modelo de prototipos Desarrollo por etapas Desarrollo iterativo y creciente o Iterativo e Incremental RAD (Rapid Application Development)

CICLO DE VIDA DEL DESARROLLO DEL SOFTWARE 1. 2. 3. 4. 5. 6. Anlisis Diseo Programacin Prueba Documentacin Mantenimiento

Ms Informacin: http://html.rincondelvago.com/ciclo-de-vida-del-software.html

INVESTIGACION REVISTA .CODE Un concepto importante para el anlisis de sistema, proveniente de la ingeniera de software es LA INGENIERIA DE REQUERIMIENTOS, la captura de requerimientos no funcionales y funcionales abarca el proceso de identificar y precisar las responsabilidades y las caractersticas que un sistema debe cumplir, el anlisis de requerimientos es muy importante a la hora de definir los concepto del sistema a desarrollar, un error en esta etapa se arrastrara y de forma exponencial durante y evolucin del sistema , por ello, es sumamente importante tomar los requerimientos mas exactos posibles de manera a que contribuya de manera satisfactoria y optima en la creacin, diseo y evolucin del sistema en desarrollo. MECANISMOS TRADICIONALES PARA CAPTURAR REQUERIMIENTOS Los Casos De Uso Los casos de usos representan una tcnica utilizada para capturar y modelar requerimientos. Cada caso de uso es una descripcin del comportamiento que debe exhibir el sistema ante determinadas situaciones. Se especifican actores (seres humanos u otros sistemas) que interactan con el sistema, y para una accin determinada se muestra el comportamiento esperado.

Requerimientos Funcionales Y No Funcionales

Anlisis y diseo La mayora de proyectos de software son complejos, y la estrategia primaria para superar la complejidad, es la descomposicin (divide y vencers). La estrategia es dividir el problema en unidades ms pequeas que sean manejables. Un enfoque tradicional para realizar esto fue el anlisis y diseo estructurados, donde se trata de descomponer el problema en funciones o procesos. Este mtodo origina una divisin jerrquica de procesos constituidos por sub-procesos. Por ejemplo, una descomposicin por funciones o procesos en anlisis y diseo estructurados, de un Sistema de Informacin de Biblioteca podra ser el siguiente: Otra forma de realizar la descomposicin, es usando un esquema de anlisis y diseo orientado a objetos. En este esquema, se busca descomponer el problema en objetos, y no en funciones. Por ejemplo, una descomposicin orientada a objetos del Sistema de Informacin de Biblioteca podra ser la siguiente: Algunas de las tareas a realizarse en la etapa de anlisis son las siguientes: 1. Definir los requerimientos. 2. Definir los casos esenciales de uso. 3. Crear y perfeccionar los diagramas de casos de uso. 4. Crear y perfeccionar el modelo conceptual.

5. Crear y perfeccionar el glosario. 6. Definir los diagramas de secuencia de los sistemas. 7. Definir los contratos de operaciones. Algunas de las tareas a realizarse en la etapa de diseo son las siguientes: 1. Definir los casos reales de uso. 2. Definir los reportes, la interfaz de usuario y la secuencia de las pantallas. 3. Perfeccionar la arquitectura del sistema. 4. Definir los diagramas de interaccin. 5. Definir los diagramas de diseo de clases. 6. Definir el esquema de la base de datos. Caso de estudio: el punto de venta Supongamos como caso de estudio el sistema de una terminal de punto de venta. Esta terminal es un sistema automatizado con el que se registran las ventas y se realizan los pagos. Por lo general este tipo de sistemas comprenden hardware (un computador y un lector de cdigo barras) y software (el sistema que se ejecuta en la terminal). Suponga que se nos ha contratado para crear este software. Los requerimientos Los requerimientos son una descripcin de las necesidades o deseos de un producto. La meta principal en esta etapa es identificar y documentar lo que en realidad se necesita, en una forma en que pueda fcilmente ser transmitido al cliente y al equipo de desarrollo. Se recomienda aqu definir al menos los siguientes puntos: Panorama general Metas Funciones del sistema Atributos del sistema a) Panorama general

Este proyecto tiene por objeto crear un sistema de terminal para el punto de venta que se utilizar en las ventas al menudeo. b) Metas En trminos generales, la meta es una mayor automatizacin del pago en las cajas registradoras, y dar soporte a servicios ms rpidos, ms baratos y mejores. Ms concretamente, la meta incluye: Pago rpido de los clientes. Anlisis rpido y exacto de las ventas. Control automtico del inventario. c) Funciones del sistema Las funciones del sistema son lo que ste deber de hacer. Hay que identificar estas funciones y listarlas en grupos lgicos. Para verificar que X es en verdad una funcin del sistema, la siguiente frase deber tener sentido: El sistema deber hacer X. Por ejemplo: el sistema deber autorizar pagos a crdito. Las funciones pueden clasificarse en tres categoras: evidentes, ocultas y superfluas. Las evidentes deben realizarse, y el usuario debe saber que se han realizado. Las ocultas tambin deben realizarse, y puede que no sean visibles para el usuario. Muchas de estas funciones se omiten (errneamente) durante el proceso de obtencin de requerimientos. Las superfluas son opcionales, y su inclusin no repercute significativamente en el costo ni en otras funciones. Las siguientes son algunas de las funciones ms representativas del sistema de punto de venta: Funciones bsicas: Referencia Funcin Categora R1.1 Registra la venta en proceso (actual): los productos comprados. evidente R1.2 Calcula el total de la venta actual; se incluye el impuesto. evidente R1.3 Captura la informacin sobre el objeto comprado usando su cdigo de barras y un lector, o usando una captura manual de un cdigo de producto. evidente R1.4 Reduce las cantidades del inventario cuando se realiza una venta. oculta R1.5 Se registran las ventas efectuadas. oculta R1.6 El cajero debe introducir una identificacin y una contrasea para poder utilizar el sistema. evidente

R1.7 Ofrece un mecanismo de almacenamiento persistente. oculta R1.8 Ofrece mecanismos de comunicacin entre los procesos y entre los sistemas. oculta R1.9 Muestra la descripcin y el precio del producto registrado. evidente Funciones de pago: Referencia Funcin Categora R2.1 Maneja los pagos en efectivo, capturando la cantidad ofrecida y calculando el saldo deudor. evidente R2.2 Maneja los pagos a crdito, capturando la informacin crediticia a partir de una lectora de tarjetas, o mediante captura manual, y autorizando los pagos con el servicio de autorizacin (externa) de crditos de la tienda a travs de una conexin por modem. evidente R2.3 Maneja los pagos con cheque, capturando el nmero de RUT y telfono mediante captura manual, y autorizando los pagos con el servicio de autorizacin (externo) de cheques de la tienda a travs de consulta telefnica. evidente R2.4 Registra los pagos en el sistema de cuentas por cobrar, pues el servicio de autorizacin de crdito debe a la tienda el monto del pago. oculta d) Atributos del sistema Los atributos del sistema son cualidades no funcionales que a menudo se confunden con las funciones. Por ejemplo: facilidad de uso, tolerancia a fallas, tiempo de respuesta, metfora de interfaz, plataformas. Los atributos tienen un posible conjunto de detalles de atributos, los cuales tienden a ser valores discretos, confusos o simblicos. Por ejemplo: tiempo de respuesta = (psicolgicamente correcto) metfora de interfaz = (grfico, colorido, basado en formularios) Algunos atributos del sistema tambin pueden tener restricciones de frontera del atributo, que son condiciones obligatorias de frontera, generalmente en un rango numrico de valores de un atributo. Por ejemplo: tiempo de respuesta = (dos segundos como mximo) Algunos atributos del sistema de punto de venta son: Atributo Detalles y restricciones de frontera tiempo de respuesta (restriccin de frontera) Cuando se registre un producto vendido, la descripcin y el precio aparecern en un segundo. metfora de interfaz (detalle) Ventanas orientadas a la metfora de un formulario y cuadros de dilogo.

(detalle) Maximiza una navegacin fcil con teclado y no con mouse. tolerancia a fallas (restriccin de frontera) Debe registrar los pagos a crdito autorizados que se hagan a las cuentas por cobrar en un plazo de 24 horas, aun cuando se produzcan fallas de energa o del equipo. plataformas del sistema operativo (detalle) Microsoft Windows 95, 98, 2000 y NT. Finalmente, es conveniente describir todos los atributos del sistema que se relacionen claramente con las funciones especificadas. Adems, los detalles de los atributos y las restricciones de frontera pueden catalogarse como obligatorios u opcionales. Por ejemplo: Ref. Funcin Categora Atributo Detalles y restricciones Categora R1.9 Mostrar la descripcin y el precio del producto registrado. evidente tiempo de respuesta 1 segundo como mximo obligatorio

metfora de interfaz Con colores. obligatorio

Pantallas basadas en formularios.

R2.4 Registrar los pagos a crdito en el sistema de cuentas por cobrar, pues el servicio de autorizacin de crdito debe a la tienda el importe del pago. oculto tolerancia a fallas Debe registrar en las cuentas por cobrar en un plazo de 24 horas, aun cuando se produzcan fallas de energa o del equipo. obligatorio

tiempo de respuesta obligatorio

10 segundos como mximo

Ms Informacin Ingeniera de requerimientos http://www.monografias.com/trabajos6/resof/resof.shtml

Requisito no funcional
Un requisito no funcional es, en la ingeniera de sistemas y la ingeniera de software, un requisito que especifica criterios que pueden usarse para juzgar la operacin de un sistema en lugar de sus comportamientos especficos, ya que stos corresponden a los requisitos funcionales. Los requisitos no funcionales ms habituales son la estabilidad, la portabilidad y el costo.

Ejemplos
A un sistema se le puede pedir que muestre en tiempo real la cantidad de datos de una base: se es un requisito funcional. En cunto tiempo debera el sistema actualizar su verificacin interna de cantidad de datos es, en cambio, un requisito no funcional.

UNIDAD I Fundamentos del anlisis de sistemas *)cap1 "Como asumir el papel de el analista de sistemas "
tipos de sistemas: sistema de procesamiento de transacciones (TPS)

son sistemas de informacin computarizados desarrollados para procesar gran cantidad de transacciones rutinarias de los negocios. Ej: Sistemas ERP, SAP, JDEDwards, Oracle finantials, softland, Contaplus. sistemas de automatizacion de oficina y sistemas de manejo de conocimiento (OAS) dan soporte a los trabajadores de datos, quienes, por lo general, no crean un nuevo conocimiento sino que usan la informacin para analizarla y transformar datos, o para manejarla en alguna forma y luego compartirla o diseminarla formalmente por toda la organizacin y algunas veces ms all de ella. sistemas de informacion gerencial (MIS) Los MIS son sistemas de informacin computarizada que trabajan debido a la interaccin resuelta entre gentes y computadoras. Requieren que las gentes, el software (programas de computadora) y el hardware (computadoras, impresoras, etc.) trabajen al unsono. Los sistemas de informacin dan soporte a un espectro ms amplio de tareas organizacionales que los sistemas de procesamiento de transacciones, incluyendo el anlisis de decisiones y la toma de decisiones. sistema de apoyo de decisiones (DSS) El DSS es similar al sistema de informacin gerencial tradicional en que ambos dependen de una base de datos como fuente. Un sistema de apoyo a decisiones se aparta del sistema de informacin gerencial tradicional en que enfatiza el apoyo a la toma de decisiones en todas sus fases, aunque la decisin actual todava es del dominio del tomador de decisiones. sistemas expertos e inteligencia artificial (AI) Un sistema experto (tambin llamado un sistema basado en conocimiento) captura en forma efectiva y usa el conocimiento de un experto para resolver un problema particular experimentado en una organizacin. Observe que a diferencia del DSS, que deja la decisin final al tomador de decisiones, un sistema experto selecciona la mejor solucin a un problema o a una clase especfica de problemas sistemas de apoyo a decisiones de grupo (GDSS) Los sistemas de apoyo a decisiones de grupo (GDSS) son usados en cuartos especiales, equipados en varias configuraciones diferentes, que permiten que los miembros del grupo interacten con apoyo electrnico, frecuentemente en forma de software especializado y con una persona que da facilidades al grupo. Los sistemas para decisiones de grupo estn orientados para reunir a un grupo, a fin de que resuelva un problema con la ayuda de varios apoyos como votaciones, cuestionarios, aportacin de ideas y creacin de escenarios. sistemas de apoyo a ejecutivos (ESS) Un sistema de apoyo a ejecutivos (ESS) ayuda a stos, para organizar sus interacciones con el ambiente externo, proporcionando apoyo de grficos y comunicaciones en lugares accesibles tales como salas de juntas u oficinas personales corporativas. EL CICLO DE VIDA DEL DESARROLLO DE SISTEMAS. Identificacin de problemas, oportunidades y objetivos. Determinacin de los requerimientos de informacin. Anlisis de las necesidades del sistema. Diseo del sistema recomendado. Desarrollo y documentacin del software. Pruebas y mantenimiento del sistema. Implementacin y evaluacin del sistema. USO DE LAS HERRAMIENTAS CASE. Aumento de la productividad del analista. Mejora de la comunicacin del analista-usuario. Integracin de las actividades del ciclo de vida Evaluacin precisa de los cambios del mantenimiento

*)cap2 "Comprensin de los estilos organizacionales y su impacto sobre los sistemas de informacin"
a) FUNDAMENTOS ORGANIZACIONALES Para analizar y disear adecuadamente los sistemas de informacin, el analista de sistemas necesita comprender las organizaciones en que trabaja como sistemas conformados por la interaccin de tres fuerzas principales: los niveles de administracin, el diseo de la organizacin y la cultura organizacional. b) LAS ORGANIZACIONES COMO SISTEMAS Las organizaciones son conceptualizadas en forma til como sistemas diseados para lograr metas y objetivos predeterminados por medio de la gente y otros recursos que emplean. Las organizaciones estn compuestas de sistemas ms pequeos interrelacionados (departamentos, unidades, divisiones, etc.) que sirven a funciones especializadas. La interrelacin e interdependencia de los sistemas Todos los sistemas y subsistemas estn relacionados y son interdependientes. Este hecho tiene implicaciones importantes para las organizaciones y para los analistas de sistemas que buscan ayudarlos a lograr mejor sus objetivos. Cuando cualquier elemento de un sistema es cambiado o eliminado, tambin son impactados el resto de los elementos y subsistemas del sistema. Retroalimentacin del sistema para planeacin y control La retroalimentacin es una forma de control del sistema. Como sistemas, todas las organizaciones usan planeacin y control para administrar sus recursos en forma efectiva. La figura muestra la forma en que son usadas las salidas del sistema como retroalimentacin con la cual comparar el desempeo con los objetivos.

Esta comparacin ayuda, a la vez, a los administradores para formular objetivos ms especficos como entrada. Sin embargo, el sistema ideal es aqul que se corrige o regula por s mismo, en forma tal que no se requieren decisiones de sucesos tpicos.

Ambientes para sistemas organizacionales La retroalimentacin es recibida desde el interior de la organizacin y del ambiente exterior que la rodea. Cualquier cosa que est fuera de las fronteras de una organizacin es considerada como un ambiente. Varios ambientes, con diversos grados de estabilidad, constituyen el medio ambiente en donde existe la organizacin. Aunque se pueden planear cambios en el estado del ambiente, frecuentemente no pueden ser controlados directamente por la organizacin.

Apertura y restrictividad en las organizaciones La apertura y restrictividad existen en forma continua, ya que no hay una cosa tal como una organizacin absolutamente abierta o totalmente cerrada. La apertura se refiere al libre flujo de informacin dentro de una organizacin. Los subsistemas tales como los departamentos creativos o artsticos frecuentemente son caracterizados como abiertos, con un flujo libre de ideas entre sus participantes y muy pocas restricciones sobre quin obtiene tal informacin y en qu momento un proyecto creativo est en su infancia. Al extremo opuesto de este continuo puede estar una unidad del departamento de defensa asignada para trabajar sobre la planeacin muy confidencial que afecta la seguridad nacional. Cada persona necesita recibir acreditacin, la informacin en su momento es una necesidad y el acceso a la informacin se da con base en la que "es necesario saber". Este tipo de unidad est limitada por muchas reglas. Cmo tomar una perspectiva de sistemas La toma de una perspectiva de sistemas permite a los analistas de sistemas iniciar la clarificacin y comprensin de los diversos negocios con los que entrarn en contacto. Es importante que los miembros de subsistemas se den cuenta que su trabajo est interrelacionado. Observe en la figura que las salidas de los subsistemas de produccin sirven como entradas para ventas, y que las salidas para ventas sirven como nueva entrada para produccin. Ningn subsistema puede lograr adecuadamente sus objetivos sin el otro. Suceden problemas cuando cada administrador tiene una imagen diferente de la importancia de su propio subsistema funcional.

En la siguiente figura se puede ver que la perspectiva personal del administrador de ventas muestra que el negocio est manejado por las ventas, con todas las dems reas funcionales interrelacionadas pero no de importancia central. De la misma manera, la perspectiva de un
administrador de produccin posiciona la produccin como la parte central del negocio, con todas las dems reas funcionales manejadas por ella.

REPRESENTACIN GRFICA DE SISTEMAS Un sistema o subsistema, tal como existe dentro de la organizacin corporativa, puede ser representado grficamente en varias formas. Los diversos modelos grficos muestran las fronteras del sistema y la informacin usada dentro del sistema. Los sistemas y el diagrama de flujo de datos a nivel contexto El primer modelo es el diagrama de flujo de datos a nivel contexto (tambin llamado modelo ambiental). Los diagramas de flujos de datos se enfocan en los datos fluyendo hacia adentro y fuera del sistema y el procesamiento de los datos. Estos componentes bsicos de todo programa de computadora pueden ser descritos a detalle y usados para analizar el problema con respecto a su precisin y totalidad. El diagrama a nivel de contexto emplea solamente tres smbolos: (1) un rectngulo con esquinas redondeadas, (2) un cuadrado con dos orillas sombreadas y (3) una flecha, tal como se muestra en la figura. Los procesos transforman los datos de entrada en informacin de salida, y el nivel de contenido tiene solamente un proceso que representa al sistema completo. La entidad externa representa cualquier entidad que proporciona o recibe informacin de sistema pero que no es parte del sistema. Esta entidad puede ser una persona, un grupo de personas, una posicin corporativa o departamento u otros sistemas. Las lneas que conectan las entidades externas con el proceso son llamados flujos de datos y representan datos.

Un ejemplo de un diagrama de flujo de datos a nivel contexto se encuentra en la siguiente figura. En este ejemplo se representan los elementos bsicos de un sistema de
reservaciones de una lnea area. El pasajero (una entidad) inicia una peticin de viaje (flujo de datos). El diagrama a nivel contexto no muestra suficientes detalles para indicar exactamente lo que sucede (y tampoco se pretende que se muestre), pero podemos ver que se envan las preferencias del pasajero y los vuelos disponibles al agente de viajes, que enva de regreso al proceso informacin sobre los boletos. Tambin podemos ver que la reservacin del pasajero es enviada a la lnea area.

Los sistemas y el modelo entidad-relacin Una manera en que un analista de sistemas puede definir las fronteras adecuadas del sistema es usar un modelo entidad-relacin. Los elementos que conforman un sistema organizacional pueden ser llamados entidades. Una entidad puede ser una persona, un lugar o una cosa, tal como un pasajero en una lnea area, un destino o un avin. En forma alterna, una entidad puede ser un evento, tal como el fin de mes, un periodo de ventas o la falla de una mquina. Una relacin es la asociacin que describe la interaccin entre las entidades. El formato estndar para trazar un diagrama entidad-relacin (o E-R), mostrado en la figura de la izquierda, usa solamente dos smbolos: un rectngulo y un rombo. El rectngulo es usado para mostrar una entidad, y el rombo representa la relacin entre esa entidad y otra entidad. El diagrama siempre es trazado poniendo en la parte superior a la entidad primaria. La figura de la derecha muestra los cuatro tipos diferentes de diagramas E-R. El primero es una relacin uno a uno (1:1). Aqu a cada EMPLEADO le es asignada solamente una EXTENSIN TELEFNICA, y cada EXTENSIN TELEFNICA es nica para cada EMPLEADO. El segundo diagrama muestra una relacin muchos a uno (M:1). Un DEPARTAMENTO puede tener muchos EMPLEADOS, pero el EMPLEADO puede pertenecer a solamente un DEPARTAMENTO. El tercer tipo de diagrama (E-R) muestra una relacin uno a muchos (1:M). Por ltimo, el cuarto diagrama muestra una relacin muchos a muchos (M:N). Un VUELO puede llevar muchos PASAJEROS y un PASAJERO puede tener muchos VUELOS en su itinerario.

Los diagramas entidad-relacin son usados frecuentemente por los diseadores de sistemas para ayudar a modelar el archivo o base de datos. Sin embargo, es todava ms importante que el analista de sistemas comprenda desde las primeras etapas las entidades y relaciones en el sistema organizacional.

Para trazar algunos diagramas E-R bsicos el analista necesita:

1. Listar las entidades de la organizacin para obtener una mejor comprensin de la organizacin. 2. Escoger entidades clave para estrechar el alcance del problema a dimensiones manejables y significativas. 3. Identificar cul debe ser la entidad primaria. 4. Confirmar los resultados de los pasos 1 a 3 por medio de otros mtodos de recoleccin de datos (investigacin, entrevistas, administracin de cuestionarios, observacin y elaboracin de prototipos).

NIVELES DE ADMINISTRACIN

Administracin de operaciones El control operacional forma el nivel inferior de la administracin a tres niveles. Los administradores de operaciones toman decisiones usando reglas predeterminadas que tienen resultados predecibles cuando son implementadas correctamente. Los administradores de operaciones son los tomadores de decisiones cuyo trabajo es el ms claro, debido al alto nivel de certeza en su ambiente de toma de decisiones. Administracin media La administracin media forma el nivel segundo, o intermedio, del sistema de administracin de tres niveles. La administracin media realiza decisiones de planeacin y control a corto plazo sobre la manera en que son mejor asignados los recursos para satisfacer los objetivos organizacionales. La administracin media experimenta muy poca certeza en su ambiente de toma de decisiones. Administracin estratgica La administracin estratgica comprende el tercer nivel del control administrativo de tres niveles. Los administradores estratgicos ven fuera de la organizacin hacia el futuro, tomando decisiones que guiarn

a los administradores medios o de operacin en los meses y aos por venir. Los administradores estratgicos trabajan en un ambiente de toma de decisiones altamente incierto. Implicaciones para el desarrollo de sistemas de informacin Los administradores de operaciones necesitan informacin interna que es, por naturaleza, de bajo nivel y repetitiva. Tienen gran dependencia sobre la informacin que captura el desempeo actual y son grandes usuarios de recursos de informacin en lnea de tiempo real. La necesidad de los administradores de operaciones de informacin sobre el desempeo pasado y la informacin peridica es solamente moderada. Ellos tienen poco uso para informacin externa que les permita proyecciones futuras o creacin de escenarios "qu pasa si". La administracin media, que tanto planea como controla, se necesita informacin de corto y largo plazo. Debido a la naturaleza de su trabajo de resolver problemas, los administradores medios experimentan necesidades extremadamente altas de informacin en tiempo real. Para poder controlar adecuadamente tambin necesitan informacin actual del desempeo medido en comparacin a juegos de estndares. Los administradores estratgicos (difieren, en buena medida, de los administradores medios y de operaciones en sus requerimientos de informacin). Son altamente dependientes de informacin de fuentes externas que les proporciona noticias sobre las tendencias del mercado y las estrategias de corporaciones con las que compiten. Debido a que la tarea de la administracin estratgica demanda proyecciones hacia un futuro incierto, los administradores estratgicos tienen una gran necesidad de informacin de naturaleza predictiva e informacin que les permita la creacin de muchos escenarios "qu pasa si". Los administradores estratgicos tambin muestran grandes necesidades de informacin reportada peridicamente cuando buscan adaptarse a cambios rpidos. Los planeadores estratgicos necesitan informacin general resumida, en vez de los datos burdos altamente detallados requeridos por los administradores de bajo nivel. La informacin para los planeadores estratgicos puede ser ms antigua y estimada y, en cambio, los administradores operacionales necesitan informacin precisa y actual. Por ltimo, el planeador estratgico necesita informacin cualitativa, principalmente de fuentes externas, en vez de la informacin cuantitativa de fuentes internas requerida por la administracin de operaciones.

*)cap3 "DETERMINACIN DE LA FACTIBILIDAD Y EL MANEJO DE LAS ACTIVIDADES DE ANLISIS Y DISEO"

Los cuatro puntos principales que el analista de sistemas debe manejar son: a) Iniciacin del proyecto, b) Determinacin de la factibilidad del proyecto, c) Calendarizacin del proyecto, y, d) Administracin de los miembros del equipo del anlisis del sistema.

De acuerdo a la figura, el revisar la salida, la observacin del comportamiento de los empleados y el escuchar la retroalimentacin, son maneras que ayudarn al analista a resaltar los problemas y oportunidades de los problemas. Los proyectos pueden ser solicitados por muchas personas diferentes dentro del negocio o por los mismos analistas de sistema. La seleccin de un proyecto es una decisin difcil, debido a que sern solicitados ms proyectos de los que pueden ser hechos. Cinco criterios importantes para la seleccin de proyectos son: a) Que el proyecto solicitado est respaldado por la administracin, b) Que tenga el tiempo adecuado para la asignacin de recursos, c) Que mueva al negocio hacia la obtencin de sus objetivos, d) Que sea practicable, y, e) Que sea lo suficientemente importante para ser considerado en vez de otros proyectos posibles. Si un proyecto solicitado satisface estos criterios, entonces puede ser elaborado un estudio de factibilidad de sus mritos operacionales, tcnicos y econmicos. Por medio de este estudio los analistas de sistemas recopilan datos que permiten a la administracin decidir si continan con un estudio de sistema completo.

La planeacin del proyecto incluye la estimacin del tiempo requerido por cada una de las actividades del analista, su calendarizacin y la agilizacin de ellas, si es necesario, para asegurar que un proyecto sea terminado a tiempo. Una tcnica de que dispone el analista de sistemas para la calendarizacin de tareas es la grfica de Gantt, la cual despliega actividades en forma de barras en una grfica. En la figura se muestran las tres actividades principales para empezar a planear.

En la figura se muestra como es necesario refinar la planeacin de las actividades del anlisis aadiendo tareas detalladas y estableciendo el tiempo que se lleva terminar estas tareas.

La calendarizacin de proyectos basada en computadora, es ahora una prctica comn, debido principalmente al uso de interfaces de usuario grficas. Adicionalmente, se pueden usar los administradores de informacin personales (PIM) por los analistas para planear, crear depsitos de nmeros telefnicos y de fax y hasta ejecutar otros programas.

Una segunda tcnica, llamada PERT (evaluacin de programas y tcnicas de revisin), despliega las actividades como flechas en una red. El PERT ayuda a que el analista determine la ruta crtica y el tiempo de holgura, que es la informacin requerida para el control efectivo del proyecto. Cuando es necesario terminar un proyecto en menor tiempo, el analista puede reducir la duracin total del proyecto identificando y agilizando las actividades principales.

En la figura se muestra el uso de la Grfica de Gantt de dos dimensiones para la planeacin de actividades que pueden ser realizadas en paralelo

Muestra del Diagrama PERT para la calendarizacin de actividades

Una vez que ha sido juzgado factible, el analista de sistemas debe administrar a los miembros del equipo, sus actividades, tiempo y recursos. La mayor parte de esto se logra mediante la comunicacin con los miembros del equipo. Los equipos estn constantemente buscando un balance entre trabajar sobre las tareas y mantener las relaciones con el equipo. Deben ser solucionadas las tensiones que suceden al intentar lograr este balance. Frecuentemente emergen dos lderes en un equipo, un lder de tarea y un lder socioemocional. Los miembros deben valorar peridicamente las normas del equipo para asegurarse de que sean funcionales en vez de disfuncionales para el logro de los objetivos de equipo.

Listado de las actividades para ser usado en el trazo de un diagrama PERT

Es importante que el equipo de anlisis ponga objetivos de productividad razonables para las salidas tangibles y las actividades del proceso. Las fallas del proyecto pueden ser evitadas, por lo general, examinando las motivaciones de los proyectos solicitados, as como los motivos del equipo para recomendar o evitar un proyecto particular. Un diagrama PERT terminado para la fase de anlisis de un proyecto de sistema

Una tabla que muestra la duracin mnima y el costo de agilizacin

Uso de la agilizacin para minimizar el tiempo del proyecto

OBS: BUSCAR INFO DE DIAGRAMA DE GANTT Y DE PERT

UNIDAD II Anlisis de los requerimientos de informacin MUESTREO E INVESTIGACIN DE DATOS IMPRESOS.

El proceso de seleccionar sistemticamente elementos representativos de una poblacin es llamado muestreo. El objeto del muestreo es seleccionar v estudiar documentos, tales como facturas, reportes de ventas y memorndums, o tal vez seleccionar y entrevistar, dar cuestionarios u observar a miembros de la organizacin. El muestreo puede reducir costos, velocidad de recoleccin de datos, hacer potencialmente que el estudio sea ms efectivo y posiblemente reducir la ascendencia en el estudio.

Cuatro tipos principales de muestras que tiene el analista.

Un analista de sistemas debe seguir cuatro pasos en el diseo de una buena muestra. Primero, se tiene la necesidad de determinar la poblacin misma. Segundo, se debe decidir el tipo de muestra. Tercero, se debe calcular el tamao de muestra. Por ltimo, se deben planear los datos que necesitan ser recolectados o descritos.

Tipos de informacin buscada en la investigacin

Los tipos de muestras tiles para un analista de sistemas son: de conveniencia, intencionada, aleatoria simple y aleatoria compleja. El ltimo tipo incluye las subcategoras de muestreo sistemtico y muestreo estratificado. Hay varios lineamientos a seguir para la determinacin del tamao de muestra. El analista de sistemas puede hacer una decisin subjetiva en relacin con el estimado de intervalo aceptable. Luego se selecciona un nivel de confianza y puede ser calculado el tamao de muestra necesario.

El analista de sistemas necesita investigar datos relevantes, incluyendo reportes, documentos, estados financieros, manuales de procedimientos y memorndums. Los datos relevantes muestran dnde ha estado la organizacin y hacia dnde creen sus miembros que est yendo. Es necesario que sean analizados documentos cuantitativos y cualitativos. Debido a que los documentos son mensajes persuasivos, debe ser reconocido que el cambiarlos tambin puede cambiar a la organizacin.

Las consignas que se colocan revelan la cultura oficial de la organizacin Hay muchas formas de analizar documentos cuantitativos y cualitativos. Sin embargo, es importante recordar que la investigacin de los datos archivados tiene ventajas y desventajas. Debido a que muchas de las desventajas pueden ser superadas, vale la pena la investigacin de archivos.

Una de las desventajas del uso de datos archivados es que los datos pueden ser importantes solamente para aquel que originalmente los guard.

ENTREVISTAS.
El proceso de las entrevistas es un mtodo que usa el analista de sistemas para la recoleccin de datos sobre los requerimientos de informacin. El analista de sistemas escucha buscando objetivos, sentimientos, opiniones y procedimientos informales en entrevistas con los tomadores de decisiones de la organizacin. Tambin vende el sistema durante las entrevistas. Las entrevistas son dilogos de preguntas respuestas planeados por anticipado entre dos personas.

Hay cinco pasos que deben tomarse para la planeacin previa de la entrevista: 1. Lectura de material de fondo 2. Establecimiento de objetivos de la entrevista 3. Decisin de a quin entrevistar 4. Preparacin del entrevistado 5. Decisin sobre el tipo y estructura de las preguntas

a Las preguntas tienen dos tipos bsicos: abiertas y cerradas. Las preguntas abiertas dejan abiertas todas las opciones de respuesta para el entrevistado, Las preguntas cerradas limitan las opciones posibles de la respuesta. Las averiguaciones pueden ser abiertas o cerradas, pero le solicitan al interlocutor una respuesta ms detallada.

Las entrevistas pueden estar estructuradas en tres formas bsicas, estructura de pirmide, de embudo o de rombo.

Las estructuras piramidales comienzan con preguntas cerradas y detalladas y se amplan a preguntas ms generales.

Las estructuras de embudo comienzan con preguntas abiertas generales y luego se estrechan a preguntas cerradas ms especficas.

Las estructuras de rombo combinan las fuerzas de las otras dos estructuras pero se llevan ms tiempo para realizarse. Hay compromisos involucrados sobre la decisin de cmo estructurar para realizar las preguntas y secuencias de preguntas de la entrevista. Las entrevistas deben ser grabadas por medio de grabadoras de cinta o la toma de notas. Despus de la entrevista, el entrevistador debe escribir un reporte que liste los puntos principales que se proporcionaron, as como opiniones acerca de lo que fue dicho. Es extremadamente importante documentar la entrevista lo ms pronto posible despus de que haya sido realizada. Para reducir tanto el tiempo como el costo de las entrevistas personales, los analistas pueden considerar el diseo conjunto de aplicaciones (JAD) como una alternativa. Mediante el uso del JAD los analistas logran tanto el anlisis de requerimientos como el diseo de la interfaz de usuario con los usuarios en un lugar de reunin de grupo. La valoracin cuidadosa del lugar de reunin para la organizacin ayudar a juzgar al analista si el JAD es una alternativa adecuada.

USO DE CUESTIONARIOS.
Mediante el uso de cuestionarios los analistas de sistemas pueden recolectar datos sobre actitudes, creencias, comportamientos y caractersticas de gentes importantes en la organizacin. Los cuestionarios son tiles s: las personas de la organizacin estn ampliamente dispersas, muchas gentes estn involucradas con el proyecto de sistema, se necesita un trabajo exploratorio antes de recomendar alternativas o hay una necesidad para la sensibilizacin del problema antes de que se realicen entrevistas.

OBSERVACIN DEL COMPORTAMIENTO DE LOS TOMADORES DE DECISIONES Y EL AMBIENTE DE OFICINA.

Los analistas usan la observacin como una tcnica de recopilacin de ir, formacin. Por medio de la observacin obtienen apreciaciones sobre lo que se hace realmente, ven de primera mano las relaciones entre los tomadores de decisiones en una organizacin, comprenden la influencia del ambiente fsico de ste, interpretan los mensajes enviados por el tomador por medio de su vestimenta y el acomodo de su oficina y comprenden la influencia del tomador de decisiones con respecto a los dems. Adems de la observacin del comportamiento del tomador de decisiones, el analista de sistemas debe observar tambin lo que le rodea. Un mtodo para la observacin estructurado del ambiente es llamado STROBE, Un analista de sistemas usa STROBE en la misma forma que un crtico de cine usa un mtodo llamado mise-en-scne para analizar una toma de una pelcula Varios elementos concretos del ambiente del tomador de decisiones pueden ser observados e interpretados. Estos elementos incluyen (1) la ubicacin de la oficina, (2) la ubicacin del escritorio del tomador de decisiones, (3) el equipo de oficina fijo, (4) las propiedades, tales como calculadoras y pantallas, (5) revistas del negocio y peridicos, (6) iluminacin y color de la oficina y (7) la vestimenta usada por el tomador de decisiones. Se puede usar STROBE para obtener una mejor comprensin sobre la manera en que los tomadores de decisiones actualmente recopilan, procesan, guardan y comparten informacin, Hay varias alternativas para la aplicacin de STROBE en una organizacin. Estas incluyen el anlisis de fotografas, el uso de una lista de verificacin con base en la escala Likert, la adopcin de una lista anecdtica con smbolos y la simple escritura de una comparacin de observacin/narrativa, Cada mtodo tiene determinadas ventajas, as como desventajas, que el analista debe sopesar cuando seleccione una alternativa sobre la otra.

PROTOTIPOS
La elaboracin de prototipos es una tcnica de recopilacin de informacin til para complementar el ciclo de vida de desarrollo de un sistema tradicional. Cuando el analista de sistemas usa prototipos est buscando reacciones, sugerencias, innovaciones y planes de revisin del usuario para hacer mejoras al prototipo y, por lo tanto, modificar los planes del sistema con un mnimo de gastos y trastornos. Los sistemas que apoyan la toma de decisiones semiestructuradas (tal como lo hacen los sistemas de apoyo a decisiones) son buenos candidatos para la elaboracin de prototipos. El trmino prototipo tiene diferentes significados, de los cuales son comnmente usados cuatro de ellos. La primera definicin de la elaboracin de prototipos es la de construccin de un prototipo parchado. Una segunda definicin es un prototipo no operacional que es usado para probar determinadas caractersticas del diseo. Un tercer concepto es la creacin de un prototipo primero de la serie que es completamente operacional. Este tipo de prototipo es til cuando estn planeadas muchas instalaciones del mismo sistema de informacin (bajo condiciones similares). El cuarto tipo es un prototipo con caractersticas seleccionadas que tiene algunas, pero no todas, de las caractersticas esenciales del sistema. Usa mdulos autocontenidos como bloques de construccin, para que si las caractersticas prototpicas son satisfactorias puedan ser conservadas e incorporadas en el sistema terminado mucho ms grande. Los cuatro lineamientos principales para el desarrollo de un prototipo son: (1) trabajar en mdulos manejables, (2) construir el prototipo rpidamente, (3) modificar el prototipo y (4) enfatizar la interfaz de usuario. Una desventaja de los prototipos es que el manejo del proceso de elaboracin del prototipo es difcil, debido a la rapidez del proceso y a sus muchas iteraciones. Una segunda desventaja es que puede haber presiones para que sea puesto en servicio un prototipo incompleto, como si fuera un sistema completo. Aunque la elaboracin de prototipos no es siempre necesaria o deseable, debe hacerse notar que hay tres ventajas principales interrelacionadas de su uso: (1) el potencial para cambiar el sistema en etapas tempranas de su desarrollo, (2) la oportunidad de detener el desarrollo de un sistema que no es funcional y (3) la posibilidad de desarrollar un sistema que satisfaga en mejor forma las necesidades y expectativas de los usuarios. Los usuarios tienen un papel distinguido en el proceso de elaboracin de prototipos. Su primer inters debe ser interactuar con el prototipo mediante experimentacin. Los analistas de sistemas deben trabajar sistemticamente para obtener y evaluar las reacciones de los usuarios ante el prototipo, y luego trabajar para incorporar las sugerencias e innovaciones de los usuarios que valgan la pena en las modificaciones subsecuentes.

UNIDAD III El uso del anlisis USO DE DIAGRAMAS DE FLUJO DE DATOS

Para comprender mejor el movimiento lgico de los datos en un negocio, el analista de sistemas traza diagramas de flujo de datos (DFD). Los diagramas de flujo de datos son anlisis estructurados y herramientas de diseo que permiten que el analista comprenda visualmente el sistema y subsistemas como un juego de flujos de datos interrelacionados.

La representacin grfica del movimiento, almacenamiento y transformacin de datos es trazada con el uso de cuatro smbolos: un rectngulo redondeado para indicar procesamiento o transformaciones de datos, un cuadrado doble para mostrar una entidad de datos externa (origen o receptor de datos), una flecha para mostrar el flujo de datos y un rectngulo de extremo abierto para mostrar un almacn de datos.

El analista de sistemas extrae procesos, fuentes, almacenes y flujos de datos desde las primeras narraciones organizacionales, y usa un enfoque de arriba hacia abajo para trazar primero un diagrama de contexto del sistema, dentro de la imagen ms grande. Luego es trazado un diagrama de flujo de datos lgico a nivel 0. Se muestran los procesos y se aaden los almacenes de datos. Luego el analista crea un diagrama hijo para cada uno de los procesos del Diagrama 0. Las entradas y salidas permanecen constantes, pero cambian los almacenes de datos y las fuentes. La explosin del diagrama de flujo original permite que el analista de sistemas se enfoque en representaciones cada vez ms detalladas de los movimientos de datos dentro del sistema. Luego, el analista desarrolla un diagrama de flujo de datos fsico a partir del diagrama de flujo de datos lgico, particionndolo para facilitar la programacin. Cada proceso es analizado para determinar si debe ser un procedimiento manual o automatizado. Los procesos automatizados son agrupados subsecuentemente en una serie de programas de computadora diseados para ser por lotes o en lnea.

Seis consideraciones para particin de diagramas de flujo incluyen si: hay procesos ejecutados por diferentes grupos de usuarios, hay procesos que se ejecuten al mismo tiempo, hay procesos que ejecuten tareas similares, los procesos por lotes pueden ser combinados para un procesamiento eficiente, los procesos pueden ser combinados en un programa para tener consistencia de datos, o si los procesos pueden ser partidos en diferente programas por razones de seguridad. El diagrama de flujo de datos correcto para el ejemplo de la nmina.

Las ventajas de los diagramas de flujo de datos incluyen la simplicidad de la notacin, usndola para obtener informacin ms clara de los usuarios, permitiendo que el analista de sistemas conceptualice los flujos de datos necesarios sin estar atado a una implementacin fsica particular, permitir que los analistas conceptualicen mejor las interrelaciones del sistema y sus subsistemas y analicen un sistema propuesto para determinar si han sido definidos los datos y procesos necesarios.

El diagrama de flujo de datos fsico (abajo) muestra determinados detalles que no se encuentran en el diagrama de flujo de datos lgico (arriba). Caso No hay negocio como el negocio de flujos Suena el telfono de Merman, y Annie Oakiea, jefa del inventario de vestidos, lo levanta y responde a una pregunta diciendo, "Djame echar una ojeada en las tarjetas de inventario. Lstima, parece como si slo hubiera dos trajes de oso macho en el inventario, con una expresin de extraeza. Tenemos gran cantidad de osos. Cundo lo necesita? Tal vez regresen uno. No, no puede hacerlo, lo siento. Sin embargo, quisiera que le enviara esos dos? Cul es el nombre de su local? El teatro en la plaza? Correcto. Qu bella compaa! Veo por nuestras tarjetas de contabilidad que usted ya ha rentado con nosotros antes. Cunto tiempo necesitar los trajes?". La figura es un diagrama de flujo de datos que pone los pasos para el procesamiento de rentas de trajes de Merman. Muestra rentas como la que Annie est haciendo para el teatro de la plaza. Diagrama de flujo de datos para Mermans Costume Rentals

Despus de conversar unos momentos ms sobre la poltica de la tienda acerca de alteraciones, Annie termina su conversacin diciendo, "Tienen ustedes mucha suerte para obtener los osos con tan poco aviso. He estado en otra compaa reservndolos desde la primera semana de julio. Les enviar los trajes de oso y se los llevar directamente nuestro mensajero. Como siempre, el retorno rpido nos ahorrar problemas enormes a todos". La empresa de renta de trajes de Merman est ubicada en el distrito teatral West End, de Londres, famoso mundialmente. Cuando a una compaa de produccin de teatro o televisin le faltan recursos (ya sea por tiempo o experiencia) para construir un traje en su propio taller, el grito es "Hblenle a Merman!" y ellos proceden a rentar lo que necesitan con el mnimo de problemas. La tienda (visualizada mejor como bodega) est en tres pisos llenos de percheros de trajes que tienen miles de ellos colgados juntos por periodo histrico, agrupados luego por si son para hombre o mujer y luego por tamao de traje.'

La mayora de las compaas de teatro son capaces de localizar precisamente lo que necesitan por medio de la asistencia capaz de Annie. Ahora elabore a la medida la parte de regreso de renta de diagrama de flujo dado anteriormente. Recuerde que los retornos a tiempo son crticos para mantener la fama de los trajes rentados a Merman.

MIS PASOS COMO ANALISTA DE SISTEMA

Mis pasos como analista de sistemas comprende lo siguiente: A) Como analista debo investigar, planear, coordinar y recomendar soluciones en sistemas informticos y software de calidad.
Tener en cuanta que EL CICLO DE VIDA DEL DESARROLLO DE SISTEMAS consiste en: Identificacin de problemas, oportunidades y objetivos. Determinacin de los requerimientos de informacin. Anlisis de las necesidades del sistema. Diseo del sistema recomendado. Desarrollo y documentacin del software. Pruebas y mantenimiento del sistema. Implementacin y evaluacin del sistema.

Observar las dependencias de la empresa para identificar tipo empresa, las personas, cultura y relacin con la tecnologa y la informtica.
B)

Obtener anlisis de requerimientos tanto funcionales como no funcionales de lo que seria el sistema. Adems de otras actividades:
C)

Dividiendo proyectos complejos en proyectos menores y manejables Anlisis de requerimientos (Panorama general, Metas, Funciones del sistema,
Atributos del sistema)

Utilizar diagrama de flujo de datos para representar los procesos en los sistemas, flujo de datos, ect. Adems de los diagramas de ER(entidad relacin) para delimitar fronteras den el sistema. UML y casos de usos
A) Utilizar tcnica para la recoleccin de datos como: muestreo, entrevistas, uso de cuestionarios, prototipo (diseo y puesta a prueba)entre otros

B) Utilizar UML para el desarrollo de las especificaciones del sistema, a travs de los casos de usos y diagramas.

(Se puede utilizar la herramienta Enterprise Architec para desarrollo de arquitectura de software)