QU ES UN SISTEMA? Sistema se refiere a un todo, es un grupo de componentes interrelacionados entre s trabajando juntos con un objetivo comn.

Cada uno de estos componentes, es a su vez un sistema en s mismo. Todo sistema cuenta con una entidad abstracta denominada sistema de informacin. Este sistema es el medio que permite a los datos, fluir entre los diferentes departamentos o personas que integran la organizacin Segn Bertalanffy, sistema es un conjunto de unidades recprocamente relacionadas. De ah se deducen dos conceptos: propsito (u objetivo) y globalismo (o totalidad). QU ES EL ANLISIS DE SISTEMAS? El Anlisis de Sistemas tiene un origen histrico militar, vinculado a la Investigacin Operativa. Aparece, finalizada ya la Guerra Mundial, situndose su fecha de origen en 1948 coincidente con la creacin de la Rand Corporation como empresa de asesoramiento sin afn de lucro y financiada inicialmente por la Fundacin Ford. Durante largo tiempo, y todava actualmente, el Anlisis de Sistemas se aplic fundamentalmente a sistemas militares, probando, una vez ms, el carcter blico de la utilizacin primera de las nuevas tcnicas; Se aplic luego a sistemas fsicos y, finalmente, a partir de 1960 aparecen las primeras tentativas de aplicacin a sistemas ms complejos de tipo social o humano. En este sentido se define Anlisis de Sistemas como un conjunto de estudios analticos previos que ayudan al responsable a decidir frente a problemas complejos, y al mismo tiempo le determinan una lnea de actuacin entre varias alternativas de accin posible conducentes a una misma finalidad, con la comparacin cuantitativa de criterios apropiados de los costes y ventajas de las soluciones consideradas. En aras de la simplificacin y atribuyendo al Anlisis de Sistemas la antigedad y dimensin que le corresponden, proponemos como definicin la siguiente: Proceso metdico que permite conocer y controlar los sistemas. CARACTERISTICAS El Anlisis de Sistemas, admite el anlisis y el clculo solamente como una ayuda al criterio y percepcin del decisor. Aporta el enfoque sistmico, es decir, estudia globalmente situaciones complejas, con objetivos en ocasiones mal definidos, una gama amplia de incertidumbres y un elevado nmero de variables.

 El Anlisis de Sistemas ser el instrumento que guiar la reflexin a realizar antes de la decisin, estudiando el problema en toda su globalidad. El Anlisis de Sistemas es de nivel superior, con una dimensin que podramos decir estratgica y donde las decisiones tienen siempre un componente econmico y el anlisis costo- beneficio o costo-eficacia se hacen imprescindibles. PAPEL DEL ANALISTA DE SISTEMAS El analista exitoso debe contar con una amplia gama de cualidades y la mayora tienen algunas cualidades comunes. En primer lugar, el analista es un solucionador de problemas. Es una persona que aborda como un reto el anlisis de problemas y que disfruta al disear soluciones factibles. Cuando es necesario, el analista debe contar con la capacidad de afrontar sistemticamente cualquier situacin mediante la correcta aplicacin de herramientas, tcnicas y su experiencia. El analista tambin debe ser un comunicador con capacidad para relacionarse con los dems durante extensos periodos. Necesita suficiente experiencia en computacin para programar, entender las capacidades de las computaras, recabar los requisitos de informacin de los usuarios y comunicarlos a losa programadores. Asimismo, debe tener una tica personal y profesional firme que le ayude a moldear las relaciones con sus clientes. Debe ser una persona autodisciplinada y auto motivada, con la capacidad de administrar y coordinar los innumerables recursos de un proyecto, incluyendo a otras personas. La profesin de analista de sistemas es muy exigente; pero es una profesin en constante evolucin que siempre trae nuevos retos. ROLES DEL ANALISTA DE SISTEMAS El analista de sistemas evala de manera sistemtica el funcionamiento de un negocio mediante el examen de la entrada y el procesamiento de datos y su consiguiente produccin de informacin, con el propsito de mejorar los procesos de una organizacin. Muchas mejoras incluyen un mayor apoyo a las funciones de negocios a travs del uso de sistemas de informa- cin computarizados. Esta definicin pone nfasis en un enfoque sistemtico y metdico para analizar y en consecuencia mejorar lo que sucede en el contexto especfico creado por un negocio. El analista debe tener la capacidad de trabajar con todo tipo de gente y contar con suficiente experiencia en computadoras. El analista desempea diversos roles, en ocasiones varios de ellos al mismo tiempo. Los tres roles principales del analista de sistemas son el de consultor, experto en soporte tcnico y agente de cambio.

EL ROL DE CONSULTOR DEL ANALISTA DE SISTEMAS Con frecuencia, el analista de sistemas desempea el rol de consultor para un negocio y, por tanto, podra ser contratado de manera especfica para enfrentar los problemas de sistemas de informacin de una empresa. Esta contratacin se puede traducir en una ventaja porque los consultores externos tienen una perspectiva fresca de la cual carecen los dems miembros de una organizacin. Tambin se puede traducir en una desventaja porque alguien externo nunca conocer la verdadera cultura organizacional. En su funcin de consultor externo, usted depender en gran medida de los mtodos sistemticos que se explican en este libro para analizar y disear sistemas de informacin apropiados para una empresa en particular. Adems, tendr que apoyarse en los usuarios de los sistemas de informacin para entender la cultura organizacional desde la perspectiva que tienen ellos. EL ROL DE EXPERTO EN SOPORTE TECNICO DEL ANALISTA DE SISTEMAS Otro rol que tendr que desempear es el de experto en soporte tcnico dentro de la empresa. En este rol el analista recurre a su experiencia profesional con el hardware y software de cmputo y al uso que se le da en el negocio. Con frecuencia, este trabajo no implica un proyecto completo de sistemas, sino ms bien la realizacin de pequeas modificaciones o la toma de decisiones que se circunscriben a un solo departamento. Como experto de soporte tcnico, el analista no esta a cargo del proyecto; tan solo acta como recurso para aquellos que si lo estn. EL ROL DE AGENTE DE CAMBIO DEL ANALISTA DE SISTEMAS El rol ms completo y de mayor responsabilidad que asume el analista de sistemas es el de agente de cambio, ya sea interno o externo para la empresa. Como analista, usted es un agente de cambio si desempea cualquiera de las actividades relacionadas con el ciclo de vida del desarrollo de sistemas (que se explicara en la siguiente seccin) y est presente en la empresa durante un largo periodo (de dos semanas a mas de un ao). Un agente de cambio se puede definir como alguien que sirve de catalizador para el cambio, desarrolla un plan para el cambio y coopera con los dems para facilitar el cambio. Su presencia en el negocio inicia el cambio. Como analista de datos, usted debe estar consciente de este hacho y utilizarlo como punto de partida para su anlisis. De ah que tenga que interactuar con los usuarios y la administracin (sino son un o solo y el mismo) desde el principio de su proyecto. Sin su colaboracin usted no podra entender lo que ocurre en una organizacin y el cambio real nunca se dara. Si el cambio (es decir, la mejora al negocio que se pueden concretar mediante los sistemas de informacin) parece factible despus de efectuar el anlisis, el siguiente paso es desarrollar un plan para el cambio de manera conjunta con quienes tienen la facultad de

