Está en la página 1de 11

Analisis y Diseo De Sistemas Kendall Resumen Cap 1 Al 10 CAPITULO 1: ROL DEL ANALISTA DE SISTEMAS Existen diversos tipos de sistemas

en los que el analista trabaja, esto sistemas tienen propsitos diversos, ya que se basan segn a las necesidades de las organizaciones. No todas las organizaciones tienen el mismo fin, ya que en ella los analistas realizan un gran trabajo como el diseo, mantenimiento y a veces dan recomendaciones de sobre que sistemas es el que necesitan. Los sistemas que estos analistas pueden desarrollar se encuentran; los sistemas de procesamiento de transacciones (TPS),sistemas de automatizacin de la oficina(OAS),los sistemas de trabajo del conocimiento(KWS) y los sistemas de informacin gerencial. Tambin se encuentran los sistemas que ayudan a la toma de decisiones (DSS), hay sistemas experto que aplican el conocimiento de los gerentes o encargados de la toma de decisiones para poder dar solucin a problemas muy bien estructurados; los sistemas de apoyo a la toma de decisiones en grupo (GDSS), sistemas de trabajo colaborativo apoyados por computadora (CSCWS) y sistemas de apoyo a ejecutivos [ESS). Muchos de estos sistemas se realizan originalmente en lo que es la web o por otro caso se suben a la web, y as dan apoyo al comercio electrnico, como es la publicidad en lnea de los productos que dichas organizaciones realizan. La realizacin del diseo y el anlisis del sistemas se dice que es un enfoque sistemtico, tal y como los analistas de sistemas lo realizan, esto ayuda a identificar los problemas, oportunidades y objetivos, y as poder analizar el flujo de entrada de los datos, el proceso que se realiza con dichos datos, como tambin su almacenamiento, y salida de la informacin. Base a esto se pueden disear sistemas de informacin computarizada destinados a solucionar este tipo de problema, este debe ser adecuado ya que se puede provocar que el sistema se deje de utilizar en el futuro. El analista tiende a desempear diversos roles, durante el transcurso del trabajo, ya que tiene que evaluar el procesamiento de los datos y la produccin de la informacin, para as poder mejorar los procesos de una organizacin. El analista tiene que tener una gran capacidad de trabajo, ya que tiene que tratar a todo tipo de personas y contar con una gran experiencia en computadoras. En este libro solo trata de explicar los tres principales roles que el analista de sistemas desempea. El rol de consultor externo para el negocio, el rol de experto en soporte tcnico este se realiza dentro de la empresa o negocio, y por el ultimo el rol de agente de cambio este es el mas completo y de mayor responsabilidad de los tres, ya que este abarca la situacin tanto externo como interior para la empresa. El analista tiene que poseer cualidades, para poder desempear cada uno de los roles, ay persona que trabajan como analista pero una descripcin de esta puede quedarse conta en cualquier sentido de la palabra. Ya que estos pueden tener cualidades comnmente iguales; un analista es un solucionador de problemas, ya que a este le encanta el reto de solucionar problemas, no importa lo difcil que sea darle una solucin. Tambin debe de ser un comunicador para tener capacidad de poder relacionarse con las dems personas durante un largo periodo de tiempo. El analista debe de ser autodisciplinada y automotivada, para poder as administrar y coordinar los innumerables recursos de un proyecto en ella tambin van incluido el personal. Gran parte de lo que se vio anteriormente lo incluye el ciclo de vida del desarrollo de sistemas (SDLC). Es un enfoque que se realiza por fases para el anlisis y el diseo. Estas fases pueden ser secuenciales, aunque en realidad estas se interrelacionan y con frecuencia se llevan a cabo de manera simultnea. Las siete fases son: 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; prueba y mantenimiento del sistema, e implementacin y evaluacin del sistema. Unas de las herramientas que es utilizada por los analistas, desde tiempo atrs este se