autorizarlo. Una vez que se haya alcanzado el consejo acerca de los cambios por realizar, usted tendr que interactuar constantemente con quienes hayan a cambiar. En su calidad de analista de sistema desempeando la funcin de agente de cambio, debe promover un cambio que involucre el uso de los sistemas de informacin. Tambin es parte de su tarea ensear a los usuarios el proceso del cambio, ya que las modificaciones a un sistema de informacin no slo afectan a ste sino que provocan cambios en el resto de la organizacin. CICLO DE VIDA DEL DESARROLLO DE SISTEMAS El anlisis y diseo de sistemas es un procedimiento para la resolucin de problemas. Cuando se trata del diseo de sistemas de informacin, busca analizar sistemticamente la entrada o flujo de datos, la transformacin de los datos, el almacenamiento de datos y la salida de informacin en el contexto de una organizacin particular. Tambin es usado para analizar, disear e implementar mejoras que puedan incorporarse a la organizacin y puedan ser alcanzadas al usar un sistema de informacin computarizado. Este procedimiento se lleva a cabo, en el llamado ciclo de vida de desarrollo de sistemas, el cual consta de seis pasos que permiten el diagnstico y optimizacin de un sistema de informacin. Este ciclo puede repetirse indefinidamente, porque como ya se seal, las organizaciones siempre se ven sometidas a cambios, y sus sistemas deben renovarse peridicamente. Los pasos del ciclo de vida de desarrollo son los que se encuentran en la imagen. Se suele llamar analistas de sistemas a quienes se encargan de realizar en las empresas, el proceso de anlisis y diseo de sistemas, definiendo los lineamientos a seguir y la manera en que debe incorporarse la tecnologa de la computacin para adecuar y actualizar sus sistemas de informacin FASES DEL CICLO DE VIDA DEL DESARROLLO DE SISTEMAS A continuacin se trata con ms detalle cada una de las fases de la metodologa con la finalidad de aclarar de qu se trata cada una de ellas. 1. INVESTIGACIN PRELIMINAR La primera fase tiene que ver con la identificacin de problemas, oportunidades y objetivos. Es muy valiosa y debe ser asumida con prudencia y atencin, porque de ella depende el resto del proyecto. La definicin correcta del problema evitar desperdiciar el tiempo en un problema equivocado. Requiere de la observacin minuciosa del funcionamiento de la organizacin, usando las sugerencias de los usuarios potenciales del sistema y de los dems miembros de la organizacin, para resaltar los problemas que ellos probablemente ya han detectado.

Esta fase regularmente obedece a la solicitud planteada por un usuario final o encargado de algn rea operativa, como un gerente, que no ve resuelto sus necesidades de informacin en la situacin actual. Estos nuevos requerimientos dan origen a un estudio que estar constituido por tres tareas sucesivas: Una breve definicin del problema; sugerencia de posibles soluciones; elaboracin de un reporte breve. Este ltimo permite a quien dirija la organizacin tomar la decisin de asumir o no el proyecto. La definicin del problema conlleva el estudio del sistema de informacin que se encuentra en uso. Se trata de determinar qu informacin se requiere y quines, cundo y por qu la necesitan llevando a cabo entrevistas con los involucrados y realizando observaciones. As, la propuesta de posibles soluciones consiste en sugerir planes alternativos de solucin en base a la informacin recabada. Esto puede ir, desde proponer una nueva organizacin de trabajo, hasta hacer cambios al sistema computarizado que existe, desarrollar un nuevo sistema computarizado o elegir un nuevo software comercial que se adapte a las necesidades encontradas. Entonces, se procede a la redaccin de un reporte que resuma los resultados de la investigacin previa, que sugiera las posibles soluciones o indique si se detecta que es innecesario continuar con el proyecto. Podra incluir incluso un plan de trabajo en caso de que el proyecto continuara. En base a este documento, los directivos tomarn su decisin de continuar o no. 2.- ANLISIS Esta fase se ocupa de la reunin y estudio a detalle de los datos del sistema en operacin y la especificacin de los nuevos requerimientos del sistema a desarrollar. Concluye en general con un documento que recoge el resultado del anlisis. Con la recopilacin de datos se complementan los datos resultantes de la fase 1, aadiendo detalles sobre el sistema actual. Son medios comunes para acometer tal recopilacin as entrevistas, cuestionarios, encuestas a usuarios finales, as como tambin, las consultas a documentos y manuales que contengan lineamientos de funcionamiento o normas de procedimientos de operacin. Ya recopilados, los datos son analizados para establecer cmo es el flujo de informacin y detectar la posible causa de que este flujo sea defectuoso. Se trata de evaluar el flujo de informacin en la organizacin para determinar si es realmente el adecuado. Es frecuente que el funcionamiento inadecuado tenga su origen en no llevar a cabo los procedimientos correctamente. Si este es el caso, bastara entonces con entrenar al personal para ceirse

apropiadamente a las normas y a los procedimientos, siendo innecesario redisear o crear un nuevo sistema. Existen varias tcnicas y herramientas tiles para el anlisis de datos. Una de stas es el uso de diagramas de flujo de datos para diagramar la entrada, proceso y salida de las funciones de la organizacin de manera grfica. Estos diagramas sirven para desarrollar el llamado diccionario de datos, el cual contiene la definicin de los datos usados en el sistema, as como sus caractersticas de tipo, tamao, limitaciones o especificaciones especiales. La documentacin de la etapa de anlisis recoge la descripcin del sistema de informacin en uso, los requerimientos para el nuevo sistema y un probable plan de desarrollo en un reporte dirigido a la gerencia. Este reporte permite tomar la decisin de proseguir o no con el proyecto. 3.- DISEO En esta fase se delinea el nuevo sistema de informacin. Se compone de tres tareas que son: diseo de sistemas alternativos, seleccin del mejor sistema, y la consiguiente redaccin del reporte del diseo. Casi siempre podr desarrollarse ms de un diseo que cubra las necesidades de informacin. Debe ser determinada la factibilidad de cada una de las alternativas. La factibilidad aqu referida tiene que ver con tres aspectos: Factibilidad econmica: Verificar si los costos del nuevo sistema son justificados por los beneficios que ofrecer. Factibilidad tcnica: Establecer si se va a contar con el hardware, software y personal necesarios para llevar a cabo el proyecto. Factibilidad operativa: Determinar si el nuevo sistema podr operar en la organizacin, siendo aceptado por los usuarios de todo nivel, o si por el contrario habr una resistencia insuperable al cambio. Para elegir el diseo adecuado, los directivos van a evaluar bsicamente si el sistema cumple con los siguientes aspectos: a) Se adaptar al sistema general de informacin de la organizacin. b) Tendr flexibilidad para aceptar modificaciones futuras. c) Ofrece seguridad contra el uso no autorizado. d) Los beneficios obtenidos valen ms que los costos. El reporte correspondiente a esta fase describe los diseos alternativos, comparando sus costos y beneficios y un esbozo de sus efectos en la organizacin. Es conveniente