a beneficiado de esta herramienta denominada como herramienta de ingeniera de software asistida por computadora (CASE). Existen 4 razones para el uso de esta herramienta, la primera es el aumento en la productividad del analista como es Visible Analyst(VA) da la posibilidad de realizar planeaciones, anlisis y diseo, por medio de grficos; la segunda razn es la mejora de la comunicacin analista-usuario durante el ciclo de vida del desarrollo de sistemas; integracin de las actividades del ciclo de vida, en esta tercera razn nos ayuda a dar una continuidad de una fase a la siguiente; y la cuarta y ltima razn es la evaluacin de manera precisa los cambios en el mantenimiento del sistema. La herramienta case puede ser de bajo y alto nivel, en el alto nivel el analista tiene la posibilidad de crear y modificar el diseo de dicho sistema, mientras que en el de bajo nivel solo se utiliza para poder generar cdigo maquina, para as eliminar la necesidad de programar el sistema. Los analistas tambin utilizan la ingeniera inversa y la reingeniera, ambos mtodos se emplea un software de reingeniera asistida por computadora llamada CARE, ya que se utilizan para alargar la vida de los programas vistos anteriormente, conocidos tambin como software heredado. Tambin existe el anlisis y diseo de sistemas orientados a objetos, estos diseos utilizan el lenguaje unificado de modelacin (UML), para as poder analizar los casos de uso. Hay ocasiones en donde el analista dejara de utilizar el SDLC y probara una nueva metodologa. Como es la programacin extrema (XP), este lleva a cabo al limite las practicas de anlisis y diseo. CAPITULO 2.-EL ESTILO ORGANIZACIONAL Y SU IMPACTO EN LOS SISTEMAS DE INFORMACIN. LAS ORGANIZACIONES COMO SISTEMAS Los analistas visualizan a las organizaciones donde elaboran como un sistema el cual esta formado por tres aspectos principales, niveles de administracin, el diseo de las organizaciones y las culturas organizacionales. Esto ayuda analizar y disear sistemas de informacin apropiados. Por otro lado las organizaciones son unos sistemas ms complejos ya que estos estn compuestos de subsistemas interrelacionados e interdependientes que se encargan de funciones especializadas. Unas de las funciones que se pueden decir que son las ms comunes estn la contabilidad, el marketing, la produccin, el procesamiento de datos y la administracin. ENTERRELACIN E INTERDEPENDENCIA DE LOS SISTEMAS La situacin de que todos los sistemas y subsistemas se interrelaciones y sean interdependientes, es de gran importancia en las implicaciones tantos para las organizaciones como para el analista de sistemas que se encarga de realizar que estas consigan de la mejor forma sus metas. El sistema ideal es aquel que corrige y regula por s mismo de tal forma que no se necesario tomar decisiones sobre situaciones comunes. ORGANIZACIONES VIRTUALES Y EQUIPOS VIRTUALES Hoy en da las organizaciones y sus equipos tambin pueden estar organizadas de manera virtual, esto les puede permitir poder hacer cambios a su configuracin para as poderse adaptarse a proyectos cambiantes o a demandas del mercado. Hay beneficios potenciales para la organizacin virtual, entre ellas se encuentran la posibilidad de reducir los costos que se derivan de la instalacin fsica, a responder con ms rapidez las necesidades de los clientes y contribuir que los empleados virtualmente satisfagan sus compromisos familiares. Pero esto aun sigue en investigacin y discusin, para saber que tan importantes son las necesidades de los trabajadores virtuales. ADOPCIN DE UNA PERSPECTIVA DE SISTEMAS Adoptar una perspectiva de sistemas da a los analistas la oportunidad de poder clasificar y as comprender los diversos aspectos con los que se tendrn que enfrentar. Es de gran importancia que los que son pertenecientes de los subsistemas se den

cuenta que su trabajo esta interrelacionado. Ninguno de ellos puede alcanzar su meta sin el otro. PLANEACIN DE RECURSOS EMPRESARIALES: LA ORGANIZACIN COMO SISTEMA Los sistemas de planeacin de recursos empresariales son sistemas de informacin organizacional (empresarial) integrados, desarrollados mediante software comercial personalizado, que ayudan al flujo de informacin entre las reas funcionales de la organizacin. Implementar este sistema puede ser desgastante ya que es difcil de analizar un sistema en uso y luego ajustar el modelo ERP a dicho sistema. Esta labor de redisear tiene el nombre de reingeniera de los procesos de negocios. DESCRIPCIN GRFICA DE SISTEMAS SISTEMAS Y EL DIAGRAMA DE FLUJO DE DATOS DE CONTEXTO Uno de los primeros modelos que se utilizan para la realizacin de graficas, es el diagrama de flujo de datos de contexto o tambin conocida como modelo del entorno. Este se enfoca principalmente en el flujo de los datos que entran y salen del sistema, en el procesamiento de los datos. SISTEMAS Y EL MODELO DE ENTIDAD-RELACIN Este es otro modelo pero este abarca ms la entidad relacin, eso ayuda que el analista pueda definir la fronteras del sistema ms apropiadas. As ayuda que el analista comprenda las entidades y relaciones con las cuales se conforman el sistema organizacional. Una entidad dentro de una organizacin puede ser una persona, un lugar o cosa, y la relacin seria la asociacin que describe la interaccin entre las entidades. Para poder dibujar un diagrama E R existen diversos esquemas con nombres como notacin de pata de cuervo, flecha o bachman. En este libro la que ms se utiliza es la notacin de pata de cuervo. En un diagrama E R se pueden describir diferentes tipos de relacin de uno a uno, uno a muchos, muchos a uno y muchos a muchos. NIVELES DE ADMINISTRACIN La administracin dentro de una organizacin se divide en tres niveles de control: control de operaciones, planeacin y control administrativo, y por ultimo administracin estratgica. Todos esto niveles tienen en si sus propias responsabilidades y se enfocan a su manera en lograr las metas y objetivos que tiene la organizacin estipulada. IMPLICACIONES PARA DEL DESARROLLO DE SISTEMAS DE INFORMACIN Cada uno de los niveles que anteriormente se vieron representa diferentes implicaciones para el desarrollo de sistemas de informacin. El horizonte de tiempo para la toma de decisiones es diferente en cada nivel. En cada una de los niveles se encuentran implicados diferentes personaje para as poder realizar el trabajo en los sistemas de informacin. CULTURA ORGANIZACIONAL Estas son reas de investigacin que ha crecido de manera notable en la ltima generacin. Tanto las culturas y las subculturas son de gran importancia ya que estas determinan la manera en como los usuarios o la gente utilizan la informacin y los sistemas de informacin. En la actualidad se han realizado estudios para poder determinar si las organizaciones y equipos virtuales tienen efectos en la creacin de las subculturas, cuando los integrantes del lugar no compartes el mismo espacio de trabajo pero si comparten tareas. CAPITULO 3: DETERMINACIN DE LA VIABILIDAD Y ADMINISTRACIN DE LAS ACTIVIDADES DE ANLISIS Y DISEO. Existen diferentes fuentes que ayudan a dar inicio a los proyectos de sistemas. Pero algunos de estos proyectos que pueden ser sugeridos pueden sobrevivir hasta llegar a uno o puede no hacerlo. Los ejecutivos de negocios han sugerido los proyectos por 2 razones principales; el primero porque tienen problemas que requiere a una solucin de sistemas y por ltimo porque identifican oportunidades de mejorar mediante la