recomendar una de las alternativas, la ms adecuada, basndose en las comparaciones de los mismos. 4.- DESARROLLO Durante esta fase los programadores pueden jugar un papel de importancia al crear o personalizar el software que formar el sistema. Esta fase consiste de las tareas de desarrollo del software, adquisicin de hardware y prueba del nuevo sistema. En realidad el software de aplicacin para el nuevo sistema de informacin puede conseguirse de dos formas alternativas. Es posible adquirir un paquete comercial que cumpla las expectativas o que incluso pueda ser modificado o adaptado. Si no es posible conseguirlo, se har necesario elaborar uno a la medida. La elaboracin de software sigue una serie de pasos que se describen en el tema sobre Programacin. Si se opta por desarrollar un sistema a la medida, seguramente adems del analista se encontrarn involucrados un grupo de programadores. El analista comunica a los programadores lo que requiere ser programado, entonces estos disean, codifican y depuran los componentes de software del sistema. El trabajo del analista tambin involucra a los usuarios, para quienes deber desarrollar y suministrar documentacin, como los manuales de procedimientos. Tal documentacin explica al usuario cmo usar el software desarrollado y qu hacer en caso de que se presenten problemas La adquisicin de hardware o nuevos equipos no siempre es requerida, si los equipos con los que se cuenta son adecuados. En otro caso, debe preverse las caractersticas de los mismos y el lugar donde sern instalados. El cambio de equipos puede representar un gran costo, por lo que se debe pensar cuidadosamente en cuestiones como: si el mismo ser til al crecer la organizacin; en el caso de las redes, si podrn ampliarse sin problemas; si se requerir someter al personal a capacitacin costosa para poder usarlo. Se procede a la prueba del sistema una vez instalados el software y el hardware usando datos de muestra. La informacin que se obtiene tras procesar los datos en el sistema, se evala para acreditar que los resultados son correctos. En el perodo de prueba los usuarios que lo utilizan pueden hacer observaciones valiosas para afinar el sistema haciendo las correcciones pertinentes. 5.- IMPLEMENTACIN En la fase de implementacin se instala el nuevo sistema de informacin para que empiece a trabajar y se capacita a sus usuarios para que puedan utilizarlo. Pero la instalacin puede realizarse segn cuatro mtodos: Directo, paralelo, piloto y en fases. Veamos en qu se diferencian estos mtodos:

 Mtodo directo: Se abandona el sistema antiguo y se adopta inmediatamente el nuevo. Esto puede ser sumamente riesgoso porque si algo marcha mal, es imposible volver al sistema anterior, las correcciones debern hacerse bajo la marcha. Regularmente con un sistema nuevo suelen surgir problemas de pequea y gran escala. Si se trata de grandes sistemas, un problema puede significar una catstrofe, perjudicando o retrazando el desempeo entero de la organizacin. Mtodo paralelo: Los sistemas de informacin antiguo y nuevo operan juntos hasta que el nuevo demuestra ser confiable. Este mtodo es de bajo riesgo. Si el sistema nuevo falla, la organizacin puede mantener sus actividades con el sistema antiguo. Pero puede representar un alto costo al requerir contar con personal y equipo para laborar con los dos sistemas, por lo que este mtodo se reserva especficamente para casos en los que el costo de una falla sera considerable. Mtodo piloto: Pone a prueba el nuevo sistema slo en una parte de la organizacin. Al comprobar su efectividad, se implementa en el resto de la organizacin. El mtodo es menos costoso que el paralelo, aunque ms riesgoso. Pero en este caso el riesgo es controlable al limitarse a ciertas reas, sin afectar toda la empresa. Mtodo en fases: La implementacin del sistema se divide en partes o fases, que se van realizando a lo largo de un periodo de tiempo, sucesivamente. Una vez iniciada la primera fase, la segunda no se inicia hasta que la primera se ha completado con xito. As se contina hasta que se finaliza con la ltima fase. Es costoso porque se hace ms lenta la implementacin, pero sin duda tiene el menor riesgo. Los mtodos piloto y en fases suelen ser los ms practicados puesto que tienen menor riesgo. Como se puede observar la decisin de adoptar cualquiera de los mtodos estar influenciada por factores de riesgo y disponibilidad de recursos. Otro aspecto importante de esta fase es la capacitacin del personal, que cobra especial importancia para asegurar el uso acertado del sistema. Se puede adelantar camino al capacitar personal, antes incluso de contar con los equipos nuevos, para que el usuario se familiarice con el nuevo sistema. Si el sistema es sencillo y el usuario tiene cierta experiencia, la capacitacin formal no se hace necesaria y bastarn algunas instrucciones para ponerle al tanto. 6.- MANTENIMIENTO Al finalizar la fase de implementacin comienza la fase de mantenimiento. Es la fase final, de gran importancia como se demostrar a continuacin, y es una fase permanente en lo que le resta de vida al sistema. El mantenimiento se inicia con una auditoria del sistema y luego contina con evaluaciones peridicas. Al realizar la auditoria del nuevo sistema, se verifica que su desempeo sea acorde a las especificaciones planteadas en la fase de diseo, para

comprobar que los procesos que han sido integrados, efectivamente son los adecuados. En caso contrario, se hace necesario un nuevo diseo para ajustar los inconvenientes detectados. Las evaluaciones peridicas permiten determinar, si el sistema contina vigente respecto a su capacidad para realizar los procesos adecuadamente. En caso contrario, se requiere de nuevos ajustes, cambios o modificaciones que le permitan al sistema adaptarse a nuevas situaciones de las que pueda ser objeto la organizacin. En este punto es bueno resaltar, que las organizaciones son entes cambiantes, as mismo sus sistemas componentes y especficamente los sistemas de informacin, los cuales debern ser sensibles a estos cambios, mediante evaluacin, para adecuarlos a responder efectivamente a las situaciones emergentes. HERRAMIENTAS CASE De acuerdo con Kendall y Kendall la ingeniera de sistemas asistida por ordenador es la aplicacin de tecnologa informtica a las actividades, las tcnicas y las metodologas propias de desarrollo, su objetivo es acelerar el proceso para el que han sido diseadas, en el caso de CASE para automatizar o apoyar una o mas fases del ciclo de vida del desarrollo de sistemas. Cuando se hace la planificacin de la base de datos, la primera etapa del ciclo de vida de las aplicaciones de bases de datos, tambin se puede escoger una herramienta CASE (Computer-Aided Software Engineering) que permita llevar a cabo el resto de tareas del modo ms eficiente y efectivo posible. Una herramienta CASE suele incluir: Un diccionario de datos para almacenar informacin sobre los datos de la aplicacin de bases de datos. Herramientas de diseo para dar apoyo al anlisis de datos. Herramientas que permitan desarrollar el modelo de datos corporativo, as como los esquemas conceptual y lgico. Herramientas para desarrollar los prototipos de las aplicaciones. El uso de las herramientas CASE puede mejorar la productividad en el desarrollo de una aplicacin de bases de datos. HISTORIA En la dcada de los setenta el proyecto ISDOS desarroll un lenguaje llamado "Problem Statement Language" (PSL) para la descripcin de los problemas de usuarios y las necesidades de solucin de un sistema de informacin en un diccionario computarizado.