actualizacin, modificacin, etc. De nuevos sistemas cuando ocurren. A veces existen administradores que no aceptan la realidad de que sus organizaciones tienen muchos problemas, no quieren tratar de hablar con alguien externo al asunto. Al contrario este debe aceptar dichos problemas y encontrarles una solucin. La retroalimentacin es til para poder ver si existe una brecha entre las metas que se han alcanzado y las que todava no. Y as poder resolver los problemas que se han originado. Otros de los puntos es la seleccin de un proyecto, ya que uno tiene que tener en cuenta las razones para as seleccionar un sistema de proyecto que ayude a resolver los problemas. Ya que no es muy fcil tomar esta decisin, tome en cuenta que los diversos subsistemas que se vieron en el capitulo anterior estn interrelacionados y son interdependientes, y que al hacerle cambio a uno de estos puede afectar a los dems. Para poder tomar una buena decisin, a continuacin se le darn 5 criterios existentes especficos para la mejor seleccin de proyectos: 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.( Si algunos de los proyectos que usted haya seleccionado cumple con cada uno de los criterios q ue se vieron en el punto anterior, entonces se puede empezar por realizar el estudio de viabilidad, se debe tambin establecer los objetivos del proyectos que ayudan a la realizacin de los procesos de la viabilidad. Ya que estos tienen aclararse de manera formal, por escrito los objetivos del proyectos y de manera informal a los representantes de dichas organizaciones. La determinacin de recursos, se divide en tres capacidades viabilidad operativa, viabilidad tcnica y viabilidad econmica. Base a este estudio el analista puede ir recolectando informacin til y as facilita a los encargados del manejo se la organizacin la toma de decisin de poder realizar un estudio de sistemas completos. La administracin de proyectos abarca las tareas generales de planeacin y control. En la planeacin se deben incluir las actividades que realiza el analista con una estimacin de tiempo para su realizacin y as se puedan programar para que estas se puedan terminar a tiempo y as garantizar un buen proyecto. Unas de las tantas tcnicas que se utilizan para planear las actividades que se puedan realizar en paralelo es la grafica de Gantt. Este representa en forma de barra cada una de las actividades. Otra de las tcnicas es el uso de diagramas PERT (de Tcnicas de Evaluacin y Revisin de Programas), este programa representa la evaluacin de actividades en forma de una red de nodos y flechas. Este tipo de diagramas ayuda a un analista poder determinar la ruta ms crtica y el tiempo que se llevara, esta es una informacin necesaria para poder controlar con eficiencia un proyecto. Cuando se utiliza un diagrama PERT es importante la precedencia de actividades para la determinacin del tiempo del proyecto. El punto de entrega es un reciente desarrollo en la administracin de proyectos. Este enfoque de punto de entrega (timeboxing) utiliza una fecha de vencimiento absoluta para el proyecto y todo lo que se realice en esa fecha se debe de implementar. Existen otros enfoques para la programacin incluyen PIMs, algunos de estos ejemplos son Microsoft Outlook y Palm Desktop. Estos son tiles ya que sirven para depositar el pago de los nmeros telefnicos y el fax. Despus de a ver administrado el tiempo y los recursos, en pocas palabras despus de que el proyecto se haya clasificado como viable, el analista tambin administra gente. Existen tcnicas para poder lograr la comunicacin en la administracin de equipos. Uno de ellos es comprender la personalidad de cada equipo. Otro punto es la fijacin de las metas de productividad del proyecto, en este el analista est acostumbrado a las metas de los empleados que muestran salidas tangibles en su productividad. Dentro de esta administracin tambin existen otros tipos: Administracin de proyectos con software comercial(COST, Microsoft Word y Access)(

Administracin de proyectos de comercio electrnico( diseo de interfaz a los usuarios) ( Tambin hay que evitar fracasos, para ello hay que involucrarse en la solicitud del proyecto, junto con el estudio de viabilidad, ya que con ello se puede rechazar proyecto que no pueden llevar al fracaso. Los proyectos de prioridad extrema (XP) es un desarrollo de sistemas que aceptan lo que se conoce como buenas practica de desarrollo de sistemas y las lleva el extremo, existen 4 variables que el desarrollador debe tomar en cuenta para poder controlar son: el tiempo, el costo, la calidad y el alcance del proyecto CAPITULO 4: RECOPILACIN DE INFORMACIN: MTODOS INTERACTIVOS En este captulo se describen lo que son loa mtodos interactivos, que quiere decir con interactivo, es tener contacto directo con alguien o con algo. Bueno en libro nos marca como interactivo 3 mtodos que son parte clave de la recopilacin de informacin que el analista de sistemas pueda utilizar. El primero es la entrevista. El libro nos dice que para que podamos entrevistar hay que hacerlo primero con nosotros mismo, para poder ver nuestros errores al momento de entrevistar a alguien. La entrevista es uno de los mtodos interactivo ms conocido por los analistas de sistemas, ya que durante su proceso al entrevistar a un encargado de tomar las decisiones en la organizacin, se puede recopilar informacin de gran importancia, como son las metas, sentimientos, opiniones y los procedimientos informales. La entrevista se realiza mediante un dialogo de preguntas y respuestas entre dos personas, las preguntas se tienen que preparar desde antes no al instante. Un analista se vale de este mtodo para tener una mejor relacin con el cliente, ya que as puede observar con atencin el lugar de trabajo y as poder recopilar una mejor informacin con base a los requerimientos de informacin. Hay cinco pasos que deben realizarse para preparar la entrevista: 1. Leer los antecedentes. 2. Establecer los objetivos de la entrevista. 3. Decidir a quin entrevistar. 4. Preparar al entrevistado. 5. Decidir el tipo de preguntas y la estructura. Las preguntas se clasifican en dos tipos en abiertas y cerradas, en las abierta se permiten utilizar todas las opciones de respuestas posibles, mientras que las cerradas limitan las respuestas. Las entrevista se estructura de tres maneras: En forma de pirmide esta enpiezacon preguntas cerrada y termina con preguntas generales. En embudo inicia con preguntas abiertas y generales y termina con preguntas cerradas. En diamante combina los dos tipos de entrevista. El segundo es el JAD (diseo de conjunto de aplicaciones) Con la ayuda de este mtodo los analistas pueden examinar con eficacia los requerimientos y as disear una interfaz de usuario. Al hacer una cuidadosa evaluacin nos puede ayudar a determinar si el JAD es adecuando utilizarlo en la organizacin. Y por ltimo el cuestionario Los cuestionarios son otra cosa, este ayuda a un analista a recopilar datos sobre otras cosas como son las actitudes, creencias, comportamiento y caractersticas de las personas importantes de la organizacin. Es muy bueno utilizar este mtodo siempre y cuando los integrantes de la organizacin se encuentren en diferentes reas, o lugares geogrficos. Puede ser que no solo una persona sino varias estn involucradas en dicho proyecto, entonces es necesario saber si todo el grupo involucrado a prueba o desaprueba una caracterstica especifica del sistemas que se propuso.Ya que los

objetivos del cuestionarios estn bien establecidos, ya se puede empezar a realizar las preguntas cerradas o abiertas, el vocabulario que se utilice tiene que ser entendible para las personas a las que se les piensa aplicar. CAPITULO 5: RECOPILACIN DE INFORMACIN: MTODOS NO INTRUSIVOS En el tema anterior se vio lo que fueron los mtodos interactivo, esta vez veremos lo contrario, ya que esta manera de recopilar informacin es menos molesta que las otras. Lo mtodos que se vern en este captulo son el muestreo, la investigacin, y la observacin del comportamiento y el entorno fsico donde se desempea la labor del tomador de decisiones. Muestreo El muestreo en si se trata de tomar elementos que represente parte de una poblacin en particular. Se dice que el analista de sistema tiene que tomar encuestas 2 puntos muy importantes a realizar este mtodo, el primero se tiene que tomar encuesta todos los documentos y sitios web que los miembros de la organizacin han realizado, tiene que checar cul de ellos le sirve y cual hay que rechazar. El segundo tiene que ver quines sern ms afectados con la implementacin del sistema que se desarrollara. Existen muchas razones por la cual es necesario el muestreo, ya que el analista tiene que seleccionar una parte representativa de dato o personas que tiene que analizar, ya sea por medio de entrevistas para el caso de las persona. Hay cuatro razones importantes. 1) Reducir costos. Ya que es muy costoso para el analista, andar examinando documento por documento, ms los sitios web. Con el muestro el analista puede ahorrase mucho trabajo, ya solo puede recopilar informacin de un lugar con todos los datos de la poblacin. 2) Acelerar la recopilacin de datos Ayuda a mejorar la efectividad si se puede obtener informacin ms precisa. 3) Mejorar efectividad Hablar con menos empleados, hace que analista tenga tiempo de verificar que no haya perdido o incompletado los datos. 4) Reducir la parcialidad En este punto el analista entrevista al ejecutivo que esta mas involucrado con el sistema. Diseo del muestreo Para tener un buen muestreo el analista tiene que seguir los siguientes 4 pasos: 1) Determinar qu datos van a ser recopilados o descritos 2) Determinar qu poblacin se van a tomar muestra 3) Escoger el tipo de muestra 4) Decidir el tamao de la muestra Investigacin La investigacin es la accin de descubrir y analizar los datos. El analista de sistemas necesita examinar cada punto importante dentro de la organizacin, mediante la exanimacin de datos reales.los datos y formulacin dan a entender a donde ha estado la organizacin y hasta donde se cree que se dirige. Para ello ay que analizar todos los documentos que sean de carcter cuantitativo y cualitativo. En el documento cuantitativo, se incluyen informes usados en la toma de decisiones, informes de desempeo, registros y una variedad de formularios. En el documento cualitativo se incluyen mensajes de correos, memorandos, carteles en los tableros de anuncios y en las reas de trabajo entre otros documentos. Estos documentos son muy detallados. Observacin La observacin es una de los mtodos mas sencillos en el se observan muchas cosas importante,ya que este nos da una mejor idea de lo que realmente se hace en la organizacin, o sea que ve como se realizan todos y cada uno de los procesos que se