Problem Statement Analyzer (PSA) era un producto asociado que analizaba la relacin de problemas y necesidades. Pero la primera herramienta CASE como hoy la conocemos fue Excelerator en 1984, era para PC. Actualmente la oferta de herramientas CASE es muy amplia y tenemos por ejemplo el EASYCASE o WINPROJECT. (Monografas.com) TECNOLOGA CASE La tecnologa CASE supone la automatizacin del desarrollo del software, contribuyendo a mejorar la calidad y la productividad en el desarrollo de sistemas de informacin y se plantean los siguientes objetivos: Permitir la aplicacin prctica de metodologas estructuradas, las cuales al ser realizadas con una herramienta se consigue agilizar el trabajo. Facilitar la realizacin de prototipos y el desarrollo conjunto de aplicaciones. Simplificar el mantenimiento de los programas. Mejorar y estandarizar la documentacin. Aumentar la portabilidad de las aplicaciones. Facilitar la reutilizacin de componentes software. Permitir un desarrollo y un refinamiento visual de las aplicaciones, mediante la utilizacin de grficos. Automatizar: El desarrollo del software La documentacin La generacin del cdigo El chequeo de errores La gestin del proyecto

Permitir: La reutilizacin del software La portabilidad del software La estandarizacin de la documentacin

COMPONENTES DE UNA HERRAMIENTA CASE De una forma esquemtica podemos decir que una herramienta CASE se compone de los siguientes elementos: Repositorio (diccionario) donde se almacenan los elementos definidos o creados por la herramienta, y cuya gestin se realiza mediante el apoyo de un Sistema de Gestin de Base de Datos (SGBD) o de un sistema de gestin de ficheros. Meta modelo (no siempre visible), que constituye el marco para la definicin de las tcnicas y metodologas soportadas por la herramienta. Carga o descarga de datos, son facilidades que permiten cargar el repertorio de la herramienta CASE con datos provenientes de otros sistemas, o bien generar a partir de la propia herramienta esquemas de base de datos, programas, etc. que pueden, a su vez, alimentar otros sistemas. Este elemento proporciona as un medio de comunicacin con otras herramientas. Comprobacin de errores, facilidades que permiten llevar a cabo un anlisis de la exactitud, integridad y consistencia de los esquemas generados por la herramienta. Interfaz de usuario, que constar de editores de texto y herramientas de diseo grfico que permitan, mediante la utilizacin de un sistema de ventanas, iconos y mens, con la ayuda del ratn, definir los diagramas, matrices, etc. que incluyen las distintas metodologas. ESTRUCTURA GENERAL DE UNA HERRAMIENTA CASE La estructura CASE se basa en la siguiente terminologa: CASE de alto nivel son aquellas herramientas que automatizan o apoyan las fases finales o superiores del ciclo de vida del desarrollo de sistemas como la planificacin de sistemas, el anlisis de sistemas y el diseo de sistemas. CASE de bajo nivel son aquellas herramientas que automatizan o apoyan las fases finales o inferiores del ciclo de vida como el diseo detallado de sistemas, la implantacin de sistemas y el soporte de sistemas. CASE cruzado de ciclo de vida se aplica a aquellas herramientas que apoyan actividades que tienen lugar a lo largo de todo el ciclo de vida, se incluyen actividades como la gestin de proyectos y la estimacin.

ESTADO ACTUAL En las ltimas dcadas se ha trabajado en el rea de desarrollo de sistemas para encontrar tcnicas que permitan incrementar la productividad y el control de calidad en cualquier proceso de elaboracin de software, y hoy en da la tecnologa CASE (Computer Aided Software Engineering) reemplaza al papel y al lpiz por el ordenador para transformar la actividad de desarrollar software en un proceso automatizado. La tecnologa CASE supone la informatizacin de la informtica es decir la automatizacin del desarrollo del software, contribuyendo as a elevar la productividad y la calidad de en el desarrollo de los sistemas de informacin de forma anloga a lo que suponen las tcnicas CAD/CAM en el rea de fabricacin. En este nuevo enfoque que persigue mejorar la calidad del software e incrementar la productividad en el proceso de desarrollo del mismo, se plantean los siguientes objetivos: Permitir la aplicacin prctica de metodologas, lo que resulta muy difcil sin emplear herramientas. Facilitar la realizacin de prototipos y el desarrollo conjunto de aplicaciones. Simplificar el mantenimiento del software. Mejorar y estandarizar la documentacin. Aumentar la portabilidad de las aplicaciones. Facilitar la reutilizacin de componentes de software Permitir un desarrollo y un refinamiento (visual) de las aplicaciones, mediante la utilizacin de controles grficos (piezas de cdigo reutilizables). Clasificacin de las herramientas case No existe una nica clasificacin de herramientas CASE y, en ocasiones, es difcil incluirlas en una clase determinada. Podran clasificarse atendiendo a: - Las plataformas que soportan. - Las fases del ciclo de vida del desarrollo de sistemas que cubren. - La arquitectura de las aplicaciones que producen. - Su funcionalidad.