realizan. En ello se identifican los actores principales en la toma de decisiones, utilizando un guion del analista. Otro punto importante dentro del mtodo de la observacin es la estructura del entorno del tomador de decisiones, llamado STROBE. Se pueden observar e interpretar algunos elementos concretos en el entorno del tomador de decisiones. Estos elementos incluyen: (1) la ubicacin de la oficina. (2) la colocacin del escritorio del tomador de decisiones; (3) el equipo fijo de oficina (4) los accesorios como las computadoras de bolsillo y las PCs (5) las fuentes externas de informacin como las revistas especializadas y el uso de la Web (6) la iluminacin y el color de la oficina (7) La vestimenta de los tomadores de decisiones. CAPITULO 6: ELABORACIN DE PROTOTIPOS, RAD Y PROGRAMACIN EXTREMA Posted in Sin categora | Abril 30th, 2010 Elaborar un prototipo es un mtodo o tcnica que ayuda a recopilar informacin para as poder completar el ciclo de vida del desarrollo tradicional de un sistema. Un analista al presentar el prototipo debe de estar muy interesado en las reacciones que este producir en los usuarios y lo directivos de la organizacin. Estas reacciones se pueden recopilar a travs de la observacin, la entrevista y las hojas de retroalimentacin, ya que as se pueden obtener de manera ms eficiente las opiniones de todas y cada una de las personas sobre el prototipo, esto despus de que interacte con l. Se dice que la palabra prototipo tiene diversos significados, de los cuales solo son usados 4. 1) Prototipo corregido: Esto quiere decir que en la primera clase de elaboracin de prototipos tiene que estar relacionada con la construccin de un sistema que funciona pero a las este de corrige simultneamente. 2) Prototipo no funcional: Este es a escala configurado para probar ciertos aspectos de diseo. 3) Primer prototipo de una serie: este es totalmente funciona. Involucra la creacin completa del sistema, el cual se le puede llamar piloto. 4) Prototipo de caractersticas seleccionadas: es la creacin de un modelo funcional que incluya alguna, pero no todas las caractersticas que tendr el sistema final. Para desarrollar un prototipo hay que seguir 4 lineamientos principales des pues de que se haya decidido elaborar dicho prototipo, estos lineamientos integran su elaboracin con fase de determinacin de requerimientos del SDLC: 1. El trabajo en mdulos manejables: cuando el prototipo en alguna de sus caractersticas se integra para formar un mdulo funcional, el analista tiene que trabajar en mdulos manejables. 2. Construccin rpida del prototipo: esto es esencial para tener una elaboracin exitosa del prototipo de un sistema de informacin. 3. Modificacin del prototipo: su construccin debe soportar modificaciones. ya que hacer un prototipo modificable es crearlo en mdulos que no sean estos demasiados interdependientes. 4. nfasis en la interfaz de usuario: este es muy importante para la elaboracin del prototipo. Existen desventajas en la elaboracin de un prototipo, ya que este es difcil debido a la rapidez de los procesos, un prototipo incompleto puede ser forzado a colocarse en servicio como si ya fuera un sistema completo, y esto sera un error ya que no trabajara eficientemente. Pero tambin existen ventajas ya que el prototipo nos ayuda a realizar modificacin en las primeras etapas de su desarrollo, tambin nos permite poder suspender el sistema si este no es funcional, y por ultimo tambin ayuda a