CASE es una combinacin de herramientas software (aplicaciones) y de metodologas de desarrollo : 1. Las herramientas permiten automatizar el proceso de desarrollo del software. 2. Las metodologas definen los procesos automatizar. Una primera clasificacin del CASE es considerando su amplitud : TOOLKIT: es una coleccin de herramientas integradas que permiten automatizar un conjunto de tareas de algunas de las fases del ciclo de vida del sistema informtico: Planificacin estratgica, Anlisis, Diseo, Generacin de programas. WORKBENCH: Son conjuntos integrados de herramientas que dan soporte a la automatizacin del proceso completo de desarrollo del sistema informtico. Permiten cubrir el ciclo de vida completo. El producto final aportado por ellas es un sistema en cdigo ejecutable y su documentacin. Una segunda clasificacin es teniendo en cuenta las fases (y/o tareas) del ciclo de vida que automatizan: UPPER CASE: Planificacin estratgica, Requerimientos de Desarrollo Funcional de Planes Corporativos. MIDDLE CASE: Anlisis y Diseo. LOWER CASE: Generacin de cdigo, test e implantacin INGENIERA INVERSA Y REINGENIERIA DE SOFTWARE La ingeniera inversa y la reingeniera de software son mtodos para alargar la vida de programas anteriores, conocidos como software heredado. En ambos mtodos se emplea software de reingeniera asistida por computadora (CARE, Computer-Assisted Reengineeringj para analizar y reestructurar el cdigo de computadora existente. En el mercado hay varios conjuntos de herramientas de ingeniera inversa. Observe que el trmino reingeniera se utiliza en numerosos contextos diferentes de ingeniera, programacin y negocios. Con frecuencia se emplea para denotar "reingeniera de procesos de negocios", que es una forma de darle una nueva orientacin a los procesos clave de una organizacin. Los analistas de sistemas pueden desempear un rol importante en la reingeniera de procesos de negocios, puesto que muchos de los cambios requeridos slo se pueden lograr mediante el uso de tecnologa de informacin novedosa. La ingeniera inversa es lo opuesto a la generacin de cdigo. El cdigo fuente de la computadora es examinado, analizado y convertido en entidades para el depsito. El primer paso de la ingeniera inversa de software es cargar, en el conjunto de herramientas, el

cdigo de programa existente (tal como se haya escrito en COBOL, C o cualquier otro lenguaje de alto nivel). Segn el conjunto de herramientas de ingeniera inversa que se utilice, el cdigo es analizado y las herramientas producen algunos o todos los elementos siguientes: 1. Estructuras de datos y elementos que describen los archivos y registros almacenados por el sistema. 2. Diseos de pantallas, si el programa es en lnea. 3. Esquemas de informes para programas por lotes. 4. Un diagrama de estructura que muestra la jerarqua de los mdulos del programa. 5. y relaciones de bases de datos. El diseo almacenado en el depsito podra modificarse o incorporarse en informacin de otro proyecto CASE. Cuando se terminan todas las modificaciones, el nuevo cdigo del sistema puede volver a generarse. La reingeniera se refiere al proceso completo de convertir el cdigo de programa al diseo CASE, modificar el diseo y volver a generar el nuevo cdigo de programa. Son varias las ventajas que se consiguen al utilizar un conjunto de herramientas de ingeniera inversa: Reduccin del tiempo requerido para el mantenimiento del sistema, con lo cual queda ms tiempo para nuevos desarrollos. Se genera documentacin, que podra haber sido inexistente o mnima en los programas anteriores. Se crean programas estructurados a partir de cdigo de computadora no estructurado o pobremente estructurado. Los cambios futuros al mantenimiento son ms sencillos, porque se pueden realizar al nivel del diseo ms que al nivel del cdigo. Es posible analizar el sistema con el fin de eliminar porciones sin utilizar de cdigo de computadora, el cual an podra estar presente en programas anteriores a pesar de que las revisiones hechas al programa a lo largo de los aos lo hayan vuelto obsoleto

ESTILOS ORGANIZACIONALES Y SU IMPACTO SOBRE LOS SITEMAS DE INFORMACIN LA INFORMACION COMO UN RECURSO DE LAS ORGANIZACIONES Las organizaciones para lograr sus objetivos, requieren de una diversidad de recursos, elementos o medios que les permitan un rendimiento eficiente. Estos recursos se presentan bajo diferentes caractersticas por ejemplo: la forma de poder vender eficientemente los bienes o servicios; la oportunidad de poder darle solucin a los problemas en el menor tiempo posible; que la organizacin logre tener satisfechas las demandas salariales y su personal, por tanto la administracin de recursos humanos, financieros, materiales y tcnicos deben ser manejados eficientemente. De estos recursos organizacionales por objeto de estudio nos interesan los recursos tcnicos que son todos aquellos medios informativos que proporcionan orientacin para desarrollar soluciones, quedan comprendidas dentro de ellas: los sistemas de produccin, la tecnologa que la orienta, los procesos de produccin, el mantenimiento, el desarrollo tcnico, los sistemas y procedimientos administrativos, los sistemas de ventas, los sistemas de promocin. Si la informacin es considerada como un recurso es importante que se gestione como tal, ms an, cuando se considere estratgico, por el hecho de ser una poderosa arma en la toma de decisiones a cualquier nivel. En el caso particular de la informacin, el hecho de considerarla como un producto implica remarcar lo siguiente: Las empresas dedican una parte importante de su tiempo y de sus recursos (econmicos y humanos) a la obtencin, proceso, aplicacin y proyeccin de la informacin. La informacin debe considerarse como patrimonio de la empresa en su conjunto y, por consiguiente se debe establecer un mecanismo de planificacin y coordinacin. La informacin es costosa debido a la formacin de las personas, la adquisicin de software, la acumulacin de experiencias, etc.

La informacin presenta una serie de caractersticas que impiden tratarla como un bien, al menos en el sentido tradicional del trmino:Resulta difcil dividir la informacin en partes claramente diferenciadas.

La informacin puede ser transportada instantneamente de un lugar a otro del mundo.

 Un individuo que posee una informacin no la pierde aunque la transmita a otra persona. Es decir, la informacin no es apropiable sino que se automultiplica. El hombre no consume informacin sino que la crea constantemente. En este sentido, los recursos de la informacin sern inagotables mientras dure la humanidad. La informacin no se gasta o consume con el uso, sino que incluso mejora cuando se la utiliza (los datos se convierten en informacin, la informacin en conocimiento, los conocimientos en inteligencia) Es decir, la informacin no se devala con el uso. La evolucin en el tiempo del valor de la informacin es difcilmente previsible: una informacin puede tener un valor extraordinario en un da y no tener valor alguno al siguiente. El valor de la informacin depende de quien la use. Una misma informacin puede ser de gran valor para una persona y de ningn valor para otra. No hay una forma objetiva de asignarle valor a la informacin ya que el valor lo da el sujeto con sus necesidades concretas en un determinado momento: por lo general, el sujeto percibe el valor de la informacin como el costo de no disponer de ella. Para que el sujeto al que va dirigida una informacin pudiera estimar su valor (es decir, pudiera evaluar si satisface sus necesidades) se le debera desvelar la informacin

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. Las organizaciones son sistemas grandes compuestos de subsistemas interrelacionados. Los subsistemas son relacionados por tres amplios niveles de administradores que toman decisiones (operacin, administracin media y administracin estratgica) y que cortan horizontalmente a travs del sistema organizacional. Las culturas y subculturas organizacionales influencian la manera en que se interrelaciona la gente en los subsistemas. LA ORGANIZACIN COMO SISTEMAS Es conveniente concebir a las organizaciones como sistemas diseados para el cumplimiento de metas y objetivos especcos mediante el empleo de diversos recursos, incluyendo el factor humano. Las organizaciones se integran colmo pequeos sistemas interrelacionados (departamentos, unidades, reas. Etc.), las cuales realizan funciones especializadas (Contabilidad, Personal, etc.). Al concebir a las organizaciones como sistemas complejos, podemos aplicar los principios de sistemas para discernir sobre su funcionamiento. Se la debe contemplar como un todo, para establecer correctamente los requerimientos de informacin, y de esamanera, disear

el sistema de informacin apropiado. Todo sistema esta constituido por subsistemas ms pequeos (incluyendo al sistema de informacin ); de manera que cuando estudiamos a una organizacin , tambin estamos examinado las relaciones y el funcionamiento de los sistemas menores. Todos los sistemas y subsistemas se encuentran interrelacionados y son interdependientes (TS). Cuando uno de los elementos de un sistema cambia o se elimina, el resto de los elementos del sistema y subsistemas asociados tambin se afectan. Otra de las caractersticas de las organizaciones con respecto a los sistemas, es la frontera que las separa de su medio ambiente. Los limite pueden ser, de manera continua, desde muy permeables hasta llegar a ser casi impermeables. Para adaptarse las organizaciones tienen la necesidad de recurrir a gente, materias primas e informacin a trabes de sus limites y de intercambiar sus productos terminados, servicios o informacin hacia el mundo externo. Pero peligrara su desempeo y competitividad si los limites se encuentran demasiados relajados. La retroalimentacin es un mecanismo para el control de un sistema. Como sistemas, todas las organizaciones utilizan la planeacin y el control para administrar los recursos. Las organizaciones reciben una retroalimentacin tanto del interior como del exterior (ambiente). Los conceptos de apertura y cerradura interna en las organizaciones coexisten de manera paralela, pues no hay algo tal como una organizacin absolutamente abierta o cerrada. La apertura se refiere al flujo libre de informacin dentro de la organizacin. Lo opuesto, es el concepto de cerradura. El enfoque de sistemas permite al analista ver y entender con amplitud las diferentes empresas con las cuales mantendr contacto. NIVELES DE ADMINISTRACIN Los tres niveles de administracin de las organizaciones son: el control operativo; la planeacin el control operativo y la direccin estratgica. Cada nivel tiene sus propias responsabilidades, y con base en sus caractersticas, colabora en el logro de las metas y objetivos de la organizacin. 1) ADMINISTRACIN DE OPERACIONES Ocupa la base de la pirmide. Los gerentes de operaciones apoyan sus decisiones en reglas preestablecidas, las cuales al implantarse en forma correcta se obtienen resultados preestablecidos. Manejan una alta certidumbre y sus decisiones afectan la implantacin de los programas de trabajo, el control de inventario, embarques, control de procesos, etc. Los gerentes de operaciones supervisan los detalles operativos, verificando las tareas rutinarias. 2) ADMINISTRACIN MEDIA