desarrollar un sistema que cumpla con todas las necesidades de la organizacin. Tambin se pueden desarrollar prototipos usando un software llamado COTS. El desarrollo rpido de aplicacin o RAD, es un enfoque que es orientado a objetos con tres fases principales: Planeacin de requerimientos Taller de diseo del RAD Implementacin La programacin extrema (XP) este tema fue tratado en el captulo 3, se dice que XP es un enfoque de desarrollo delo software, el cual adopta practicas de software aceptables y las lleva al extremo. Dentro de la programacin extrema podemos encontrar valores y principios, ya que crean el contexto para la colaboracin entre programadores y clientes. Existen 4 valores que crean el entorno, en el cual se pueden servir de manera adecuada el diseador y el negocio. Tambin encontramos 4 actividades bsicas, las cuales son codificar, probar, escuchar y disear. Hay 4 variables de control de recursos, como son el tiempo, costo calidad y alcance. Las 4 prcticas esenciales, son las necesarias en la programacin extrema CAPITULO 7: USO DE DIAGRAMAS DE FLUJO DE DATOS Hay una forma de entender mejor cada uno de los procesos que se realizan dentro de la organizacin, y as entender los movimientos lgicos de los dato, el analista de sistemas realiza diagramas de flujo de datos. Existen 4 ventajas que posee el enfoque del flujo de datos, las cuales describen la relacin con la forma en que los datos se mueven a travs del sistema: 1. Libertad para emprender la implementacin tcnica del sistema en las etapas tempranas. 2. Una comprensin ms profunda de la interrelacin entre sistemas y subsistemas. 3. Comunicar a los usuarios el conocimiento sobre el sistema actual mediante diagramas de flujo de datos. 4. Anlisis de un sistema propuesto para determinar si se han definido los datos y procesos necesarios. En estos diagramas de flujo de datos son utilizados 4 smbolos bsicos los cuales ayudan a graficar el movimiento de los datos: un cuadrado doble, una flecha, un rectngulo con esquinas redondeadas y un rectngulo abierto (cerrado en el lado izquierdo y abierto en el derecho). Con la combinacin de estos cuatro smbolos se puede describir grficamente un sistema completo y varios subsistemas. Todo diagrama de flujo tienen que ser desarrollados de manera sistemtica, el analista tiene que ver cada uno de los flujos de datos desde una manera de jerarqua, ose a de arriba hacia abajo. Ya que hayan recabado una lista bsica de elementos de datos, entonces se podr realizar el diagrama de contexto; el diagrama de contexto debe de mostrar de manera inicial un panorama global que incluye las entradas bsicas, el sistema general y las salidas de los datos. Se dice que este tipo de diagrama es el nivel ms alto en un diagrama de flujo de datos y este contiene un solo proceso, que representa a todo el sistema en s. El siguiente nivel es el diagrama 0, este es la ampliacin del diagrama de contexto y este a su vez puede incluir hasta nueve procesos. El otro diagrama es la creacin del diagrama hijo, el diagrama anterior se le denomina proceso padre, ya que con la ayuda del diagrama 0 se crea la ampliacin con el diagrama hijo, este diagrama no puede producir salida o no puede este recibir entrada, siempre y cuando el proceso padre no produzca o reciba tambin. Hay que tener en cuenta que al realizar un diagrama de flujo de datos se pueden cometer errores, como puede ser: Olvidar incluir un flujo de datos o apuntar con una flecha en la direccin incorrecta Conectar directamente entre s almacenes de datos y entidades externas Entre otros errores.

Existe tambin el diagrama de flujo de datos lgico y fsico, de manera lgica el diagrama se enfoca ms a lo que es el negocio y el funcionamiento de este, mientras que de manera fsica muestra en si como se implementara el sistema, incluyendo todo lo relacionado con el software, hardware, etc. Hay varias ventajas al usar un modelo lgico, entre ellas: 1. Mejor comunicacin con los usuarios. 2. Sistemas ms estables. 3. Mejor entendimiento del negocio por parte de los analistas. 4. Flexibilidad y mantenimiento. 5. Eliminacin de redundancias y creacin ms sencilla del modelo fsico. As como los diagramas de flujo de datos lgicos tienen ciertas ventajas, los diagramas de flujo de datos fsicos tienen otras, entre ellas: 1. Aclarar qu procesos son manuales y cules son automatizados. 2. Describir los procesos con mayor detalle los DFDs lgicos. 3. Distribuir en un orden particular los procesos que se deben realizar. 4. Identificar los almacenes de datos temporales. 5. Especificar los nombres reales de archivos y documentos impresos. 6. Agregar controles para asegurar que los procesos se realicen adecuadamente. CAPITULO 8: ANLISIS DE SISTEMAS MEDIANTE DICCIONARIOS DE DATOS Este captulo como dice su nombre, de los diccionarios de datos, en ella se guarda como una especie de consulta, que con tiene informacin sobre los datos. Este diccionario recopila y coordina trminos de datos especficos y a la vez no da a mostrar el significado para las diferentes personas en la organizacin. El analista de sistemas se basa en el diagrama de flujo para empezar a disear el diccionario de datos, ya que se tiene que tener un enfoque de manera jerrquica, este es un trabajo que sirve como referencia por que contiene datos acerca de datos. Para entender mejor se dice muchos sistemas de administracin contienen diccionarios de datos de manera automtica. Adems de proporcionar documentacin y eliminar la redundancia, el diccionario de datos se podra usar para: 1. Validar la integridad y exactitud del diagrama de flujo de datos. 2. Proporcionar un punto de partida para desarrollar pantallas e informes. 3. Determinar el contenido de los datos almacenados en archivos. 4. Desarrollar la lgica para los procesos del diagrama de flujo de datos. Todo diccionario de datos tiene que contener el nombre del elemento o campo, una descripcin, el rango, la longitud, y la informacin que sea necesaria. Este diccionario de datos es muy til al momento de crear la base de datos en algn lenguaje de programacin. CAPITULO 9: DESCRIPCIN DE LAS ESPECIFICACIONES DE PROCESOS Y DECISIONES ESTRUCTURADAS Ya que pasamos los captulos anteriores identificando los que son los flujos de datos y base a este se empieza a construir el diccionario de datos, entonces es necesario pasar a otro paso, como son las especificaciones de procesos y el anlisis de decisiones. En este captulo se describirn 3 mtodos mas para as tomar una mejor decisin y para as poder describir la lgica del proceso, estos mtodos: el lenguaje estructurado, tablas de decisiones y arboles de decisiones Las especificaciones se le pueden llamar a veces miniespecificaciones, ya que representan una pequea parte de las especificaciones del proyecto en total. Este contiene tres metas para poder as producir especificaciones de procesos: 1) Reducir la ambigedad del proceso 2) Obtener una descripcin precisa de lo que se est realizando. 3) Validar el diseo del sistema