Los gerentes de mandos intermedios toman decisiones sobre la planeacin y el control a corto plazo, y de la forma de asignar recursos, al cumplir con las metas de la organizacin. Toman decisiones en ambientes de baja certidumbre y son de muy diversa naturaleza. Por ejemplo; desde pronosticar recursos hasta resolver conictos con el personal. El dominio de su toma de decisiones se puede caracterizar por tener cierto contenido operativo y estratgico, con fluctuaciones. 3) ADMINISTRACIN ESTRATGICA Los gerentes de logstica se ubican mas all de las fronteras de la organizacin, en el tiempo o en el espacio. Su toma de decisiones conducir a los gerentes de los otros niveles. Actan bajo gran incertidumbre. Mediante los postulados de metas y el establecimiento de estrategias y de polticas para su logro, los gerentes de logstica definen a la organizacin como un todo. El contexto donde se mueven es por ejemplo: en definir nuevas lneas de productos, fusin de la organizacin, quiebra y liquidacin de la organizacin, etc. CULTURA ORGANIZACIONAL La cultura organizacional es un rea de investigacin que ha crecido de manera notable en la ltima generacin. As como es correcto considerar que las organizaciones dan cabida a muchas tecnologas, tambin es conveniente considerarlas como receptculos de mltiples subculturas, que con frecuencia compiten entre s. An no hay un consenso sobre la definicin precisa de lo que constituye una subcultura organizacional. Sin embargo, s hay consenso en que las subculturas podran entrar en conflictos y competir para ganar adeptos a su visin de lo que debera ser la organizacin. Actualmente se realizan estudios para determinar los efectos de las organizaciones virtuales y los equipos virtuales en la creacin de subculturas cuando los miembros no comparten un espacio de trabajo fsico pero s comparten tareas. En lugar de ver a la cultura como un todo, es ms til considerar los factores determinantes de las subculturas, como los simbolismos verbales y no verbales compartidos. Los simbolismos verbales incluyen el lenguaje compartido para construir, transmitir y preservar los mitos, metforas, visiones y estados de nimo de las subculturas. Los simbolismos no verbales incluyen objetos, ritos y ceremonias compartidos; la vestimenta de los encargados de la toma de decisiones y de los trabajadores; el uso, ubicacin y decoracin de las oficinas, y la forma de celebrar los cumpleaos, promociones y jubilaciones de los miembros. Las subculturas coexisten dentro de las culturas "oficiales" de la organizacin. La cultura oficial aprobada podra establecer una forma de vestir, formas apropiadas de dirigirse a los superiores y a los compaeros, as como la manera ms conveniente de tratar al pblico. Las subculturas se podran constituir en factores determinantes de los requerimientos,

disponibilidad y uso de la informacin. Los miembros de la organizacin podran pertenecer a una o ms subculturas. Estas ltimas podran ejercer una fuerte influencia en el comportamiento de los miembros, incluyendo castigos por o contra el uso de los sistemas de informacin. La comprensin e identificacin de las subculturas que predominan en una organizacin podra ayudar al analista de sistemas a superar la resistencia al cambio que surge al instalar un nuevo sistema de informacin. Por ejemplo, el analista podra planear la capacitacin de usuarios para resolver problemas especficos de las subculturas de la organizacin. La identificacin de las subculturas tambin podra ser til para disear sistemas de apoyo a la toma de decisiones adecuados para interactuar con grupos especficos de usuarios. DETERMINACION DE LA FACTIBILIDAD Y MANEJO DE ACTIVIDADES DE ANALISIS FUNDAMENTOS DEL PROYECTO: Un proyecto de sistemas que se inicia en una empresa tiene problemas y oportunidades de mejora dentro de un negocio, que frecuentemente se presentan conforme la organizacin se adapta a los cambios. Los cambios que requieren deuna solucin de sistemas se presentan tanto en crculos legales como en los industriales. Tan pronto surge el inters por un proyecto, el analista de sistemas se rene con quienes toman las decisiones y colabora para determinarla factibilidad. Si las actividades del proyecto se aprueban para un estudio completo de sistemas, se programaran mediante el uso de instrumentos tales como diagrama de Gantt y las graficas PERT, de tal manera que el proyecto se finalice oportunamente. Una de las acciones ms importantes para garantizar la productividad en el desarrollo del proyecto, es la administracin efectiva de las actividades programadas para los miembros del equipo. INICIO DELPROYECTO Losproyectos surgen de numerosas fuentes diferentes, muchos proyectos sugeridos solo sobrevivirn a algunas etapas de evaluacin, pero otros debern trascender. Generalmente los gerentes consideran los proyectos de sistemas por 2 razones: la experimentacin de problemas que los conduzcan a soluciones con sistemas y la identificacin de oportunidades para mejorar, ambas situaciones surgen conforme la organizacin se va adaptando o enfrentando a los cambios evolutivos naturales. DETERMINACION DELA FACTIBILIDAD

Para los proyectos de sistemas la factibilidad es valorada en tres formas principales: operativo, tcnico y econmico. Un proyecto debe ser factible enlas tres formas para merecer un desarrollo posterior, el estudio de factibilidad no es un estudio de sistema completo. En vez de ello, se usa al estudio de factibilidad para recopilar datos relevantes para la administracin, para que a su vez les permitan tomar una decisin sobre si deben continuar con el estudio de sistema. Los datos para el estudio de factibilidad pueden ser recolectados por medio de entrevistas, estn directamente relacionadas con el problema u oportunidad que est siendo sugerido. Aunque es importante atacar el problema adecuado, no se debe gastar mucho tiempo haciendo estudios de factibilidad, debido a que muchos proyectos sern solicitados y solamente unos cuantos sern ejecutados. El estudio debe ser lo ms conciso posible y altamente comprimido en el tiempo, realizndose varias actividades en un pequeo lapso. PLANEACION Y CONTROL DE LAS ACTIVIDADES El anlisis y diseo de sistemas involucra varias actividades diferentes que juntas forman un proyecto. El analista debe administrar cuidadosamente el proyecto para que llegue a ser exitoso. La administracin de proyectos involucra las tareas generales de planificacin y control. La planificacin incluye todas las actividades requeridas para seleccionar un equipo para anlisis de sistemas, la asignacin de los miembros del equipo a los proyectos adecuados, la estimacin del tiempo requerido para completar cada tarea y la calendarizacin del proyecto para que las tareas sean terminadas en forma ordenada. El control significa, usar la retroalimentacin para monitorear el proyecto y tomar las acciones adecuadas para agilizar o reprogramar las actividades para que terminen a tiempo y motivar a los miembros del equipo para que se termine el trabajo adecuadamente. PLANEACIN DE PROYECTOS BASADAS EN COMPUTADORA El objetivo de la Planificacin del proyecto de Software es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos, costos y planificacin temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de software, y deberan actualizarse regularmente a medida que progresa el proyecto. Adems las estimaciones deberan definir los escenarios del mejor caso, y peor caso, de modo que los resultados del proyecto pueden limitarse. El objetivo de la planificacin se logra mediante un proceso de descubrimiento de la informacin que lleve a estimaciones razonables de recursos costos y planificacin temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo

de un proyecto de software, y deberan actualizarse regularmente medida que progresa el proyecto Dentro de la Planeacion de sistemas el analista debe incluir los siguientes aspectos: Identificacin de elementos clave de los que dependen las aplicaciones como su desarrollo. Descripcin de las relaciones entre estos elementos y la documentacin de las necesidades actuales de informacin o el bosquejo de futuros planes de la empresa. Actividades asociadas a la Planificacin del Proyecto: mbito del Software: En esta etapa evala la funcin y el rendimiento que se asignaron al Software durante la Ingeniera del Sistema de Computadora para establecer un mbito de proyecto que no sea ambiguo, e incomprensible para directivos y tcnicos. Describe la funcin, el rendimiento, las restricciones, las interfaces y la fiabilidad, se evalan las funciones del mbito y en algunos casos se refinan para dar mas detalles antes del comienzo de la estimacin. Las restricciones de rendimiento abarcan los requisitos de tiempo de respuesta y procesamiento, identifican los lmites del software originados por el hardware externo, por la memoria disponible y por otros sistemas existentes. El mbito se define como un pre-requisito para la estimacin y existen algunos elementos que se debe tomar en cuenta como es: La Obtencin de la Informacin necesaria para el software. Para esto el analista y el cliente se renen sobre las expectativas del proyecto y se ponen de acuerdo en los puntos de inters para su desarrollo. RECURSOS: La Segunda tarea de la planificacin del desarrollo de Software es la estimacin de los recursos requeridos para acometer el esfuerzo de desarrollo de Software, esto simula a una pirmide donde las Herramientas (hardware y Software), son la base proporciona la infraestructura de soporte al esfuerzo de desarrollo, en segundo nivel de la pirmide se encuentran los Componentes reutilizables. Y en la parte mas alta de la pirmide se encuentra el recurso primario, las personas (el recurso humano). Cada recurso queda especificado mediante cuatro caractersticas: Descripcin del Recurso. Informes de disponibilidad. Fecha cronolgica en la que se requiere el recurso. Tiempo durante el que ser aplicado el recurso.

Recursos Humanos: La Cantidad de personas requeridas para el desarrollo de un proyecto de software solo puede ser determinado despus de hacer una estimacin del esfuerzo de desarrollo (por ejemplo personas mes o personas aos), y seleccionar la posicin dentro de la organizacin y la especialidad que desempeara cada profesional. Recursos o componentes de software reutilizables: Cualquier estudio sobre recursos de software estara incompleto sin estudiar la reutilizacin, esto es la creacin y la reutilizacin de bloques de construccin de Software. Tales bloques se deben establecer en catlogos para una consulta ms fcil, estandarizarse para una fcil aplicacin y validarse para la tambin fcil integracin. El Autor Bennatan sugiere cuatro categoras de recursos de software que se deberan tener en cuenta a medida que se avanza con la planificacin: Componentes ya desarrollados. Componentes ya experimentados. Componentes con experiencia Parcial. Componentes nuevos. O Recursos de entorno.

El entorno es donde se apoya el proyecto de Software, llamado a menudo entorno de Ingeniera de Software, incorpora Hardware y Software. El Hardware proporciona una plataforma con las herramientas (Software) requeridas para producir los productos que son el resultado de la buena practica de la Ingeniera del Software, un planificador de proyectos debe determinar la ventana temporal requerida para el Hardware y el Software, y verificar que estos recursos estn disponibles. Muchas veces el desarrollo de las pruebas de validacin de un proyecto de software para la composicin automatizada puede necesitar un compositor de fotografas en algn punto durante el desarrollo. Cada elemento de hardware debe ser especificado por el planificador del Proyecto de Software. ADMINISTRACION DE LAS ACTIVIDADES DE ANALISIS Junto con la administracin del tiempo y los recursos, los analistas de sistemas tambin deben administrar gente. La administracin se realiza principalmente mediante una comunicacin precisa con los miembros del equipo que se han seleccionado por su capacidad y compatibilidad. Se deben establecer las metas para la productividad del proyecto, y es necesario motivar a los miembros de los equipos de anlisis de sistemas para que las alcancen. ESTRATEGIAS DE COMUNICACIN PARA ADMINISTRAR EQUIPOS Los equipos tienen su propia personalidad, resultado de la combinacin de cada uno de los miembros individuales del equipo con los dems miembros de una manera que crea una red de interacciones totalmente nueva. Una forma de estructurar la manera en que concibe a los equipos es visualizarlos siempre en una bsqueda constante de equilibrio entre la consecucin de las tareas en turno y el mantenimiento de las relaciones entre los miembros del equipo.