Tambin existen procesos que no necesitan o no requieren especificaciones, de las cuales se mencionan algunas categoras: 1. Procesos que representan entrada o salida fsica, tal como leer y escribir. 2. Procesos que representan una validacin de datos simple, la cual normalmente es bastante fcil de realizar. 3. Procesos que usen cdigo preescrito. Las especificacin de procesos estn vinculados a los diagrama de flujo y por consiguiente tambin a los diccionarios de datos. Este se debe registrar en un formulario especial. Lenguaje estructurado Este lenguaje es utilizado cuando la lgica del proceso involucra formula o interacciones o cuando las decisiones no son nada complejas. Esta tcnica ayuda a analizar el proceso de decisiones, este se basa en lgica estructurada. Este utiliza instrucciones o palabras claves como son el IF, THEN, ELSE, DO, DO WHILE, DO UNTIL y PERFORM. Estas palabras claves son las nicas aceptadas por este lenguaje; y tambin es vlido agregar sangras, para as poder identificar la jerarqua de la estructura dependiendo del proceso de decisin. Tabla de decisiones Esta es una tabla como cualquier otra, ya que contiene filas y columnas, separas en cuatro cuadrantes. En las cuales se encuentran las condiciones, las reglas, sus acciones y las entradas de las acciones. Para determinar las acciones, la lgica se mueve en el sentido de las manecillas del reloj empezando por la parte izquierda. Para desarrollarla el analista tiene que determinar que tamao tendr la tabla, los pasos siguientes proporcionan al analista un mtodo sistematizado 1. Determine el nmero de condiciones que podran afectar la decisin. 2. Determine el nmero de posibles acciones que se pueden realizar. 3. Determine el nmero de alternativas de condicin para cada condicin 4. Calcule el nmero mximo de columnas en la tabla de decisin multiplicando el nmero de alternativas para cada condicin. 5. Complete las alternativas de condicin. 6. Complete la tabla insertando una X en donde las reglas indiquen ciertas acciones. 7. Combine las reglas en donde sea evidente que una alternativa no representa una diferencia en el resultado. 8. Verifique si la tabla contiene situaciones imposibles, contradicciones y redundancias. 9. Reorganice las condiciones y acciones (o incluso las reglas) si esto hace ms comprensible la tabla de decisin. rbol de decisiones Este es el ltimo mtodo, se utiliza tambin para el anlisis de decisiones, est compuesto por nodos y ramas. Este tipo de mtodo est asociado con el mtodo anterior que son las tablas de decisiones. Tambin son apropiados ya que ayudan cuando las acciones que se realizaron son de cierta forma secuencialmente. CAPITULO 10: PREPARACIN DE LA PROPUESTA DE SISTEMAS Este captulo trata que cuando se va a implementar el sistema, el analista tiene que ver si la organizacin necesita comprar equipo nuevo, para poder instalar el sistema. Con frecuencia se exige a analistas de sistemas desarrollar o evaluar paquetes de software de nivel superior usado por los sistemas de apoyo a la toma de decisiones. El analista puede ayudar a obtener la informacin necesaria para identificar los objetivos, alternativas, criterios, atributos y prioridades o pesos necesarios para la toma de decisiones criterios mltiples. Dice que para tener lista una propuesta, hay que identificar primero los costos y beneficio de varias alternativas con el sistema. Tiene que ver si el sistema tendr buenos resultados, si ser eficaz en el desarrollo de la organizacin. Los costos y

beneficios de este tienen que ser tangibles o se cuantificable, pero tambin pueden ser intangibles (no cuantificables). Para realizar estos anlisis, el analista puede tener muchos mtodos, los cuales se mencionaran unos: El anlisis de punto de equilibrio, anlisis del tiempo y el anlisis de flujo de efectivo. El analista de sistemas debe seguir tres pasos principales para reunir una propuesta de sistemas eficaz: organizar eficientemente el contenido de la propuesta, escribir la propuesta en un estilo de negocios apropiado y presentar de forma oral una propuesta de sistemas informativa.