De hecho, por lo regular los equipos tendrn dos lderes, no slo uno. Generalmente una persona se encargar de guiar a los miembros a la consecucin de tareas, y otra se ocupar de las relaciones sociales entre los miembros del grupo. Ambos son necesarios para el equipo. Algunos investigadores han denominado a estos individuos como lder de tareas y lder socioemocional, respectivamente. Todos los equipos padecen las tensiones derivadas de la bsqueda de un equilibrio entre la consecucin de las tareas y el mantenimiento de las relaciones entre los miembros del equipo. Para que contine la eficiencia del equipo, es necesario solucionar continuamente las tensiones. Si se resta importancia a las tensiones o se ignoran, stas conducirn a la ineficiencia y a la desintegracin eventual del equipo. Gran parte de la liberacin de la tensin se puede lograr mediante un uso inteligente de la retroalimentacin por todos los miembros del equipo. Sin embargo, todos los miembros deben estar de acuerdo en que la forma en que interactan (es decir, los procesos) es suficientemente importante para ameritar algn tiempo. Las metas de productividad para los procesos se explican en una seccin posterior. Para garantizar el acuerdo sobre la interaccin apropiada entre los miembros es necesaria la creacin de normas explcitas e implcitas (expectativas, valores y formas de comportamiento colectivos) que guen las relaciones entre los miembros. Las normas son exclusivas de los equipos y no es necesario que se transfieran de un equipo a otro. Estas normas cambian constantemente y es mejor considerarlas como un proceso de interaccin de los equipos y no como un producto. Las normas pueden ser funcionales o disfuncionales. El hecho de que un comportamiento particular sea una norma para un equipo no significa que le ayudar a conseguir sus metas. Por ejemplo, la expectativa de que los miembros ms recientes de un equipo se encarguen de toda la programacin del proyecto podra ser una norma de equipo. Al apegarse a esta norma, el equipo ejercera una fuerte presin sobre los miembros ms nuevos y no aprovechara la experiencia de los dems miembros del equipo. sta es una norma que, de continuar, podra ocasionar que los miembros del equipo desperdiciaran recursos valiosos. Los miembros del equipo necesitan hacer explcitas las normas y evaluar peridicamente si dichas normas son funcionales o disfuncionales para ayudar al equipo a conseguir sus metas. La expectativa ms importante para su equipo debe ser que el cambio es la norma. Pregntese si las normas del equipo estn fomentando u obstaculizando el progreso del equipo. FIJACIN DE LAS METAS DE PRODUCTIVIDAD DEL PROYECTO Cuando ha trabajado con los miembros de su equipo en diferentes tipos de proyectos, usted o el lder de su equipo adquirirn habilidad para proyectar lo que puede conseguir el equipo

en un periodo especfico. Al utilizar las sugerencias descritas en la seccin sobre mtodos para calcular el tiempo requerido y aplicndolas de manera conjunta con la experiencia el equipo podr fijar metas de productividad benficas. Los analistas de sistemas estn acostumbrados a las metas de productividad para empleados que muestran salidas tangibles, tales como el nmero de pantalones vaqueros azules cosidos por hora, el nmero de entradas capturadas por minuto, o el nmero de artculos escaneados por segundo. Sin embargo, conforme se incrementa la productividad en la manufactura, est claro que la productividad del rea administrativa debe incrementarse tambin. Con esta finalidad en mente se fijan las metas de productividad para el equipo de anlisis de sistemas. Es necesario que el equipo formule las metas y est de acuerdo con ellas, y que lo haga con base en la experiencia de todos sus miembros, el desempeo anterior y la naturaleza del proyecto especfico. Las metas variarn un poco para cada proyecto que se emprenda, porque en ocasiones el proyecto consistir en la instalacin de un sistema completo, y en otros casos tal vez slo se realicen algunas modificaciones a una parte de un sistema existente.

CONCLUSION
La informacin se puede considerar como un recurso organizacional. Como tal, se debe manejar con cuidado, al igual que los dems recursos. La disponibilidad de gran poder de cmputo en las organizaciones ha propiciado una explosin de informacin y, en consecuencia, se debe prestar mayor atencin al manejo de la informacin generada Los analistas de sistemas recomiendan, disean y dan mantenimiento a diversos tipos de sistemas. Tambin crean sistemas orientados a la toma de decisiones, como los sistemas de apoyo a la toma de decisiones.

Las herramientas CASE han venido a revolucionar la forma de automatizar los aspectos clave en el desarrollo de los sistemas de informacin, debido a la gran plataforma de seguridad que ofrecen a los sistemas que las usan y es que stas, brindan toda una gama de componentes que incluyen todas o la mayora de los requisitos necesarios para el desarrollo de los sistemas, han sido creadas con una gran exactitud en torno a las necesidades de los desarrolladores de sistemas para la automatizacin de procesos incluyendo el anlisis, diseo e implantacin.
Existen tres aspectos fundamentales de la organizacin que se deben tomar en cuenta al analizar y disear sistemas de informacin: el concepto de organizaciones como sistemas, los diversos niveles de administracin y la cultura general de la organizacin. Las organizaciones son sistemas complejos compuestos de subsistemas interrelacionados e interdependientes. Las culturas y subculturas de una organizacin son factores importantes que determinan la manera como la gente utiliza la informacin y los sistemas de informacin. Al considerar a los sistemas de informacin en el contexto de la organizacin como un sistema ms grande, entenderemos que hay diversos factores importantes que debemos tomar en cuenta al determinar los requerimientos de informacin y disear e implementar sistemas Los cinco aspectos fundamentales de un proyecto que el analista de sistemas debe dominar son: 1) 2) 3) 4) 5) La iniciacin de proyectos, La determinacin de la viabilidad de un proyecto, La planeacin y el control de actividades, La programacin de proyectos y La administracin de los miembros del equipo de anlisis de sistemas. Los proyectos pueden ser solicitados por diversas personas de la organizacin o por los mismos analistas de sistemas.

La seleccin de un proyecto es una decisin difcil, ya que se solicitarn ms proyectos de los que se pueden realizar. Cinco criterios importantes para la seleccin de proyectos son: 1) 2) 3) 4) 5) Que el proyecto solicitado tenga el respaldo de los directivos de la organizacin Que cuente con un periodo adecuado de compromiso para la terminacin del proyecto, Que impulse a la organizacin hacia la consecucin de sus metas, Que sea factible Que tenga la importancia suficiente para darle mayor prioridad que a otros proyectos.

BIBLIOGRAFIA
KENDALL & KENDALL; Anlisis y Diseo de Sistemas; 6ta Edicin; Pearson Educacin. PRESSMAN, Roger S. Ingeniera del Software;4 Edicin; Mc Graw Hill

WHITTEN, Jeffrey. Anlisis y Diseo de Sistemas de Informacin; 3ta Edicin

www.monografias.com www.slideshare.com